Discovery has a reputation problem. To a buyer it can look like paying an agency to write a document before any of the real work starts, and plenty of suppliers have earned that suspicion by delivering exactly that: a deck restating what the client already told them.
Done properly it is the opposite. Discovery is where the expensive decisions get made while changing your mind still costs a conversation rather than a rebuild.
What it is for
The purpose is to replace assumptions with facts before anyone commits a budget. Four questions, specifically.
What are we actually building? Not the feature list. The workflows, the rules, the states a record can be in, what happens on the unhappy paths. Most of this lives in people’s heads and contradicts itself until it is written down.
What does it have to connect to? Every system the new software touches, whether each has a usable API, whether there is a test environment, and who can authorise access. This is the largest single source of cost overrun in custom projects.
What is the data situation? What exists, what condition it is in, and what has to move. Data is almost always worse than anyone expects.
What could stop this working? Technical risks, organisational risks, and anything that needs a decision from somebody not currently in the room.
What actually happens during it
On a mid-sized project this runs two to four weeks, and the work is unglamorous.
Watching people do the job. Not asking them to describe it. Watching. The gap between the described process and the real one is where the requirements you would otherwise miss are hiding. Someone always maintains a spreadsheet on the side because the official system cannot do something, and that spreadsheet is a requirement.
Mapping the integration surface. For each connected system: documentation, credentials, rate limits, a sandbox, and a named human who owns it. A lot of discovery time goes into finding out that the sandbox does not exist or the API costs extra. Better now than in week nine of a build.
Looking at real data. Not a sample, not a schema diagram. Production data, with counts. How many records hold a null in a field the new system treats as required. How many duplicates. How many dates stored as text.
Deciding the architecture. Enough to estimate and to avoid a choice that becomes expensive to reverse. Where it runs, what it is built with, how authentication works, how data moves. Not a design for every screen.
Prototyping the frightening part. Where something is genuinely uncertain, build the smallest thing that settles it. A day confirming an integration behaves as documented can save several weeks.
What you should receive
That last point matters more than it sounds. The order of work is a commercial decision, not a technical one. Building the easy parts first produces comfortable early progress and concentrates all the risk at the end, when there is no money left to absorb it.
What skipping it costs
Projects that start without discovery do not skip the work. They do it during the build instead, at a much worse rate.
The pattern is consistent. The first few weeks feel fast because the obvious parts get built. Then someone finds the integration cannot do what was assumed, or the data will not migrate as it stands, or two departments want incompatible things and nobody has authority to choose. Now the team is idle or, worse, building on a guess. The eventual fix costs several times what the same decision would have cost before any code existed.
There is a second cost that is easier to miss. Without a written scope there is no agreed definition of finished, so the project ends when the budget runs out rather than when the thing works. That is how software gets delivered and then quietly not used, which is the failure mode the research says is most common: across more than 5,400 IT projects, McKinsey and Oxford found the average value shortfall (56%) was larger than the average cost overrun (45%).
The same research found the worst overruns clustered in projects with infrequent checkpoints, where a quarterly review meant three months could pass before anyone noticed the project had drifted. Discovery sets the checkpoints as much as it sets the scope.
Discovery that is not worth buying
The scepticism is sometimes justified. Signs you are being sold theatre:
- It produces a presentation rather than a scope, an architecture and an estimate
- Nobody asks to see your data or your existing systems
- No developer is involved, only a consultant and a designer
- The output could not be handed to a different supplier and used
- The price is a fixed percentage of the build rather than a function of what needs investigating
- The conclusion is always that you should proceed
That last one is the clearest test. A discovery that cannot conclude “do not build this, or not in this form” is not an investigation. It is a sales process with a deliverable attached.
How we run it
Ours is fixed-price and time-boxed, with the scope of the investigation agreed in advance, and it is deliberately separable from the build. You can take the output to another supplier. If discovery shows the project should not proceed as described, that is a legitimate result and a cheap one next to finding out later.
It ends with an estimate carrying a stated range and stated assumptions, which is the only kind worth relying on. There is more on how that becomes a number in what custom software actually costs, on evaluating suppliers in choosing a development partner, and on the warning signs in why software projects run over budget.
If your project is still a description rather than a specification, tell us about it. That is the stage discovery is designed for.
Common questions
How long should a software discovery phase take?
Two to four weeks for a mid-sized project. Long enough to watch people work, map every integration, look at real production data and prototype the uncertain part. Much shorter and it becomes a requirements interview. Much longer and it is usually substituting for a decision somebody needs to make.
What should a discovery phase deliver?
A scope statement with explicit exclusions, an integration map with owners and blockers, an assessment of the real data, architecture decisions with reasoning, a project-specific risk list, and an estimate with a stated range and written assumptions. If it produces only a presentation, it has failed.
Can we skip discovery to save money?
You can skip the phase but not the work. It gets done during the build instead, at developer rates, with the team blocked or building on assumptions while it happens. The decisions are the same. Only the price changes.
Sources
- McKinsey & Company with the University of Oxford, Delivering large-scale IT projects on time, on budget, and on value. More than 5,400 IT projects: 45% average cost overrun, 56% less value than predicted, with the worst overruns concentrated in projects with infrequent checkpoints.
Figures were current at the time of writing (September 2026).
