Scenario Planning for Forecasting
Executive Summary
Key Takeaways
- ✓ Scenario planning for forecasting is the process of building coherent base, upside, and downside cases, distinct from the Excel mechanics of implementing a scenario switch, covered on the Scenario Analysis glossary entry.
- ✓ A well-planned case changes multiple related drivers together in a way that reflects one coherent view of the future, rather than moving a single driver in isolation.
- ✓ Case governance means defining, in advance, which assumptions are allowed to vary between cases, the plausible range for each, and who has authority to approve a case's design.
- ✓ Every case should carry a documented rationale stating what was changed, by how much, and on what basis, so a reviewer can assess the case without reverse-engineering it from the model.
- ✓ The output of the planning process, a defined set of case-specific driver values, is what a switch-cell mechanism then operationalises inside the model itself.
Overview¶
Building a base, upside, and downside case is fundamentally a planning and governance exercise, not a technical one. The technical mechanism that operationalises the resulting cases inside a model — a switch cell that selects which set of driver values a formula reads from — is covered on the Scenario Analysis glossary entry, along with the underlying Switch Cell and Toggle Cell mechanics. This guide addresses the process that has to happen upstream of that mechanism: deciding which drivers change between cases, by how much, on what basis, and under what governance, so that what the switch cell ultimately selects between is a set of considered, defensible cases rather than an arbitrary set of numbers.
Defining a Coherent Case¶
A forecast case represents one internally consistent view of the future, not an isolated change to a single number. A downside case that lowers revenue growth while holding every cost assumption unchanged is rarely coherent, because an adverse revenue environment typically accompanies pressure on margins as well — through pricing pressure, higher customer acquisition cost, or reduced operating leverage. A coherent downside case, by contrast, changes the related set of drivers together in a way a reader would recognise as one plausible story about the future.
Building a coherent case typically starts by identifying the driving narrative for the case — what specifically is assumed to be different about the world in this case — and then mapping that narrative onto every driver it would plausibly affect, rather than starting from the drivers and asking which ones are easiest to adjust.
This is the same coherence principle addressed on the Scenario Analysis glossary entry, which distinguishes scenario analysis (a coherent set of assumptions changed together) from sensitivity analysis (a single variable changed in isolation).
Case Governance¶
Case governance is the set of rules, agreed in advance, that determine how a case is built and by whom. At minimum, governance for forecast case planning should address:
Which drivers are permitted to vary between cases. Not every driver in a forecast necessarily needs a case-specific value — a driver with high confidence, such as a contractually fixed cost, may reasonably be held constant across every case, while a driver central to the case's narrative should vary explicitly.
The plausible range for each driver's case-specific value. A downside case should represent an adverse but realistic outcome, not an unbounded worst case, and an upside case should represent an optimistic but plausible outcome, not an unconstrained best case. Defining the plausible range in advance, rather than at the moment a specific case is built, reduces the risk of a case being tuned after the fact to produce a target output.
Who approves the final case design. For a model used in an investment committee or lender submission, case design is typically reviewed and approved by someone other than the model's builder, consistent with the independence expectations applied to model review more broadly.
Documenting Case Rationale¶
Every case should carry a short, written rationale stating three things: what narrative the case represents, which specific drivers were changed from the base case and by how much, and the basis for each change — a stated benchmark, a historical precedent, or an explicit management judgement. A case described only by its label, such as "downside," without this documentation, cannot be assessed by a reviewer without reverse-engineering every driver change directly from the model, which defeats the purpose of presenting named cases at all.
This documentation is distinct from, but complementary to, the assumption-level documentation set out in Assumption Design Best Practices — that guide addresses how an individual driver is labelled and sourced; case rationale documentation addresses why a specific driver was moved to a specific case-adjusted value.
From Planning to Mechanism¶
Once a case's driver values have been defined and documented, they are operationalised in the model using the same switch-cell mechanism addressed on the Scenario Analysis glossary entry: a single control cell selects which set of case-specific driver values each dependent formula reads from. The planning process described on this page determines what values populate each case; the switch-cell mechanism determines how the model selects between them. A model can implement the switch-cell mechanism correctly and still present poorly planned, incoherent, or undocumented cases — the two disciplines are independent, and both are necessary.
Common Errors¶
| Error | Description | Risk |
|---|---|---|
| Single driver changed and labelled a "scenario" | Only one assumption varies; the rest are held at base | Not a coherent scenario, but an isolated sensitivity presented as if it were one |
| Case narrative not mapped onto every plausibly affected driver | A downside case's narrative implies cost pressure, but costs are left unchanged | Case understates its own stated severity |
| No documented basis for the plausible range of a case's driver values | Case built without a stated benchmark or precedent | Reviewer cannot assess whether the case is realistic or arbitrarily tuned |
| Case design approved by the same person who built the model | No independent review of case coherence or plausibility | Case can be unintentionally, or intentionally, tuned to produce a target output |
| Planning and mechanism conflated | Case values are decided at the same time as, and inside, the switch-cell formula itself | No standalone record of the planning rationale exists outside the model's formulas |
Best Practices¶
Treat case planning as a distinct step that precedes building the switch-cell mechanism, with its own documented output: a table of case-specific driver values and the rationale behind each. Define governance — which drivers vary, the plausible range for each, and who approves the final design — before building any specific case, not while building it. Keep the case planning record (the rationale document) alongside the model itself, so a reviewer encountering the model later can assess the cases without needing the original builder present to explain them.
Continue Reading¶
Prerequisites¶
- Financial Forecasting in Financial Models — the parent pillar
Related Glossary¶
- Scenario Analysis — the Excel mechanics of implementing a scenario switch
- Switch Cell
- Toggle Cell
- Forecast Driver
Related Comparisons¶
How OXXON tests thisRun a free structural check with FMAE
Frequently Asked Questions
What is scenario planning for forecasting?
The process of designing a coherent base, upside, and downside case for a forecast — deciding which drivers change between cases, by how much, and why — as distinct from the Excel technique used to implement the resulting cases as a working scenario switch inside the model.
How is this different from the Scenario Analysis glossary entry?
Scenario Analysis, on the glossary, describes the Excel mechanics of implementing a scenario switch — the switch-cell formula pattern, parallel scenario columns, and Excel's native Scenario Manager. This guide describes the upstream planning process that determines what values the switch should actually select between, and the governance around how those values are chosen and documented.
What makes a forecast case coherent rather than arbitrary?
A coherent case changes a related set of drivers together in a way that reflects one internally consistent view of the future — for example, a downside case that lowers both revenue growth and gross margin together, reflecting a plausible adverse market condition, rather than moving only the driver that is easiest to adjust.
What does case governance mean in practice?
Defining, before a case is built, which assumptions are permitted to vary between cases, the plausible range within which each may move, and who is responsible for approving a case's final design, so that case construction is a deliberate, reviewable process rather than an ad hoc adjustment made by whoever is building the model that day.
Why does every case need a documented rationale?
Because a case description limited to a label such as "downside" gives a reviewer no way to assess whether the case is actually adverse enough, or coherent, without independently reverse-engineering every driver change from the model itself, which defeats the purpose of presenting named cases in the first place.
How many forecast cases should a model include?
At minimum a base case; for most institutional purposes, a base case plus at least one downside case is expected, and an upside case is commonly added to define the range of outcomes, following the same case-type conventions set out on the Scenario Analysis glossary entry.
How does scenario planning relate to a rolling forecast?
The two are independent but complementary disciplines — a rolling forecast, described on the Rolling Forecast glossary entry, concerns how frequently the forecast horizon itself is updated, while scenario planning concerns how many coherent alternative views of that forecast are maintained at any given time. A rolling forecast can, and often does, carry its own base and downside cases forward each time it rolls.
Related Articles
Financial Forecasting in Financial Models
Financial forecasting is the process of projecting a business's future financial performance from a defined set of operating drivers and assumptions, structured so that every forecast line traces back to a labelled, auditable input rather than a value typed directly into a calculation. It underpins every model built for valuation, budgeting, financing, or investment decision-making, and it is also one of the areas of a financial model most prone to silent structural failure, since a forecast that looks complete can still rest on drivers that are hardcoded, undocumented, or inconsistently applied from one period to the next. This page is the hub for the Knowledge Centre's forecasting content: what a forecast driver is, the major forecasting methodologies and when each applies, the governance distinction between a budget and a forecast, rolling forecasts, and how forecasting failure modes map onto FMAE's existing structural audit rule taxonomy.
Scenario Analysis
Scenario analysis is the process of recalculating a financial model's outputs under a defined set of alternative assumptions that together represent a coherent possible future state. Each scenario changes multiple assumptions simultaneously to reflect a plausible economic environment or operational outcome — for example, a scenario in which both construction costs are higher than expected and revenue is lower than expected during the ramp-up phase. Scenario analysis is distinct from sensitivity analysis, which changes one variable at a time while holding all others constant. Scenario analysis tests the model under internally consistent combinations of assumptions; sensitivity analysis tests the model's response to changes in individual variables in isolation.
Switch Cell
A switch cell is a dedicated input cell in a financial model whose value controls which set of assumptions, which scenario, or which modelling approach is active in the model at any given time. Formulas throughout the model reference the switch cell and use conditional logic to select the appropriate calculation or assumption based on its value. A switch cell allows the model to operate in multiple modes without requiring the user to manually edit formulas or change individual assumption cells. By changing a single input, the model's entire output changes to reflect the selected mode.
Toggle Cell
A toggle cell is a binary input cell in a financial model that switches a single feature, assumption, or calculation on or off. It accepts one of two values — typically 0 and 1, or True and False — and formulas throughout the model reference the toggle cell to determine whether to include or exclude a specific element. The toggle cell is a specific implementation of the switch cell concept, restricted to two states. Where a switch cell may have three or more states representing different scenarios or modes, a toggle cell has exactly two: active or inactive.
Forecast Driver
A forecast driver is a labelled input cell, most commonly a growth rate, a margin percentage, a unit count, or a price, that a forecast formula references rather than embeds directly. It is the structural unit that makes a forecast auditable and sensitizable, because changing the driver cell changes every downstream calculation that depends on it, consistently and traceably. A forecast driver is structurally distinct from a hardcode, a value typed directly into a calculation cell with no traceable source, even where the two produce an identical output in a given period.
Budget vs Forecast — What's the Difference?
A budget and a forecast are frequently used as if they were interchangeable terms, and treating them that way obscures a governance distinction that matters to how each is actually used. A budget is a fixed, formally approved plan, typically set once per year, used as a performance benchmark against which actual results are measured. A forecast is a forward-looking estimate that is updated frequently as new information arrives, and it is not used as a fixed target. Both are legitimate, complementary tools, and most organizations of any size run both together rather than choosing one over the other.