Why do ERP projects fail?

The short answer: ERP projects fail when an organisation treats a change in how work is run as a software installation. The platform matters, but failure usually forms in the gaps around it: an unclear business outcome, weak executive decisions, processes copied without review, unreliable data, excessive customisation, unrealistic scope, shallow testing, and a go-live plan that assumes adoption instead of earning it.

There is no single trustworthy global “ERP failure rate.” Definitions vary: one study may call a late project a failure; another only counts cancellation; a third measures whether expected value appeared. A useful review therefore asks what failed, for whom, and against which baseline.

1. 45%Average cost overrunIn McKinsey and Oxford research on large IT projects above $15 million—not ERP projects alone.
2. 56%Less value than predictedThe same research found an average benefit shortfall of 56%; scope and population matter.
3. 7×Objective attainment gapProsci reports 88% of initiatives with excellent change management met or exceeded objectives, versus 13% with poor change management.
4. 86.3%Variance explainedOne ERP-specific study of 36 manufacturing firms grouped critical implementation issues into eight factors explaining 86.3% of impact variance.

01First, define what “ERP failure” means

An ERP can go live on schedule and still fail operationally. It can also arrive late yet create durable value. Before choosing software, define success across five dimensions:

Failure is not only cancellation. It can mean cost overrun, missed benefits, poor data trust, parallel spreadsheets that never disappear, a process that works only with consultants present, or a system that operators avoid when pressure rises.

02The famous “70% of ERP projects fail” claim is not a safe benchmark

The percentage is repeated frequently, but often without a stable primary dataset, common definition, sample or date. Using it as a board-level fact creates false precision. A better approach is to use transparent evidence and state its limits.

McKinsey and the University of Oxford analysed more than 5,400 large IT projects. Their reported averages—45% over budget, 7% over time and 56% less value than predicted—show that technology delivery can miss value even when schedule variance looks modest. But these were projects with initial budgets above $15 million, not an ERP-only sample and not a proxy for every small or mid-sized manufacturer.

The decision lesson is stronger than the slogan: track value, not only go-live.

031. The project starts with software, not a business decision

“We need an ERP” is a purchase intention, not a problem statement. Teams then collect hundreds of requirements without knowing which decision should improve. The result is a large scope in which every request appears equally important.

Use a one-sentence outcome:

We need to know what by when, so who can make which decision, measured against this baseline.

For example: “The production planner needs reliable available-to-promise quantities by 10:00 each day so sales can confirm delivery dates, measured against the current rate of changed promises.” This statement connects data, timing, user and value.

PMI research involving more than 2,000 practitioners reported that poor requirements management was a primary reason projects failed to meet their original goals. The research concerns projects broadly, but its practical implication fits ERP work: requirements must remain connected to outcomes and owners, not become an unprioritised feature inventory. See the PMI requirements-management research.

042. Governance exists on paper but decisions have no owner

Steering committees do not create governance by themselves. ERP programmes repeatedly face cross-functional choices: who owns the item master, when finance closes a period, whether production can backdate consumption, how sales overrides credit limits, and who approves an exception.

When ownership is vague, the implementation partner becomes the accidental process owner. Decisions wait for meetings, customisation fills the vacuum, and departments optimise locally.

• Decision rightWho can approve a process change?Name one accountable role, not a committee of interested people.
• Data ownershipWho signs off each master-data domain?Separate the person preparing data from the person approving its quality.
• EscalationHow long can a blocked decision wait?Set a response window and the next named decision-maker.
• Value ownershipWho confirms that a promised benefit happened?Finance can validate value, but an operational owner must change the work.

053. The future process is just the old process moved onto a screen

Automating a broken handoff makes the problem travel faster. Workshops often document the current process in detail, then reproduce every approval, spreadsheet and workaround because changing them feels risky.

A stronger design separates four things:

1. Controls required by law, audit or safety.
• Steps that create operational value.
• Temporary workarounds caused by the old tools.
• Preferences that can change without increasing risk.

