Risk management

Why More Than 80% Of ERP Projects Fail

Nike wrote off $100 million. National Grid's month-end close went from 4 days to 43. The technology was not the problem in any of these cases. Here is what actually went wrong, and how to make sure it does not happen to you.

Get a Risk Review The Executive Guide

80%+

of implementations fail to deliver what was promised

25

years, and the rate has not improved

$1B+

spent on the single largest failure on record

#1

cause in disputes: the people side, not the software

The software almost never fails. The organization does.

Modern ERP systems are mature, capable and well tested. When a project collapses it is almost always because the business processes were never defined, or because the people who had to change the way they work were never brought along. Technology is the easy part. People do not like to change, and no amount of software solves that.

Ask these before you sign the contract

Who owns this on the business side, by name?
Which process are we changing first, and why?
What happens if the go-live date arrives and the data is not ready?

The recurring pattern

The Same Handful Of Mistakes, Every Time

Look closely at any failed rollout and the cause is rarely a bug. It is a process nobody mapped, a sponsor who disappeared after kickoff, or a go-live date fixed before the data was ready.

Root causes

Five Reasons Projects Go Wrong

These five explain the overwhelming majority of failed implementations, and every one of them is decided before a single line of configuration is written.

Unrealistic expectations from day one

A timeline nobody could have met. Halfway through, reality hits and the team starts cutting whatever looks optional, which is almost always testing and change management.

Pressure-test the vendor timeline against your real available resources before you sign.

Rushing past the planning phase

Excitement peaks the day you pick the software, so teams jump straight into building. The questions they skipped get answered later, expensively, mid-implementation.

Run a short planning phase after selection and before implementation. It pays for itself many times over.

No clear executive vision

"Our old system is dying" is a reason to act, not a vision. Without one, hundreds of project decisions get made by whoever is in the room.

Agree as a leadership team what the company should look like after go live, in specific terms.

Neglecting the people side

The single most common pattern in ERP disputes that reach court. The technology worked; the organization never adopted it.

Budget change management as a real workstream, not as a training session in the final month.

No definition of success

If nobody wrote down what value this project must deliver, nobody can tell whether it did, and no one can be held to it.

Define the business case up front and measure against it during and after go live.

Case studies

Ten Of The Most Expensive ERP Failures

These are public cases, documented in financial filings, lawsuits and regulatory reports. Every one of these companies had a large budget and a well-known implementation partner. Neither saved them.

US Navy

Government / DefenseOver $1 billion

Spent over a billion dollars since 1998, cut the scope down to financials only, and oversight reports still found no material improvement. Scale and budget do not buy success.

National Grid

UtilitiesOver $1 billion

Period-end close went from 4 days to 43 days after go live, roughly 15,000 supplier invoices could not be processed, and $30 million a month was being spent just to stabilize the system.

Nike

Consumer Products$400 million

Wrote off around $100 million and the share price fell roughly 20%. It then took another five years and another $400 million to get the program back on track.

Revlon

Consumer ProductsUndisclosed

The failure was disclosed in an SEC filing and the stock dropped about 7% the next day. A plant could not ship product, and they were implementing while absorbing an acquisition.

MillerCoors

Beverages~$100 million

Ended in a $100 million lawsuit against the system integrator. A reminder that a big-name partner is not by itself a guarantee of anything.

Hershey

Food~$100M in orders

Compressed the timeline unreasonably, then went live right before the busiest holiday season. Around $100 million of orders could not be processed.

Waste Management

Services~$100 million

Promised annual benefits of $100–200 million that never materialized, and litigation followed alleging the demonstrated software was not what was actually delivered.

Hewlett-Packard

Technology$160 million

Damages reached roughly five times the project cost. Their own CIO described a series of small problems that individually were manageable but together created a perfect storm.

Washington Community College

Education$13M lawsuit

The implementation partner went bankrupt mid-project, the successor cancelled the work and then sued the college. Partner risk is real risk.

Haribo

Food~25% sales drop

Could not track raw materials or get stock to stores after go live, and sales fell roughly a quarter. Supply chain readiness is not a detail.

These figures come from public financial filings, court records and government oversight reports. They are included here as industry case studies, not as any comment on the vendors or partners involved.

Prevention

Eight Things That Keep You Off This List

You are far more likely to face a quieter failure than a headline one: a system that goes live, technically works, and never delivers the value you paid for. These eight habits prevent both.

Choose software that fits, independently

Evaluate against your own prioritized requirements, not against a sales demo, and get an opinion from someone who does not sell the software.

Choose the partner as carefully as the software

Several of the biggest failures on record involved the best known integrators in the world. Check the specific team, not the logo.

Stay in charge of your own project

It is your business being changed. If the partner is not working, correct course early rather than hoping it improves.

Price the cost of disruption

Work out what a month of not shipping or not invoicing costs you. That number usually justifies spending more, not less, on doing it properly.

Decide your processes before the software does

If you do not define how the business should run, the default configuration will define it for you.

Test properly, with real users

Nearly every failure on the list above would have been caught by serious user acceptance testing against end-to-end processes.

Keep executives genuinely involved

Not a monthly status slide. Leadership has to make the trade-off decisions and know the real risks.

Get independent risk review

The people building the system are not the right people to audit whether it is going well.

Warning signs your project is already in trouble

Failures are rarely sudden. By the time a project collapses publicly, the signals have usually been visible for months. If you recognize several of these, act now rather than at go live.

Nobody can state the project's business case in one sentence
Change management was cut to protect the budget
Testing keeps getting shortened to protect the date
The partner's status report is the only view of progress
Go live is scheduled during your busiest season
Data cleaning has not started and go live is near
End users have not seen the system yet

The Hershey lesson

Hershey compressed an already tight timeline, then chose to go live immediately before its busiest holiday season. Roughly $100 million of orders could not be processed.

Go live timing is not a scheduling detail. It is one of the highest-impact risk decisions in the entire project, and it belongs to the executive team, not the project plan.

Frequently asked questions

What counts as a failed ERP implementation?

Rarely a system that never switches on. Far more often it is one that goes live late, costs far more than planned, disrupts operations, or works technically while delivering none of the business value that justified it.

Does choosing a bigger vendor reduce the risk?

The list above is made almost entirely of large enterprises with major vendors and world-renowned integrators. Size correlates with budget, not with success. What matters is the fit of the software and the quality of the specific team assigned to you.

We are mid-way through a struggling project. Is it too late?

Usually not, but the window narrows as go live approaches. An independent review of scope, data readiness, testing and user adoption will normally show whether you should delay, reduce scope, or change how the project is being run. Pushing ahead on hope is the expensive option.

Why is change management always the first budget cut?

Because it is the line whose absence causes no immediate pain. Servers not configured stops the project today; people not prepared only shows up at go live. By then the cost is operational disruption, which is far larger than the saving.

How do smaller companies avoid these mistakes?

By starting narrow. A first phase covering two or three modules, done properly and adopted fully, beats an enterprise-wide rollout that stalls. Smaller companies actually have an advantage here: decisions are faster and there are fewer people to bring along.

Find the risks before they find you

Whether you are about to start or already mid-project, an independent review of scope, readiness and adoption is the cheapest insurance you will buy.

Get a Risk Review ERP Implementation Guide

ERP Implementation Guide: Models, Workstreams & Phasing

A practical guide to ERP implementation models, program workstreams, phasing and typical costs.

ERP for Executives: Business Value, Not Just Software

What executives need to know about ERP: business case, governance, costs and the value it unlocks.