Discovery is the easiest phase to cut. It produces no software, it is hard to demonstrate progress on, and every proposal that includes it looks more expensive than one that does not. So it gets compressed from six weeks to two, and everyone agrees to "work the details out during implementation".
The details are the project. Working them out during implementation means discovering, in month five, that the way the warehouse actually receives goods cannot be represented in the configuration everyone signed off in month two.
What goes wrong, specifically
The process nobody documented
Every organisation has procedures that exist only in the heads of two or three people. The credit approval that technically requires the finance director but in practice is done by phone. The supplier who invoices differently because of a fifteen-year-old agreement. These do not appear in an org chart or a policy document. They appear when someone tries to do their job in the new system and cannot.
Signing off a document nobody read properly
A functional specification written in consultant language, approved by a steering committee, none of whom will ever use the system. The people who will use it see it for the first time at user acceptance testing, which is far too late for their feedback to be affordable.
Configuring for the exception
The opposite failure. A workshop surfaces an edge case that happens twice a year, and the team builds elaborate configuration to handle it, adding permanent complexity for everyone. Some exceptions should stay manual. Deciding which is a judgement call that requires knowing the frequency, and frequency is something discovery measures.
Data nobody looked at until migration
Duplicate customers, products with three different unit-of-measure conventions, opening balances that do not reconcile. Migration is when this surfaces, and migration is at the end. Discovery is when it should surface, because cleansing takes months of somebody's part-time attention.
What a proper workshop phase looks like
Sit with the people who do the work
Not their managers, and not only in a meeting room. Watch a purchase order being raised. Watch a delivery being received. Watch a month-end close. You will see the spreadsheet that sits between two official systems, and that spreadsheet is a requirement whether or not anyone declares it.
Map current state before target state
It is tempting to skip straight to how things should work. Do not. You cannot judge which existing practices are deliberate and which are workarounds until you have documented what happens today, including the workarounds.
Quantify every exception
For each unusual case, ask how often. "Rarely" is not an answer. Twice a year means handle it manually and write it in the procedure. Twice a week means configure it. This single question resolves most arguments about scope.
Write the specification in the client's language
Screens, roles, fields, rules and the reports people will actually open on Monday morning. If a warehouse supervisor cannot read the document and tell you whether it describes their job, it is not a specification, it is a licence to argue later.
Profile the data early
Run duplicate detection, completeness and consistency checks on the legacy data in week two, not month five. Give the client a cleansing task list with owners and a deadline. Data cleansing is almost always the critical path, and it is almost always started too late.
Agree what will not be in phase one
Writing down what is out of scope is more valuable than writing down what is in. A short explicit exclusion list prevents most change-request disputes, because both sides agreed in advance where the line was.
The signal we watch for. If, three weeks into workshops, nobody has said "actually, that is not how we do it", the workshops are not working. Silence in discovery means the right people are not in the room, and it always becomes noise later.
How long it should take
| Scope | Discovery | Typical total |
|---|---|---|
| Single entity, finance and inventory | 2 to 3 weeks | 10 to 14 weeks |
| Multi-entity, adding procurement and HR | 4 to 6 weeks | 18 to 26 weeks |
| Manufacturing or multi-warehouse distribution | 6 to 8 weeks | 26 to 40 weeks |
Discovery is roughly twenty per cent of the timeline. When a proposal shows five per cent, that is not efficiency, it is a decision to discover the requirements later at implementation rates.
What it buys you
On the projects where we have held the discovery phase properly, change requests after sign-off have run at under ten per cent of contract value, and user adoption at go-live has been high enough that the old spreadsheets actually got retired. On the one project where we allowed discovery to be compressed because of a client deadline, we spent more than the saving on rework, and the finance team kept their parallel spreadsheet for another year.
That is the real measure. Not whether the system went live, but whether people stopped using what it replaced.