The seven-item checklist
- Business problem: write one sentence describing what is slow, risky, expensive, or hard to manage.
- Current workflow: map the trigger, steps, handoffs, decisions, and exceptions as they work today.
- Users and owners: name who performs the work, who approves it, and who owns the outcome.
- Systems and data: list the CRM, accounting, payment, scheduling, files, and data sources the solution must work with.
- Constraints and risks: identify permissions, security, contracts, compliance, legacy technology, and operational limits early.
- First release: choose one end-to-end path that creates value without rebuilding the entire operation.
- Success measure: record the current cycle time, manual touches, errors, open exceptions, or another measurable result.
This follows a basic discovery principle: understand the problem, users, context, and constraints before committing to a solution. The GOV.UK Service Manual also recommends deciding how success will be measured and being willing to stop when discovery shows that building is not worthwhile.
Put it on one page
| Field | Write down |
|---|---|
| Problem | What is failing and who feels it? |
| Outcome | What should become faster, safer, or easier to manage? |
| Workflow | Trigger, steps, owners, decisions, and exceptions. |
| Systems | What stays, what connects, and which system owns each record? |
| First release | The smallest end-to-end path worth using. |
| Measure | One baseline and one target outcome. |
Three warning signs
- The project is described as a list of screens instead of a business workflow.
- The estimate assumes integrations, data quality, permissions, and exceptions will be solved later.
- The first release tries to serve every department and replace every tool.
Security belongs in the brief
Security should not appear for the first time before launch. Record access rules, sensitive data, audit needs, and likely risks before architecture decisions are made. NIST’s Secure Software Development Framework recommends tracking security requirements, risks, and design decisions as part of the development process.
The decision at the end
A useful discovery does not always end with “build.” It may show that the business should buy an existing product, connect current tools, simplify the process first, build one narrow workflow, or stop. That is a good result because it prevents a larger commitment built on weak assumptions.
A simple rule
Do not start with features. Start with one workflow, one owner, one costly problem, and one measurable outcome. Then decide the smallest solution that can improve it.