Post-mortems love to blame technology. Rewind any failed platform project, though, and the fatal decisions cluster in the same fortnight — the one where everyone was eager to get started and nobody wanted to slow down for questions.
Across more than a hundred deliveries, the pattern has not varied: the outcome is largely decided before the first line of code. Industry surveys of ERP and platform failures point the same direction, and they consistently rank unclear requirements, unexamined assumptions and skipped discovery above anything that happens in engineering.
The questions that do not get asked
These are the four that change project outcomes, and the reason they get skipped is that all four make the timeline look worse before they make it better.
Who actually performs this process, and what do they do when the rules do not fit?
The person who described the process in the kickoff is usually not the person who performs it. The gap between those two accounts is where the requirements are. Someone from the delivery side has to watch the work happen — not interview about it — because the workarounds are invisible to the people who have normalised them.
Which of these requirements is a legal constraint, and which is a habit?
Organisations routinely present both in the same voice. A surprising share of the things a system supposedly cannot do turn out to be conventions nobody has revisited since a rule changed. Separating the two shrinks scope more reliably than any prioritisation workshop, because it removes work rather than deferring it.
What happens in March, at year-end, during the audit?
Systems are specified against the ordinary month and then fail in the exceptional one. Financial year-end, statutory audit, the annual price revision, the seasonal peak — these are not edge cases. They are the events that decide whether the platform is trusted.
What does the exception path look like?
The exceptions are the specification; the happy path is its cover page. Any process that runs at volume has an exception rate, and the handling of that exception is usually where the institutional knowledge lives.
Requirements as testable statements
The system should handle returns efficiently is a wish. A return against a partially-paid invoice creates a credit note and adjusts the ledger within the same day's books is a requirement — you can build to it, test against it, and argue about it before it costs anything.
The test for whether a requirement is written well is not length or formality. It is whether two competent engineers, reading it independently, would build the same thing, and whether a third could tell from the running system that it was satisfied.
| Wish | Requirement |
|---|---|
| Approvals should be fast | A purchase requisition under the department's delegated limit routes to a single approver and expires to the next level after 48 hours |
| The system should be secure | Retrieval and reporting enforce the same access rules as the source system, evaluated at query time against the requesting user |
| Reports should be accurate | Stock on hand reconciles to the ledger daily, and any discrepancy over a defined threshold raises an exception before the close |
Spike the risky assumptions
Every blueprint has two or three assumptions carrying disproportionate risk. They are almost always the same three:
- The legacy integration. The interface exists in the brochure. Whether it exposes the field you need, at the volume you need, without a nightly window, is a different question — and it is answerable in a week.
- The condition of the data. Migration effort tracks data quality, not record count. Pull a real extract early and count the duplicates, the inconsistent units and the missing history.
- The accuracy the AI or automation actually reaches on your documents rather than on a benchmark.
Prototype exactly those in week two, not month eight. A small spike that kills a large mistake is the best trade available in software, and the ratio is rarely close.
What discovery should produce
Discovery that ends in a slide deck has not ended. The artefacts that make the next phase de-riskable are concrete:
- Process maps of the work as performed, including the exception paths and the spreadsheets.
- A written problem definition that names what changes if this succeeds, in terms someone outside IT can verify.
- Testable requirements, separated into legal constraints and business preferences.
- Spike results for the two or three riskiest assumptions, with evidence rather than opinion.
- A target architecture and a phased plan, costed, and written to be buildable by any competent firm.
That last clause is the test of whether the document is real. A blueprint that only its author can build is a sales artefact.
The objection, answered
The standard objection is that this delays the start. It does — by a few weeks that are visible, in exchange for the months that are not. The months are the ones spent rebuilding a module against a requirement that was misunderstood, or discovering in user acceptance testing that the exception path was never designed.
Discovery is not a delay before the real work. It is the real work, done while changing course still costs a meeting.