A business case is a written argument that asks a named person to commit money to a specific piece of work and states the expected return. This guide covers the five sections, the financial measures, and how to keep the case current after approval.
A business case is a written argument that asks a named person to commit money to a specific piece of work, and states what the organisation expects to get back for it. Most authors spend their effort assembling material. The effort pays off when it sharpens the choice. The test of a good business case is that a reasonable person could read it and say no.
That test changes what belongs in the document. Anything that helps someone decide stays. Anything included because a template asked for it, or because the author wanted to show the work, comes out. A case that runs to sixty pages usually means nobody made a judgement about what mattered. The reader receives the raw material along with the request, and the sorting becomes the reader's job.
Somewhere in the organisation a person can approve this spend. A slightly different person will answer for it in two years. Find out who each of them is before you start. A case addressed to nobody in particular gets decided by nobody in particular.
That reader is deciding whether your idea is the best use of money that has other places to go, and whether the people asking can deliver what they described. A delivery team asks different questions, so the reader needs different material. The material is cost, return, risk, who is accountable, and what happens if the work goes badly.
Assume the reader works through the case alone, before the meeting, in about fifteen minutes. Assume they skip to the numbers first and work backwards. Write the document so that path makes sense, with every figure traceable to the paragraph that explains it.
The problem. State what is wrong now in terms a finance director recognises, such as cost, risk, lost revenue, a regulatory exposure, or a manual process that ties up people, and give each a figure or a date wherever the source data allows it. A problem that can only be described as the absence of the thing you want to build is a preference, and the reader will treat it as one.
The outcome. Describe what is different when the work has succeeded, as a state of the world. Shipping a platform is a deliverable. Settling trades the same day instead of overnight is an outcome. The outcome is what the sponsor will be measured against once the platform is live.
The expected return. This section turns the outcome into money or avoided cost, with a rough date. Prose often works better than a number here, because the reasoning is what gets challenged. If the return depends on a headcount reduction nobody has agreed to, say so in this section. Buried in the model, the dependency surfaces later as a surprise.
Scope bounds. List what is in and, specifically, what is out. The out-of-scope list is the more useful half. Nine months into delivery, when someone proposes an adjacent piece of work and assumes it was always included, the list is the document you point at.
Decision authority. Name who approves the case, who approves changes to it, and the threshold above which a change returns for a decision. Writing this down at the start turns a future argument into a lookup.
The financial case makes the size of the commitment legible. The sponsor can see what they are signing up for. Three measures do most of the work.
Net present value (NPV) discounts the year-by-year net cashflows back to today at a rate that reflects what capital costs your organisation. A rate of 8% is a common default. It is a reasonable starting point when nobody has given you one. Internal rate of return (IRR) is the discount rate at which NPV comes to zero, and it lets you compare investments of different shapes. It cannot always be calculated. When the cashflows never turn from negative to positive, no rate solves the equation, and the measure does not apply to that case. Payback is the point where cumulative cashflow crosses zero, meaning the month or year in which the money returned first equals the money spent. Show it both undiscounted and discounted, because the gap between the two says how much of the promised return depends on the discount rate.
Choose a horizon and hold to it, because a horizon that moves during the review reads as a horizon chosen to fit the answer. Three years suits work whose benefits arrive quickly and whose technology will be replaced, five years is the usual middle, and seven years is defensible for infrastructure and rarely for anything else. Extending the horizon until the numbers work is the oldest trick in the file. Every experienced sponsor knows it.
Almost every figure in a business case is an estimate. Treating estimates as facts is why finance teams distrust the genre, because readers mistake precision for accuracy. A benefit stated as $2.4 million a year reads as less credible than one stated as $2 to 3 million, because the first implies a measurement that nobody took.
Write down the assumptions the model rests on, next to the model, in plain sentences. Name the one that would hurt most if it were wrong. It may be the adoption rate, the licence price at renewal, or the timing of the second release. Show what happens to the return if it moves by a stated amount. A sponsor who can see which assumption carries the weight can govern the investment. A sponsor handed one confident number can only approve or reject it.
If your finance team has already built the model, use theirs. A case that carries the organisation's own numbers, produced by the people who own the chart of accounts, leaves the finance team nothing to correct.
Most business cases fail after approval. The author writes the case to release funding. It succeeds, and nobody opens it again. Delivery proceeds against a plan that has drifted from the case by month three, scope has been traded away in a series of reasonable meetings, the assumptions in the model have aged, and when someone finally asks whether the investment is still worth completing, nothing current exists to compare against.
A business case that is versioned and kept current becomes the document you govern against at every gate, in every steering committee, whenever the scope changes, whenever a cost forecast moves, and whenever someone asks whether the organisation should continue with the work. The case moves as the facts move, and each version records what changed and who agreed to it. Any question at a gate can then be answered from the record, without a scramble to rebuild the history the night before the meeting and without asking the people who have since left the project.
Three entries in the record do most of that work.
A baseline holds the budget and dates as they stood at approval, frozen. Without a fixed number to measure against, variance means nothing, because the forecast quietly becomes the plan and everything is always on track, for as long as nobody checks.
A named sponsor is one person whose name is on the case and who will still hold the role when the benefits fall due. A committee cannot chase a return.
A test for later states the outcome specifically enough that a person coming to it cold in eighteen months could tell whether it happened. Benefits realisation rests on that sentence. Write it while you are still optimistic. People rarely write a demanding test for themselves after the fact.
Tollgate keeps the business case inside Jira, versioned and current. The record holds the problem, the outcome, the expected return, the scope bounds, and the decision authority. The financial case computes NPV, IRR, and payback, discounted and undiscounted, over a 3, 5, or 7 year horizon. It uses a discount rate you set, or carries the figures your finance team produced. The approved baseline stays fixed, and changes go through change control. Tollgate runs on Atlassian infrastructure with no Softwired server in the path, so the data 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.