Process mapping basics for work that crosses two people

Aug 22
3 min read

Updated: 4 days ago

Introduction

Internal work breaks at the joins. Not within one person's tasks, which they do reliably, but at the points where something passes from one person, team or system to another.

Process mapping exists to make those joins visible. It does not require notation, software, or a consultant, and the useful version fits on a page.

1. Process mapping basics: define where it starts and ends

Before listing anything, fix the boundaries. A process without a defined start and end expands until it describes the whole business and helps with nothing.

"From enquiry received to quote sent." "From order placed to order dispatched." "From job completed to invoice paid."

Narrow scope, clear trigger, clear finish. Most useful maps cover a stretch involving two or three people and a dozen steps.

2. Write the steps as they happen, not as intended

Map reality first. The improved version comes later and cannot be designed without knowing the current state.

That means asking the people who do the work rather than the person who designed it, and expecting differences between them. Where two people describe the same process differently, you have already found something worth fixing.

Record the informal steps too: the message someone sends to check, the second system somebody types into, the workaround everyone uses.

3. Mark every handover

Handovers are where work waits, gets lost, or gets done twice.

Draw a clear marker at each point where responsibility changes hands. For each one, note who passes, who receives, how they are notified, and what happens if the receiver is unavailable.

That last question exposes most failures. A handover that depends on someone noticing an email is a handover that fails during a busy week or a holiday.

4. Mark the decisions and who makes them

Every point where the process branches needs an owner and a criterion.

Approve or reject, standard or exception, escalate or continue. Write down who decides and on what basis.

Unowned decisions are where processes stall indefinitely — the item sits waiting because nobody is certain it is theirs to move, and everyone assumes someone else is looking at it.

5. Add times, especially waiting times

Duration turns a description into a diagnosis.

Put an approximate time on each step, and separately on each gap between steps. The gaps are usually far larger than the work, and they are invisible until written down.

A process where four hours of actual work spans six days is normal and fixable. You cannot see that without recording the waiting.

6. Keep the notation as simple as possible

Boxes for steps, arrows for flow, a different shape for decisions, a marker for handovers. That is enough.

Formal notations exist and are valuable in large organisations with specialists to maintain them. In a small business, a map that requires learning a notation is a map nobody updates.

A numbered list in a document works. The value is in the thinking, not the diagram.

7. Stop at the detail level you will maintain

The most common failure is over-specification. A map broken into forty micro-steps is accurate on the day it is made and obsolete within a month.

Aim for the level where each step is a recognisable unit of work with one owner. If a step is entirely within one person's control and never goes wrong, it does not need decomposing.

Ask whether you will update this when the process changes. If not, simplify it until you would.

8. Use it for one change, then keep it current

A map is not the deliverable. Pick the single worst problem it revealed — usually the longest wait or the handover with no notification — and fix that.

Then update the map to reflect the fix, and note the date. An out-of-date process map is actively harmful, because new staff follow it and find it wrong, after which they distrust all documentation.

Review the maps for your core processes annually, and whenever a tool or a role changes. That is sufficient, and it keeps them useful as onboarding material — which is ultimately where most of their value is realised.

Conclusion

Fix the start and end points, map what actually happens rather than the intended version, and mark every handover with its notification method and fallback.

Name the owner and criterion for each decision, record waiting times as well as work times, keep the notation simple enough to update, stop at a detail level you will maintain, and use each map to fix one problem before keeping it current.