Scenario Analysis for Two Competing Options

Choose the uncertain drivers

Select two or three variables that materially change the outcome, such as demand, time available, cost, or implementation delay. More variables can make the scenarios impossible to interpret.

Choose the two or three uncertain drivers that could actually change the decision, such as demand, useful life, cost, or timing. Give each a plausible range and evidence note. Leave minor variables at a shared baseline. Changing everything at once creates dramatic stories but makes it impossible to learn which assumption controls the result.

Build coherent conditions

A downside scenario is not every bad thing happening at once. Combine values that can plausibly occur together and explain why.

Build each scenario as a connected set of conditions. A downside case should not punish only one option or combine values that could not occur together. Explain why the inputs belong in the same case. Use neutral names such as constrained, expected, and favorable when labels like disaster or best case would add emotion rather than information.

Use one scorecard

Evaluate both options using the same criteria and time horizon in every scenario. Keep the assumptions visible beside the result.

Evaluate both options with the same criteria, units, and time horizon in every scenario. Keep hard constraints visible before scores. This allows the reader to see whether an option remains workable, not merely which total is larger. If a criterion changes meaning across scenarios, define the change instead of silently altering the scale.

Look for robustness and triggers

A robust option remains acceptable across scenarios. If the preferred option changes, identify an observable trigger that tells you when to adapt.

Look for an option that stays acceptable, then identify the input that causes the leader to switch. Turn that input into a monitoring trigger with an owner and response. A scenario analysis is most useful when it changes the plan: commit, stage the decision, keep a reserve, or switch when a named condition becomes observable.

Build a scenario table that exposes the switch

Place scenarios in rows and the same decision criteria in columns. Add the key input values at the top of each row so the reader can see why the result changes. Do not hide the assumptions in a note after the recommendation.

If one option wins in every scenario, inspect whether the scenarios are genuinely distinct and whether a neglected tail risk matters. If the winner changes, focus research on the switching input and design a response that can be triggered when that input becomes observable.

Do not average scenario scores unless you have defensible probabilities and a reason an average fits the decision. A scenario table is often more useful as a robustness test: it shows which option remains acceptable and which conditions require a different action. Preserve that information instead of compressing it too early.