Skip to content
Product Lifecycle Templates

Business Case

beta  ·  Family discovery-docs  ·  Phase discover  ·  Sizes lean, full  ·  ~2,200 tokens

The document that justifies an investment before anyone commits to making it: what problem it solves, what it is being compared against including doing nothing, and why the preferred option wins. Lean scopes the decision; full adds the costs, benefits, risks and financials a real funding gate needs.

How to tell whether you need one, how to pick lean or full, and how to grade what comes back before it reaches a funding decision.

Before you start: is this the right document at all?

Section titled “Before you start: is this the right document at all?”

Write a business case when a real investment decision is at stake and you need to say, in writing, what the investment is being compared against, including doing nothing. That comparison is the job. A document that argues for one option without naming what it beats is not a shorter business case, it is a proposal wearing a bigger name.

Write something else if:

You actually need Because
a project brief you need a short overview for starting up a project, not an investment case. A project brief absorbs an outline business case as one component and retires once initiation documentation exists; the business case itself keeps being refined, it does not retire with the brief
a trade study you are comparing technical approaches against weighted criteria, not comparing whether to invest at all. A trade study’s output feeds into Options Considered as one input, it does not replace the case
a PRD the investment decision is already made and you need to specify what gets built. A PRD deliberately excludes market opportunity and revenue, which is exactly the ground this document covers
a cheap way to test a hypothesis you would rather validate an assumption than build a funding case for a known investment. The named alternative tradition is the SAFe Lean Business Case, which substitutes a hypothesis and leading indicators for a financial model. It is a genuinely different document, not a shorter one, and it is not shipped in this library

Write nothing at all if no funding or go/no-go decision is actually on the table. The document exists to decide whether an investment is worth making; if nobody is deciding that, there is no case to make.

One posture worth adopting before you start writing. Every standard this library’s research could read in full treats the business case as revisited as the work proceeds, not filed once at approval and never reopened. Write it expecting to reopen it, not expecting to file it.

Picking a variant

Section titled “Picking a variant”

Lean carries Problem and Opportunity, Options Considered, and Recommendation: enough to scope a decision and name what it is being compared against, without a financial model behind it. Use it to get agreement that an idea is worth exploring further.

Full inserts Costs, Benefits, Risks and Financials between Options Considered and Recommendation, the four sections a reader needs to actually commit money rather than merely agree the idea is worth exploring.

The signal to move from lean to full: are you asking someone to agree an idea is worth exploring, or asking them to release real money? A rough estimate is a legitimate way to scope a decision, but the tolerance for an unexamined estimate should shrink as the decision gets closer to an actual commitment, which is exactly the point at which lean stops being enough.

If you would rather validate an assumption cheaply than build either size of this case, that is not a smaller version of this document. See the hypothesis-driven alternative named above, and do not reinvent a thinner version of this template to get the same effect.

The rubric

Section titled “The rubric”

Score each row 0, 1 or 2. Under 11 out of 16 on a full case, and finance should send it back before it reaches a funding decision. Under 6 out of 8 on a lean case, and it cannot carry the scoping conversation it exists to open, so that conversation gets decided on something other than what the document says. The lean variant scores against fewer rows because it does not ship the four sections a funding decision depends on; the scope table below says which.

