A project governance framework is the standing arrangement of decision rights, gates, records, and reporting that an organisation uses to decide whether an investment continues, changes, or stops. This guide sets out its parts and how to keep them working in a program's worst week.
A project governance framework is the standing arrangement of decision rights, gates, records, and reporting that an organisation uses to decide whether an investment continues, changes, or stops. It sits above the delivery method. The method governs how the work gets built, and the framework governs whether the money keeps flowing, who gets to say so, and what they have to be looking at when they say it.
A framework designed for a steady state assumes the program is roughly on plan, the sponsor is engaged, and the records are tidy. It says little about the week a program is four months late and 30% over budget, when the question in the room is whether to keep funding it, and that week tests the framework because it is the week someone proposes suspending it until things settle. Everything below is written for that week.
Write the decision rights down as a table with three columns: the decision, the person or body that owns it, and the threshold that pulls it up to them. Anything you cannot express in that form will be argued about at the worst possible moment.
As an illustration, a workable set for a technology investment runs like this. The project manager moves money inside a work package and reschedules inside the approved end date, while a forecast that exceeds a work package baseline by more than 10% or $25,000, whichever is smaller, goes to the sponsor. Anything that moves the program’s total budget or its committed end date goes to the steering committee. A change to the outcome the case promised goes back to whoever approved the case.
Set the numbers so they get hit. A threshold that has not triggered once in two years is too high, which means decisions that should have reached the sponsor were absorbed below the line by people trying to be helpful. A threshold that triggers every fortnight is too low, and the committee will start approving in batches without reading.
A gate is a scheduled point where someone with spending authority looks at what the stage produced and decides whether to continue. The mechanics sit in what a stage gate is, and the framework’s job is to say, in advance, exactly what has to be in front of that person at each gate.
A structure that holds up for technology investments runs six stages in three acts. Commit covers Discovery and Approval, Run covers Initiation and Delivery, and Realise covers Close-out and Benefits realisation. The count varies by industry. Pharmaceutical development uses more stages, capital works uses different names, and five and six are both common. Four properties matter more than the count. A cheap stage sits in front of the expensive commitment. The money is committed at one gate, and a baseline freezes there. Recurring delivery gates ask whether the work is still worth finishing. A final stage after delivery checks whether the return arrived.
Discovery needs a problem statement, an order-of-magnitude cost, and a sponsor. Approval needs the business case with a financial case attached, which means year-by-year cashflows over a stated horizon, a discount rate you have written down, and the resulting net present value, internal rate of return, and payback. It also needs scope bounds, a named project manager and sponsor, and the decision authority in writing. Approving the case sets the baseline. Every work package’s budget and planned dates freeze at that moment.
Initiation needs the work packages with owners and linked delivery work. Delivery gates need forecast against baseline, variance, the risks that have materialised, and every change approved since the last gate, and close-out needs actuals against the frozen baseline and a list of what is still open. Benefits realisation, months later, needs a written verdict against the target the case set. At commitment the return is arithmetic. At realisation it is a judgement that someone has to sign.
The gates are periodic. The records run all the time. They are what make the gates cheap to run. Each risk or opportunity gets an impact, a likelihood, a treatment, an owner by name, and a residual score after treatment, while decisions are appended and never edited, and each one records who decided, when, on what basis, and the evidence in front of them. Each change carries its budget impact and its schedule impact. Approving a change moves the current forecast. The baseline stays locked at what the sponsor approved, so the gap between the two is always visible.
Records only work if they are written as the work happens. A decision log built the week before a steering meeting is a reconstruction. Reconstructions are kinder to the author than the record would have been. The baseline follows the same rule. If someone edits it every time the forecast moves, variance is always zero, and the framework has lost its measuring instrument. A new baseline needs a new approval of the amended case.
Monthly suits written reporting on most programs, and weekly suits the delivery team’s own tracking. Gate meetings belong on stage boundaries, wherever those fall in the calendar. Do not build a report. The dashboard is the deck. If someone spends a day pulling delivery status out of one system, budget out of a spreadsheet, and the original case out of an old slide pack, the governance record does not exist yet.
Four roles carry the framework. The sponsor owns the return and can stop the program. The project manager owns delivery and the accuracy of the forecast. The steering committee brings the customer and supplier perspectives and holds the decisions the sponsor escalates. Finance owns the assumptions in the financial case and re-runs them. That keeps the numbers out of the hands of the person seeking approval.
One template applied to everything is the most common reason people abandon a framework. Put a $40,000 internal tool through the same six gates as a $6 million platform replacement, and everyone who touched it learns that governance is paperwork. That lesson sticks.
Tier the framework by two variables. Spend is the obvious one. Irreversibility matters as much. A small project that migrates customer data or changes a regulated process deserves the full treatment whatever its budget. A light tier runs one approver, one risk list, and gates at approval and close-out. A standard tier adds a steering committee, delivery gates, and change control. The full tier adds the financial case, a formal baseline, and benefits realisation with a named owner. Publish the boundaries so that nobody negotiates which tier applies.
The program is late, the forecast has moved twice, the sponsor is under pressure from someone above them, and the delivery team is working weekends. Every instinct in the room says to stop reporting, stop escalating, and get through it.
A framework survives that week if three things are already true. The baseline is frozen at approval, and only a new approval replaces it, so the variance is visible whether or not anyone wants to look. The change process is the only route to a new forecast, so anyone moving the scope leaves a record. The decision log holds the earlier calls with their reasoning, so the conversation stays on what to do next, and who said what in March is already written down.
That is when a governance framework earns its keep. It isn’t the apparatus that keeps good programs tidy. It’s the thing that lets a sponsor stop a bad one without a fight about the facts.
When the program is finished, someone who was not there should be able to reconstruct why it went the way it did. Five artefacts make that possible. The first is the business case as approved, with every version since and a note of what changed and who agreed. The second is the baseline frozen at approval, with the actuals against it. The third is the decisions in order, evidence attached. The fourth is every change request with its budget impact, its schedule impact, and its approver. The fifth is the closing verdict on whether the return arrived.
Hold those five and the program is auditable, and the next business case that lands on that sponsor’s desk gets read as a forecast with a track record behind it. Lose them, and the next round of estimates will be exactly as optimistic as this one was.
Tollgate runs this framework inside Jira. The business case calculates NPV, IRR, and payback from the cashflows you enter. Risks & Opportunities, an append-only decision log with the evidence of record, and Changes with their budget and schedule impact sit on the same record. The financial case stays separate from work-package budgets and change requests. The approved baseline stays fixed, and changes go through change control. The six stages run in three acts, from Discovery to Benefits realisation. Gate states are advisory, so the sponsor makes the call. Tollgate is built on Forge, so the record 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.