ERP-specific research supports treating implementation as organisational change. A case-based study of four firms found that cautious, evolutionary implementation plus change management and cultural readiness supported outcomes. The sample is small, so use it as directional evidence rather than a universal formula. See A framework for adopting ERP systems.

064. Data migration is scheduled as a technical upload

Migration is a sequence of business decisions: what to keep, what to merge, what to archive, which opening balances are authoritative, and who accepts exceptions. A clean import file does not prove that units of measure, duplicate customers, bills of material or warehouse balances are correct.

1. 01ProfileCount blanks, duplicates, inactive records, invalid formats and conflicting units before cleansing.
2. 02DecidePublish rules for merge, archive, conversion and exception handling. Do not let scripts make business policy silently.
3. 03RehearseRun at least two full migrations using production-like volumes and record reconciliation differences.
4. 04Sign offAssign an owner to each domain and require evidence, not a general “data looks fine” approval.

Reconcile totals at three levels: record count, financial or quantity total, and sampled transaction detail. The final cutover should reuse a rehearsed script and checklist; it should not be a new migration exercise performed under deadline pressure.

075. Customisation grows faster than the organisation can govern it

Some customisation is justified. A distinctive manufacturing calculation, local compliance rule or high-value customer workflow may create real advantage. The risk appears when customisation becomes the default answer to discomfort.

Every change creates a long-term surface for testing, security review, documentation, training and upgrades. Ask four questions before approving it:

• Is this a legal, safety or genuine competitive requirement?
• Can configuration or a small process change solve it?
• What is the five-year ownership cost, including regression testing?
• Who will remove the customisation if the need disappears?

Research from an ERP user perspective identified minimum customisation, training, testing, the project team, strategic decisions and performance measurement among the highest-ranked critical factors. That study focused on one German manufacturer, so its ranking should inform discussion rather than become a universal scorecard. See the ERP implementation user-perspective study.

086. Training teaches screens instead of work

A user can remember where a button is and still not know what to do when material is short, a quantity is rejected, a customer changes an order, or a machine stops mid-run. Role-based scenario practice is more useful than a generic tour.

Training should answer:

• Normal flowCan the user complete the common task without a trainer?Observe the full task, not a click-by-click imitation.
• Exception flowCan the user recover from a real deviation?Use returns, shortages, corrections and approval rejections.
• MeaningDoes the user know what the data affects downstream?Connect each entry to planning, costing, quality or finance.
• SupportDoes the user know where to get help during the shift?Provide a named channel, owner and response expectation.

Prosci’s benchmark combines more than 10,800 respondents across 101 countries. It reports that 88% of initiatives with excellent change management met or exceeded objectives versus 13% of those with poor change management. This is self-reported change-management research, not ERP-only experimental evidence, but the gap makes adoption discipline hard to dismiss. See Prosci’s change-management research.

097. Testing proves transactions, not operations

Unit tests and configuration checks are necessary, but they do not show that an end-to-end month, shift or order can survive realistic volume and exceptions. “The purchase order saved” is different from “the complete procure-to-pay flow reconciled correctly after a partial receipt, quality hold, price variance and supplier return.”

Build tests from business risk:

• Run normal, peak-volume and exception scenarios.
• Include integrations, permissions, reports, mobile devices and printers.
• Rehearse period close, not only daily transactions.
• Test with realistic roles and masked production-like data.
• Record expected results before execution so a surprising output is not accepted after the fact.

Exit criteria should be measurable: no unresolved critical defects; named high-risk scenarios passed; reconciliations within an agreed tolerance; support rota active; and rollback or contingency steps rehearsed.

108. Go-live is treated as the finish line

The first weeks expose workload, behaviour and edge cases that workshops could not fully predict. If the project team disappears at launch, users create workarounds precisely when process discipline matters most.

Plan a stabilisation period with daily triage at first, a clear severity model, visible ownership, and a weekly review of adoption and business signals. Freeze non-essential enhancements until the core flow is stable. Otherwise urgent defects compete with optional ideas and the team cannot see whether reliability is improving.

11A rollout model that reduces avoidable risk

