The mistakes that make ERP projects fail
An ERP abandoned after six months is almost never abandoned because of the software. It is abandoned because the teams went back to Excel, because the figures could not be trusted, or because the project never had an end.
Here are the mistakes we see repeatedly, and what prevents them. None are specific to Odoo — they apply to any ERP.
1. Building before using
The most frequent mistake, and the most expensive.
A company describes its processes in a meeting, the matching modules get built, and the whole thing goes live. Three months later it turns out the real process differs from the described one — because nobody works exactly the way they recount it.
What works: put the standard foundation live first — purchasing, sales, stock, invoicing — and write code only after a few weeks of real use. The need is then expressed against concrete cases, not recollections.
2. Letting scope grow
A project starts with invoicing. Along the way someone asks for payroll. Then document management. Then a customer portal. Each request is legitimate, and each one pushes the go-live back.
An ERP that never goes live returns nothing, whatever its scope.
What works: freeze a phase-one scope, write down what comes after, and deliver phase one. Later phases are far easier to sell internally once the first is running.
3. Not settling the accounting question
Who keeps the books, and in which tool? This has to be settled before the edition is chosen and before configuration starts.
Discovering it mid-project forces the chart of accounts to be redone, sometimes the edition to be changed. We devote a whole article to it: Community or Enterprise.
4. Skipping a clean data migration
Importing uncleaned files gives you an ERP that is technically working and practically unusable: duplicate customers, wrong stock, inconsistent balances.
The teams then have no reason to trust the system, and go back to their files. Details in our article on data migration.
5. Treating training as a formality
A two-hour demo at the end of the project trains nobody. Users remember what they did themselves, on their own data.
What works: train on the company's real configuration, with its own customers and products, hands on the keyboard. And train the right people — those who will enter data every day, not just their manager.
6. Having nobody internally owning the project
An ERP touches every department. Without someone on the company side to arbitrate between departments and decide when two ways of working collide, the integrator ends up settling organisational questions that are not theirs to settle.
The role requires no technical skill. It requires authority and availability.
7. Modifying the core
The shortcut that costs the most later. Modifying Odoo's own code instead of writing extensions makes every version upgrade impossible or ruinous.
A cleanly written module survives updates. A modified core freezes the system on its version, and the gap widens every year.
8. Not planning for after
An ERP is not a project that ends. Versions ship, the business changes, new needs appear.
Deciding upfront who handles maintenance, backups and version upgrades avoids discovering two years later that you are running an obsolete version nobody knows how to migrate.
Frequently asked questions
How many ERP projects actually fail? Published failure rates vary wildly depending on the definition used — outright abandonment, budget overrun, reduced scope. Rather than quote a questionable figure, note what is observable: failing projects almost always share the causes listed here, and none of them is technical.
Can a project that started badly be salvaged? Often yes. It starts with cutting scope back to what works, cleaning up the data, and retraining the teams. Starting over is rarely necessary, and rarely the right call.
Do we need a full-time project manager on our side? Not full-time, but one identified person with dedicated time and the authority to decide. It is the factor that most clearly separates projects that land from those that do not.
Is Odoo riskier than a proprietary ERP? The risk comes from how the project is run, not from the software. Odoo's advantage is being extensible without extra licensing; its drawback is making custom work easy — and therefore tempting, including when it is not needed.
How do we start without getting it wrong? With a scoping exercise that reviews your processes and separates what fits the standard from what needs development. We then provide a detailed, free quote within 24 hours.
For the details of our offer, see our Odoo service. For sector projects, Odoo for construction and Odoo for car rental.