The same inputs, two different questions
Both approaches change inputs and observe outcomes. That surface similarity is exactly why they get conflated. But they are built differently, they answer different questions, and they serve different audiences.
Used in the wrong context, the analysis can look rigorous while telling you something other than what you think. In practice, the confusion sounds like this:
- “Let’s run a sensitivity on the downside market.” That is a scenario. You are describing a set of market conditions, not isolating a variable.
- “Let’s scenario-test the impact of a cost blow-out.” That is a sensitivity. You are moving one input and measuring the effect.
- “We have base, upside, and downside, but we only changed the sale price.” That is a sensitivity analysis with three labels. It is not three scenarios.
The clean separation:
| |
Sensitivity Analysis |
Scenario Analysis |
| Variables moved |
One at a time |
Multiple, simultaneously |
| Everything else |
Held constant |
Adjusted to reflect a coherent market view |
| Primary output |
Ranked risk drivers |
Project performance under a plausible future state |
| Best used for |
Diagnosing exposure, prioritising assumptions |
Stress-testing resilience, communicating range |
| Primary audience |
Internal: analysts, modellers, project leads |
Boards, financiers, investment committees, JV partners |
That last row is the one most teams overlook, and it is the one that matters most. A sensitivity is a diagnostic instrument for the people building the model. A scenario is a communication instrument for the people making the call. Confuse them and you hand a board a diagnostic, or hand a modeller a narrative, and neither can act on what they have been given.
Sensitivity analysis: which lever actually moves the outcome
Sensitivity analysis is diagnostic. You move one input at a time, hold everything else constant, and measure the impact on a headline return metric, typically project IRR, NPV, or equity multiple. In a staged residential development, the inputs worth testing usually include sale price and price growth, absorption rate, construction cost escalation, the construction-to-settlement lag, finance costs, and stage timing.
The output is a ranked view of which inputs carry the most risk. That gives the team a clear basis for where to stress assumptions, where to hold contingency, and what to monitor as the project moves through each stage.
Worked example: a master-planned community across six stages over eight years. Each input is shifted by ±10%, independently, with all others held constant.
| Input Tested |
IRR Impact (±10% shift) |
Implication |
| Sale price |
± 4.1% |
Dominant driver, the single largest source of return exposure |
| Absorption rate |
± 2.7% |
Material, as slower sales compound holding costs across a long program |
| Construction cost escalation |
± 2.2% |
Significant over an eight-year build, where small annual rates compound |
| Construction-to-settlement lag |
± 1.4% |
Frequently underestimated, since cash timing affects returns directly |
| Finance cost |
± 0.8% |
Real, but secondary to the operational drivers above |
| Stage end-date timing |
± 0.5% |
Low in isolation, but compounds across multiple stages |
Sale price and absorption rate dominate. These two should anchor any scenario built for this project. And critically, rankings shift from one project to the next, which is precisely why sensitivity should be run, not assumed.
Scenario analysis: does the project hold up when conditions move together
A scenario is not a number adjustment. It is a structured, plausible view of market conditions in which every input is consistent with that view. When you define a scenario, you are asserting that here is a set of conditions that could reasonably occur together, and this is how the project performs under that reality.
Real markets do not soften through price alone. A genuine downside means softer prices, slower sales, and elevated cost pressure, not one of those in isolation. So a well-built scenario moves multiple inputs at once, in a logically coherent way.
One control matters more than any single input: the scenario start date, the point from which the forecast diverges from actuals. Completed work and locked stages are not overwritten. Only the forward view is tested. Anchor your scenarios to the actuals-versus-forecast boundary and the analysis reflects genuine project progress, rather than a theoretical reset from day one.
Worked example: the same project. Three market conditions applied simultaneously from the scenario start date forward. Actuals are locked, and only the forecast period is stress-tested.
| Input |
Base Case |
Upside |
Downside |
| Sale price growth (p.a.) |
3% |
5% |
0% |
| Absorption rate |
8 lots / month |
12 lots / month |
5 lots / month |
| Construction cost escalation (p.a.) |
4% |
3% |
6.5% |
| Construction-to-settlement lag |
3 months |
2 months |
5 months |
| Finance rate |
6.5% |
6.0% |
7.5% |
| Project IRR |
17.5% |
24.2% |
10.9% |
| Equity Multiple |
2.1x |
2.8x |
1.6x |
Against a 10% IRR hurdle, the project clears in all three states, including the downside. But notice that the downside clears with limited headroom: 10.9% against a 10% hurdle. That margin is the insight. A sensitivity would have told you sale price is your biggest single risk. Only the scenario tells you that when your two dominant drivers move adversely together, the project survives but its cushion is thin. That is exactly the kind of forward-looking judgement a board submission or financier briefing exists to inform. The range is defensible, the assumptions are transparent, and the message is one a decision-maker can actually act on.
Why this gets harder, and more valuable, at scale
Most teams first meet both techniques in Excel. It does the job, up to a point. The limitations surface when projects scale, teams grow, and outputs need to be consistent, auditable, and presentation-ready without a rework cycle before every meeting.
A modern EPM platform changes what the capability can do:
- One model, one version of the truth. Every user works from the same logic, inputs, and outputs. Update a scenario and everyone sees it, with no version reconciliation the night before a presentation.
- Scenarios toggled instantly, sensitivities that run themselves. Scenarios are defined once and switched with a single action. Sensitivity rankings recalculate across all nominated inputs in real time, with no manual reruns.
- Real-time recalculation across the whole project. A change in one input flows through every stage, period, and interdependency immediately.
- Board-ready outputs by default. Comparison tables, rankings, and return metrics are available at any point, consistently formatted, without rebuilding before each use.
- A traceable audit trail. Scenarios are saved and version-controlled. When decisions are documented at board or transaction level, traceability is a requirement, not a nice-to-have.
But the platform does not resolve the confusion on its own. Without a shared understanding of when to use a sensitivity, when to use a scenario, and why the difference matters, even the most capable tool produces confusion faster.
