Why Do ERP Projects Fail? 7 Mistakes We Have Seen Across a Decade of Delivery

Organisations spend large sums on ERP systems, and some of them end up with a system that goes unused, or is only half used. The irony is that the cause is rarely the system itself — mature systems work. The cause is usually in how it was delivered and configured. From a decade of delivery, these are the seven most recurring mistakes, and how to protect your project from them.

Mistake 1: starting without a scope document

“We want a system that manages everything” is not a scope document. A project without a written, agreed scope expands endlessly: a new request every week, every department wanting an exception, the budget exploding and the deadline evaporating. We always start with a scope document that states exactly what will be delivered — written before any code. Anything outside the document is handled as a deliberate change, not a silent addition.

Mistake 2: no internal project owner

When the project is handed to the vendor alone, it fails. The system needs someone inside the organisation who holds the decision, gathers input from departments, and settles disagreements. Without that owner, every meeting turns into debate without resolution, and the system ends up reflecting the absence of decisions. Read: the signs you are ready, one of which is having an internal owner.

Mistake 3: automating the chaos instead of fixing it

If your processes are chaotic and you put a system on top of them as they are, you get faster chaos, not a system. A system imposes discipline on an agreed process; it does not create the agreement. The common mistake: speeding up a broken process instead of fixing it first. We diagnose the process before automating it, and sometimes recommend reordering it before any system.

Mistake 4: over-customisation

The wish for the system to match every old habit in the organisation leads to customisation without end. Every customisation means build cost, maintenance complexity, and a harder upgrade later. The rule: start from what is ready, and customise only the difference. Many of the “habits” we insist on are not necessary — they are simply what we got used to. A mature system usually offers a better way if we give it a chance.

Mistake 5: neglecting data migration and cleaning

Old, messy data migrated as-is spoils the new system from day one. Duplicate items, balances that do not reconcile, the same customer under different names. Cleaning is real work, and ignoring it means a clean system filled with dirty data. Read about this line item: what makes up ERP cost.

Mistake 6: late or incomplete training

The best system in the world fails if your team does not know how to run it. Training left to the final week, or delivered to one person who is supposed to pass it on to everyone else, produces a system a few people use and many ignore. We train to independence, with documented material the team can return to, not a single session that is forgotten.

Mistake 7: no plan for after go-live

Go-live is not the end but the beginning. The first weeks surface cases that did not appear in testing, and need close, fast support. A project that is handed over and then leaves the organisation on its own stumbles at the first real problem. Annual support and close follow-up after go-live are not a luxury — they are part of the project succeeding.

Early warning signs that your project is drifting

Failure rarely happens suddenly — it has early warnings that, if you notice them, save the project:

• Meetings without decisions: if every meeting defers the call, the project is losing momentum.
• Customisation requests multiplying: a new “small feature” every week is a sign that scope is expanding unchecked.
• Dates quietly pushed: repeated postponement with no clear reason means a deeper problem below the surface.
• The team secretly using the old system: the most dangerous sign — it means the new system is not actually serving them.

When these appear, stop and diagnose before they compound. The weekly cycles and the weekly report in our methodology are designed precisely to expose drift early, while correcting it is still cheap.

Can a troubled project be rescued?

Yes, and we have done it. Organisations have come to us after a failed ERP project with a previous vendor. Rescue starts with an honest diagnosis: what was actually built? What is usable? Where is the fault — in the configuration, the data, the training, or the system itself? Sometimes the system is sound and the problem is only configuration and training, so the rescue is cheaper than starting from zero. And sometimes the foundation is broken, and honesty requires saying so. What matters is not repeating the seven mistakes in the rescue attempt.

What the seven mistakes have in common

Notice that six of the seven have nothing to do with technology — they are about planning, decisiveness and people. That is why we insist that successful delivery begins with a diagnosis rather than an installation, and with a six-stage methodology with binding deliverables: qualification, proposal and contract, kick-off with a scope document, delivery in two-week cycles with a weekly report, handover with documented training, then annual support. The details are on the ERP systems page.

In summary

ERP projects succeed or fail before a line of code is written — in clarity, decisiveness and readiness. The system is a tool, and its success depends on who holds it and how. The free diagnostic session reveals whether your organisation is ready, and where the risks are before they turn into cost.