A Process Everyone Hates Keeps Getting Skipped: Decision Tree
Why this matters
A process the whole crew quietly skips is not a discipline problem, it is a design problem wearing a discipline costume. When one person cuts a corner, coach the person. When everyone cuts the same corner, the process is telling you something, and writing people up will not fix it. This tree diagnoses why a step keeps getting skipped and points you at the fix, instead of the reflex of adding another reminder to a process people already hate.
Start here: is the skipped step a safety or code step?
Before any diagnosis, sort this first.
- If the skipped step protects someone from harm or keeps you legal (lockout, verification a circuit is dead, a gas check, fall protection), stop the work until it is followed. A skipped safety step is not a process to redesign on the fly, it is a stop-work issue. You still owe yourself the diagnosis below, because a safety step that everyone skips is a badly designed safety step, but the fix happens after the immediate risk is controlled, not instead of controlling it.
- If it is an operational or paperwork step, continue down the tree.
Branch 1: does the step actually add value?
Ask what breaks if the step disappears forever. Be honest.
- If nothing breaks, the crew is right and you are wrong. The step is scar tissue, a rule added years ago for a problem that no longer exists. Kill it. People skipping a pointless step are protecting the customer's time and yours, not defying you.
- If something real breaks, the step earns its place. Move on to find out why a valuable step still gets dropped.
Branch 2: is it too slow, clumsy, or redundant?
Watch someone do the job and time the step against the payoff.
- If it takes far longer than the value it delivers, the friction is the cause. A step that costs ten minutes to prevent a rare small problem will always lose to the clock. Redesign it to be faster, or accept the risk and drop it. Do not demand heroics to run a clumsy step.
- If it asks for information the crew already entered somewhere else, redundancy is the cause. People will not type the same thing twice, and they are right not to. Remove the double entry.
Branch 3: does anyone actually know how, and why?
- If the step is unclear or was never really taught, the cause is training, not will. People skip what they are unsure how to do because doing it wrong feels worse than not doing it. Make the how obvious and reachable at the moment of work.
- If they know how but not why, the cause is missing context. A step whose purpose is invisible feels like busywork. Show the crew the callback or the near-miss the step prevents, and skipping drops on its own.
Branch 4: does the incentive fight the step?
- If the crew is rewarded for speed and the step costs time, the incentive is the real instruction and the step is just words. People do what gets counted. Fix the scoreboard, or the step loses every time.
- If the step only helps someone downstream (the office, the next tech) and costs the person doing it, you have a split-incentive problem. Make the downstream value visible, or move the step to whoever actually benefits.
The comparison
| What you find | Root cause | The fix |
|---|---|---|
| Nothing breaks without it | Scar-tissue step | Kill the step |
| Slow versus its payoff | Friction | Redesign faster or drop |
| Same info entered twice | Redundancy | Remove double entry |
| Unclear or untaught | Training gap | Teach, put the how at hand |
| Known but feels pointless | Missing why | Show what it prevents |
| Speed rewarded, step costs time | Bad incentive | Fix the scoreboard |
When to pick which
Run the branches in order, because they get progressively harder to fix and the cheap wins are near the top. Most persistently skipped steps die at Branch 1 or Branch 2: the step is either pointless or painful, and no amount of enforcement changes that. Reach for training and incentives only after you have confirmed the step is worth doing and reasonably quick to do. If you find yourself adding a third reminder to make people follow a step, stop and go back to Branch 1, you are treating a design problem as a compliance problem.
Recap
- Safety or code step, stop the work first, diagnose after.
- Adds no value, kill it.
- Too slow or redundant, redesign or remove the friction.
- Unclear or purpose-less, teach the how and show the why.
- Incentive fights it, fix the scoreboard.
References
- See related: Why People Skip a Process and What It Tells You
- See related: Killing a Broken Process Instead of Patching It
- Trade-standard practice for work-instruction design and safety compliance