Software Delivery
What Good Software Discovery Looks Like Before Development Starts
Good discovery does not attempt to specify an entire system before learning begins. It makes the outcome, workflow and costly uncertainties visible, then produces enough evidence to choose a sensible first investment.
Discovery is a decision process, not a requirements phase
Traditional requirements exercises aim to capture everything users say they need. Good discovery asks which problem is worth solving, how the work happens today, what must be true for an option to succeed and which evidence is missing.
Its output may recommend building, buying, integrating, simplifying a process or doing nothing yet. If the engagement is contractually expected to justify a predetermined solution, it is mobilisation disguised as discovery.
Discovery reduces uncertainty; it cannot eliminate it. Detailed specifications created too early often replace visible uncertainty with undocumented assumptions.
Begin with the outcome and the cost of the current situation
State who experiences the problem, what happens, how often and with what consequence. “Replace the CRM” is a proposed intervention. “Sales cannot produce a reliable renewal forecast without three days of reconciliation” is an investigable problem.
Establish baseline measures where possible: handling time, queue age, error correction, completion, incidents or delayed change. Avoid optimistic percentages with no source.
Name the decision discovery must support and the person accountable for it. Without a decision, research expands indefinitely.
Include the people who do, govern and support the work
Senior stakeholders know goals and constraints; operational users know exceptions; support teams know how the system fails; security and data owners know obligations. Discovery needs these perspectives without turning every workshop into a large committee.
Interview and observe representative users. People omit habitual steps when asked to describe a process. Watching a real case reveals spreadsheets, copying, judgement and workaround queues.
Protect time for decisions. Delayed access to subject-matter experts is not a delivery inconvenience; it is an estimate and correctness risk.
Map real journeys, including failure and correction
Trace a case from trigger to business outcome. Record actors, data, decisions, hand-offs, systems, waiting, controls and exceptions. Include month-end, retrospective correction and dependency failure.
Do not confuse the current screen sequence with the required workflow. A step may exist only because two systems cannot communicate. Preserve business purpose and necessary control, not every historical click.
Quantify variants. The rare exception may dominate support cost or carry the greatest consequence.
Make business rules concrete with examples
Statements such as “managers can approve large orders” hide thresholds, delegation, currency, absence, conflicts and effective dates. Use example mapping or decision tables to expose the rule.
Distinguish policy from implementation. A spreadsheet formula, stored procedure or manual check may implement a rule without being the desired future design.
Record disputed terminology. If finance and operations mean different things by “completed”, an elegant data model will not resolve the business disagreement.
Understand data before designing screens
Identify authoritative entities, identifiers, owners, sensitivity, retention and downstream consumers. Profile real source data where permitted: volume, duplicates, missing values and inconsistent categories.
Migration scope should distinguish active records, valuable history, read-only archive and data that can be deleted under policy. Row count says little about semantic cleanup.
Document where data is copied into exports, logs and departmental files. Privacy and migration boundaries extend beyond the primary database.
Treat integrations as operating relationships
For every external system identify owner, contract, authentication, limits, sandbox, data semantics, latency, failure handling and support route. “Has an API” is not enough.
Obtain sample payloads and access early. A technical spike is appropriate where a legacy protocol, vendor product or identity flow creates material uncertainty.
Define authoritative ownership and reconciliation when operations span systems. The happy-path sequence diagram is incomplete without partial failure.
Bring security and operations into discovery
Classify data and map identities, tenant boundaries, privileged actions, trust boundaries and audit needs. Security decisions shape architecture and cost; a penetration test is later evidence, not a substitute.
Define expected availability, recovery, support hours, deployment constraints, volumes and peak events. Ask how operators will know a business journey failed and whether replay is safe.
A non-functional checklist is too abstract. Tie qualities to journeys: how long may a payment status remain uncertain, or how much accepted work may be lost?
Use prototypes for questions, not approval theatre
A prototype should test a named uncertainty: can occasional users understand the workflow, can complex evidence fit on one review screen, or can an integration support the required interaction?
State its fidelity and what it does not prove. A clickable interface proves neither production feasibility nor completed scope. Stakeholders easily mistake polished screens for near-finished software.
Test with representative users and tasks. Record observations and decisions, not only preference ratings.
Use technical spikes where evidence can change the plan
A spike is a bounded experiment around a costly assumption: migration throughput, document extraction quality, authentication coexistence or third-party API behaviour.
Define the question, timebox, production-like inputs and success criteria first. Throwaway code may be the right output; promoting an experiment into production creates hidden debt.
Publish what was learned, including limitations. A successful call from a laptop does not prove resilience, security or operating cost.
Compare options before committing to architecture
| Option | Discovery question | Typical evidence |
|---|---|---|
| Improve the process | Is software the primary constraint? | Workflow observation and policy decisions |
| Buy a product | Can important journeys fit without harmful customisation? | Configured scenario demonstrations and exit review |
| Integrate existing systems | Can ownership and failure be made reliable? | API spike, data contracts and reconciliation design |
| Build bespoke | Does control over this capability justify ownership? | Differentiation, workflow and lifecycle model |
| Incrementally modernise | Can valuable capabilities move behind safe seams? | Dependency map, routing and data ownership |
A good discovery produces usable artefacts
- A concise problem, outcome, baseline and decision statement.
- Journey maps showing normal, exception and recovery paths.
- Business rules, glossary and unresolved policy decisions.
- Data ownership, migration profile and retention boundaries.
- Integration and trust-boundary maps.
- An assumptions and risks register with evidence and owners.
- Prototype or spike findings tied to explicit questions.
- Compared options and an architecture direction with consequences.
- A bounded first release, delivery range and roadmap hypotheses.
- Measures that will show whether the investment works.
Artefacts should be proportionate and maintainable. A hundred-page document nobody uses is not more rigorous than a concise decision record backed by evidence.
What discovery should not promise
It should not pretend every future requirement is known, guarantee a final fixed price for unresolved work or design every class and table. Nor should it produce an unprioritised backlog presented as commitment.
It should show ranges, assumptions, dependencies and confidence. Later estimates should narrow as working software and data migration provide evidence.
Warning signs of discovery theatre
- The solution and technology were chosen before investigation.
- Only managers attend; operational users and support are absent.
- Workshops discuss desired screens but not current evidence or exceptions.
- Integrations are boxes with no access, contracts or failure behaviour.
- A polished prototype is counted as delivery progress.
- Risks are listed without experiments, owners or decisions.
- The supplier retains the useful outputs or makes them unintelligible elsewhere.
Know when discovery is sufficient
Discovery is sufficient when decision-makers understand the outcome, options, largest risks, first production boundary and investment range well enough to choose the next step. It need not eliminate ordinary implementation detail.
Stop or extend deliberately. If a critical data source remains inaccessible or product fit cannot be tested, say how that uncertainty affects commitment rather than burying it in contingency.
Keep an evidence ledger, not only a risk register
Risk registers often become static lists of concerns. An evidence ledger connects each important assumption to its current support, confidence, owner and next test. It records when a prototype, data sample, user observation or vendor response changes the decision.
This stops confident workshop statements acquiring the status of fact. It also makes discovery transferable: a later team can understand why a boundary was chosen and which claims still require production evidence. Unanswered assumptions should appear in scope, contingency or a decision gate rather than disappear from the final presentation.
Related C3 Software guides
Frequently asked questions
How long should software discovery take?
Long enough to resolve or expose the decision's costly uncertainties. Scope it by questions and risk rather than applying one duration to every project.
Does discovery produce a fixed quote?
It should improve the range and confidence. A fixed price is appropriate only where the resulting scope and dependencies are sufficiently understood.
Is discovery still needed when buying software?
Yes. It tests process fit, data migration, integration, security, operating change and exit rather than assuming product features equal outcomes.
Who owns discovery outputs?
The client should receive usable artefacts and decisions under clear contractual terms, enabling it to proceed, pause or work with another competent supplier.
Turn uncertainty into a better first decision
C3 Software Limited has built and supported UK business software since 2001. If you need evidence before committing to a product or development programme, talk to C3 Software about a focused discovery.