What a Software Discovery Phase Should Prove Before Development Starts

A software project can appear ready to build long before it is ready to make dependable decisions. The organisation has a problem, a budget range and a list of requested features. Screens may already have been sketched, suppliers may have estimated the work, and stakeholders may be expecting development to begin.

That momentum is useful, but it can also hide uncertainty. Different teams may understand the problem differently. The proposed system may depend on data that is incomplete, an integration that cannot support the required transaction, or a process whose exceptions have never been written down. If those facts emerge during development, the project pays for them through rework, delays and difficult scope conversations.

A discovery phase should reduce that uncertainty before the organisation commits to the most expensive part of delivery. It is not a series of workshops that ends with a longer wish list. It should produce evidence about the users, service, technology, data, risks and delivery options, then turn that evidence into decisions.

The aim is not to know everything in advance. Software delivery will always involve learning. A useful discovery identifies what must be true for the project to succeed, tests the riskiest assumptions and leaves the team with a credible next step.

Start with the outcome, not the proposed product

Organisations often enter discovery with a solution already named: a portal, an app, a dashboard, a replacement CRM or an AI assistant. That description can help people discuss the idea, but it should not become an unquestioned requirement.

Define the operational outcome first. The real goal might be to reduce the time taken to assess an application, let customers complete a task without calling support, remove duplicate data entry, improve the accuracy of a statutory return or give field staff reliable access to current records.

Record the current measure and the intended change. If an approval takes twelve working days, what part of that time is waiting, checking, correcting or making the decision? If staff rekey information, how often does it happen and what errors follow? This baseline helps the team judge options and later prove whether the delivered service made a difference.

A discovery should also state what is outside the outcome. A new case-management interface may improve allocation and visibility without changing the policy used to decide eligibility. Separating those responsibilities prevents the software project from quietly inheriting every unresolved organisational problem.

Observe the real process, including its exceptions

A documented process usually shows the intended route. Real work includes incomplete submissions, urgent cases, delegated authority, duplicate records, unavailable approvers, manual checks and information arriving through the wrong channel. Those exceptions are often where the greatest effort and risk sit.

Discovery should follow representative work from beginning to end. Speak to the people who receive, process, approve, support and report on it, not only the people commissioning the system. Review actual forms, spreadsheets, emails, queues and reports where access and privacy rules allow.

For each step, record who acts, what information they need, which rule they apply, how long the work waits, what system holds the result and what happens when the normal route cannot continue. Look for unofficial tools and workarounds. A private spreadsheet or shared mailbox may be compensating for a gap that the new system must address.

The result should be a service view rather than a polished flowchart that hides complexity. It needs to show handovers, decision points, failure routes and ownership. That evidence lets the team decide which parts should be simplified, automated, integrated or left as a human judgement.

Identify users by their responsibilities and context

Broad labels such as administrator, manager and customer are rarely enough to design useful software. Two people with the same job title may need different access because they work for different regions, organisations or service areas. A customer may also be an authorised representative for somebody else. A member of staff may need temporary cover permissions without receiving permanent access.

Describe users in terms of the tasks they complete, the decisions they can make, the information they are allowed to see and the conditions in which they work. Include frequency, device, connectivity, accessibility needs and confidence with the process.

Recruit representative users into discovery and test assumptions with them. Senior stakeholders can explain policy and priorities, but they may not know how often an address is missing, why a case returns to a queue or what happens when a device loses its connection halfway through a visit.

Keep the research proportionate. The purpose is to find patterns and risks that affect the service, not to produce elaborate personas with no influence on scope. Every research finding should connect to a decision, requirement, prototype or question that still needs answering.

Define the data and integration reality

Many proposed features depend on information held elsewhere. Discovery must establish where that information originates, who owns it, how reliable it is and whether it can be used in the way the new service expects.

Create a data map covering the important records, identifiers, owners, retention rules and flows between systems. Sample the source data rather than relying only on a field list. A mandatory customer number may be missing in older records. Status values may have changed meaning over time. Two systems may refer to the same organisation using different identifiers.

For integrations, confirm the available interface and its operational limits. An API existing does not prove that it exposes the required records, supports updates, returns changes quickly enough or permits the anticipated volume. Check authentication, rate limits, test environments, error handling, supplier responsibilities and commercial constraints.

Where an integration is central to the case for change, use a short technical investigation to prove the difficult path. A small read-and-write test against a non-production service is more valuable than an architecture diagram based on assumptions. Record what was proved, what remains uncertain and what fallback is available.

Turn the scope into testable service capabilities

A feature list describes what stakeholders would like to see. It does not necessarily show which capabilities are needed to achieve the outcome or how the team will know they work.

Group the scope around end-to-end tasks. Instead of separate requirements for a form, document upload, notification and dashboard, describe the capability to submit a complete request, route it to the correct owner, assess it, ask for missing information and communicate the decision.

