Skip to content

Lesson 1 — Governance and Decision Rights

At a glance

Learning objectives

By the end of this lesson you should be able to:

  1. Distinguish governance that decides from governance that merely reviews, and explain why the difference determines whether a project can move.
  2. Write a decision rights table that names the decision, the decider, the limit, and the escalation route.
  3. Design a change control process with proportionate thresholds, including an emergency path that does not become the normal path.
  4. Explain what a configuration baseline is for, and what breaks when documents and code are versioned differently.
  5. Identify the conditions under which additional governance makes delivery worse rather than better.

Prerequisites

  • Module 02, on stakeholders and governance — this lesson assumes you can already write a RACI matrix.
  • Module 11 Lesson 3, on change and configuration management — this lesson extends it to the organisational level rather than re-teaching it.

Introduction

Every project has governance. The question is whether it is designed or inherited. Inherited governance is usually a steering committee that meets monthly, an approval queue, and a set of documents nobody reads until an audit. It is not that these structures are pointless; it is that they were assembled by accretion and nobody can say which decision each one exists to make.

The failure mode is not corruption or incompetence. It is latency. A project that must ask permission for a three-day change, and waits eleven days for the answer, has not been governed — it has been slowed, and the people in the project have learned to stop asking. That learned behaviour is the expensive part, because the escalations that genuinely mattered stop happening too.

This lesson treats governance as three concrete artefacts you can write: a decision rights table, a change control process with thresholds, and a configuration baseline. Everything else about governance — committee composition, reporting cadence, assurance reviews — follows from those.

1. What governance actually decides

Governance is the set of arrangements by which someone outside the project decides what the project may do, and holds it to account for doing it. Stripped of vocabulary, it answers five questions:

Question If it is unanswered
Who can approve a change to scope, schedule, or cost? Changes happen anyway, unrecorded
What is the project's tolerance for variance before it must escalate? Every variance escalates, or none does
Who confirms the project is still worth doing? Nobody can stop it
Who accepts the deliverable? The project ends without closure
Who owns the benefits after closure? Nobody measures whether it worked

A governance arrangement that cannot answer these five is not governing; it is meeting. Notice that none of them require a committee. In a small organisation the sponsor may answer all five, and that is perfectly adequate governance — the questions are what matter, not the structure.

Assurance is a separate function: independent checking that what the project reports is plausible. Its value is highest where the project is large, novel, or regulated, and lowest where the people checking have no way to form an independent view and simply re-read the project's own reports. Assurance that repeats the project manager's numbers adds cost and no information.

2. Decision rights, not responsibility

A RACI matrix (see the template) says who does what. It does not say who may decide what, and it does not say when a decision must escalate. That is a decision rights table, and it is the single most useful governance artefact on a project.

Decision Decider Limit Escalates when Timescale
Correct a defect inside agreed scope Technical lead Any effort the team can absorb within the current iteration It displaces committed work Same day
Change a requirement's behaviour Product owner ≤ 3 person-days and no milestone moves Above the limit, or a milestone moves 2 working days
Add scope not in the baseline Sponsor ≤ 5% of budget Above the limit, or launch date at risk 5 working days
Re-baseline schedule or budget Steering committee — Always At the next scheduled meeting, or within 10 days for a material change
Release to production Business owner Any change meeting the definition of done A known P1/P2 defect would ship Same day
Stop the project Sponsor with steering committee — Always Within one cycle of the evidence

Three properties make this table work, and each is a design choice worth arguing about:

  • A limit with a number. "Small changes" is not a limit. A named effort or percentage is, and it lets a developer decide without a meeting.
  • A timescale. A decision right with no response time is a queue. The timescale column is what makes the table usable by people who are waiting.
  • An explicit escalation route. Escalation is not failure; it is the designed path for decisions above your limit, and people should be able to take it without it being read as a complaint.

3. Governance structures, and what each is for

