In discovery work across several industries, I have learned to expect the unofficial spreadsheet. Someone mentions it almost apologetically: a workbook that is not official, is not in the warehouse, and stealthily overrides a number the “real” system produces before anything reaches a manager.
The scenario here combines several real situations I have encountered. The corrections did not all live in one workbook, but the pattern was the same: a person had become the final transformation layer because the shared system did not represent an exception the business still had to manage.
The usual response is a policy conversation: stop using unofficial spreadsheets, trust the system of record, route exceptions through proper channels. That conversation rarely works, and it should not, because it treats the spreadsheet as the problem instead of what it actually is: evidence.
Nobody maintains a manual override for years for fun. At some point the automated number was wrong, someone fixed it by hand under deadline pressure, and no one closed the gap that made the correction necessary. The spreadsheet is the visible symptom of an invisible defect.
Read the spreadsheet instead of banning it
The more useful opening is not “Why are you doing this outside the system?” It is “Walk me through exactly what you change, and when.”
Across real situations, that question has surfaced a location attributed to the wrong region after a reorganization, a category of return the source system could not distinguish from a fresh sale, and a timing difference between operational and financial revenue recognition.
Three questions turn the workbook into a diagnostic:
- What does the spreadsheet change?
- Under which circumstances does the change apply?
- What happened when its owner stopped trusting the official answer?
Once the gap has a name, it usually has a tractable response: add a missing dimension attribute, refine an incomplete transformation rule, or turn undocumented operational knowledge into an explicit business definition. The spreadsheet was not merely a workaround. It was someone performing governance the system should have supported, using the only tool available.
What actually retires it
The spreadsheet does not go away because someone asks nicely. It goes away when its owner checks the new number against their own for several cycles and the result holds up—including the edge case that made the workbook necessary in the first place.
That is slower than a policy memo. It is also the only process that earns trust back.
Before asking who authorized the spreadsheet, ask what failure made it necessary.