ERP Implementation: Avoiding the Most Common Failures

Why ERP implementations fail at alarming rates, and what operations leaders can do differently to protect implementation success, timelines, and budgets.

2025-09-1513 min read

The ERP Implementation Risk Landscape

Enterprise Resource Planning implementations are among the most consequential operational projects a company undertakes and among the highest-risk. Industry research consistently finds that 50–75% of ERP implementations run over budget, over schedule, or fail to deliver the expected business benefits. A subset—estimated at 10–15% of major implementations—are abandoned entirely after significant investment, producing write-offs that can reach into the hundreds of millions for large enterprise implementations. The risk is not hypothetical. The ERP implementation failure case study library includes cautionary tales from Hershey, Nike, Waste Management, Lidl, and dozens of less-publicized organizations across every industry. The common threads in these failures are not technical—ERP software is mature, proven technology—they are organizational: inadequate executive commitment, scope management failures, underinvestment in change management, and the systematic underestimation of the data quality work required to migrate from legacy systems to the new platform. COOs who approach ERP implementation with the expectation that the software vendor or implementation partner will manage the majority of the risk have misunderstood the risk allocation of these projects. The implementation partner brings methodology, configuration expertise, and project management. The client organization—under the COO's leadership—must supply business process clarity, data quality, stakeholder alignment, change management investment, and decision-making speed. In most failed implementations, the client organization failed to provide these inputs at the required level, not the implementation partner.

Scope Management: The Discipline That Saves ERP Projects

Scope creep is the most common and most damaging failure mode in ERP implementations. The project begins with a defined scope—the modules to be implemented, the business processes to be covered, the integrations to be built. As the project progresses, additional requirements surface: a business unit that was out of scope requests inclusion, a legacy process that the standard ERP configuration does not support generates a customization request, a stakeholder who was not engaged in scoping identifies a requirement that was missed. Each individual addition appears reasonable; collectively, they transform a manageable implementation into an unmanageable one. The governance mechanism for scope management is a formal change control process: any addition to the original project scope must be documented, assessed for impact on timeline and budget, approved by the project steering committee, and funded through the project budget or a formal budget amendment. This process creates visibility into the cumulative impact of scope additions before they have already been committed to, and it creates an accountability mechanism that prevents individual stakeholders from unilaterally expanding scope without organizational approval. The philosophy underlying rigorous scope management is not rigidity for its own sake. It is the recognition that a successful implementation of a defined scope is dramatically more valuable than a failed implementation of an expanded scope. Organizations that defer additional requirements to Phase 2 of the implementation—following a successful Phase 1 go-live—accumulate far more benefit than those that attempt to implement everything at once and produce a delayed, over-budget, quality-compromised system.

Data Migration: The Overlooked Critical Path

Data migration is consistently the most underestimated element of ERP implementations. The technical work of extracting data from legacy systems, cleansing it to meet ERP data quality requirements, transforming it into the target data model, and loading it into the new system is complex, time-consuming, and dependent on organizational investments in data quality that many companies have not made. The data quality challenge is acute because ERP systems enforce data integrity rules that legacy systems do not. A legacy system may tolerate duplicate customer records, incomplete vendor master data, or inconsistent chart of accounts coding; an ERP will reject or misprocess the same data. Before migration can occur, the source data must be assessed, cleansed, and often rationalized—a process that requires significant investment in business user time (the people who know whether a given customer record is active or duplicate), data engineering capability, and management of competing priorities for the business users being asked to participate. The practical recommendation is to begin the data migration workstream at project initiation, not after the system is configured. A parallel-path approach—configuring the system while simultaneously cleansing and preparing migration data—is the only way to avoid the situation where the implementation is on schedule from a configuration perspective but cannot go live because the data is not ready. Projects that discover the data quality gap in the final 60 days before planned go-live are the ones that produce the headline-making delays.

Change Management: The Human Side of ERP

