Why do ERP Projects Fail?

Updated July 2026.

ERP projects fail when the organization around the software is unprepared, not when the code breaks. The same five causes recur: poor vendor fit, excessive customization, weak training and adoption, budget and scope overrun, and evaluating only one vendor. Every one of them is a decision made before go-live.

In the world of enterprise resource planning projects, mistakes, setbacks, additional cost and failure are commonplace — but so is success, greater efficiency and huge rewards. What separates the two is rarely the software brand. It is almost always what the business did, or failed to do, in the months before anyone logged in.

To learn about real life ERP implementation case studies, download our case study report below, covering ERP implementations such as Nike, Lidl, Hershey and more:

How often do ERP projects actually fail?

You will find a lot of confident-sounding percentages on this question. Most of them are worth less than they look — they get repeated from blog to blog until the original source is untraceable, and the figure you end up quoting to your board has no report, no year, and no methodology behind it. We removed one such statistic from this page for exactly that reason. So here is what can actually be substantiated.

The honest answer is that it depends entirely on how you define failure. Outright abandonment — walking away from the software altogether, as Lidl and LeasePlan did — is relatively rare, in the low single-digit to low-teens percent range. "Failure" measured as missing the original budget, timeline, or expected benefits is far more common. Those are very different questions, and quoting a single number for both is how the folklore starts.

The most recent primary survey data comes from Panorama Consulting Group's 2026 ERP Report, based on 170 respondents surveyed between January 2025 and January 2026, with a median annual revenue of $200.5M and a median project timeline of nine months. It found:

• More than a quarter of organizations reported their project was over budget. The most common reason was the unexpected need for additional technology — which the report attributes to poor system selection, where organizations discover fatal misfits late and bolt on extra tooling to compensate.
• Almost a quarter reported their project was over schedule. The most common reason was organizational issues: governance, resistance to change, and process redesign.
• Most benefit categories were realized by over half of the respondents who anticipated them, with productivity and efficiency benefits the most commonly achieved.

Treat that as one self-reported survey of a particular sample rather than a universal law — respondents skew toward mid-market organizations running relatively short projects, and self-reporting flatters everyone. But note how far it sits from the "most ERP projects fail" folklore. The failures that dominate headlines are real, but they are the tail of the distribution, not the median.

That tail is worth studying precisely because it is so well documented. These four are the most thoroughly reported ERP failures in history:

• Hershey (1999) — a big-bang cutover of SAP R/3, Manugistics and Siebel rushed into the peak Halloween season broke order-to-cash. Hershey could not deliver $100M+ of confirmed orders despite having the inventory in the warehouse; quarterly profit fell around 19%.
• Nike (2000) — an i2 demand-planning deployment with inadequate testing and over-reliance on automated forecasts over-ordered some products and under-ordered others. Nike attributed roughly $100M in lost sales to it, and the stock fell about 20%.
• Revlon (2018) — a botched SAP S/4HANA cutover disrupted manufacturing badly enough that orders went unfilled: $64M in lost sales and a 6.9% one-day stock drop.
• Lidl (2011–18) — seven years and roughly €500M written off when a SAP-based merchandise system (eLWIS) was scrapped, largely because Lidl valued inventory at purchase price where the software assumed retail price, and chose to bend the software rather than the process.

Not one of those was a software defect. Each was a decision about timing, testing, scope or process fit. We break all of them down, with sources, in our ERP implementation failure case studies.

The five reasons ERP projects fail

More often than not, failure traces to the same handful of mistakes — made by consultants, by vendors, and by the business itself. Here they are at a glance, with the warning sign that tells you it is happening to you.

Each one is unpacked below.

1. The wrong ERP vendor or partner was chosen.

Despite the impressive demos, snazzy dashboards and marketing videos, the ERP solution didn't quite live up to what was sold when it came to project kick-off and implementation. Sometimes ERP software is oversold and demos are full of smoke and mirrors, suggesting the technology is capable of more than it can deliver.

However, it isn't always the fault of the ERP vendor. Often businesses fail to capture, document and communicate their business requirements in the first place. This is usually due to poor planning in the early stages of the ERP evaluation and comparison process. A demo can only be judged against a standard — and if you haven't written the standard down, you are judging theater.

We also often see organizations get swayed by politics. A board member used a particular system at an FMCG company, so naturally they think it will work for a professional services business too. With every ERP solution catering to different markets, geographies, industries and company sizes, it's critical to run an independent selection process for your own business.

The warning sign: you cannot trace a feature you saw in a demo back to a numbered line in a requirements document. If the requirement doesn't exist on paper, it will not exist in the contract, and it will become a change request later at your expense.

