There is a familiar sequence in failed transformation programmes. A platform is selected. An implementation partner is appointed. A timeline is agreed. And then, somewhere around the third month, a series of uncomfortable discoveries begins: the process the system expects is not the process the business runs.
What follows is usually one of two things. Either the business bends itself to the software, absorbing a hundred small degradations in how work gets done. Or the software bends to the business, through customisations that solve today's mismatch and quietly make every future upgrade harder. Both outcomes are expensive. Both were avoidable.
The document is not the process
Most organisations have a process document. Very few organisations run the process in that document. The gap between the two is not negligence — it is accumulated adaptation. Someone hit an edge case the procedure did not cover, invented a workaround, and the workaround became the norm. Repeat this over a few years and the official process describes an organisation that no longer exists.
This matters because requirements are usually gathered from the document, or from managers describing the document from memory. The people who know the real process are the people executing it, and they are rarely in the requirements workshop.
The workarounds are not the mess to be cleaned up. They are the most accurate documentation you have.
What discovery should actually produce
A discovery phase that produces only a diagram has not earned its cost. It should produce decisions — specifically, decisions about which parts of how you work today are genuine competitive differentiators worth preserving, and which are simply accidents of what your old tools allowed.
A useful discovery produces four things:
- A map of how work actually moves, including the exceptions and the workarounds
- An honest ranking of where the cost sits — measured in time, rework and delay
- A clear statement of which current practices are deliberate and which are inherited
- A sequence: what has to change first, and what depends on it
This is not an argument for slower projects
Discovery does not have to be long. It has to be real. A focused few weeks spent with the people doing the work will tell you more than a quarter of workshops with people describing it. And the time is not additive — it is borrowed from the change requests, rework and scope arguments that would otherwise arrive later, when they cost considerably more.
The platform decision is easier and better once the process is understood. Sometimes it turns out the platform you already own was adequate all along, and the real problem was a configuration nobody had revisited in six years.