A project governance plan sets out who decides what, when a decision is required and how performance is checked against the baseline. It needs five things from day one: named roles with clear accountability, defined decision points mapped to deliverables, a change control procedure with thresholds, a reporting and meeting cadence, and an assurance method for auditability. The sections below break each of these into templates you can adapt directly.
TL;DR:
- A RACI matrix should assign exactly one Accountable owner to each decision; multiple Responsible contributors are acceptable, but shared accountability often stalls resolution.
- Set escalation thresholds before work begins, such as routing change requests under £10,000 to the Project Manager and larger requests to the sponsor.
- Match governance to project size: small projects may hold steering reviews at key gates, while large projects need frequent reports and independent checks.
- Require high severity issues to have a named owner and a response service level of 48 hours, with automatic escalation if the deadline passes.
- Independent assurance should verify reported status against reality before each gate, and findings should inform the decision rather than sit in a separate report.
Table of Contents
- What to include in a project governance plan: document structure and purpose
- Roles, accountabilities and RACI: who decides and who delivers
- Core governance processes to define inside the plan
- Meeting and reporting cadence: a practical rhythm for governance
- Templates and checklist: ready-to-adapt governance checklist
- How Keystone implements governance and how Videra supports operational delivery
- Practitioner perspective: common failures and fast fixes
- Keystone consultancy and Videra: how we help implement governance plans
- FAQ
- Sources
What to include in a project governance plan: document structure and purpose
A governance plan is not a restatement of the project schedule. It is the control document that says how decisions get made, who answers for them and how the organisation checks that the project is still worth running. Every version should open with a short statement of objectives: what the plan governs, and how it connects to wider organisational governance rather than sitting as a standalone artefact. GAO's Project Planning and Management Approach recommends anticipating major decisions early and making them before large resources are committed, which is exactly what this opening section should set up.
From there, the document needs to record the decision points the project will hit, tied to specific deliverables rather than calendar dates. A gate at the end of design, a go or no go before procurement, a readiness check before go live: each needs an owner and a decision rule, not just a date on a Gantt chart.
The plan should also set out the assurance basis: the baselines against which progress is measured, and the key performance indicators used to flag drift. GAO's guidance points to variance analysis, comparing actual progress against the plan, as a primary control mechanism and an early warning system for redirection.
A usable governance plan typically includes:
- A statement of objectives and scope, linking governance activity to organisational strategy.
- A roles and accountabilities section, usually built on a RACI matrix.
- Decision points and escalation thresholds mapped to project stages.
- Reporting and meeting cadence, including report templates.
- Change control, issue and risk management procedures.
- Assurance arrangements and the metrics used to measure them.
- A version control and review section defining who approves changes to the plan itself.
To draft the plan in order:
- Confirm objectives and how they map to organisational or portfolio governance.
- Define roles and complete a RACI matrix before writing procedures.
- Map decision points to the project life cycle, not the calendar.
- Write the change, issue, risk and assurance procedures using consistent thresholds.
- Set the reporting cadence and attach templates.
- Agree the version and approval rule, then circulate for sign-off.
The final clause that most drafts miss is maintenance. A governance plan is a living document: it needs a stated review trigger, such as a stage gate, a scope change above a set threshold or a fixed quarterly check, and a named approver for any revision.
Roles, accountabilities and RACI: who decides and who delivers
Governance stalls when nobody can say who actually owns a decision. Four roles carry most of the weight on a typical project.
- Project Sponsor: sets tolerances, acts as the main escalation point above the Project Manager, and owns the authorise, continue, change and stop decisions across the life cycle.
- Steering committee: reviews progress against baseline, resolves cross-functional conflicts and ratifies decisions above the sponsor's own tolerance.
- PMO: maintains standards, templates and the governance calendar, and provides independent assurance input.
- Project Manager: runs day-to-day delivery, manages the risk and issue registers, and escalates only what sits outside their own tolerance.
PMI's guidance on stakeholder management and RACI is built on one firm rule: a task can have several people marked Responsible, but only one Accountable owner. Splitting accountability between two people is the single most common cause of governance paralysis, because neither feels fully obliged to resolve a stalled decision.
Decision timing matters as much as ownership. A scope change under an agreed cost threshold might sit with the Project Manager; above it, with the sponsor; above a second, higher threshold, with the steering committee. Writing these numbers into the plan, rather than leaving them to judgement on the day, is what keeps decisions moving at pace.
Pro Tip: Set your escalation thresholds in the plan before the project starts, not when the first dispute arrives.
A properly built RACI matrix is the fastest way to surface these gaps before they cost time. It also gives the steering committee a single reference when a dispute over ownership comes up mid-project, rather than relying on memory or email trails.
Core governance processes to define inside the plan
Four processes do most of the governance work day to day, and each needs a short, specific procedure written into the plan rather than left implicit.
- Change control: every change request is submitted on a standard form, assessed for cost, time and risk impact, then decided against a threshold (for example, under £10,000 by the Project Manager, above it by the sponsor). Every decision, approved or rejected, is logged with a date and rationale.
- Issue management: issues are classified by severity, assigned a named owner and given a response service level, such as 48 hours for a high-severity issue before it escalates automatically.
- Risk management: a structured register records likelihood, impact, owner and mitigation, reviewed on a fixed cadence rather than only when something goes wrong. A risk register built around clear tolerances keeps this from becoming a static document nobody opens.
- Assurance: independent checks, often from the PMO, confirm that reported status matches reality before a gate decision is made. Assurance findings should feed directly into the next stage gate rather than sit in a separate report nobody reads before the meeting.
Closure needs its own short checklist too: exit criteria met, deliverables accepted, lessons logged, and a formal handover of ongoing risks and open issues to the business-as-usual owner.
PMI's governance practice guide frames governance as the link between strategy and delivery rather than a compliance layer bolted on afterwards. That framing matters for how these four processes are written: each should state not just what happens, but which strategic or delivery objective it protects.
A widely used practitioner structure for governance plans lists ten core procedural elements, including issue management, change management, resource management, communication, reporting, risk management and closure, as a baseline checklist for what a plan needs to cover. (ITToolkit)
- Keep every register (change, issue, risk) in one consistent format so assurance reviews do not require translation between documents.
- Log rejected change requests with the same rigour as approved ones: patterns in rejections often reveal scope creep early.
Meeting and reporting cadence: a practical rhythm for governance
Governance fails as often from too many meetings as too few. The fix is matching cadence to project size rather than applying one rhythm to everything.
- Project board or working-level checkpoints: weekly or fortnightly, focused on delivery status and near-term blockers.
- Sponsor checkpoints: fortnightly or monthly, covering tolerance checks and any decisions sitting just below steering committee level.
- Steering committee: monthly or at each stage gate, reviewing baseline variance and ratifying major decisions.
Reports should be short and standard: an executive summary stating status against baseline in a few lines, an exception report that only appears when a tolerance is breached, and a dashboard of the live risk, issue and change counts. Exception reporting in particular keeps meeting time focused on what actually needs a decision, rather than walking through status that has not changed.
| Project size | Steering committee cadence | Sponsor checkpoint | Typical report |
|---|---|---|---|
| Small | At key gates only | Periodic | Executive summary |
| Medium | Regularly scheduled | Moderately frequent | Summary plus exception report |
| Large | Frequent | Frequent | Detailed dashboard plus exception report |
A detailed breakdown of governance meeting cadence and how to compress it without losing decision speed is worth reading alongside this table, since the right rhythm often needs adjusting once the project is a few weeks in.
Templates and checklist: ready-to-adapt governance checklist
A governance plan earns its place in the project management plan when it is short enough to act on, not just read.
Use this sequence to build and place it:
- Draft the roles and RACI section first; everything else depends on who owns what.
- Set decision thresholds and escalation paths before writing change control wording.
- Attach report templates (executive summary, exception report, dashboard) as appendices, not as separate documents.
- Size the assurance effort to the project using t-shirt bands, S through XL, so a small project is not carrying the paperwork of a large one.
- Embed the finished plan as a named section of the wider project management plan, cross-referenced from the schedule and risk register.
- Set a review trigger (gate, scope threshold or fixed date) and a named approver for changes to the plan itself.
- A small project typically needs a simpler RACI, a straightforward change log and less frequent reporting.
- A large project usually needs a comprehensive RACI matrix, independent assurance input, frequent reporting and a formal steering committee.
- Keep the stage gate criteria and the governance plan's decision thresholds in the same document so they cannot drift apart over time.
- Review decision-rights wording against a structured decision rights matrix if the organisation has multiple approval layers above the project itself.
Portfolio-level guidance on turning governance meetings into genuine decision points, rather than status theatre, is covered in more depth in portfolio governance for PMOs, which pairs well with the cadence table above.
How Keystone implements governance and how Videra supports operational delivery
In our experience working across healthcare, construction and facilities management, common governance failures include accountability split across two people, reporting that exists only to be read once, and assurance that happens too late to change a gate decision. Our approach is to map the governance plan's rules, decision thresholds, RACI assignments, escalation paths, directly into workflows rather than leaving them in a document nobody revisits.
Within Videra, stage gates and exception thresholds from the plan become automated checkpoints, and board-level reports are generated from live project data rather than compiled by hand before each meeting. On engagements where reporting had become a weekly manual exercise, shifting those reports into mapped workflows cut the preparation time to near zero and gave the steering committee a live dashboard instead of a static slide deck.
- Governance rules written once, enforced consistently across every live project.
- Exception reports generated automatically when a tolerance is breached, not compiled manually.
- Audit trails kept by design rather than reconstructed after the fact.
Pro Tip: Build the RACI and thresholds into the plan first; the tooling only pays off once the decision rules are already clear.
Practitioner perspective: common failures and fast fixes
Three failures turn up on almost every project we have reviewed. First, two people share Accountable on a decision, so neither resolves it: fix it by naming one owner per decision line in the RACI, no exceptions. Second, sponsors are named but never actually exercise their tolerance or escalation authority, so issues drift upward too late: get a short, specific commitment from the sponsor in week one, not a general endorsement. Third, governance is copied wholesale from a larger project onto a smaller one, burying a simple job under paperwork it does not need. Size the governance to the project's actual risk and complexity, and revisit that sizing as the project moves through its stages, not just at kick-off.
— Peter
Keystone consultancy and Videra: how we help implement governance plans
Writing the plan is the easy part. Making it hold under pressure, through audits, staff turnover and scope pressure, is where most governance efforts quietly fail. We work directly alongside project teams to adapt governance templates to the sector and scale, then roll them into Videra PM so decision rights, thresholds and reporting run as mapped workflows rather than static documents.
- An initial audit of current governance gaps against your project's size and sector.
- Adaptation of the roles, RACI and reporting templates to your organisation.
- Rollout support inside Videra PM, with reporting and assurance already mapped.
If you are drafting or rebuilding a governance plan now, our consultancy services team can work through the audit and template adaptation with you directly.
FAQ
What is a project governance example?
A typical example is a steering committee that meets monthly, a sponsor who owns the authorise, continue, change and stop decisions, and a change control process with a cost threshold deciding whether the Project Manager or the sponsor approves a given request. The governance plan documents all three in one place rather than leaving them to informal practice.
What are the three pillars of project governance?
Most governance frameworks rest on structure (roles and decision rights), process (change, issue, risk and assurance procedures) and reporting (the cadence and formats used to check progress against baseline). PMI's governance practice guide frames these as the components that link strategy to delivery rather than separate compliance tasks.
What are the 7 pillars of effective governance?
Definitions of a "seven pillars" governance model vary across sources, so there is no single agreed list; most versions expand the core structure, process and reporting pillars into finer categories such as accountability, transparency, risk management and assurance. Rather than chasing a fixed count, focus the plan on clear roles, defined decision rights and consistent reporting, which cover the substance behind most versions of the list.
What is a good project governance structure?
A good structure names a Project Sponsor, a steering committee, a PMO and a Project Manager, each with clear accountabilities set out in a RACI matrix, so only one person is Accountable for any given decision. PMI guidance on RACI stresses that defined escalation paths must exist before the structure goes live, not after the first dispute.
Sources
- PMI blog post: stakeholder management and RACI (2026)
- Governance of portfolios, programs, and projects: a practice guide (PMI)
- GAO guide to project planning and management (PPMA)