Business Case: Structure, Contents and Ongoing Use
A business case is the document that justifies an investment: the problem, the options considered, the recommended option, its costs and benefits over a defined period, the assumptions behind those numbers, and the risks to achieving them. It is approved before funding is released and, in principle, reviewed at each stage to confirm the justification still holds.
What it contains
| Section | Content |
|---|---|
| Problem or opportunity | What is happening now and what it costs to leave it alone |
| Options | Normally including do nothing, a minimum option and the recommendation |
| Costs | One-off and recurring, split by category, across the appraisal period |
| Benefits | Cash-releasing, cost-avoiding and non-financial, each with an owner |
| Assumptions | The inputs the numbers depend on, stated so they can be challenged |
| Financial summary | Net position by year, payback period, and whatever measure the organisation uses |
| Sensitivity | What happens to the case if the main assumptions move |
| Risks | Threats to delivery and to benefit realisation, which are not the same list |
| Timeline | When costs are incurred and when benefits start, which rarely coincide |
How it is used
The case is written to get a decision, and that shapes it: the recommendation, the number and the payback period sit at the front, and the workings sit behind. Once approved, the case becomes the baseline for two later checks. At each stage boundary it should be asked whether the justification still holds, since costs move and benefits get reforecast. And at closure, the benefits section is handed to whoever now owns those benefits, which is where most cases fall apart.
Keeping it usable after approval is largely a structural problem. Where costs and benefits sit in a register with an owner and a date on each line, they can be tracked; where they sit inside prose in a slide deck, they cannot. The business case template is built that way — a cost and benefit register, an explicit assumptions log, payback, and a benefits realisation tab for the year after go-live. At portfolio level the same numbers feed the prioritisation view in the portfolio tracker, which is the point at which one project's case gets compared against another's. Handing the benefits on properly at the end is covered in project closure, and the closure report carries the tab for it.
Where it goes wrong
- Benefits with no owner. A benefit that no named person is accountable for delivering will not be measured, and nobody will notice.
- Assumptions buried. When the assumptions are inside the spreadsheet rather than listed, the case cannot be challenged properly and cannot be revisited when an input changes.
- Reverse-engineered numbers. A case built backwards from a decision already taken passes approval and provides no baseline worth measuring against.
- Do-nothing option omitted. Without it there is no counterfactual, and the cost of the status quo goes unstated.
- Closed at approval. The case is filed the day funding is released and never reopened, so nobody knows whether the investment paid.
- Delivery risks only. The risks that stop benefits being realised — adoption, process change, data quality — usually sit outside the delivery risk register and go untracked.
Related terms
Benefits realisation — the tracking of whether the benefits in the case actually arrived. Project charter — the authorisation document that follows approval. Payback period — the point at which cumulative benefit exceeds cumulative cost. Assumption — the A in RAID, and the thing most business cases rest on. Project closure — where the case is handed over rather than closed.
Questions
How long should a business case be?
Long enough to justify the number and short enough to be read by the people approving it. A summary of one to two pages with the detail behind it works better than a single long document.
What period should a business case cover?
Whatever period the organisation uses for investment appraisal, commonly three to five years from go-live. The period has to be long enough to include the benefits, since costs land first.
Who owns the business case?
The sponsor. The project manager may write it, but the sponsor is accountable for the investment holding up, and it is the sponsor who defends the number.
Should the business case be updated during delivery?
Yes, at each stage boundary or major change. Approved changes move costs and often move benefit timing, and a case that no longer reflects the position cannot be used to decide whether to continue.