The process is
not the work.

Most broken processes do not look broken in a diagram. The boxes align. The arrows point forward. Every step has a name. Then a real order arrives, a client changes the brief, or a manager goes on leave—and the neat sequence comes apart.

This is not a case against process maps. A map helps a team see the same thing at once. The trouble starts when the map becomes a claim about how work happens, rather than a prompt to inspect it. A formal process records the intended path. Work also contains judgment, memory, favors, interruptions, and small repairs. Those parts rarely make it into a box, yet they often keep the whole system moving.

Inspect each departure

A useful review does not begin with “What are the steps?” Begin with “Where does this become hard?” Ask the person doing the work to show the last three cases, not an ideal example. Look for the point where an email replaces the system, where a spreadsheet appears, or where someone walks across the room to settle a doubt. These acts are part of the process and belong in the review.

Exceptions tell you more than the normal case. The normal case tells you what the system can already handle. An exception shows you where a rule lacks range, an input arrives late, or no one accepts the task. Track exceptions for two weeks and group them by cause. A short list will often explain most delays.

Do not ask whether people follow the process. Ask what staff must repair after following it.

Make handoffs visible

Work slows down between roles. One person believes a task has left their desk; the next does not yet see it as theirs. No one works on it during that gap. Teams tend to add alerts, status fields, and meetings. These steps may add work without making one person responsible.

Define each handoff with three facts: what must be true before the work moves, who accepts it, and how both people know acceptance took place. “Send to finance” is an action. “Finance has accepted a complete request” is a state. That small change makes queues easier to see and disputes easier to solve.

Design for judgment

Standard work matters when variation adds no value. A clear template for an invoice, a test for a release, or a checklist for opening a site can prevent cheap mistakes. But rules become harmful when they try to replace judgment in work that needs judgment. People then choose between serving the customer and obeying the system. Most will serve the customer and hide the workaround.

Separate fixed rules from guided choices. Fixed rules protect safety, law, money, or a hard promise. Guided choices help a trained person weigh context. Write down the aim, the bounds, and one or two examples of a sound choice. Then let the owner decide. This keeps control where failure costs most and leaves room for skill everywhere else.

Measure the result, not the ritual

Process measures often reward visible activity: forms filled, calls made, tickets closed. These counts are easy to gather and easy to game. Pair them with a result that matters to the next person in line. Did the request arrive complete? Did the client need to ask again? Did the fix hold for thirty days? A good measure makes the purpose of the work hard to miss.

Use fewer measures than you think you need. One measure for speed, one for quality, and one for demand will reveal a great deal. Review the trend with the people who do the work. When a number moves, ask what changed in the system before asking who changed their behavior. Blame makes data less true. Curiosity makes it more useful.

Review the process often

A process records a current agreement. Give it an owner, a review date, and a plain way for anyone to report a problem. Update it after real work proves that a better method exists. Remove rules that no longer prevent harm. The best process is not the most detailed. It uses the fewest shared rules needed to help people deliver a sound result when real work differs from the diagram.