By Hiran de Silva
The Kevin McMahon Budget Review challenge raises a much bigger question than whether a particular spreadsheet solution is good, bad, modern or old-fashioned.
It raises a question for the CFO.
If a business-critical Excel problem landed on your desk tomorrow, would you know what expertise you actually needed to solve it?
Because I think we may have a problem.
And the Budget Review provides a remarkably good way of seeing it.
Start with the business problem
Forget Excel for a moment.
Imagine the challenge arrives in Finance.
You have hundreds of managers across a business.
They need to review financial information at different levels of the organisation — perhaps Group, Region, Country, City and individual operating unit.
They need to see the appropriate information.
They need to drill down.
They need to enter comments.
They need to update review status.
Those updates need to be visible elsewhere.
The process needs security, auditability and control.
And it needs to work reliably for hundreds of people.
It is urgent.
It is important.
And, viewed from the CFO’s desk, it looks like quite a serious technical undertaking.
So what would you do?
Presumably, you would hire expertise.
And not just ordinary Excel expertise.
You might look for somebody with seriously advanced Excel capabilities.
An Excel expert.
An MVP.
A highly regarded trainer.
Perhaps somebody prominent on social media.
You might consult a spreadsheet competency framework and ask:
What competencies constitute “advanced Excel” for a problem of this scale?
That sounds entirely sensible.
But then we encounter the uncomfortable part.
Look at the solution
If you have seen my Budget Review explainer, you have already seen the solution I am proposing.
And what is striking about it is not its complexity.
It is its simplicity.
There are spreadsheets.
There is a central relational database.
The spreadsheets GET the information they need from that database.
They PUT information back into it.
That is essentially it.
The architecture is hub and spoke.
The database is the hub.
The spreadsheets are the clients.
And suddenly something rather extraordinary happens.
The apparent complexity of the business problem does not require corresponding complexity inside the spreadsheets.
There are remarkably few moving parts.
In architectural terms, almost nothing needs to move at all.
The data moves.
And this solution does not depend upon expertise in the collection of features that we have increasingly come to regard as synonymous with “advanced Excel”.
That should interest a CFO.
Because it raises another question.
What happens if you recruit the wrong kind of expert?
Suppose you advertise for somebody with exceptional modern Excel skills.
You find them.
They are genuinely excellent at what they do.
They know the latest functions.
Power Query.
Dynamic arrays.
LAMBDA.
Perhaps Python in Excel.
Perhaps Office Scripts and the wider Power Platform.
They may be considerably more knowledgeable about these technologies than I am.
But there is a problem.
They may be extremely competent at solving a different class of problem.
If their mental model remains centred upon the workbook, then when confronted with a multi-user enterprise process, they are likely to begin building relationships between workbooks.
And that takes us towards what I illustrate with my Tim, Ted and Todd diagram.
One workbook talks to another.
That workbook feeds another.
Something consolidates something else.
Files acquire dependencies.
Copies appear.
Transformations multiply.
More processes are added to manage the processes already created.
Before long, the organisation has constructed precisely the kind of spreadsheet architecture that CFOs are subsequently told is dangerous.
The problem is not necessarily lack of Excel expertise.
Paradoxically, it can arise from having a great deal of expertise in the wrong architecture.
Are we recruiting for features instead of architecture?
This is where I think the CFO community has a genuine problem.
Because the system is largely set up to produce exactly this result.
Look at the Excel content surrounding us.
Social media.
YouTube.
Training courses.
Webinars.
Conference presentations.
Professional discussion.
Even competency frameworks.
What do we generally mean when we describe somebody as becoming more “advanced” in Excel?
Usually, we mean that they know more things that Excel can do inside the workbook.
That is perfectly useful knowledge.
But it does not necessarily answer the enterprise question.
The question is not:
How sophisticated can we make this workbook?
The question may instead be:
Why are we trying to make the workbook do this job at all?
Perhaps the workbook should simply be the interface.
Perhaps the data belongs somewhere else.
That single change in thinking can transform the architecture.
The recruitment paradox
This creates what I would call the CFO recruitment paradox.
You can write a job specification demanding the highest levels of Excel expertise.
You can recruit somebody who satisfies every box.
You can find somebody with a formidable command of modern Excel.
And you can still end up with the wrong solution.
Not because the person is incompetent.
Quite the opposite.
They may be extraordinarily competent.
But they have been recruited according to a definition of Excel competence that does not test the capability you actually require.
So here is my question to CFOs:
What box do you tick?
If you want somebody capable of recognising that the Budget Review should be implemented as a simple client-server process rather than an elaborate network of workbooks, what competency are you actually recruiting for?
What is it called?
Where is it taught?
Where is it tested?
Where does it appear in the job description?
That, to me, is the interesting question.
What does “the future of Excel” mean?
There is another influence worth considering.
Much of the public discussion about the future of Excel naturally concentrates on new technologies.
Power Query will become more important.
Python will become more important.
AI will become more important.
New functions will become more powerful.
That may all be perfectly true.
But notice what happens if we allow that conversation to define professional competence.
We progressively push Excel expertise further and further inside the workbook.
And for some enterprise problems, the correct direction may be exactly the opposite.
Get the data out of the workbooks.
Centralise it.
Govern it.
Let spreadsheets retrieve what their users need.
Let authorised users write appropriate information back.
In other words:
Stop making every spreadsheet an island.
“A database is not Excel”
I have also encountered the argument that a database is somehow outside the legitimate territory of Excel — or that databases are not realistically available to the so-called citizen developer.
From a CFO’s perspective, I think that deserves examination.
Because this isn’t some exotic new interpretation of Excel that I have invented.
Microsoft was demonstrating Excel communicating with backend systems decades ago.
In the December 1993 DevCast presentation that I have discussed elsewhere, a young Satya Nadella demonstrated Excel communicating with an AS/400 backend.
That matters historically.
Because if separating the spreadsheet interface from centrally managed data were somehow contrary to the intended use of Excel, why was Microsoft demonstrating precisely that architecture more than thirty years ago?
The more interesting question may therefore be:
How did we forget?
Now look at the Excel replacement industry
Here is where the story becomes even more interesting for the CFO.
Look at almost every enterprise platform offered as an antidote to spreadsheet chaos.
Planning systems.
FP&A platforms.
ERP systems.
Cloud applications.
Excel replacement products.
What architecture do they use?
Broadly speaking, they centralise the data and provide controlled interfaces through which users interact with it.
In other words:
Hub and spoke.
Client and server.
Central data.
Distributed users.
And what problem are many of these products marketed against?
The spreadsheet mess.
The point-to-point nightmare.
The collection of files flying around the organisation.
Broken links.
Version confusion.
Consolidation headaches.
No single source of truth.
Poor governance.
Precisely the mess represented by my Tim, Ted and Todd diagram.
And I don’t dispute the problem.
Quite the opposite.
I agree with the diagnosis.
What I question is the sleight of hand that can occur between the diagnosis and the prescription.
Because demonstrating that a badly designed spreadsheet process is bad does not logically demonstrate that Excel itself must be replaced.
It demonstrates that the process is badly designed.
The diagram tells you the answer
Put the two architectures next to one another.
On the left:
A point-to-point network of spreadsheets, dependencies, links, transformations and consolidation processes.
On the right:
A central data hub surrounded by simple spreadsheet interfaces.
Which would the CFO prefer?
I suspect the answer is obvious.
Order.
Control.
Auditability.
Simplicity.
Explainability.
Scalability.
The extraordinary thing is that the architecture on the right is usually presented as the reason to leave Excel.
Yet Excel has been capable of participating in precisely that architecture for decades.
That is the missing piece of information.
And once you know it, the entire conversation changes.
The toothpaste problem
There is a basic principle in marketing.
First, show people something they don’t want.
Fear.
Pain.
Chaos.
Risk.
Then place your product next to the solution.
The human mind is remarkably good at completing the connection for itself.
You don’t necessarily have to prove that Product B solves Problem A.
You merely have to put them close enough together.
At an absurd extreme, I could show you a frightening diagram of broken spreadsheet links…
…and then show you a tube of Colgate Advanced White.
If the presentation were slick enough, perhaps somebody would eventually associate whiter teeth with better spreadsheet governance.
Obviously that is ridiculous.
But the logical point matters.
The existence of a genuine problem does not validate the product being sold as its solution.
Spreadsheet chaos is real.
Bad Excel practice is real.
Poorly controlled spreadsheet processes are real.
None of those facts proves that Excel needs replacing.
They may simply prove that Excel is being used with the wrong architecture.
Why this matters to the CFO
This brings me back to the Budget Review.
What can a CFO learn from it?
I think there are two important lessons.
The first is that the obvious conventional avenues available to you may not solve this particular class of urgent problem.
A major replacement platform may be too expensive, too slow to procure and implement, or wildly disproportionate to the immediate requirement.
The ERP route may involve projects, approvals, development cycles and IT resources that simply aren’t available within the required timescale.
But hiring somebody whose expertise is entirely based upon modern workbook features may merely create a more sophisticated version of the architecture that caused the problem.
And yet the solution you have just seen is comparatively simple.
Excel at the front.
A relational database behind it.
GET.
PUT.
Security.
Audit.
Central control.
That is not science fiction.
It is not a theoretical future for Excel.
It is an architecture that has been available for decades.
So why isn’t everybody teaching it?
That, perhaps, is the biggest question of all.
If this capability can transform a difficult multi-user spreadsheet process into something dramatically simpler…
If it can reduce the number of moving parts…
If it can centralise data…
If it can improve control…
If it can preserve the flexibility and familiarity of Excel…
…why is it almost absent from mainstream Excel education?
Why isn’t it prominent in the definition of advanced Excel?
Why isn’t it routinely discussed in CFO communities?
Why doesn’t a finance leader confronted with the Budget Review problem immediately know that this is one of the architectural choices available?
I don’t think CFOs should simply accept that situation.
Because the consequence is bigger than spreadsheets.
It affects cost.
Risk.
Productivity.
Technology decisions.
Recruitment.
Transformation programmes.
And ultimately the standing of Finance within the organisation.
A question for the CFO community
So I am not going to finish this article by telling CFOs which new Excel feature they should learn.
I think there is a much more important question.
Imagine the Budget Review challenge landed on your desk tomorrow.
You have seen the point-to-point solution.
You have seen the hub-and-spoke solution.
You know which architecture you want.
You know that the technically simpler solution can be implemented with Excel.
Now write the job specification.
Who do you hire?
What expertise do you ask for?
What qualification demonstrates it?
What box do you tick?
And perhaps most importantly:
If the solution is this simple, this powerful and has been technically possible for decades, why did nobody tell the CFO?
That is the question behind Excel for the CFO.
And I think it is a question the CFO community deserves an answer to.
Add comment