Almost every operation we are asked to systematise is already running on a spreadsheet. It is usually one workbook, several years old, maintained by two or three people who are quietly afraid of it. Everyone treats it as the problem. It is better understood as the most accurate specification the business has ever produced.
Nobody wrote that workbook in a planning meeting. It grew a column at a time, each one added the day a real problem appeared. That makes it an unusually honest record of how the work actually happens — including the parts nobody would mention in a requirements workshop.
What to read out of it
- The columns are your data model. Each one exists because somebody needed that field badly enough to add it by hand.
- The conditional formatting is your alerting. Whatever turns red is what the business considers an exception worth acting on.
- The tabs are your permissions model. A tab exists per role far more often than per topic.
- The formulas are your business rules — margin thresholds, uplift percentages, capacity assumptions — written by the person who actually understands them.
- The manual steps are your integrations. Every copy-paste between sheets is a system boundary that should be an event.
The columns nobody can explain are the most valuable ones. Somebody added them for a reason, and finding out what it was is discovery.
What not to do with it
Do not rebuild it screen for screen. A spreadsheet is a workaround for not having software, and it carries compensating habits: duplicate rows kept “just in case”, a status column that means three different things, a tab that exists because two people cannot edit at once. Those disappear when the underlying constraint disappears.
The right move is to model the entity the sheet is really about — the job, the enquiry, the cohort — and then check that every column has a home. Columns that do not fit usually reveal either a second entity hiding in the sheet, or a habit that no longer needs to exist. Both are worth a conversation before anything is built.
The handover test
When we map an operation, the goal is a document that the person who maintains the workbook reads and recognises. If they read the map and say “that is what we do, but you have straightened out the bit about part-completed jobs”, the specification is right. If they read it and go quiet, something has been lost and the build would have failed six weeks later.