# Criterion 0 1 2
1 Problem before solution The section names a solution, not a problem Names a problem, but you cannot point to who is affected or how the author knows You can point to who is affected, how the author knows, and nothing in the sentence already names the fix
2 Genuine alternatives One option only, or no do-nothing row A do-nothing row exists, but its rejection reason is a single adjective with no content behind it At least one alternative is a real option a reader could actually choose, and the do-nothing row states a genuine reason, not a formality
3 Cost adjustment visible (full only) One lump total, no breakdown, no adjustment shown Costs are broken into categories, but the optimism-bias adjustment is folded into the total invisibly The base estimate and the adjustment appear as separate numbers, and the adjustment states its basis
4 Benefits as ranges (full only) A benefit is named with no number attached A single confident point figure appears with no stated method behind it Each benefit is a range with a stated method, and no figure is one of the well-known unverified benefits-realisation statistics
5 Risk mechanism named (full only) A risk is a generic worry with no owner An owner is named, but the risk does not say whether it is closer to self-deception or deliberate overselling The mechanism is named, an owner is named, and a concrete trigger for reopening the case is stated
6 Financials caveated (full only) A metric is stated as a bare number with no caveat A caveat is present but generic, not tied to what that specific metric actually gets wrong Each metric carries a caveat drawn from that metric’s own documented limit, and no ratio is used as an automatic accept-or-reject rule
7 Recommendation earns its place The recommendation reads as a starting assumption with no link back to the analysis above it The recommendation names the chosen option, but the reasoning could apply to any of the options listed You can point to a specific line in Options Considered, and in Costs, Benefits, Risks or Financials where they exist, that the recommendation’s reasoning depends on
8 Post-go-live check named The post-go-live field is blank or says “TBD” A check is named, but with no owner or no date A named person checks a named outcome against this case’s own figures, on a stated date or trigger

Which rows apply to what. Full ships all eight rows because a funding decision depends on all of them. Lean ships only the four rows that do not require a section it does not carry.

Document Rows Maximum Score against
lean 1, 2, 7, 8 8 6
full all 8 16 11

Anti-patterns

Section titled “Anti-patterns”

The one-time gate. Filed at approval and never reopened. Every standard this research could read in full treats the opposite as the discipline: revisited as the work proceeds, with PRINCE2 naming a real consequence, if the case stops being justified, the work it justifies should stop too.

No genuine alternative. Missing a do-nothing row, or a do-nothing row rejected in a single adjective with no reasoning behind it. Both traditions this research read treat a named alternative as non-negotiable in substance, whichever tradition places the section differently in the document.

Optimism hidden in a lump total. A single already-adjusted cost figure with no visible base estimate or adjustment. The documented remedy is an explicit, empirically grounded adjustment shown separately from the base number, not vigilance alone, and the tolerance for skipping it should shrink as the decision gets closer to a real commitment.

Strategic misrepresentation mistaken for optimism. Treating every inflated estimate as innocent self-deception when some are deliberate. The two are complementary mechanisms, not one blurred into the other, and naming the wrong one misses the actual failure.

Decision-based evidence making. Assembling the case to support a decision someone has already made. This can happen even with no competing proposal in sight, which is what makes it easy to mistake for strategic misrepresentation; the fix is different because the underlying incentive is different.

Borrowed benefits-realisation statistics. Citing one of the well-known percentages that circulate in practitioner writing with a name attached. This research could not independently verify any of them, and repetition in your own case does not make an unverifiable number more credible.

A ratio used as an automatic verdict. Rejecting a proposal because its benefit-cost ratio misses a round number, or comparing IRRs across projects of very different scale without their dollar size attached. A lower ratio can still represent good value once benefits that were not monetized are weighed in, and a high percentage on a small base is not automatically the better bet.

No accountable check after go-live. The sources this research could read hand the check to an organisational layer on a generic schedule, a benefits review after the project closes, and stop there. Inheriting that generic answer is the anti-pattern. Say explicitly which person checks whether the expected benefits showed up, and on what date or trigger, rather than leaving it at the layer the standard names.

When it is good enough

Section titled “When it is good enough”

When someone with money to release can point to the alternative this recommendation beat, when the cost and benefit figures show their own adjustment rather than hiding it, and when a named person already knows they are checking this case’s benefits on a specific date after go-live.

Then delete every HTML comment, and treat the document as reopened rather than filed away. That is the discipline every standard this research could read in full insists on, and the distance between saying it and doing it is what this bundle was built around. How wide that distance is, no source this research could reach has measured.

