ERP implementations are among the most consequential investments a company will ever make. They touch every department, reshape workflows, and demand months — sometimes years — of sustained effort. Yet the failure statistics remain staggering.
According to Panorama Consulting’s research, 55 to 75% of ERP projects fail to meet their original objectives. Gartner puts the figure at 75% for projects that are considered outright failures or deliver diminished value. The average cost overrun hovers around 240%, and schedule overruns average 178% of original estimates.
These are not abstract numbers. Behind every failed ERP project, there are real consequences: executives who lose their positions, companies that face liquidity crises, and organizations that spend years recovering from a botched rollout.
This article examines seven recurring failure patterns, each illustrated with real-world cases. More importantly, it provides concrete strategies to prevent them. This is a spoke article in our complete ERP implementation guide — refer to the hub for the full methodology.
1. No Executive Sponsorship (or Sponsorship in Name Only)
What Goes Wrong
An ERP project without genuine executive sponsorship is a project running on borrowed time. The sponsor is not a figurehead who signs the budget approval and disappears. The sponsor is the person who resolves cross-departmental conflicts, maintains organizational priority for the project, and absorbs political resistance.
Real-world example: A major UK public sector ERP program (reported by the NAO) saw its executive sponsor rotate three times in two years. Each transition created a 3-4 month vacuum where no strategic decisions were made. Vendors exploited the gap to push scope changes, and the project eventually delivered 18 months late at 3x the original budget.
Warning Signs
- The sponsor delegates all steering committee meetings to a deputy
- Budget escalation requests sit unsigned for weeks
- Cross-departmental disputes go unresolved because “nobody has the authority”
- The project is positioned as an “IT initiative” rather than a business transformation
How to Prevent It
Appoint a C-level sponsor with genuine authority over the affected business units. Mandate their physical presence at monthly steering committees. Define the sponsor’s responsibilities in the project charter — including conflict resolution timelines. If the sponsor changes, treat it as a major risk event and conduct a formal re-alignment session within two weeks.
2. Underestimating Change Management
What Goes Wrong
Organizations routinely treat ERP implementation as a technology deployment. It is not. It is a fundamental change to how people work. When change management is neglected, user adoption collapses. The system goes live, but employees revert to spreadsheets, shadow systems, and workarounds within weeks.
Real-world example: When Hershey’s went live with SAP R/3 in 1999, the technical deployment itself — while troubled — was compounded by a near-total failure in change management. Warehouse workers and order processors were inadequately prepared for new workflows during the critical Halloween shipping season. The result: $150 million in lost sales and a 19% drop in quarterly profits. The system worked; the people could not use it effectively.
Warning Signs
- No dedicated change management budget line (or it is the first line cut)
- “Training” is treated as synonymous with “change management”
- Business process owners are not identified or not involved
- The phrase “users will adapt” appears in project documentation
How to Prevent It
Allocate 15-20% of the total project budget to change management. Start change activities in the design phase, not two weeks before go-live. Identify change champions in every department. Measure adoption with leading indicators (login rates, transaction completion rates, support ticket volumes) — not just lagging satisfaction surveys. For a deeper dive into planning these activities, see our guide on ERP project planning phases.
3. Scope Creep and Uncontrolled Customization
What Goes Wrong
Scope creep is the silent killer of ERP projects. It starts innocently: a department head requests “just one small customization.” Then another. Then a critical integration that was not in the original design. Each individual request seems reasonable. Collectively, they transform a 12-month project into an 18-month money pit with a fragile, over-customized system that is nearly impossible to upgrade.
Real-world example: Lidl’s SAP implementation in Germany, which began in 2011, was ultimately abandoned in 2018 after consuming an estimated EUR 500 million. A central factor was the decision to customize SAP to match Lidl’s existing pricing logic (based on purchase price) rather than adapting business processes to SAP’s standard approach (based on retail price). This single customization decision cascaded into thousands of downstream modifications that made the system unmanageable.
Warning Signs
- No formal change request process, or the process exists but is routinely bypassed
- Customization decisions are made by department heads without impact analysis
- The integrator agrees to every request without pushback (they bill by the hour)
- The gap between “standard” and “custom” is not tracked or reported
How to Prevent It
Implement a rigorous change control board (CCB) from day one. Every scope change must include a documented impact on budget, timeline, and technical debt. Set a hard customization threshold: if total customizations exceed 20% of standard functionality, escalate to the steering committee. Favor configuration over customization. Favor process adaptation over configuration. Make “fit-to-standard” the default philosophy.
4. Poor Data Migration
What Goes Wrong
Data migration is consistently the most underestimated workstream in ERP projects. Organizations assume that moving data from the old system to the new one is a straightforward technical task. In reality, legacy data is riddled with duplicates, inconsistencies, missing fields, and format incompatibilities. When dirty data enters the new ERP, it poisons every downstream process: incorrect inventory levels, wrong customer addresses, broken financial reconciliations.
Real-world example: Revlon’s 2018 SAP S/4HANA migration at its Oxford, North Carolina plant led to a data migration failure that disrupted production and shipping. The company disclosed a $64 million net sales impact in its SEC filing. Inaccurate master data — particularly around production scheduling and inventory — caused the plant to effectively lose visibility into its own supply chain for weeks.
Warning Signs
- Data migration is assigned to a junior analyst with no business context
- No data profiling or quality assessment is performed before design phase
- Legacy system owners are not involved in mapping exercises
- The migration plan has no dry-run schedule
- “We’ll clean the data after go-live” appears in meeting notes
How to Prevent It
Start data profiling in the first month of the project. Assign a dedicated data migration lead with both technical and business expertise. Run a minimum of three dry migrations before go-live, each with a formal quality scorecard. Define data ownership: every data domain (customer, product, finance) must have a named business owner responsible for quality. Budget 15-20% of total project effort for data activities.
5. Insufficient Testing
What Goes Wrong
Under schedule pressure, testing is the first phase to be compressed. Teams skip integration testing, reduce UAT (User Acceptance Testing) cycles, or — worst of all — let the integrator mark their own homework by performing testing without meaningful business user involvement. The result: defects that should have been caught in a test environment surface in production, often during the most critical business periods.
Real-world example: Nike’s 2000 implementation of i2 Technologies demand planning software (tightly integrated with their ERP) suffered from inadequate integration testing. The system generated wildly inaccurate demand forecasts, ordering $90 million too much of slow-selling shoes and too little of popular models like Air Jordans. The resulting write-down was $100 million, and Nike’s stock dropped 20%. Their CEO famously told analysts: “This is what you get for $400 million.”
Warning Signs
- Testing phase is less than 15% of total project duration
- No dedicated test environment (testing is done in the development environment)
- Test scripts are written by the integrator, not validated by business users
- Integration testing between modules is “planned for later”
- Performance/load testing is not in scope
How to Prevent It
Fix the testing timeline in the project charter — it should represent 20-25% of total duration. Insist on four testing layers: unit testing (integrator), integration testing (integrator + internal IT), UAT (business users with real scenarios), and regression testing (after every configuration change). Create a go/no-go checklist tied to test completion rates and defect severity. Never go live with unresolved severity-1 or severity-2 defects.
6. Wrong Vendor or Integrator Fit
What Goes Wrong
Choosing an ERP vendor or implementation partner based primarily on brand reputation, lowest bid, or executive golf relationships is a reliable path to failure. A vendor whose strength is manufacturing will struggle in a services-heavy organization. An integrator with 500 consultants but no experience in your industry will apply generic templates that miss critical business specifics.
Real-world example: Waste Management’s 2008 lawsuit against SAP (settled for $100 million) centered on the allegation that SAP had sold them a system that could not handle the waste industry’s specific operational requirements without massive customization. The project consumed 18 months and $100 million before being abandoned. The root cause: a fundamental mismatch between the vendor’s standard capabilities and the buyer’s industry-specific needs, compounded by a sales process that prioritized deal size over fit.
Warning Signs
- The vendor demo is entirely based on their standard demo script, not your processes
- The integrator’s proposed team has no verifiable experience in your industry
- Reference clients provided are in completely different sectors or sizes
- The commercial proposal focuses heavily on licensing and lightly on implementation services
- The integrator does not challenge your requirements during presales — they agree with everything
How to Prevent It
Use a structured vendor scoring methodology with weighted criteria. Demand industry-specific references and speak to them without the vendor present. Require CVs of the actual consultants who will staff your project (not the presales team). Include contractual clauses for consultant continuity. Run a proof of concept on your most complex process, not your simplest one.
7. Cutting the Training Budget
What Goes Wrong
Training is often the last budget line approved and the first one cut when costs escalate. Organizations assume that a few “train-the-trainer” sessions and a user manual will suffice. In practice, inadequate training means users do not understand the system’s logic, cannot troubleshoot basic issues, and never learn the efficient workflows that justify the ERP investment.
Real-world example: A North American mid-market manufacturer (documented in a Panorama Consulting case study) went live with a new ERP with only 8 hours of training per user. Within three months, 40% of transactions contained errors, the finance team could not close the books on time, and the company hired 12 temporary staff to manually correct data. The cost of remediation exceeded the original training budget by a factor of five.
Warning Signs
- Training is scheduled entirely in the two weeks before go-live
- Training content is based on the integrator’s generic materials, not your configured system
- No role-based training paths (everyone gets the same session)
- No post-go-live training or refresher plan
- Training budget is less than 5% of total project cost
How to Prevent It
Budget 10-15% of total project cost for training. Design role-based training paths: a warehouse operator, an accounts payable clerk, and a sales manager need entirely different curricula. Start training 6-8 weeks before go-live, not 2 weeks. Provide a sandbox environment where users can practice without consequences. Plan for post-go-live refresher sessions at 30, 60, and 90 days. Measure training effectiveness with practical assessments, not attendance sheets.
The Common Thread: These Failures Are Preventable
Looking across all seven patterns, a clear theme emerges: ERP failures are rarely caused by technology. They are caused by organizational decisions — or the absence of them.
Every failure pattern described above has a known prevention strategy. The knowledge exists. The frameworks exist. What fails is the discipline to apply them consistently, and the courage to make hard decisions early rather than easy decisions that compound into catastrophic outcomes later.
Here is a summary checklist for your next ERP project:
| Failure Pattern | Key Prevention Metric |
|---|---|
| No executive sponsorship | Sponsor attends 90%+ of steering committees |
| Weak change management | 15-20% of budget allocated to change activities |
| Scope creep | Customization ratio tracked and capped at 20% |
| Poor data migration | Minimum 3 dry-run migrations before go-live |
| Insufficient testing | Testing phase = 20-25% of project duration |
| Wrong vendor fit | Structured scoring with industry-specific references |
| Training cuts | 10-15% of budget, role-based, starts 6+ weeks early |
If you are planning an ERP implementation or recovering from a troubled one, start with our complete ERP implementation guide for the full methodology. Prevention is always cheaper than remediation — and as the cases above demonstrate, the cost of failure is measured not just in money, but in careers, market position, and organizational trust.
This article is part of the ERP Implementation Guide series. For the full methodology covering every phase from vendor selection to post-go-live optimization, read the complete guide.
