The business has a proper system. It stores the records, supports the official process and produces the agreed reports. Yet one team still runs an important part of its day from a spreadsheet.
Before telling them to stop, I would want to see what is in it.
That file may contain a picture of the work that the official process has never quite captured: the exceptions, dependencies and decisions people need to manage. Understanding why it exists can tell you what an improvement needs to do.
The workaround may be answering a real question
Consider an illustrative scheduling team. Its main system shows jobs, dates and status. Its spreadsheet also records access restrictions, equipment availability, the customer's preferred contact time and whether a specialist person is required.
Those additional columns influence whether a job can actually go ahead. The spreadsheet gives the team a view it can use to make that decision.
Perhaps the main system can hold the information but has not been configured to show it usefully. Perhaps the team has never been trained on the relevant feature. Perhaps a genuine capability is missing.
Each explanation suggests a different response. Removing the spreadsheet before understanding the need could remove a useful part of the operating process without replacing it.
Honest does not mean accurate or safe
The title describes what the spreadsheet can reveal about the work. It does not mean every figure or formula in it should be trusted.
A file may contain stale data, inconsistent definitions, hidden calculations or manual adjustments that only its creator understands. Several versions may be in circulation. Access arrangements may be inappropriate for the information it contains.
Inspect those weaknesses alongside the useful capability. Ask where the inputs come from, who updates them, how calculations are checked and what decisions rely on the result.
The aim is to understand both the requirement and the risk. Familiarity with a file should not become a reason to ignore errors or leave a critical process without clear ownership.
Watch someone use it to make a decision
Ask a regular user to take you through a recent piece of work. Let them show you the sequence rather than starting with a list of features they would like in a replacement.
What do they enter first? Which information do they copy from elsewhere? What does a colour or note mean? When do they call a colleague? Which part tells them the next action?
Look closely at the exceptions. A manual override may represent a legitimate business decision, a temporary fix or an error that has become normal practice. Ask what authorises it and what effect it has downstream.
Repeat the walkthrough with another user if the process depends on several people. Differences can reveal a training need, an unclear definition or a file that has grown into several different jobs.
Turn the columns into requirements
Return to the scheduling example. An “access confirmed” column might represent a readiness condition. A colour beside a name might mean that a qualification needs checking. A notes field may contain the reason a date cannot be moved.
Translate those observations into plain requirements. Who needs to know the information? Who can confirm it? When does it become relevant? What should happen if it is missing or changes?
Separate the requirement from the current way of showing it. The business may need to prevent an unready job from being scheduled; that does not establish that the new system needs the same coloured cell.
Also distinguish useful information from inherited clutter. Ask when a field last changed a decision. Some columns remain because an earlier customer or reporting arrangement once needed them. Confirm their purpose before carrying them into another tool.
Choose the response around the work
There are several reasonable outcomes from this review.
Improve the spreadsheet. A bounded task may be served well by a clearer, controlled file with checked calculations, appropriate access and a named owner. Agree what its limits are and how it will be maintained.
Use the existing system better. Relevant fields, views or workflow features may already exist. Check the available capability and what it would take for the team to use it in practice.
Connect a specific gap. A small integration or application may help where information needs to move between tools or a focused decision needs a clearer interface. Define which system owns each record and how errors will be handled.
Replace the arrangement. If the process needs stronger controls, collaboration or scale than the existing tools can support, a broader change may be justified. Use the observed requirements to assess the options.
The right answer depends on the task, the consequences of failure and the effort needed to operate the solution. A bigger system is only helpful if it supports the work and can be maintained.
Test the replacement against the awkward cases
If you change the arrangement, use representative examples from the current process. Include incomplete inputs, changed plans, exceptions and the handover to another person.
Ask users to make the decisions they would normally make. Can they see enough context? Can they explain an exception? Does the result reach the people who need to act on it?
Compare the outputs with an agreed standard. Where an old calculation is wrong, document the correction rather than expecting the replacement to reproduce it. Where the new process deliberately changes a rule, make that decision explicit.
Agree how records will be checked during transition, which source takes precedence and when the old method will be retired. A short, controlled comparison can be useful; two indefinitely competing records create another problem to manage.
A five-column discovery exercise
Choose one spreadsheet the business depends on and build a short review alongside it:
| What to record | The question it answers |
|---|---|
| Information or calculation | What does this field or formula represent? |
| Decision supported | What does someone do differently because of it? |
| Owner and source | Who confirms it, and where does it come from? |
| Exception or weakness | When does it become unreliable or need judgement? |
| Required capability | What must a future arrangement allow the team to do? |
Use the exercise to choose a response, then define the smallest useful improvement you can test. Keep the people who rely on the file involved in judging whether the change works.
A workaround is evidence worth examining. It can expose the distance between a documented process and the work people actually need to complete. Read that evidence before deciding what to build.
Novologix offers business reviews and diagnostics and scoped workflow automation. We can help you understand the job your spreadsheet is doing and assess a proportionate way to improve it.