It is almost never the software
When an ERP project goes wrong, the first explanation is usually that the system was the wrong choice. It rarely is. Business Central, SAP, NetSuite, Odoo — any mature product can handle the processes of an ordinary distribution or manufacturing company. What fails is everything around it: decisions, ownership and people.
This matters because it determines where you look for the risk. If the problem were the product, switching products would fix it. If the problem is that nobody wrote down how the business actually works, a second project will fail the same way — only more expensively, because you will have paid for two migrations.
Seven causes, in order of how often they occur
1. Nobody on the client side owns the project
The most common by a wide margin. A partner cannot make decisions about your processes; they can only ask questions. Without someone empowered to answer, every question waits a week and the timeline doubles.
"The finance director is responsible" usually means nobody is, because the finance director does not have several hours a week free for two months. What is needed is a named person who understands the business, has authority to say "we do it this way," and has had some of their normal workload removed.
2. Automating a mess
If a process is undocumented and runs on informal agreements, the system will not fix it — it will freeze it in place, and in a harder form, because working around an inconvenient step is now more difficult than it used to be.
The order matters: understand how the process should work, then configure. Not the other way round.
3. Data migrated as-is
Duplicate customers, items under three different codes, stock balances that have never reconciled to the warehouse. All of it moves into the new system and starts causing problems there — except now the new software gets the blame. Cleaning comes before migration, and it is covered in the data preparation checklist.
4. Scope grows during the project
Finance and inventory first, then manufacturing gets added, then CRM, then an e-commerce integration. Each addition looks sensible on its own; together they break the timeline and the budget.
The problem is not the additions themselves but that they are not treated as a change to the agreement. The scope grows and the deadline does not, and after that it is arithmetic.
5. Training happens too early
The team is trained two months before go-live, on a demo company. By the time the system is live, it has been forgotten. Training belongs close to cutover, on your own configured data.
6. The parallel period has no end date
The old system stays available "just in case," and people drift back to it because it is familiar. Two systems run half-populated for months. The date the old system is switched off should be set before the project starts, not decided afterwards.
7. Customisation instead of rethinking the process
Every modification costs twice: once to build, and again at every update. A meaningful share of customisation requests actually mean "we are used to doing it this way" rather than "there is no other way." Separating those two is work in itself, and it pays for itself — the criteria are in when AL customisation pays off.
Signs a project is drifting
Failure is rarely sudden. The symptoms appear months in advance.
- Meetings end without decisions, and the same questions come up for the third time.
- Different people attend from your side each week, and each one reverses what the last one agreed.
- The deadline moves but the scope does not shrink.
- Key users have never seen the system.
- The customisation list grows faster than it is closed.
- Nobody can name the date the old system gets switched off.
Two or more of these at once is a reason to stop and renegotiate, not to push harder.
What to do if it has already started
A drifting project is almost always recoverable, but not by going faster.
Freeze the scope. Fix in writing what goes live first. Everything else becomes a second phase with its own timeline.
Name one owner on your side. If there is not one, this is the thing to fix today.
Shrink the first release. Better to launch finance and inventory and see them work than to spend six months preparing a perfect launch of everything. A first success changes how the team feels about the project more than any amount of explanation.
Set the switch-off date. Even if it looks unrealistic. Without one, the parallel period never ends.
Four things that remove most of the risk
| What to do | When | Which risk it removes |
|---|---|---|
| Name an owner with authority | Before signing | Cause 1 |
| Write the processes down in plain text | Before selecting a system | Causes 2 and 7 |
| Clean the master data | Before migration | Cause 3 |
| Fix first-phase scope and the switch-off date in the contract | At signing | Causes 4 and 6 |
Three of the four happen before you choose a partner, and none of them requires budget. This is the cheapest insurance available: documented processes and clean data shorten the project and reduce its cost at the same time. Partner selection is covered in how to choose an implementation partner, and the cost structure in what an implementation costs.
Frequently asked questions
What share of ERP projects actually fail?
Published estimates vary enormously because everyone counts differently — some treat a budget overrun as failure, others only a full abandonment. More useful than the statistic is checking your own risk signals: no named owner, undocumented processes, dirty data.
Can a project that is already drifting be saved?
Almost always, but not by accelerating. Freeze the scope first, then name an owner on the client side, then shrink the first release. Speeding up without those three only brings the moment it stops closer.
Whose fault is it when a project fails — the partner or the client?
Usually shared, which is why apportioning blame does not help. The partner is responsible for flagging risk and not accepting an unrealistic scope. The client is responsible for decisions about their own processes, which no partner can make for them.
Will changing partner help?
If the cause is on the partner side — missing domain expertise, poor responsiveness, nothing written down — yes. If the cause is on yours, the second project repeats the first at higher cost, because you now pay for two migrations.
How much time does the client need to commit?
Not the managing director but the named owner, and at minimum several hours a week for the length of the project, with peaks during process design and test migration. If nobody has that time, the project is better postponed than started.