Investment governance is the practice of governing the money an organisation commits to its own change programs, deciding repeatedly and on the record whether that capital is still well spent.
Investment governance is the practice of governing the money an organisation commits to its own change programs, deciding repeatedly and on the record whether that capital is still well spent. The phrase also has a life in funds management, where it describes the stewardship of a securities portfolio; this article is about the other one — capital put into technology programs, platform replacements, migrations and regulatory uplifts. Applied to a single program, it governs one funding decision after another. Applied across the set of programs competing for the same pool of money, the same practice usually goes by the name portfolio governance.
The work sits above delivery. It is done by whoever signed for the money, on a slower clock than the delivery cadence, and it has to survive changes of project manager, method and vendor.
Project governance asks whether the work is on track. Are the work packages moving, is spend tracking to budget, are the risks being managed, will the dates hold. That question is answered by the people closest to the work, and it gets answered weekly.
Investment governance asks whether the money is still well spent. Given what is known now about cost to complete, about the market, about the regulation, about what the organisation has since committed to elsewhere — would we fund this today, at this price, for this return?
The two answers can point in opposite directions at the same moment on the same program. A program can be green on every delivery measure and dead as an investment, because the regulation it was built to satisfy was withdrawn, or because the business it was built for was sold, or because the competitor whose product it was answering exited the market. Nothing about the delivery has gone wrong. The reason for funding it evaporated, and the delivery report has no field for that.
It runs the other way too. A program can be late, over budget and red on delivery while remaining the best available use of the money, because the cost to complete is now small against a return that has grown. Killing it on the strength of a red status report destroys value. In both cases the delivery answer is accurate, and the investment answer sits somewhere else entirely.
A sponsor should be able to answer three questions at any moment, without commissioning a piece of work to find out.
Are we still going to get what we funded? That asks about the outcome the money was released for, which by now is some distance from the scope in the current plan after it has drifted by consent through a dozen sensible decisions.
What has changed since I last said yes? Every approved change request, every risk that materialised, every forecast that moved away from the baseline, in one list, since the last time the sponsor put their name to something.
What do you need me to decide today? A gate with nothing on the agenda is a status meeting. A gate with a decision on it is governance.
None of the three is answerable from a delivery report, and none of them is answerable from an approval that happened eighteen months ago and has been sitting in a slide deck ever since.
On time and on budget describes how the inputs were consumed. It says the organisation spent roughly what it said it would spend, over roughly the period it said it would take. That is worth knowing, and it is a delivery answer offered to an investment question.
A program can consume its budget exactly as forecast and return nothing. A program can overrun and return five times its cost. Budget adherence is a constraint check, and it is only as meaningful as the number it is checked against. Where someone quietly re-sets the baseline every time the forecast moves, everything is always on budget and the measure has stopped carrying information.
Four artefacts make the sponsor's three questions answerable, and each of them is a record rather than a report.
A business case that stays current. Most business cases are written once, to release funding, and are never opened again. A case that stays current is versioned — the problem, the outcome, the expected return, the scope bounds, who holds decision authority — so that at any gate you can read what was believed then beside what is believed now.
A baseline. Approving the case freezes the budget and dates that were approved. Without a frozen number, variance is arithmetic against a moving target, which is to say it is not variance.
A decision record. Who decided, when, on what basis, and what they were looking at when they decided it. Append-only, so nothing is quietly revised. Two years on, when someone asks why the program went the way it did, the answer is either written down or it is folklore.
A benefits check after the fact. Months after go-live, with the thing in production and the team dispersed, someone goes back and asks whether the return arrived.
Before commitment, expected return is a calculation. Cashflows in and out over a three, five or seven year horizon, discounted at a rate the organisation sets, producing net present value, an internal rate of return and a payback period. Reasonable people argue about the inputs, and they should, but the arithmetic itself is not contested. That is what makes it useful at a gate — the assumptions are visible and can be attacked directly.
After delivery, the same arithmetic stops being honest. Realised return is not a calculation, it's a judgement — made by named people, against the target they approved, and written down where it can be read later. The counterfactual is invisible, because nobody can observe the version of the organisation that did not run the program, which makes any benefit figure a comparison against a world that never existed. Attribution windows are long, so benefits land over years, in periods the program no longer owns, mixed into results that other work also moved. Causal chains are contested, because revenue rose and so did pricing, headcount, a competitor's exit from the segment and the trading conditions of the second half.
This is why a live realised-ROI variance, recomputing through delivery and displayed as a number, is a bad instrument. It would be precise, it would be indefensible, and it would be defended anyway, because people trust a number on a dashboard more than the working behind it. At realisation the useful artefact is the verdict — what we said beside what we got, judged against the target rather than recomputed from it, with the reasoning attached.
Benefits realisation is the stage that gets cut. By the time it falls due the team has dispersed, the sponsor has a new portfolio, the budget line is closed, and there is no one whose performance depends on going back. Everyone moves on, and nothing appears to break.
What breaks is the next business case. Where nobody ever checks a case, nobody pays a price for a forecast, and estimates drift upward without anyone lying about anything. Benefit numbers become the price of entry to the funding round rather than a claim someone will be held to. Everyone in the room knows it, which is why the numbers in the pack get discounted in people's heads and the decision turns on whether the room believes the sponsor. The check is what makes the arithmetic worth doing at all.
Tollgate runs investment governance inside Jira — a versioned business case with its NPV, IRR and payback model, work packages baselined at approval, a risks register, an append-only decision log, and a benefits realisation stage that reads against the case that was actually approved. 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.