Every replacement project starts with a confession: we're still running this on a spreadsheet. It's said with embarrassment, as if the spreadsheet were the failure. It isn't. The spreadsheet is the survivor. It's what was left after the purchased system didn't fit, after the workarounds piled up, after staff quietly chose the one tool that would bend to the work. It won on merit, and it holds more of the program than anyone admits.
Anatomy of a Working Spreadsheet
Open the backflow tracking workbook at a small utility and look at what's actually there. There's a column named LAST TEST / OK? that holds three different kinds of truth: sometimes a date, sometimes just the word OK, and sometimes a sentence — called 4/12, owner says the assembly came out during the remodel, verify before sending notice. A date, a judgment, and a story, all in one column, and the clerk who maintains it knows exactly which is which.
There's a tab called DO NOT DELETE. Nobody remembers everything on it, but the two times someone needed it, it was the only place the answer existed. The row colors are statuses too subtle for any status field: yellow means waiting on the owner, gray means vacant service, and a particular shade of green means see Carol before you touch this one. The conditional formatting that turns a row orange when a test date ages past ten months was set up by a billing clerk who retired six years ago. Nobody knows the formula. Everybody trusts the orange.
And down at the bottom are the weird rows — the church with two meters and one assembly, the property in a billing dispute, the account that exists in the spreadsheet but not in the CIS. Those rows are the cases no purchased system has ever known what to do with.
The Twelve Columns That Never Made the RFP
Replacement projects fail by replacing the artifact without reading it. The RFP gets written from the vendor demo and the program manual: assembly type, test due date, tester certification number. The spreadsheet has thirty-eight columns. Twelve of them never make it into the RFP, because nobody asked the person who added them why they exist. Each one was added the day its absence cost somebody an afternoon.
So the new system arrives, the official columns migrate, and the record counts match. The colors, the notes, the DO NOT DELETE tab, the weird rows — none of it has a destination, because nobody knew it was load-bearing. Within months the dashboard says current while a fresh spreadsheet grows in the shadows, holding the parts of the job the software refused to hold. Now the utility runs two systems, and the honest one is still a spreadsheet.
Read It Before You Replace It
The spreadsheet is the most accurate requirements document the program will ever have, so treat it like one. Sit with the person who maintains it and have them narrate a week of real use. Ask what every color, abbreviation, and odd tab means — each is a requirement nobody wrote down. Spend the most time on the rows that don't fit, because those are the exceptions the new system has to represent or it isn't an upgrade; it's a regression with a login page. The next system has to remember what the spreadsheet knew.
What It Genuinely Can't Do
None of this is an argument for keeping the spreadsheet. It has no audit trail beyond what the notes column remembered to say, no automation — every due date is watched by a person — no permissions, and no defensible record when a shutoff gets appealed. It's one bad filename away from disaster and one retirement away from illegible. Those are real reasons to replace it. They are reasons to replace it with something that holds everything it holds, plus those things — not with something that holds less, more officially.
Before you write the RFP, print the spreadsheet and read it column by column with the person who built it. It isn't the embarrassment. It's the specification.