For more than twenty years, industry research has consistently found that the majority of ERP implementations fail to fully meet their original business goals — most studies place the figure between 50 and 75 percent depending on how "failure" is defined. Gartner's most recent research predicts that by 2027, more than 70 percent of recently implemented ERP systems will fall into that category, with as many as 25 percent failing catastrophically. "Failure" in this research covers a range of outcomes — projects that ran over budget, projects that missed deadlines, projects that went live without delivering the expected business value, projects that were quietly written off before going live at all.
The startling thing isn't the number. It's the fact that the number hasn't moved.
Despite enormous improvements in software, in implementation methodology, and in the maturity of the consulting industry, mid-market companies are about as likely to be disappointed by an ERP project today as they were in 2005. Boards know this. CFOs know this. And yet the projects keep happening, and the failure rate keeps holding.
The numbers also tilt against smaller buyers in a particular way: mid-market companies typically spend 3–5 percent of annual revenue on total ERP cost of ownership, compared with 2–3 percent for large enterprises. The financial impact of a struggling implementation lands harder on the company that's least equipped to absorb it.
After thirty years of being involved in these projects — first as a developer building custom systems, then running implementation practices that did this work for hundreds of clients, and now as an independent advisor — I've come to believe that most failures don't trace to technology problems at all. They trace to a small number of decision problems. And almost all of them are entirely preventable.
The pattern is consistent. The failures cluster around three moments: how the platform was chosen, how the implementation was designed, and how the work was monitored. When all three go well, the project lands. When any one of them goes wrong, the math gets ugly fast.
1. The Wrong Platform Was Chosen — for the Wrong Reasons
Selection is supposed to be a structured process: define your requirements, evaluate vendors against those requirements, score the options, pick the best fit.
In practice, selection often runs on a different track entirely. A board member knows someone who runs a SaaS firm. A CFO had a good experience with Vendor X at a previous company. The "evaluation process" that follows is real but cosmetic — the conclusion was reached before the rigor was applied.
Familiarity and relationships are powerful and not unreasonable inputs. But they're poor primary inputs for a decision that will shape your operations for the next decade and cost ten to twenty times the software's annual license over its lifetime.
The pattern I've watched repeatedly: a well-run company adopts a platform whose strengths simply don't align with how their operations actually work. The implementation that follows is technically competent. Go-live is achieved. But the system doesn't fit, and three years later the workarounds and exceptions have quietly accumulated until the team is running their real operations in spreadsheets again.
Preventable by: running selection with someone whose only stake is the right answer; defining requirements before evaluating vendors, not after; and treating familiarity as one factor among many — never the deciding one.
2. The Implementation Reproduced the Existing Process Problems — Faithfully
The most expensive ERP failures I've seen aren't selection mistakes. They're successful selections followed by implementations that take the buyer's existing operational mess and lock it into the new system.
Here's how it happens. A company picks a strong, modern platform. The implementation kicks off. The implementation team asks, sensibly, "show us how you do this today." The team responds — with their actual processes, including the workarounds, the exception cases, the manual steps that exist because someone left in 2014 and nobody questioned the pattern after that. The implementation team configures the new system to match what they were shown.
Twelve to eighteen months later, go-live happens. The new system works. It just works the same way the old system worked, including all the dysfunction that was the reason for replacing the old system in the first place. The clients I've debriefed in this position usually summarize it the same way: "We bought a faster, prettier version of our existing problems."
This is the pattern behind some of the most public ERP disasters of the last decade. Lidl famously abandoned an SAP project after seven years and roughly €500 million in spend — the company insisted on configuring SAP to match its existing inventory data model rather than adapting its processes to the platform, and the customization spiral that followed eventually became impossible to unwind. The same pattern shows up at much smaller scale in mid-market businesses every quarter, with much smaller checks but the same underlying mistake: the implementation faithfully reproduced the operational problems it was supposed to fix.
A great ERP implementation is partly a software project and partly a business process project. The software is the easier half. The harder half — and the one most often skipped — is taking a clear-eyed look at how the business should run going forward, and using the implementation as the moment to actually fix what's broken. Without that work, the new system inherits the old operations, and a multimillion-dollar project produces a faster way to run a broken process.
This is what a real business process review is supposed to do, before configuration begins. Most mid-market projects skip it, do it poorly, or do it as a checkbox exercise driven by the implementation partner who has every incentive to start configuring quickly because that's where the bulk of their fees are earned. The result is predictable: every dysfunction in the existing operation gets carefully embedded into a new platform that's now expensive to change.
Preventable by: doing a true business process review before configuration starts; resisting the impulse to customize the software to match current state; and being willing to push back on internal stakeholders who say "we need it to work the way it's always worked." Sometimes "the way it's always worked" is precisely what the implementation should change.
3. The Warning Signs Were Missed — Because No One Experienced Was Watching for Them
Once an implementation is underway, the project starts speaking a particular language: green-yellow-red status reports, milestone burndown charts, change-order requests, weekly working sessions. Anyone in the room can read the dashboards. Almost no one in the room can read the signals.
What I mean by signals: the things that don't show up on a status report, but that reliably predict serious trouble two or three months out.
A few examples I've watched get mistaken for routine, repeatedly:
-
"The discovery phase is taking longer than expected." Sometimes that's a normal scheduling slip. Sometimes it means the implementation team has uncovered requirement gaps that weren't sized in the SOW and isn't yet ready to surface them. The two situations look identical for several weeks.
-
Change orders that are individually reasonable but cumulatively accelerating. Each one is defended on its merits. The pattern, when you stack them up, can point to the last point just discussed — faithfully recreating the old system and processes.
-
User acceptance testing that "passes" without realistic transaction volumes or a valid mix of every type of transaction being tested.
-
Steering committee reports that stay yellow for two months and never quite escalate to red. Everyone notices. Nobody names it. By the time someone does, three more milestones have slipped.
-
Configuration documents that are long, technically accurate, and almost impossible for anyone outside the implementation team to actually evaluate.
-
Data migration treated as an IT workstream rather than a business workstream — leading to a go-live where the inventory in the new system is wrong on day one. After that, the team has every reason to keep using the spreadsheets they had before.
These aren't subtle problems once you know what to look for. The CFO or COO supervising the project from the buyer's side has the authority but not the time, and rarely has the pattern recognition that comes from having watched a hundred of these go sideways.
Change management failures contributed to many project failures, but rarely arrive announced. They arrive disguised as schedule slips, configuration disagreements, and "minor" customization requests. Catching them early requires someone who's seen the disguise before.
This is the structural reason projects so often go off the rails without anyone catching it until late: there's no one on the buyer's side whose entire job is to watch for the signals. By the time the signals become problems, the problems have compounded for two or three months. Recovery is now expensive, political, and rarely full.
Preventable by: appointing someone on the client side — internal or external — whose explicit job is implementation oversight, with the authority and the experience to actually do it. This person reads the deliverables, attends the working sessions, asks the inconvenient questions in week six instead of month four, and translates between the implementation team's optimism and the client's interests. On smaller projects this can be done part-time; on larger ones it warrants a dedicated role.
A Closing Thought
Each of these causes shows up as a "technology problem" by the time the executive team is paying attention. The system isn't doing what we expected. The project is over budget. The team isn't adopting it.
But the technology is rarely the actual problem. The decisions made before, during, and around the implementation are. And those decisions were preventable.
If you're about to start an ERP project, the most valuable hour you can spend before signing anything is mapping how your organization plans to handle each of these three risks. If you can't articulate clear answers — who owns the selection rigor, who owns the process redesign, who owns the warning-sign watch — that's where to spend the next thirty days. The implementation will go better.
— Mark