Take a simple example: a manager asks for a register before Monday’s meeting. You pull a few exports, tidy the names, add colour to the urgent rows and send it through. It does the job.
The next week, they ask for the same report again. Then someone wants a column for the account owner. A month later, finance needs a different status. A colleague asks for access so they can update their part before the meeting. The file gets a permanent name and a spot in the shared drive.
None of those requests is unreasonable. The spreadsheet may be the fastest, cheapest way to answer a real business question. Good Excel work is skilled work: it turns messy information into a usable view, often long before a larger system could be changed. Research on spreadsheet engineering makes the same point. Spreadsheets are valuable partly because people can explore a problem and change a model quickly as the business changes (Grossman, Spreadsheet Engineering).
Trouble starts when the work outgrows the arrangement around it. A workbook that supports a recurring meeting, a customer commitment, an approval or a payment run has a job in the business. It needs someone to own that job, decide what the numbers mean, keep track of changes and make sure it can still run when its creator is on leave.
That doesn’t automatically call for a software project. It calls for a deliberate decision.
The quiet change from file to service
A weekly report creates an expectation. People plan around it. They expect the figures to be ready at a certain time, and they may make decisions before anyone has checked how the figures were assembled. The spreadsheet has become a small internal service, even if it still looks like a grid of cells.
Look beyond the workbook itself. The real process may include a CRM export, a copy-and-paste step from an email, a lookup sheet maintained by somebody else, formulas, a PDF sent to leaders and a meeting where actions are assigned. The report is one visible part of a chain.
The risk comes from dependency and consequence. A small workbook can matter a great deal if it informs a sensitive decision or has no workable fallback. A huge analysis file used once for local planning may need little beyond clear labelling and saved source data. The ICAEW’s spreadsheet practice principles start with that practical question: how dependent is the organisation on the spreadsheet, and is the spreadsheet suitable for the process it supports?
This is why row count, number of tabs and number of users are poor triggers on their own. A better set of questions is more concrete:
- Who relies on the output, and what do they do with it?
- What happens if it is wrong, late or unavailable?
- Where do the inputs come from, and who can change their meaning?
- Can another person run it and explain a result?
- Has the file started to collect approvals, exceptions or work that should live somewhere else?
Those questions find the point where a handy report has acquired an operating role.
“One more column” is often a new requirement
A new column may be harmless. “Last contact date” could be a useful addition to a sales list. Yet repeated field requests often carry more change than they appear to.
A request for “risk status” needs a definition. Who decides whether an account is amber? Does every team use the same definition? A request for “approval date” may mean the report is now tracking a workflow. “Source of truth” may reveal that people no longer trust the source system. A field for a named executive can turn a local report into an input to senior resource decisions.
Each addition can also create a maintenance obligation. Someone needs to populate it, check it, explain it and decide what happens when it is blank. If the answer is “the person who built the spreadsheet will sort it out”, the process has become person-dependent.
Hypothetical scenario: the Monday pipeline register
A sales operations manager makes a one-off pipeline register for a leadership meeting. The CRM has the core opportunities, but the manager adds notes from support and a separate finance sheet to explain delays.
The CEO asks for the report every Monday. Sales leaders request forecast category, onboarding blocker, renewal risk and executive sponsor. The manager keeps the master file on their laptop and sends a PDF after a late Sunday refresh. Eventually, people use the exception flags to decide where senior staff should spend time.
This is a reasonable response to a reporting gap. It has also grown into a recurring decision product with a deadline, several source systems and business rules that live inside one person’s workbook.
The immediate answer could be modest. Move the master to approved shared storage. Name a process owner and a backup operator. Put the refresh date and source list on the first sheet. Agree what each status means. Check that the number of rows imported from each source makes sense before publishing. Keep a short record when a formula or definition changes.
If the report later feeds compensation, board reporting or commitments to customers, reassess it. The purpose has changed, so the controls may need to change too.
Ownership means more than a name on the file
“IT owns it” is often too vague. IT may be best placed to provide secure storage, access controls, backups and help with data connections. The business team still has to own the meaning of a forecast category, the decision the report supports and whether the report is still needed.
“The analyst owns it” has a different problem. It leaves the business exposed when that analyst changes roles, takes leave or simply has too much work to do. A case study of an end-user computing policy describes annual owner review, review after changes to use or complexity, and the need to support a tool after its author leaves. Those habits are useful well outside financial services, but the exact policy is not a universal template.
For a report that matters, write down the responsibilities in ordinary language:
| Role | What they are accountable for |
|---|---|
| Process owner | Why the report exists, who uses it, what a late or wrong output would affect, and whether it is still required. |
| Maintainer | Refreshing it, documenting material changes and leaving enough instructions for someone else to run it. |
| Reviewer | Checking the inputs and output before use, especially after a change. |
| Data owner | Explaining what an input means and warning people when the source changes. |
| Platform support | Providing appropriate storage, access, recovery and technical advice. |
In a small business, one person may do several of these jobs. That is fine. The point is to expose the gap when nobody has agreed to do one of them.
A useful test is a 30-minute handover. Could a colleague, using a plain run sheet, refresh the report, see which sources are expected, spot an obvious problem and publish the result? If they can’t, start there. You do not need a lengthy manual. A page covering purpose, inputs, refresh steps, checks, recipients and the fallback plan is often enough to reduce a real source of stress.
Treat the request queue as evidence
Most scope creep is recorded somewhere, though rarely in a neat requirements document. It is in email threads, Teams messages, comments on a PDF and the memory of the person asked to “just add this one thing”.
Review the last few requests together. Ask what each was trying to solve. You may find that different people want different things from the same report:
- a sales manager needs exceptions for this week;
- finance needs a stable monthly figure;
- an operations team needs to update a status and show it was approved;
- leadership wants a trend they can trust.
Trying to meet all of those needs on one tab is how a report becomes hard to understand and risky to alter. The right response may be separate views, a clear cut-off time, a formal request for a new field, or a decision to stop using the report for one of those jobs.
Before accepting another change, ask the requester five things. What decision will this change support? Who will maintain the field? What is the definition? Which source supplies it? Does anyone else rely on the old result? Those questions are quick, and they turn a casual request into an explicit choice.
They also make it easier to say no. A report has limits. Adding an approval history to a workbook may be a sign that a temporary tracker is now doing the work of a workflow system. Adding a customer’s personal information may require a different access arrangement. A new field can be declined until its owner, source and use are clear.
Choose a proportionate next step
There are four sensible destinations for a growing spreadsheet. The best choice depends on the work, the consequence of failure and the effort your team can actually sustain.
Keep it, with a few better habits
A shared team report can stay in Excel when the logic is understandable, the process is stable and the consequences of an error are manageable. Give it a named owner and a backup. Separate inputs, calculations and outputs where practical. Protect formula areas if people enter data. Add visible checks, such as a control total or a flag for missing records. Store the master in an approved shared location.
If your organisation uses Microsoft 365 storage, Version History can let collaborators view, compare and restore earlier file versions. That helps recover from an unwanted change. It does not prove the report was reviewed, explain a business rule or replace a handover plan.
This option respects budget and effort. It also asks the team to keep doing the controls they choose. A checklist nobody uses is decoration.
Improve the process around it
Sometimes the spreadsheet is serviceable, while the way it is fed and distributed causes the pain. Remove a repeated copy-and-paste step. Use one agreed export. Replace emailed versions with a shared master and a read-only published view. Add a field dictionary. Arrange a second person to check the report before a deadline that matters.
A global-business spreadsheet-risk case study found that classification, ownership, review, change management and ongoing monitoring worked together, and warned against applying the same control regime to every tool (Lemon and Ferguson). The lesson for a smaller team is not to copy a corporate programme. It is to match the effort to the job.
Rebuild or replace a defined part
Replacement earns its cost when the spreadsheet has absorbed work that spreadsheets handle poorly for your situation: repeated data entry by many people, approvals that need an audit trail, competing versions, frequent rule changes, sensitive information shared too widely, or handoffs between teams that keep failing.
Start with the job, not the vendor shortlist. Map the inputs, decisions, exceptions, people and reporting deadlines. Keep the existing spreadsheet running with sensible controls while you test a replacement. Moving quickly without agreeing on definitions can reproduce the same confusion in a more expensive system.
A business-built tool can be visible and properly managed without being run by central IT. Deloitte Australia’s discussion of end-user computing includes reporting spreadsheets, dashboards and linked automation, and argues for looking at the whole set of tools involved in a decision. That broader view helps avoid a replacement that fixes one workbook while leaving the same manual process upstream.
Retire it
Some reports survive because everyone assumes someone else still needs them. Check the recipient list and ask what decisions each person has made from the last few issues. If there is no clear answer, stop the report for a trial period or reduce its frequency. Archive the final version with enough context to explain it later.
Retirement is a useful outcome. It gives time back to the person maintaining a report that has outlived its purpose.
Hypothetical scenario: the temporary exception tracker
A finance analyst creates a spreadsheet to track invoice exceptions while an ERP fix is pending. The first version has an invoice number, a reason and a note. Over time, teams add approval status, evidence links, adjustment amount, payment date and customer contact. A macro prepares a weekly reconciliation. The analyst is the only person who understands it.
The tracker now holds a working queue, approval evidence and a reconciliation step. Calling it temporary does not make those responsibilities disappear.
First, make it safer to operate. Put the master in a controlled location. Limit editing to the people who need it. Name a backup operator. Keep recovery copies. Have one person prepare a change and another check it. Record how the macro is run and how the weekly total is checked.
Then decide where the work belongs. The ERP fix may remove most of the need. A controlled list or a small purpose-built workflow may fit better. The spreadsheet can remain a controlled interim tool while that decision is made. Removing it before the replacement works would simply push the process into email and memory.
Set review triggers before the next emergency
A one-time inventory soon goes stale. The tools change because the work changes. Keep a short register for reports and workbooks that support meaningful operations. For each one, record its purpose, owner, backup, cadence, inputs, recipients, key checks, last review date and planned destination.
Then review it when something material changes. Good triggers include a new decision-maker relying on it, a new data source, a change in the calculation rules, a new approval step, a wider audience, sensitive data, loss of the maintainer or a missed deadline. A periodic review also helps, but events are where hidden scope creep becomes visible.
Consultancy guidance on end-user computing highlights the same lifecycle issue: inventories decay when the people using the tools are not accountable for updating them (KPMG’s EUC risk approach). Keep the register small enough that owners will actually maintain it. Start with the reports that would hurt most if they were wrong or absent.
Start with the report that makes people nervous
Pick one recurring report, register or tracker. Ask who uses it, what feeds it, who could run it tomorrow and what has changed since it began. Read the request history. Write down the answer on one page.
You may decide the spreadsheet is still the right tool. Many are. You may find a few straightforward controls will take the pressure off. Or you may find a process that needs a proper rebuild. Each is a good result because somebody has deliberately taken ownership of work that was previously growing by accident.
If you want an outside view, DitchMySpreadsheet can analyse a synthetic sample and provide structure analysis and recommendations. Use made-up or safely anonymised data only. Do not upload sensitive business, customer or personal information.