A business case exists to let someone decide. This is a practical guide to writing one that survives the room: what goes in it, how to do the financial analysis properly, and the mistakes that sink otherwise sound proposals. There is a free editable template at the end, and you can grab it now if that is all you came for.
A business case is the reasoning behind spending money on something. It sets out the problem, the options, the recommended one, what it costs, what it returns, and what could go wrong. Its job is not to describe the project. Its job is to give someone enough to say yes, no, or not yet, and to be able to defend that decision later.
That framing matters, because a lot of weak business cases are really project plans wearing a different hat. If your document explains how the work will run before it has established whether the work is worth doing, the order is wrong.
It is also easy to confuse with the documents around it:
| Document | Answers | When |
|---|---|---|
| Business case | Should we fund this, and which option? | Before approval |
| Project brief or one-pager | Is this worth investigating at all? | Before the case |
| Feasibility study | Can this actually be done? | Feeds the case |
| Project charter | Who is accountable, and what is in scope? | After approval |
| Delivery plan | How and when will it be built? | After approval |
Not every spend deserves a formal case, and writing one where it is not warranted is a good way to get them ignored. You need a business case when at least one of these is true:
You probably do not need one for small, reversible, already-budgeted work. A short brief is enough, and the credibility you save is worth more.
As short as it can be while still answering the questions a reviewer will ask. Most business cases land between five and fifteen pages, with a one-page executive summary that stands on its own. Length is not rigor. A twenty-page case with an invented discount rate is weaker than a six-page one where every number traces to a stated assumption.
Assume the person deciding will read the summary carefully, skim the middle, and go straight to the financials and the risks. Write accordingly.
This is the structure the template follows. The order matters: each section earns the right to the next one.
Write it last. One page: the ask, the problem, the recommendation, the return, and the decision you need. The mistake: introducing a claim here that the rest of the document does not support.
What is broken, what it costs today, and the evidence for both. Include what happens if you do nothing, honestly. The mistake: opening with the technology. A case that starts from the capability rather than the problem invites the question you least want.
Name the specific business objective this serves, not a general aspiration. The mistake: a paragraph of strategy language that would fit any initiative in the portfolio.
Include doing nothing as a real option with real consequences, plus two or three genuine alternatives. Where it applies, say whether each is build, buy, or hybrid. State the comparison criteria before the verdict. The mistake: two strawmen and the answer you had already chosen. Experienced reviewers spot this instantly, and it damages everything else in the document.
Which one, why it beats the others on the stated criteria, and why not the alternatives. The mistake: recommending one option and then costing a different one. More on this below, because it is the single most common inconsistency in business cases.
What is in, what is out, the phases, and the requirements that are genuinely load-bearing: performance, availability, security, accuracy, where data is allowed to live. The mistake: discovering that a hard requirement conflicts with the chosen approach during security review, when changing course is expensive.
Most initiatives fall over on adoption, not on technology. Set out who has to work differently, what that actually asks of them, and what it will take to get there: communication, training, manager involvement, support through the transition, and the dip in output while people learn. This section is load-bearing in two directions. It creates real cost lines, and it is the only thing that justifies the adoption rate your benefits depend on.
Five questions are worth answering explicitly, because reviewers ask them and most cases have no answer ready:
The mistake: treating change as something to fund later. If the benefit depends on people behaving differently and the case has no plan for making that happen, the benefit is a wish.
Build the cost from its parts. Separate what you pay once from what you pay every year, and say how firm each line is. A signed quote and an educated guess should not look identical on the page. The mistake: a single round number with no visible arithmetic behind it.
Quantify what can honestly be quantified, and report the rest as outcomes rather than inventing a dollar figure. Apply two discounts to every financial benefit: adoption and attribution. The mistake: assuming everyone uses it and that nothing else contributed.
Cash flows by year, then net present value, internal rate of return, and payback. Then sensitivity. Covered properly in the next section.
Number the assumptions so the financial section can point at them, and give every risk a named owner. The mistake: an assumption nobody can find is an assumption nobody can challenge, which is worse than a weak one.
What you will measure, the baseline as it stands today, the target, and when it gets checked. Then who signs.
Say what happens if performance misses the forecast: at what threshold it gets reviewed, who decides, and what the options are between carrying on and stopping. The mistake: two of them here. Not recording the baseline before you start, which makes the benefit unprovable afterward, including to yourself. And describing only what success looks like, which leaves nobody able to hold the case to account when it does not arrive.
This is the section that gets skipped or fudged most often, and it is the one a finance reviewer reads first.
Ask your finance team for the organization's hurdle rate or weighted average cost of capital. Do not choose one yourself. An invented discount rate invalidates every number that depends on it, and it is trivially easy for a reviewer to challenge.
Not a single total. Year zero through year five, with one-time costs, recurring costs, gross benefits, net benefits after adoption and attribution, net cash flow, and discounted cash flow. The shape of that curve is what payback depends on.
| Metric | What it tells you | Where it misleads |
|---|---|---|
| Net present value | Whether the initiative creates value at your cost of capital. Positive is good. | Says nothing about scale of effort or risk. A tiny positive NPV is not a reason to proceed. |
| Internal rate of return | The discount rate at which NPV hits zero. Compare it to the hurdle rate. | Goes absurdly high when the initial outlay is small, and breaks entirely when cash flows change sign more than once. |
| Payback period | When cumulative cash flow turns positive. Executives love it. | Ignores everything after the payback point, so it quietly favors short, small initiatives. |
| Cost of delay | What a month of not deciding costs you. Underused, and unusually persuasive. | Only credible if the benefit itself is credible. |
Report more than one. Any single metric can be gamed, and a reviewer who sees all four together can tell quickly whether the case is sound.
Ask which single assumption, if it turned out to be wrong, would change the decision. Then show the case at a downside, base, and upside value for it. That one table pre-empts most of the questions you would otherwise face live, and it signals that you went looking for the weakness yourself.
Structure is the easy part. These are the failures that get cases sent back, in rough order of how often we see them.
Twenty minutes back for four hundred people is not a financial benefit until you say what happens to that time. Fewer contractors, more output, or nothing yet. All three are acceptable answers. Silence is not.
Almost no benefit lands across the whole population, and almost no case says so. State the adoption rate you are assuming and where the figure came from.
The benefit assumes people work differently, but the cost contains no communication, no training, no manager time, and no allowance for the productivity dip while everyone learns. Adoption does not happen for free. A case that budgets for the system but not for the switch tends to miss on both.
When three initiatives all count the same reduction in handling time, the portfolio promises more than the business will ever bank. Say what share of the outcome this initiative is claiming.
The case recommends option two and then finances a number derived from option one, usually because the estimate was built before the options were compared. It is easy to miss internally and very easy to spot in review.
If a line is priced per user per month, the annual figure has to equal unit cost multiplied by users multiplied by twelve. A stated total that disagrees with its own unit economics is a common error and an expensive one, because it usually understates the run cost.
A firm quote and a rough estimate carry very different risk. Blending them into one number throws away the information a reviewer needs to judge how much contingency the case deserves.
If the alternatives were assembled after the decision, the options section is doing no work. Reviewers read it precisely to see whether the thinking was genuine.
Without a recorded measure of how things stood before, nobody can prove the benefit landed. This is why organizations end up unable to say whether their last five investments paid off, and why the sixth is harder to fund.
An editable Word document covering every section above, with the tables already built for options, costs, benefits, cash flow, assumptions, risks, and sign-off. Guidance notes are included in the file and are meant to be deleted as you write. No email required.
Download the business case templateA business case is the reasoning behind committing money to an initiative. It sets out the problem being solved, the options considered, the recommended option, what it will cost, what it is expected to return, and the risks and assumptions behind those numbers. Its purpose is to let a decision-maker approve, reject, or defer with confidence, and to defend that decision afterward.
An executive summary, the problem and what it costs today, strategic alignment, the options considered including doing nothing, the recommended option and why, scope and approach, the people and change impact, costs split between one-time and recurring, quantified benefits discounted for adoption and attribution, financial analysis with net present value and payback, assumptions and risks, success measures with a baseline, and sign-off.
Most land between five and fifteen pages, with a one-page executive summary that stands on its own. Length is not rigor. A short case where every number traces to a stated assumption is stronger than a long one built on figures nobody can check.
A business case answers whether the work should be funded and which option to pursue, and it is written before approval. A project charter answers who is accountable and what is in scope, and it is written after approval. If your business case is mostly describing how the work will run, it has drifted into charter territory before earning the right to.
Lay out costs and benefits as cash flows by year, discount them at your organization's hurdle rate or weighted average cost of capital, then report net present value, internal rate of return, and payback period together rather than relying on any one of them. Discount the benefit side for adoption and attribution before it reaches the financials, or the return will be overstated.
Treat it as both a cost and a condition of the benefit. On the cost side, budget for communication, training, manager time, and support through the transition, plus the temporary drop in productivity while people learn. On the benefit side, the adoption rate you assume has to be justified by that plan rather than asserted. A case with no change effort in it has nothing holding its adoption assumption up.
Usually the sponsoring manager or a business analyst writes it, with finance validating the numbers and the affected functions contributing costs and assumptions. Approval sits with whoever holds the budget, which above a certain threshold typically means an investment committee or executive group rather than one individual.
The template gives you the structure. Arivue drafts the case itself, computes the financials, and checks the whole thing for the inconsistencies above before anyone else sees it.