Structure What it exists to do Where it fails
Sponsor Owns the business outcome and the money Sponsor who is interested but has no authority to release funds or people
Steering committee Cross-functional decisions: scope, priority, resourcing conflicts Monthly cadence on a project that changes weekly
Change control board Decide changes that exceed delegated limits Becomes a queue for trivial changes because no limits were delegated
Assurance or review function Independent check on plausibility Repeats the project's own reporting and adds no information
Programme board Resolve between projects: shared people, dependencies, priorities Treating a portfolio problem as a project problem
Project management office (PMO) Capability, standards, and information across projects Directive PMO imposing process regardless of project type

The last row is the one people argue about. A useful way to think about a PMO is by degree of control: supportive (provides templates, coaching, and reporting), controlling (requires compliance with methods), or directive (takes over management of projects). Each is legitimate in some organisations and destructive in others. A controlling PMO on a small adaptive product team adds overhead without adding information; a supportive PMO in a regulated environment may be too weak to provide the evidence an audit requires. The choice is a real one, and it is usually made by accident.

4. Change control with proportionate thresholds

Change control goes wrong in two ways that look like opposites and have the same cause: either everything needs approval, or nothing does. Both are consequences of not deciding thresholds.

A workable design has four parts:

  1. Delegated limits — the bands in the decision rights table, expressed in effort, money, or schedule effect.
  2. One form, one log. Every change, including the ones approved instantly, gets an ID and a row in the change log. The log is the audit trail, not the meeting.
  3. An assessment before a decision: scope, schedule, cost, quality, risk, and other work affected. For small changes the assessment is a sentence; the requirement is that it exists.
  4. An emergency path that is genuinely exceptional. A path that skips assessment for "urgent" work becomes the default. Constrain it: who may invoke it, what must be recorded within 24 hours, and a standing review of every use.
Change size Path Recorded within
Inside the iteration's agreed capacity Team decides, no escalation The iteration's normal record
Above delegated limit, no milestone effect Product owner decides on the assessment 2 working days
Milestone, budget, or regulatory effect Steering committee, with options Next meeting or 10 days
Emergency (production incident, legal obligation) Named role acts, reviewed afterwards 24 hours

The test of a change process is what people do with a change they think will be refused. If they implement it quietly, the process has failed regardless of how well documented it is.

5. Configuration baselines: what they are for

A configuration baseline is the identified, versioned set of things that together define what the project has agreed to deliver — requirements and scope statement, schedule and cost baseline, design decisions, release contents, and the interfaces to other systems. Its purpose is not tidiness. It is to make one sentence answerable: what did we agree to, and what has changed since?

Three failure patterns are common enough to be worth naming:

  • Versioned code, un-versioned agreements. The repository is scrupulous; the requirements document exists in four copies in three email threads. The change log then cannot be reconciled with reality.
  • Approved changes never reaching the baseline. The change was decided, the work was done, and the baseline still shows the old figure — so every later variance is unexplainable.
  • Interface baselines owned by nobody. When two systems must agree, the interface definition needs an owner and a change route. Where it does not, the integration slips and each side blames the other.

A minimum viable configuration baseline for a small project: an agreed scope statement with a version, a schedule and budget version, the requirements list with IDs, and a single log where every change to any of them is recorded. That is achievable by one person with a spreadsheet.

6. Where governance stops helping

Situation What additional governance does
Genuinely novel work with unknown requirements Approval cannot assess what is not yet understood; frequent small checkpoints beat infrequent large ones
Small co-located team, single stakeholder Adds latency to decisions one person could make
Highly competitive market with short windows Governance optimised for cost control loses the window; cost of delay dominates
Regulated deliverable Justified, but should be scoped to the obligation rather than applied to everything
Delivery already slow for reasons inside the team More reporting produces better descriptions of a problem it does not fix

The honest limitation: governance cannot substitute for capability. If a team cannot estimate or test, no amount of review will make it deliver. Governance is at its worst when used as a control mechanism for a problem that is actually a skills, staffing, or clarity problem — and the artefacts will multiply while the outcome stays the same.

A second limitation is that decision latency is invisible in governance reporting. Committees report decisions made, not days lost waiting. Tracking the median time from escalation to decision is one of the few measures that exposes it, and almost nobody collects it.