The artifacts

Section titled “The artifacts”

business-case_template-lean.md · ~2,200 tokens

---
title: "{{investment_name}} Business Case"
investment_name: "{{investment_name}}"
sponsor: "{{sponsor}}"
stage: "{{stage}}"
status: "{{status}}"
last_updated: "{{date}}"
doc_type: business-case
size: lean
source_template: business-case
source_template_version: 0.1.0
---


<!--
LEAN BUSINESS CASE. The smallest case that is still a real case: the problem or opportunity worth acting on,
the alternatives it was actually weighed against including doing nothing, and the recommendation that
follows from that comparison. Use it to scope a decision before real money or a procurement commitment is at
stake, close to what a staged model calls a Strategic Outline Case. To grow it into a case that can actually
be funded (see business-case_template-full.md), ADD sections between Options Considered and Recommendation;
never rename or reorder the ones below, because the full variant is a strict superset of this one.


The frontmatter `stage` field names where this sits if your organization stages its cases (Strategic Outline
Case / Outline Business Case / Full Business Case, or your own equivalent gates); write "N/A" if it does not.


A BUSINESS CASE IS A LIVING DOCUMENT, NOT A ONE-TIME GATE. Every standard this library's research could read
in full treats it as revisited as the work proceeds, checked and updated as assumptions firm up, not filed
once at approval and never reopened. Most people use it as a one-time gate anyway; closing that gap is this
document's whole point. See business-case_companion.md section 1 and section 7.


