Investment governance is the practice of deciding, repeatedly and on the record, whether the money committed to a change program is still well spent. This article separates it from project governance and lists the four records it needs.
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 meaning in funds management, where it describes the stewardship of a securities portfolio. This article covers the other meaning. It concerns capital put into technology programs, platform replacements, migrations, and regulatory uplifts. Applied to a single program, investment governance covers one funding decision after another. Applied across the programs competing for the same pool of money, the same practice usually goes by the name portfolio governance, and the questions in the rest of this article carry over unchanged.
The work sits above delivery. Whoever signed for the money does it, on a slower clock than the delivery cadence, and it has to survive changes of project manager, method, and vendor, none of which alter what the original decision was for.
Project governance asks whether the work is on track. Are the work packages moving, is spend tracking to budget, are the risks managed, and will the dates hold? The people closest to the work answer these questions. They answer them weekly.
Investment governance asks whether the money is still well spent. Given what the organisation now knows about cost to complete, the market, the regulation, and what it has since committed elsewhere, would it fund this program today, at this price, for this return, ahead of every other program competing for the same pool?
The two answers can point in opposite directions on the same program at the same moment. Both can be correct. A program can be green on every delivery measure and dead as an investment. The regulation it was built to satisfy is withdrawn, or the business it was built for is sold, or the competitor it was answering leaves the market. Delivery goes well. The reason for funding has gone, and the delivery report has no field for that.
The reverse also happens. A program can be late, over budget, and red on every delivery measure while remaining the best available use of the money, because the cost to complete is now small against a return that has grown since the case was approved. Cancelling it on the strength of a red status report destroys value. In both cases the delivery answer is accurate. The investment answer lives somewhere else.
A sponsor should be able to answer three questions at any moment without commissioning a piece of work to find out.
The first is whether the organisation will still get what it funded. The question concerns the outcome the money was released for, and that outcome usually sits some distance from the scope in the current plan, which has drifted by consent through a dozen sensible decisions.
The second is what has changed since the sponsor last said yes. The answer is one list of every approved change request, every risk that materialised, and every forecast that moved away from the baseline since the sponsor last put their name to anything.
The third is what the sponsor needs to decide today. A gate with nothing on the agenda is a status meeting. A gate with a decision on it is governance, and the decision is written down.
A delivery report cannot answer any of the three. Neither can an approval that happened eighteen months ago and has sat in a slide deck since.
On time and on budget describes how the inputs were consumed. It says the organisation spent roughly what it planned, over roughly the period it planned. That is worth knowing. It answers a delivery question, and the investment question needs a different answer, drawn from the case and the current forecast.
A program can consume its budget exactly as forecast and return nothing. Another can overrun and return five times its cost. Budget adherence is a constraint check, and it means only as much as the number it is checked against. Where someone resets the baseline every time the forecast moves, every program is always on budget and the measure has stopped carrying information.
Four records make the sponsor's three questions answerable. Each one stays put once written.
The first is a business case that stays current. Most business cases are written once, to release funding, and never opened again. A current case is versioned. It holds the problem, the outcome, the expected return, the scope bounds, and who has decision authority. At any gate the reader can see what was believed then beside what is believed now, and can ask which of the two changes the decision.
The second is a baseline. Approving the case freezes the budget and dates that were approved. Without a frozen number, variance is arithmetic against a moving target, and any result can be made to look acceptable by moving the target.
The third is a decision record. It shows who decided, when, on what basis, and what they were looking at, and it is append-only. Nobody can revise it quietly. Two years on, when someone asks why the program went the way it did, the answer is either written down or has become folklore.
The fourth is a benefits check after the fact. Months after go-live, with the system in production and the team dispersed, someone goes back and asks whether the return arrived, and records the answer against the approved case.
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, produce net present value (NPV), internal rate of return (IRR), and a payback period. Reasonable people argue about the inputs, and they should. The arithmetic is settled. That makes it useful at a gate, because the assumptions are visible and anyone can challenge them directly.
After delivery, the same arithmetic stops holding up, and the reasons are structural. Realised return is a judgement made by named people against the target they approved, and written down where it can be read later. Three things prevent a calculation. First, nobody can observe the version of the organisation that skipped the program, so any benefit figure compares against a world that never existed. Second, benefits land over years, in periods the program no longer owns, mixed into results that other work also moved. Third, the causal chains are contested. Revenue rose, and so did pricing, headcount, a competitor's exit from the segment, and the trading conditions of the second half, and each of those has an owner who will claim part of the credit.
For these reasons a live realised-ROI variance, recomputed through delivery and shown as a number, is a weak instrument. It would be precise and hard to defend. People would defend it anyway, because a number on a dashboard attracts more trust than the working behind it. At realisation the useful record is the verdict, which sets what the organisation said beside what it got, judges the result against the approved target, and keeps 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 nobody's performance depends on going back. Everyone moves on. Nothing appears to break.
The damage shows up in the next business case. Where nobody checks a case, nobody pays a price for a forecast. Estimates drift upward without anyone lying, because every author knows the last author was never held to a number. Benefit numbers become the entry fee for the funding round, and nobody expects to be held to them. The numbers in the pack get discounted in people's heads, and the decision turns on whether the room believes the sponsor. The after-the-fact check restores the value of the arithmetic.
Tollgate runs investment governance inside Jira. It holds a versioned business case with its NPV, IRR, and payback model, work packages baselined at approval, Risks & Opportunities, an append-only decision log, and a Benefits Realisation stage that reads against the case that was approved. Tollgate runs on Atlassian infrastructure with no Softwired server in the path, 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.