Business Case: What It Is and How to Write One

Key Takeaways

• A business case supports one decision. If you cannot write that decision in a sentence, the case is not ready.
• Doing nothing is always an option, and it is the baseline every other option's costs and benefits are measured against.
• Compare real alternatives. One proposal flanked by two weak options is a request, not a choice.
• NPV, ROI, payback and IRR answer different questions and can rank the same options differently. Show them together.
• Tie each benefit to the business capability it improves. That is what stops two projects from claiming the same saving.
• A benefit without a measure, a baseline, an owner and a date was never really claimed.

What Is a Business Case?

A business case is the written justification for spending money, time and attention on one course of action rather than another.

It answers four questions in order. Why act at all? Which option is best? Can the organization afford it and deliver it? How will anyone know, later, whether it worked?

A business case is not a budget request, which states what something will cost. It is not a sales pitch, which presents one option in its best light. And it is not a project plan, which assumes the decision has already been made. It is closer to a piece of evidence prepared for a judge: the decision-makers should be able to read it, test its assumptions, and reach their own conclusion, which may differ from the author's.

The best-known project management methods treat it as a living document rather than a hurdle cleared once. PRINCE2 makes continued business justification one of its principles: a project needs a valid reason to start, that reason must still hold at each stage boundary, and if it stops holding the project should be stopped. The business case is where that reason is recorded, so it is revisited as costs, benefits and risks change.

• Desirable: does the organization actually want the outcome, and does it serve a stated objective?
• Viable: do the benefits justify the costs and risks, compared with the alternatives?
• Achievable: can the organization deliver it, with the money, people and time available?

Business Case vs. Project Charter, Proposal and Feasibility Study

These documents are often confused because they share content. They answer different questions and are written at different moments.

The order matters. A feasibility study can come first, to establish whether an option is possible at all. The business case then decides whether, and which, option is worth doing. Once it is approved, a project charter authorizes the work and names who is in charge. A proposal can appear anywhere, but it argues for one option rather than comparing several.

What Goes in a Business Case?

Templates vary, but a complete business case covers the same ground. Each section exists to answer a question a reviewer will ask.

In the UK public sector, HM Treasury's Green Book points departments to the Five Case Model, which organizes a business case into a strategic case, an economic case, a commercial case, a financial case and a management case. It is a useful check for private-sector cases too: if one of the five is missing, a reviewer will notice the gap. The sections below map onto it. The strategic case covers the problem and objectives; the economic case covers options and their value; the commercial case covers how the solution will be bought; the financial case covers affordability; and the management case covers delivery, risk and benefits realization.

How Do You Write a Business Case?

Write it in the order a skeptical reader would question it, not in the order the template lists the sections.

1. Write the decision first. One sentence, which a committee can approve or reject: "Approve option B and release the year 0 budget to begin platform selection." Everything else in the document is there to support or test that sentence.

2. State the problem as a business outcome. "Claims take too long to settle because intake and adjudication hand work back and forth" is a problem. "We need a new claims system" is a solution wearing a problem's clothes, and it closes off the options before the comparison starts.

3. Describe what happens if nothing is done. Doing nothing is rarely free: costs drift up, risks grow, a support contract expires. This is the baseline, and every option is measured as a change from it.

4. Name the capabilities that must change. List the business capabilities involved, how well each performs today, and how well it needs to perform. This turns a vague ambition into a gap that can be closed and checked.

5. Generate real options. Include doing nothing, doing the minimum, and at least one option that differs in kind, not only in size. If every option but one is obviously poor, reviewers will assume the analysis was done to fit a conclusion.

6. Cost each option year by year. Include one-time and recurring costs, people and training, and the cost of running old and new in parallel. Ask finance how capital and operating spending should be split; the classification affects budgets even when it does not change the economics.

7. Quantify the benefits you can, and describe the ones you cannot. Separate cash benefits, such as lower handling cost, from cost avoidance, such as a support contract you will no longer need, and from benefits that are real but cannot be priced. Do not force the last group into the spreadsheet.

8. Compare the options and recommend one. Present net present value, payback and the other measures together, and say plainly why the recommended option wins, including where it is not the cheapest or the fastest.

9. Plan how the benefits will be checked. For each benefit, name the measure, its value today, the target, the owner and the date. Then write down every assumption behind the numbers, because that is the first place a reviewer will push.

The Numbers: NPV, ROI, Payback and IRR

Four measures appear in most business cases. Each answers a different question, and they can rank the same options in a different order.

