Guide · project success
Why ERP projects fail: five causes, none technical
ERP projects almost never fail because of the software. They fail for organisational reasons and those reasons are visible before kick-off.
Here are the five causes we encounter most often, the signals that help you spot a struggling ERP project early and what neutralises them: an ERP specification, project owner assistance and change management.
The short answer
Short answer: an ERP project fails because the client lacks time, processes are undocumented, data is dirty, the scope keeps growing and users are trained too late.
These causes are well known and avoidable. They can be spotted before signing: it is simply a matter of asking the right questions at the right time.
The five causes
Nobody has the time
The client-side project manager runs the project on top of their day job. Decisions drag on.
Processes that were never written down
Informal practices are reproduced as they are. You end up computerising the mess.
Dirty data
The new tool inherits the old one's errors and amplifies them.
A growing scope
Every meeting adds a request. The first batch is never delivered.
Users trained too late
They discover the tool at go-live and work around it.
How to spot each cause before you start
- Time: ask who, by name, will spend how many hours a week on the project. If the answer is vague, the risk is high.
- Processes: can you describe in writing how an order goes from quote to payment? If not, start there.
- Data: a sample of customer or product files quickly reveals the level of duplicates.
- Scope: is there a first batch that nobody is allowed to widen before delivery?
- Training: do key users handle the tool before acceptance, or do they discover it at the last minute?
What our organisation consulting does to avoid them
A process review before configuration, a short but written ERP specification, key users named from the outset, project owner assistance that arbitrates and a split into waves. The first batch stays small, each wave delivers a benefit and the scope only changes after a written decision. Change management starts at scoping: key users handle Odoo before acceptance.
Our approach is detailed on the organisational consulting and process review page. The free on-site situation audit is its first step.
Struggling ERP project: how to get it back on track
A struggling ERP project is not necessarily lost. An audit tells you what is recoverable, what needs to be redone and what should be stopped. That is the purpose of an Odoo project recovery, which also applies to a project run by another Odoo integrator.
To avoid falling into the same trap again, re-read the integrator selection criteria in our dedicated guide.
Frequently asked questions about ERP project failure
It is rare. When the software is to blame, it is usually because it was bent to fit unscoped practices through an accumulation of custom developments.
One identified person, with dedicated time and the authority to arbitrate. A project manager who has to ask their hierarchy for everything slows down every decision.
Yes, but a short one: the key processes, volumes, interfaces and the expected first batch. An ERP specification of a few pages, written with an Odoo consultant, is enough to compare proposals. A hundred-page document freezes needs before you have seen the tool.
Project owner assistance (AMOA in French) represents your interests with the integrator: it writes the scope, prepares decisions, organises acceptance testing and drives change management. It is one of the strands of our consulting offer.
No, but you do need to write down the scope of the first batch, the names of the key users and how decisions are made. The rest is adjusted wave by wave.
Three signs: decisions that come back at every meeting, an acceptance phase that keeps being postponed and a list of requests that grows without arbitration.
Does your project have any of these five weaknesses?
Better to know before you start. Thirty minutes is enough to take stock.