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. This article covers the roles that carry weight and three ways governance fails.
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? Can anyone reconstruct the decision a year later without relying on memory?
The reporting rhythm, the templates, and the standing calendar invitations all get filed under the same heading, and they are 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 carries load.
Governance has a bad name for a reason. Most people have only met the bureaucratic version: 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, and they are right about what they were shown. The mistake is to conclude that the underlying job is unnecessary.
Two different jobs get called project governance, and mixing them up 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? People close to the work ask these questions constantly, 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. An investment case decays too slowly for anyone to feel it day to day, so the question has to go on a schedule. Delivery discipline will not produce this answer as a side effect.
The agile objection usually lands here. It deserves a straight answer. Agile methods govern how work gets done, through short cycles, decisions pushed to the people closest to the problem, and working software over documents about software. Agile teams often do that better than any committee has. Whether the organisation should keep funding the thing is a separate question, asked at a different altitude, by a different person, on a different clock.
The sponsor is the person who can stop the project. That means a named individual who owns the return, since a committee or a function can only ever share it. The test is whether anything of theirs moves with the outcome, such as budget, reputation, or a target they are measured against, and 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. The investment decision belongs to someone else. That separation matters more than it sounds, and it also creates a structural problem, because the pack that supports the decision is usually built by the person whose work is being assessed, for example on the Tuesday before a Thursday meeting. That pack is a curated argument, and it is out of date before it is presented, so the fix is a record that stays current on its own, with the pack as a view of that record.
A steering committee is a room of approvers, and most of them are attendees. An approver has something to withhold, whether that is money, people, access to a system, an operational go-live, or 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. The decision gets made somewhere else afterwards, usually in a corridor and usually without a record.
Status reporting is the most common stand-in. A report describes; governance decides. The report tells you the forecast has moved 15% above baseline, and 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 gets mistaken for governance too. The monthly steering meeting is a container. A container that has never held a difficult decision proves very little.
Then there is the document set. Templates carry evidence, and evidence is necessary, but the artefacts sit downstream of the decision rights, so 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 showing that the steps were followed. Whether the calls were any good is a separate question, and the checklist leaves it out.
For a single program with one sponsor, the minimum is small. It has five parts: a written case that states the problem, the expected return, and the scope bounds; a baseline frozen when the case is approved, so that 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 an open question. All five can live in one place, and one monthly session is enough to review them.
A portfolio needs one thing more, and it changes the shape. The portfolio question is which of several projects deserves the next dollar of a fixed capacity. Comparison only works if the cases are built the same way, with the same discount rate, the same horizon, and the same definition of a benefit. Otherwise you end up weighing a three-year IRR against a seven-year NPV. You choose whichever was written more persuasively. A portfolio also needs a working mechanism to stop things, because without one it only accumulates, and the capacity goes to whoever is most senior.
Governance that only ratifies meets after the budget is allocated, the team is hired, and the vendor contract is signed, so reversing costs more than continuing. A series of commitments that nobody called a decision settled the matter months earlier. The symptom is easy to check. Ask when a gate last produced a stop, and count how long the silence runs.
Governance nobody can trace loses its reasons. The decision was real and well argued at the time, and six months later somebody asks why the migration was descoped. 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.
Governance heavy enough to route around asks for a paper on every change, sits monthly, and takes three weeks to approve. Teams adapt, and the adaptation is rational. They size changes just under the threshold, or they do the work and paper it afterwards. The weight pushes change underground, and the record goes with it. Make the process heavier than the work can carry and people stop writing anything down.
Two questions settle it. 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, and if the second answer is no, you have an outcome with no reason attached, so somebody will argue the same ground again next year at full price.
What makes both answers yes is unglamorous. The record has to be the source, kept current as a by-product of the work, so that the decision-maker is looking at the position itself. A no becomes possible then. The evidence for it is already on the table.
Tollgate runs investment governance inside Jira. It holds a versioned business case whose financial case calculates NPV, IRR, and payback from the cashflows you enter. The approved baseline stays fixed, and changes go through change control. Risks & Opportunities sit on the same record, along with an append-only decision log that records who decided, when, and on what evidence, and change requests carry their budget and schedule impact. Gate states are advisory, so the sponsor makes the call. Tollgate is built on Forge, so the data stays in your own Atlassian tenancy.
Tollgate keeps the business case, the gate decisions and the payoff in one record, next to the delivery they pay for.