Net present value (NPV) adds up each year's net cash flow after discounting it, so that money received later counts for less than money received now. The discount rate is normally set by the finance function and reflects what the organization's capital costs it. A positive NPV means the option earns more than that rate; between two options, a higher NPV means more value created in total.

Return on investment (ROI) is total benefit minus total cost, divided by total cost. It is easy to explain and ignores timing completely, which is its weakness: a benefit in year 5 counts the same as one in year 1.

Payback is how long it takes for cumulative net cash flow to turn positive. It speaks to risk and liquidity: the sooner an option pays back, the less exposed the organization is if circumstances change. It says nothing about what happens after payback. Discounted payback does the same calculation with discounted cash flows, so it is always a little longer.

Internal rate of return (IRR) is the discount rate at which NPV would be zero. It is often compared with the organization's hurdle rate. It is only well defined when the cash flows change sign once, typically spending first and benefits after. When a project has a second large outlay midway, there can be more than one IRR, and the figure should not be reported.

The table below uses the illustrative example from later in this article: a fictional insurer choosing between improving its claims process (option A) and replacing its claims platform (option B), over five years after year 0, at an 8% discount rate. All figures are invented to show how the measures behave.

Where Business Architecture Makes a Business Case Defensible

Most business cases are attacked on their benefits, not their costs. Business architecture is how you make the benefits hold up.

Costs are relatively easy to defend: there are quotes, rate cards and contracts. Benefits are where cases fall apart, usually for one of three reasons. The benefit is claimed by more than one project. The benefit is real but lands somewhere other than the case says. Or nobody can tell, a year later, whether it happened.

A capability map addresses all three. When every benefit is attached to the business capability it improves, two projects claiming to improve Claims Adjudication show up side by side instead of in separate documents, and the portfolio office can see that the same saving has been counted twice. A value stream shows where in the flow of work the improvement lands, which tells you whose budget the saving will actually appear in. And a capability's maturity today and its target maturity give the benefits realization plan something to measure besides spending.

The capability view also sharpens the strategic case. "Our claims system is old" invites the response that old systems can be patched. "Claims Adjudication operates at maturity 2 against a target of 4, and it is the stage where most rework happens" invites a different conversation, about the business outcome rather than the technology. Comparing options becomes a comparison of how far each one moves each capability, which is often more revealing than the cash flows.

This is also why the order of work matters. If the capability assessment comes after the business case, it tends to be used to decorate a decision already made. Done first, it shapes which options are worth costing at all.

Go further

• Business case vs. capability case — When to justify a single investment, and when to justify building a capability across several.
• Business capability analysis — How to assess importance and maturity, the evidence behind a capability-based case.
• Capability roadmap — How to sequence the capability gaps a set of business cases will close.
• Capability Map Visualizer — Common Level 1 and Level 2 capabilities by industry, to name the capabilities in your case.

A Business Case Example: Claims Modernization

An illustrative example. The insurer, its numbers and its outcomes are invented to show how a finished case reads.

A mid-sized insurer's claims division has a familiar problem. Straightforward claims take too long to settle, and the reason is not any single team. Intake accepts claims that are missing information; adjudication sends them back; they are re-keyed and re-assessed. The legacy claims system cannot be changed without a vendor project, so every new product rule adds another manual workaround. The support contract on that system renews in two years, on worse terms.

The business architect starts with the capability map rather than the vendor shortlist. Claims Intake and Claims Adjudication are both assessed at maturity 2 of 5; the strategy needs both at 4. Claims Payment is adequate at 3 and stays there. The value stream for settling a claim shows the rework loop between the intake and assessment stages, which is where the time goes.

Two real options emerge. Option A keeps the legacy system, standardizes the intake checklist and adds a workflow tool for handoffs: $250,000 up front and $40,000 a year, with savings of $120,000 in year 1 rising to $150,000 a year. Option B replaces the claims platform and redesigns intake and adjudication around it: $1,050,000 in year 0, $650,000 in year 1 including parallel running, then $150,000 a year, with rework savings reaching $450,000 a year and the legacy support cost of $250,000 a year avoided once the old system is retired.

On a five-year view at 8%, option A pays back in 2.5 years with an NPV of $161,420. Option B takes 3.7 years and has an NPV of $220,065. A committee looking only at payback would choose A. The business case recommends B, and says why in plain terms: option A improves intake but leaves adjudication, where most rework happens, at its current maturity, and it leaves the legacy support cost in place. B is the only option that brings both capabilities to target.

