Short Charters, Sharp Decisions: Replacing Governance Theatre in UK Project Delivery

Project charters are often written to secure approval, not to run delivery. They arrive as multi-page documents with background, scope, assumptions, a governance map and a long list of roles. They can look rigorous. Yet the questions that decide whether a project moves quickly — who can say yes, what is out of bounds, when an issue must escalate — are frequently left vague. In UK delivery teams, this is not a paperwork problem. It is a decision problem.

The paperweight problem

A charter that is not used in meetings is not a governance instrument. It is a paperweight. The pattern is familiar: a sponsor signs a long document at the start, the steering group meets monthly, and the real rules are negotiated in corridors or inferred from behaviour. Decision rights are assumed rather than agreed. Constraints are discovered late. Escalation happens when frustration, not thresholds, triggers it.

This is governance theatre. It creates the appearance of control while leaving the important ambiguities intact. The answer is not more detail. It is a shorter document that forces the right choices into the open.

A charter should be a decision tool

A one-page delivery charter is not a summary of the business case. It is a working agreement for how delivery will be governed. It should fit on a single page because if it cannot, the team has not yet decided what matters. The page should cover five elements: outcomes, accountabilities, success measures, boundaries and escalation triggers.

Outcomes, not activity

State the outcome in one sentence. Not the deliverables, not the project name, but the change the organisation expects. Then name three success measures that will be used to judge progress. Measures should be observable and, where possible, already collected. If a measure requires a new reporting pack, question whether it is a measure or a comfort blanket.

Accountabilities that name decisions

Role lists are common; decision rights are rare. The charter should state who can approve scope changes, who can commit spend within agreed limits, who can accept operational risk and who can stop work. Use role titles, not individual names, so the charter survives staff changes. Name one accountable executive for the outcome and one delivery lead for execution. Avoid shared accountability for decisions; it usually means no one is accountable.

Boundaries and constraints

Boundaries are not the same as a detailed scope statement. They are the limits within which the team can act. Include budget tolerance, regulatory obligations, procurement rules, technical constraints and explicit non-goals. In UK organisations, this might include data protection requirements, public sector procurement thresholds or contractual change controls. A clear non-goal is often more useful than another paragraph of scope, because it prevents well-meant drift.

Escalation triggers, not escalation moods

Escalation should be predictable. Agree triggers such as slippage beyond an agreed number of working days, cost variance beyond a set percentage, a decision pending for more than five working days, or a risk moving above an agreed rating. For each trigger, name the route, the decision owner and the expected response time. This protects delivery teams from being accused of escalation for its own sake, and protects sponsors from late surprises.

The one-page test

A practical test: can a new team member read the charter in five minutes and know what success looks like, who decides what, where the limits are and when to escalate? If not, it is not ready. The charter should be reviewed at each major gate, not rewritten every month. Changes should be version-controlled and visible to the team.

Adopting it in UK teams

The fastest route is to pilot the charter on the next project rather than launch a governance redesign. Use it to open the first steering group, not to close the last approval meeting. Ask the sponsor to reference it when making decisions. Ask the delivery lead to test escalations against it. If the charter is ignored, the problem is not the template; it is the absence of sponsorship behaviour.

A one-page charter will not solve every governance weakness. It will expose ambiguity earlier, which is the point. Clearer delivery, done properly, starts with a short document that is actually used.