The 8D problem-solving process, without the box-ticking

8D is the discipline most quality teams claim to run and few run well, usually because they collapse three different jobs (stop it, fix it, prevent it) into one. This is the full walkthrough: what every discipline from D0 to D8 is actually for, what good looks like at each step, and where each one fails.

The nine disciplines at a glance

• D0Plan & emergency response. Decide 8D is warranted; if the situation is dangerous, contain immediately, before the formal team even forms.
• D1Build the team. Cross-functional, with the process knowledge and authority to actually change things. Wrong team, wrong fix.
• D2Describe the problem. Specific and quantified: what, where, when, how many (5W2H). "Bad parts" is not a problem statement; "12% short shots on cavity 3 since the resin lot change" is.
• D3Interim containment. Stop the affected line, screen, quarantine. Protects the customer while the cause is unknown. Temporary by design.
• D4Identify & verify root cause. Not the first plausible cause: the verified one, with the evidence written down.
• D5Choose & verify corrective action. Select the permanent fix for the verified cause and prove it works before rollout.
• D6Implement & validate. Deploy it and confirm the defect rate actually dropped and stayed down, with data, not optimism.
• D7Prevent recurrence. Change the systems that allowed it: update the control plan and FMEA, error-proof the step, propagate the lesson to sister lines.
• D8Close & recognize. Document, close, and credit the team. Skipping this quietly kills the appetite for the next 8D.

Every discipline, in detail

D0 · Plan and emergency response

D0 answers two questions before anything else moves: does this problem deserve an 8D, and does anything need to happen right now. Not every defect warrants the full method; 8D earns its overhead on recurring problems, customer escapes, safety risks, and anything that will need a formal record. The second half of D0 is the emergency response action: if product or people are at risk this minute, containment starts immediately, before a team exists or a problem statement is written. A plant that waits for D3 to stop shipping a dangerous defect has misread the method.

Output: a go/no-go decision, the initial scope, and any emergency actions already taken. Failure mode: running a three-week 8D on a one-off cosmetic blemish, or the reverse, triaging a recurring field failure as routine scrap.

D1 · Build the team

The team needs three things: direct knowledge of the process where the problem lives, the data skills to test hypotheses, and the authority to change what the investigation says must change. A champion owns removal of roadblocks; a team lead owns the pace. Size matters less than coverage: a process engineer, an operator who runs the actual step, quality, and whoever controls the suspected inputs (materials, maintenance, the supplier if it comes to that).

Output: named members, named roles, a champion with authority. Failure mode: a team of managers describing a process none of them runs, or a team with perfect knowledge and zero authority, whose corrective actions die in review.

D2 · Describe the problem

D2 is where most weak 8Ds are already lost. The problem statement must be quantified and bounded: what is the defect exactly, where does it appear (line, cavity, position, lot), when did it start and does it come and go, how many units and at what rate, and how big is the gap against normal. The 5W2H frame (what, where, when, who, why detected, how, how many) forces the boundaries. Equally important is the "is / is not" contrast: which products, lines, and shifts show the problem and which, running the same process, do not. That contrast is the first piece of evidence D4 will use.

Output: a problem statement a stranger could act on, with the supporting data attached. Failure mode: "customer complaints about leaking cells" instead of "0.4% electrolyte weepage at the positive terminal seal, lines 2 and 3 only, starting May 12, absent on line 1 which uses the older crimp tooling."

D3 · Interim containment

Containment protects the customer while the cause is unknown: stop the line producing the defect and let only the lines verified clean keep running, quarantine suspect stock everywhere it sits (WIP, finished goods, in transit, at the customer), and put up a validated 100% screen so nothing unscreened ships. Containment is bridge engineering, temporary by design, with exit criteria defined the day it starts. It has its own quality bar: a screen that does not actually catch the defect is theater, so it gets validated against known-bad parts first.

Output: a containment record (scope, actions, validation, exit criteria) and a clean point separating certified from suspect stock. Failure mode: containment becoming the permanent fix, with 100% inspection still running a quarter later because D4 never finished. The full treatment is in the interim containment guide.

D4 · Identify and verify the root cause

