Project Management Leadership with AI · Project governance, lifecycles and the business case · lesson 1 of 21 · 14 min
Project governance and decision rights
What governance is (and is not)
Project governance is the framework of roles, responsibilities, decision rights and processes that directs and controls a project. It answers: who decides what, on what information, and how are they held accountable? Governance is not bureaucracy for its own sake; good governance speeds decisions because everyone knows who can make them.
The core roles
| Role | Accountable for | Common failure | |---|---|---| | Sponsor | The business case and benefits; securing funding; resolving escalations | Absent or too junior to decide | | Steering committee / project board | Direction, stage approvals, major changes, risk appetite | Becomes a status meeting with no decisions | | Project manager | Delivering agreed scope within tolerances; planning, coordination, reporting | Owns delivery but has no authority over resources | | Product owner / senior user | Defining and prioritising requirements; accepting outputs | Unavailable, so the team guesses | | Senior supplier / delivery lead | Technical integrity and resources for delivery | Commitments without capacity | | Project assurance / PMO | Independent check on health, standards and reporting | Paper compliance without insight |
These roles appear, with different names, in most major frameworks (for example PMI's PMBOK Guide, PRINCE2 and the APM Body of Knowledge). In agile settings, the product owner often absorbs parts of the senior user role.
Tolerances and management by exception
A powerful governance idea, central to PRINCE2 and widely used elsewhere, is tolerance: the board sets permissible deviations (for example ±5% cost, ±2 weeks on a stage end date), and the project manager acts freely within them. If a forecast breaches tolerance, the PM escalates with options. This avoids micromanagement while guaranteeing escalation when it matters.
Tolerance sheet (illustrative)
Level Cost Time Scope Risk
Project ±5% ±3 weeks Must-haves fixed No new "very high" risks unmitigated
Stage ±7% ±2 weeks Could-haves flexible —
Work package ±10% ±1 week Per product description —
Escalation: forecast breach → exception report within 3 working days
Decision rights: a RAPID-style view
For major decisions, clarify who will Recommend, Agree (must sign off, e.g., legal or security), Perform, provide Input, and Decide. Only one person or body should have the "D". Many projects stall because nobody is sure who has it.
Stage gates
Most projects pass through decision points (gates) such as: idea → business case → plan approval → build → go-live → close. At each gate, governance checks:
- Is the business case still valid?
- Is the plan for the next stage credible, with risks understood?
- Are resources and funding committed?
- Are there lessons from the previous stage to apply?
Gates are the right moment to stop a project that no longer makes sense. Stopping early is a success of governance, not a failure of the team.
Worked example
Illustrative. A fictional bank in Riyadh ran a digital onboarding project with a 14-person steering committee that met monthly and reviewed 40-slide status packs. Decisions took months. A governance redesign cut the board to five members (sponsor, product owner, technology lead, risk and compliance lead, finance partner), introduced tolerances, and replaced the status pack with a two-page exception-based report. Routine items were delegated; only breaches and strategic choices came to the board. Decision cycle time fell from weeks to days, and the team gained autonomy within clear limits.
Governance in regulated environments
Banks, healthcare, government and critical infrastructure add regulatory checkpoints: data protection impact assessments, security approvals, regulator notifications. Build them into the plan and governance calendar early. In the UK, public projects follow HM Treasury and government assurance guidance; in KSA and the UAE, government entities often apply national PMO standards; in Pakistan, public-sector projects follow planning commission processes (PC-I and related forms). Always check local requirements.
Common mistakes
- A sponsor without authority or time.
- Boards that receive information but make no decisions.
- No agreed tolerances, so every variance becomes a crisis or none do.
- Gates treated as formalities.
- PMO focused on templates rather than insight.
Quick self-check
For your current project, can you name in one sentence each: the sponsor, who has the "D" for scope changes, the cost and time tolerances, and the next gate with its criteria? If any answer is unclear, fix governance before you fix anything else.
Hands-on: a decision rights matrix with a built-in check
Columns: A Decision | B Sponsor | C Board | D PM | E Product owner | F Tech lead | G Risk & compliance | H Check
Cells: R (recommend), A (agree), D (decide), P (perform), I (input), blank
H2 =IF(COUNTIF(B2:G2,"D")=1,"OK","Needs exactly one D")
Tolerance block: Level | Cost | Time | Scope | Risk | Escalation route | Response time
Example rows (illustrative): "Scope change beyond stage tolerance" → PM R, Product owner A, Board D. "Release go/no-go" → Tech lead A, Product owner D, Risk & compliance A for regulated features.
Template: exception report (one page)
Project: ____ Date: ____ Tolerance breached: cost / time / scope / risk (level: project / stage)
1 What has happened and the forecast impact (numbers, dates)
2 Cause (root cause, not symptom)
3 Options (at least two, plus 'do nothing'): cost, time, scope, risk, benefits impact of each
4 Recommendation and rationale
5 Decision required by: ____ from: ____
Prompt template: drafting an exception report (approved AI tool)
Using ONLY the forecast table and issue notes below, draft an exception report in the template above.
Quantify each option's impact using figures from the table; if a figure is missing write [TO ESTIMATE].
Keep it under 350 words, neutral in tone, and list any assumption you made.
The project manager verifies every figure and owns the recommendation.
How to measure success
- Median time from escalation to decision (target: days, not weeks).
- Every key decision has exactly one named decider.
- Board time spent on exceptions and strategic choices rather than status updates.
Video lecture: Project governance and decision rights
Lecture coming soon · 9 chapters · about 8 minutes. Read the full transcript below.
- Who decides, and when?
- Why it matters
- The concept: roles and tolerances
- Decision rights and stage gates
- Worked example one: a small tolerance sheet
- Worked example two: the Riyadh bank redesign
- Watch me do it: a one-page decision rights summary
- Governance in regulated environments, and mistakes
- Recap and try this now
Lecture transcript
Who decides, and when?
A bank in Riyadh, and it's a fictional one, had a steering committee of fourteen people that met once a month to review a forty-slide status pack. Decisions that should have taken a day took months. Everyone was busy governing, and nothing was being decided. Sound familiar? In this lecture you'll learn what project governance really is, and what it isn't. We'll cover the core roles, the idea of tolerances and management by exception, a clear way to assign decision rights, and how stage gates work in both predictive and agile settings. By the end, you'll be able to draft a tolerance sheet and a one-page decision rights summary that makes your project faster and safer at the same time.
Why it matters
Why does governance matter? Because every decision that waits costs money. Teams idle, options expire and people make assumptions that later have to be undone. Unclear authority creates a different problem: two people both think they decide, or nobody does, and the argument surfaces at the worst possible moment. And the opposite extreme, where every small choice goes to the board, crushes the team's autonomy. Good governance is the sweet spot. It gives the team freedom to act within clear limits and guarantees that the right people decide the things that genuinely need them. As the PMBOK Guide's eighth edition puts it, governance is the system that holds the other performance domains together.
The concept: roles and tolerances
Here's the key idea. Governance is about decision rights, not meetings. Think of it like driving lessons. The learner drives, the instructor sits beside them, and there's an agreed set of situations where the instructor takes over. In projects, the sponsor owns the business case, the why. A small board or steering group makes decisions beyond the project manager's authority and represents the business, users and suppliers. The project manager runs the project day to day. And tolerances, an idea central to PRINCE2 and widely used elsewhere, set the agreed limits. For example, plus or minus five per cent on cost and three weeks on the end date at project level. Inside tolerance, the project manager acts freely. If a forecast breaches it, they escalate with options. That's management by exception.
Decision rights and stage gates
To make decision rights explicit, many organisations use a model inspired by RAPID: who recommends, who must agree, who decides, who performs and who provides input. The rule that matters most is one decider per decision. Then stage gates. A stage gate is an evidence-based go or no-go decision at the end of a phase: is the business case still valid, are risks acceptable, is the next stage planned and funded? In predictive projects, gates sit at the end of design, build and test. In agile delivery, gates move to release decisions and funding points, with the board looking at working product and value delivered rather than documents. The principle is the same: decide on evidence, at the right level, at the right time.
Worked example one: a small tolerance sheet
Let's build a simple tolerance sheet, with illustrative numbers from the lesson. At project level: plus or minus five per cent on cost, plus or minus three weeks on time, must-have scope fixed, and no new very high risks left unmitigated. At stage level: plus or minus seven per cent and two weeks, with could-have scope flexible. At work package level: plus or minus ten per cent and one week, against the product description. And the escalation rule: a forecast breach means an exception report within three working days. Now watch what this does. A work package manager who forecasts eight per cent over budget doesn't need permission to act. A project manager forecasting a four-week slip must escalate with options. Everyone knows exactly where the line is, so nobody has to guess.
Worked example two: the Riyadh bank redesign
Now back to the fictional bank in Riyadh and its digital onboarding project. The governance redesign cut the board from fourteen people to five: the sponsor, the product owner, the technology lead, the risk and compliance lead, and a finance partner. It introduced tolerances. It replaced the forty-slide status pack with a two-page, exception-based report. Routine items were delegated to the project manager and product owner. Only tolerance breaches and genuinely strategic choices came to the board. The result: decision cycle time fell from weeks to days, and the team gained real autonomy within clear limits. Notice that nobody lost control. The board actually had more control, because it spent its time on the few decisions that mattered.
Watch me do it: a one-page decision rights summary
Let me show you how I build the decision rights summary on day one. I list the ten decisions that will actually matter: scope changes beyond tolerance, vendor selection, release go or no-go, budget reallocation, key hires, risk acceptance, and so on. Across the top, the roles: sponsor, board, project manager, product owner, technical lead, risk and compliance. In each cell, one letter: recommend, agree, decide, perform or input. Then a check column that counts the D's in each row. It must be exactly one. Here, 'release go or no-go' has two deciders, the product owner and the technical lead. That's an argument waiting to happen, so I fix it now: the product owner decides, the technical lead must agree on technical readiness. Finally, I add the tolerance and the escalation route. It fits on one page, and it prevents weeks of confusion.
Governance in regulated environments, and mistakes
In regulated environments, such as banking, healthcare and the public sector, governance carries extra weight. Compliance and risk functions often hold agree or decide rights over specific choices, and decisions and their rationale need to be recorded for audit. A simple decision log, with the date, the decision, the rationale and who decided, protects everyone. Now the common mistakes. Boards that are too big to decide anything. No tolerances, so everything escalates or nothing does. Stage gates treated as paperwork rather than genuine go or no-go decisions. An absent sponsor who delegates the business case and then disowns the outcome. And governance so heavy that teams quietly route around it, which is worse than having none.
Recap and try this now
Let's recap. Project governance is the system of decision rights that lets a team act freely within limits and guarantees the right people decide what genuinely needs them. The sponsor owns the business case, a small board decides beyond tolerance, and the project manager manages within it. Tolerances make escalation automatic and remove micromanagement. Decision rights should be explicit, with exactly one decider per decision. And stage gates, whether at phase ends or release points, are evidence-based go or no-go decisions. Here's a quick self-check: can everyone on your project name who decides on a scope change beyond tolerance? Your try-this-now: draft a tolerance sheet and a one-page decision rights summary, recommend, agree, decide, for a project you know.
Key takeaways
- Governance defines who decides what, on what information, with what accountability.
- The sponsor owns the business case; the PM delivers within tolerances set by the board.
- Management by exception: escalate when forecasts breach tolerance, with options.
- Stage gates re-check business case validity; stopping early can be good governance.
Try it
Draft a tolerance sheet and a one-page decision-rights summary (who recommends, agrees, decides) for a project you know.