The spreadsheet is often innocent

“We need to get out of spreadsheets” sounds like a software requirement. Usually, however, it’s several complaints packed into one sentence.

Perhaps two people keep overwriting the same customer, nobody knows which tab is current, and a manager can’t tell who should act next. Moving the work into an application might solve all three, but it might also give the third problem a more expensive interface. If nobody has agreed who owns the next step, the new system won’t make that decision for them.

Therefore, before we discuss a replacement, we take one row and follow it. Not a cleaned-up process diagram, but an actual row that entered the file recently: who put it there, what happened next, where it waited, and what finally allowed somebody to call the work finished. By the time that row reaches the end, the spreadsheet often looks rather less guilty than it did at the beginning.

What happens when the row leaves the grid?

Imagine a customer enquiry arriving in a shared sheet. The first person adds a name, company, and a short note. Somebody else checks the price in another file, copies the result back, and colours the row yellow because the manager needs to review it. The manager asks a question in chat. By the time the answer comes back, a colleague has made a second copy for the weekly report.

There are at least three different jobs hiding inside that little journey (although they all happen to use rows and columns): the price file is doing a calculation, the shared sheet is acting like an inbox, and the copied report is beginning to behave like an operational database held together by memory. Calling all of them “a spreadsheet problem” doesn’t help us decide what to change.

The price calculation may nevertheless be perfectly at home in a grid. One person owns it, the inputs are controlled, the output is checked, and everybody can inspect the assumptions. A web application could make that model harder to change without making it any safer. The useful improvement may be quite ordinary (separate the inputs from the formulas, protect the important cells, document the owner, and keep a change log).

The shared inbox is a different matter. It can, however, work well while the team is small and the route is simple, especially when people can resolve an ambiguous colour by turning to the person beside them. As the work grows, though, the colours begin to stand for states, the notes begin to stand for history, and each row needs an owner who remains responsible even after somebody sorts the table.

That doesn’t mean the team should start building immediately. First we’d therefore ask what yellow actually means, who can move a row out of it, which information must be present, and what counts as done. If the answers vary by person, the missing thing is an operating rule, because software can enforce the rule once it exists but can’t quietly settle a disagreement the team has never resolved.

The reporting copy points to the third job. When exports feed other systems, staff moreover have to remember which tab is authoritative, and a customer action depends on somebody noticing that a cell changed, the sheet has become more than a flexible working document. It is now carrying state between parts of the business, but without the granular permissions, reliable events, transactional updates, or defined interface we would expect from an operational system. Here the grid itself may finally be the constraint.

Following one row gives us this distinction without asking the team to classify its spreadsheets. It also exposes the side messages and duplicate entry that disappear from an official process map, which is why the same trace sits at the centre of our software discovery conversation.

Count consequences, not just errors

The quickest argument for replacing the file is often that spreadsheets contain errors. They do; however, an error count on its own tells us surprisingly little about the decision in front of us.

Stephen Powell, Barry Lawson, and Kenneth Baker examined 25 operational spreadsheets from five organizations. They found many errors with no quantitative effect and some that materially changed important outputs. It was a small sample, so we shouldn’t turn it into a universal rate, but the paper and its limits make a useful point. A typo in an exploratory scenario isn’t equivalent to a wrong price being sent to a customer (and counting each as one error would hide the difference we care about).

What matters is the consequence, along with the controls around the file. The same researchers therefore later surveyed nearly 1,600 spreadsheet users and reported differences connected with expertise, working practices, and organizational policies. In other words, the way a spreadsheet is managed belongs in the risk discussion too. Replacing Excel while keeping vague ownership, weak review, and indiscriminate access may preserve exactly the conditions that made the original file risky.

Moreover, the official GOV.UK guidance on creating and sharing spreadsheets is practical on this point. A shared file should be understandable to other users, its data and structure should be explained, access should be deliberate, and sensitive information needs protection. Those are good habits whether the sheet lasts for two weeks or two years.

The row tells us when the grid has reached its limit

File size is a poor signal. A sprawling forecast can remain useful because one person owns it and its assumptions are visible, while a tiny sheet can create serious risk if it controls customer prices or exposes information to the wrong people.

The better clues instead appear in what the row is expected to do. We therefore want to know whether two people can change it at once without overwriting each other, whether one role should see a field hidden from another, and whether a changed value needs a record of who changed it, why they did so, and what used to be there. These aren’t questions about whether the sheet looks modern. They’re questions about concurrency, permission, and durable history (things a grid wasn’t built to carry by itself).

The limit becomes clearer when a change is supposed to cause something elsewhere. Perhaps, however, an approved row should reserve inventory, call an API, create a task, or notify a named owner, and the business can’t depend on somebody watching a cell all afternoon. Perhaps the record can be waiting for documents, returned to a previous owner, or approved with conditions, so “open” and “done” no longer describe the work. Or perhaps a customer needs to participate without seeing the rest of the internal file.

Recovery matters as well. When an integration fails halfway through, or the same action is submitted twice, the team should be able to see what happened and continue safely, because reconstructing the event from chat messages isn’t a recovery plan. Once several of these needs belong to the normal workflow, however, a database and application are usually a more honest fit.

Even then, the first release shouldn’t reproduce every tab and formula. We’d rather, nevertheless, complete one important route from beginning to end, leaving a calculation in the spreadsheet if the spreadsheet still does that particular job well.

Keeping it is a real decision

Suppose our customer-enquiry row makes it to the end and the only serious delay was the manager’s unclear ownership decision. We’d keep the file for now, settle the rule, and see whether the work starts moving (a cheaper test than replacing the tool). If the painful part was copying a controlled price into another tool, a validation step or a small integration might remove the handoff without disturbing a model people understand.

Keeping the sheet also makes sense when the work is low-risk, clearly owned, easy to inspect, and still changing as the team learns. The annual cost of a slightly awkward workaround may simply be lower than the cost of building, migrating, training, maintaining, and owning a new system. That’s not technological timidity. It’s a decision about where the business should spend its attention.

We’d replace the sheet when the row reaches a point where the grid can’t honestly represent the permissions, history, events, or states the work now requires. By then, the team can explain the decision using one piece of work instead of a general feeling that spreadsheets are old-fashioned, and the first release can follow that same row without trying to recreate every tab (including the ones that still work well).

Once that limit is visible, therefore, the useful question becomes whether to configure, connect, build, or leave the process alone, which is a much better question than whether the business has graduated from spreadsheets.