By the time this surfaces it is usually too late to rip up the contract and start again. It's rare that the ERP software vendor will let you — instead you'll be footing the bill, taking your vendor or partner to court, or simply living with it. Notably, Panorama's 2026 data found the single most common cause of budget overrun was needing extra technology to fill gaps the selection process missed. Choosing badly doesn't just cost you fit; it costs you budget.

How do you avoid choosing the wrong ERP?

Research the market thoroughly and speak to an unbiased external consultant with knowledge of all Tier 1 and Tier 2 solutions. Ensure the system — whether cloud or on-premise — meets your functional requirements by comparing several options side by side rather than evaluating one in isolation. Score every shortlisted vendor against the same written criteria, weight the criteria before you see the demos, and insist that anything you're promised is captured in the requirements document rather than in a slide.

2. You wanted everything your way.

"Most important of all, and the single biggest failure point for ERP implementations, is the need for change management. The need for change management is not likely to be recognized until it is too late."

— Neville Turbit, ERP Implementation: The Traps, Project Perfect white paper, 2005

Twenty years on, that observation still describes most of the failures on this page. Generally speaking, modern accounting and enterprise resource planning systems should dictate the way you run the majority of your processes — unless a process is a genuine competitive differentiator with a return attached.

Many solutions come out of the box with mature processes across financial management, inventory, procurement, supply chain, project management and more. Long gone are the days when an army of consultants charged $2,000 per day to recreate the wheel, building procure-to-pay or lead-to-cash from scratch to custom specifications. Sure, your systems integrator can make it work the way you've always worked — but that will cost you time and money, and it will cost you again at every upgrade.

Lidl is the cautionary tale here. Its practice of valuing inventory at purchase price clashed with SAP's standard model of valuing stock at retail. Rather than adapt the process, Lidl tried to bend the software — and wrote off roughly €500M after seven years.

The warning sign: change requests start arriving before the first phase is live. Customization is unavoidable, but do it where it really counts. The test is simple: if a process doesn't win you customers or margin, it is not worth customizing for.

3. Bad training and end-user adoption.

Embarking on an ERP project can be tough. You have to assemble large internal and external teams, sit through endless meetings, battle setbacks and manage deadlines.

But don't forget that once the system is perfectly configured, you need to actually train people to use it. You also need to generate internal excitement to encourage employees to embrace the change. Otherwise they'll quickly start telling others in the business that it doesn't work properly as you roll out. Before you know it, the project — and you — will be labeled a failure.

Despite this, many organizations get caught up in objective goals and milestones and forget the most important catalyst for change: their people. Without employees adopting the system and learning to use it to its full potential, your ERP project is bound to fail. An ERP project is much more than an IT project. The system will not run your business on its own; you need people to augment technology and vice versa.

This is not a soft concern — it is the measurable one. Panorama's 2026 report found that where projects ran over schedule, the most common cause was organizational: governance, resistance to change, and process redesign. The technical work often lands on time. The approvals, sign-offs and cross-functional alignment are what slip.

The warning sign: the first time most end users hear about the new system in any detail is at user acceptance testing. If training is a line item scheduled for the month before go-live, it is already too late.

Learn more about ERP change management in our detailed explainer.

4. You ran out of budget.

Sure, the systems integrator quoted you $250,000 and said it would take five months. Here you are six months later and $100,000 over budget. The lesson is to thoroughly vet your partner's assumptions — and your own — before you even talk to potential vendors, or risk a nasty surprise.

Many organizations fail to properly communicate their needs during an implementation. That can be survivable, but only if your organization is then able to adopt the standard processes the chosen system dictates. More often, organizations fail to document requirements properly, then ask their implementation partner to customize the solution to their needs. This creates significant technical debt and setbacks. And your implementation partner will usually be happy to approve those change requests, adding more days and more cost.

Budget overruns are almost always scope overruns wearing a different costume. Pin the scope down on paper before contracts are signed — our ERP implementation project plan template walks through the structure a defensible plan needs, so change requests stop becoming surprises. Benchmark your numbers against a realistic ERP implementation cost breakdown rather than the first quote you receive, and hold a contingency you actually expect to spend.

The warning sign: scope exists in conversation but not in a signed document. If you cannot point to the page that says what is in and what is out, every disagreement will be resolved in the supplier's favor.

5. You only review one vendor.

Your CFO said this system worked at his last company. The reviews were good. Nobody gets sacked for choosing that vendor. There's an exception to every rule, particularly when you're dealing with something as complex as an enterprise resource planning project.

