Reading the spreadsheet as the specification, explained before you need it
Reading the spreadsheet as the specification from the start, for a room that contains both engineers and the people who'll live with it.
Most write-ups of this start in the middle. We'll start earlier than strictly necessary, because nine times in ten the confusion comes from a word two people are using differently, not from the mechanism.
The spreadsheet somebody maintains by hand is the most accurate specification in the building. It has no budget, no committee and no aspirations. It describes what the work actually requires, which is more than the requirements document manages.
WHY IT IS MORE HONEST
A requirements document describes what people believe should happen. A spreadsheet describes what they do to get through the week. When those disagree, the spreadsheet is right, because it's under daily pressure from reality and the document isn't.
It also survives selection. Every column in it exists because someone needed it badly enough to type it in repeatedly. Nothing in it is speculative, which is not something you can say about any feature list.
HOW TO READ ONE
Start with the columns nobody can explain the name of. Those are usually where two concepts got fused because the system forced a choice. Then look for the colour coding, which is almost always an undocumented state machine. Three shades of yellow means three states your model needs.
Then find the comments. Free-text notes are where the exceptions live, and the exceptions are the actual domain. Read forty of them in a row and you'll have a better model than any workshop produces.
Made concrete: a meter read passes through several pairs of hands, and each of them believes it owns the record. What's above is how you let all of them be right without letting any of them silently overwrite the others.
REPLACE THE JOB, NOT THE FILE
The instinct is to build the spreadsheet as software, which produces a worse spreadsheet with a login page. The point isn't to reproduce the file, it's to remove the reason it exists, usually a state the real system can't represent or a handoff it can't see.
Fix that and the file stops being updated on its own. That's the outcome to aim for. Nobody needs to be told to abandon a workaround once the workaround stops being necessary.
Picture a distributed generation operator at several million reads a day. The naive version works perfectly in testing and falls over the first day two settlement analysts touch the same meter read in the same second.
WHERE IT GOES WRONG
- Ignoring the colour coding, which was the state machine nobody wrote down.
- Reading the requirements document and not the forty free-text notes that describe the real exceptions.
- Banning the spreadsheet before the system can represent what it was tracking.
- Building the spreadsheet as software, and shipping a worse spreadsheet with authentication.
Read the spreadsheet before the requirements. Then remove the reason it exists.
THE SHORT VERSION
None of this is advanced. It's ordinary practice that gets skipped when a date is close, and then paid for with interest by whoever's on call.