Choosing a Project Governance Model

Most project managers never choose a governance model. One arrives with the project, already fixed by the funding route, the sponsoring directorate or whatever the last programme used, and the first few weeks are spent learning its rhythms rather than questioning its design. The question of which model is appropriate usually surfaces later, and in a less comfortable form: the board meets monthly but the work needs a decision this week, or a decision that should have taken an hour has been sitting with three people for a fortnight because nobody is certain whose it is.

A governance model is appropriate when it puts each type of decision at the level that holds both the information and the authority to make it, reviews the project often enough to catch problems while they are still cheap to fix, and leaves enough evidence for whoever will eventually be held accountable. Nearly everything else about a governance structure is preference, habit or inheritance.

What a governance model has to settle

Whatever it is called, a governance model has to answer five questions, and it is worth checking that yours answers all of them rather than only the ones that were easy to write down.

The first is decision rights: which decisions the project manager makes alone, which the project team makes, which the sponsor makes, and which need a board. The second is thresholds: the points at which a decision stops being local, expressed in something measurable such as cost, delay, scope commitment, risk exposure or contractual effect. The third is cadence: how often the project is reviewed, and whether that rhythm matches the rate at which the work actually generates decisions. The fourth is evidence: what a decision-maker needs in front of them to decide properly, which is rarely the same as a status report. The fifth is funding: how money is committed, and how often that commitment can be revisited.

A structure that covers reporting but not decision rights is not a governance model. It is a communication plan with a committee attached. The clearest symptom is a steering group that receives information every month and has never actually said no to anything.

The Governance Performance Domain in the PMBOK® Guide Eighth Edition treats this as a matter of selection and tailoring rather than a single correct structure, and Section 2.1.2 deals specifically with project governance models. That framing matters, because it removes the idea that there is a compliant answer waiting to be found. Project governance also sits inside the organisation's wider governance arrangements, so the practical scope of the choice is usually narrower than it first looks: much is inherited, and the real work is deciding what happens within it.

Sizing the model to the project

Governance intensity should follow consequence, not project value. A large but reversible decision often needs less oversight than a small decision that cannot be undone. Five questions size the model reasonably well.

How reversible is a wrong decision? If a poor choice can be corrected next iteration at the cost of a fortnight, the model can be light. If it commits a manufacturing tolerance, a public contract or a safety case, it cannot.

How quickly do decisions actually need to be made? Count the decisions the work generates in a typical month, then compare that with how often the deciding body meets. A team producing weekly priority questions inside a monthly forum will either wait or proceed unauthorised, and both are governance failures.

Where does the money sit, and how often can it be re-decided? Annual capital allocation and rolling quarterly funding produce genuinely different models. Continuous funding without any re-decision point is not agility, it is an absent gate.

Who outside the project needs to see the reasoning? Regulators, auditors, customers, insurers and safety assessors all impose evidence requirements that no amount of streamlining can remove. If the reasoning has to survive scrutiny in two years, it needs recording at the time.

How much delegated authority has the team earned? Capability and track record are legitimate inputs. Delegation is a judgement about the people doing the work, not a philosophical position about empowerment.

The models most projects choose between

Real models are usually combinations, and the names below are descriptions rather than products.

Stage-gated authority. Funding and permission are released in phases, with a decision point between each. This suits work with long lead times, high commitment costs and contractual or regulatory milestones. Its failure mode is ceremonial: a gate that has never rejected anything is a reporting event wearing a gate's clothing.

A standing board with delegated thresholds. The project runs continuously, the project manager and team decide inside defined limits, and anything breaching a threshold escalates. This fits a great deal of organisational change work. Its failure mode is vague thresholds, which quietly return every decision to the board.

A single accountable decision-maker with frequent review. A sponsor or product owner holds the authority, funding is committed in rolling increments, and review happens at the delivery cadence rather than in a monthly forum. This suits adaptive product work where priorities move faster than any committee can meet. Its weaknesses are absence and succession, and a thinner evidence trail than regulated work can tolerate.

Nested governance. The project sits inside a programme or portfolio and the model is largely given. The useful conversation is not which model to adopt but which decisions stay local and which genuinely belong upwards.

Dual-track hybrid. Predictive governance over commitments, external milestones and regulatory evidence, combined with adaptive control over how the increment is built. This is a legitimate and common answer, provided it results from the shape of the work rather than from a wish to appear modern.

Changing a model that is already running

Consider a mid-sized manufacturer installing a new packing line while also replacing the scheduling software that will run it. Governance was inherited from the capital estate: a monthly capital board, gate approvals at design, order and commissioning. For the line itself this works well, because the commitments are large, irreversible and infrequent. For the scheduling change it works badly, because sequencing questions arrive weekly and each delay pushes the software work out of step with the installation.

The instinctive response is to ask for a second, faster board. The better move is to split the decision types rather than add a forum. The capital board keeps the gates and any commitment above an agreed figure. The operations director takes a standing delegation for scheduling scope and sequencing within a defined budget envelope, with exceptions reported to the board rather than pre-approved by it. Nothing new meets. What changes is who is allowed to decide what, written down where both sides can see it.

That is generally how a governance change should be proposed: with evidence of the decisions that waited and what the waiting cost, the smallest adjustment that would fix it, and an agreed point at which the adjustment is reviewed. Governance can be tailored during a project, not only designed at the start, and a model that was correct at initiation may be wrong by the second phase.

For a PMP candidate, the useful habit is recognising which decision belongs where before considering how to act. The current Examination Content Outline includes a Business Environment task on defining and establishing project governance, covering structure, rules, procedures, reporting and policy drawn from organisational process assets, alongside defining success metrics and outlining escalation paths and thresholds. Scenario questions in that territory tend to reward reading the authority in the situation rather than naming a model. Candidates who have only ever worked inside one governance structure often answer from habit, which is one reason our PMP® Exam Preparation course works through decision rights and thresholds across predictive, adaptive and hybrid contexts rather than treating governance as a vocabulary topic.

On a live project, the practical test is simpler. Look at the last ten decisions your project needed. Note who made each one, how long it took and whether the person deciding had the information to decide well. If several were made by people without the relevant knowledge, the model is escalating too much. If several were made informally by people without the authority, the model is escalating too little. That evidence, gathered over a few weeks, is worth more in a governance conversation than any diagram of committees.

Andre Malowney

Interested in going further?

Governance questions rarely announce themselves, and the difference between escalating properly and escalating out of discomfort is one of the harder judgements to develop alone. Structured preparation gives you enough worked situations to recognise the pattern before you have to decide under pressure.

The Governance Performance Domain in the PMBOK® Guide Eighth Edition is the fuller treatment of the material behind this article, including how governance interacts with the other domains.

Ad · Amazon affiliate link.

References

A090: Project Governance Explained: Who Decides What, and Why
A091: Project Governance vs Organisational Governance: What's the Difference?
A096: How to Recognise a Governance Question on the PMP Exam
A094: Governance Metrics That Actually Tell You Something
A053: AI Governance for Project Managers

PMP and PMBOK are registered marks of the Project Management Institute, Inc.