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.
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 rather than sharpening the choice. The test of a good business case is simple — a reasonable person could read it and say no.
That framing changes what belongs in the document. Anything that helps someone decide stays. Anything that is there 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 was willing to make a judgement about what mattered, so the judgement was passed to the reader along with the raw material.
Somewhere in the organisation is a person who can approve this spend, and a slightly different person who will be answering for it in two years. Write for both, and find out which is which before you start. If you can't name them, stop and find out, because a case addressed to nobody in particular gets decided by nobody in particular.
That reader is not deciding whether your idea is good. They are deciding whether it is the best use of money that has other places to go, and whether the people asking can be trusted to deliver what they described. Those are different questions from the ones a delivery team asks, and they are answered with different material. Cost, return, risk, who is accountable, what happens if it goes badly.
Assume they read it alone, before the meeting, in about fifteen minutes. Assume they will skip to the numbers and work backwards. Write so that path makes sense.
The problem. State what is wrong now, in terms a finance director would recognise — cost, risk, lost revenue, a regulatory exposure, a manual process that ties up people. If the problem can only be described as an absence of the thing you want to build, you have described a preference, and it will be read as one.
The outcome. What is different when this has worked. Written as a state of the world, not a list of deliverables. Shipping a platform is a deliverable. Settling trades same-day instead of overnight is an outcome, and it is the thing you will be measured against.
The expected return. How the outcome turns into money or avoided cost, and roughly when. Prose is fine here, and often better than a number, because the reasoning is what gets challenged. If the return depends on a headcount reduction nobody has agreed to, say so in this section rather than burying it in the model.
Scope bounds. What is in, and specifically what is out. The out-of-scope list is the more useful half. It is what you point at nine months later when someone proposes an adjacent piece of work and assumes it was always included.
Decision authority. Who approves the case, who approves changes to it, and above what threshold a change comes back for a decision. Getting this on paper at the start converts a future argument into a lookup.
The financial case exists to make the size of the commitment legible, not to prove the answer. Three measures do most of the work.
Net present value discounts the year-by-year net cashflows back to today, at a rate that reflects what capital costs your organisation — 8% is a common default and a reasonable place to start if nobody has given you a rate. Internal rate of return is the discount rate at which the net present value comes out to zero, which lets you compare investments of different shapes. It cannot always be calculated. If the cashflows never turn from negative to positive, there is no rate that solves it, and the honest answer is that the measure doesn't apply. Payback is the point where cumulative cashflow crosses zero, and it is worth showing both undiscounted and discounted, because the gap between the two is itself informative.
Choose a horizon and hold to it. Three years suits work whose benefits arrive quickly and whose technology will be replaced. Five is the usual middle. Seven is defensible for infrastructure and rarely for anything else. Extending the horizon until the numbers work is the oldest trick in the file, and every experienced sponsor knows it.
Almost every figure in a business case is an estimate, and treating estimates as facts is what makes finance teams distrust the whole genre. The reader mistakes precision for accuracy. A benefit stated as 2.4 million dollars annually reads as less credible than one stated as 2 to 3 million, because the first implies a measurement nobody took.
Write down the assumptions the model rests on, next to the model. Name the one that would hurt most if it were wrong — the adoption rate, the licence price at renewal, the timing of the second release — and show what happens to the return if it moves. A sponsor who can see which assumption carries the weight can govern the investment. One who has been handed a single confident number can only approve it 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 rather than during it. The author writes it to unlock funding, it succeeds, and nobody opens it again. Delivery proceeds against a plan that has drifted from the case by month three, and by the time anyone asks whether the investment is still worth completing, there is nothing current to compare against.
A business case that is versioned and kept current is a different instrument entirely. It stops being a fundraising document and becomes the thing you govern against — at every gate, in every steering committee, when the scope changes and when someone asks whether to keep going. The case moves as the facts move, each version records what changed and who agreed to it, and the question at each gate is answerable from the record rather than reconstructed for the meeting.
Three things do most of that work, and none of them are prose.
A baseline — 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.
A named sponsor. One person, whose name is on the case, who will still be in the seat when the benefits are due. A return owned by a committee is a return nobody chases.
Something to compare against later. The outcome, written specifically enough that a person coming to it cold in eighteen months could tell whether it happened. That sentence is the whole point of benefits realisation, and it has to be written while you are still optimistic, because nobody writes a demanding test for themselves after the fact.
Tollgate keeps the business case inside Jira, versioned and current — the problem, the outcome, the expected return, scope bounds and decision authority, with a financial case that computes NPV, IRR and payback over a 3, 5 or 7 year horizon at a discount rate you set, or carries the figures your finance team produced. Approving the case snapshots each work package's budget and dates as the baseline you govern against from then on. Forge-native, 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.