Setting up a governance framework

Most organisations don’t set up a governance framework — they accumulate one. A steering group gets created for one project, a sign-off threshold gets established for another, an escalation path gets agreed informally over email. Over time, a patchwork of governance conventions develops that nobody designed and nobody fully understands.

The result is inconsistency. Some projects are heavily governed, others barely at all. Decisions get made at the wrong level. Problems surface too late because nobody knew where to escalate them.

Building a governance framework from scratch — or rationalising the one you’ve inherited — is one of the most valuable things a PMO can do. Here’s how to do it.

What a governance framework actually contains

A governance framework isn’t a single document. It’s a set of connected components that together define how project decisions get made in your organisation.

Step 1 — Define decision rights

The most important thing a governance framework does is clarify who can decide what. Without this, every decision either escalates unnecessarily (slowing everything down) or gets made at the wrong level (creating risk).

A simple decision rights matrix covers the most common project decisions:

• Project initiation — who approves a new project starting?
• Budget approval — who can approve spend at different levels (£10k, £50k, £100k+)?
• Scope changes — who approves changes to what the project will deliver?
• Risk acceptance — who decides to accept a risk rather than mitigate it?
• Project closure — who signs off that a project is complete?

For each decision, assign a RACI: who is Responsible, who is Accountable, who is Consulted, who is Informed. The accountable person is the one who has the final say — make sure that’s always a single individual, never a committee.

Step 2 — Set approval thresholds

Not every decision needs the same level of scrutiny. A £5,000 budget variance on a £2 million programme is noise. A £5,000 variance on a £15,000 project is serious. Your governance framework should define thresholds that trigger escalation automatically — not based on someone’s judgement that a situation is serious, but based on objective criteria.

Common threshold triggers:

• Budget variance exceeding X% or £X
• Schedule slippage beyond X weeks
• New risk rated above a certain level
• Scope change exceeding X% of original scope
• Change in RAG status from Green to Red (skipping Amber)

Be specific. “Significant budget variance” is not a threshold. “Budget variance exceeding 10% or £25,000, whichever is lower” is a threshold.

Step 3 — Build escalation paths

Escalation fails in most organisations not because people don’t know there’s a problem, but because they don’t know where to take it. A clear escalation path removes the uncertainty.

For each type of issue, the path should be explicit:

• Project Manager → Project Sponsor (first escalation)
• Project Sponsor → Steering Group (second escalation)
• Steering Group → Portfolio Board (third escalation)

Define what each level can and can’t resolve, and what the expected response time is at each step. The PMO’s role in escalation is usually as the facilitator — ensuring the right information gets to the right person quickly, not making the decision itself.

Step 4 — Establish your reporting cadence

Governance without information is theatre. Your framework needs to define what gets reported, to whom, and how often — so that the people making decisions actually have what they need to make them well.

A simple reporting hierarchy for most organisations:

• Weekly — Project manager to sponsor: one-page status update, RAG, risks, decisions needed
• Monthly — PMO to steering group: portfolio dashboard, exception report, resource picture
• Quarterly — Portfolio view to leadership: strategic alignment check, benefits realisation, investment decisions

The most common mistake

Building a governance framework that covers every eventuality. The first version of your framework should be simple enough to fit on two pages. Complexity can be added later. A simple framework that people actually use beats a comprehensive one that sits in a SharePoint folder nobody visits.

Start with the four components above. Get them agreed and signed off. Then iterate based on what isn’t working.