النسخة العربيةAR
Let’s talk

A good partnership starts with a conversation.

Guides & insights

What Should Technical Discovery Reveal About Project Risks?

Useful discovery distinguishes consequential unknowns from confirmed obstacles and links assumptions to evidence, resolving tests and decision owners before scope or timing is fixed.

5 min read
A professional examines a document with a magnifying glass beside a laptop and notebook

A proposal says data can migrate, employees will use the app and integration is available. These may be reasonable assumptions, but become expensive when cost and timing treat them as established facts. Useful discovery identifies which assumptions deserve testing before implementation commitments.

Do not request a long list of generic potential risks. Connect unknowns to important project outcomes, available evidence and decisions following defined checks. The consultant need not promise to remove all uncertainty, but should prevent it hiding inside an apparently final estimate.

Separate unknowns from existing problems

In a fictional laundry network, a shared portal will track customers' items through reception, preparation and delivery. An old system holds some records while branches use separate files. The team assumes item references can be matched and operational status read, but has not examined a representative sample.

If a required file demonstrably cannot be extracted through available means, that is an existing obstacle to address, not only a future possibility. Whether references match across every branch remains an open assumption. Distinguishing them determines whether action must solve a problem or an experiment must obtain evidence.

Three assumptions and three evidence types

Example assumptionPossible current evidenceProposed resolving test
Item references can connect both sources.Field descriptions and a small one-branch sample.Match an authorized sample of branches and cases, reporting differences.
The mobile journey suits reception employees.Management opinion without observed use.Observe a test task with artificial content and appropriate users.
The old system exposes the required status.An interface name or untested assurance.Authorized technical validation of reading and limits in an identified environment.

These example experiments are not a universal recipe or permission to use customer data without suitable arrangements. Checks may require access, authorization or third-party coordination. Record those inputs, work possible without them and evidence limits when they are unavailable.

A decision card for each consequential assumption

  • Statement: what do we believe, expressed in a testable way?
  • Impact: which function, duration or cost changes if it is false?
  • Available evidence: supporting observations, files or tests, with dates and limits.
  • Missing coverage: cases, environments or groups outside that evidence.
  • Check: the smallest suitable experiment that informs a decision and its expected output.
  • Ownership: input provider, implementer and result approver.
  • Decision point: when results are reviewed and which work depends on them.
  • Response: continue, change scope, use an alternative or stop under evidence-based conditions.

Do not turn impressions into precise probabilities to fill a field. Prioritize checks using consequences of failure, weak evidence and the cost of late discovery. Explain the priority rather than making a register appear scientific through unmeasured numbers.

Design a test that changes a decision

Reading one laundry record does not establish matching across every item state. Request a sample covering known variation, expected results before testing and an account of unchecked cases. Unmatchable references may change cleanup scope or the first-phase approach.

This differs from implementing the entire project under the label validation. A limited test, source review or user observation may answer a particular question. Agree effort boundaries and outputs before buying the experiment, including unknowns remaining afterward rather than expanding discovery indefinitely.

Use references without importing their procedures

GOV.UK discovery guidance addresses understanding users and constraints before continuing. Its alpha guidance emphasizes testing consequential assumptions. These principles do not prescribe government procedures or durations, nor establish commercial viability from a small experiment.

Consult discovery purchasing deliverables when comparing the consultancy service itself. For external approval risks, the API dependency register details follow-up ownership. This card connects the need for investigation with the decision after evidence, rather than repeating consultancy deliverables or approval lists.

Acceptance does not require concealing unknowns

Request a review of the important cards: what belief changed, what evidence changed it and which scope or estimate changed as a result? Separate observations, interpretations and recommendations. Retain open assumptions with owners and next steps.

Technical discovery with Nextwave may end by requesting missing input, reducing scope or recommending no start yet. A useful outcome is an explainable decision that can change with new information, rather than approval simply because meetings ended.

Sources and preparation

GOV.UK's discovery and alpha guides were opened on 4 November 2026. The example and card are editorial; no client system investigation or financial probability assessment was performed. AI assisted preparation with meaning and source review.

FROM INSIGHT TO ACTION

Turn an idea into something that works.

Explore Nextwave software, business systems and application services for your next step.

Explore our services