Business case software: what it is and what to look for

Most business cases are written to unlock funding and never opened again. Business case software keeps the case alive against delivery — targets, assumptions, approved changes and realised benefits. What to look for, and when a template is enough.

min read
Business case software holds a business case as a structured, living record — financial targets, assumptions, approved changes and realised benefits — connected to delivery work so the approved case can be reconciled against what actually happened.

Business case software is software that holds a business case as a structured record and keeps it connected to delivery. Financial targets, assumptions, approved scope, changes and realised benefits live in one system, alongside the work itself, so the case can be checked at any point against what is actually happening.

That definition matters because most of what gets sold as a business case tool is a template with a logo on it. The template solves the writing problem. It does nothing for the years after approval, which is where business cases actually fail.

The problem business case software exists to solve

Most business cases are written to unlock funding and never opened again. The document does its work at the investment committee, the money is released, and the file goes back to a folder. Delivery starts in another system entirely. The plan moves, scope shifts, assumptions quietly expire, and none of it touches the case.

Two years later someone asks whether the investment delivered what it promised. The honest answer, in most organisations, is that nobody can tell. The approved case said $2.4 million NPV, resting on assumptions nobody tracked the fate of. Delivery reported progress against milestones that stopped mapping to the case around month three. Reconciling the two now means archaeology. Archaeology is expensive, so it does not happen, and benefits realisation dies at exactly this point. The case and the delivery were never in the same room after approval.

Business case software exists to keep the case alive against delivery. Not the document — the commitments inside it. NPV, IRR, payback period, the assumptions those numbers rest on, the changes approved along the way, and eventually the benefits realised. Held as data, connected to the running work, current for as long as the investment runs.

What to look for

A living record

The first test is whether the case is data the system understands or a file the system holds. If the NPV is a number in a field, the system can track it, compare it and report on it. If the NPV is a number on slide 14, the system can store slide 14. Plenty of products sold as business case management are document repositories with workflow attached. They keep the file safe. They do not keep the case alive.

Financials that update against actuals

The approved case carries targets. Delivery generates actuals. The tool should put the two side by side without a human re-keying either. When forecast cost moves, the payback period should move with it, visibly, in the same place the target was set. If updating the financial position of a case means reopening a spreadsheet, someone will update it for steering committees and at no other time.

A change log

Cases change. Scope gets cut, costs shift, an assumption fails and takes a benefit with it. The question is whether the change is governed or absorbed. Good business case tracking shows the approved case and the current case at the same time, with each approved change recorded between them — who raised it, who approved it, what it did to the numbers. Without that, "the business case" means whichever version the loudest person in the room remembers.

Proximity to delivery data

A case system that cannot see delivery re-imports the reconciliation problem it was bought to remove. If the work runs in Jira and the case lives in a standalone platform, someone has to carry status between the two by hand, and the carrying stops in the first busy month. The closer the case sits to the delivery data, the less the whole arrangement depends on someone remembering to reconcile.

An audit trail

The trail shows who approved the case and who approved each change, when, and on what basis. Boards and auditors question funded programs later, and when the question comes, the answer is either written down or it is reconstructed from memory and politics. An audit trail is cheap to keep and impossible to backfill.

When you do not need it

A single project with one funding decision and no ongoing governance does not need business case software. A template, a spreadsheet for the financials and a well-run approval meeting will do the job, and the money saved is real. If the task in front of you is the writing itself, our guide to how to write a business case covers the structure and the financials.

Document management is also sometimes the genuine requirement. If the organisation wants cases stored, versioned and findable, and nobody intends to track them after approval, SharePoint already does that. Buying a case management platform to use as a document library is a common and expensive way of getting the same result.

The signal that you have outgrown both is repetition. Multiple concurrent cases, a governance cadence that reviews them, and benefits that someone is accountable for realising. At that point the question stops being where the documents live and becomes whether anyone can state the current position of each investment. That is a software problem.

How Tollgate does it

Tollgate is a Forge app that runs inside Jira Cloud. The business case is a structured record with NPV, IRR and payback targets. Work packages link to Jira epics, so the case sits next to the delivery data instead of in a separate system that someone has to feed. A risk register, a decision log and a change log with a full audit trail sit alongside the financials, and the approved case stays visible together with every approved change since — the original and the current position are always both on the table. Investment Health dashboards show how each case is tracking against what was promised.

Because Tollgate is built on Forge, everything runs on Atlassian infrastructure and no data leaves it. The delivery data itself lives in your Jira projects and stays there whatever you decide about Tollgate later. Pricing is per user through the Atlassian Marketplace.

If your delivery already runs in Jira, install Tollgate from the Atlassian Marketplace and put your next business case in it.

See the method running in Jira

Tollgate keeps the business case, the gate decisions and the payoff in one record, next to the delivery they pay for.