What to do when an implementation has stalled
Stalled projects rarely fail loudly. They go quiet, the meetings get shorter, and everyone waits for someone else to say it. Here is how to work out whether to finish it or stop.
Implementations do not usually fail. They go quiet. The status meeting gets moved, then shortened, then held every other week. Nobody says the project is in trouble because nobody wants to be the person who said it, and the sunk cost grows while everyone waits.
Three shapes, three different answers
Before deciding anything, work out which of these you have. They look identical from the outside and the correct response to each is different.
The scope one. Work is happening and the finish line keeps moving. Every fortnight a department adds a requirement that was always obviously necessary. This is recoverable and the fix is not technical: someone has to be given authority to say no, and that authority has to be visible.
The data one. Work is blocked on records nobody will take responsibility for. Recoverable, because the work is well-defined and can be parallelised. It is also the one most easily mistaken for a vendor problem. See data migration is the project.
The agreement one. The project is blocked because the business has not decided how the process should work, and configuring it requires that decision. This is the serious one. It does not get better with more engineering, more budget or a different vendor, and replacing the partner resets the clock without touching the cause.
Establish what is actually done
Stalled projects run on optimistic reporting, not because anyone is lying but because "nearly finished" is what people say about work they understand and have not yet completed.
Two questions cut through it:
- What is in production and being used by a real person for real work today? Not configured, not demonstrated, not signed off in a workshop. Used. The honest answer is frequently much smaller than the percentage on the status slide.
- What would we lose if we stopped this afternoon? Configuration and decisions frequently survive a change of direction. Only some of what was spent is genuinely sunk, so the cost of stopping is worth calculating rather than assuming.
Whether to continue
Continue when the remaining work is definable, the blocker is data or scope, and the people who have to agree can be got into a room. Those projects finish once someone stops managing the vendor and starts managing the decisions.
Stop, or restart with different scope, when the business has not agreed how the process should run and shows no sign of doing so, or when the system being built encodes a process the team has already abandoned. Continuing then just buys a more expensive version of the same disagreement.
Either way the first deliverable should be an honest assessment, produced by someone who is not paid more by the answer. That is difficult to get from the incumbent partner, not because they are dishonest but because the question is whether to keep paying them.
What to do this week
Ask for the list of what is live and used today, by name, per module. Ask it in writing and give it a deadline. The length of that list, compared to the percentage on the status report, tells you which of the three shapes you have and that is the whole decision.
Where this goes next
The workstreams a recovery has to re-scope are in what software implementation actually covers. If the blocker turns out to be records rather than configuration, start with data migration is the project. If the underlying problem is that the wrong system was chosen, that is a different conversation: how to buy enterprise software without regretting it.