How to use these
Ask them in one session, with the person who does the work in the room rather than only the person sponsoring the project. Write the answers down. Questions that cannot be answered are the finding — they are the scope nobody has costed yet.
1. What does this workflow cost today?
In hours or headcount, stated by someone who does it. If nobody can answer, you are shopping for a problem rather than solving one — start at the expensive workflow.
A usable answer sounds like “two people, roughly half their week, most of it in the triage step”. That level of detail also tells you which part to automate, which is a different question from whether to.
2. Can a human check the output in seconds?
If not, you cannot evaluate it, catch drift, or trust it. That single property decides whether this is a safe first project or something that should wait.
Name the person who would do the checking, not the role. Verification requires the same expertise as the task, so if that person is already the bottleneck you may be about to add work to your scarcest resource.
3. What does a mistake cost, and who notices?
Recoverable, invisible, or reputational. Anything irreversible or customer-facing multiplies the governance work, and it is where escalation on stakes becomes mandatory rather than nice.
The second half of the question matters more than the first. A recoverable mistake nobody notices for three months is worse than a visible one caught immediately, because by then it has propagated into records, reports and customer expectations.
If nobody can say what the current process costs or how a mistake would be caught, the project isn’t ready to start.
4. Does the knowledge exist in writing?
Usually partly. The gap is the real scope, and discovering it late is why estimates are wrong — the knowledge base often is the project.
Test it cheaply: pick five questions the system would need to answer and try to find a current, correct, written answer for each. Most teams find two, and the gap between two and five is measured in weeks of somebody’s time.
5. What must it never be able to see?
Ask in week one. Retrofitting permissions into retrieval after indexing everything is the most expensive correction in the category.
The usual answers are other customers’ records, internal notes attached to customer records, pricing exceptions, and anything under a client confidentiality obligation. Each has to be excluded at the index rather than discouraged in the prompt.
6. What would make us stop?
A result that means abandon, agreed before building. Without it the project cannot conclude, only continue — the anatomy of a permanent pilot.
7. Who owns it in eighteen months?
A name, for the evaluation, the knowledge, and the reviews. If there isn’t one now there won’t be one later, and unowned systems decay.
Ask that person directly whether they have the hours. An owner assigned in a meeting they did not attend is not an owner, and this is the single most common way a working deployment quietly stops working.
8. What does it leave behind?
Retrieval, logging, corrections, an evaluation harness. Prefer the project whose by-products make the next one cheap — that is how a first feature becomes a capability rather than a one-off.
What the answers tell you
Clear answers to all eight mean you are ready to run a two-week proof of concept. Gaps in four and five mean the first phase is documentation and access control, not modelling. No answer to one, six or seven means the project is not ready regardless of how good the technology is.
None of this takes longer than an hour, and it reliably predicts which projects ship. That ratio is why it is worth doing before anyone writes a proposal.