Technical Discovery: Why It Matters Before Starting a Software Project

Two teams can agree to build a customer portal and still be imagining different projects. One expects a simple view of existing records. The other expects self-service changes, approval workflows, payment handling and a replacement for several spreadsheets. The disagreement often stays hidden until an estimate, prototype or missed deadline forces it into view.

Technical discovery brings those assumptions into the open while changing direction is still relatively inexpensive. It investigates whether the proposed solution can work with the organisation's people, data, systems and constraints. Its output should help someone make a decision about investment and scope.

Discovery does not need to become a long programme for every project. A small enhancement with familiar dependencies may need a focused review. A new service built around an uncertain supplier integration needs deeper investigation. The amount of work should follow the consequences of being wrong.

Establish the decision discovery must support

Start by stating what the organisation needs to decide. It may be whether to build or buy, whether an existing platform can support a new service, or which first release can fit an available budget. A discovery effort without a decision can accumulate information indefinitely.

Write the decision in plain language and identify its owner. For a portal, the question might be whether customers can reliably manage one type of service request using the current back-office system. That is more useful than an open-ended instruction to explore digital transformation.

Agree what evidence would support each outcome. A viable integration, understandable user journey and workable operating model might justify implementation. Missing access to essential records might require a different approach. The option to stop should remain real if the investigation exposes a fundamental mismatch.

The GOV.UK Service Manual's discovery guidance emphasises understanding the problem before building and recognises that stopping can be an appropriate outcome. For a commercial project, use that principle to protect investment decisions rather than treating discovery as a guaranteed route to development.

Describe the current service as people experience it

Follow a real task from its trigger to its conclusion. Observe the people who receive information, make decisions, correct mistakes and answer questions. The official process diagram may omit the informal work that keeps the service functioning.

Ask for representative examples with appropriate handling of personal or sensitive information. A redacted request, a sample approval and an anonymised exception can reveal more than a general discussion about requirements. Avoid copying production data into ungoverned discovery tools merely for convenience.

Record where people wait and why. A delay may come from missing information, unclear authority or a supplier response rather than the absence of software. The proposed application should address the actual obstacle instead of giving an unresolved process a new interface.

Include the people who experience the exceptions. A manager may understand the normal route, while a coordinator knows what happens when a customer changes an address halfway through a request. These details often determine the difficult parts of the eventual implementation.

Separate assumptions from established facts

Create an assumption log with a statement, its evidence, the consequence if it is wrong and the person responsible for investigating it. “The accounting platform supports invoice creation” is not established merely because a vendor page mentions an API.

Classify uncertainty by its effect on the decision. Some assumptions affect a minor interface choice. Others can change the architecture, cost or viability of the whole service. Investigate the latter first, even when they are less enjoyable than sketching screens.

Use precise language for the result. “Integration tested” is too broad. “A test account can retrieve the required order fields, but historical records lack a stable customer reference” tells the planning team what it can rely on and what remains unresolved.

Keep assumptions visible in estimates and proposals. They should not disappear when a discovery document becomes a commercial offer. If a supplier's promised capability has not been demonstrated, the implementation plan still needs a condition or contingency for it.

Inspect integrations through a narrow working example

Choose an operation that tests the difficult part of a dependency. For the portal, this might mean retrieving an account's requests using the actual access model, or submitting a change that must pass back-office validation. A generic connectivity check is rarely enough.

Confirm access to the relevant documentation, environment and support channel. Discover whether the available test environment behaves differently from production in ways that affect the project. Note any operations that require a separate commercial agreement or supplier enablement.

Examine failure behaviour. What happens when a record is missing, permission is denied or the service times out? Can the application determine whether a submitted change took effect? Recovery requirements can be more consequential than the happy-path field mapping.

Keep the experiment bounded and disposable unless deliberately engineered otherwise. A discovery script may prove a capability without being suitable for production. Label it clearly and capture the finding so nobody mistakes an unreviewed prototype for a finished integration.

Investigate data before promising migration

Ask where the essential records live and who owns their meaning. Different departments may use the same word for different concepts, or different identifiers for the same customer. A shared label does not establish a reliable mapping.

Inspect a representative sample for completeness, duplication and inconsistent formats. Include older records and exceptional cases, not only the clean examples selected for a demonstration. Record the limitations of the sample so findings are not mistaken for a full audit.

Decide how questionable data will be handled. Some records may need correction, some can remain in an archive and some require a business decision before migration. Assign ownership for that work. Developers can transform data according to rules, but they cannot safely invent those rules.

Estimate the human effort as well as the technical transfer. Content review, customer matching and reconciliation can take substantial organisational time. If these tasks depend on busy operational staff, their availability belongs in the delivery plan.

Use prototypes to answer a specific question

A prototype is useful when it tests an uncertainty about understanding or behaviour. For example, can a customer distinguish a submitted request from an accepted booking? Can a coordinator identify the next action without opening several records?

Choose the simplest fidelity that supports the question. Paper sketches may be enough to discuss a sequence. A clickable prototype can test navigation. A technical proof may be necessary to examine performance or integration. More polished visuals do not automatically produce better evidence.

Observe participants attempting a task rather than asking whether they like the design. Record where they hesitate, misinterpret a label or expect something the proposed service does not support. Explain the limitations of a small research sample and use findings to guide the next investigation.