Key terms

Term Meaning
Governance The arrangements by which authority is exercised over a project and accountability is established
Decision rights Who may decide what, within which limit, and who decides above it
Escalation threshold The point at which a decision must move to a higher authority
Assurance Independent checking that a project's reported position is plausible
Change control board The body that decides changes above delegated limits
Configuration baseline The versioned set of scope, schedule, cost, design, and release definitions the project has agreed
Decision latency Elapsed time from escalation to decision — the governance cost that is rarely measured
Emergency change A change taken without prior assessment under a constrained, logged exception path

Worked example

Task: design governance for the admission portal — a fixed-date, publicly visible, regulated project with one external integration and a steering committee that meets monthly. Figures are invented for teaching.

Step 1 — Answer the five governance questions before designing any structure. The sponsor owns the business outcome (admissions conversion and staff effort); the steering committee confirms the project is still worth doing at each milestone; the business owner accepts the deliverable; the admissions office owns the benefit after closure; and the project manager owns delivery. Writing this first makes the committee's remit obvious — and its remit is not approving small changes.

Step 2 — Write the decision rights table with numbers. Defect corrections inside scope: technical lead, same day. Requirement behaviour changes: product owner up to 3 person-days and no milestone movement, decision within 2 working days. New scope: sponsor up to 5% of budget, decision within 5 working days. Re-baselining: steering committee, always. The limits were set by asking the team how much rework they could absorb without displacing committed work — 3 days was their answer, not a benchmark from a book.

Step 3 — Set the change thresholds and the emergency path. Anything inside the iteration's capacity is the team's decision. The data-protection officer is named as the role that may invoke the emergency path for a suspected breach, and every use is reviewed at the next committee meeting. Note that the emergency path exists because the scheduled path would be too slow for that class of event, not because the normal path is inconvenient.

Step 4 — Identify the configuration baselines and their owners. Four: scope statement (product owner), schedule and budget (project manager), requirements list with IDs (business analyst), and the student-records interface definition (technical lead, with a named counterpart at the records office). Naming the counterpart matters — the interface baseline is jointly owned or it is not owned.

Step 5 — Measure decision latency and report it. From week 4 the project records the date each escalation was raised and the date it was decided. The first month's median is 9 working days against a 5-day target, and the cause is that two of the three escalations waited for the monthly committee. The response is a standing deviation authority: the sponsor may decide between meetings on scheduled committee business, subject to ratification. The governance changes because a measurement exposed the cost — not because anyone was performing badly.

Step 6 — Test the design against the failure question. If a developer wanted to make a change she believed would be refused, what would she do? The answer should be: put it through the 2-day path, where a refusal comes with a reason and a decision record. If the honest answer is "do it quietly", the design is not finished — and that test is worth running with the team rather than on paper.

Common misconceptions

“More governance means better control”

Control is a function of decision latency and whether decisions are followed, not of the number of artefacts. A monthly committee that decides in ten days controls less than a delegated limit that decides in two, because the second is fast enough to be used.

“The steering committee should approve changes”

It should approve changes above the threshold you set. A committee that reviews every change becomes the bottleneck, and its members stop reading the papers — which is worse than delegating, because the appearance of control remains while the substance has gone.

“A change log is bureaucracy”

The log is what makes the difference between an explainable project and an unexplainable one. Its cost is one row per change. Its value appears the first time someone asks why the finish date moved and nobody can remember.

“Assurance replaces trust”

Assurance across a large project can be genuinely useful. Assurance that re-reads the project's own status report is a cost with no information. The question to ask of any review is: what could this function discover that the project does not already know?

Practical activity

Design governance for a project you can actually see — your capstone, or a project at work.

  1. Answer the five governance questions in the table in section 1, in writing. If any answer is "nobody", mark it and say who should own it.
  2. Write a decision rights table with numeric limits and a response timescale for each row. Aim for five to seven rows; if you need fifteen, the limits are too low.
  3. Define the change thresholds, including who may invoke the emergency path and what must be recorded within 24 hours.
  4. List the configuration baselines with a named owner for each, including any shared interface.
  5. Run the failure test: ask the people doing the work what they would do with a change they believed would be refused. Record the honest answer, and one change you would make as a result.