WHAT A BUSINESS CASE IS, AND IS NOT
It decides whether an investment is worth making and says plainly what it is being compared against,
including doing nothing. It is NOT a project brief (a short overview that absorbs an outline business case as
one component and then retires once initiation documentation exists), NOT a trade study (a bounded technical
comparison whose output feeds Options Considered as one input), and NOT a PRD (which specifies what to build
once this document's investment decision has already been made). See business-case_companion.md section 8.


HOW TO FILL THIS IN
1. Read the comment under each heading: WHAT it wants, WHY it matters (with a pointer into
   business-case_companion.md), guiding questions to ASK, a GOOD and a WEAK example, and the TRAP to avoid.
   For the table, PRIORITY explains the ordering rule and ROW HINT says what a good row contains.
2. Replace each {{placeholder}} with your content. Name a do-nothing option in Options Considered even if you
   reject it in one line; a case naming no alternative is a proposal wearing a bigger name.
3. If a section does not apply, write "N/A" and one line of why, rather than deleting it.
4. This document is never really finished, but before you circulate it for a decision: self-grade against
   business-case_guide.md, then DELETE every HTML comment. They are guidance, not content.
-->


# {{investment_name}} Business Case


## Problem and Opportunity


<!-- WHAT  The problem or opportunity this investment addresses, who it affects, and why it matters now,
           described without naming the solution you already have in mind.
     WHY   Everything below has to answer to this section; treat it as foundational to the whole case rather
           than as background. It drives which options in the next section are even worth comparing. Deep
           dive: business-case_companion.md section 3 (Anatomy > Problem and Opportunity).
     ASK   What problem or opportunity is this? Who is affected, and how do you know? Why does it matter now
           rather than later? What happens if nothing changes?
     GOOD  "Analysts rebuild the same dashboard filters an average of three times a day, according to the
           2026-05 friction study; at current headcount that is a recurring tax on the team's scarcest
           resource, and it worsens as the analyst segment grows."
     WEAK  "We should build saved views." (a solution stated as if it were the problem; the next section has
           nothing genuine left to compare it against)
     TRAP  Naming a solution instead of a problem. If the "problem" is already the answer you want, Options
           Considered below cannot do its job, because the real comparison never happens. -->


{{problem_and_opportunity}}


## Options Considered


<!-- WHAT  At least two genuine alternatives, including a do-nothing baseline, with what each would involve
           and why it was accepted, carried forward, or rejected.
     WHY   This is the load-bearing section, and the one most likely to be skipped under time pressure.
           Standards disagree about where it sits in the document, some fold it inside a wider case, some
           give it a standalone heading, but none treats comparison against a named alternative, including
           doing nothing, as optional in substance. A case that skips this section is a proposal, whatever
           its own heading claims. Deep dive: business-case_companion.md section 3 (Anatomy > Options
           Considered), section 6 (the section-order debate), section 7 (anti-patterns).
     ASK   What are the realistic alternatives, including doing nothing? What would each concretely involve?
           Why was each accepted, carried forward, or rejected? Which one do you expect to recommend?
     PRIORITY  Every case needs a do-nothing row, even when it is rejected in one line. Mark exactly one
           option's status as the one carried forward into the Recommendation.
     ROW HINT  A good row names a real option, states plainly what it would take, and gives a genuine reason
           for its status. A weak row is a label with no content, or a straw-man option deliberately built to
           lose.
     GOOD  | OPT-2 | Build saved views into the existing dashboard shell | Reuses the current filter and
           permissions model; estimated 6 engineer-weeks | Carried forward |
     WEAK  | OPT-2 | Build it | Because it's the obvious answer | Recommended |
     TRAP  Including a deliberately weak straw-man alternative so the preferred option wins the comparison by
           default. Every option here should be one a reasonable reader could actually choose. -->


| ID | Option | What it would involve | Why accepted, carried forward, or rejected | Status |
|---|---|---|---|---|
| {{option_id}} | {{option_name}} | {{option_description}} | {{option_rationale}} | {{option_status}} |


## Recommendation


<!-- WHAT  The recommended option, the reasoning that follows from everything above it, the decision being
           asked for, and how the case will be checked after go-live.
     WHY   This is where the case commits, and it should read as the conclusion the analysis above earns, not
           as the starting point everything else was built to justify. Written the other way round, it is
           indistinguishable from a decision already made being dressed up with evidence after the fact. The
           sponsor named in the frontmatter is accountable for what this section states. It is also the
           section the sources this bundle could read leave unfinished: they describe how the case is
           revised up to approval, but none names who checks it after go-live, so state that check explicitly
           rather than leaving it assumed. Deep dive: business-case_companion.md section 3 (Anatomy >
           Recommendation), section 6 (decision-based evidence making), section 7.
     ASK   Which option is recommended? Why, given the comparison in Options Considered above? What decision
           or approval is being asked for, and by when? Who checks whether the expected benefits actually
           showed up after go-live, and when?
     GOOD  "Recommended: OPT-2 (build saved views into the existing shell). It clears the comparison in
           Options Considered on cost and reuses the current permissions model, avoiding OPT-3's rebuild
           risk. Decision requested: funding approval at the 2026-08-20 steering review. Post-go-live check:
           the sponsor reviews adoption and time-to-insight against this case's targets 90 days after GA."
     WEAK  "We recommend building saved views because it's the right thing to do." (no link back to the
           comparison, no decision named, no post-go-live check; nothing here follows from anything above it)
     TRAP  Writing this section first and backfilling the sections above it to support a decision already
           made. That is decision-based evidence making, and it can happen even when nobody is competing for
           the funding. -->


- Recommended option: {{recommended_option}}
- Why: {{recommendation_rationale}}
- Decision requested: {{decision_requested}}
- Post-go-live check: {{post_go_live_check}}

Provenance

Section titled “Provenance”

The reasoning, the history and every source, in the repository:

  • Companion - the long-form argument: why these sections, where the sources disagree, and what the bundle refuses to claim
  • History - what changed in this bundle, and when
  • Research log - every source consulted, with what each one actually supports
  • Catalog metadata - the machine-readable record this page is generated from

Catalog record: 7 sections across 1 format(s), methodology PMBOK strategy artifact; methodology-agnostic, typically owned by PM / Program Manager.