D4 is the analytical heart. The candidate causes come from structured tools: a fishbone to enumerate them across the six Ms, 5 Whys to chase a single thread to its systemic end, a root cause tree to hang candidates under the symptoms they would explain, and cross-batch correlation when the defect comes and goes with lots. But the discipline of D4 is verification, not generation: each surviving candidate is tested against evidence, and the confirmed cause should turn the defect on and off, present when the cause is present, gone when it is removed. A cause that cannot pass that test, or at least discriminate cleanly between affected and unaffected units, is still a hypothesis.

Output: the verified root cause with its evidence, plus the documented rule-outs. Failure mode: voting on the most plausible cause in a meeting room and proceeding straight to D5. Half of failed corrective actions were aimed at an unverified cause.

D5 · Choose and verify the corrective action

D5 selects the permanent fix for the verified cause and proves it works before full rollout. Candidate actions are judged on whether they remove the cause rather than suppress the symptom, what side effects they introduce, and whether they survive production reality: a fix that depends on permanent extra vigilance is weaker than one that changes the process physics or adds an interlock. Verification at D5 is a trial: the action applied in a controlled way, with the defect demonstrably gone, before D6 commits the whole line to it.

Output: the chosen action, its trial evidence, and a rollout plan with owners. Failure mode: calling rework a corrective action. Disposing of bad parts is correction; only a change upstream is corrective. The full treatment, including verification windows, is in the corrective action guide.

D6 · Implement and validate

D6 deploys the action and validates effectiveness at production scale: the defect rate has to drop to the target and stay there through a pre-defined window (lots, days, or cycles) measured with enough volume to be statistically real, covering the conditions that vary, both shifts, all tools, multiple material lots. D6 is also when containment winds down: the exit criteria defined at D3 are checked against the validation data, and the 100% screen comes off only when the corrective action has demonstrably replaced it.

Output: validation data over the defined window, and the formal release of containment. Failure mode: declaring victory on three good lots after an intermittent defect, or leaving the screen running forever because nobody trusts the fix they did not validate.

D7 · Prevent recurrence

D7 is the discipline most 8Ds skip, and it is the one that changes the plant rather than the batch. The verified cause happened because some system allowed it: a control plan without the right characteristic, a step that depended on memory, a spec with no teeth. D7 fixes those systems: error-proof the step so the mistake is impossible rather than prohibited, update the control plan, FMEA scores, and work instructions, and deploy the lesson horizontally to every line, plant, and product that shares the same weakness. The question that scopes D7 is "where else could exactly this happen," and the answer gets the countermeasure before its own incident.

Output: systemic changes with owners, an updated FMEA, and a horizontal deployment record. Failure mode: closing at D6 under time pressure, so the same failure returns through a different door wearing a different lot number. The full treatment is in the prevent recurrence guide.

D8 · Close and recognize the team

D8 closes the loop twice. Administratively: the final 8D report is completed, the customer (if there is one) accepts it, and the investigation is filed where the next team can find it, with its signature, evidence, and outcome searchable rather than buried in a PDF. Culturally: the team gets credited, in public, by name. That is not a courtesy. The next defect will need volunteers who believe an 8D leads somewhere, and nothing recruits them like the last one being finished, acknowledged, and visibly used.

Output: the closed report, filed as searchable institutional memory, and a recognized team. Failure mode: the report nobody can find a year later, so the plant pays to solve the same problem twice.

Where teams go wrong

• Stopping at containment. Screening becomes permanent because the cause was never found. You are now paying forever to catch a defect you could have eliminated.
• Skipping verification (D4). Acting on the first guess. If you never turned the suspected cause on and off, you have a hypothesis, not a root cause.
• Confusing D5 with D7. Fixing this batch's cause without changing the system that let it happen, so it returns through a different door six months later.
• No data at D6. Declaring victory without confirming the rate dropped. Verification is a measurement, not a meeting.

Where this gets slow by hand

The bottleneck is rarely the template. It is D2 and D4. Writing a quantified problem description means pulling production records, defect logs, material lots and process traces into one timeline. Verifying root cause means correlating that defect against process drift, incoming material, and equipment history across batches. Done manually, that assembly is the multi-week part of a "two-week" 8D, and it is where weak problem statements and unverified causes slip through.