What a Good Technology Discovery Phase Looks Like
Discovery is often sold with a claim that traces to an internal IBM training programme with no published dataset. That does not mean discovery is worthless — it means the pitch for it has been resting on the wrong evidence.
Discovery phases are sold constantly and delivered inconsistently. Part of the reason is that the most common justification for them rests on evidence that does not actually say what it is quoted as saying.
The claim that needs retiring
You have likely heard some version of: defects found early cost 100 times less to fix than defects found in production. This traces back to an IBM Systems Sciences Institute figure that was an internal training programme, not a published, peer-reviewed study — no dataset has ever been made public. The largest modern empirical study on the question — 171 projects, 2006 to 2014 — found "no evidence for the delayed issue effect." Its authors go further: "DIE might be an historical relic" from earlier, differently structured software projects. (Empirical Software Engineering, 2017)
This does not mean discovery is worthless. It means discovery should be justified by what it actually demonstrably does, not by a number that does not survive scrutiny.
What discovery actually does well
Requirements quality correlates with project outcomes in the contexts that have been studied, even without the dramatic 100x framing. A discovery phase, done properly, reduces the single biggest source of avoidable rework: building the right thing incorrectly understood, rather than the wrong thing correctly built.
It also directly addresses the risk our piece on rewrite, refactor or replace describes for legacy replacement projects — behavioural discovery, documenting what a system actually does versus what it was designed to do, is a discovery exercise by another name.
What a real discovery phase produces
A written, specific set of requirements — not a shared feeling of alignment. If discovery ends with "we all understand the project better now" but no artefact anyone can point to and say "this is what we agreed," it has not produced anything durable.
Named assumptions, distinguished from confirmed facts. A discovery document that treats an assumption as settled fact is more dangerous than no discovery at all, because it creates false confidence.
Identification of the specific risks that could derail the project, not generic ones. "Integration risk" is not a finding. "The payments provider's sandbox environment does not support the webhook pattern the checkout flow requires" is a finding — specific, checkable, and actionable before a contract is signed on the assumption it would work.
A go/no-go recommendation the client can actually evaluate. A good discovery phase is willing to conclude that the project as scoped should not proceed, or should proceed differently. A discovery phase that always concludes in favour of the vendor's larger follow-on engagement should be treated with proportionate suspicion.
Data quality findings, where relevant. For any project involving existing data — migration, integration, analytics — discovery should include at least a lightweight data profiling pass, because as we cover in data migration risk, legacy data is rarely as clean as anyone assumes going in.
What a padded discovery phase looks like
Generic risk lists that could apply to any project. No named assumptions — everything presented as settled. A recommendation that always happens to favour more billable work. No artefact that could be handed to a different vendor if the client chose to walk away afterward — which is itself a red flag, because a discovery phase whose output only makes sense in the hands of the vendor who produced it is really a sales tool wearing a research phase's name.
How to price and scope it
Discovery should be a distinct, capped, priced engagement — not an open-ended activity that blends into the build. Agree upfront on what it will produce, and confirm that the output belongs to you regardless of whether you proceed with this vendor afterward. If a vendor resists that last point, they have told you something about what they think discovery is actually for.
What we do
We scope discovery as a standalone, fixed-price engagement with a specific deliverable the client owns outright, and we are willing to recommend against proceeding when discovery finds a reason to. If you are planning a project and want a discovery phase that produces something real rather than a sales pitch with extra steps, that is a conversation we are glad to have.
Kaizen Spark Tech designs and delivers software, AI, automation and digital infrastructure for businesses and institutions. Every statistic here is linked to its original published source. Where a widely-quoted figure turned out to have no traceable primary source, we have said so rather than repeated it.