Benefits tracking software records the returns a business case promised and measures them after the project closes. This article covers why benefits go missing, five features to look for in a tool, and the governance gap that software cannot close.
Benefits tracking software records the returns a business case promised, gives each return a named owner and a baseline, and measures actual results on a schedule that continues after the project closes. Vendors also sell it as benefits realisation software. The job is the same under either name. It keeps a promised number alive after the team that promised it has disbanded, which is the point at which most promised numbers are forgotten.
Carelessness gets the blame, but the cause sits in the way projects end. Suppose a business case promises $1.8 million a year in reduced claims processing cost, and the investment committee approves the money on that number. The project runs. The system ships. The team disbands. The project closes, the project manager moves to the next initiative, and the sponsor's attention moves with them.
The $1.8 million stays behind with no owner. It lived in a slide deck that was archived at go-live. Twelve months later the CFO asks whether the return arrived, and a project manager who never saw the original case has to reverse-engineer the answer from whatever data can be found, hedge it, and present it to a room that has no reason to trust it.
Benefits realisation is the stage most organisations skip, because by the time it falls due the team has dispersed, the budget line has closed, and nobody's performance review depends on going back. The cost lands on the next business case. When nobody checks the last forecast, readers treat the next one as a bid for funding and discount it.
The software gives every promised benefit four things that the project lifecycle otherwise removes.
The arithmetic is simple. Keeping the record alive is the hard part, because the record has to survive staff turnover, restructures, changes of sponsor, and the slow decay of attention that follows every go-live, and because the people who understand a number best tend to be the first to leave the project. A spreadsheet on one person's desktop lasts until the first handover. A system of record lasts through many.
A benefit with no parent case is a KPI. Most organisations already run KPI dashboards, and one more adds little. The value of benefits tracking sits in the comparison between what the case promised and what arrived. A tool that lets users create benefits without a parent case removes the promise from that comparison. The accountability goes with it.
Every benefit needs one person's name. A steering committee has never measured a benefit, and neither has a department. Choose a tool that refuses to save a benefit without an owner, and that shows the owner on every list, so that a blank would be awkward to ignore in any review, at any level, for as long as the benefit stays open.
The tool should schedule measurements at, for example, six, twelve, and twenty-four months after go-live, and surface each one when it falls due. If reminders stop when the project status changes to closed, you have bought project tracking. The benefit then dies at the moment it matters.
A sponsor looks at one investment and leadership looks at the pattern. The tool should show expected against realised across every investment in the portfolio, so a systematic gap appears as one portfolio fact. Take a portfolio where every case promised a 20% saving and the measured average came to 8%. That one line changes what the next round of business cases will be asked to promise, and who will be asked to defend the numbers.
The person who records a measurement in month eighteen probably was not on the project. If recording it needs a separate platform, a licence request, and half a day of training, tracking stops the first time it changes hands. The tool has to sit where the work already lives. Updating it should take minutes.
A business case that names “improved efficiency” or “better customer experience” with no figure and no date leaves nothing to track, and no software can create a baseline retrospectively. That is a governance problem. It sits upstream of any purchase decision.
The fix belongs at the investment gate, where the approver can decline a case that makes no testable promise. Once that discipline exists, benefits tracking software holds the promise to account. Without it, the organisation buys a register that stays empty, and the empty register shows the gap to everyone who opens it.
Tollgate is a Forge app that runs inside Jira Cloud. Benefits tracking lives where delivery teams already work. The business case carries the financial targets, including NPV, IRR, and payback, and each benefit traces back to the case that promised it. Benefits Realisation is the last of Tollgate's six lifecycle stages, which sit in three acts: Commit, Run, and Realise. The record keeps asking whether the return arrived long after close-out, because the stage stays open once the project has closed.
The Realisation record shows expected beside realised for each investment, and Tollgate Portfolio shows the same comparison across the whole portfolio. The sponsor records realisation as a judgement against the approved target. Tollgate declines to compute a live realised-ROI variance. When a target moves, the Decisions record keeps who changed it and why, so a revised number carries a reason and a name.
Tollgate runs on Atlassian infrastructure. No Softwired server sits in the path. It is free for up to 10 users under standard Atlassian Marketplace terms, and beyond 10 users pricing is per user through the Marketplace.
Install Tollgate from the Atlassian Marketplace and give every number in your next business case an owner before the project starts.
Tollgate keeps the business case, the gate decisions and the payoff in one record, next to the delivery they pay for.