A business case is a document that asks for resources by making an argument. Most of them fail not because the idea is bad but because the document does one of three things: it advocates rather than analyses, it omits the option of doing nothing, or it buries the number that everything else depends on. This covers what a business case needs to contain, how to structure it so it survives scrutiny, and the failure modes that get one sent back.
What it is for
A business case exists to let someone with authority make a decision they can defend. That framing changes what belongs in it.
It is not a pitch. A pitch is designed to persuade; a business case is designed to be evaluated. The difference shows in whether the alternatives are treated seriously and whether the risks are stated by you or discovered by the reader.
It is not a project plan. The plan comes after approval. A business case that spends four pages on the delivery schedule and one on the benefits has the balance wrong.
It is not a one-off document. A good business case is revisited: at approval, at gate reviews, and after delivery to check whether the benefits arrived. Writing it as a permanent record rather than a submission changes how carefully the assumptions get recorded.
The structure
The standard shape, which most organisations' templates approximate:
1. The problem or opportunity. What is wrong or what is possible, stated in terms of impact rather than activity. "Order processing takes six days" is a problem; "we need a new order system" is a solution wearing a problem's clothes. Quantify it — the cost of the status quo is the number your whole case leans on.
2. Options considered. At least three, always including do nothing. This is the section that separates analysis from advocacy, and its absence is the most common reason a case is sent back. Typically: do nothing, do the minimum, do the recommended thing, and sometimes do more. Each with its cost, benefit, risk and timeline.
3. The recommendation, with reasoning. Which option and why, including what you are giving up by choosing it.
4. Costs. All of them: one-off, recurring, internal effort, opportunity cost, and the cost of change — training, migration, disruption. Internal staff time is a real cost and omitting it is the most common way a case understates its own price.
5. Benefits. Split into:
- Cashable — money that actually leaves the budget line. The only kind a finance function fully believes.
- Non-cashable efficiency — time saved that is redeployed rather than removed. Legitimate, but say so rather than converting it to pounds and hoping.
- Qualitative — risk reduction, compliance, customer experience, staff retention. Real, and weakened by pretending to quantify it precisely.
6. Risks, with mitigations, and honestly. A risk section listing only risks you have already solved is a tell.
7. Assumptions and dependencies. What must be true for this to work, and what else must happen first. This section is what lets a reader test the case rather than accept it.
8. Timeline and milestones, at the level of when benefits start, not a work breakdown.
9. How success will be measured, and when it will be checked. A business case with no measurement plan cannot be evaluated afterwards, which is convenient for the author and bad for the organisation.
The numbers
Financial rigour is where cases are most often weak, and where the reader's attention is most concentrated.
- State the payback period — how long until cumulative benefit exceeds cumulative cost. It is the number most executives look for first.
- Show the cash flow by year, not just a total. A three-year benefit with the cost in year one has a very different profile from an even spread.
- Use net present value if your organisation does, with the discount rate it mandates. If you do not know the rate, ask; guessing produces a number nobody trusts.
- Show the sensitivity. What happens if the benefit is half what you project, or the cost 50% higher? A case that only works under its central assumption is a case that will not survive delivery.
- Be conservative in benefits and generous in costs. Optimistic cases get approved and then fail publicly. The reputational arithmetic favours caution.
- Make every number traceable. A figure with no stated source is a figure the reader will discount entirely. Where an assumption drives a large number, say who provided it.
The failure modes
No do-nothing option. Every decision has a status quo, and its cost is what makes action worth taking. Omitting it looks like you are hiding something, usually because you are.
A solution in search of a problem. The case is written after the decision has been made, working backwards to justify the chosen tool. Reviewers recognise this immediately; the tell is that the options section describes three variants of the same answer.
Benefits that nobody owns. "This will save 200 hours a year" requires someone to accept a target reflecting that saving. If no budget holder will sign up to the reduction, the benefit is theoretical, and saying so is more credible than asserting otherwise.
Ignoring the cost of change. Migration, training, dual running, the productivity dip during transition. These are frequently larger than the licence cost and are the ones omitted.
Precision theatre. "£247,830 annual saving" from a model built on three estimates implies a confidence you do not have. Round, and state the range.
Too long. A 40-page business case is read by its author and skimmed by everyone else. The substance belongs in appendices; the argument fits in a few pages, fronted by a summary. See writing a one-page summary and how to write an executive summary.
Writing for the reader you have
A business case is read by several people who want different things, and it should be structured so each finds theirs quickly.
- The approver wants the ask, the cost, the payback, and the main risk. They may read only the summary.
- Finance wants the numbers, their derivation, and the assumptions.
- The technical reviewer wants the options analysis and the dependencies.
- The person who will deliver it wants the scope and the timeline.
A summary page at the front, clear section headings, and appendices for detail serve all four. Writing one continuous argument that must be read in order serves none.
After approval
The document does not stop being useful when it is approved:
- Baseline the benefits. The measures in the case become the measures the project is held to.
- Revisit at gates. If the assumptions have moved, the case has changed, and the honest response is to say so rather than to proceed on a case that is no longer true.
- Review after delivery. Did the benefits arrive? Organisations that never do this keep approving cases with the same optimistic assumptions, and everyone learns that projections are decorative.
Keep the approved version, dated and versioned, as the record — the same discipline as any governed document: document versioning best practices and writing a decision log.
Summary
Structure the case as problem, options including do nothing, recommendation, full costs, honestly categorised benefits, risks, assumptions, and a measurement plan. Put the payback period and the cash flow profile where they can be found in seconds, show what happens when the assumptions are wrong, and make sure someone will actually own each benefit you claim. Then keep the document, because its real value is being checked against reality a year later.
