Back to Insights

Problem solving

How to run an 8D that actually sticks

By the Axiom team · 15+ years in quality & compliance · 6 min read

Most 8D reports do not fail because the team did not work hard. They fail quietly, weeks later, when the same defect comes back and someone reopens a report that was marked "closed". The eight disciplines are not the problem - the way they get rushed is. Here is the method as it should be run, and the three traps that catch even experienced teams.

The eight disciplines, briefly

8D is a structured, team-based route from a symptom to a verified, permanent fix. Worked in order, it stops you jumping to a favourite solution before you understand the problem.

• D0 - Symptom & emergency response. Describe what the customer actually sees, quantify it, and take any immediate protective action.
• D1 - Team. A small, cross-functional team with real product and process knowledge, and a named leader.
• D2 - Problem description. 5W2H and an IS / IS-NOT analysis to define the problem precisely - and to define what it is not.
• D3 - Interim containment. Protect the customer now, and verify the containment is actually working.
• D4 - Root cause. Find and verify the true cause, separating why it happened from why it escaped.
• D5 - Permanent corrective actions. Choose actions that remove the verified root cause, not the symptom.
• D6 - Implement & validate. Put them into production and prove they work with data.
• D7 - Prevent recurrence. Update the systems - FMEA, control plan, standard work - and read across to similar products.
• D8 - Close & recognise. Confirm closure, capture the lesson, and credit the team.

Trap 1: jumping from symptom to solution

The most common failure is skipping the discipline of D2 and D4. Someone has a hunch, the team agrees, and the report is reverse-engineered to fit. The fix is to force a quantified problem statement and an IS / IS-NOT analysis before anyone proposes a cause. If you cannot say where the problem is not appearing, you do not yet understand where it is.

If you cannot say where the problem is not appearing, you do not yet understand where it is.

Trap 2: confusing occurrence with escape

A defect that reaches a customer has two root causes, not one. The occurrence root cause is why the defect was made. The escape root cause is why your controls did not catch it. Fix only the first and the same defect will simply escape again through the same gap. A strong D4 always answers both, and ideally a third - the systemic cause: what in the way you work allowed this to happen at all.

Verify each cause rather than asserting it. The cleanest test is to turn the suspected cause on and off: if reintroducing it reproduces the failure and removing it clears it, you have the real cause, not a plausible story.

Trap 3: closing without verifying effectiveness

"Actions implemented" is not the same as "problem solved". D6 should carry before-and-after data - defect rate, PPM, first-pass yield - over enough production to be convincing, not a single good lot. Until you have that evidence, the report stays open. This single habit is the difference between an 8D that closes once and one that gets reopened.

Make the prevention real

D7 is where an 8D pays for itself. A corrective action that lives only in the report is fragile; one that updates the PFMEA detection ranking, adds a line to the control plan, and changes the operator's standard work is built into the system. Then read across: if this failure mode is possible on one line or product, check the others before they teach you the same lesson.

Put it to work

The method is only as good as the document you run it in. A good 8D template keeps occurrence and escape separate, tracks every action with an owner and a verification, and will not let you mark D6 done without evidence. That is exactly how we built ours.