Most of a process is the part nobody documented

The manual is not the process

A written procedure does not always describe the way the work is really done. The gap between the two is where exceptions and unwritten rules can be found.

They accumulate: a client invoiced differently because of an earlier agreement, a step skipped when a request comes from a particular department, a threshold applied differently in practice.

Where the exceptions are kept

In the head of the person who has done the job longest. Sometimes in a spreadsheet on one machine, sometimes in an email folder, occasionally on a note taped to a monitor.

That person is also the reason the process works. They are not obstructing anything by holding the rules in their head, which is why asking for documentation produces the procedure again rather than the truth.

How we get them out

So we sit with them and watch the work. Not a workshop and not a questionnaire: the actual queue, on an actual morning, including the cases they would normally handle without mentioning.

Then we read back what we wrote, in their language, and they correct it. Most of what we learn comes out of that correction rather than the first telling.

What we end up with is the process as it runs, which is the document the client keeps whether or not anything gets built.

Why they decide whether a system works

The exceptions are the design

A system that handles only the clean path automates the part that was never expensive. The value is in one that recognises the exception, applies the rule where a rule exists, and hands the case to a person with the working attached where it does not.

And they keep arriving

New exceptions appear as the business changes, which is why somebody has to stay with the system. We review them with the people who do the work, not against a dashboard.