ERP failures are usually described as software problems and almost never are. The system that a company blames in year two is generally the same system running successfully at a competitor down the road. What differed was scope discipline, data quality, sponsorship, and whether anyone seriously addressed the fact that people would have to change how they work.
This article covers twelve causes of failure, what each looks like from the inside, the early warning signs that appear months before anyone admits there is a problem, and what to do if you are already in one.
What “Failure” Actually Means
Very few ERP projects are abandoned outright. Failure is usually quieter and takes one of four forms:
• Budget failure — the system works, and it cost far more than approved.
• Schedule failure — go-live slipped repeatedly, and the delay cost more than the overrun on fees.
• Benefit failure — the system went live on time and on budget, and none of the promised improvements materialised. This is the most common and the least reported.
• Adoption failure — the system runs, and staff maintain shadow spreadsheets alongside it. Technically live, practically abandoned.
Benefit and adoption failures are the ones worth worrying about, because they pass every project management checkpoint and only become visible when someone asks, a year later, whether anything actually improved.
Cause 1: Scope That Was Never Really Defined
What it looks like: the project charter says “modernise our systems” or “improve efficiency”. Every department assumes their priority is included. Nobody wrote down what is excluded, so nothing can be refused.
Why it happens: defining scope requires saying no to colleagues before the project has any credibility. It is easier to defer the argument, and the argument then happens repeatedly, at higher cost, for the rest of the project.
How to prevent it: write scope as measurable outcomes, and write an explicit out-of-scope list that is as long as the in-scope list. Establish a change-control process on day one, with a named approver and a cost estimate attached to every request. Requests that survive that process are usually genuine.
Early warning: the phrase “while we’re in there, can we also…” appears in more than two meetings.
Cause 2: Executive Sponsorship in Name Only
What it looks like: a senior leader is listed as sponsor, attends the kickoff, and is not seen again. Cross-departmental disputes escalate to a project manager with no authority to settle them, so they do not get settled.
Why it happens: sponsorship is treated as a title rather than a workload. Executives underestimate how many decisions an ERP project generates that only they can make.
How to prevent it: define what the sponsor is actually committing to — attendance at steering meetings, decision turnaround within a defined period, visible communication to staff, and willingness to overrule a department head. If no executive will commit to that, the project is not ready to start.
Early warning: steering committee meetings are cancelled or repeatedly rescheduled; decisions sit unresolved for weeks.
Cause 3: Data Nobody Cleaned
What it looks like: migration is scheduled for the final six weeks. It begins, and the team discovers thousands of duplicate customers, items with no cost, suppliers with wrong tax details, and inventory records that do not match the warehouse. The go-live date is already announced.
Why it happens: data cleanup is unglamorous, nobody owns it, and its scale is invisible until someone starts. Every project underestimates it, including the ones that have been warned.
How to prevent it: name a data owner at kickoff, not at migration. Start cleaning in the first month. Profile the data early — count duplicates, blanks and outliers — so the scale of the work is a number rather than a feeling. Migrate master data and opening balances; archive transaction history instead of carrying it forward.
Early warning: nobody can tell you how many customer records you have, or how many are active.
Cause 4: Over-Customisation
What it looks like: every process gap is closed with custom development. The system matches the old way of working perfectly. The first upgrade takes four months and breaks three modifications nobody remembers requesting.
Why it happens: customising is easier than change management. Telling a department to adapt is a political cost; writing code is a line item. The bill arrives later, permanently, at every upgrade.
How to prevent it: default to standard functionality. Require a written business justification for each customisation, approved by the sponsor, stating what competitive advantage it protects. Most requests do not survive that question. Keep customisation for genuine differentiators and adapt everywhere else.
Early warning: the customisation list grows during design instead of shrinking.
Cause 5: Testing That Was Compressed
What it looks like: the project runs late. Testing is the last phase before go-live, so testing absorbs the delay. User acceptance testing becomes a two-day demonstration rather than genuine scenario testing. Defects are discovered by customers in week one.
Why it happens: testing is the only phase that can be shortened without an obvious immediate consequence. That is precisely why it should be protected.
How to prevent it: protect testing in the plan and treat cutting it as a scope decision requiring sponsor approval. Run three layers — unit, integration, and user acceptance with real staff, real scenarios and migrated data. If the schedule must give, remove a module from the first phase rather than removing testing.
Early warning: the test plan has fewer scenarios each time it is revised.
Cause 6: Training Treated as an Event
What it looks like: one training session, two weeks before go-live, delivered by a consultant on demo data. Staff go live having seen the system once, on records that bear no resemblance to their own.
Why it happens: training is budgeted as a fixed number of days and scheduled where it fits, rather than designed around what people need to do.
How to prevent it: train by role, on your own migrated data, in the environment people will actually use. Deliver close enough to go-live that it is fresh but with time to practise. Provide short task-based reference guides. Identify super users in each department and train them more deeply so support exists on the floor, not only on a ticket queue.
Early warning: the training plan is described in days rather than in roles and tasks.
Cause 7: The Team Was Never Backfilled
What it looks like: your best operational people are assigned to the project on top of their existing full-time jobs. They attend design workshops between crises, make decisions while distracted, and burn out by month five.
Why it happens: backfilling costs money that is visible in a budget, whereas exhausting your key staff costs money that is not.
How to prevent it: cost project participation honestly in the business case. Either backfill the roles, reduce operational duties formally, or reduce project scope to match the capacity that genuinely exists. Assigning people without adjusting their workload is a decision to under-resource the project while pretending otherwise.
Early warning: project workshops are repeatedly rescheduled because key people are firefighting.
Cause 8: Nobody Managed the Change
What it looks like: staff first hear about the new system when they are invited to training. Rumours about job losses circulate. On go-live day, resistance appears as a thousand small refusals — data entered incorrectly, workarounds preserved, the old spreadsheet quietly maintained.
Why it happens: change management sounds soft, is easy to cut, and its absence produces no visible symptom until the system is live.
How to prevent it: communicate early and repeatedly. Explain what improves for each team, not only what improves for management, and be honest about what gets harder. Involve staff in design so the system reflects their reality. Address job security questions directly rather than allowing the vacuum to fill itself.
Early warning: people refer to it as “the finance system” or “IT’s project” rather than as the company’s system.
Cause 9: The Wrong System Was Chosen
What it looks like: six months in, a fundamental capability is missing — finite scheduling, a costing method, a compliance report — and the only routes forward are a bolt-on, a heavy customisation, or a manual process.
Why it happens: selection was decided on demo quality rather than verified fit. Must-have requirements were never tested against real scenarios, and “that can be customised” was accepted as a yes.
How to prevent it: score against scripted scenarios drawn from your own business, mark must-haves as pass or fail independently of the total score, and treat roadmap functionality as absent. Call references at your size in your industry and ask what they discovered after go-live.
Early warning: during selection, more than a couple of your requirements were answered with a plan rather than a demonstration.
Cause 10: The Partner Was Wrong for You
What it looks like: consultants who know the software but not your industry. Advice that produces a technically correct configuration nobody can operate. Named senior consultants replaced by juniors after the contract is signed.
Why it happens: partners are selected on price or on vendor recommendation rather than on verified comparable experience, and staffing is not contractually protected.
How to prevent it: ask for three references of your size in your industry and call all three. Ask who specifically will work on your project and get key personnel written into the contract. Confirm knowledge transfer is planned so you are not permanently dependent.
Early warning: the people in the sales meetings are not the people who appear at the first workshop.
Cause 11: A Timeline Nobody Believed
What it looks like: the date was set by a board meeting, a financial year end, or a contract expiry rather than by the work required. Everyone involved privately knows it is not achievable, and nobody says so until it is missed.
Why it happens: optimistic dates get approved and honest dates get challenged, so honest estimates are quietly adjusted upward until they fit.
How to prevent it: plan to the honest estimate. Build in contingency explicitly rather than hiding it inside task estimates. Use stage gates with defined criteria, so slippage is visible early rather than announced at the end. Create an environment where raising a risk is rewarded rather than treated as negativity.
Early warning: the plan has no contingency, and every task is estimated at exactly the time available.
Cause 12: No Ownership After Go-Live
What it looks like: the partner leaves at the end of hypercare. Nobody internally owns the system. Configuration drifts, reports stop matching, permissions are granted ad hoc, and within eighteen months people are building spreadsheets again.
Why it happens: the project budget ends at go-live, and ongoing ownership was never established as a role.
How to prevent it: name an internal system owner during the project, not after it. Give them time allocated to the role. Plan knowledge transfer from the partner deliberately. Schedule a formal benefits review at six and twelve months to check whether the improvements you bought have actually appeared.
Early warning: nobody can answer the question “who owns this system after go-live?”
Warning Signs, Ranked by How Early They Appear
| When it appears | Warning sign | What it usually predicts |
| Before kickoff | No named sponsor with real authority | Decisions will stall from month two |
| Before kickoff | Scope described in adjectives, not outcomes | Scope creep and budget overrun |
| Month 1–2 | Nobody owns data quality | Migration crisis in the final weeks |
| Month 2–4 | Customisation list growing during design | Painful, expensive upgrades forever |
| Month 2–4 | Key staff missing workshops due to day jobs | Design decisions made without the people who know |
| Month 4–6 | Test plan shrinking with each revision | Defects discovered by customers after go-live |
| Month 4–6 | Staff still calling it “IT’s project” | Adoption failure regardless of configuration quality |
| Near go-live | Training compressed into a single session | Productivity dip that never fully recovers |
| After go-live | Shadow spreadsheets reappearing | Benefits will not materialise |
If You Are Already In Trouble
Most struggling projects are recoverable. The recovery is rarely comfortable.
39. Stop and assess honestly. Pausing for two weeks to establish the real position costs less than three more months of pushing toward an impossible date.
40. Get an independent view. Internal teams cannot easily report that a project they are running is failing. An outside assessment gives people permission to say what they already know.
41. Cut scope before cutting quality. Deferring a module costs far less than going live untested and untrained.
42. Re-baseline the plan publicly. A revised, credible date restores confidence faster than repeated small slips.
43. Fix data before anything else. No configuration decision improves a system loaded with wrong data.
44. Reset sponsorship. If the sponsor has disengaged, replace them or formally escalate. The project cannot proceed without someone who can settle disputes.
45. Decide about the partner deliberately. Changing partners mid-project is expensive and disruptive, and sometimes it is still the cheapest remaining option.
46. Consider a phased fallback. Going live with finance only, properly, beats going live with everything, badly.
| The decision most companies avoid too longIf the system genuinely cannot meet a must-have requirement, no amount of additional effort will change that.Stopping is expensive. Continuing toward a system that cannot do the job is more expensive, and the cost compounds for years. |
Frequently Asked Questions
What is the most common cause of ERP failure?
Poor data quality and inadequate change management are the two that appear most consistently, usually together. Both share the same underlying pattern: they are unglamorous, easy to defer, and produce no visible symptom until the point at which fixing them is expensive.
Is ERP failure the software’s fault?
Rarely. The same systems that produce disasters at one company run successfully at comparable companies elsewhere. Genuine software mismatch does happen, but it almost always traces back to a selection process that accepted claims without verifying them against real scenarios.
How do I know if my project is failing?
Look for shrinking test plans, a growing customisation list, cancelled steering meetings, key staff missing workshops, and staff referring to the system as somebody else’s project. These appear months before a missed go-live date and are far easier to address early.
Can a failing ERP project be recovered?
Usually, yes. Recovery typically requires reducing scope, re-baselining the timeline publicly, fixing data properly, and restoring active sponsorship. The main obstacle is organisational reluctance to acknowledge the position early enough for those actions to still be cheap.
Should we go live if we are not ready?
No. Going live untested and untrained converts a schedule problem into an operational one, and operational problems damage customer relationships that outlast the project. Reduce scope and go live with less, properly, instead.
How much contingency should an ERP project carry?
Ten to twenty percent is a common range, weighted higher for manufacturing, multi-entity structures, or projects with known data quality issues. Contingency should be explicit rather than hidden inside task estimates, so that consuming it is a visible decision.
What is the single highest-return preventive action?
Naming a data owner at kickoff and starting data cleanup in month one. It is the cheapest intervention available and it removes the most common cause of late-stage crisis.
Conclusion
ERP projects fail for organisational reasons dressed up as technical ones. Undefined scope, absent sponsorship, dirty data, reflexive customisation, compressed testing, token training and unmanaged change account for the overwhelming majority of disappointing outcomes — and every one of them is visible months before the consequences arrive.
Name a sponsor who will actually decide things. Own your data from day one. Adapt to the software rather than rebuilding it. Protect testing and training when the schedule tightens. And appoint someone to own the system after go-live, because a system nobody owns quietly reverts to spreadsheets within two years.
Leave a Reply