What "good" looks like: limits small enough that the team rarely needs to escalate, a timescale on every row, at least one thing the sponsor has decided not to be consulted on, and an honest failure test rather than a predicted one.

Self-assessment

  1. What is the difference between a RACI matrix and a decision rights table, and why do you need both?
  2. Why is decision latency a better indicator of governance quality than the number of committee meetings?
  3. A project has a change control board that meets fortnightly and reviews all changes. What is likely to happen within two months, and what would you change?
  4. Give one situation in which adding governance genuinely reduces delivery performance, and say what you would do instead.

  5. Why does an emergency change path need a standing review of its own use?

  6. Apply it — steering committee. A steering committee of eleven people meets monthly and reviews every change request, including one-line configuration edits. Decisions that used to take a day now take a month, and two project managers have started implementing changes while waiting “so the committee can ratify them later”.

    Hint: A strong answer says what governance artefact is missing and what belongs in it.

Show answers
  1. The RACI says who does the work, who is accountable, and who is consulted or informed. It does not assign authority, and it has no concept of a limit or of escalation. The decision rights table assigns authority with numeric limits and response times. A project needs both: the RACI to know who acts, and the decision rights table to know who may decide, so that ordinary decisions do not wait for a meeting.
  2. Because governance exists to enable decisions. Meetings are an input; decisions are the output, and what determines whether the project moves is the elapsed time between needing a decision and having one. A committee that meets fortnightly but decides escalated items within two days may be effective; one that meets weekly and takes ten days is not.
  3. People will either stop raising changes or implement them quietly, because waiting two weeks for a trivial approval is not a rational choice when a deadline is close. The change log will look reassuringly small while the baseline drifts. The fix is delegation: set numeric limits so most changes never reach the board, and let the board handle only those above the limits.
  4. Novel work with genuinely unclear requirements: approval cannot assess what is not yet understood, so the process approves guesses and then evaluates the consequences. Replace infrequent large approvals with short checkpoints where someone senior can see working software more often.
  5. Because an exception path that is never reviewed drifts into being the normal path — usually for work that is urgent rather than exceptional. A standing review of every use keeps it exceptional and produces evidence about which classes of change the normal path is too slow for, which is often a reason to change the thresholds.
  6. Governance here reviews but does not decide, which is why it has become a queue. What is missing is a decision rights table: for each class of decision — scope changes above a stated limit, budget reallocation, tolerance breaches, design authority, acceptance — name the decider, the numeric limit, the evidence they need, and the escalation route. One-line configuration edits belong to the team lead, not to eleven people; a change above the threshold belongs to the committee. Replace “small change” with a number, and give each row a response time so a decision cannot sit indefinitely. Two things then need attention: the work being done in advance of the decision is a real risk — it converts a decision into a fait accompli and means the baseline is no longer trustworthy, so it needs addressing directly rather than generously ratifying; and governance that decides at a known speed also needs to be able to say no, which is the reason the thresholds must be pre-agreed.

Summary

  • Governance exists to make decisions at a known speed with a known authority; its five questions are approval, tolerance, continued justification, acceptance, and benefit ownership.
  • A decision rights table with numeric limits and response times is the artefact that makes this real. Replace "small change" with a number.
  • Change control fails in both directions — everything approved or nothing approved — and the cause is missing thresholds. Delegated limits, one log, assessment before decision, and a constrained emergency path are the four parts.
  • A configuration baseline exists so that "what did we agree, and what has changed?" is answerable. Versioned code with un-versioned agreements is the commonest failure.
  • Governance cannot substitute for capability, and its most common cost — decision latency — is almost never measured. Measure it before adding another review.

Further learning

The PMBOK® Guide (Project Management Institute) describes governance and change control as part of project integration, and the Standard for Portfolio Management (also PMI) addresses portfolio-level authority; neither is required reading for this lesson, but both are verifiable places to look for a different vocabulary for the same questions.