---
{
  "title": "Project governance",
  "summary": "Define authority, decisions, escalation, and accountability for a change.",
  "topic": "delivery",
  "level": "Beginner",
  "updated": "2026-10-12",
  "units": [
    1
  ],
  "aliases": [],
  "sources": [
    {
      "title": "UK Government: Project Delivery Functional Standard",
      "url": "https://www.gov.uk/government/publications/project-delivery-functional-standard"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## The idea

Project governance establishes how a project is directed and overseen. It defines sponsors, decision rights, reporting, approvals, and escalation. The structure should be proportional to the project’s impact. Security and operational owners need input where changes affect access, data, availability, or obligations. Governance supports delivery by clarifying who can resolve tradeoffs rather than requiring approval for every harmless detail.

## In practice

A sponsor approves the objective and budget; service owners approve operational acceptance; a defined change authority evaluates production impact.

## A common misunderstanding

A meeting schedule is not a governance model unless decision authority and responsibility are clear.

## Check your understanding

What should happen when scope and budget conflict?

**Think it through:** The responsible authority should evaluate options and record the approved tradeoff.


## Who can make which decision?

Governance provides the authority and accountability around a project. It identifies who sponsors the work, who manages delivery, who accepts the result, and where decisions go when competing priorities cannot be resolved by the working team. A governance arrangement is useful when it enables timely decisions with the right context. A large committee is not inherently stronger governance.

Define decision boundaries. A delivery lead might adjust task sequencing within an approved budget, while the sponsor approves a major scope change. A service owner may accept operational readiness, and a risk owner may accept a documented residual risk. These decisions should not be treated as interchangeable merely because one person has a senior title.

## A fictional rollout exception

During a security monitoring rollout, one legacy system cannot provide the expected logs. The engineers can explain the technical limitation and propose alternatives, but they should not silently decide that the resulting detection gap is acceptable to the business. The governance route brings the tradeoff to someone with the appropriate accountability.

The decision might approve a compensating measure, fund an integration, or defer that part of the scope. Record the reason, conditions, and review date. Later reviewers can then distinguish an intentional exception from an unnoticed omission. Escalation should carry options and consequences, rather than merely forwarding a problem without context.

## Map a decision route

For a fictional identity migration, list three decisions: changing a pilot date, spending beyond the approved budget, and accepting a temporary access-control gap. Assign a suitable decision owner to each and explain the information they need. Then check whether the delivery team knows how to reach those owners. Governance is practical when it makes responsibility clear at the moment a decision becomes necessary.

## Keep exploring

- [[project-charter]]
- [[stakeholder-management]]
- [[change-control]]