A single-vendor process removes the only real leverage you have. Competitive tension is what surfaces the honest answers — the gaps a vendor will admit to when they know a rival is being asked the same question, the discount that only appears when the deal is genuinely contested, and the implementation assumptions that get firmer when someone else's estimate is on the table. With one vendor, every one of those conversations is a monologue.

It also removes your reference points. When you have three proposals scored against the same weighted criteria, an outlier is obvious. With one, you have no idea whether the timeline is ambitious or the price is high, because you have nothing to compare it against.

The warning sign: the decision is being justified by who used the system before, rather than by how it scores against your requirements. Shortlist at least three, score them identically, and make the vendors compete — using the same ERP selection criteria for each.

Get ERP Project Ready

Every failure on this page traces back to a decision made before go-live: a requirement that was never written down, a process nobody was willing to change, a training budget that got cut, a scope that lived in conversation instead of a contract, or a vendor chosen because someone in the room already liked them. None of those are software problems, which is the good news — they are all things you control.

The protective pattern is consistent across every well-run program we see:

1. Document requirements before you shortlist. Start with a structured ERP requirements template so every vendor is answering the same question, and so anything you're promised in a demo has somewhere to live.
2. Choose software whose standard processes already fit. Customize only where a process genuinely wins you customers or margin.
3. Compare properly. Score at least three shortlisted systems against weighted criteria you set before the demos begin — you can compare ERP systems side by side to build that shortlist.
4. Plan the go-live away from peak trading. Hershey and National Grid both show what happens when cutover timing is treated as an IT scheduling detail rather than an executive decision.
5. Fund change management and training as a first-class workstream, not the contingency everyone raids when the build runs late.
6. Work the details. Our ERP implementation checklist covers the tasks most programmes discover too late.

To find the right technology, ensure end-user adoption, nail your budget and control expectations, start by building your requirements in the ERP Requirements Wizard — it's free, vendor-neutral, and produces a document you can send straight to shortlisted vendors.

Frequently Asked Questions

What percentage of ERP implementations fail?

There is no credible single number, and you should be skeptical of anyone who offers one. It depends entirely on how you define failure. Outright abandonment — scrapping the software, as Lidl did — is rare, in the low single-digit to low-teens percent range. Budget and schedule overruns are far more common: Panorama Consulting Group's 2026 ERP Report, a survey of 170 organizations, found more than a quarter of projects ran over budget and almost a quarter ran over schedule. That is well below the "most ERP projects fail" folklore. Many widely-quoted failure rates — including ranges often attributed to Gartner — cannot be traced back to any named report, year, or methodology, so treat them as hearsay unless someone can show you the source. The documented disasters are real and expensive: Hershey ($100M+, 1999), Nike ($100M, 2000), Revlon ($64M, 2018) and Lidl (~€500M, 2011–18). But they are the tail of the distribution, not the median outcome.

Why are ERP systems so difficult to implement?

Because an ERP implementation is a business change program wearing an IT project's clothes. The software touches finance, supply chain, procurement, HR and operations simultaneously, so it forces every department to agree on definitions and processes they have historically been free to handle their own way. That negotiation — not the configuration — is the hard part. Add to it the need to migrate years of inconsistent legacy data, retrain staff who are already busy, and keep trading throughout the cutover, and the difficulty is organizational rather than technical. This is why Panorama's 2026 data found organizational issues — governance, resistance to change, process redesign — were the most common cause of schedule overrun.

How do you avoid ERP implementation failure?

Do the unglamorous work before you sign anything. Document your requirements in detail and get stakeholders to approve them, so vendors are scored against a written standard rather than a demo. Shortlist at least three systems and score them against weighted criteria set before you see any presentations. Choose software whose standard processes fit your business, and customize only where a process is a genuine competitive differentiator. Migrate clean, reconciled data rather than dumping legacy records. Phase the go-live by site or module instead of a big bang, and schedule it away from your peak trading period. Fund training and change management as their own workstream with its own budget that cannot be raided when the build runs late. Finally, pin scope to paper before contracts are signed — every budget overrun on this page began as an undocumented scope assumption.

What is the most famous ERP failure?

Hershey's 1999 SAP R/3 implementation is the most frequently cited. A rushed big-bang go-live of SAP, Manugistics and Siebel, timed just before the Halloween and Christmas seasons, broke order fulfilment and left more than $100M of confirmed orders undelivered despite stock sitting in the warehouse. Quarterly profit fell around 19%. Lidl's roughly €500M abandoned SAP program and Nike's $100M supply-chain failure are the other two most-cited examples.