The spreadsheet is the specification

Every organisation past a certain size has one: a spreadsheet, maintained by one person, that the real operation depends on. It has colour coding nobody documented, a tab called DO NOT DELETE, and a column that means two different things depending on the row.

When you are building operational software, that file is the most valuable artefact in the building. It is a specification written by the people who actually do the work, refined against reality every day, with every exception already handled — badly, but handled.

Why requirements gathering produces a worse document

Ask a manager how admissions work and you will get the official process: enquiry, application, interview, offer, enrolment. Clean, linear, correct in outline, and missing everything that makes the system hard.

The spreadsheet tells you the truth. There is a column called Status with fourteen distinct values, four of which are variations on "waiting for the parent to send a document". There is a row highlighted amber with a comment reading sibling — check discount with head before invoicing. There is a tab for students who left mid-year and came back, which the official process does not acknowledge exists.

Those are not edge cases. They are the operation. A system that models the clean five-step process and treats the rest as exceptions will be abandoned within a term, because the exceptions are where the staff spend their day.

What to extract from it

Read the file for four specific things.

The real state machine. Every distinct value in the status column is a state, and every colour, comment, or separate tab is usually a state somebody could not express in the column. Write them all down, then ask which transitions are legal. You will find at least one state that exists purely because two departments disagree about who owns the record at that point — and that disagreement needs resolving in a meeting, not in a schema.

The identity rules. How does the team know two rows are the same person, order, or property? Whatever they do by eye — name plus date of birth, address plus postcode, invoice number plus supplier — is your deduplication key, and it is usually more subtle than any single ID field would suggest.

The unwritten permissions. Who is allowed to open this file? Who edits which columns? The fact that only one person touches the fees tab is an access-control requirement, and if you miss it you will build a system where the receptionist can see salaries.

The manual reports. Somewhere there is a pivot table, or a monthly copy-paste into a document, that produces the numbers a manager actually looks at. That report is your first dashboard. Not the one anybody asks for in a workshop — that one gets built and never opened.

Model the transformation, not the form

The most common mistake in operational software is modelling the screens people currently look at rather than the process underneath. Screens are cheap to change; models are not.

In a factory, this is the difference between recording that a slab was produced and recording that this block became these slabs, on this machine, on this date, losing this much material. The first gives you inventory. The second gives you yield, machine performance, real unit cost, and traceability — from the same capture effort, because the operator scans the parent either way.

In a clinic, it is the difference between an appointment record with a notes field and separate appointment, encounter, and invoice records with explicit transitions between them. The first is easier to build and cannot answer "how much unbilled work happened last month".

Ask what the record becomes, not what it looks like.

Then ship something small, quickly

The corollary of taking the spreadsheet seriously is that you cannot build the whole system before anybody uses it. The spreadsheet contains the operation as it was; the moment you replace part of it, you will learn things about the operation as it is.

One department, real data, a few weeks. Not a demo — a thing somebody uses on a Tuesday to do their actual job. The feedback from one real Tuesday is worth more than a month of workshops, and it arrives while the data model is still cheap to change.

The spreadsheet does not get deleted at that point, incidentally. It gets quietly abandoned, which is a much better signal. When the person who maintained it stops updating it because the system is faster, the project is working. Until then, they are telling you something.