The failure mode nobody plans for
Projects rarely fail because the code was bad. They fail because the team built precisely what was asked for, and what was asked for did not match how the business actually operates.
By the time that becomes obvious, the budget is spent and the rework is structural.
What discovery actually involves
Two weeks, a small team, and a deliberate effort to see the real process rather than the documented one.
- Sitting with the people who will use the system, watching them work
- Finding the spreadsheets and side-channels that exist because the official process does not fit
- Mapping data as it really flows, including the manual re-keying steps
- Identifying the two or three decisions that carry the most risk if we get them wrong
- Producing a scoped, estimated plan with those risks named explicitly
The output is a decision, not a document
Good discovery sometimes concludes that the project should not proceed as imagined - that a configuration change to an existing system solves 80% of the problem for 5% of the cost. That outcome is a success. Two weeks spent avoiding a six-month build is the highest return available on the engagement.
The uncomfortable part
Discovery surfaces disagreement. Two departments describe the same process differently; nobody can say who owns a decision point. Teams sometimes read this as the discovery going badly.
It is the opposite. Those disagreements exist whether or not anyone writes them down. Finding them in week two is cheap. Finding them in month five, encoded in software, is not.