The Workflow Management Guide: Designing a Process People Will Actually Follow

Plenty of work is genuinely a list of independent items. Building a workflow around it adds ceremony without adding safety, and ceremony is what people route around. Ask three questions before designing anything:

1. 01Does the order matter? If steps can be done in any sequence, you have a checklist, not a workflow.
2. 02Can a step be skipped? If it is physically impossible to skip, it does not need enforcing.
3. 03Does skipping it hurt? A skipped step with no consequence is a step that should probably be deleted rather than enforced.

The boundary between the two is less obvious than the words suggest — task management vs workflow management works through where it actually falls.

Trace three real cases

Take three recent instances of the work — ideally one that went well, one that went badly and one ordinary one — and write down what actually happened to each, in order, with names. Three real traces will tell you more than a workshop, and they surface the steps nobody documents because "everyone knows".

Mark the handoff points

Wherever the work moves between people or teams, mark it. These are where work stops, where context is lost and where the trace usually goes vague. They are also where a recorded handover has the most value.

Mark the waits

Note every point where the work was waiting on something — a customer, an approval, a part, another team. Waits are usually the majority of elapsed time and are almost never in the written procedure, which is why the written procedure always looks faster than reality.

Find the step that gets skipped

There is nearly always exactly one, and everyone knows which it is. It is usually a check or an approval, it is usually skipped under time pressure, and it is usually the reason the bad case went badly. That step is your first candidate for enforcement.

The counter-intuitive part is that fewer enforced steps produce more compliance. A process with three hard rules and a lot of judgement is followed; a process with fifteen hard rules is circumvented, and the circumvention becomes the real process.

This is the difference between a workflow that still describes reality in six months and one that quietly becomes fiction. Every field somebody has to remember to fill in is a field that will eventually be blank, or worse, be filled in inaccurately at the end of the week.

• Acceptance instead of a start button. If accepting a task is what starts it, the start time is recorded without anyone thinking about it.
• A handover form instead of a reassign field. If the only route to change owner records what was completed and pending, that information exists for every transfer.
• A blocked state instead of a comment. "Cannot proceed because…" as a status with a reason is data; as a comment it is prose nobody can report on.
• Review as the completion action. If submitting is what requests approval, the approval record exists for everything that was completed.
• An audit entry written by the server. A log somebody has to maintain is not a log.

Once the steps are settled, work out for each one who is allowed to perform it — and, just as importantly, who is not. The rule that catches the most real problems is the simplest one: the person who did the work is not the person who signs it off. It is worth building in even when it feels bureaucratic for a small team, because the exception you would have made is exactly the case where it mattered.

Keep authority in roles and permissions rather than in the process description. A step whose permitted actors are written in a document drifts; a step whose permitted actors are a permission does not. And be wary of any system where holding a role-editing permission is effectively equivalent to holding every permission — that is a very common and very quiet way for a designed process to be bypassed.

1. 01Modelling every branch. Real processes have long tails of exceptions. Model the trunk, let people handle the tail with judgement, and accept that a workflow which covers 85% of cases is a success.
2. 02Building it before running it. A process designed in a room and configured over three weeks meets reality once, badly. Run it manually for a fortnight first; the design will change.
3. 03Making it impossible to be wrong. Every path you close is a path someone will eventually need. Prefer a recorded exception over a hard block for anything that is not genuinely dangerous.
4. 04Forgetting who maintains it. A configurable engine needs an owner who understands it. If that person leaves and nobody else can change a rule, the process is now permanent by accident.

• Read the blocked reasons. The same reason appearing repeatedly is a missing step, not a series of unlucky weeks.
• Read the handover history. Work that consistently changes hands three times has an unclear owner or a step in the wrong team.
• Compare completion time with turnaround. A large gap means the process is mostly waiting, and the waits are where to look.
• Count rejections at review. A high rejection rate usually means the intake did not capture what the reviewer needs, not that people are careless.
• Check the routines are running. A scheduled process with a poor execution rate is one nobody has told you they abandoned.

Do this quarterly rather than continuously. A workflow that changes every month teaches people not to learn it.