Why ERP Programs Almost Never Fail for Technical Reasons

This article is the first of three in the series "The Real Point of Failure" — the opening part of a larger body of work on ERP strategy and implementation, on why programs really fail and what a structure that holds actually looks like.

When an ERP program goes off the rails, the first instinct is to open the hood and look at the engine. Audit the architecture. Review the interfaces. Question the configuration, the data model, the integration layer. Someone runs a technical health-check, the report comes back with a list of things to fix, and it all feels rigorous. It feels like progress.

It almost always misses the point.

I've spent ten years inside SAP programs, as a consultant, as a team lead, as the functional integrator who reads the code and not just the slides. Across three international S/4HANA rollouts and the projects before them, I've watched programs with genuinely good technical teams fail anyway, and I've watched ordinary teams deliver. The thing that moved the outcome was never the technical skill in the room. It was the quality of the decisions made around it.

Here's the way I've come to see it. Technical skill is the oil in the engine, not the engine. Run low and the engine strains harder to move, sure, but the oil was never what made the car go. The engine is the governance of the program: who decides what, when, and against whom. Pour in all the oil you want. A seized engine still won't turn.

Why this is more true now than it used to be

So why does everyone still treat technical expertise as the engine? Recent history, mostly. When ERP exploded twenty years ago, and SAP with it, the skills available in the market couldn't keep up with the demand. Expertise really was the bottleneck. If you couldn't staff the skill, the program stalled, and that was that. A whole generation of leaders learned to see the technical layer as the thing that makes or breaks a rollout. The reflex stuck around long after the conditions that justified it had gone.

And they have mostly gone. The workforce went global, search engines got good, SAP's own documentation got a lot better, and now there's AI that will walk you through a problem at two in the morning. A team missing a specific competence can close that gap far more easily than it could a decade ago. I'm not saying expertise is worthless. It compounds, and the best people are still worth their weight. I'm saying it stopped being the binding constraint. When the technical gap is the easiest thing to close, it stops being the thing that decides how the program ends.

So if the oil is cheap and everywhere now, where is the failure actually coming from? A McKinsey study with Oxford, looking at more than 5,400 large IT projects, found they delivered on average 56% less value than promised, against a time overrun of just 7%. Read that again. The schedule mostly held. The value didn't. That's not a project-management failure, the kind you fix with a tighter plan and a better Gantt chart. It's a failure of what got decided before the work began. (The study is from 2012, so treat the exact figure as directional rather than fresh, but the shape of it matches everything I've seen on the ground since.)

Why the technical layer takes the blame anyway

The technical layer is the convenient suspect, and it's worth being honest about the three reasons why, because they're exactly what keeps the misdiagnosis alive.

It's visible, first of all. A broken interface, a failed load, a report spitting out the wrong number. These are concrete, you can measure them, and they show up on a screen in front of you. A governance failure doesn't show up on any screen. It shows up as a decision someone made, or quietly didn't make, in a meeting a year and a half earlier.

It's also reassuring. A bug can be fixed. If the problem is technical then it's bounded, and someone can be put on it. "The program failed because of a flawed arbitration structure" is a much harder sentence to say out loud than "there's a bug in the layout of this program."

And then there's the reason almost nobody says out loud: the technical layer is often the only place around the table where no one present is implicated. The dev team leader, as we all know, is rarely sitting at the governance table. Which is where the real mechanism lives.

Where the failure actually happens

Let me tell you about a program I worked on at a large systems integrator. The technical teams were good. Genuinely good, people who knew SAP cold and could see a risk coming from a long way off. That's not where it broke.

It broke in the balance of power. The business carried more weight than the program leadership, for one structural reason: the budget came from the business side. And when the money sits on one side of the table, that side wins every disagreement that matters. Not by argument. By gravity.

It played out the same way again and again. The solution teams would flag a serious technical risk and propose an alternative, one that still met the business need without torturing the system to get there. The business would push back, because they wanted the bespoke thing they'd asked for in the first place. And because the business held the purse, the business got the bespoke thing. Every time the risk got weighed against the requirement, the requirement won. Not because it was the better call. Because of who was paying.

Here's the part that matters most. There was an arbitration committee. The governance existed on paper, all of it. It just couldn't function, because it had no power to rule against the side holding the budget. The committee was theater. The real decisions were made by the structure sitting underneath it.

And the bill came due later, the way it usually does. The over-tailored solution went into production and didn't behave the way the business had expected. What got asked for as a bespoke requirement at month two came back as a rework project at month six, wearing a technical costume. Anyone looking at it by then called it a technical problem. It was nothing of the sort.

I want to be careful here, because this is easy to get wrong: it isn't a story about the business being the villain. The business was doing what businesses do, fighting for what they believe they need. The failure was that the governance never built a counter-power that could weigh technical risk at parity with business demand. The arbitration that should have done that job was disarmed before it ever sat down. I'll get into concrete solutions in a later piece, Governance Is Not a Committee, It's a Decision Chain.

Why the gap between cause and symptom fools everyone

Look at the timeline. The decision that doomed the workstream got made at month two. The symptom turned up at month six, on a developer's screen. Those few months between cause and consequence are the structural reason the misdiagnosis is so reliable. By the time the pain is visible, the decision that caused it is buried under a hundred decisions that came after, often made by people who've already rolled off the program. The eye lands on the symptom because the cause is out of frame.

Why governance escapes the audit

There's a deeper reason governance rarely makes it into the post-mortem, and it has nothing to do with the timeline. It's a conflict of interest, built right into who runs the review.

In a large organization, the people auditing the failure are very often the same people who owned the decisions. A program director can't easily stand up in a post-mortem and conclude, in front of everyone, that the failure traces back to their own chain of decisions. That's not a character flaw. It's an impossible spot to put a person in. So the review goes where it can safely go, which is the technical layer, the one terrain where no one in the room is on the hook. The audit points at the oil, at the missing skills, and leaves the engine, the governance, out of the analysis entirely.

If you actually want to know why a program failed, the people who ran it can't be the ones reviewing it. The review has to come from outside the chain of command, from someone with no stake in the verdict. Almost no organization does this, which is exactly why the same failures keep repeating with the same official explanations attached.

The question that re-frames everything

So here's the diagnostic reflex I'd hand any CIO watching a program drift. When something surfaces as a technical problem, don't stop at the symptom. Ask one question:

What decision, made or not made, turned this into a problem that was even possible?

Follow that question honestly and most of the time the trail doesn't end in the code. It ends in a room, at a particular moment, where someone decided something. Or where the structure decided it for them.

If that's right, then the lever a CIO actually controls isn't the tool, and it isn't the integrator with the glossiest technical references. It's the quality of the decision chain they build before the technical work ever starts, and whether the arbitration inside it has the power to rule or is just theater stretched over a budget.

Which leaves the question the rest of this work is about: what does a governance that actually decides look like? Everyone has a steering committee. Almost no one has a chain of decision that holds. That's where the next article goes: Governance Is Not a Committee, It's a Decision Chain.