The spreadsheet is the specification

When a business has outgrown its software, somebody in that business is already maintaining the replacement. It is usually a spreadsheet. It is open on a second monitor all day, it has one owner who is slightly apologetic about it, and it is where the real answers live when the system and reality disagree.

People tend to show it last, and they show it the way you would show a cupboard you meant to tidy. It is the most valuable document in the building.

Why it exists

A product built for thousands of businesses encodes one model of how the work goes. Most of the time yours is close enough. The spreadsheet is precisely the gap between that model and yours — the parts of the job the software has no field for, no step for, and no opinion about.

Which means it is not a sign of disorganisation. It is a record, kept at real expense in someone’s time, of every requirement the product failed to meet. Nobody maintains a spreadsheet for fun. Every column in it survived because it earned its place, which is more than can be said for most requirements documents.

A requirements document is a guess about what matters, written by people who will not be using it. The spreadsheet is the same thing after two years of being wrong in public and getting corrected.

How to read one

Sitting with the person who maintains it for an hour will tell you more than a week of workshops. Some of what is in there:

• The columns are the fields the system is missing. Not the ones somebody would like. The ones that were worth typing by hand, every time, for years.
• The colour-coding is a status field. Nobody calls it that. Ask what yellow means and you will get a precise answer, including the edge case where something is yellow but actually fine.
• The formulas are business rules. Usually the pricing ones. They are often the only written record of how the company actually decides what to charge.
• The tab nobody opens any more is a process that died. Worth asking about, because occasionally it did not die — it moved into someone’s head.
• The rows that break the pattern are the exceptions. The merged cell, the note in red, the row with a different formula. Those are the cases that will break your build if you only design for the pattern.
• Whoever updates it is the system owner. Whatever the org chart says, that is the person whose approval the new system needs and whose working day it will change most.

What it tells you that people will not

Ask how a quote gets produced and you will be told the official process. That answer is honest and it is usually also wrong, not because anyone is hiding anything but because the official process is what people believe they do. It leaves out the step everyone takes without thinking, and the two cases a month that go a different way entirely.

The spreadsheet does not have that problem. It is a log of what happened, not a description of what should. When the interview and the spreadsheet disagree, the spreadsheet is right, and the disagreement itself is the most useful thing you will find that day.

The trap

The obvious move is to build the spreadsheet. A table with the same columns, the same colours, a nicer interface. It demos well, everyone recognises it, and it is nearly always the wrong system.

A spreadsheet is shaped by what a spreadsheet can do. Things are duplicated because there is no way to reference them. Status lives in a colour because there is no way to make it a field with rules. Everything is one flat table because that is the only structure available. Rebuilding those constraints in software preserves the workarounds and throws away the reason to replace it.

The question to keep asking is not “what does this column do” but “what is this column working around”. A column called Chased? is not a requirement for a Chased field. It is a requirement for the system to know when something has gone unanswered too long.

What we do with it

We ask for a copy early, with the real data in it, and we read it before the second conversation. It becomes the first draft of the specification — not copied across, but used as the checklist that the specification has to account for. Every column has to end up somewhere, or there has to be a sentence explaining why it does not need to.

It also tends to supply the success criterion, which is the hardest part of a specification to write well. Often the criterion is the spreadsheet itself: if it is still open on that second monitor six months after launch, the job is not finished, whatever the scope document says. That is a harder test to pass than a feature list, and a much easier one to agree on, because both sides can see the answer without arguing about it.