Sensitivity Analysis

Risk technique · See it on the map

Guide only — A tornado-diagram calculator could serve this.

Changing one uncertain input at a time to see which ones actually move the outcome.

When to use it

When the risk register or cost model has more uncertain inputs than you have time or budget to manage carefully, and you need to know where the limited attention should go — usually before committing to a detailed response plan for every item.

When to avoid it

When the inputs interact strongly (varying one only makes sense in combination with another) — sensitivity analysis holds everything else fixed, which can mislead when the real risk is in how two or three factors move together. That's the case for a full simulation, not this technique.

Steps

1. List the uncertain inputs feeding the outcome you care about (cost, schedule, or another project objective).
2. For each input in turn, vary it across its plausible range while holding every other input at its baseline value.
3. Record how much the outcome moves for each input's swing.
4. Rank the inputs by how much outcome movement they cause — this is usually displayed as a tornado diagram, widest bar at top.
5. Direct further analysis, monitoring, and response planning at the handful of inputs at the top of that ranking, not evenly across all of them.

What it produces

• A ranked list of which uncertain inputs most affect the outcome — usually presented as a tornado diagram.
• A justified basis for concentrating monitoring and response effort on a small subset of the risks or estimates in play.

Common pitfalls

• Treating the register's sheer size or the loudest risk as a proxy for which risks matter most, when a proper sensitivity pass usually shows the set that actually moves the outcome is much smaller than the register suggests — and isn't always the same set as the highest-exposure entries.
• Varying inputs one at a time and stopping there, when the biggest real exposure sometimes only appears when two inputs move together — the case this technique deliberately doesn't cover.
• Doing the analysis once early in the project and never repeating it as estimates firm up and the ranking shifts.

Worked example

A software rewrite has nine uncertain cost inputs. Varying each alone shows that swings in 'third-party licensing renewal cost' and 'senior engineer availability' each move the total project cost by more than 15%, while the other seven inputs — including the one the team spent the most meeting time debating — each move it by under 3%. The PM redirects the risk owner's attention to the two inputs that matter and stops tracking weekly updates on the rest.

Source

• PMBOK-6 §11.4.2.5

Where it comes from: this technique is named by the PMBOK Guide, 6th edition.