A Mistake Just Repeated Itself (Decision Tree)

Why this matters

There is a special sting to a mistake you already fixed showing up again. You spent the time, you thought it was handled, and here it is. That sting is actually good news, because a repeat is the clearest diagnostic you will ever get: it tells you your first fix did not hold, and the reason it did not hold is knowable. This tree walks you through why a fix fails, from the most common cause to the least, so your second fix is the last one.

Safety first: if the repeat is a safety mistake, stop the work

If the mistake that just repeated has injury potential, a missed lockout, a bad connection, an unsafe lift, do not treat this as a process puzzle first. Stop that work, make it safe, and control the hazard now. A safety mistake that has already repeated is a loud warning that the next repeat could be the one that hurts someone. Handle the hazard, then diagnose the fix failure below.

Start here: is it truly the same mistake?

Before you conclude your fix failed, confirm it is the same problem and not a look-alike.

• If the cause is genuinely the same as last time, your fix did not hold. Continue down the branches.
• If it looks similar but the cause is different, you do not have a failed fix, you have a new problem that happens to share a symptom. Diagnose it fresh. Forcing it into the old fix is how you chase your tail.

Confirm the cause matches before you assume the fix broke. Same symptom is not same cause.

Branch 1: did you fix the root cause, or a symptom?

The most common reason a fix fails is that it was never a fix. You patched the instance, not the cause.

• If your original "fix" was to redo the one job, apologize, or handle the one instance, you treated the symptom. The cause was never touched, so of course it returned.
• The move: run the cause down properly this time. (See related: The Five Whys and How to Actually Use It.) Then fix that, not the instance.

Branch 2: did the fix get captured, or did it live in your head?

The second most common failure. You found the real cause and fixed it correctly, once, in your own head or on one job, and never made it the standard.

• If the fix was never written into the workflow, a checklist line, a required field, a changed step, then it only ever applied to the one time you were paying attention. Everyone else kept doing it the old way.
• The move: turn the fix into a standard the shop actually runs. (See related: Standardizing Your Process So Every Crew Runs the Same Way.)

Branch 3: was it captured but not followed?

You wrote the fix down, and people are not doing it. That is a different problem with its own diagnosis: is it that they cannot, or that they will not?

• Do not assume defiance. A written step that gets skipped by most people is usually a broken step, not a defiant crew.
• The move: diagnose adoption separately. (See related: Process Not Followed: Retrain vs Enforce vs Revise.)

Branch 4: was it followed but too weak to work?

Sometimes the fix was captured and followed, and the problem came back anyway. That means the countermeasure was too weak for the job.

• A reminder, a "be careful," or a note in a training doc is the weakest kind of fix. It depends on human memory under pressure, which is exactly what failed the first time. If your fix was a reminder, it was always going to leak.
• The move: pick a stronger countermeasure, one that makes the mistake hard or impossible rather than just discouraged. (See related: Stopping a Recurring Problem From Recurring Again.)

Branch 5: right fix, not enough time yet?

One honest check before you tear it up. If the fix was recent, is it possible this repeat was already in flight, a job booked or started before the change landed?

• A fix needs a fair trial before you judge it failed. A repeat from a job that predates the fix is not evidence the fix is broken.
• The move: confirm the timeline. If the repeat truly post-dates the fix under real conditions, the fix failed, work branches 1 through 4. If not, give it the trial.

The recap

1. Safety mistake? Stop and make it safe first.
2. Same cause, or a look-alike? If different, diagnose fresh.
3. Did you fix a symptom instead of the cause? Fix the cause.
4. Did the fix live in your head? Standardize it.
5. Captured but skipped? Diagnose adoption, cannot vs will not.
6. Followed but weak? Pick a stronger countermeasure.
7. Too soon to tell? Give it a fair trial.

The judgment to bank: a repeat is not a reason for despair, it is a pointer to exactly which link in your fix broke. Find the link, and the second fix holds.

References

• See related: The Five Whys and How to Actually Use It; Stopping a Recurring Problem From Recurring Again; Process Not Followed: Retrain vs Enforce vs Revise
• Plan-Do-Check-Act improvement cycle, standard continuous-improvement practice
• Trade-standard practice for corrective action and root-cause analysis