Why finance teams should never give up spreadsheets, whatever vendors tell them
- Spreadsheets have massive flaws if they're used in the wrong way, but finance professionals shouldn't feel ashamed of keeping them in their toolbox.
Spreadsheets have taken some hard knocks in the nine or so years that diginomica has been writing about enterprise technology. Hardly a week goes by without some vendor or other decrying the fragility of spreadsheet-based processes and proclaiming the superior merits of their own HR, FP&A or data transformation offering. The pejorative term 'spreadsheet hell' crops up in no less than seven separate headlines over those years — one of them mine. But I've since come round to the view that the humble spreadsheet still has a role to play and shouldn't be erased from anybody's digital toolbox, despite its evident shortcomings.
Those shortcomings have been amply documented by Den Howlett, diginomica's now retired co-founder, who first took a dislike to the spreadsheet in the early 1990s. As he recalled back in 2015:
I first became interested in the topic around 1991-2 when I was preparing cashflow forecasts for funding operations. At the time, there were no tools available other than the spreadsheet and it used to drive me nuts that I'd have to fiddle about with templates that then had to be checked and rechecked for integrity. There were no linking mechanisms back to financial statements so there was always a risk that errors would creep in. So when I came across my first budgeting, planning and forecasting tool it was like arriving in heaven. I successfully dumped the spreadsheet — mostly — in favor of a tool that was built for the purpose and became much more efficient and confident in the information I was producing.
In another article he cites several of the more egregious spreadsheet errors that have been reported over the years, including a miscalculation at Goldman Sachs that cost Tibco shareholders $100 million during the software company's buyout by private equity firm Vista Equity Partners. Yes, spreadsheet errors can be costly. No business should be using spreadsheets for routine, mission-critical calculations, transaction tracking, data transformation or analysis. There are far better software tools that can do all that faster and with better error checking, validation and audit trails.
Why people like spreadsheets
But where the spreadsheet excels — if you'll pardon the pun — is as an ad-hoc tool for quickly setting up and trying out new datasets, calculations and analysis. There's a tipping point where a spreadsheet becomes too complex, too disconnected or too mission-critical to be fit for purpose, at which point it's absolutely right to shift that process to a more robust, flexible and auditable software platform. But at a time when everyone is talking up the benefits of low- and no-code tooling, why are people so keen to rule out using the original low-code platform? As Dan Bricklin, co-author of VisiCalc, the very first microcomputer spreadsheet program, once wrote about why people prefer working in spreadsheets rather than writing code:
One of the good properties of a spreadsheet (leading to its wide acceptance) is that you usually set things up so that you can see the intermediate results of calculations. Rather than have one long formula in a cell, you use several cells, each with simpler formulas referring to some other cells. This makes testing and debugging much easier ...
In addition to letting you see intermediate results, the recalculation ability of a spreadsheet, giving instant feedback, helped lead to Don Norman's conclusion that with a spreadsheet '...it felt as if you were working directly on the problem, not on a computer.'
This is why people are still drawn to the spreadsheet. It's a simple grid of numbers and formulae that they can move around to their heart's content and see exactly what they're doing at every step. The ease with which those steps can be accessed and altered is as much the spreadsheet's strength as its Achilles heel. Those flaws make it deeply unsuitable for use in production, particularly at scale or by users who lack intimate familiarity with how it's constructed. But as a prototyping tool to quickly build and try out a new dataset or calculation, the transparency and easy modification makes it far quicker and simpler to use than any application or no-code tool that hides those workings away. Learning the quirks and indirections of a new tool puts up a barrier to getting a quick result and always runs the risk of getting stuck halfway through when you realize the tool can't do exactly what you had in mind.
Prototyping, not production
Many tools, of course, use the spreadsheet as an alternative interface precisely because so many people are already familiar with its transparent structure, from Airtable task management to the very FP&A tools whose purported mission is to displace spreadsheets. Here's tech legend Adam Bosworth writing about why he chose the spreadsheet as the interface for the Amazon Honeycode app builder he created, echoing the same strengths outlined by Bricklin:
The vision behind Honeycode is to enable mere mortals to take what they already knew and use to manage their data, namely spreadsheets, and enable these same customers to build easily and interactively, and without code, the applications and business logic they need to get their jobs done. This required deep innovations in data (adding the power of the relational model to the data and expressions in the spreadsheet), UX (instant interactive changes to the running app as the authors modify it), and an underlying engine that provides live dynamic personalized updatable views into the data in the spreadsheet.
In summary, the spreadsheet is a powerful tool, and finance professionals shouldn't feel ashamed of turning to spreadsheets to figure out how to assemble data and analyze it. What's important is to recognize that the very flexibility and transparency of the spreadsheet that makes it so good for this kind of prototyping exercise is exactly what makes it so vulnerable to error and corruption in a production environment. Once the concept has been validated in a spreadsheet, it then becomes a matter of urgency to take that model and implement it in a more robust platform before distributing it out for routine use. The spreadsheet can still be your friend, but it will soon betray your trust if you let it loose on the world without proper supervision.