ERP projects: 7 mistakes that derail change management
An ERP rarely fails for technical reasons. The seven people and organisation mistakes we see most often, and how to avoid them.
When an ERP project disappoints, the software usually gets the blame. In our experience, it is rarely the problem. What makes a project fail are people and organisation decisions, made (or avoided) long before go-live.
Here are the seven mistakes we come across most often.
1. Leaving the project to IT alone
An ERP changes how the company sells, buys, stores and accounts. If management and business leads are not involved, the tool will reproduce yesterday’s habits instead of improving them. The project needs an executive sponsor, present for the key decisions.
2. Trying to replicate the old system exactly
“Make it work like before” is the most expensive request in an ERP project. Every deviation from the standard means development, maintenance and a harder upgrade later. The right reflex: first ask why you work this way, then whether the standard does it better.
3. Not appointing key users
Every department needs a champion: someone who knows the business, takes part in workshops, tests, and then trains colleagues. Without them, every question goes back to the integrator, and users never take ownership of the tool.
4. Underestimating data migration
Duplicate products, incomplete customer records, wrong stock levels: the starting data is often the weakest link. An ERP fed with dubious data will produce dubious figures, and lose the teams’ trust in the very first week.
5. Training too early, or too little
Training three months before go-live is forgotten on the day. A one-hour demo is not enough. What works: training just before cut-over, on the company’s real data, then supporting users through the first weeks.
6. Going live without a cut-over plan
Who freezes data entry, when, how balances are checked, what happens if something goes wrong on Monday morning? Without written answers to these questions, the cut-over becomes a stressful improvisation. A rollback plan also reassures everyone.
7. Treating go-live as the end of the project
Go-live is only the beginning. The first three months reveal the real needs: a missing report, a process to adjust, a team to retrain. Plan this time and budget from the start.
What we do to avoid these mistakes
- scoping with management and the business, not just IT;
- key users trained first, who become internal champions;
- a dry-run migration to check the data before the big day;
- a planned cut-over, with frozen data entry and a rollback plan;
- a three-month warranty after go-live, followed by a suitable support plan.
A successful ERP is, above all, a team that wants to use it.