A process audit sounds straightforward: look at how work moves, find what is slow or broken, write it down. In practice, the hard part is not the analysis. It is getting to the real process rather than the one people think they are supposed to describe. This guide covers how we approach that problem.
Start with the people doing the work, not the documentation ¶
The documentation tells you what someone intended the process to be, usually two or three versions ago. The people doing the work know what it actually is. Start by asking them to walk you through a normal day, step by step. Do not prompt them with the documented flow. Let them describe it in their own order. The places where their description diverges from the documentation are the places worth examining.
Ask about the non-normal days ¶
Once you have the normal-day description, ask what happens when something goes wrong. What do they do when the system is slow, when a colleague is out, when a deadline moves? The workarounds people have built for non-normal days are often the most revealing part of the audit. They show you where the official process is fragile and what the team has quietly built to compensate.
Map the actual handoffs, not the org chart ¶
Handoffs are where most process problems live. A task moves from one person or team to another, and in that gap, things get lost, delayed, or duplicated. Map every handoff explicitly: who sends, who receives, what format, what the expected turnaround is, and what actually happens when the turnaround is missed. You will almost always find at least one handoff that nobody officially owns.
Quantify the cost of the stall ¶
A process problem that cannot be connected to a cost is hard to prioritise. For each issue you find, try to estimate the cost: time lost per week, error rate, rework hours, or customer impact. You do not need precision. A rough order of magnitude is enough to help the organisation decide what to fix first.
Write the report for the person who has to act on it ¶
The final report should be readable by the person who will implement the changes, not just the person who commissioned the audit. That means plain language, a clear priority order, and specific enough recommendations that someone can start on Monday morning without needing to ask a follow-up question. If a recommendation requires a decision before it can be acted on, say so explicitly.
A good process audit is uncomfortable to read. If the report confirms everything the organisation already believed, it probably did not go deep enough. The goal is an honest map, not a reassuring one.