IT Governance That Doesn't
Have to Slow You Down.

Governance gets blamed for most delivery slowdowns. In my experience, that blame is usually misplaced. The governance model, whether it is COBIT, a homegrown stage-gate framework, or something derived from ITIL, is rarely the problem. What causes friction is almost always something that sits underneath the framework: who is allowed to make which decisions, and what has to happen before they can make them.

The actual problem: decision rights.

In most organisations, decision rights are implicit. They have never been written down. They have accumulated through precedent, organisational politics, and individual managers' interpretations of their own authority. The result is that decisions that should take a day take two weeks. Not because the governance process requires it, but because nobody is quite sure whether they are allowed to decide, so they escalate. And escalation, in most IT departments, is a queue.

The clearest sign of a decision rights problem is a long approvals trail on decisions that don't warrant it. When a project manager needs three sign-offs to approve a vendor invoice below a certain threshold, or when a technical architecture decision gets bumped to a steering committee that meets monthly, those are symptoms. The process is not the disease.

The fix starts with an exercise that feels obvious but rarely gets done properly: write down who can decide what, at what value or risk threshold, with what information required, and with what consultation obligations. For each decision type, ask: does this authority level match the actual risk? Could a lower level decide this safely, with appropriate reporting upward? In almost every organisation I have worked in, the answer to the second question is yes for at least half the decision types on the list.

Escalation path design.

The second structural problem is poorly designed escalation paths. When something goes wrong on a project, a scope creep request, a budget overrun, a technical blocker, the question is: who needs to know, who needs to decide, and how fast does that need to happen? In most organisations, the answer to all three questions is "unclear," which means everything ends up in front of the same steering committee that meets every four weeks.

A functional escalation path has three properties. It is proportionate: not every problem needs the same level of attention. It is time-bounded: there is a clear expectation of how quickly a decision will be returned, so the project is not left waiting in ambiguity. And it has a clear owner at each level: a named person who is accountable for the decision, not a committee that can defer indefinitely.

Practically, this means defining a tiered escalation model. A project manager can resolve operational issues within their authority. A program manager handles scope, resource, and budget decisions up to a defined threshold. The steering committee handles strategic trade-offs, portfolio-level conflicts, and decisions above those thresholds. Each tier has a response time expectation. Each tier has defined triggers for what goes there and what does not. This sounds administrative, but once it is in place, it dramatically reduces the volume of items that end up in steering, because most things stop needing to go there.

Proportionate governance.

The third piece is proportionality. Applying identical governance to a six-week internal tooling project and a two-year regulatory compliance program is not rigorous; it is just friction. The same stage-gate process that provides genuine value on a high-complexity, high-stakes program becomes a bottleneck on a straightforward delivery that does not need four committee reviews to get to production.

Designing proportionate governance means creating tiers of governance intensity based on risk: project size, number of dependencies, regulatory exposure, technology novelty. Low-risk projects get a lighter model: clear objectives, a named owner, periodic check-ins, and a simple escalation path. High-risk projects get the full framework. The key is that the classification is done upfront and consistently, not left to the discretion of whoever happens to be sponsoring the project.

When you implement this, two things happen. Delivery teams stop experiencing governance as bureaucracy, because the overhead is proportionate to the actual complexity. And the governance process becomes more effective, because the attention of steering committees and risk functions is concentrated on the projects that actually need it, rather than diluted across everything regardless of risk.

How to audit what you have.

If you want to assess your own governance model, start with three questions. First: what was the last decision that took significantly longer than it should have? Trace it through the process and identify where it waited and why. In most cases you will find either an unclear decision right or a missing escalation path, not a broken framework. Second: ask three delivery leads what aspect of governance adds the most friction to their work. The answers are usually consistent, and they point directly at the problem. Third: look at your last ten steering committee agendas. If most items are status updates rather than decisions, the committee is being used as a reporting function rather than a governance one. That is fixable, but it requires redesigning what goes to steering and what does not.

Good governance is not invisible. But it should feel proportionate to the people working inside it. If it does not, the answer is almost never to abolish the framework. It is to design the decision rights and escalation paths that the framework assumes but rarely specifies.