Software discovery: what you should receive

Agree the decision the report must support

Write the decision on the first page of the discovery agreement. For example: “Should the business change its repair-approval process, and what should it test before commissioning software?” Name who will approve the findings and what evidence they need. A list of proposed screens can wait.

The GOV.UK discovery guide starts with understanding the problem and its constraints, and treats stopping as a valid outcome. This is guidance for public services. The deliverables below adapt that approach for a private business; government phases and assessment requirements do not become rules for your project.

Agree the depth as well as the document names. A review of one workflow can produce a useful next step while leaving wider research or technical checks for a separate scope. Discovery should make those limits visible.

1. A workflow map you can check against a real task

The map should identify the trigger and the point at which the task is complete. Between them, show who acts, which record they use and what happens when work crosses a boundary. Include the awkward exception. A box labelled “approval” leaves too much unanswered.

Consider a hypothetical appliance-repair service. A customer requests a repair; a coordinator opens a job; a technician assesses the fault; the customer receives an estimate and agrees the work. Then the technician finds an additional fault. The important question is which version of the estimate the customer approved.

The map should show how that revised estimate reaches the customer, what pauses while consent is outstanding and where the coordinator checks the answer. For your own workflow, attach a redacted example to the relevant step. The business-systems service outline describes this workflow-first starting point.

The approval boundary in the example

2. An evidence record that separates findings from guesses

Ask for a short evidence record beside the requirements. Each entry should say what was examined, what it supports and what remains uncertain. Someone remembering a problem is useful input; the record should distinguish that account from an observed task or a checked system capability.

GOV.UK user-research guidance includes observing current work, interviewing users and examining existing data. It also considers the people providing the service and offline steps. For this repair example, a customer-facing form would show only part of the approval process.

Use the following as an illustrative record format. These sample artefacts and findings are invented to demonstrate the document, not evidence collected from a business.

• ·E1, sample original estimate and approval email: supports the need to associate consent with a specific version. It does not establish how frequently estimates change.
• ·E2, sample job card with an additional fault: illustrates a point where work needs a decision. Whether the existing job system can hold a revised estimate is untested.
• ·A1, assumption: customers will approve revisions through a link. Check this with likely users, including people who need assistance, before choosing that interaction.
• ·R1, proposed business requirement: the coordinator can identify the approved estimate version before releasing additional work. The business must confirm this rule and who can authorise an exception.

3. A recommendation with reasons you can challenge

The options document should explain how each plausible route handles the problem. It should identify why the recommendation fits and what could overturn it. Include a process change when that could solve the difficulty. The build, buy or connect comparison covers those routes in more detail.

For the repair service, a sensible provisional recommendation might be to test revised estimates in the existing job system. That recommendation remains conditional until the system is demonstrated with the changed-estimate example. “The supplier says it supports approvals” is insufficient evidence of version handling.

If a critical uncertainty needs a prototype, state the question it will answer. GOV.UK alpha guidance focuses prototypes on risky assumptions and distinguishes that work from production-quality software. A private business can commission a similarly focused test without adopting the whole government delivery model.

4. A first-stage boundary and observable acceptance criteria

The proposed delivery stage should describe the behaviour included and the work left outside it. List dependencies, especially access to existing systems or a business decision about approval rules. Put unresolved questions beside the affected part of the scope so they survive the handover.

For this example, an initial test could cover revised estimates and customer approval, leaving payment collection outside scope. Its acceptance check: after an estimate changes, the coordinator can distinguish the superseded approval from consent to the revision; the customer can see what changed before responding.

Accepting the discovery report and accepting future software are separate decisions. Review the report by walking through the recommendation and tracing its important requirements to evidence. The proposed software acceptance checks describe what a later delivery would have to demonstrate. They do not establish that it already works.

5. An operating owner and a route for unresolved work

Name the person responsible for the workflow after launch. Record who answers staff questions, who changes the approval rules and who investigates a failure. If a supplier will provide technical support, describe the arrangement to agree before delivery.

For the repair example, the coordinator needs a way to handle a customer who cannot use the approval link. That fallback belongs in the plan, with an owner. The handover and support outline covers the operating questions that should accompany a delivery decision.

Copy this decision record into the findings

A useful final page records the choice and the condition for reconsidering it. Here is a completed example for the hypothetical repair service. Its decision is illustrative; no product capability has been verified.

• ·Decision sought: whether to commission a new repair-approval tool.
• ·Current decision: defer a build. Authorise a scoped test of revised estimates in the existing job system, subject to a separate agreement.
• ·Basis: E1 and E2 illustrate why approval needs to refer to an estimate version. A1 remains untested; R1 needs the business owner’s confirmation.
• ·Test before reconsidering: demonstrate a changed estimate, a customer response and the coordinator’s view using sample records and ordinary role access. Record what succeeds and what needs a workaround.
• ·Decision owner: the business owner approves the next commitment; the coordinator reviews whether the process is workable.
• ·Reopen the choice when: the test establishes the existing system’s fit, or exposes a gap that justifies investigating another approach.
• ·Handover: retain the map, evidence references and test result together. Any delivery proposal must state which unresolved questions it includes.

Sources and editorial note

Sources checked on 14 October 2026: the linked GOV.UK discovery, user-research and alpha guides. They concern government services. The deliverables review and decision record are editorial advice for business buyers. The repair service, sample artefacts and proposed findings are hypothetical; they report no client results.