Most scenario models are built to answer the question 'what will happen?' They shouldn't be. The future is not knowable in the detail that most financial models imply. A scenario model built to predict is a model that will be wrong in ways that matter. A scenario model built to surface assumptions is a model that is useful regardless of what actually happens.
The difference between a forecast and a scenario model ¶
A forecast tries to estimate the most likely outcome. A scenario model tries to map the range of plausible outcomes and identify the assumptions that determine which scenario you end up in. The distinction matters because it changes what you do with the output. A forecast tells you what to expect. A scenario model tells you what to watch, what to prepare for, and where your plan is most vulnerable.
Starting with the assumptions, not the numbers ¶
The most useful scenario models start by identifying the two or three variables that matter most to the outcome: the ones where a change in assumption produces a large change in result. These are the variables worth modelling carefully. Everything else can be held at a reasonable central estimate. A model that treats every variable as equally uncertain is a model that obscures more than it reveals.
Making assumptions explicit and auditable ¶
Every assumption in a scenario model should be documented: what the assumption is, why it was set at that level, and what evidence or reasoning supports it. This sounds obvious but is rarely done. When assumptions are buried in formulas rather than documented explicitly, the model becomes a black box that no one outside the team that built it can interrogate. An auditable model is a model that can be updated as the situation changes.
Sensitivity analysis: finding the levers that matter ¶
Sensitivity analysis answers the question: if this assumption is wrong by 20%, how much does the outcome change? Running sensitivity analysis across the key variables quickly identifies which assumptions the outcome is most sensitive to. These are the assumptions worth spending time on, either to gather better evidence or to build contingency plans around. The ones the outcome is insensitive to can be set and left.
Building a model your team will actually use ¶
A scenario model that lives in a consultant's proprietary tool and requires the consultant to update it is not a useful model. We build all scenario models in Excel, Python, or R, depending on what the client's team already uses, and we run a working session to walk through the model with the people who will use it. The goal is a model the client owns and can update independently. That's the only kind of model that remains useful after the engagement ends.
If you're preparing a plan that depends on assumptions you haven't fully stress-tested, a scenario modelling engagement is usually the most efficient way to find out where the vulnerabilities are.