Written for whoever was not there

The problem it solves

Ask anyone to describe their job and you will get a clean version: five steps, in order, no friction. Stand beside them while they do it and you will see something else. You will see them open an old email to recover a number, ask a colleague something without looking up, and handle one case differently without mentioning it, because to them it is not a special case, it is just how it goes.

That gap is why so many written procedures are useless. They are not badly written. They are written from memory, and memory erases exactly what a beginner needs: where the file is, what to do when the figure does not arrive, who to ask, and how you know the step finished correctly. The cost is paid in pieces nobody adds up: every new hire learns by asking, and learns a different version depending on whom they ask, and every absence of the person who knows stops the work or leaves it to improvisation.

There is also an incentive problem nobody says out loud. The person who knows the process best is the one with the least time to write it down and, in many organizations, the one with the least to gain from writing it, because part of their standing comes from being the only one who knows. Left alone, the process walks out the door the day that person does.

What it covers

The day is spent producing documents rather than explaining how documents are produced, and it is organized around one specific reader: the person who was not there and who will have to run the process tomorrow with nobody to ask. That reader sets the level of detail better than any writing standard could. Each participant works on a real process they run or supervise, in short rounds with cross-review between people from different areas, and goes through the full cycle more than once in the course of the day.

The method starts with observation rather than drafting. People work in pairs: one runs the process with their own tools, or walks through it step by step on a recent case, and the other writes down what they see rather than what they are told. That is how the sequence gets captured as it happens: the trigger that starts it, what has to be at hand before beginning, the decisions and the criteria behind each one, the exceptions the person resolves without thinking, and the signal that the step was completed properly. The most productive question is also the simplest one: how do you know that step came out right? It forces into words a criterion that until then lived in habit. Only then is it written, one page per process, in the vocabulary the operation actually uses rather than the vocabulary of a manual.

The test is what separates this day from a drafting exercise. Each document is handed to someone in the room who does not know that work and who tries to follow it unaided. Wherever they stop, the document is corrected. That correction is the real product of the day, because a procedure only its author can follow is not a procedure. It is a note.

The close settles what usually goes unsettled: where each document lives, who updates it when the process changes, and which processes are still missing, in what order and under whose name. Each participant leaves with processes of their own written down and tested by an outsider, the capture template they used during the day ready for the ones still pending, and that prioritized list in hand. A procedure someone else can follow unaided is the smallest unit ALUD works with in Operations, and it is often the piece missing when a company tries to measure, delegate or reorganize a function.

What participants learn

• Capture a process by watching it performed instead of reconstructing it from memory.
• Identify the trigger, the inputs, the decisions and the completion signal of each step.
• Write down the exceptions the person running the work resolves without noticing.
• Draft a one-page procedure in the operation's own vocabulary.
• Test the document with someone who does not know the job and correct what failed.

Agenda

1. 01Why the process people describe is not the process people run
2. 02Observing before drafting: what to watch and what to write down
3. 03Trigger, inputs and the conditions for starting
4. 04Decisions and criteria: writing down what is currently decided by experience
5. 05Exceptions, and the cases the person resolving them does not consider exceptions
6. 06The completion signal: how you know the step was done properly
7. 07The one-page format: level of detail, vocabulary and length
8. 08The test with a reader who does not know the work
9. 09Where the document lives and who updates it when the process changes

What the organization leaves with

• Between two and four of your company's processes documented on one page each.
• Every document tested by someone outside the process, with the corrections applied.
• A reusable capture template for the processes still waiting to be written.
• A prioritized list of the processes still undocumented, with an owner assigned to each.