8D vs A3 vs 5 Why: problem solving methods compared

The three methods at a glance

The key difference is purpose. An 8D report is usually an answer to a customer who wants evidence. An A3 mainly serves your own learning and alignment inside the company. 5 Why is not a process of its own but a tool used within both methods.

8D: the standard for customer complaints

The 8D method takes a team through eight consecutive disciplines: form the team, describe the problem, contain, analyse root causes, choose corrective actions, implement and validate, prevent recurrence and close. Many guides add a D0 for preparation and emergency response.

Its strength is completeness. An 8D report explicitly requires containment to protect the customer and two causes: why the defect occurred and why it was not detected. That is why many car makers and suppliers require an 8D report with fixed deadlines for complaints.

Its weakness is effort. A full 8D is too heavy for small internal problems. Teams that handle every topic as an 8D produce a lot of paper and little learning. The 8D report guide explains the structure in detail, and the free 8D report template helps you fill one in.

A3: problem solving on one sheet

The A3 report takes its name from the paper size. A single sheet holds background, current condition, target, root cause analysis, countermeasures, implementation plan and follow-up. The left side describes the problem, the right side the solution. The structure follows the PDCA cycle: plan, do, check, act.

The one-sheet limit is deliberate. It forces you to condense, to use charts instead of prose and to understand the problem before settling on a solution. An A3 is built in conversation: the owner discusses it with the people affected and with their manager until everyone shares the same view.

A3 works well for internal improvements, process deviations and topics where several departments need to be convinced. It does not replace an 8D report for customers who require a specific complaint format, because containment and the non-detection cause are not built in.

5 Why: the tool for finding the cause

With the 5 Why method the team keeps asking "why?" until it reaches a cause it can influence. Five is a guideline, not a rule. Sometimes three questions are enough, sometimes it takes seven.

• Why is the screw loose? The tightening torque was too low.
• Why was the torque too low? The screwdriver was set incorrectly.
• Why was it set incorrectly? The value was not checked after the tool change.
• Why was it not checked? The work instruction has no check after a tool change.
• Why is there no check? Tool changes were not considered in the last revision.

The method's value is its simplicity. Its limit: it follows only one path. For complex problems with several influences, combine 5 Why with an Ishikawa diagram. And apply it twice – once for occurrence and once for non-detection. The root cause analysis guide has more.

Which method when? A decision guide

1. 1

   Does a customer require a report?

   Then use 8D, in the customer's format if they prescribe one. The root cause analysis in D4 uses 5 Why or Ishikawa.

2. 2

   Is the problem internal and does it involve several departments?

   Then use A3. It creates a shared view and is a good basis for a management decision.

3. 3

   Is the problem small and the cause quick to find?

   Then 5 Why is enough, documented in the deviation or CAPA record. A separate report is not needed.

4. 4

   Is the problem relevant to safety or regulatory approval?

   Then it belongs in a formal CAPA process with risk assessment and effectiveness check, whichever method you choose.

An example: one complaint, three methods

A supplier receives a complaint: 40 of 5,000 delivered housings are missing a seal. The customer wants feedback on containment within 24 hours and the root cause analysis after ten working days.

With 8D

The team from quality, assembly and logistics blocks all stock, sorts at the customer and marks inspected housings (D3). In D4 it finds two causes: the seal feeder shifted after maintenance (occurrence), and the camera inspection did not detect missing seals on dark housings (non-detection). Both causes are confirmed in a trial. Corrective actions, effectiveness data from three weeks of production and read-across to identical lines complete the report.

With A3

Internally, the assembly manager also summarises the case on an A3: how often do feeders shift after maintenance overall? Which lines are built the same way? The A3 becomes the basis for the decision to change the maintenance instruction for all lines and add a function check after every maintenance job.

With 5 Why

Within D4 the team uses two 5 Why chains. The first ends at a maintenance instruction without a function check, the second at a camera setting that was not adjusted when dark housing variants were introduced. On its own, 5 Why would not have satisfied the customer, because containment and proof of effectiveness are missing.

Related methods

• PDCA: the basic cycle of plan, do, check, act. A3 is one way to document PDCA.
• DMAIC: the Six Sigma cycle of define, measure, analyse, improve and control. It suits data-rich problems that need statistical analysis and usually takes months.
• Ishikawa diagram: sorts possible causes into categories such as people, machine, method, material, measurement and environment. It complements 5 Why when several influences interact.
• FMEA: assesses potential failures before they happen. Findings from 8D and A3 should flow back into the FMEA.

Common mistakes in all three methods

• Solution first: the action is decided before the problem is understood, and the form is filled in to match afterwards.
• People as the cause: "operator was inattentive" is rarely the root cause. Keep asking why the system allowed the error.
• No verification: the suspected cause is never tested. A short trial saves a second complaint later.
• Training as the only action: training works when knowledge is missing. Process errors need a change to the process.
• No proof of effectiveness: without data after implementation, nobody knows whether the problem is solved.

Documentation and evidence

Standards such as ISO 9001 and IATF 16949 do not prescribe a specific method. They do require that causes of nonconformities are determined, actions are implemented and their effectiveness is reviewed, and that this is documented. IATF 16949 also requires a documented problem solving process that takes customer-specific formats into account.

Which method you choose is therefore up to you. What matters is that it is described in a procedure and that the evidence can be found. In docxpert, CAPA management covers this flow: root cause analysis, actions, deadlines and effectiveness check in one place, linked to changed documents. The CAPA process guide shows the overall flow.

In audits, an auditor rarely asks about the method but almost always about the thread. They pick a closed complaint and trace it from the report through containment, verified cause and actions to the proof of effectiveness. If one of these links is missing, it does not matter whether the report is called 8D, A3 or something else. Define the minimum content every problem solving record needs regardless of method, and sample it regularly in internal audits.