The risks section names data migration as the largest risk, with a mitigation that moves data profiling into year 0. The benefits realization plan commits to three measures: the share of claims returned to intake as incomplete, the cost to handle a claim, and the date the legacy system is retired. Each has an owner. That last section is what lets the committee approve B with confidence, because it says exactly how they will find out if the case was wrong.

Why Business Cases Fail

Business cases rarely fail because the arithmetic is wrong. They fail because of what the arithmetic is fed.

• Optimism. Costs are estimated low, timelines short, and benefits early and complete. HM Treasury's Green Book asks appraisers to adjust explicitly for optimism bias, which is a sign of how common it is. Test every estimate against a past project that went wrong.
• Straw-man options. One serious option and two that nobody would choose. Reviewers notice, and it costs the case its credibility.
• No baseline. Without a clear picture of what happens if nothing is done, benefits are measured against nothing in particular.
• Double-counted benefits. Two projects both claim the same headcount saving. A capability view makes this visible across the portfolio.
• Benefits nobody owns. If no manager has agreed to deliver a benefit in their budget, it will not appear there.
• Written after the decision. A case assembled to justify a choice already made reads that way, and stops being useful the moment circumstances change.
• Never revisited. A case that is not reopened when costs or risks change cannot tell anyone when to stop.

Business Case Template

You can write a business case in a word processor, but the numbers are where most templates leave you on your own.

The Business Case Builder is a free, in-browser template that follows the structure in this article. It walks through the decision, the strategic case, the capabilities affected, up to four options with year-by-year costs and benefits, the economic comparison, risks, benefit measures, implementation and assumptions. It calculates NPV, ROI, IRR, payback and discounted payback as you type, warns you about the gaps a review board asks about first, and produces a finished document you can print to PDF or paste into Word or Google Docs. Nothing you type leaves your browser.

• Business Case Builder (free) — The template in this article, with the arithmetic done for you. No sign-up.
• The business case for business architecture — How to make the case for funding an architecture practice itself.

Frequently Asked Questions

What is a business case?

A business case is a structured argument for a decision to invest. It states the problem or opportunity, compares the realistic options including doing nothing, sets out each option's costs, benefits and risks over time, and recommends one, so the people who control the budget can make a choice they can defend later.

What are the main parts of a business case?

An executive summary with the decision requested; the strategic case (problem, objectives, and what happens if nothing is done); the options considered; an economic comparison of their costs and benefits; the commercial approach and affordability; risks; a benefits realization plan; and the implementation approach and assumptions. The UK Five Case Model groups these into strategic, economic, commercial, financial and management cases.

How long should a business case be?

As long as the decision needs and no longer. A modest investment may need a few pages; a large transformation may need a full document with appendices. Whatever the length, the decision requested and the recommendation should fit on the first page.

What is the difference between a business case and a project charter?

A business case argues for whether to invest and in which option. A project charter comes after that decision and authorizes the chosen project: its scope, its manager's authority, its roles and its milestones.

Should a business case include a do-nothing option?

Yes. Doing nothing is the baseline every other option is measured against, and it is rarely free: costs drift, risks grow and contracts expire. Leaving it out makes the benefits of every other option impossible to judge.

What is the difference between NPV and ROI in a business case?

ROI divides total net benefit by total cost and ignores when the money arrives. NPV discounts each year's net cash flow, so later benefits count for less. Two options can rank differently on the two measures, which is why a business case should show both.

What discount rate should a business case use?

The rate your organization's finance function sets, which usually reflects what capital costs the organization. Using the official rate keeps cases comparable across the portfolio.

How does business architecture improve a business case?

By tying each benefit to the business capability it improves. That exposes benefits claimed by more than one project, shows where in the organization each benefit lands, and gives the benefits realization plan a measurable target: the capability's maturity, not just the money spent.

Pro Tips

• Write the executive summary last, but write the one-sentence decision first. If the summary and the decision disagree, the case has drifted.
• Put the do-nothing consequences in money where you can: a support contract renewal, a growing backlog, a known fine. Doing nothing is an option with costs.
• Show each benefit's owner by name and budget line. A benefit that no manager has agreed to deliver is a forecast, not a commitment.
• Run the numbers with costs 25% higher and benefits a year later. If the recommendation changes, say so in the risks section.
• Keep a version of the approved case. Benefits realization is judged against what was promised, not against the latest revision.