Governance is not bureaucracy. Poor governance is.

Say the word "governance" in most IT departments and you can watch people's shoulders drop. They picture approval boards that meet fortnightly, forms nobody reads, and a change calendar that exists mainly to say no.

That is not governance. That is what is left when governance has been designed badly — or copied from a framework without being designed at all.

Good governance does the opposite. It makes decisions faster, because everyone knows who is allowed to make them. It lets teams move, because the guardrails are clear. And it catches risk early, while it is still cheap to fix.

What governance is actually for

Strip away the vocabulary and IT governance answers three questions:

1. Who decides? Decision rights — for spend, for change, for risk acceptance, for priorities.
2. What does good look like? The service levels, controls and outcomes we have agreed to.
3. How do we know? The evidence and reporting that show whether it is happening.

COBIT gives you a structured way to answer these at board level. ITIL gives you the practices to run them day to day. Neither is useful as a rulebook. Both are useful as a decision framework.

The $2.5M question nobody had asked

On one enterprise migration, the plan was on track and the sign-off meeting was close. Governance, done properly, meant one more question before approval: had compatibility been verified for every critical dependency, not just the ones in the test plan?

It had not. A VPN compatibility defect was sitting in the gap. Catching it before sign-off averted a projected $2.5M business impact.

Nobody would call that bureaucracy. It was a single, well-placed control, owned by someone with the authority to pause a go-live. That is the whole point.

Five signs your governance has become bureaucracy

• Every change goes to the same board, whether it is a password policy tweak or a core platform migration.
• Approvals are recorded, but decisions aren't — you can see who signed, not why.
• SLAs measure activity, not outcomes — tickets closed, rather than services available when the business needed them.
• Reports are written for IT, so executives stop reading them.
• Nobody can name the owner of a given risk, service or vendor relationship.

Designing governance that speeds things up

Tier your decisions. Standard, low-risk changes should be pre-approved and automated. Save human review for the changes that could genuinely hurt the business.

Put decision rights in writing. A one-page RACI for your key decisions removes more friction than any tool.

Design SLAs backwards from the business. Start with what a store, a plant or a vessel actually needs, then set targets and OLAs to support it. That is how SLA compliance becomes meaningful rather than cosmetic.

Make vendor governance a routine, not a rescue. Monthly service reviews against contract, with clear escalation paths, stop vendor issues becoming incidents. Disciplined vendor consolidation and asset lifecycle governance is how I helped cut regional IT costs by 15% (AED 5.5M) — not by cutting corners, but by knowing exactly what was being paid for.

Report in the board's language. Risk, cost, availability, customer impact. One page. Trend lines, not raw ticket counts.

The test

Here is a simple test for any governance process: if you removed it tomorrow, what would go wrong, and how quickly would anyone notice?

If the answer is "nothing" — remove it. If the answer is "a $2.5M defect would reach production" — that is governance doing its job, and it deserves to be protected.

Governance is not bureaucracy. Poor governance is. The difference is whether it was designed on purpose.