Keep visual approval separate from technical feasibility. A convincing screen can show information the existing system cannot supply. Connect each important interface promise to its underlying data and operation before including it in the initial release.

Examine the operating model alongside architecture

Ask who will run the service after launch. Someone needs to handle access requests, investigate failures, correct records and answer customer questions. A solution that assumes an unavailable support team is incomplete even if its architecture is sound.

Define service expectations in terms the business understands. How long can a request remain unprocessed? What happens outside office hours? Which failures need immediate attention? These choices influence monitoring, recovery and staffing as well as infrastructure.

Review the trust boundaries and sensitive operations early. Identify which users may see which records and which actions need stronger control. Discovery should expose the relevant security questions without pretending that a short workshop replaces detailed implementation review.

Consider ownership of accounts, code, configuration and supplier relationships. The organisation should understand how it could maintain or transfer the service if a key person or delivery partner becomes unavailable. These practical dependencies belong in the feasibility discussion.

Compare realistic options

Frame a small set of viable approaches, including improving the existing process where appropriate. A packaged platform, a custom application and a narrower integration can have different trade-offs in fit, delivery effort and long-term ownership.

Evaluate them against the same business needs. One option may look cheaper because its proposal excludes migration, support or a difficult workflow. Make the comparison explicit so the sponsor sees the cost of achieving the intended outcome rather than a collection of incomparable feature lists.

Identify the conditions under which each option becomes preferable. A custom approach may be justified by a distinctive approval process; an existing product may be sufficient if the organisation can adopt its workflow. These are decisions about the business as well as technology.

Avoid false precision in a scoring matrix. Scores can organise discussion, but a single unresolved dependency may outweigh several minor advantages. Explain the decisive trade-offs in words and retain the evidence that supports them.

Turn findings into a coherent first release

Choose a release that completes a useful task from beginning to end. A portal that accepts a request but gives staff no way to resolve an error may be visually complete and operationally unfinished. Include the administration needed to support the chosen journey.

Define exclusions with their temporary arrangements. If customers cannot amend a submitted request initially, specify how they request a correction and who performs it. A deliberate manual route can be acceptable when its volume and consequences are understood.

Write acceptance examples around behaviour. “A customer sees only their own requests” and “an interrupted submission does not create duplicate work” are clearer than broad feature names. They connect the discovered risk to something the implementation team can demonstrate.

Preserve unresolved questions as owned work with decision dates. Discovery reduces uncertainty; it does not eliminate it. The handover should make the remaining uncertainty manageable rather than hide it behind a polished scope document.

Timebox discovery without forcing a conclusion

Set a limit based on the questions and available evidence. A timebox helps the team prioritise the investigations with the greatest effect on the decision. It should include access arrangements and stakeholder availability, not assume every dependency is ready on the first day.

Review findings during the work, especially when an early result changes the likely direction. If the essential supplier interface is unavailable, there may be little value in continuing to refine screens that depend on it. Redirect the remaining effort toward alternative approaches.

At the end, distinguish demonstrated facts, reasonable recommendations and unresolved conditions. The sponsor should understand whether the next step is implementation, a smaller additional investigation, a process change or a decision to stop.

If more investigation is proposed, state exactly what it will resolve and why the current evidence is insufficient. An extension should have a decision value of its own, rather than simply continuing because the team has more interesting questions.

A bounded discovery example for a request portal

Suppose a service company wants customers to change booking details online. The central uncertainty is whether its existing scheduling system allows a change after allocation without creating conflicting work for dispatchers. Attractive portal screens will not resolve that question.

The discovery team can begin with a redacted sample booking and a conversation with the dispatcher who handles corrections today. It records the states in which a change is allowed, the information that must be rechecked and the messages staff currently send. This establishes the business rule the technical experiment needs to test.

Next, a narrow experiment uses an approved test account to attempt the relevant changes through the scheduling interface. The result should distinguish supported operations from manual-only steps. It should also test what happens when the booking changes between retrieval and submission.

A prototype can then show customers the behaviour the integration can actually support. Perhaps they can request a change, but staff must approve it before the booking is updated. Research should test whether that distinction is clear and whether customers understand the expected response.

The recommendation might be a smaller first release: submit a correction request, show its pending state and give dispatchers an owned review queue. That scope could provide useful service improvement without pretending that fully automatic rescheduling has been demonstrated.

The discovery handover should explain why this boundary was selected, what evidence supports it and what would need to change before automation expands. The organisation receives a concrete decision and a feasible next step, while the implementation estimate can focus on a known workflow rather than an ambiguous promise to let customers edit bookings.

Make the handover usable

A concise discovery package should describe the problem, users, important journeys, system dependencies, findings and recommended scope. Include the option comparison, assumption log and evidence from experiments. Link to detailed material where needed instead of burying the recommendation in a large document.

Walk through the package with the people who will implement and operate the service. Ask them to explain the intended first release and identify the unresolved risks. That conversation reveals gaps that a document approval alone may miss.

Use the findings to update the estimate, schedule and responsibilities. Discovery has limited value if the project continues with its original assumptions unchanged. The decision should visibly reflect what the organisation learned.

Before starting your next software project, write down the three assumptions that could most seriously change its scope or viability. Identify the smallest credible investigation for each. That creates a practical starting point for technical discovery and a clearer basis for deciding what deserves to be built.

---