ع
Learn Tracks Reference Guides Saved
playbook

Build the business case

Turn a requirements doc into a defensible cost-benefit case: quantified where you can, honest about what's a guess, with the payback math and the risks that could break it laid out for a named decision-maker.

medium ~45 min
when to reach for this

You've got a signed-off requirements doc and stakeholders who want the initiative funded — but 'it'll help' isn't a business case. A funding decision needs numbers: what it costs, what it returns, when it pays back, and what could go wrong with that math. This system builds that case from what you already have, keeps every benefit tagged as measured or estimated, and stops short of the confident-sounding fiction a generic prompt will hand you if you let it guess in silence.

gather this first
  • The signed-off requirements doc (from Write the requirements doc) — the case has to be built from what's actually in scope, not a wish list.
  • The options analysis, if one exists — a chosen option changes what costs and benefits you're even costing out.
  • Any real numbers you have: current process cost, headcount time, error/rework rates, vendor quotes, past project actuals. Even rough ones are better than none, as long as they're labeled.
  • The name of who signs off on funding and what they'll actually ask — a case aimed at a CFO reads differently than one aimed at a department head.
the workflow

  1. Ground the case in the requirements, not a blank page

    Open the requirements doc and any options analysis in Claude Desktop and ask for a plain read-back of scope before any numbers get built. A business case for the wrong scope is worse than no case.

    you ask
    Read requirements-doc.md and options-analysis.md if it exists. Summarize in 5 bullets: what's actually in scope, what's explicitly out of scope, which option (if chosen) this case should cost out, and which stakeholder need this initiative traces back to. Don't estimate costs or benefits yet.

    what you get back A scope read-back naming the in-scope work and the specific stakeholder need driving it — e.g. 'traces to Ops' need to cut invoice processing time, per requirement R4' — so the case can't drift from what was actually agreed.

    If the read-back surfaces scope the requirements doc doesn't cover, stop and get it added there first — the case should never out-run the signed-off requirements.

  2. Build the cost side, labeled by confidence

    Feed in whatever real numbers you have and ask for a structured cost breakdown that's explicit about what's known versus assumed.

    you ask
    From the scope above and these numbers I have [paste any known costs — vendor quotes, hours, current spend], build a cost breakdown: one-time build/implementation costs, ongoing costs, and internal time cost. For every line, label it MEASURED (I gave you a real number), ESTIMATED (a reasonable industry/internal benchmark), or ASSUMED (a placeholder that needs a real number before this goes to sign-off). List the ASSUMED lines separately at the end as 'numbers I still need.'

    what you get back A three-tier cost table plus a short punch-list of assumed figures still needing a real source — so nothing quietly passes off a guess as a fact.

  3. Build the benefit side the same way

    Benefits are where cases get inflated. Apply the same MEASURED/ESTIMATED/ASSUMED discipline, and ask Claude to show its math, not just a final number.

    you ask
    Now build the benefit side against the same stakeholder need: time saved, cost avoided, revenue protected or enabled, and risk reduced. For each benefit, show the calculation (e.g. 'X hours/week × Y people × Z hourly rate'), label it MEASURED/ESTIMATED/ASSUMED the same way, and flag any benefit that depends on adoption or behavior change rather than the tool alone.

    what you get back A benefit table with visible math for every line and an explicit flag on 'soft' benefits that depend on people actually changing how they work — so an optimistic number can't hide behind a clean total.

    A benefit with no visible calculation is a guess wearing a business case's clothes. Push back if Claude hands you a number without the arithmetic behind it.

  4. Calculate payback and run the downside

    Turn the two sides into the numbers a decision-maker actually asks for, then stress-test it — what happens if the ESTIMATED and ASSUMED lines run worse than hoped.

    you ask
    Calculate simple payback period and first-year net benefit from the cost and benefit tables. Then run a downside case: if every ESTIMATED benefit comes in at half, and every ASSUMED cost comes in 30% higher, what's the payback then? Show both cases side by side.

    what you get back A base-case and downside-case payback comparison — e.g. 'base case: 7-month payback; downside: 13-month payback, still net-positive in year one' — so the sign-off decision sees the range, not one flattering number.

  5. Write the risks that could break the math

    Ask specifically for what could invalidate the case — not generic project risks, but the things that would change the cost-benefit math itself.

    you ask
    List the top risks that could specifically break this cost-benefit math — adoption risk, a dependency on another team's timeline, a cost that could scale beyond the estimate, a benefit that assumes a process no one has actually changed yet. For each, note the likely impact on payback if it hits.

    what you get back A short, math-specific risk list, each tied to what it does to the payback number if it materializes — not a boilerplate risk register.

  6. Assemble the case for the named decision-maker

    Pull it into the document the actual sign-off person will read, in the register they expect.

    you ask
    Assemble a one-page business case for [name/role of decision-maker]: the problem and stakeholder need, the recommended option, cost and benefit summary with the MEASURED/ESTIMATED/ASSUMED labels intact, payback (base and downside), the key risks, and a clear ask. Keep it in a register a [CFO/department head] would expect — direct, numbers-first, no hedging language.

    what you get back A funding-ready business-case document, labeled honestly throughout, addressed to the actual approver — ready to attach to the requirements doc for sign-off.

