From the CFO Seat: Five Questions to Ask in Your Next FP&A Demo
I’ve been on both sides of these demos.
As a Controller and later as a CFO, I sat through plenty of presentations where everything worked exactly as promised. Like many finance leaders, I believed that choosing the “right” system would remove most of the friction our teams were dealing with.
Later, through years of consulting with Controllers, CFOs, and FP&A leaders across different organizations, I saw how those decisions played out over time. Teams selected tools with good intentions, then had to adapt them as structures changed and reality diverged from the demo.
That experience changed how I evaluate demos. I’m less interested in whether a system works in a clean, controlled scenario. I want to understand what happens after approval, when assumptions change, structures evolve, and the organization no longer behaves the way the demo did.
These are the questions I wish I had asked earlier, and the ones I now encourage finance leaders to ask before committing to a new FP&A, budgeting, or reporting solution.
1. What happens when assumptions change after the model is already in use?
In every organization I’ve worked in or advised, assumptions changed mid-cycle. Headcount plans shifted. Revenue drivers evolved. Priorities changed after the budget was already “final.”
When I ask this in a demo, I listen for how much effort it takes to respond. Are assumptions easy to adjust, or does the answer involve rebuilding logic, duplicating versions, or deferring changes to the next cycle?
Across many organizations, the tools that look strongest in demos often struggle once change becomes constant rather than occasional.
2. Where does flexibility live when something doesn’t fit the model?
No system I’ve implemented or encountered ever matched an organization perfectly. There were always exceptions or scenarios the original design didn’t anticipate.
This question helps clarify whether flexibility is designed into the workflow or handled outside the core process. Finance teams need room to test, adjust, and explain numbers without breaking reporting or creating parallel processes they later have to reconcile.
When a demo implies that everything fits cleanly by design, you should immediately be skeptical. Experience suggests the real work usually ends up happening somewhere else.
3. How much of this depends on predefined templates over time?
Templates are useful starting points. I’ve relied on them myself, and they help teams move faster early on. The challenge appears later. Organizations change faster than templates do.
I ask this to understand what happens when the original structure no longer fits. Can the model evolve without starting over? Can it handle new reporting views, dimensions, or funding models without becoming fragile? If repeated reimplementation or vendor support intervention is required, that may or may not be acceptable, but it should be understood up front.
4. Who can see and change the logic once the system is live?
This became one of my biggest concerns over time, first as a finance leader and later while advising other Controllers and CFOs.
Models outlive implementations, and people move on. When something breaks or needs to change, someone on the team has to understand how the numbers flow.
I now ask who can trace the logic and modify it. If that requires specialized access or ongoing vendor involvement, it creates a dependency that rarely shows up in a demo but matters every month.
5. How does this work when the data is incomplete or still in progress?
Some of the hardest decisions I made as a CFO, and many I’ve seen others make, happened with imperfect information. Late entries, partial actuals, and missing inputs were normal.
This question tests whether a system supports decision-making under those conditions or expects everything to be finalized first. Tools that assume perfect timing often create the most pressure during close, reforecasting, and board preparation.
What These Questions Really Do
Over time, I’ve learned that the value of a demo is not in how completely it removes friction, but in how honestly it shows (1) where friction will still exist, and (2) what capacity the team has to understand and navigate these friction points.
Every FP&A, budgeting, or reporting solution reflects assumptions about how organizations operate. Some assume stability. Some assume standardization. Some assume that once a process is designed, it stays designed. Those assumptions are not inherently wrong, but they are rarely neutral.
Asking these questions makes those assumptions visible early. Not to dismiss a solution, but to understand what it will require of your team as the organization changes.
Looking back, the demos that impressed me most were not always the ones that held up best. The solutions that aged well were the ones whose tradeoffs were clear from the beginning, even if that made the demo feel less polished.
A good demo doesn’t promise that workarounds disappear. It helps you understand which kinds of work will remain, and whether they align with how your finance team actually operates. That clarity, more than any feature list or template library, leads to better decisions and far fewer surprises later.