Process Map on One Page

A process map drawn in a meeting is a drawing of what people believe the process is. It is usually right about the sequence and wrong about everything that decides how long the work takes, because the two things that decide that — waiting, and the steps nobody mentions — are exactly what a meeting will not surface.

This template treats the map as the deliverable rather than as a step toward one. One page, and every step carries both its touch time and the wait sitting in front of it.

Why this exists

Record only touch time and you will optimize the wrong tenth of the process. Most business processes are mostly waiting: in a queue, in an inbox, for a signature, for the overnight batch. Speed up the typing and you have improved a small share of elapsed time, which is how a project delivers a real efficiency and an invisible result. The people who live in the process will tell you nothing changed, and they will be right.

So record both, per step, and put the arithmetic on the page. Total wait divided by total touch is the finding. The step list is context for it.

The second thing a meeting will not give you is the undocumented work — the spreadsheet somebody keeps on the side, the standing Thursday check with a colleague, the re-typing between two screens, the personal folder of saved replies. These are missing from every official map, and not because anyone is hiding them. They do not register as steps. They register as “just what you do.”

You get them by changing the question. Not “what is the process,” which returns a summary, but “walk me through the last three real ones, including the one that went badly.” A summary is a belief. Three instances are evidence, and the bad one is where the map is.

How to use it

Map the path the work actually took, not the approved path. When those differ, the difference is the deliverable — lead with it rather than burying it in a footnote.

• Interview the person who does the work, at their desk, with the screen open. Ask what they did between receiving it and sending it.
• Interview two people who do it differently, not the one who does it best. What varies between them is where the process is genuinely undefined, and that is where an automation will break.
• At every handoff, record what the receiver had to go and find. Handoffs that arrive incomplete generate most of the wait.
• Count re-entries: how often work comes back to an earlier step. The re-entered step is the constraint. The slow step is usually just slow.

Hold it to one page and roughly twelve to fifteen steps. That is not a formatting preference, it is an altitude control. If it will not fit, you are mapping keystrokes, and a map of keystrokes cannot be read by the person who has to approve the change.

Where it goes wrong

A map with no loop back to an earlier step and no wait longer than an hour is not a map of a process. It is a map of an interview with a manager. Go back to the desk.

The map is also a snapshot, and processes vary by person, by volume and by season. Date it and write the volume on it. A map made in the quiet month will not describe the close, and the close is when the process breaks.

Last, and this is the one people resist: do not map a process you are about to delete. Mapping creates attachment to the shape of the thing. You spend two days understanding the twelve steps, and then the conversation becomes which of the twelve to automate — when the honest answer was that the entire path exists to service a form nobody reads any more. Ask what would happen if the process simply stopped, and ask it before you spend a page describing it.