01What discovery is for
Discovery is a short phase before the build in which the team learns enough about users, processes, data and constraints to plan the work with confidence. The GOV.UK Service Manual describes the same idea for public services. Its outputs should reduce the uncertainty in every later decision, including the price.
02What it should deliver
Agree the outputs before discovery starts, and make sure you own them:
- Documented goals, users and the journeys the first release must support.
- Business rules, data sources and integrations, with known gaps marked.
- A prioritized scope with explicit exclusions.
- Key technical decisions and a proposed architecture.
- Risks and assumptions, and how each will be tested.
- A release plan and an estimate with its assumptions stated.
03What happens without it
The US Government Accountability Office’s review of HealthCare.gov (GAO-14-694, July 2014) found that key systems were commissioned while important technical requirements were still unknown, and that the site launched without verification that it met its performance requirements. Starting the build before the requirements are understood moves discovery into the most expensive phase of a project.
04How long it takes and who is involved
For a typical business project, discovery is measured in weeks rather than months, depending on the scope and how quickly people and data are available. The people who run the process today are essential, and their availability often sets the pace.
05Paid discovery or free proposals?
A detailed proposal written without discovery is an estimate built on assumptions. Many teams sell discovery as a separate, fixed piece of work whose outputs you own and can take to any partner; ask whether that is the case before you sign. For comparing what you receive, see how to compare development proposals.
06Questions to ask before discovery starts
A clear project brief shortens discovery by answering the first questions before the first workshop. Then ask:
- What exactly will we receive at the end, and in what format?
- Who from our side needs to be involved, and for how long?
- Will the estimate after discovery be binding, and on which assumptions?
- Can we use the outputs with another partner?
Editorial approach
This guide offers practical planning questions. It is not a guarantee of delivery outcomes. Adapt the checklist to your project and validate assumptions with the proposed team.
