A project governance framework is the standing arrangement of decision rights, gates, registers and reporting that an organisation uses to decide whether an investment continues, changes or stops.
A project governance framework is the standing arrangement of decision rights, gates, registers 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. 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.
Most published frameworks describe a steady state. They assume the program is roughly on plan, the sponsor is engaged and the registers are tidy. They say very little about the week the program is four months late and 30% over, when the honest question in the room is whether to keep funding it. That is the week the framework gets tested, because that 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.
A workable set for a technology investment runs roughly like this. The project manager moves money inside a work package and reschedules inside the approved end date. 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. Anything that changes the outcome the business case promised goes back to whoever approved that case.
Set the numbers so they get hit. A threshold that has not triggered once in two years tells you the number is too high, and that decisions which should have reached the sponsor were absorbed below the line by people trying to be helpful. A threshold that triggers every fortnight is set too low, and the committee will start approving in batches without reading. Four to eight escalations a year on a program of any size suggests the line sits about right.
A gate is a scheduled point where someone with spending authority looks at what the stage produced and decides whether to continue. The mechanics of that sit in what a stage gate is. The framework's job is to say, in advance, exactly what has to be in front of that person at each one.
A structure that holds up for technology investments runs six stages in three acts. Commit covers Discovery and Approval. Run covers Initiation and Delivery. Realise covers Close-out and Benefits realisation. The count varies by industry, though. Pharmaceutical development uses more stages, capital works uses different names, and five and six are both common. The shape carries more weight than the number, and four properties make the shape. Put a cheap stage in front of the expensive commitment. Commit the money at one gate and freeze a baseline there. Ask at recurring delivery gates whether the thing is still worth finishing. Keep a stage after delivery that checks whether the return arrived.
Discovery needs a problem statement, an order-of-magnitude cost, and a named person willing to sponsor it. Approval needs the business case with a financial case attached, meaning 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, and 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 actually materialised, and every change approved since the last gate. 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 someone has to sign.
The gates are periodic. The registers are continuous, and they are what make the gates cheap to run. Risks and opportunities, with impact, likelihood, treatment, an owner by name and a residual score after treatment. Decisions, appended and never edited, recording who decided, when, on what basis, and the evidence in front of them. Changes, each carrying its budget impact and its schedule impact, with approval triggering a rebaseline rather than a quiet adjustment to the forecast.
Registers only work if they get written as the work happens. A decision log built the week before a steering meeting is a reconstruction, and reconstructions are always kinder to the author than the record would have been. The same applies to the baseline. If someone edits it every time the forecast moves, variance is always zero and the framework has no measuring instrument left.
Monthly suits written reporting on most programs, weekly suits the delivery team's own tracking, and gate meetings belong on stage boundaries rather than on the calendar. Resist the urge to build a report. The dashboard is the deck, and 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 it. 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, rather than the person seeking approval.
One template applied to everything is the most common reason people abandon a framework. A $40,000 internal tool put through the same six gates as a $6 million platform replacement teaches everyone who touched it that governance is paperwork, and the lesson sticks.
Tier it by two variables. Spend is the obvious one. Irreversibility matters as much, because 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 register, 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 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 and cannot be edited by the person reporting against it, so the variance is visible whether or not anyone wants to look. The change process is the only route to a new number, so anyone moving the scope leaves a record instead of a quiet reforecast. And the decision log holds the earlier calls with their reasoning, so the conversation is about what to do next rather than about who said what in March.
That is the point at which a governance framework earns its keep. It is not the apparatus that keeps good programs tidy, it is 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 business case as approved and every version since, with what changed and who agreed. The baseline frozen at approval, and the actuals against it. The decisions in order with their evidence attached. Every change request with its budget and schedule impact and its approver. 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 rather than as a story. 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 with NPV, IRR and payback, work packages baselined the moment the case is approved, the risks and opportunities register, an append-only decision log with evidence of record, change requests that rebaseline on approval, and six stages in three acts from Discovery to Benefits realisation. Forge-native, 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.