We can learn a great deal from spreadsheets.
For starters, spreadsheets are amazing when it comes to creating accounting worksheets and financial models. Instead of laboriously having to recalculate pages of financials by hand, spreadsheet software has utterly changed the operations of accounting and financial planning, making it possible for all manner of organizations to evaluate more projects and more permutations of those projects than would have been imaginable a few decades ago. Cash flow, net present value, and scenario planning can now be completed in minutes or hours instead of days and weeks.
Perhaps more astonishing is how spreadsheets have become the most widely-used project management software. (1)
It isn’t hard to find folks arguing what a terrible thing this is. A quick Google search will provide links to any number of blog posts and articles about how spreadsheets are not fit for purpose, and proper software should be used…which is hogwash. People who use software are usually a lot smarter about these things than those of us who make software (especially when we fail to listen carefully).
People use spreadsheets for project management because spreadsheets are often the best tool for the job. A tool for which spreadsheets were not designed. This is all the more remarkable because a lot of software sucks for its intended purpose and not much use for anything else. We can learn from this!
Our theory is that while there is no single reason that organizations use spreadsheets, the most important factor is that spreadsheets are Agile.
Need to manage a project or a team? You can hammer together a plan in a spreadsheet in a few hours or a few days, depending on the scale of the effort.
Need to update your process? All that is required is to sit down and update the spreadsheet. Voila! Your project management software has been updated to your latest process.
Need to share information? You can quickly share the document or link, or export the data you need to share and text/email/Slack the details to whomever needs this information.
There is of course much, much, much more that you can do with a spreadsheet, but let’s stay focused on project management and agility (2)
The Agile manifesto and business software
Spreadsheets are so powerful and flexible, in fact, that it is useful to think of spreadsheets as Agile. In particular, we can think of spreadsheets as a powerful exemplar of how we should think about business software. More generally, we can use spreadsheets to help us think about what it means for business software to be Agile.
If we turn to the Agile manifesto while thinking of spreadsheets, we see that spreadsheets hold up pretty well:
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan (3).
The Agile manifesto works pretty well for project management. Suppose that you and I sit down to work on a complex project together. The odds are that if we use a spreadsheet to manage the project, we shall remain largely focused on the task at hand and how we can partner effectively, even as our complex project takes various twists and turns.
(1) If, on the other hand, we decide that we ought to use a database or some other complex software, we are liable to change course and end up very quickly talking about which database to use, and how to manage information in the database. Happily lost in a conversation about processes and tools, we will find ourselves busily veering away from the complex project which brought us together.
(2) If we jot some notes in a spreadsheet, we are likely to quickly have a sense of what we’re working on and have an opportunity to get to work. If, on the other hand, we try to plan out the next year of work, we are perfectly capable of wasting several days planning work that will have nothing to do with where we find ourselves a few months.
Periodically, we are likely to find that our plan was not particularly accurate, and need to update our spreadsheet.
(3) If, on the other hand, we have opted for a project management process that becomes a contract, we will find ourselves negotiating over the contract instead of collaborating on the complex project that brought us together. Goodness help us if we have business plan, and we spend weeks accomplishing nothing while we argue about what we should do some time hence. Which is not to impugn business plans, which are very useful! You just have to remember to throw them away after you write them, or as soon as they turn out to be useless.
(4) Finally, if this hypothetical complex project has to evolve over time, as complex projects usually do, we find that if we have spreadsheet we are in good shape. On the other hand, if we’ve built any sort of project management or process software, we are very likely to have to discard our software, or set our work aside to refactor our planning software. Heck, it’s probably easier just to stick to the original plan and stick to the original project even if nobody needs it any more.
Agile business software
If we accept that spreadsheets are Agile, how can we understand the particulars to help us to understand the general case? Can we we use inductive reasoning to identify general principles that we can further examine? We could write books about this question, so to contain it, let’s wrap this post by going back to the Agile manifesto once again:
Individuals and interactions over processes and tools. When it comes to processes, spreadsheets tend to be so elastic that the individuals using them are able to update them in whatever manner and process that they see fit. Need to track more information? Just add some columns or rows. Want to try a different model? Just make a copy of the current spreadsheet and spend a few hours organizing it in a new way. Any team and any set of individuals can open a spreadsheet and look at it, work with it, update it if needed. In a healthy organization, spreadsheets privilege people and collaboration over processes and tools. In a world where we are too often limited by our processes and tools, this is no small thing. People come first. People interacting most of all!
Working software over comprehensive documentation. In the bad old days when servers were extraordinarily expensive, there was a school of thought that felt it was important to write detailed documentation before creating software. Sometimes we write hundreds or thousands of pages of documentation reflecting the business software that would have been useful five or ten years earlier. Often, complex project plans were built in parallel with these documents. The impulse is understandable: if I am going to charge you nine or ten figures to build a business platform over the next few years, shouldn’t you know what you will get for that investment, and when you can expect it? This understandable impulse is horribly wrong. For example, the CHAOS Report suggests that large projects fail far too often, and large projects fail more often than small projects (4).
Spreadsheets, in contrast, are as successful as weeds. They thrive precisely in those parts of your organization that are changing the fastest, in those parts of your organization that will drive the changes that are the most important in the coming years. Spreadsheets that are not needed can be discarded. Spreadsheets that serve a purpose are an exemplar of working software. Working software, at a business level, is not a server that meets a spec. It is software being used by teams to manage or facilitate their day-to-day work. Spreadsheets are a canonical example of working software.
Customer collaboration over contract negotiation. How often have you watched a colleague share a spreadsheet in a meeting or collaboration tool to report on an outcome or propose a new process? The spreadsheets that are most important are those that allow us to collaborate, either by driving operations in the case of project management or driving decision making in the case of planning.
Agile business software is built for humans, around humans’ fraught and limited collaboration skills. While contract negotiations are necessary, we know that collaboration is generally more profitable than adversarial negotiation. The more complex our work together, the more important collaboration is, and the less useful contracts are.
Responding to change over following a plan. Everything changes. If our business software cannot respond to change, it will not be fit for purpose long. Here we see the great tragedy of too much business software, deployed to meet a need that has already passed, and too brittle to grow and change with an organization that never stands still. Again, we see how spreadsheets provide an example for the flexibility that we can reasonably expect to drive business in the coming decades.
We can learn a great deal from spreadsheets.
(1) Citation needed. As always, happy to be proven wrong on this 🙂 Anecdotally, we can confirm that we’ve talked to dozens and dozens of teams and businesses who run their business on spreadsheets and similar software, so we feel that this is a reasonable hypothesis.
(2) Well, we have to digress a tiny bit, because spreadsheet art! https://www.calculatedriskblog.com/2007/12/very-nerdy-christmas.html