Project governance is the system of decision rights, forums, and escalation paths that determines how a project is directed and controlled. A project governance framework writes that system down before the project starts: who can approve what, at which threshold, in which meeting, and what happens when they disagree. It is not oversight, reporting, or assurance, though it produces all three. It is an answer, agreed in advance, to the question of who decides.
The reason it is worth the effort is narrow and specific. Almost every project delay that gets blamed on complexity is actually a delay in deciding. Someone raised an issue, nobody was sure who owned the call, it went to a meeting, the meeting deferred it, and four weeks disappeared. A governance framework does not make the decision easier. It makes the owner obvious, which is most of the four weeks.
Key takeaways
- Project governance answers one question: who decides what, and at what threshold.
- A workable framework has five components: decision rights, forums, escalation path, reporting cadence, and assurance.
- Decision rights are written as thresholds with numbers, not as principles. "Material change" is not a threshold.
- Governance is not management. Management makes the project happen. Governance decides whether it should.
- Project governance controls one project. Portfolio governance decides whether that project should exist at all against the others competing for the same money.
- Every framework needs a documented way to say no. A structure with no path to stopping a project is reporting dressed as governance.
- Keep it to two pages. A governance framework nobody reads governs nothing.
What is project governance?
Project governance is the framework of roles, decision rights, processes, and oversight structures through which a project is authorized, directed, and held accountable for its outcome. It sets the boundaries inside which the project manager may act freely, defines what must be escalated and to whom, and establishes the points at which someone senior decides whether the work continues.
Notice what governance is not. It is not the project plan. It is not the status report. It is not the PMO, though the PMO usually administers it. Governance is the constitutional layer: the set of rules about who holds which power, agreed while everyone is calm, so that when the project is late and two directors want incompatible things, the rules already exist and nobody has to invent them under pressure.
The distinction from management is the one that trips people up. Management is the exercise of authority to make the project happen: planning, sequencing, assigning, chasing. Governance is the conferral and the limitation of that authority. The project manager manages. The steering committee governs. When the same person does both, you have a project with no brake.
The five components of a project governance framework
Frameworks in the wild list anywhere between four and nine components, and most of the variation is repackaging. Five carry the load.
| Component | What it specifies | Test that it is real |
|---|---|---|
| Decision rights | Which decisions belong to the project manager, the steering committee, and the portfolio board, expressed as numeric thresholds. | Two people reading it independently agree on who approves a $40,000 overrun. |
| Forums | Which bodies exist, who sits on them, how often they meet, and what they decide. | Every forum can name a decision it made in the last two months. |
| Escalation path | What triggers an escalation, where it goes, and how long the recipient has to respond. | Escalations have an ageing report and someone reads it. |
| Reporting cadence | What information moves upward, in what form, and when. Variance, not narrative. | The report drives a decision rather than describing the past. |
| Assurance | Who independently checks that the reported position is true, and at which gates. | Assurance has, at least once, contradicted a project's own status. |
The component organizations skip is assurance, and it is skipped because it is uncomfortable. Assurance means someone who does not report to the project confirms that the schedule is achievable and the reported spend is complete. Without it, governance is a system for making decisions on data supplied by the party whose project is being judged. That is not a moral failing of project managers. It is what happens to any measurement when the measured party controls the instrument.
Project governance structure
A structure is the set of forums and the reporting lines between them. Three layers are enough for almost any organization, and a fourth appears only in very large programs.
| Layer | Body | Decides | Cadence |
|---|---|---|---|
| Portfolio | Portfolio board or executive committee | Which projects are funded, which are stopped, how scarce people are allocated across them. | Monthly or quarterly, on the funding cycle |
| Project or program | Steering committee (project board) | Whether this project proceeds as planned. Change beyond tolerance. Risk acceptance. Gate passage. | Monthly, plus at each gate |
| Delivery | Project manager and delivery team | Everything inside the agreed tolerances. Sequencing, assignment, day to day trade-offs. | Continuous |
| Assurance (cross-cutting) | PMO, internal audit, or an independent reviewer | Nothing. Reports independently on whether the position presented is accurate. | At gates, and on exception |
The line between the top two layers is where most structures go wrong. A steering committee will always conclude that its project should continue, because everyone in the room is invested in it. Comparing it against the other projects that want the same engineers is a different decision, taken in a different room, by people who see all of them. Collapsing those two forums into one is the most common structural error in project governance, and its symptom is a portfolio where nothing is ever stopped and every project is slightly under-resourced. The forum that fixes it is the portfolio review meeting.
A simple project governance model you can copy
Two pages. Written before the project starts, agreed by the sponsor, issued by the PMO as a template so that each project is not inventing its own. The numbers below are illustrative. Set thresholds proportionate to the size of your projects, and set them once so that they are consistent across the portfolio.
| Decision | Threshold | Decided by | In which forum |
|---|---|---|---|
| Schedule change | Up to 10% of remaining duration, no milestone move | Project manager | None. Recorded in the log. |
| Schedule change | Milestone moves, end date holds | Sponsor | Steering committee |
| Schedule change | End date moves | Portfolio board | Portfolio review |
| Budget change | Up to 5% of approved budget, within contingency | Project manager | None. Recorded. |
| Budget change | Above 5%, funded from contingency | Steering committee | Steering committee |
| Budget change | Requires new money | Portfolio board | Portfolio review |
| Scope change | No effect on the benefit case | Project manager | None. Recorded. |
| Scope change | Reduces the stated benefit | Sponsor | Steering committee |
| Risk | Residual exposure above the project's risk appetite | Sponsor | Steering committee |
| Risk | Exposure crosses into other projects | Portfolio board | Portfolio review |
| Gate passage | Any | Sponsor, on assured evidence | Gate review |
| Stop the project | Any | Portfolio board, on the sponsor's recommendation | Portfolio review |
Two design choices in that table are deliberate. Stopping the project sits with the portfolio board rather than the steering committee, because a steering committee stopping its own project is a body voting itself out of existence, and it very rarely does. And gate passage requires assured evidence rather than the project's own report, which is the point of having gates at all. The mechanics of running those reviews properly are set out in the stage gate process, with the artifact itself in the stage gate review template.
What is a project governance example?
Take a $2M platform replacement, eighteen months, three departments affected. The governance framework issued at initiation says the following.
The sponsor is the COO, who owns the business case and chairs the steering committee. The steering committee has six members: the COO as chair, the operations director as senior user, the CTO as senior supplier, a finance business partner, the head of the PMO, and the customer service director whose team absorbs the change. The project manager attends and does not vote. The committee meets on the first Tuesday of each month, and additionally at each of the four gates.
The project manager may absorb any change under $100,000 and any slippage that does not move a milestone, and must record both. Anything larger goes to the steering committee, which may draw on the $200,000 contingency. Anything requiring new money or a later end date goes to the portfolio board, which meets monthly. Risks with residual exposure above $250,000 are accepted by the COO in the steering committee and reported to the portfolio board. Any risk that affects another project is escalated the same week, because a risk that crosses projects is a portfolio risk and belongs in portfolio risk management.
Escalations from the project manager receive a decision within ten working days or they are automatically tabled at the next portfolio review with the delay recorded. The PMO reports escalation ageing to the portfolio board every month, without commentary. That single mechanism does more for delivery speed than any amount of reporting, because it makes the cost of not deciding visible to the people who are not deciding.
Gate reviews are assured: the PMO reviews the evidence before the sponsor signs, and the sponsor's approval is recorded as a signed decision. That signature is not ceremony. Eighteen months later, when someone asks why the scope changed at gate two, the record either exists and is retrievable or it does not, and the answer becomes whatever the most confident person in the room remembers. Getting the approval captured as a signed record and stored where an auditor can find it takes minutes at the time and saves an argument that would otherwise take days.
Project governance vs project management
| Project governance | Project management | |
|---|---|---|
| Question it answers | Should this continue, and who decides? | How do we deliver it? |
| Who does it | Sponsor, steering committee, portfolio board | Project manager and team |
| Output | Decisions and authority | Deliverables and a plan |
| Frequency | Periodic, at gates and thresholds | Continuous |
| Fails as | Status meetings, no decisions, nothing stopped | Missed dates, scope creep, burnout |
Project governance vs portfolio governance
Project governance controls one project. It asks whether this project is being run properly and whether it should proceed to its next stage. Portfolio governance controls the set of projects. It asks whether this project should exist at all, given the others that want the same money and the same twelve people. They use different forums, different data, and different time horizons, and they should not be merged.
The practical seam between them is the escalation path. When a decision affects only this project, it stops at the steering committee. When it affects the balance between projects, whether that is money, people, or sequence, it crosses into the portfolio layer. Everything on that side of the seam, including how projects enter the portfolio and how their relative priority is settled, belongs to project portfolio governance rather than here.
One more consequence follows. A project governance framework that has no portfolio layer above it will eventually make portfolio decisions badly, one project at a time, in rooms that cannot see the whole. That is how organizations end up with fourteen simultaneous projects, each individually approved, each perfectly reasonable, collectively requiring twice the engineering capacity that exists. The fix is not better project governance. It is prioritizing the portfolio in a forum that can see all fourteen.
Frequently asked questions
What is project governance in simple terms?
Project governance is the written set of rules about who can decide what on a project. It names the forums, sets the thresholds at which a decision moves from the project manager to the sponsor to the executive level, defines how issues escalate, and establishes when someone senior formally decides whether the project continues.
What are the components of a project governance framework?
Five: decision rights expressed as numeric thresholds, the forums that hold those rights, the escalation path with a response deadline, the reporting cadence that feeds the forums, and independent assurance that the reported position is accurate. Frameworks with more components usually subdivide these five rather than adding anything new.
What is the difference between project governance and project management?
Project management is the exercise of authority to deliver the project: planning, sequencing, assigning work, tracking progress. Project governance is the conferral and limitation of that authority: deciding how much the project manager may commit without asking, and deciding whether the project should continue at all. Management makes it happen. Governance decides whether it should.
Who is responsible for project governance?
The sponsor is accountable for it and chairs the forum that exercises it. The PMO usually designs the framework, issues the template, and administers the cadence, but the PMO does not hold the decision rights. The steering committee and the portfolio board exercise them. If the PMO is deciding, governance has been delegated to a function with no accountability for the outcome.
What is a project governance structure?
A governance structure is the arrangement of decision-making bodies above a project and the reporting lines between them. The standard shape is three layers: a delivery layer led by the project manager, a project layer represented by the steering committee, and a portfolio layer represented by an executive or portfolio board, with an independent assurance function cutting across all three at gates.
What is a project governance model?
A governance model is the specific instance of a framework applied to one project: the named forums, the named members, the actual thresholds in dollars and days, and the actual meeting cadence. The framework is the pattern issued by the PMO. The model is what one project fills in and the sponsor signs off before work begins.
How do you manage project governance?
Write the decision rights with numbers before the project starts, get the sponsor to sign them, hold the forums on their cadence whether or not there is news, report escalation ageing so that indecision is visible, assure the evidence at each gate independently, and review the framework once at the halfway point. Governance is managed by making the absence of decisions measurable.
Does a small project need a governance framework?
It needs decision rights and a sponsor. It does not need forums. On a project inside one department, funded by that department, with no shared resources, write down what the project manager may commit without asking, name the person who decides everything else, and stop there. Convening a steering committee for a project that small adds cost and no control.
Where to start
Write the decision rights table first. It is the only part of a governance framework that changes behavior on day one, because it is the only part anyone consults under pressure. Fill in real numbers, get the sponsor to agree them in writing, and publish them where the project manager can point at them when a director asks for something the project cannot give.
Everything else follows. The forums exist to hold the rights. The escalation path exists because rights are sometimes exercised too slowly. The reporting exists to feed the forums. The assurance exists because the reporting comes from an interested party. And the whole apparatus exists because a project without an agreed answer to "who decides" will find one anyway, usually the person with the most political capital, usually four weeks late. If you are building this alongside a new function rather than a single project, the sequence is set out in how to set up a PMO.