Discovery questions have one job: reduce the number of things you have to guess at when you estimate. These are grouped so you can pull the sections relevant to the engagement rather than reading a script.
Two habits matter more than the list itself. Ask for numbers wherever a number exists, and write down what you did not get an answer to — unanswered questions are the real source of estimate volatility.
How to use this
- Pick the six to ten questions per section that fit the engagement; a full read-through turns a conversation into an interrogation.
- Record the session where the client permits it, so you capture detail rather than interpretation.
- Close every session by reading back the effort drivers you heard and the questions still open.
Outcome and business context
- What outcome does this project need to produce for the business?
- What happens if nothing changes over the next twelve months?
- Who inside the organisation asked for this, and who is funding it?
- How will you know, six months after go-live, whether this worked?
- Is there a date this has to land by, and what drives that date?
- What has already been tried, and why did it stop?
- What does this need to be compatible with a year from now?
Current state
- Which systems are involved, and which are you planning to retire?
- Who owns each of those systems internally?
- Where does the data live today, and who maintains it?
- What condition is that data in — completeness, duplication, structure?
- Which processes are documented, and which live in people's heads?
- What integrations exist today, and how were they built?
- What environments do you have: production, staging, development?
- Are there systems we cannot touch, and why?
Scope boundaries
- If we could only deliver one part of this, which part would it be?
- What is explicitly not in this phase?
- Which teams, regions, or business units are in scope, and which come later?
- Are there processes you intend to change as part of this, or keep as-is?
- Does anything need to run in parallel with the old way for a period?
- What would you consider a minimum acceptable version of this?
- What is on the roadmap immediately after this project?
Effort drivers
This section is where estimates are won or lost. Ask for counts, not impressions.
- How many integrations, and to which systems and versions?
- How many user roles or permission profiles?
- How many records, transactions, or documents, and over what history?
- How many locations, entities, currencies, or languages?
- How many reports or dashboards, and are any regulatory?
- How many workflows need configuring, and how different are they from each other?
- How many review or approval cycles do you expect per deliverable?
- How many stakeholder groups will need to sign off?
- Is any custom development required, or is configuration sufficient?
- What volume of content, data, or configuration must be migrated?
Stakeholders and decision-making
- Who has final decision authority on scope?
- Who has to be consulted before a decision becomes real?
- Who could stop this project, and what would make them want to?
- How are decisions normally made here — single owner, committee, consensus?
- How long does a typical approval take?
- Who will review our deliverables, and how much of their week can they give this?
- Is there a steering group, and how often does it meet?
Constraints, compliance, and security
- What regulatory or contractual constraints apply to this work?
- Is there a security review, and what does it involve and when?
- Are there restrictions on where data can be stored or processed?
- Do our people need background checks, training, or specific access approvals?
- Are there change freeze periods, audits, or peak seasons to avoid?
- What are your requirements for accessibility or internationalisation?
- Is there an internal architecture or tooling standard we must follow?
Ways of working
- Who from your team will be embedded with ours, and for how much of their time?
- Where will work happen, and is onsite presence expected?
- What tools do you use for tracking, documentation, and communication?
- What is your release process, and who controls production access?
- Do you expect us to work in sprints, phases, or continuous flow?
- Which of your teams will take this over after delivery?
- What does handover need to include for that team to be self-sufficient?
Risk
- What is the part of this you are most worried about?
- What has gone wrong on similar projects here before?
- Which dependency are you least confident will be ready on time?
- Are any of the systems involved being changed by another project right now?
- Which assumption, if wrong, would change this project the most?
- Is there organisational change coming that could affect this?
Commercial context
- Is there an approved budget, and does it cover licences and internal time as well?
- What procurement process does this have to pass through, and how long does it take?
- Who signs the contract, and what is their approval threshold?
- Do you prefer fixed fee or time and materials, and why?
- Are you evaluating alternatives, and what would make one of them a better fit?
- What would cause this to be deferred to next year?
Close the session
- Read back the deliverables you believe are in scope.
- Read back the effort drivers and the numbers you were given.
- State the assumptions you will estimate on unless corrected.
- List the questions still open and who will answer each one, by when.
- Confirm who receives the estimate and who reviews it before pricing is discussed.
This template is general guidance for scoping and drafting practice, not legal advice. Have your own counsel review contract language before use.
Put this into practice
SOW Studio turns discovery inputs into structured scope, a reviewable estimate, and a client-ready Statement of Work — with your team approving every step.
No credit card required. Full Professional capabilities for 14 days.