Business Case Fundamentals: Definition & Purpose

2.5 Scope Boundaries: What to Include and Exclude

Strong cases focus on decision‑critical content and push everything else to appendices or to other documents entirely. These boundaries prevent bloat, reduce review noise, and keep the approval conversation on the merits.

Include in the main body (nearly always):

• Decision framing and the ask. Who decides, by when, on what criteria.
• Problem/opportunity and “why now.” Quantified size of prize and cost of inaction.
• Options analysis. At least two credible alternatives plus baseline; evaluation criteria and high‑level scoring.
• Economic summary. Time‑phased costs and benefits; NPV/IRR/payback (or public‑sector equivalents such as BCR/NPV of societal benefits), sensitivities for top drivers, scenario ranges.
• Top risks and mitigations. Limited to the handful that can move the decision; residual risk explicit.
• Delivery feasibility. Phases, milestones, critical path, major dependencies, and resource outline.
• Governance and measurement. Decision rights, funding tranches, KPIs, benefit owners, and cadence.
• Clear ask and next steps. Approval sought, conditions, and immediate actions.

Include in appendices (as needed, not by default):

• Assumptions log with sources, ranges, and confidence levels.
• Model documentation. Driver dictionary, cell maps, and version history.
• Detailed cost build‑ups. Vendor quotes, rate cards, sizing assumptions.
• Detailed benefit calculations. Attribution logic, adoption curves,leakage assumptions.
• Legal/privacy/security confirmations or exception summaries.
• Architecture and process detail sufficient to support feasibility claims.
• Sensitivity tables and scenario matrices beyond the top‑line view.
• Assurance reports (finance review, audit, cyber assessment).
• Stakeholder input summaries (interview notes, survey results) where relevant.

Exclude entirely (or move to separate documents) unless explicitly requested:

• Marketing copy and brand narratives not tied to the decision.
• Solution blueprints at a level suitable for engineers (e.g., detailed user stories, wireframes, configuration tables). Those belong in design/requirements documents referenced by the case.
• Training materials, SOPs, and support playbooks. Keep them out of the case; cite them as readiness artifacts if needed.
• Excessive historic context that doesn’t affect the decision (e.g., year‑by‑year chronologies). Summarize to one paragraph if materially relevant.
• Speculative benefits without attribution logic or evidence. If a benefit cannot be traced to a driver, exclude or mark as qualitative only.
• Unbounded scope lists (“everything we might do later”). Focus the recommendation on a defined scope; future phases can be decision‑points with gates.
• Internal politics and personalities. Frame stakeholder dynamics in terms of risks, dependencies, or change management—not personal commentary.
• Raw data dumps or lengthy vendor proposals; abstract the essentials and reference the source.

Boundary rules for modeling.

• Delta, not total. Model incremental economics relative to the status quo. Don’t rebuild the full corporate P&L unless the decision alters it materially.
• Materiality filter. Include a cost/benefit only if it could move the decision; otherwise note it qualitatively or exclude.
• Conservatism with transparency. Prefer conservative estimates and disclose your rationale; optimism bias destroys credibility.
• Time and discount discipline. Declare the horizon and discount rate; keep them consistent across options.
• No double counting. Benefits that are causally linked (e.g., churn reduction and revenue growth) must be treated with attribution logic to avoid overlap.

Boundary rules for risk and compliance.

• Top risks only in the main body. Limit to those with board‑level visibility or decision‑moving potential.
• Residual risk statement. Always state what risk remains after mitigations and why it is acceptable (or what additional funding is needed to reduce it).
• Regulatory/ESG/ethics inclusion by materiality. If the decision materially changes customer outcomes, workforce composition, environmental footprint, or compliance posture, include a succinct analysis and controls.

Boundary rules for delivery content.

• Show feasibility, not every task. Provide phases, milestones, critical path, and capacity plan; leave detailed work breakdowns to the program plan.
• Stage‑gate alignment. Tie funding tranches and exit criteria to gates; approvals should not be “all or nothing” unless the decision is binary by nature.
• Vendor path clarity. If success depends on procurement, note sourcing strategy and timelines; move RFP/RFQ detail to appendices.

When to broaden scope.

 Occasionally, decision‑makers need to see the portfolio level (e.g., cumulative capacity constraints, cross‑initiative dependencies). In those cases, add a short section that: (i) shows the interaction with other funded work, (ii) highlights what will be delayed or deselected if your case is approved, and (iii) confirms the net portfolio effect on KPIs or risk. Keep it to a page; the portfolio view should guide prioritization, not drown the case in program management detail.

When to narrow scope.

 If the initiative includes both mandatory and discretionary components, split the decision: request approval for the mandatory core and a conditional approval (or separate case) for optional enhancements. This preserves decision quality and focuses debate where value is most sensitive.