No framework guarantees success. This sequence makes assumptions visible earlier and keeps each gate evidence-based.

1. Phase 1FrameBaseline the problem, name the outcome owner, define scope boundaries and list assumptions that could invalidate the case.
2. Phase 2DesignMap the end-to-end flow, remove obsolete workarounds, assign decision rights and approve the minimum viable process.
3. Phase 3ProveConfigure, migrate a realistic sample, test high-risk scenarios and let actual users complete tasks without coaching.
4. Phase 4RehearsePerform full migration, cutover, security, close and support rehearsals using production-like volume.
5. Phase 5StabiliseTriage daily, measure adoption and control defects before accepting optional enhancements.
6. Phase 6ExpandAdd sites, modules or automation only when the previous flow meets its stability and value gates.

One ERP study across 36 manufacturing companies found eight groups of critical issues explaining 86.3% of variance in implementation impact. Its population was limited and older, yet it reinforces an important point: ERP outcomes are multi-factor. A single “best practice” cannot compensate for weak governance, data, process and people together. See Identifying critical issues in ERP implementation.

12What should an ERP steering committee measure?

Use a compact set that balances delivery, adoption, operations, data and value. Avoid a dashboard with dozens of measures and no decision rule.

Report trends and decisions, not just a green status. A metric without an owner, threshold and response is decoration.

13If the implementation is already struggling

Do not begin with a larger status meeting. Begin with a two-week fact-finding reset:

1. Freeze new optional scope.
• List the five business flows that must work and assign one accountable owner to each.
• Compare promised outcomes with current baselines and available evidence.
• Review open defects, customisations, data exceptions and blocked decisions by business impact.
• Observe real users completing real work; do not rely only on survey sentiment.
• Publish a recovery backlog with an owner, date, acceptance test and dependency for every item.
• Re-plan in short gates. Cancel, defer or simplify work that does not protect the core outcome.

14Frequently asked questions

What is the main reason ERP implementations fail?

There is no single cause. The most common pattern is a mismatch between technology ambition and organisational readiness: unclear outcomes, delayed decisions, weak data ownership, untested process design and insufficient adoption support reinforce one another.

Is the ERP vendor responsible when a project fails?

Sometimes the product or implementation quality is a major cause. But accountability is shared. The customer owns business outcomes, process decisions, data acceptance and adoption; the vendor or partner owns accurate advice, competent delivery, transparency and agreed technical outcomes. Contracts should make those boundaries explicit.

Should a company customise the ERP or change its process?

Choose case by case. Keep customisation for legal, safety or genuinely differentiating needs. Prefer configuration or process simplification when the old behaviour exists only because of legacy tools or habit. Calculate the upgrade and test burden, not only build cost.

Is phased rollout always better than a big-bang launch?

Not always. A tightly integrated business, regulatory deadline or system shutdown may make a single cutover necessary. Phasing usually reduces learning risk, but interfaces and temporary duplicate processes can create their own cost. Choose based on operational dependencies and rehearse the selected strategy.

How long should ERP implementation take?

There is no responsible universal answer. Duration depends on scope, locations, data condition, integrations, regulatory controls, customisation and team availability. Estimate by verified work packages and decision capacity—not by an attractive calendar promise.

15Sources, scope and limits

• McKinsey and University of Oxford: Delivering large-scale IT projects. Large IT projects above $15 million; not ERP-only.
• Prosci: Best Practices in Change Management. Broad change initiatives and self-reported benchmarking; not ERP-only.
• PMI: Requirements Management research. Broad project population; published in 2014.
• Identifying critical issues in ERP implementation. ERP-specific research across 36 manufacturing firms; limited geography and an older implementation context.
• A framework for adopting ERP systems. Four-company case research; useful for mechanisms, not prevalence estimates.
• ERP critical success factors from a user perspective. Single-manufacturer setting; useful as directional evidence.

The evidence does not support a universal failure percentage. It does support a practical conclusion: ERP value is produced by coordinated decisions about process, data, people and technology—not by software installation alone.