A business case is not just “some slides and a model.” It is a structured argument. The anatomy matters because executives read in patterns: they expect to see the question, the options, the economics, the risks, and the plan in a predictable order. When you follow a clear structure, reviewers can skim what they know, focus on what they question, and reach a decision faster.
This chapter sets out the canonical section order and purpose, the optional/advanced sections and when to use them, the standards you should apply to evidence, how deep to go by decision size, and a final completeness checklist you can use before submission.
5.1 Canonical Section Order and Purpose
Think of the canonical structure as the “spine” of every decision-grade case. You will adapt and compress it, but you should rarely deviate from the basic order.
Cover and metadata
Purpose: Make ownership, version, and status obvious.
Content: Title, sponsoring function, case lead, date, version, confidentiality label, and distribution list. This prevents people debating outdated versions, and makes it easier to track commitments later.
Executive summary
Purpose: Let a busy decision-maker understand and decide in minutes.
Content: The ask, the recommendation, the key numbers (economics and risk), and the high-level plan. This is not a teaser; it must be fully decision-grade. Many readers will only read this section carefully.
Problem/Opportunity and “Why Now”
Purpose: Establish why this decision matters and the value at stake.
Content: Clear articulation of the current state, the pain or opportunity, the size of prize, and the consequences of inaction. This is where you connect to strategy, external forces, and internal performance gaps.
Objectives and success metrics
Purpose: Define what “good” looks like before you propose solutions.
Content: The 3–5 KPIs or outcome metrics that will define success, with indicative targets and timeframes. For public sector or ESG cases, include non-financial outcomes and how they will be assessed.
Options and baseline
Purpose: Demonstrate that you have explored credible alternatives, not just your favorite idea.
Content: At minimum: “do nothing” baseline plus 2–3 realistic options that differ on scope, timing, and approach (e.g., build/buy/partner). You should define evaluation criteria before scoring: strategic fit, economics, feasibility, risk, time to impact.
Recommended option and rationale
Purpose: Explain clearly why this option is best, given the criteria.
Content: Concise description of the recommended option’s scope (what’s in, what’s out), how it compares on each criterion versus alternatives, and key trade-offs you are consciously making (e.g., accepting higher Capex for lower long-run OpEx, or slower rollout for lower risk).
Economics (costs, benefits, and financials)
Purpose: Show the value logic and the numbers in a way finance can own and executives can understand.
Content: Headline costs (Capex/OpEx; one-time/run-rate), quantified benefits (revenue, margin, cost, risk), cash flow profile, and core investment metrics (NPV, IRR, payback, or public-sector equivalents such as benefit-cost ratio). Include sensitivities (what moves the case) and scenarios (base, downside, upside).
Risks, dependencies, and mitigations
Purpose: Make risk explicit and manageable.
Content: Top risks, their likelihood and impact, mitigations, and residual risk after mitigations. Key dependencies (vendors, other initiatives, regulatory decisions, critical hires) and how they will be managed. This section gives comfort that you have looked around corners.
Implementation and change plan
Purpose: Demonstrate that value can actually be delivered.
Content: Phases, milestones, critical path, resourcing (internal and external), high-level workstreams, and a view of change management (communications, training, org impacts). You are not writing a full project plan, but you must show the path is plausible.
Governance, decision rights, and funding
Purpose: Clarify how the initiative will be controlled and steered.
Content: Governance structure (steering committees, design authorities), decision rights, stage-gates, and the link between gates and funding tranches. This reassures approvers that they are not writing a blank check.
Measurement and benefits realization
Purpose: Ensure benefits are tracked, owned, and realized post-approval.
Content: KPIs, baselines, benefit owners, target trajectories, data sources, and review cadence. This section connects the promises in economics to operational accountability.
Appendices and supporting evidence
Purpose: Provide depth without bloating the main narrative.
Content: Assumptions log, model documentation, detailed cost/benefit calculations, vendor proposals, regulatory and security assessments, architecture notes, research summaries, and any assurance reports. Anything referenced in the main body should be findable here.
If you maintain this order, reviewers will quickly learn where to find what they care about, and you will spend far less time rewriting to “their preferred structure.”
5.2 Optional/Advanced Sections and When to Use Them
Not every case needs every advanced section. Use them when the decision merits the extra rigor or the audience explicitly expects it.
Portfolio and capacity context
Use when the approver manages a portfolio (e.g., ExCo, portfolio board). Include a short section that shows:
- Where this initiative sits on the value-vs-risk map.
- How it interacts with existing initiatives (synergies, conflicts, shared resources).
- What must be delayed or dropped if this is approved.
Regulatory and policy impact statement
Use when regulations, licenses, or policy constraints are material.
Content: Relevant rules, how the initiative complies or improves compliance, any approvals required, and the consequence of non-compliance. This may be mandatory in regulated industries or the public sector.
ESG and stakeholder impact
Use when sustainability, social impact, or stakeholder expectations are part of the strategy or external commitments.
Content: Environmental footprint changes, social implications (jobs, community, inclusion), governance implications, and how these will be measured. Avoid over-financializing soft benefits; be honest about what is measurable.
Technical architecture and data
Use when success hinges on technology decisions.
Content: High-level architecture diagram, key design choices (e.g., cloud vs on-prem, vendor vs in-house), integration points, major technology risks, and data considerations (ownership, quality, lineage). Ensure it reads as an executive-level architecture note, not a design specification.
Vendor and commercial structure
Use when the initiative relies heavily on external suppliers or partners.
Content: Procurement approach (RFP vs single-source), vendor shortlist, commercial models (fixed price, outcome-based, subscription), key terms and risks (lock-in, SLAs, termination). This section often reassures CFOs and procurement.
Scenario and options valuation
Use for high-uncertainty, high-optionality contexts (e.g., staged innovation, real-options decisions).
Content: Clear scenarios (e.g., low/medium/high adoption, different regulatory futures), their probabilities if you assign them, and implications for value and strategy. If you explicitly use real-options thinking (e.g., option to expand, abandon, or pivot), summarize it in business language.
Public value / distributional impact
Use in public sector or where distribution of benefits matters.
Content: Who gains and who loses (citizens, regions, groups), equity considerations, and distribution of costs/benefits over time. This can be critical in grant-funded or politically visible initiatives.
Ethics and risk appetite alignment
Use when the initiative touches sensitive topics (AI, data usage, customers in vulnerable situations, workforce reductions).
Content: Ethical considerations, alignment with stated values, mitigation plans (e.g., human-in-the-loop, impact assessments), and how you stay within risk appetite.
You do not need all of these in every case. The test is simple: if the absence of such a section would cause a key decision-maker to push back (“Where is the regulatory impact?”), include it.
5.3 Evidence Standards and Citation Practices
Strong business cases show their working. Weak ones bury opinions under impressive formatting. Set explicit standards up front and stick to them.
Evidence hierarchy
In most organizations, evidence quality broadly falls on this spectrum:
- Direct, observed internal data (transaction records, system logs, audited financials).
- Credible external data and benchmarks (industry reports, regulator data, analyst reports).
- Structured primary research (customer interviews, surveys, experiments, pilots).
- Expert judgment (internal or external SMEs), clearly labeled as such.
You will use all four, but you should be explicit about which is which and not let judgment masquerade as data.
Minimum practices for evidence
- Date everything: “As of Q3 FY25, source: X.”
- Name an owner for each dataset or estimate (finance, sales ops, risk, HR analytics).
- Show ranges where uncertainty is material, not point estimates that imply false precision.
- Check internal consistency: numbers in text, charts, and model must match.
Citation practices in internal cases
You are not writing an academic paper, but you must allow reviewers to trace claims. Simple patterns work best:
- Inline reference to source and date in text: “Customer churn increased from 8% to 11% over 12 months (CRM data, FY24).”
- Short footnote or endnote for external sources: report name, publisher, publication year.
- Hyperlink where appropriate to internal dashboards or repositories, with note on data extraction date.
If you refer to expert judgment, label it clearly: “Estimate based on sales director interviews (July 2025); any variance from actuals will be tracked in the benefits review.”
Using pilots and experiments
For cases built on pilots or experiments:
- Document design (sample, control, duration, metrics).
- Note limitations (biases, external factors, sample representativeness).
- Show how you scale from pilot to full-scale economics (assumptions for adoption, saturation, learning curve).
Handling weak or missing evidence
You will sometimes lack strong data. In that situation:
- State explicitly where evidence is weak and which assumptions you adopted.
- Use ranges and scenarios, not a single “best guess.”
- Commit to a learning plan: what you will measure early and how it may adjust scope or pace.
You gain more credibility by admitting uncertainty and structuring around it than by asserting unwarranted confidence.
5.4 Proportionality: Depth by Decision Size
Not every decision merits a 40-page case and a fully engineered model. The effort should match the combination of materiality, irreversibility, and risk. A practical way to think about this is three “tiers” of depth.
Tier 1 – Minimum-Viable Business Case (MVBC)
Use when: Smaller, reversible decisions; limited cross-functional impact; spend within a manager’s discretionary envelope.
Typical characteristics:
- 5–7 pages (or 10–12 slides) plus a compact model.
- Short executive summary, problem/opportunity, options, recommended option, headline economics, top 3 risks, and first 90 days of the plan.
- Light assumptions log, often embedded in the model itself.
- Pre-wiring mostly with my boss and finance partner.
Goal: Enable a clear decision fast while capturing key assumptions in a reusable format.
Tier 2 – Standard business case
Use when: Moderate to large spend; multi-year commitment; significant cross-functional dependencies; ExCo-level attention.
Typical characteristics:
- 15–25 pages (or 20–30 slides) plus detailed model and appendices.
- Full canonical structure: all core sections from executive summary through measurement.
- Consolidated assumptions log, evidence references, and structured risk register.
- Formal reviews by finance, risk/compliance, and architecture/IT.
- Pre-wiring with sponsors, key functional heads, and at least one independent challenge.
Goal: Provide a robust, comparable basis for capital allocation and portfolio trade-offs.
Tier 3 – Board-grade or transformational case
Use when: Very large or strategically defining decisions; M&A; existential technology shifts; material regulatory exposure; board approval required.
Typical characteristics:
- Concise main pack (often 10–15 board-level slides) supported by extensive appendices and a robust model.
- Advanced sections as needed (portfolio context, regulatory and ESG, architecture, vendor/commercial, integration thesis, scenario and options valuation).
- Multiple scenario sets, including stress tests and downside cases.
- Independent validation (e.g., finance, internal audit, external advisors).
- Explicit stage-gate structure with granular funding tranches and risk controls.
Goal: Ensure the board can discharge its fiduciary duties, understand downside risk, and be confident in management’s readiness.
When unsure which tier to use, start by sketching an MVBC. As you answer stakeholder questions (“What about integration risk?” “How does this compare to other portfolio options?”), you will quickly see whether the case needs to “grow up” into Tier 2 or Tier 3.
5.5 Contents Completeness Checklist
Use this checklist as your last gate before circulating a draft. Adjust the level of detail by tier, but try not to skip any item without a conscious decision.
Decision framing and ownership
- Case has a clear title, sponsor, case lead, date, version, and distribution list.
- The decision, the ask, and the decision body are explicitly stated on page one.
- Strategic link (“how this supports our strategy”) is clearly articulated.
Problem/opportunity and objectives
- Current state and pain/opportunity are described with at least one quantified fact.
- “Why now” is explained (triggers, windows, risks of inaction).
- 3–5 objectives or success metrics are defined, including timeframes.
Options and baseline
- “Do nothing” baseline is defined and quantified.
- At least two credible options beyond the baseline are described.
- Evaluation criteria are defined before options are compared.
- Key trade-offs between options are explicit.
Recommended option and scope
- The recommended option is clearly named and described.
- Scope boundaries (what’s in, what’s out, where, when) are explicit.
- Rationale versus alternatives is clear and linked to the criteria.
Economics and modeling
- Time horizon and discount rate (or equivalent) are stated.
- Costs are split into Capex/OpEx and one-time/run-rate, with sources.
- Benefits are attributable, time-phased, and grouped by driver (revenue, cost, risk).
- NPV, IRR, and payback (or appropriate metrics) are calculated and shown.
- Sensitivities on top 3–5 drivers are provided.
- At least one downside scenario is presented and discussed.
Risks, dependencies, and controls
- Top risks (not a laundry list) are identified, with likelihood and impact.
- Mitigations and residual risk for each top risk are described.
- Material dependencies (vendors, initiatives, regulatory approvals) are listed with owners.
- Any regulatory, security, privacy, safety, or ESG implications are addressed or explicitly stated as non-material.
Implementation and change
- High-level plan (phases, milestones, critical path) is described.
- Resource plan (key roles, internal capacity, vendors) is outlined.
- Change-management elements (communications, training, org impacts) are addressed at least at a high level.
- Exit/stop-loss criteria are defined where appropriate.
Governance, funding, and benefits realization
- Governance structure (committees, decision rights, cadence) is defined.
- Funding ask is broken into tranches aligned to stage-gates where feasible.
- Benefit owners are named for each material benefit stream.
- KPIs, baselines, targets, and data sources are specified.
- Benefits tracking and review cadence are defined (who, how often, in which forum).
Evidence and documentation
- Assumptions log exists and is up to date.
- All material numbers have traceable sources and owners.
- Evidence quality is indicated (data vs benchmark vs expert judgment).
- Appendices contain the detailed model outputs, vendor quotes, and key supporting analyses referenced in the main body.