Give each capability acceptance evidence. That might include the users who can complete it, the business rules applied, the data created, the response required from another system and the result visible to support staff. Include unsuccessful paths as well as the ideal journey.

Prioritisation should expose trade-offs. Mark which capabilities are essential for a usable first release, which can follow after real use, and which are currently ideas rather than commitments. A first release should complete a valuable piece of work safely; it should not be a collection of disconnected screens chosen because they are easy to demonstrate.

Test the assumptions that could change the plan

Discovery should spend most effort on uncertainty with material consequences. A minor layout preference can be resolved during delivery. Uncertainty about identity, data quality, transaction volume, accessibility, supplier APIs or a complex business rule can change the architecture, cost and viability of the project.

Use the cheapest appropriate method to test each assumption:

• Process walkthroughs can reveal missing decisions and handovers.
• Clickable prototypes can test language, navigation and task sequence without building production code.
• Data profiling can show whether records are complete and consistent enough for migration or automation.
• Technical spikes can prove integration, performance or security constraints.
• Service rehearsals can test what staff will do before and after the digital transaction.

State the question before running the test and record the decision afterwards. Prototypes and experiments are not progress by themselves. Their value is the evidence they provide and the work they prevent the project from doing on a false assumption.

Include security, accessibility and operations from the start

Non-functional requirements are often collected as generic statements near the end of discovery: the system must be secure, accessible, scalable and reliable. Those words are too broad to guide design or estimation.

Define the relevant risks and operating conditions. Identify the data classifications involved, roles and permissions, authentication needs, audit events, retention periods and recovery expectations. Record the expected transaction volume, response times and periods of peak demand. Confirm whether the service must work with poor connectivity or older devices.

Accessibility needs to be connected to real tasks, content and components. Include disabled users in research, test representative journeys with keyboards and assistive technologies, and identify any documents or third-party services that could become barriers.

Consider the live service as well as the build. Decide who will monitor it, respond to incidents, manage users, approve content or configuration changes, support integrations and communicate planned maintenance. If the operating model is unaffordable or unclear, that is a discovery finding rather than a problem to hand to support after launch.

Produce an architecture proportionate to the evidence

Discovery should create enough technical design to expose major decisions and support an estimate. It should not attempt to specify every class, database table and cloud resource before the team has learned from delivery.

The architecture should show system boundaries, data flows, trust boundaries, important integrations, deployment environments and the services that need to be operated. Record why major choices were made and which alternatives were rejected.

Prefer a simple approach that meets the known constraints. A new platform may not need microservices, a mobile app or real-time synchronisation simply because those options are available. Additional moving parts should earn their place by solving an evidenced problem.

Where the existing estate is involved, identify what can be reused, wrapped, improved or retired. Replacing everything at once may increase risk without improving the first user outcome. Discovery should make the transition path visible, including coexistence, data migration, cutover and rollback.

Give the estimate an explicit basis

A single fixed number can look reassuring while concealing large assumptions. A stronger discovery explains the scope, team, dependencies, risks and level of confidence behind the estimate.

Break delivery into meaningful increments and identify external work that the estimate depends on. Examples include access to supplier test systems, availability of subject-matter experts, content preparation, procurement approvals, data cleansing and decisions from an information-governance team.

Separate known delivery work from contingency for identified risks. Document exclusions and the circumstances that would trigger a change. Where uncertainty remains high, estimate a bounded next phase that resolves it instead of pretending the whole programme is equally predictable.

Include ongoing cost. Hosting, licences, monitoring, support, security updates, app-store accounts, third-party transactions and future content or data work can materially affect the option an organisation should choose.

End with decisions, evidence and a clear recommendation

A useful discovery output should let a decision-maker understand what problem is being solved, what was learned, what remains uncertain and what should happen next. It should be usable by the delivery team rather than existing only as a presentation.

The final set of outputs will vary, but it will usually include:

• the outcome, baseline measures and success criteria;
• a map of the current and proposed service, including exceptions;
• user needs, access responsibilities and research evidence;
• prioritised, testable service capabilities;
• data, integration, security, accessibility and operational findings;
• prototype and technical-investigation results;
• the recommended architecture and transition approach;
• a delivery plan, estimate, dependencies and risk register; and
• a decision log covering the choices already made.

The recommendation may be to proceed, run a narrower test, change the proposed solution or stop. Stopping can be a successful discovery outcome when the evidence shows that the cost, dependency or service model does not support the original idea. It is cheaper to reach that conclusion before a large build.

Discovery earns its place when it changes the quality of the commitment. It replaces confident guesses with tested assumptions, connects features to operational outcomes and makes risk visible while the organisation still has options. Development can then begin with a shared understanding of what is being built, why it matters and what evidence will show that it works.