Most ERP projects that go wrong do not go wrong loudly. There is no dramatic collapse — just a go-live that slips twice, a team quietly keeping the old spreadsheet open beside the new system, and a year later nobody can say what the investment actually bought.
We have been called in to rescue enough of these to see the pattern. The software is almost never the problem.
Nobody agreed what the process was
A system has to be configured around how work actually happens. If three departments describe the same process three different ways, you are not configuring an ERP — you are arbitrating a disagreement, mid-build, under deadline. That argument is far cheaper to have before the project starts.
The scope grew in the dark
Scope rarely explodes. It creeps — a report here, a small customisation there, each one reasonable on its own. Six weeks later the timeline is gone and nobody can point to the decision that cost it. Every change needs a name, a cost and someone who said yes.
It was treated as an IT project
ERP is not a systems installation. It changes how people book an order, close a month, receive stock. If the sponsor is the IT manager rather than the person who owns the operation, the decisions that matter most — the ones about process, not configuration — get made by people without the authority to make them stick.
Data was left to the end
Migration is the step everyone underestimates. Customer records with three spellings of the same company. Stock quantities nobody has trusted since 2019. An opening balance that does not tie out. Bad data does not just slow a go-live — it destroys confidence in the new system in week one, and confidence is very hard to win back.
Training happened once, before it mattered
A two-day session a month before go-live teaches people a system they have no reason to remember yet. Training has to land close to the moment of use, and someone has to be reachable in the first weeks, when the real questions start.
None of these are technical failures. They are decisions about ownership, sequencing, and honesty about the current state — which is why a project can fail on excellent software and succeed on ordinary software.
If you are planning an implementation, the most useful thing you can do this month has nothing to do with choosing a product. Map how the business runs today, and be honest about where it does not.