Governance Is Not a Committee, It's a Decision Chain

This article is the second of three in the series "The Real Point of Failure." The first, "Why ERP Programs Almost Never Fail for Technical Reasons," made the case that programs break in the decision chain, not in the technology. This one shows what a chain that holds is built from.

Everyone has a steering committee. Almost no one has a chain of decision that holds.

Here's the uncomfortable part. A governance committee can be perfectly assembled on paper, with the right people, the right cadence, a clear mandate written into the program charter, and still be theater. Having a committee was never the question. The question is whether it can actually rule against the people who don't want to hear "no." Most can't. And the reasons they can't are structural, which is genuinely good news, because structure is something a CIO can design before the program starts.

Let me show you what breaks it, then the three things that fix it. None of this is theory. I've watched the same setup fail in one place and hold in another.

The committee that couldn't decide

In the program I described last time, at a large systems integrator, the governance existed in full. There was an arbitration committee. It met, it had a mandate. It just had no power to rule against the side holding the budget, because the business funded the program and therefore won every disagreement that mattered. The committee wasn't weak because the people on it were weak. It was weak because of who sat on it and what they were attached to.

The failure wasn't a missing committee, it was a committee wired in a way that guaranteed it couldn't say no. Fix the wiring and the same committee starts to work. Three changes do most of that work.

Fix one: detach the budget from the demand

The first change is the most counter-intuitive. The business sponsor who sits in governance should not be the person originating the operational demands.

This sounds backwards. Surely you want the people asking for things in the room, defending what they asked for? That's exactly the problem. When the person who controls the budget is also the author of the demand, every design discussion turns into a negotiation they're invested in winning, emotionally and politically. They didn't come to weigh the trade-off. They came to get their thing.

I saw the opposite work. On one program the business sponsor sat in the governance committee only, responsible for the budget but not the source of the day-to-day operational requests coming up from the business teams. His job in arbitration was to validate the demand and the design, and that was the whole job. Because he hadn't personally asked for any of it, he could refuse a design that twisted the system to fit the way the business already liked to work. There was nothing for him to defend. He could look at a bespoke request and say the standard path was good enough here, without losing any face, because it had never been his request in the first place.

Detaching the money from the demand is what gives the chair the freedom to say no. Keep the two fused together and you've just rebuilt the committee that can't decide.

Fix two: keep the arbiters off the project

The second change matters most, and it's where I've seen the sharpest contrast between a program that failed and one that worked.

The people doing the arbitrating, the IT and business decision-makers on the committee, should not be operational on the project itself. The moment your arbiters are also the people who have to deliver the work, you've planted a bias, and it cuts both ways.

Say the arbiter is an IT lead who'll have to build whatever gets approved. The temptation is to refuse demands to protect the team, because more scope means more workload, tighter deadlines, the permanent reorganization that comes with a target that keeps moving. You say no to survive. Now say the arbiter is a business operational lead. The opposite temptation shows up: accept everything, because every approved request is a win for their function, and let the budget and the build absorb the damage. That's how you end up with a full-custom solution that's brutal to implement and worse to maintain.

Either way the decision gets made for the wrong reason. Non-operational arbiters don't have that gun to their head. They can weigh a request on what it's worth, because they don't personally pay for the answer in overtime or in turf.

This is the difference I lived. At the large integrator the arbiters were in the line of fire, and the committee behaved accordingly. At a large construction-sector group I worked with four years ago, the method ran the other way round: arbitration sat with decision-makers who weren't operational on the program, and it held. The same kind of disagreement that had derailed the first program got resolved cleanly in the second, because the people deciding had no personal stake in which way it went.

One caveat, because it's tempting to reach for the ideal version. The cleanest setup is the budget sponsor sitting in arbitration often enough to anchor every hard call. In practice that sponsor is usually too senior to turn up regularly. He gets pulled in for emergencies and is otherwise absent. So treat the present sponsor as a rare luxury, not the plan you build on. The robust, repeatable version is the committee of non-operational arbiters. Build for that one.

Fix three: bring decisions in already cooked

The third change isn't about who sits on the committee. It's about what reaches them.

A chain of decision differs from a committee in one practical way: the quality of what lands on the table. Most governance runs on a thin slide. A need, a proposed solution, an effort estimate, three bullet points. For simple requests that's fine, and dragging every small thing through a heavy process just clogs the chain anyway.

But for the questions that genuinely deserve a debate between business and IT, that thin slide is where good governance goes to die. You can't arbitrate well off a bad brief. So those questions have to arrive instructed. The dossier does two things. First it lays out the business need in purely functional terms, what the business actually needs to accomplish, with no solution named, because the moment you frame the need around a solution you've already smuggled the answer in. Then it puts two or three solutions on the table, running from the most standard to the most custom, each one carried with its effort and its risks.

That's what makes arbitration possible. The committee isn't being asked to rubber-stamp a foregone conclusion, and it isn't being asked to invent an answer on the spot. It's handed a real choice with the trade-offs visible. A committee with a genuine choice in front of it can decide. A committee handed one option and an effort number can only approve it or stall.

What this means before day one

Notice what the three fixes have in common. Not one of them is a skill you pick up while the program runs. Not one is a tool you buy. They're decisions about how the organization is wired, and they get made before the first workstream kicks off.

So here's the check I'd run as a CIO, before a program goes anywhere near a go-live date. Is the person holding the budget detached from originating the demands? Are the arbiters free of operational responsibility on the project? Do the decisions worth debating arrive instructed, with real options and honest risks?

If all three answers are yes, you have a chain of decision. If they aren't, you have a committee that meets. And a committee that meets is exactly what every failed program also had.

Which raises the next question, sharper than it looks: if governance is a chain of decision, then who actually owns the program? Because the answer is almost never the name on the org chart. That's where the next article goes: Nobody Owns an ERP Program. The Decision Chain Does.