Implementation
How to Avoid Costly ERP Implementation Mistakes
Every ERP failure I have worked on follows a recognisable route. It is not the complex technical fault that brings a project down. It is a small number of avoidable mistakes, made early, that compound until the budget and the schedule can no longer absorb them. The good news is that each one is a decision you control, and preventing it is cheaper than recovering from it.
The mistakes that actually cost money
Strip away the jargon and most costly implementations share the same handful of problems: sponsorship that is not real, scope that moves, data work deferred, and change management left until too late. Fix those four and you remove most of the risk. The wider picture on overruns and their causes is covered in why ERP projects fail and the numbers behind it, but here I want the practical, line-by-line prevention.
Weak sponsorship at the top
The most expensive mistake is a sponsor who approves the budget but does not do the work of leadership: making the hard calls, unblocking decisions, and visibly backing the change when the business resists. A sponsor who only signs cheques hands down risk to the whole programme. The fix is to have the sponsor's role written down, their time committed, and their own behaviour on the critical path from day one. Unless the most senior person owns the outcome, the project inherits their ambivalence.
Scope creep and the moving line
Scope creep is how budgets die quietly. It rarely arrives as a big request. It is the steady accumulation of "one more report" and "can we also do" that turns a standard build into a bespoke one a feature at a time. Every addition stretches the schedule, and a stretched schedule invites more requests in a downward spiral.
Hold the line with a change control board that has the authority to say no and a definition of done that is signed by every department. When a new request appears, ask whether it is genuinely needed for go-live or belongs in a second phase. This discipline is central to choosing the right implementation approach, because it is the methodology that governs how change is let in.
Deferring the data work
Data is the mistake teams most like to postpone, because it is unglamorous and it does not show up on the project plan until late. By the time it is urgent, it is far too late to do well, and the programme responds by cutting corners that then surface after go-live as reporting failures and frustration. The cost is far higher than anyone budgeted, which is exactly what our hidden costs article warns about.
Start the data workstream on day one. Profile, clean and validate in parallel with the build, not after it. The practical method is in our guide to cleaning master data before migration. Treat data as a first-class project pillar and most of the go-live panic simply never happens.
On one retail engagement the team deferred data cleaning because it looked like the least interesting work. Four months before go-live we profiled the customer base and found tens of thousands of duplicates that would have sent marketing campaigns to the wrong records and revenue reports out of balance. Pulling business people off their jobs to fix it added real cost, but nowhere near what fixing it after go-live would have cost.
Skipping change management
The quiet killer is change management left until the final weeks, when the programme realises adoption is flagging and sends everyone to a rushed training session. Training is not change management. Change management is showing people why the new way is better, before and after go-live, and it has to run the whole length of the programme to work. Prosci's change management research consistently finds that projects with structured change management are far more likely to meet their objectives.
Budget it, staff it, and start it early. The teams that treat adoption as a workstream rather than an afterthought go live faster and stay on the new system, rather than quietly reverting to the spreadsheets the deadline left behind. This is the same human dimension that decides whether the whole project is judged a success, explored in whether your business is ready to migrate.
The practical checklist
Boiling it down, eight checks prevent most of the avoidable cost. One, a sponsor whose role is written and commitments are real. Two, a signed definition of done and a change board with teeth. Three, data workstream starting on day one. Four, internal time priced and protected. Five, change management resourced from the start. Six, a realistic test plan with business sign-off on cutover. Seven, named owners for every process after go-live. Eight, an honest business case that the whole leadership team has actually read.
Run these eight and you reduce the risk that turns a £5 million programme into a £9 million one. The remaining piece is sequencing the work well, which is exactly what planning the migration step by step walks through.
Frequently asked questions
What is the most common ERP implementation mistake?
Weak executive sponsorship, closely followed by scope creep, deferred data work and change management left too late. These people, data and governance failures are far more common than technical ones, and each compounds into budget and schedule overruns.
How do you prevent scope creep in an ERP project?
Agree a definition of done signed by every department, stand up a change control board with the authority to say no, and route every request through it. Defer anything not needed for go-live to a later phase rather than absorbing it mid-build.
When should data migration start in an ERP project?
Day one. Profiling, cleaning and validating master data should run in parallel with the build, not after it. Deferring it makes the workseam a critical-path risk and forces costly shortcuts later.
Why is change management important in ERP implementation?
Because the system is only as good as its adoption. Teams that do not understand why the new way is better quietly revert to old habits and spreadsheets. Change management, not training, ensures people actually use the system the business paid for.
Sources and further reading
The argument in this article draws on public research. Where you want to go deeper, these are the sources cited in the text and further reading.
