How to Run a Discovery Session That Produces Usable Scope

Get the right people in the room

The sponsor knows why the project exists. The system owner knows what is really in there. The person who does the work today knows which of the documented processes are fiction. You need all three, and they are rarely the same person.

If you can only have one session, prioritise the system owner and the operator over the sponsor. Sponsors describe intent, which you can infer; operators describe reality, which you cannot.

• Sponsor or budget holder: outcome, constraints, decision authority.
• System or data owner: what exists, in what condition, and who controls access.
• Day-to-day operator: how the work actually happens versus how it is documented.
• From your side: whoever will build the estimate, not just whoever sold the meeting.

A ninety-minute structure that works

Discovery drifts when it is unstructured, and produces defensive answers when it is over-structured. This shape leaves room for the conversation while guaranteeing you leave with the material you need.

• 0–10: outcomes. What has to be true when this is done, and what happens if nothing changes.
• 10–30: current state. Systems, data, processes, and who owns each.
• 30–55: drivers. Counts of integrations, roles, entities, reports, workflows, locations.
• 55–70: boundaries. What is explicitly not in this phase, and what comes next.
• 70–80: constraints and risk. Compliance, security review, freeze periods, the thing they are worried about.
• 80–90: read-back. Scope heard, drivers heard, assumptions you will make, questions still open.

Ask for numbers, not impressions

'A lot of integrations' cannot be estimated. 'Six, of which two are to a mainframe nobody has documented' can be. Whenever a client uses a quantity word, ask for the quantity.

Where the client does not know the number, that is not a failure — it is your most valuable output. It becomes an open question with a named owner, and it is the reason your first estimate is a range rather than a figure.

Listen for the four buckets in real time

Everything said in discovery sorts into requirements, open questions, assumptions, and risks. You do not need to sort it during the session — that costs you the detail — but you do need to notice when a risk goes past unremarked.

The tell for a risk is usually hedged language: 'normally', 'should be fine', 'we think', 'assuming they've finished'. Those sentences are where next quarter's change order is born.

Capture the session, do not summarise it

Record where the client permits it, and keep the raw material with the engagement rather than in a personal notebook. The most common failure in scoping is that the person who ran discovery is not the person who builds the estimate, and the context never made the trip.

Written summaries lose exactly the detail that turns out to matter: the aside about a system nobody supports, the qualifier on a date, the name of the person who has to approve.

Close with a read-back, always

Spend the last ten minutes stating what you heard: the deliverables in scope, the drivers and their numbers, the assumptions you will estimate on unless corrected, and the questions still open with an owner and a date.

Clients correct read-backs. They rarely correct documents sent three days later, and never correct assumptions they were not told you were making.

What to do between the session and the estimate

Send the read-back in writing within a day, while the session is still fresh for both sides. Keep it short: scope, drivers, assumptions, open questions, next step and date.

That single email does more for estimate quality than any amount of internal analysis, because it converts your interpretation into something the client has had the opportunity to object to.