Quality & Continuous Improvement

Root Cause Analysis in Quality: How to Do It

By Claudia · · 7 min read

Plant team drawing a fishbone diagram on a glass wall

Root cause analysis in quality: how to do it

When something goes wrong on the plant floor — a contamination, a process deviation, a customer complaint — the first instinct is usually to fix the visible problem as fast as possible. But without a rigorous root cause analysis, that same problem resurfaces weeks or months later, sometimes with a bigger impact. Root cause analysis is the methodology that lets you look past the symptom and find the real origin of the failure, so the corrective action actually lasts instead of just patching things over.

What root cause analysis is, and why a corrective action without it doesn't last

Root cause analysis (RCA) is a structured process that aims to identify the factor or combination of factors that triggered a non-conformity. It's not about assigning blame or superficially documenting what happened — it's about understanding the mechanism that set off the problem.

The difference between a corrective action that works and one that fails almost always comes down to this step. If a batch shows out-of-limit pathogen levels and the response is simply to discard it and step up cleaning for a week — without investigating why the usual controls failed — the risk stays dormant. As set out in Regulation (EC) 852/2004 on the hygiene of foodstuffs (Regulation [EC] 852/2004, 2004), food business operators must maintain procedures based on HACCP principles on a permanent, up-to-date basis — which means reviewing and fixing the system when controls fail, not just the one-off result.

A corrective action without root cause analysis has an expiration date. The problem comes back because the condition that caused it is still present in the system.

The most-used tools on the plant floor: the 5 whys and the Ishikawa diagram, with food-industry examples

There are several methodologies for running a root cause analysis in the food industry. The two most widely used on the plant floor, for their simplicity and effectiveness, are the 5 whys method and the Ishikawa diagram.

The 5 whys method involves asking "why?" repeatedly until you reach the root cause. There's no magic number — it might take three questions or seven, though five is usually enough for most cases in industrial settings. Here's a food-industry example:

  • Problem detected: Customer complaint about a foreign body (plastic fragment) in packaged product.
  • Why? Because the metal detector didn't identify the fragment.
  • Why? Because the fragment was plastic and the equipment was only calibrated for ferrous metals.
  • Why? Because the control point's validation didn't account for plastics as a hazard category.
  • Why? Because the HACCP plan's hazard analysis hadn't been reviewed since new packaging materials with plastic components were introduced.
  • Root cause: The management system had no procedure for reviewing the hazard analysis when materials or suppliers changed.

As you can see, the root cause isn't the metal detector — it's a systemic failure in change management. Without going that deep, any corrective action would have been incomplete.

The Ishikawa diagram — also called a fishbone diagram or cause-and-effect diagram — is especially useful when a problem could have several simultaneous causes. It's built by identifying six categories of factors that commonly influence industrial processes: Machinery, Manpower, Method, Materials, Environment, and Measurement (the "6 Ms").

For example, faced with a temperature deviation in a cold room, the diagram lets you explore at once whether the failure came from the equipment (a faulty compressor), the people (a door opened outside protocol), the method (insufficient logging frequency), the materials (overloading that blocks airflow), the environment (extreme outdoor temperature), or the measurement (an uncalibrated probe). This broad view stops the quality team from fixating on only the most obvious cause.

Both tools work well together: the Ishikawa diagram helps map out the space of possible causes, and the 5 whys let you dig deeper into each branch until you hit the root.

The common mistake: stopping at the first symptom instead of following through to the real cause

The most frequent mistake in root cause analysis for quality issues is confusing the immediate cause with the root cause. The immediate cause is what directly produced the problem; the root cause is the underlying condition that allowed that immediate cause to exist.

In the example above, "the detector didn't work" is an immediate cause. "There was no review procedure for changes" is the root cause. Acting only on the immediate cause (replacing the detector) fixes the symptom but leaves the system's vulnerability intact.

This mistake has direct consequences for how effective the quality management system is. Quality teams working under standards like ISO 22000 and ISO 9001 (ISO, n.d.) know these standards require proof that corrective actions were applied to the root cause, with evidence of their effectiveness afterward. An external auditor will check exactly this: whether the analysis goes beyond the symptom.

To avoid stopping halfway, a useful practice is to ask: "If we apply this corrective action, could the same problem happen again for the same reason?" If the answer is yes, the analysis hasn't gone far enough.

How to document the analysis and link it to the corrective action it generates

Root cause analysis shouldn't just be carried out — it needs to be documented so that anyone on the team, or an auditor, can follow the thread from the issue to the corrective action and its follow-up. Incomplete documentation turns the analysis into an exercise with no traceability or evidentiary value.

A well-structured root cause analysis record should include, at minimum, the following elements:

  • Description of the issue: what happened, when, where, and what impact was detected.
  • Immediate containment: what was done at the time to limit the damage (batch hold, notification, shipment block).
  • Methodology used: note whether the 5 whys, the Ishikawa diagram, or another tool was used, and attach the analysis output.
  • Root cause identified: a clear, concise statement of the root cause, distinguished from immediate or intermediate causes.
  • Associated corrective action: description of the action, owner, deadline, and resources needed. The direct link between the analysis and the corrective action it generates is essential here, so that both records are connected in the documentation system.
  • Effectiveness verification: date and criteria used to confirm the corrective action actually worked.

Using quality software makes this traceability far easier. Compared to paper records or scattered spreadsheets, a digital platform automatically links the issue to the root cause analysis and the corrective action, assigns owners with due-date alerts, and generates follow-up reports with no extra effort. The result is a continuous improvement system that works in practice, not just on paper.

Investing time in root cause analysis is, ultimately, investing in problems not happening again. And in the food industry, where consumer safety is on the line, that investment is never optional.

References