Skipping discovery is not always the most expensive choice. Running an oversized discovery for a small, reversible change can cost more than learning through delivery.

The expensive decision is committing beyond the evidence the decision requires.

That refinement preserves the useful source argument and makes it practical. Discovery should be proportional to uncertainty, consequence and reversibility. It is a means of improving a commitment, not a mandatory toll before every project.

Start with the decision, not the phase

“Do discovery” is too broad. State the decision it needs to support.

A firm may need to decide whether to replace a CMS, how to repair onboarding, which portal task to prioritise, whether data can support an AI use or how much of a migration to commit.

Each question requires different evidence and specialists. A general programme of workshops, audits and research can appear thorough while failing to address the point of irreversibility.

Define:

  • the decision and owner;
  • options genuinely open;
  • critical assumptions;
  • consequence of error;
  • evidence already available;
  • new evidence required;
  • budget and deadline;
  • output and acceptance.

Discovery is complete when the agreed evidence is sufficient for the decision, with uncertainty visible.

Use more discovery when commitment is hard to reverse

A large data migration, regulated client service, long contract or core platform can create high switching and failure costs. Technical, user, operational, financial and legal evidence deserve investment before commitment.

Discovery should test the assumptions that could change the option or scope. It should not attempt to remove every unknown. Some architecture and behaviour can only be learned through prototypes or delivery.

Use less discovery where the change is contained, safe, cheap to reverse and observable. A small content improvement may be released behind normal controls and assessed. The delivery itself produces evidence.

The appropriate question is “What is the cheapest safe way to learn what we need?”

Requirements gathering is one method

If the problem and solution are well understood, structured requirements may be enough. If leaders have self-diagnosed a solution, broader investigation can test whether the brief describes the cause.

Useful discovery methods include:

  • observation and interviews around real tasks;
  • analysis of service, support and commercial evidence;
  • content and data audit;
  • system and integration inspection;
  • security, privacy, accessibility and legal assessment;
  • prototype or technical spike;
  • operating-model and capability review;
  • option and total-cost comparison.

Choose methods for the uncertainty. Do not perform every method because it appears in the agency template.

Stakeholders supply evidence and conflict

The marketing lead, technology owner, finance director, frontline employee and client can see different parts of one service.

Discovery should expose those differences rather than force early consensus. Ask which observations are facts, which are interpretations and which reflect competing outcomes.

Interviewing everybody is unnecessary and can become avoidance. Sample roles based on the decision and include people affected by failure or exclusion. State who was not represented and the effect on confidence.

Senior sponsors must be available for trade-offs. Delegating every interview and returning only to approve the answer produces late surprise.

User research needs ethical and useful scope

Observe representative users completing relevant tasks. Include accessibility and differing confidence. Protect privacy, obtain appropriate consent and avoid asking participants to disclose sensitive client information unnecessarily.

Research is not a vote. A small group can reveal severe usability barriers without estimating population prevalence. Leaders still balance evidence, duties and strategy.

Do not manufacture a dramatic insight to prove discovery had value. Confirmation of a tested assumption can reduce material risk.

Technical discovery should find decision-changing risk

Inventory critical components, support, dependencies, data, interfaces, customisations, environments and operating ownership.

Use representative production-like data through approved safe access. Inspect failure, recovery and migration, not only the happy path.

A diagram is insufficient if nobody verifies which systems or jobs still rely on the legacy service. Equally, a complete estate map may be unnecessary for one bounded integration.

Identify uncertainties and options. Avoid turning every imperfection into scope for the supplier.

The output should be portable

A client should receive evidence, decisions, options, assumptions and recommendations it can use with another capable team.

A good output includes:

  • current problem and affected users;
  • evidence with source and confidence;
  • constraints and duties;
  • options and trade-offs;
  • recommended next commitment;
  • dependencies and risks;
  • what should wait or stop;
  • measures and review;
  • unresolved questions;
  • ownership and estimated range.

A flat list of requirements is not automatically discovery. A sixty-page report is not automatically strategy. Judge whether the output changes or strengthens the decision.

Independence needs commercial disclosure

An implementation supplier may be well placed to run discovery and has an incentive to recommend follow-on work.

Make that interest visible. Ask whether options include repair, internal delivery, another platform or another partner. Separate findings from the proposal. Retain rights to research and decision materials.

A paid discovery can legitimately lead to a proposal. It becomes a sales exercise when evidence is shaped so only the supplier's offer can follow.

Discovery can fail through excess

Warning signs include:

  • questions expand without a decision change;
  • the same evidence is collected twice;
  • workshops substitute for observation;
  • every stakeholder receives a veto;
  • options remain open after criteria distinguish them;
  • the team avoids a recommendation;
  • delivery never begins because certainty is the unstated target;
  • the report repeats the brief in more polished language.

Set decision gates and stop conditions. Extend only when missing evidence could materially change the commitment.

Discovery can fail through absence

Other warning signs include:

  • a vendor appears before the outcome is defined;
  • user or client need is assumed;
  • data migration is estimated from record counts alone;
  • security, legal or accessibility work appears at the end;
  • internal capacity and operating ownership are missing;
  • success equals launch;
  • a detailed fixed price rests on untested dependencies.

The answer may be a short validation, prototype or specialist assessment rather than a large phase.

Compare its cost with decision exposure

The source contains repeated client cases involving £400,000 scope, £320,000 avoided spend and a 22% conversion change. It also includes a second overrun anecdote. Hold all of them until engagement records, metric definitions, causal limits and client permission are verified.

Build the economic case from the current decision. Estimate discovery cost, delay, internal demand and the probability that it changes the choice. Compare with plausible rework, lock-in, harm and opportunity cost.

Do not promise that discovery always saves money. It can increase confidence, reveal that the current option remains best or show that the project should stop. Those are legitimate returns.

The client helps create value

Provide access, context and timely decisions. Be candid about budget, politics, previous failures, contracts and untouchable systems. Protect client and personal data through agreed routes.

Challenge the methods and recommendations. Ask what the team believes, why and what would overturn it.

Accept that a useful conclusion may be smaller, later, different or no project. Do not commission independent diagnosis while making a predetermined solution politically mandatory.

Make the next commitment explicit

Discovery should end with a decision meeting. Approve a bounded next phase, request one specified piece of evidence, choose another route or stop.

Record owner, funding, assumptions and review. If delivery follows, carry research participants, measures and risks into it so the insight does not disappear at handover.

The most expensive digital projects I've ever seen aren't the ones with ambitious scope or complex integrations. They're the ones that started building before anyone properly understood what they were building, or why.

If you're considering a digital project - a replatform, a redesign, a new portal, an AI initiative, whatever it is - and you're weighing up whether discovery is worth the investment, flip the question. Can you afford the cost of getting it wrong? Because that's what skipping discovery actually puts on the table.