Scenario Planning Tools Miss the Only Question That Matters

I once sat through a sales demonstration for a major scenario planning tool. The team showed a room of executives how the platform could model forty-eight supply-chain scenarios in under an hour. Heat maps shifted colour. Sliders adjusted. Numbers cascaded through connected dashboards. The executives looked satisfied, which is the whole point of a demo. When I asked which assumption they would watch after signing the contract, nobody in the room could name one.

I have sat with executives who spent six figures on scenario planning tools and could not show me a single named assumption on a single sheet of paper. The pattern repeats in mining, logistics, pharmaceuticals, government. Each organisation finishes the exercise with polished outputs and the confident sense that the scenario work is done. It is not done. The work has not started.

Roger Estall and I kept seeing the same gap. The tools handled modelling and visualisation well enough. What they never touched was the judgment work underneath: which premise is load-bearing, at what point is it broken, and who acts when it breaks. That gap is not a feature request. It is outside the category the software was built for.

Scenario planning tools are software platforms that model, compare, and visualise alternative futures. They become useful only when they force the team to name the assumptions each scenario rests on and judge which ones must hold before anyone commits to act.

What scenario planning tools are selling

The market sells modelling and visualisation in different packaging. Anaplan connects drivers across functions so teams can adjust scenarios in one workspace. SAP Integrated Business Planning simulates across supply and demand plans and monitors execution against KPIs. Tableau wraps the work in parameter-driven interactivity: sliders, calculated fields, dashboards. @RISK by Lumivero runs ten thousand Monte Carlo iterations and ranks inputs by sensitivity. Each platform is competent within its own category. The problem is that what they do well is the less important half of the work.

Click to expand

Every product creates the impression that the scenario work is finished. An executive team that leaves a workshop with forty-eight modelled futures and zero named assumptions has not reduced uncertainty. It has buried it under licensing fees.

Four questions scenario planning tools cannot answer

I grade these tools against four questions from the Universal Decision-Making Method. They belong to the step of recognising assumptions and ranking them before anyone claims sufficient certainty to proceed.

First: what assumptions hold up this scenario? Every modelled future rests on premises the modeller plugged in. Anaplan lets you adjust drivers; it does not require anyone to state them in plain language. Tableau lets you create sliders; it never asks why those particular variables matter or what would happen if the premise behind one turned out to be wrong. The assumption sits behind the parameter, unnamed and unjudged.

Second: which of those assumptions is load-bearing for this decision? @RISK comes closest with its sensitivity analysis, because the tornado chart at least shows which uncertain inputs dominate the output. A variable can dominate the spreadsheet while the premise that would derail the project sits in a cell nobody tested. The critical-uncertainties matrix shares this weakness: quadrant placement tells you an uncertainty is important without telling you whether it would change the decision.

Third: at what point is an assumption considered broken? SAP IBP monitors plan execution against KPIs after the decision is made. That is useful, but a KPI miss tells you performance moved. It does not tell you which premise failed or what the pre-agreed response should be. I have seen dashboards that reported a plan deviation two quarters after the assumption behind the plan had already failed. The team was watching the wrong signal. Monitoring without named premises is damage assessment, not early warning.

Fourth: who acts when it breaks, and what do they do? No modelling environment answers this. The question requires an organisational commitment, not a software feature: a named person, a pre-agreed threshold, and a documented response. Every board I have worked with could produce a forty-slide deck on scenario outputs. Almost none could show me a single page naming who owns which assumption.

The discipline no software provides

Scenario planning tools are convincing, which is the problem. A Monte Carlo simulation exposes the spread of outcomes faster than any whiteboard exercise; a connected platform shows second-order effects that manual calculation would miss. The danger is that a board sees the output and concludes the scenario work is done. Each tool handles at most two of the four questions, and those two are the less important pair.

This is not a feature gap that the next release will close. The tools are built to model variables, not to surface the judgment calls behind those variables. A vendor profits from adding complexity: more scenarios, more drivers, more connected dashboards. The discipline that matters is reductive. It asks a team to stop modelling and start answering: which of these premises would change our decision, and how confident are we that each one still holds?

The harder half of scenario planning is the plain-language work that happens before anyone opens the software and after the modelling is finished. Before: name the assumptions and rank them by influence and confidence, separating the ones that are both influential and poorly understood. After: write down the threshold that breaks each critical assumption, the person who watches it, and the response that follows.

That is a short list on a single page. It is the piece most organisations skip, partly because it is uncomfortable and partly because nobody charges for it. The useful output is a ten-line assumption register that an executive can read in two minutes and act on the same afternoon.

If the scenario work does not end with a named premise and an owned trigger, the software has produced an expensive audit trail that nobody is allowed to reopen. The examples that actually changed decisions shared one feature: somebody had written down the assumption they were watching and the action they would take when it broke. Roger Estall and I wrote Deciding around that pattern, because we kept meeting boards who had spent on the apparatus and still could not answer the question that matters: what would make us change our minds?

---

Grant Purdy is the co-author, with Roger Estall, of Deciding (2020), and the architect of the Universal Decision-Making Method.