By 2007, a three-year ERP implementation had stopped being a warning sign and become a planning assumption. Steering committees approved thirty-six month timelines without argument. Consultancies bid them as standard. Boards signed them because every comparable company was doing the same thing. The cost of that assumption became visible the following year, when Waste Management sued SAP over an allegedly failed implementation, seeking recovery of more than $100 million in project expenses plus the benefits the software had been promised to deliver. The claim later escalated to roughly $500 million before the parties settled in 2010 with an undisclosed one-time payment from SAP. The litigation is worth studying not for who was right, but for what both sides agreed on: the project had been running for years, and the pilot that was supposed to go live in December 2006 was nowhere near ready.
Why Timelines Stretched to Three Years
The long ERP implementation was not caused by slow software. It was the predictable output of five structural choices, each individually defensible. Waterfall sequencing. Requirements were gathered exhaustively, then designed, then built, then tested, then deployed. Nothing reached a user until the end. A twelve-month requirements phase produced a document nobody could validate against working software. Big-bang deployment. Going live everywhere at once avoided the cost of running parallel systems, so it looked cheaper. It also meant no benefit whatsoever until the final day, and an all-or-nothing cutover carrying the full risk of the entire programme. Customisation as the default response to difference. Every gap between the package and current practice was resolved by modifying the package. Each modification added build time, test time, and permanent upgrade cost. Committee governance. Decisions requiring a monthly steering meeting take a month. A programme with two hundred such decisions takes years, most of it spent waiting. Commercial incentives. Time-and-materials contracts paid integrators for duration. Change orders were the profit mechanism. Nobody in the delivery chain was rewarded for finishing early.
What Actually Happens During Thirty-Six Months
The damage is not the calendar. It is what a three-year window guarantees will happen inside it.
- The business changes. New products, an acquisition, a reorganisation, a regulatory change. Requirements written in year one describe a company that no longer exists at go-live.
- The sponsor leaves. Executive tenure is often shorter than the project. The successor inherits a commitment they did not make and cannot easily cancel.
- The team turns over. Consultants rotate, internal experts are promoted, and the reasoning behind early design decisions leaves with them. What remains is configuration nobody can explain.
- Benefits are deferred past the point of relevance. A return that begins in year four fails almost any investment test, and by then the baseline it was measured against has moved.
- Scope creeps in both directions. New requirements are added because the project is the only funded route to change anything, while quietly, testing and training are cut to protect the date. The Waste Management dispute captured this precisely. The vendor argued the customer had failed to define requirements accurately and to supply "sufficient, knowledgeable, decision-empowered users and managers." The customer argued the software had been misrepresented. Both descriptions can be true simultaneously — and in a thirty-six month programme, they usually are, because there is enough time for both failures to develop fully.
Name the decision owner
Give someone authority to resolve choices without another committee cycle.
Configure before customizing
Test the standard process before building an exception into the programme.
Release usable scope
Put a defined slice into production rather than waiting for every module.
Review adoption
Check that people use the working process and adjust the next increment.
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
What Good Programme Governance Looks Like
The organizations that deliver ERP successfully have not found better software. They have removed the conditions that make long projects fail.
- Deploy in increments of ninety to one hundred and twenty days. Every increment must put something into production that a user relies on. If an increment cannot, the plan is wrong.
- Configure first, modify never — until proven otherwise. Require written executive approval for every customisation, with its lifetime upgrade cost estimated and owned.
- Take the standard process unless the difference is genuinely competitive. Most organizations have three to five processes worth protecting, and dozens they defend out of habit.
- Push decisions down. Name a business decision-maker per workstream with real authority. Escalation should be the exception, not the operating model.
- Fix the date, flex the scope. Deadline pressure applied to scope produces prioritisation. Applied to quality, it produces a failed go-live.
- Measure adoption, not milestones. Percentage of transactions processed in the new system is the only status metric that cannot be presented optimistically.
- Make the sponsor's commitment structural. Sponsorship that depends on one individual staying in post is a single point of failure on a multi-year programme.
The Test That Predicts Failure
Ask for the date of the first production go-live, for any part of the business, however small. If the answer is more than six months away, the project is carrying schedule risk that no governance process will contain. A long ERP implementation is not a sign of ambition. It is a sign that the programme has been designed so that nobody has to be right about anything until it is far too late to correct.
Common Questions
Why do ERP implementations take so long?
Mostly by design: sequential waterfall phases, big-bang cutovers, heavy customisation, slow committee decision-making, and commercial models that reward duration. The software itself is rarely the constraint.
Are phased rollouts really less risky than big bang?
Yes, in almost all cases. Phasing produces working software early, surfaces integration and data problems while they are still cheap, and limits the blast radius of any single failure. The trade-off is temporary interface complexity between old and new systems.
What is the biggest driver of ERP cost overruns?
Customisation, followed by data migration. Both are systematically underestimated, and both compound: modifications increase testing and upgrade cost permanently, while poor data quality is usually discovered late and delays cutover.
How do you keep an ERP programme honest?
Short increments with production releases, adoption-based status metrics, written approval for every deviation from standard, and a named business decision-maker per workstream. Governance is about decision speed, not meeting frequency.
Implementation Timeline Review — Outpace reviews your ERP plan against the failure patterns that produce multi-year overruns, re-sequences delivery into production increments, and tests whether your governance can make decisions at the speed your schedule assumes.