Articles · ERP

2026-12-09 12 min EN / FR

Why ERP projects fail, and the questions to ask before you start

ERP projects have a bad reputation, deserved or not. Most failures are not about the software. They are about decisions made before the first line of configuration. Here are the usual causes, and what to do about each.

The usual causes

1. Nobody owns the project on the client side

The vendor configures, but no one in the company decides. Questions pile up, answers come late, and the vendor fills the gaps with assumptions.

Fix: name one internal project owner with real authority and a few hours a week. Not "the whole team", one person.

2. The scope is a wish list

Everything is "required", nothing is prioritised, and the project tries to replace every tool at once.

Fix: split into phases. Phase one covers what the business cannot run without: typically sales, purchasing, stock, invoicing and accounting. Everything else waits. That pairs with the decision method in Odoo or custom software.

3. Processes were never written down

The team cannot describe how work really happens, and the ERP encodes someone's idea of it. Real practice, with its exceptions, appears after the launch.

Fix: map the current process with the people who do the work, not only with managers. Ask for exceptions: "what happens when it does not go as planned?"

4. Too much customisation

Every disagreement becomes a custom module. The system becomes expensive to change and painful to upgrade.

Fix: a rule: configure first, adapt the process second, customise last. Each customisation needs a business case and a cost of ownership.

5. Poor data

Duplicated customers, inconsistent product codes, outdated prices, missing addresses. The new system faithfully reproduces the mess.

Fix: treat data cleaning as a project of its own, started early, with named responsibilities. Decide what to migrate (often less than people think) and what to archive.

6. Users are involved too late

People see the system for the first time at training, and it does not match their work. They return to spreadsheets, and the ERP becomes a second system to maintain.

Fix: involve end users from the start, demonstrate early versions, and give them real tasks to try. Adoption is built, not announced.

Starting an ERP project?

We can help you write phase one, challenge the vendor proposal, and keep accounts under your name.

Talk before you sign Custom solutions

7. The "big bang" cutover

Everything switches on one date, with no fallback and no parallel period.

Fix: for small companies, a big bang can be fine if prepared well. Even then, plan a dry run with real data, a rollback option, and extra support the first two weeks. For more complex setups, switch by module or site.

8. Underestimated integration work

The ERP must talk to the shop, the bank, the carrier, the payment provider, the accountant. Each connection hides rules and exceptions.

Fix: list every integration at the start, with the direction of data flow, frequency, and who owns the other side.

9. Unclear success criteria

Nobody can say how they will know the project worked.

Fix: define three to five measurable outcomes: invoices produced without re-entry, stock accuracy, month-end closing time, orders processed per person.

10. No plan for after go-live

The vendor leaves, nobody maintains the system, upgrades pile up, and key knowledge sits with one person.

Fix: plan support, documentation, training, and a yearly review before signing. Put handover and ownership in an exit plan.

Questions to ask yourself before starting

  • What problem are we solving, in one sentence?
  • Which three processes cause the most pain today?
  • Who is the internal owner, and what other work will they put down?
  • Which tools will this replace, and which will remain?
  • What is the minimum we must have working on day one?
  • How clean is our data, and who will clean it?
  • Which of our practices are we willing to change?

Questions to ask the vendor

  • Can you show a similar project in a company of our size?
  • Who will actually work on our project, and are they available?
  • How do you handle scope changes, and what do they cost?
  • What is configured versus custom-coded in your proposal?
  • What happens at the next major version upgrade?
  • Where will the system be hosted, and in whose name are the accounts? (see the account ownership audit)
  • What documentation and training do we receive?
  • What does the handover look like, and can another provider take over?
  • Which parts of our data and customisations would be hard to move away from?

A good vendor welcomes these questions. Vague answers deserve attention.

Red flags

  • A fixed price and fixed date promised before any discovery work
  • "Yes, we can do that" to every requirement, with no discussion of trade-offs
  • No mention of data migration, or it is called trivial
  • Hosting and accounts owned by the vendor
  • No training or documentation in the offer
  • Pressure to sign quickly

What a healthy project looks like

  • Discovery: processes mapped, scope and priorities agreed, risks listed
  • Prototype: a configured system with your real products and a sample of your data, shown to end users
  • Iteration: adjustments based on actual use, with scope changes managed deliberately
  • Data migration: rehearsed at least once with real data
  • Training and dry run: users practice on real scenarios
  • Go-live with support: extra availability for the first weeks
  • Handover: documentation, access, a support arrangement, and a review after a few months

When to stop or pause

Projects get cancelled for good reasons. Consider pausing if:

  • The owner has left and not been replaced
  • The scope has doubled without a revised budget
  • Users are rejecting the prototype for reasons that are not being addressed
  • Data is not ready

Pausing to fix the foundation is cheaper than going live with a system nobody trusts.

Pre-start checklist

  • One named internal owner with time to do it
  • Phase one scope written on one page
  • Current processes described by the people doing them
  • Data cleaning plan and owner
  • Integrations listed
  • Success criteria defined
  • Accounts and hosting under our name
  • Post-launch support planned

Related

Want a pre-start review?

Send your phase one draft and the vendor offer. We will flag gaps before money is spent.

Start a conversation All articles