Key takeaways
- Discovery should produce decisions, not just documentation.
- Expect a process map, a scoped first release, an architecture outline and an estimate with assumptions.
- Involve the people who do the work, not only the people who manage it.
- A good discovery sometimes recommends building less — or not building at all.
Discovery is where a software project's cost and risk are mostly decided. A checklist of what a useful discovery phase produces, and the warning signs of one that won't help.
What discovery is for
Discovery exists to replace assumptions with decisions before they become expensive. It answers what the first release must do, for whom, with which integrations, under which constraints — and what it will reasonably cost.
What you should receive
A useful discovery ends with a small set of documents your team can read, challenge and approve.
- A process map of how work happens today and how it will happen in the new system.
- User roles and what each needs to see and do.
- A scoped first release, with what is deliberately left for later.
- Integration inventory: every system the new one must talk to, and how.
- Architecture outline: data model, components, hosting and security approach.
- Estimate and plan, with the assumptions behind them written down.
Who needs to be in the room
Managers describe how a process should work. The people doing the work describe how it actually works — including the workarounds that the new system must either support or remove. Both views are needed, and the second is usually where the important requirements hide.
Warning signs
Any of these suggests the difficult decisions have been postponed into development, where they cost more.
- A requirements document that lists screens but not workflows.
- No written assumptions behind the estimate.
- No discussion of data migration or integrations.
- Every requested feature included in the first release.
Sometimes the answer is to build less
An honest discovery will occasionally recommend a packaged product, a smaller first release, or a process change instead of software. That is a good outcome: the cheapest code is the code that never needs to be written.
Enjoyed this? Get the next one by email.