Scenario Planning Tools Miss the Only Question That Matters

Scenario planning tools model futures, shift sliders, and cascade numbers through connected dashboards. Executives look satisfied, which is the point of a demonstration. None of these tools force the team to name the one assumption that would cancel the investment if it turned out to be wrong.

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.

Tool	What it does	Names assumptions?	Tests thresholds?
Anaplan	Connects drivers across functions for multi-scenario modelling	No	No
SAP IBP	Simulates supply/demand plans, monitors KPIs post-decision	No	Partial (KPI miss, not premise failure)
Tableau	Parameter-driven interactive dashboards and what-if sliders	No	No
@RISK (Lumivero)	Monte Carlo simulation with sensitivity analysis	Partial (ranks inputs by influence)	No

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.

Take the investment your scenario software cannot settle and specify the assumption that would tell you to stop. Start the Walk →

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?

What to do after the scenario exercise ends

I have watched dozens of scenario exercises end the same way. Four futures on a wall. Sticky notes arranged by theme. The room disperses feeling productive. A month later, nobody can point to a single thing the organisation is doing differently. The exercise produced theatre, not discipline.

The missing step is short and uncomfortable. Take each scenario and ask: what would have to be true for this future to unfold? Write each answer as a named assumption in plain language. Not a paragraph. A sentence. "The regulator will approve the new licensing framework before Q3." "Our largest customer will renew at current volume." "Lithium spot prices will stay below $25,000 per tonne." If you cannot state the assumption in one sentence, you have not finished thinking about it.

I once worked with a port authority that had run a creditable scenario exercise around decarbonisation policy. They had four futures, each with a name the facilitator was proud of, each built around different assumptions about regulatory timing and technology adoption. Six months later, I asked the CEO which scenario they were tracking. He said he was not sure, but the board had found the workshop valuable. Valuable. Four futures sitting in a forgotten slide deck, and the capital plan had not changed.

We went back to the scenarios and pulled out three assumptions that actually mattered. One was about the timing of a national emissions standard. One was about the cost trajectory of shore power infrastructure. One was about whether their largest shipping client would mandate green berths. Each assumption was verifiable. Each could break. And each one, if it broke, would change what the port should build next.

That is the bridge from scenario output to operational discipline. The critical uncertainties matrix gets you part of the way by sorting which drivers are both uncertain and influential. But the matrix is a sorting tool, not a commitment. The commitment arrives when someone writes down three things: the assumption, the signal that would tell you it has broken, and the name of the person who will act when that signal fires.

In my experience, the third item is the one that changes the room. People will debate assumptions all afternoon. They will nod at thresholds without discomfort. The moment you ask who owns the trigger and what they will do when it fires, the conversation shifts from intellectual to operational. Suddenly people are not talking about scenarios. They are talking about their own names next to a decision they might get wrong. That is where scenario planning stops being a strategy exercise and starts being monitoring with a purpose.

The output should fit on a single page. Each line carries the assumption, the threshold, the owner, and the pre-agreed response. If the register runs longer than a page, the team has confused detail with discipline. The useful register does not describe every scenario. It names the handful of premises that would change the decision, and it tells the organisation when to change course and who gives the order.

The method Roger Estall and I set out in Deciding runs through this sequence: surface the assumptions, judge whether each one gives you sufficient certainty, and set the monitoring that catches it when it breaks. Scenario exercises are a fine way to surface the raw material. They are not a substitute for the judgment and ownership that follow. Until someone in the room can say what they would do differently and when, the futures on the wall are intellectually satisfying and operationally weightless.

---

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