By Hiran de Silva
One of the great strengths of civilisation has been our relentless pursuit of improvement.
Everything around us today exists because someone looked at the world and thought:
“There has to be a better way.”
Fire was improved.
Stone tools were improved.
The wheel was improved.
Ships were improved.
Medicine was improved.
Computers were improved.
The entire history of human progress is one continuous process of observing limitations, understanding why they exist, and then finding better ways of doing things.
The important point is this:
Real improvement does not begin with a solution. It begins with understanding the problem.
That sounds obvious.
Yet surprisingly, it is one of the most commonly ignored principles in modern business.
The Four Ingredients of Improvement
The more I think about it, the more I believe every genuine improvement follows roughly the same pattern.
First, somebody observes that something is unsatisfactory.
Without recognising a limitation, nothing changes. We simply accept the current situation as normal.
Second, we understand why the limitation exists.
Not merely what we dislike about it.
Not merely what symptoms we observe.
We understand the underlying cause.
Third, we identify measurable value that would be created if that cause were removed.
Improvement is not simply change. Improvement must create value.
Finally, somebody has sufficient motivation to make the improvement happen.
People rarely invest significant time, money and effort unless there is an identifiable return.
There is perhaps a fifth ingredient too.
Every significant improvement creates winners and losers.
Those who benefit from the existing situation will almost always defend the status quo.
History is full of examples.
Imagine proposing the Panama Canal.
Ports around the southern tip of South America would inevitably lose shipping traffic.
Naturally they would resist.
The same happened with the Suez Canal.
Every major technological shift creates opposition from those whose interests are threatened.
That is simply human nature.
The Flintstones and the Square Wheel
One of my favourite ways of illustrating this is with the Flintstones.
Imagine Barney builds the world’s first car.
It has square wheels.
Nobody questions it.
After all, nobody has ever seen anything different.
People begin discussing ways to improve the ride.
Better suspension.
Better seats.
Better shock absorbers.
Better steering.
More comfortable cushions.
Everyone is trying to solve the symptoms.
Then Fred quietly asks a different question.
“What if the wheels weren’t square?”
Suddenly every previous discussion becomes irrelevant.
The problem wasn’t the suspension.
It wasn’t the seats.
It wasn’t the steering.
The problem was far more fundamental.
Until someone asked why the vehicle behaved the way it did, genuine improvement was impossible.
That same principle applies to business systems.
Applying This Thinking to Excel
Every week we see articles about Excel Hell.
Spreadsheet chaos.
Version control.
Broken budgeting.
Emailing workbooks.
“Final.xlsx”
“Final Final.xlsx”
“Final Final Version 3.xlsx”
Most business professionals smile because they recognise the situation immediately.
Yes.
Those things happen.
Yes.
They are frustrating.
Yes.
They are expensive.
So far, we all agree.
But then I ask a question that almost nobody asks.
Why?
Why do these problems exist?
What actually causes them?
Unless we answer that question, how can we possibly claim to have found the solution?
Describing Symptoms Is Not Explaining Causes
This is where many Excel replacement campaigns become fascinating.
Take the famous Nine Circles of Spreadsheet Hell.
It identifies numerous problems that many organisations experience.
To be fair, those observations are largely accurate.
The symptoms are real.
The frustration is real.
The inefficiency is real.
But something remarkable happens.
The paper rarely stops to ask why those problems exist in the first place.
Instead, it jumps almost immediately towards the conclusion that the answer is replacing spreadsheets.
That is a very large leap.
It is rather like diagnosing a fever and immediately prescribing surgery without first understanding the infection.
One Sentence That Reveals Everything
The opening paragraph makes an extremely important statement.
It says that FP&A belongs in the cloud, not in spreadsheets.
That sentence deserves much more attention than it usually receives.
Because hidden inside it is an architectural distinction.
Without explicitly saying so, it contrasts two completely different ways of organising business processes.
The first is document-based architecture.
The second is client-server architecture.
Once you recognise that distinction, almost every so-called spreadsheet problem suddenly makes sense.
The Real Problem Is Document-Based Architecture
For most of the twentieth century, businesses operated using paper.
Documents moved around organisations in brown internal mail envelopes.
Departments completed forms.
Those forms were physically transported to the next department.
People waited.
Somebody copied information into another document.
Someone else filed it.
That was perfectly reasonable for its time.
Then computers arrived.
But something interesting happened.
Many organisations simply digitised exactly the same workflow.
Instead of moving paper documents…
…they moved email attachments.
The architecture hardly changed at all.
The paper became Excel files.
The internal mail became Outlook.
The filing cabinet became SharePoint.
But fundamentally, the organisation was still passing documents from person to person.
Version control problems.
Duplicate files.
Manual consolidation.
Broken links.
Conflicting edits.
These are not inherent spreadsheet problems.
They are the natural consequences of document-based architecture.
Once you understand that, everything changes.
Microsoft Solved This Thirty Years Ago
What makes this discussion particularly interesting is that Microsoft recognised this problem decades ago.
In December 1993, Microsoft demonstrated Excel working directly against enterprise databases during one of its DevCast presentations.
The presenter was a young Microsoft engineer called Satya Nadella.
The demonstration showed Excel retrieving live information directly from enterprise systems.
This was not theoretical.
It worked.
A few years later, Office 97 introduced ActiveX Data Objects (ADO), dramatically simplifying client-server development.
Access was bundled with many editions of Microsoft Office.
SQL Server rapidly became accessible.
Bill Gates spoke extensively about what he called the Digital Nervous System.
His vision was simple.
Business events should trigger business responses automatically.
Not because documents were emailed around the organisation.
Because shared data drove shared processes.
This represented an enormous shift in thinking.
The spreadsheet was no longer the database.
The spreadsheet became an intelligent interface.
The data lived centrally.
Many spreadsheets could read and update that shared information simultaneously.
Exactly the client-server model that modern cloud systems still use today.
So Why Does Spreadsheet Hell Still Exist?
This is the obvious question.
If Microsoft solved the architectural problem thirty years ago…
Why are organisations still experiencing spreadsheet hell?
The answer, I believe, is surprisingly simple.
Many organisations never adopted the architectural change.
They continued using spreadsheets exactly as electronic documents.
Meanwhile, software vendors quite understandably built products that solved those document-based problems.
There is nothing wrong with that.
The problems genuinely exist.
But the important question becomes this.
Were they solving spreadsheet problems…
…or document architecture problems?
Those are not the same thing.
The Question I Always Ask
Whenever I read another article explaining why spreadsheets should be replaced, I ask a very simple question.
Why?
Why does this problem exist?
What exactly is causing it?
If the answer turns out to be document-based architecture, then replacing Excel is only one possible solution.
Another solution is to remove the document-based architecture altogether while continuing to use Excel as the front end.
That is precisely what I have spent much of my consulting career demonstrating.
Separate the data from the spreadsheet.
Store the data centrally.
Allow every spreadsheet to retrieve and update shared information.
Suddenly the familiar symptoms begin disappearing.
No endless versions.
No manual consolidation.
No emailing files backwards and forwards.
No disconnected copies.
Exactly the same architectural principles used by modern cloud platforms.
Only implemented using technology that Microsoft has provided for decades.
A Better Question
Perhaps the biggest lesson from all of this extends far beyond Excel.
It applies to every technology discussion.
Whenever somebody proposes an improvement…
Whenever somebody claims to have solved a major business problem…
Whenever somebody explains why an existing technology is broken…
Don’t immediately ask what their solution is.
Ask something much more fundamental.
Why does the problem exist in the first place?
Because until we understand why something behaves the way it does, we cannot know whether the proposed solution addresses the real cause—or merely the symptoms.
That principle has guided civilisation for thousands of years.
It guided the invention of the wheel.
It guided the construction of the Suez and Panama Canals.
It guided the development of modern computing.
And it should guide the way we think about spreadsheets.
Only when we understand why something is broken can we begin to improve it.
Add comment