The variable that most often decides the result is not the one the scenarios varied. Plans typically flex price and volume; outcomes turn on customer retention and the timing of a commercial hire.
What is a scenario, exactly?
A coherent description of a state of the world in which several things move together, with the plan's consequences worked through. Not a number varied up and down.
The distinction sounds pedantic and it is the whole difference between a document that anticipates a future and one that decorates a base case. A plan assuming a commercial hire starts on day one has already decorated, given how long that search actually takes.
The test of whether something is a scenario is whether the variables in it move together for a reason. If the downside case has lower volume and the same pricing, the same churn and the same hiring plan, it is not describing a world — it is describing the base case with one dial turned. Worlds are internally consistent, and building them that way is what makes the consequences worth working through.
How does it differ from sensitivity?
A sensitivity varies one input and holds the world constant. That is useful for understanding a model's mechanics and useless for anticipating what actually happens, because inputs do not move independently.
Most plans labeled scenario planning are sensitivity analysis with three columns and optimistic naming.
Sensitivities still have a job. They tell you which inputs the model is most responsive to, which is useful for knowing where precision matters and where it does not. The error is treating that responsiveness as a ranking of risk: a model can be highly sensitive to an input that never moves and barely sensitive to one that moves constantly.
How many scenarios do you need?
Three at most, and they should differ in what the world is doing rather than in how optimistic the author feels. Base, upside and downside built from the same assumption set are one scenario in three costumes — which is why a session that surfaces objections beats another modeling pass.
More than three and none of them gets thought through properly, which is worse than having one that does.
Three also happens to be the number a board will engage with. Beyond that the discussion becomes an exercise in comparing documents rather than in deciding what to watch for, and the scenarios stop performing their actual function, which is to tell an organization what would have to be true for it to change course.
Who should build the downside?
Someone who is not accountable for the plan. A downside written by the team that owns the upside is bounded by what they can say without undermining their own case, and that is a structural limit.
Outside operators are useful here precisely because they have no position to protect and have usually seen the downside arrive somewhere else.
The downside also has to be specific enough to be recognisable. A generic downside — the market is weaker, everything is harder — cannot be identified when it arrives, so nobody acts on it. One built around named events, such as a key account moving to a competitor or a hire slipping two quarters, gives the team something to watch for and a trigger they can agree in advance.
What happens after close?
The plan should be reviewed against which variable actually moved, not only against whether the numbers were met. That is how a planning process learns, and it is almost never done.
Where it has been done, the recurring finding is that the decisive variable was not among those the scenarios flexed — which is the assumption a planning process tests least.
Reviewing afterward is unpopular for an obvious reason: it names whoever built the plan. Framing it as a review of the method rather than of the people is the only version that gets done, and the useful output is a list of variables to flex next time rather than an account of who was wrong.