Every EPM platform has scenario planning. Few implementations design it for decisions.

Enterprise software has been solving the wrong problem for thirty years. Organisations buy capability, define scope around reporting and compliance requirements, optimise for go-live, and discover six months later that the work that would have changed how decisions get made was never designed in.

Scenario planning in EPM is the current version of that pattern, and the reason most organisations already have everything they need to do this well, and still don’t.

All the leading EPM vendors ship with driver-based planning, what-if analysis, and the ability to run multiple versions of a forecast side by side. The capability is there, often well-built, sometimes genuinely powerful. But the implementation process that determines how organisations actually use it tends to optimise for delivery rather than for decision value.

How scenarios become useless

Six months after an EPM go-live at a mid-market manufacturer, the FP&A director opens the scenario module to support a discussion about whether to hold price or match a competitor’s discount. Three scenarios sit there: optimistic, base, worst case. Revenue at +5%, flat, -5% against plan. None of them model a competitive pricing response. None of them show what happens to margin if the company holds price and absorbs a volume decline in the most exposed product lines. The module is technically complete. The decision gets made in a spreadsheet.

The vendor didn’t ship broken software. The implementation met its requirements. The scenarios were built to specification. Nobody designed them to support that decision.

The problem is that what gets built in most implementations is closer to sensitivity analysis than scenario planning: one variable, flexed up or down, with no narrative attached. FP&A Trends draws this distinction directly: sensitivity analysis tests a single variable at a time, while scenario planning constructs a plausible narrative that moves multiple drivers together. [1] Workday’s own guidance makes the same point, warning against anchoring: scenarios should be “truly distinct” and narrative-based, not minor deviations from the base case. [2]

Nobody in the executive team looks at “base case minus five percent” and thinks: this helps me decide whether to invest in the new product line or double down on our existing market. The scenarios exist in the system. They don’t exist in anyone’s decisions.

Why this keeps happening

Consider what an EPM implementation looks like from inside the delivery team.

There’s a requirements document, a project timeline, and a go-live date. The finance team’s stated needs are faster close, automated allocations, consolidated headcount and revenue in one system. These needs are real, urgent, and almost entirely backward-looking. The scope that gets signed off reflects them. Scenario planning appears as a line item. Three versions get configured. The box gets checked.

The deeper question of “what decisions should these scenarios support?” isn’t in the requirements document. Answering it requires conversations with the executive team about strategy, competitive position, and the choices leadership expects to face over the next twelve to eighteen months. Those conversations have a structural reason for not happening. The finance team owns the requirements process. The strategy lives with the CFO, the board, and the executive team. Getting those two groups in the same room during an implementation, to talk about how the planning architecture should support decisions the company hasn’t made yet, is a different engagement model than most implementations are structured to deliver. The strategic context stays implicit. Everyone assumes someone else captured it. The question of whether it connects to anything that matters gets deferred until six months after go-live, when the answer is obvious and expensive to fix.

Then there’s time pressure. The 2024 FP&A Trends survey found that only 22% of finance teams can run scenarios in real-time or within a day, while 21% are unable to run scenarios at all. [3] For most organisations, the scenario is ready after the decision window has already closed.

The platform goes live. The scenarios are enabled, technically correct, and strategically empty. Nobody designed them to support the decisions leadership faces.

What decision-relevant scenarios actually look like

The scenarios that change decisions are designed around a specific choice, not around a more sophisticated model.

A mechanical scenario says: revenue grows at 8% instead of 12%. That tells you the magnitude of a shortfall, nothing about why it might happen, nothing about what to do. It’s sensitivity thinking applied to planning: one variable, flexed, with no narrative. [1]

A decision-relevant scenario says: our largest competitor drops pricing by 15% over the next two quarters. The CFO and VP of Sales choose to protect margin rather than match. Volume declines by roughly this magnitude in these product lines, which translates to this revenue impact, this effect on capacity utilisation, and this shift in contribution margin by segment. Here’s how the picture changes if the response is a targeted promotion in the most price-sensitive accounts instead, trading some margin protection for volume retention where the exposure is highest.

That version connects to a choice leadership might actually face. It names who decides. It identifies the levers. It creates the conditions for a real conversation about what to do and what to watch for. Some CFOs have started calling this “scenario management” rather than scenario planning, specifically because the output is an action set and a set of triggers, not a document.

Building this is implementation work, not a feature request. It happens in the design phase, before the system goes live, through a conversation that starts with “what are the decisions you need this system to support?” rather than “what reports do you need?” That question is the entry point for strategy-literate planning design. It almost never appears in a standard requirements document.

The gap isn’t where you’d expect

The platforms are capable. The finance teams are capable. The implementation process optimises for a functioning system, and that priority shapes what gets built. Scenario planning becomes “build three versions” instead of “design the decision architecture.” The system ships. The consultants leave. Nobody designed it to work differently.

What this means in practice

The question worth asking early, before scope is locked and before the requirements document is finalised, is: what decisions should this system support that it doesn’t today? Not what reports. Not what dashboards. What actual choices does leadership need to make, and how would better scenario planning change the quality of those choices?

For organisations already past go-live and wondering why scenario planning feels like an unused feature: the issue is probably not the platform. The scenarios were more likely designed around data variations rather than strategic alternatives. That’s fixable, often without a major re-implementation, but it requires someone willing to have the strategic conversation that got skipped the first time.

The next article looks at what that layer requires: the connective tissue between what the platform knows and what leadership needs to decide.

What decision should your scenario model support that it doesn’t today?

---

Robyn Halbot, MBA, BSc, PMI-ACP is Principal at AshPoint Solutions, with fifteen years of EPM implementation experience. She previously co-founded an ML-based forecasting startup and is currently building AI applications that connect financial planning to strategy.

Whether you’re evaluating EPM platforms, rethinking how your current build supports decision-making, or curious about where AI fits in your planning process, I’m always happy to talk through it. Let’s connect.

---

References

[1] FP&A Trends: Sensitivities, Scenarios, What-if Analysis: What’s the Difference?
https://fpa-trends.com/article/sensitivities-scenarios-what-if-analysis-whats-difference

[2] Workday: Scenario Modeling 101
https://blog.workday.com/en-us/scenario-modeling-101-framework-strategic-financial-planning.html

[3] FP&A Trends Survey 2024
https://fpa-trends.com/sites/default/files/docs/FPA-Trends-Survey-2024.pdf