Programme Governance: The Structure That Actually Works

Which forums a programme needs, what each one decides, how often they meet, and how to keep governance proportionate to the delivery it protects.

Programme governance is the structure of forums, roles, decision rights and reporting through which a programme is directed and held to account. Its job is to make decisions at the right level, quickly, and to give the organisation confidence that the programme is under control.

Governance fails in two directions. Too little and decisions queue behind an unavailable sponsor. Too much and the programme spends its capacity producing reports about work it no longer has time to do. The design question is always proportionality.

The forums a programme needs

Steering committee (or programme board)

Meets monthly. Decides on scope changes beyond an agreed threshold, budget, re-baselining, and anything crossing the programme's boundary into the wider organisation. Chaired by the sponsor.

Its only real purpose is to make decisions the programme manager cannot make alone. If a steering committee meets and takes no decisions, it is a briefing — and it is worth asking whether it needs to happen at that frequency. The steering committee report guide covers the pack.

Delivery or programme management forum

Meets weekly. Workstream leads plus the programme manager. Reviews progress, RAID, dependencies and the next two weeks. Escalates upward only what genuinely needs the steering committee.

This is where most real governance happens, and it is the forum most often skipped when the programme gets busy — which is exactly when it is needed.

Design or technical authority

Meets fortnightly or on demand. Decides architecture and design questions so they do not arrive at the steering committee, where nobody is qualified to answer them. For any programme with meaningful technical content, this forum removes more delay than any other.

Change control board

Meets as needed, with a standing slot. Assesses and approves scope changes against quantified impact. Scope creep is rarely one large change; it is eleven small ones waved through without an impact assessment.

Decision rights: write them down

The most valuable governance artefact is a single page stating who can decide what, and up to what value or impact. For example: the programme manager approves changes below an agreed threshold with no schedule impact; the steering committee approves anything above it or affecting the go-live date; the sponsor alone approves re-baselining.

Without this, every decision defaults upward, and a queue forms behind whoever is least available. Agreeing it takes an hour at mobilisation and saves weeks later.

Reporting cadence

Each layer should be derived from the one below rather than written fresh. If the steering committee pack is composed from scratch each month, either the underlying reporting is not trusted or it is not fit for purpose — and both are worth fixing at the source.

The artefacts that carry the governance

• RAID log — reviewed weekly, escalated monthly
• Dependency tracker — the thing a steering committee can most usefully unblock
• Decision log — decisions not written down are relitigated at the next meeting
• Action log — with owners and dates, reviewed at the top of each forum
• Status reporting in one fixed format across workstreams
• Change register with quantified impact per request
• Plan and milestone set that the reported dates are actually derived from

Seven artefacts. A programme that needs more than this usually has a governance problem rather than a documentation problem.

Keeping governance proportionate

Every forum must produce decisions. If it does not, reduce its frequency or merge it.

Every report must have a named reader who acts on it. Reports produced for a distribution list nobody has reviewed in a year should be stopped, and almost never are.

Review the governance itself at least twice. Once about eight weeks in, when the initial design meets reality, and again at any major phase change — mobilisation governance and cutover governance need different things.

Escalate on the date, not after. Agree in advance the point at which an unconfirmed dependency or an unmet criterion goes upward. Escalating late is what turns a manageable problem into a schedule change.