Most companies have at least one spreadsheet leadership wishes would disappear. Nobody really trusts it, but deleting it would probably cause an immediate minor crisis.
It may have started because the reporting software couldn’t answer a fairly ordinary question. Over time, someone added another column, then a second tab, then a formula copied from an older file nobody completely understands. There may be a cell that turns red for reasons known only to one employee and a tab called something like USE THIS ONE. The file is difficult to maintain and easy to break. It may also be one of the more accurate descriptions of how part of the business actually works.
These arrangements don’t always look like software. A Teams thread can become the place people check before answering a particular customer because it contains details that never made it into the customer record. New employees learn to check it, too, and eventually the team depends on a conversation nobody intended to maintain as a reference.
There are good reasons to bring that information into a controlled system. IT may have security concerns about unofficial software, and a manager trying to reconcile conflicting records has a reasonable interest in getting everyone to use the same one. But the people proposing the cleanup need to understand why employees still use the unofficial version.
Suppose a customer service team keeps a spreadsheet beside the company CRM. The CRM records whether a case is open or closed, while the spreadsheet distinguishes cases waiting for finance from those waiting for the customer. There’s also a category whose meaning turns out to be roughly “Maria is dealing with it.”
The obvious improvement is to stop maintaining two records, but those categories probably appeared one at a time as the team found it needed them. A case waiting on the company requires a different response from one waiting on the customer, even though both are open. Eventually the team had built a rough model of the work the CRM didn’t represent very well.
Replace the file without preserving those distinctions and people will find another place for them. Their jobs still require the information. Six months later there may be a new spreadsheet that someone has to reconcile with the CRM again. Management may conclude that employees are refusing to adopt the new system, even though they’ve rebuilt something the project accidentally removed.
People are continuously editing the business
A salesperson starts recording a detail that wasn’t considered important when the CRM was configured. She’s noticed that it tells her which deals are likely to stall, so she finds somewhere to put it and keeps track. By the time anyone reviews the CRM configuration, she may have been using that information for years.
Formal systems rarely receive an update every time someone learns something useful or the work changes. An acquisition can leave a team working across two sets of tools for much longer than anyone planned. The manager combining reports from both every Monday still needs an answer for the meeting at ten. She develops a way to get it, and that routine may survive long after anyone remembers it was supposed to be temporary.
There are bad habits mixed into this, naturally. Some processes outlive their purpose, and a personal account used for company work may need to be shut down regardless of how convenient it is. Understanding a workaround doesn’t commit you to keeping it. It gives you a better chance of removing it without leaving people unable to do part of their jobs.
Sometimes the dependency is a person. One employee somehow becomes part of five processes without anybody deciding she should. She remembers an old agreement that created an exception for one customer and knows why a particular status in the system doesn’t mean what a new employee would reasonably assume it means. When an order gets weird, someone sends her a message. Nothing in the org chart says the company depends on her for any of this, but planning around her holiday may reveal how much it does.
Cleanup can erase knowledge
Modernisation projects often begin with an inventory of everything messy about the current operation. There are overlapping systems and people copying information between them, along with a few processes nobody can explain without involving someone who has worked there for fifteen years. Looking at that inventory, it’s easy to see the appeal of consolidating everything.
Some organisations desperately need that work. The difficulty is establishing which apparent duplicates are actually doing the same job. One department may maintain its own customer list because the official hierarchy doesn’t describe the relationships it needs to track. Moving those records into the main system requires a decision about how those relationships will be represented, or whether the department will have to manage without them.
Software projects can expose these questions halfway through implementation. Somebody asks what a particular status means and gets a different answer from each department. A screen that looked like a straightforward replacement suddenly needs to represent distinctions nobody documented because everybody using the old process already knew them. The disagreement has to be resolved before anyone can build a replacement that works for all of them.
Automation makes this easier to overlook because so much administrative work can now be automated that previously required a person. Consider an employee who routinely ignores a field and reads a note before approving an order. The field may be unreliable, or the note may contain a condition the system has no way to represent. Automating the approval using the field alone removes a check without necessarily removing the need for it. Someone needs to establish what the employee is checking and how the new process will account for it.
Sometimes the workaround is the interesting part
An unofficial system can contain an idea worth developing. A homemade sales tracker may group customers in a way that helps the team predict which accounts will need more support. The categories might have started as one person’s shorthand, then spread because colleagues found them useful. That gives the company something specific to investigate: whether those categories predict the work more accurately than the ones in its existing systems.
There may have been no proposal or deliberate attempt to innovate. Someone made an Excel file on a Tuesday because they were sick of answering the same question, and other people kept using it. It’s worth finding out what made it useful enough to last.
This is part of what we look for at ShanVic when we read an organisation across People, Processes and Products. We want to understand where the formal process no longer accounts for what people have to do. A workaround can help us locate that gap, while the way employees use it may tell us what a replacement needs to support. Occasionally, they’ve already worked out a better approach and need help making it reliable enough for wider use.
That thinking is part of the Clarity Brief. We want to understand why something strange survived before deciding what should replace it. A closer look may reveal that the team needs a decision about who owns the work before it needs new software. When we say Read the Signals. Build the Systems., that includes asking why a team still needs a spreadsheet everyone agrees should have been retired.
Ask about the weird stuff
If you want to learn how a company works, read the process documentation and then ask someone to walk you through a recent case that didn’t fit it. Find out what they had to check and where they found the information. If they needed help from a colleague, ask what that person knew that they didn’t.
It’s also worth asking what they would be nervous to lose tomorrow, even though it isn’t supposed to be important. That question can lead you to an unofficial file or a routine so familiar that nobody thought to mention it when you asked about the process.
Some of what you find will be junk, and the people maintaining it may be relieved to see it go. But there may also be a spreadsheet everyone makes fun of because it’s old, ugly and much too important. Before you delete it, find out why.