What goes in a project business case?

An executive summary, the reasons for the project, the options considered (including doing nothing), the expected benefits with baselines and named owners, the expected dis-benefits, the timescale, the costs, an investment appraisal, and the major risks to the case itself. The core of it is the comparison: this option, against the realistic alternatives, in numbers.

Why does a business case need a 'do nothing' option?

Because it is the baseline every other option is measured against, and it is sometimes the right answer. A business case with only one option is not a case, it is a proposal with a decorative table. Doing nothing usually has a cost too — the problem continues — and quantifying that cost is what makes the recommended option persuasive.

What is a dis-benefit?

A dis-benefit is an outcome of the project that someone will experience as a loss — not a risk, but a certainty you are accepting. Disruption during transition, a capability given up, a team tied up for six months and unavailable for anything else. Every real project has them, and a business case claiming none is not being believed by anyone experienced.

What is an investment appraisal?

The comparison of what the project costs against what it returns, over a stated period. It can be as simple as payback period — how long until the benefit repays the spend — or use discounted measures such as net present value. What matters is that the figures are traceable to real assumptions, and that the assumptions are written down where someone can challenge them.

Home · Templates · Business case

Business case template

Q: When is the business case reviewed?

At every stage boundary. The question it answers is not 'was this a good idea?' but 'is it still worth finishing, given what we now know and what remains to be spent?' Costs already sunk are irrelevant to that decision. The business case is the mechanism for stopping a project that no longer makes sense, which is its most valuable and least used function.

A free, editable Word template for the document that justifies the project — and the one the board should return to at every stage boundary to ask the question nobody enjoys: is this still worth finishing?

Business case template — Word (.docx)

Options table including "do nothing", benefits with baselines and owners, dis-benefits, costs, investment appraisal and risks to the case. No email wall.

Download the template

What a business case is actually for

Most people write a business case to get a project approved, then never open it again. That is a waste of the single most useful document in project governance.

Its real job is to be the thing you come back to. At every stage boundary the board asks one question — given what we now know, and what is left to spend, is this still worth finishing? — and the business case is what they ask it against. Which means it has to be honest enough to be capable of saying no. A business case that could only ever have justified going ahead is not a case. It is a sales document with a table in it.

The options table — where most business cases quietly fail

You need at least three: do nothing, do the minimum, and the thing you actually want to do. Mark the recommended one and say why it wins.

Option	What it means	Cost / consequence
Do nothing	Carry on as we are. The baseline every other option is measured against.	Not zero. The problem continues, and that has a price — quantify it.
Do the minimum	The cheapest intervention that addresses the worst of the problem.	Lower cost, partial benefit. Often uncomfortably reasonable.
The proposal — chosen	What you are asking for, and what it delivers that the others don't.	Full cost, full benefit. The one you must justify against the other two.

"Do nothing" is not a formality. It is the option your board is silently comparing you against anyway, so put it on the page and price it. A project that cannot beat doing nothing on paper is not a project — and finding that out now is a great deal cheaper than finding it out in month five. Occasionally the honest answer is that "do the minimum" wins. Write it down when it does; your credibility next time is worth more than this one approval.

Benefits — with a baseline and an owner, or they are not benefits

"Improved efficiency" is not a benefit. It is a mood. A benefit has four parts, and if you cannot supply all four, you do not yet have one:

Part	Question	Example
Measure	What number moves?	Average order processing time.
Baseline	What is it today? Measured, not guessed.	14 minutes per order (sampled over March).
Target	What will it be, and by when?	Under 5 minutes, within 3 months of go-live.
Owner	Which named person is accountable for it happening?	Operations Manager — not the project manager.

The baseline is the one everybody skips, and skipping it is fatal: without a "before" number you can never prove an "after" one. A year later, when someone asks whether the project was worth it, the honest answer will be "we think so" — and that is how organisations learn to stop believing business cases.

The owner matters just as much, and it is never the project manager. The PM delivers the capability; someone in the business has to actually use it to produce the benefit, long after the project has closed.

Dis-benefits — the section that buys you credibility

A dis-benefit is not a risk. A risk might happen; a dis-benefit is a certainty you are choosing to accept. Six weeks of disruption during transition. A capability you are giving up. A team tied up until autumn and therefore unavailable for anything else. A dependency on one supplier you did not have before.

Every real project has them. A business case claiming none is not being believed by anyone experienced — and the reader who spots the omission stops trusting the rest of your numbers. Naming your own downsides is the cheapest credibility you will ever buy.

Costs and investment appraisal

Costs: the build, plus the running cost afterwards, plus the internal time nobody ever counts. That last one is where business cases lose their honesty — "we'll absorb it internally" is a cost, it is just one you have decided not to write down.

The appraisal compares that spend against the return over a stated period. Payback period is usually enough for a small project: how long until the benefit repays the spend? Larger or longer-lived investments may justify discounted measures like net present value.

The rule that matters more than the method: every figure must be traceable to a written assumption. A payback period with no visible assumptions is not analysis — it is a number someone made up, and an experienced reader will treat the whole document accordingly. Better to write "we cannot yet quantify this; here is what we would need to measure" than to invent a plausible-looking return.

Risks to the business case itself

Not every risk on your risk register — only the ones that, if they fired, would mean the project was no longer worth doing. Usually a handful. They are what the board is really buying when they approve the case, and they are what should trigger a re-examination if any of them starts to look more likely.

Why business cases fail

Written once, to get approval. Filed after the gate, never consulted at a stage boundary. The project then runs to completion on momentum alone.
One option. No "do nothing", no cheaper alternative — so there was never a decision to make, only a proposal to rubber-stamp.
Benefits with no baseline. Nothing was measured before, so nothing can be proved after.
Benefits owned by the project manager. Who leaves at closure, taking accountability with them.
No dis-benefits. Reads as advocacy, not analysis.
Never used to stop anything. The business case's most valuable function is killing a project that no longer makes sense. If yours has never done that, ask yourself whether it is doing anything at all.

A template is a snapshot. A project moves.

Costs change, risks fire, benefits get re-forecast — and the business case in your documents folder knows none of it. In Guddle the business case is a living view: costs summed straight from the stage plan, major risks pulled from the register, exportable to a branded PDF whenever the board asks for it. Paste a plain-English brief and Guddle will even draft the options, benefits and appraisal for you to review — using only the figures your brief supports, never invented ones.

Start free — first project on us

The other templates

PIDThe baseline you control against Project briefComes before the business case Risk registerWith 5×5 scoring built in

Common questions

When is the business case reviewed?

At every stage boundary. The question is never "was this a good idea?" but "is it still worth finishing, given what we now know and what remains to be spent?" Money already spent is irrelevant to that decision, however much it hurts to ignore it.

How long should it be?

Short enough that the board reads it. On a small project, two pages with an honest options table and four properly-baselined benefits beats thirty pages of narrative.

Is this an official PRINCE2 template?

No. It is an independent template written from scratch, aligned with the method's approach to business justification. It is not affiliated with, endorsed by, or copied from PeopleCert or AXELOS materials.