ERP implementations change how people do their jobs. The system enforces new processes, requires new data entry practices, and often eliminates the workarounds and manual interventions that employees have developed over years to adapt a deficient legacy system to the actual demands of the business. Without deliberate change management investment, this disruption produces resistance, workarounds in the new system, and the systematic undercapture of the efficiency gains that justified the implementation. The change management investment for an ERP implementation should be proportionate to the scope of the process changes involved. A rule of thumb used by experienced implementation practitioners: change management investment (in budget and resources) should be at least 20–30% of the total implementation investment. Organizations that allocate 5% of their ERP budget to change management and the remaining 95% to software licensing and technical implementation are misallocating against the actual risk profile of the project. Training is the most visible component of ERP change management but is frequently the most inadequately executed. Generic training delivered in a classroom setting weeks before go-live produces knowledge that decays rapidly in the absence of practice. Role-specific training—focused on exactly the tasks a given employee will perform in the new system, delivered close to go-live and reinforced through a hypercare period of intensive support during the first 30–60 days in production—is the training model that produces lasting capability.

Governance: The Project Structures That Determine Outcomes

ERP implementation governance structures—the decision-making bodies, accountability frameworks, and escalation paths that govern the project—are the organizational infrastructure within which all other project activities occur. Governance failures are implicated in the majority of large ERP implementation failures, typically manifesting as inability to resolve cross-functional disagreements about process design, inability to make configuration decisions within required timeframes, or inability to hold the implementation partner accountable for deliverable quality and schedule performance. The governance framework for a major ERP implementation should include: an Executive Steering Committee (ESC) composed of C-suite executives who meet monthly to review project health, resolve escalated issues, and maintain strategic alignment; a Project Management Office (PMO) that maintains the project plan, tracks issues and risks, manages the budget, and coordinates across workstreams; functional workstream leads who own the business process design and configuration decisions within their domain; and a Change Advisory Board that reviews and approves scope change requests before they reach the Steering Committee. Executive engagement is the most important and most commonly deficient governance input. ERP implementations that are delegated to the IT function, the implementation partner, or a project manager without genuine executive ownership consistently underperform those where a C-suite executive—typically the COO or CFO—is personally accountable for implementation success, attends steering committee meetings consistently, and is willing to make the hard decisions about scope, resource allocation, and organizational change that the project will inevitably require.

Frequently Asked Questions

How long does a typical ERP implementation take for a mid-size company?

For a company with $50M–$500M in revenue implementing a tier-1 or tier-2 ERP system across core modules (finance, procurement, inventory, manufacturing or fulfillment), a realistic timeline is 12–24 months from project kick-off to go-live. Timeline estimates below 12 months for a multi-module, multi-site implementation should be treated with skepticism unless the scope is unusually constrained. The majority of timeline overruns are attributable to scope creep, data quality issues, and change management deficits rather than implementation methodology failures.

Should we implement "vanilla" ERP or customize for our specific processes?

The consensus among experienced ERP practitioners has shifted decisively toward vanilla (standard configuration) implementations, with significant customization reserved for genuinely differentiating processes that cannot be adapted to standard ERP workflow. The reasons are practical: customizations increase implementation cost and timeline, create technical debt that complicates future upgrades, and eliminate the productivity improvements that come from adopting industry-standard processes embedded in the ERP design. The discipline of asking "can we adapt our process to match the ERP standard?" before requesting a customization is one of the most value-preserving practices available to implementation leadership.

How do you choose between cloud SaaS ERP and on-premise ERP for an operations-intensive business?

The trend toward cloud SaaS ERP is strong for most business contexts, and the argument for on-premise deployment has narrowed to situations involving unique security requirements, regulatory mandates for data sovereignty, or highly specialized manufacturing processes that are inadequately supported by available SaaS solutions. For most growth-stage and mid-market companies, cloud SaaS ERP provides faster time-to-value, lower total cost of ownership over a 5-year horizon, and a continuous upgrade path that eliminates the costly version-upgrade projects that characterized on-premise ERP management.

The Crimson Bench · Est. 2002 · Founded in New York City

Deploy an Executive in 48 Hours

Verified corporate accounts only. Ivy League-educated. Flat-rate pricing. 14-day no-cause cancellation.

Deploy Now →Start with a $1,500 Diagnostic

25,000+ Ivy League Executives · 150,000+ Global Consultants · 48-Hour Deployment