Definition

What is project governance?

Project governance is the arrangement of decision rights, accountabilities and records that determines who can commit money to a project, on what evidence, and where the reasoning gets written down.

7
min read
Project governance is the arrangement of decision rights, accountabilities and records that determines who can commit money to a project, on what evidence, and where the reasoning gets written down.

Project governance is the arrangement of decision rights, accountabilities and records that determines who can commit money to a project, on what evidence, and where the reasoning gets written down. Three questions sit underneath it. Who decides. What is in front of them when they decide. And whether anyone can reconstruct that decision a year later without relying on memory.

Everything else filed under the heading — the reporting rhythm, the templates, the standing calendar invitations — is machinery in service of those three questions. You can remove a fair amount of it without weakening the governance at all, which is worth knowing before you inherit someone else's process and assume all of it is load-bearing.

Governance has a bad name for a reason. Most people have only ever met the bureaucratic version, which is a monthly meeting they attend without deciding anything, a template someone in the PMO asked for, and an approval that was never realistically going to be withheld. That experience is common enough that the word now reads as overhead to a lot of capable people. They are not wrong about what they were shown. They are wrong to conclude the underlying thing is unnecessary.

Governing the work and governing the investment

Two different jobs get called project governance, and confusing them is where most of the trouble starts.

Governing the work asks whether delivery is going well. Is the scope holding, are the dependencies managed, is the quality acceptable, is the team blocked. That question is asked constantly, by people close to the work, and a bad answer is felt immediately. Teams are generally good at it because the feedback loop is short.

Governing the investment asks a colder question. Given what we now know, would we fund this again today? The return that justified the spend was a forecast written before anyone had built anything. Six months in, the cost is higher, the scope has moved, a competitor has shipped something, and the person who wrote the case has changed roles. Nobody feels the decay of an investment case day to day, which is exactly why it has to be scheduled. Delivery discipline will not produce this answer as a side effect, no matter how good the delivery is.

This is also where the objection about agile usually lands, and it deserves a straight answer rather than a dismissal. Agile methods govern how work gets done — short cycles, decisions pushed to the people closest to the problem, working software over documents about software. That is governing the work, and it is often better at it than any committee has ever been. It does not answer whether the organisation should keep funding the thing. Different altitude, different person, different clock.

The roles that carry weight

The sponsor is the person who can stop it. Not a committee, not a function, a named individual who owns the return rather than the delivery. The test is whether anything of theirs moves with the outcome — budget, reputation, a target they are measured against. If nothing does, the seat is decorative and the approvals coming out of it are formalities.

The project manager assembles the evidence and runs the work, and does not decide the investment. That separation matters more than it sounds. It also creates a structural problem. The pack that supports the decision is usually built by the person whose work is being assessed, on the Tuesday before a Thursday meeting. It is a curated argument, and it is out of date before it is presented. The fix is not to distrust the project manager. The fix is a record that stays current on its own, so the pack is a view of something rather than a construction.

A steering committee is a room of approvers, and most of them are attendees. An approver has something to withhold — money, people, access to a system, an operational go-live, a signature. An attendee has an opinion and a calendar entry. Committees drift towards attendees because adding someone is polite and removing them is awkward. A room with six attendees and one approver produces a briefing, and the decision gets made somewhere else afterwards, usually in a corridor and usually without a record.

What governance is not

Status reporting is not governance. A report describes; governance decides. The report tells you the forecast has moved 15% above baseline. Governance is the moment someone with authority looks at that number and chooses to fund it, cut scope, or stop. Organisations that produce excellent reporting and no decisions have built an expensive observation deck.

A meeting cadence is not governance either. The monthly steering meeting is a container, and a container that has never held a difficult decision is not evidence of much.

Nor is a document set. Templates carry evidence, and evidence is necessary, but the artefacts sit downstream of the decision rights. Filling in a business case template for a project whose funding was settled in a corridor produces a document and nothing else.

Compliance is the closest lookalike and the most misleading. Audit-driven process optimises for demonstrating that the steps were followed. Whether the calls were any good is a different question, and it does not appear on the checklist.

The minimum that counts

For a single program with one sponsor, the honest minimum is small. A written case that states the problem, the expected return and the scope bounds. A baseline frozen when the case is approved, so variance means something later. A named sponsor with the authority to stop. A log of decisions with the evidence attached. And scheduled points where continuing is a genuinely open question. Five things. They can live in one place and be reviewed in an hour a month.

A portfolio needs one thing more, and it changes the shape. The portfolio question is not whether a project is going well but which of several deserves the next dollar of a fixed capacity. Comparison only works if the cases are built the same way — the same discount rate, the same horizon, the same definition of a benefit. Otherwise you end up weighing a three-year IRR against a seven-year NPV and choosing whichever was written more persuasively. A portfolio also needs a working mechanism to stop things, or it only accumulates and the capacity goes to whoever is most senior.

Where governance fails

It only ratifies. By the time the meeting happens the budget is allocated, the team is hired and the vendor contract is signed, so reversing costs more than continuing. The decision was made months earlier by a series of commitments nobody called a decision. The symptom is easy to check. Ask when a gate last produced a stop, and count how long the silence runs.

Nobody can trace it. The decision was real and well reasoned at the time. Six months later somebody asks why the migration was descoped, and the four people in the room remember four different reasons, two have moved on, and the answer lived in a conversation and a deleted slide. A decision without its evidence attached is a rumour with a date on it. The cost lands later, when the next case has to be argued from scratch because nothing from the last one survived.

It is heavy enough to route around. Every change needs a paper, the committee sits monthly, and the approval takes three weeks. Teams adapt rationally. They size changes just under the threshold, or they do the work and paper it afterwards. The weight does not stop the change, it drives it underground, and the record goes with it. Make the process heavier than the work can carry and people stop writing anything down.

The test

Two questions settle whether governance is real. Could this decision have gone the other way? And can you find out, six months from now, why it went the way it did?

If the first answer is no, the meeting ratified something that was already settled. If the second answer is no, you have an outcome with no reason attached, and somebody will argue the same ground again next year at full price. Governance that cannot say no and cannot be traced is not governance, it's paperwork with a quorum.

What makes both answers yes is unglamorous. The record has to be the source rather than a reconstruction, kept current as a by-product of the work, so the decision-maker is looking at the position rather than at somebody's account of it. Then a no is possible, because the evidence for it is already on the table.

Tollgate runs investment governance inside Jira — a versioned business case with its financial model, work packages baselined at approval, a risks and opportunities register, an append-only decision log recording who decided, when and on what evidence, and change requests that carry their budget and schedule impact. Forge-native, so the data stays in your own Atlassian tenancy.

See how it works · Start free on the Atlassian Marketplace

See the method running in Jira

Tollgate keeps the business case, the gate decisions and the payoff in one record, next to the delivery they pay for.