make it your own
  • No options analysis yet: run this against a single proposed approach instead of a chosen option — just say so explicitly in the case so the decision-maker knows only one path was costed.
  • Multiple funding tiers: ask Claude to build the same cost/benefit table at two scope sizes (a minimal version and the full requirements-doc scope) so the decision-maker can approve a smaller bet first.
  • Recurring initiative: for a program rather than a one-off project, ask for a 3-year view instead of first-year net benefit — the payback math changes shape once costs and benefits repeat annually.
  • Feeds sign-off: once approved, this case becomes the attached evidence in Requirements to sign-off — the traceability chain runs need → requirement → option → costed case → sign-off.
watch out for
  • A confident number is not a real number. Never let an ESTIMATED or ASSUMED line sit in the final case without its label — a decision-maker approving budget on a disguised guess is the traceability guardrail failing at the last step.
  • Claude can compute payback correctly from wrong inputs and hand you a clean, wrong answer. Verify every MEASURED figure against its source and sanity-check every ESTIMATED one against someone who knows the real number before this goes to sign-off.
  • A business case with no downside case is a sales pitch, not a case. Always ask for the stress-tested version — the range is what makes it defensible, not the best-case headline.
  • Don't let the case drift past what the requirements doc actually scoped. If a benefit only holds for a bigger scope than what was agreed, that's a sign the requirements doc needs revisiting first, not a shortcut to a bigger number.

you'll end up with A funding-ready business case, honestly labeled by confidence, with base and downside payback math and the risks that could break it — traced back to the requirements doc and addressed to the person who actually signs off.

Questions people ask

What's the difference between MEASURED, ESTIMATED, and ASSUMED?
MEASURED means you gave Claude a real number from your own data. ESTIMATED means it's a reasonable benchmark standing in for a number you don't have yet. ASSUMED means it's a placeholder that must be replaced with a real figure before the case goes to sign-off. Keeping these labels visible in the final document is what stops an optimistic guess from reading as a fact.
Do I need the options analysis before building a business case?
It helps but isn't required. If no options analysis exists, cost out the single proposed approach and say so explicitly in the case — the decision-maker should know only one path was evaluated, not assume alternatives were ruled out.
Why build a downside case if it makes the numbers look worse?
Because a business case with only a best-case number is indistinguishable from a sales pitch. Showing the payback under a stress-tested downside is what makes the case defensible when someone on the approval side pushes back on the assumptions.
How does this connect to requirements-to-sign-off?
The business case is the costed evidence that gets attached alongside the requirements doc when it goes for formal approval — it's one more link in the traceability chain from stakeholder need to signed-off, funded initiative.