A podcast by Hiran de Silva. Read by Bill
Whenever a spreadsheet disaster makes headlines, it’s often attributed to “human error.” We’ve all heard this narrative–someone made a mistake, overwrote a formula, or sorted data improperly. It’s not Excel’s fault, people say; it’s human error. But I believe there’s a deeper, more fundamental type of human error that is rarely discussed, yet it’s far more consequential. Let’s call it **Excel Human Error of the Second Kind**–the kind of mistake that occurs before any formulas are typed or cells are formatted. This error happens at the very foundation of how a spreadsheet is architected and how its purpose is defined.
Human Error in Spreadsheet Foundations.
What’s usually meant by “human error” is the sort of thing anyone who’s worked with spreadsheets has seen before–small, individual mistakes made by users. Perhaps someone overwrites a formula with a value, or sorts a list without realizing that a hidden column exists, corrupting the entire dataset. These are basic, day-to-day mistakes, often caused by a lack of attention or experience. Yes, these are human errors, and they can lead to costly consequences, but there’s another, more critical type of human error that we should be talking about.
I’m referring to the **human error in designing the very foundation of the spreadsheet.** This isn’t about clicking the wrong cell or using the wrong formula–it’s about deciding how a spreadsheet will function and whether it will serve as a one-off tool for a single user or as part of a larger data process that spans across an entire organization.
This distinction is rarely made, but it’s crucial. Failing to recognize the scale of the process a spreadsheet is supposed to support is, in my view, the most serious human error of all.
Popular Excel vs. Professional Excel: The Wrong Techniques for the Wrong Context.
In a previous blog, I explored the difference between **Popular Excel** and **Professional Excel**. Popular Excel techniques are what you’ll find in countless tutorials and social media posts–strategies designed for single-user tasks, small businesses, or simple data manipulation. These techniques work just fine for an individual user on a single machine with a specific task. However, the problem arises when these same techniques are applied in an enterprise context, where processes need to be scalable, repeatable, and robust enough to support multiple users across different departments.
Using Popular Excel techniques in an enterprise context is like building a house with the foundation of a wooden shed. Sure, that shed works for a small, isolated purpose. But try to build something larger–like a corporate reporting system or a financial forecasting tool–on that same foundation, and it will crumble under the weight of complexity and interconnectedness.
The Foundation Analogy: From Elvis’s Wooden Shack to the Shard.
To illustrate this point, consider a simple analogy. Here’s a picture of a small wooden house–humble, with a minimal foundation. This was the house where Elvis Presley grew up. It was perfectly fine for a small family in the 1930s. But as Presley’s fame grew, so did his lifestyle, and eventually, he moved to Graceland–a far larger, more elaborate mansion. The foundation of Graceland was much stronger than that of his childhood home.
Now imagine building something even more ambitious–like the Shard in London, the tallest building in the UK. The foundation for that structure must be deeper, stronger, and carefully engineered to support its towering height and complexity.
Spreadsheets, like buildings, require different foundations depending on their purpose. A simple spreadsheet for a one-man business doesn’t need much in terms of architecture. But when that same logic is applied to enterprise-level processes–month-end reporting, financial consolidation, or supply chain management–it’s a recipe for disaster. The bigger mistake here is not overwriting a cell or sorting incorrectly–it’s choosing the wrong foundation to begin with.
Where Are the Guidelines for This Type of Error?
I recently reviewed the Twenty Principles of Good Spreadsheet Practice from the Institute of Chartered Accountants in England and Wales (ICAEW), a respected guideline in the field. While it addresses many important points about spreadsheet design, there’s little to no discussion about the **scale of the spreadsheet’s purpose**. Shouldn’t there be a distinction between a spreadsheet that supports a small, individual project versus one that is integral to a large enterprise’s operations?
Similarly, the **Spreadsheet Competency Framework** released in 2016 outlines competencies from beginner to developer. Yet, at no point does it address the crucial decision of **scalability**–whether this spreadsheet will be used for a single task by one person or will form part of a much larger, more complex system. The absence of this consideration in widely accepted guidelines contributes to the perpetuation of the Excel Human Error of the 2nd Kind.
There is also the Spreadsheet Review Guidelines from the ICAEW. Should we not review the very foundation on which the spreadsheet is created? Is it the right architecture for the task? Often these considerations are left at the mercy of the competency level, that is ‘limitations’, of the user.
Author’s Edit: I wrote contributions to each of these publications at the time, but then realised that one would need a conceptual understanding of Enterprise Level spreadsheet architecture to understand the points I made. Years later, I’m addressing this now in this blog series.
Conclusion: Human Error of a Different Kind.
Whenever a spreadsheet error is exposed, the knee-jerk reaction is to blame human error–someone made a mistake, someone wasn’t careful. But this explanation only scratches the surface. The bigger, more impactful human error lies in choosing the wrong architecture for the spreadsheet in the first place. And this error is often a result of applying Popular Excel techniques in contexts where **Professional Excel** is required.
If we want to reduce spreadsheet disasters, we need to look beyond individual mistakes and start asking the more foundational question: What kind of structure are we building? Is this spreadsheet a wooden shack for a small task, or is it the foundation for an enterprise system that will support the weight of a large, complex organization? The answer to that question can make all the difference.
You’ve been listening to a podcast by Hiran de Silva. Read by Bill.
Add comment