Root Cause Analysis: A Practitioner's Guide to Solving Problems Permanently
- Mar 30, 2023
- 9 min read
Updated: Mar 27
By Allan Ung | Founder & Principal Consultant, Operational Excellence Consulting
Updated: 25 March 2026
Allan Ung is the Founder and Principal Consultant of Operational Excellence Consulting, a Singapore-based firm established in 2009. With over 30 years of experience leading operational excellence and quality transformation across manufacturing, technology, and industrial sectors — including senior roles at IBM, Microsoft, and Underwriters Laboratories — he is a Certified Management Consultant (CMC, Japan), Lean Six Sigma Black Belt, TPM Instructor, TWI Master Trainer, and former Singapore Quality Award National Assessor. He has facilitated structured problem-solving programmes for organisations including Lam Research, Panasonic, Micron, Tokyo Electron, NEC, and NileDutch.
The problem with fixing problems
Most organisations are reasonably good at responding to problems. They identify the symptom, take corrective action, and move on. The defect stops. The complaint is closed. The pressure eases.
And then, three months later, the same problem appears again. Sometimes in the same place. Sometimes somewhere else in the system. But recognisably, unmistakably, the same problem.
This pattern — the recurring problem, the repeated fix, the cycle that never quite ends — is not a sign of incompetence. It is a sign that the organisation has been solving symptoms rather than causes. The fix addressed what was visible. The root cause, which was not visible, remained untouched.
Root Cause Analysis (RCA) is the discipline of finding and eliminating that invisible driver — the true underlying cause that, if removed, prevents the problem from ever recurring.
After three decades of facilitated problem-solving work across manufacturing, technology, and operations environments, I have come to a clear view: RCA is not a tool. It is a habit of mind. The tools — and there are several excellent ones — are instruments in service of a deeper discipline: the refusal to accept the first plausible explanation as the final answer.
What root cause analysis actually means
RCA is a systematic process for identifying the underlying cause of a problem — not its symptoms, not its immediate triggers, but the fundamental condition or failure that made the problem possible in the first place.
The distinction matters enormously in practice. A symptom is what you observe. A trigger is what set the problem off on a particular occasion. A root cause is the systemic condition that, if left unchanged, will produce the same problem again regardless of how many times you address the symptom.
Consider a simple example. A machine produces defective parts. The symptom is the defect. The trigger might be an operator error on a particular shift. The root cause might be inadequate training, or a process specification that is ambiguous, or a maintenance interval that has been quietly extended beyond its designed limit. Fix the symptom and the defects stop — temporarily. Fix the root cause and they stop permanently.
The RCA process typically moves through six stages: defining the problem precisely, collecting relevant data, analysing the data to identify causal patterns, identifying the root cause, developing and implementing solutions, and verifying that those solutions have actually eliminated the problem. Each stage matters. Skipping the data collection stage and moving directly to cause identification is one of the most common — and most costly — shortcuts in problem solving.
The core RCA tools — and how to use them well
RCA is not a single technique. It is a family of complementary tools, each suited to different types of problems and different stages of the investigation. Understanding when to use which tool is as important as knowing how each one works.
The 5 Whys technique
The 5 Whys is the most widely known RCA tool — and, in my experience, the most frequently misused. The principle is straightforward: when confronted with a problem, ask "why" repeatedly, using each answer as the basis for the next question, until the root cause is reached. The name comes from the observation that five iterations of "why" is typically sufficient to move from symptom to root cause — though in practice the number varies with the complexity of the problem.
The power of the 5 Whys lies precisely in its simplicity. It is accessible to anyone, requires no specialist software, and can be applied immediately to a live problem. What makes it effective — and what most practitioners miss — is the discipline of validating each answer before proceeding to the next "why." An unvalidated answer is an assumption, and assumptions compound. A chain of five unvalidated assumptions produces a root cause that bears no relationship to reality, no matter how logically constructed it appears.
The 5 Whys works best for problems with a single causal chain. For problems with multiple interacting causes — which is the norm rather than the exception in complex manufacturing or operations environments — the Fishbone diagram is a more appropriate starting point.
The Cause and Effect (Fishbone) diagram
The Fishbone diagram, also known as the Ishikawa diagram after its creator, is a structured visual tool for mapping the potential causes of a problem across multiple causal categories. The problem sits at the head of the fish. The major cause categories branch off as bones — typically People, Process, Equipment, Materials, Management, and Environment, though these can be adapted to the specific context.
What makes the Fishbone diagram particularly valuable is its ability to prevent premature convergence. Teams under time pressure tend to reach for the most familiar or most convenient explanation. The Fishbone structure forces the team to systematically consider all major causal domains before narrowing their focus — which frequently surfaces causes that would otherwise never have been considered.
In the 8D Problem Solving workshops I have facilitated for engineering teams at Lam Research and Panasonic, the Fishbone exercise consistently generates the most productive cross-functional conversations of the entire investigation. People who rarely work together discover that the root cause of a quality problem sits squarely at the boundary between their functions — visible only when both perspectives are in the room simultaneously.
The Fishbone diagram identifies where to look. The 5 Whys drills into what it finds. Used together in sequence, they are considerably more powerful than either tool alone.
Is / Is Not analysis
Less widely known than the 5 Whys or Fishbone, the Is / Is Not analysis is one of the most practically effective problem-definition tools in the RCA toolkit — and one I return to consistently in workshop settings.
The technique works by systematically contrasting what the problem is with what it is not across a structured set of dimensions: which products are affected and which are not, which processes show the defect and which do not, which time periods or shifts or locations see the problem and which are clear. The boundaries revealed by this comparison are often the most direct pointer to the root cause available.
A defect that appears on Line A but not Line B, on the morning shift but not the afternoon shift, in products from Supplier X but not Supplier Y — that pattern of boundaries, systematically mapped, frequently makes the root cause self-evident before any formal root cause analysis has even begun.
The Pareto chart
The Pareto chart applies the 80/20 principle to problem analysis: in most situations, a small number of causes account for the majority of the problem's impact. By ranking causes or defect categories by frequency or impact and displaying them as a bar chart with a cumulative frequency line, the Pareto chart makes the prioritisation decision visual and defensible.
In RCA, the Pareto chart is most useful when there are multiple identified causes or defect types and the team needs to decide where to focus limited improvement resources. Addressing the top two or three causes in the Pareto distribution will typically deliver the majority of the available improvement — which is why the tool is particularly valuable in environments where time and resources are constrained.
How RCA connects to your broader problem-solving system
RCA does not exist in isolation. It is the analytical core of every structured problem-solving methodology — the step that separates permanent solutions from temporary patches.
In the 8D Problem Solving methodology, D4 — identify root causes and escape point — is the discipline on which the entire process depends. A weak root cause analysis at D4 produces ineffective corrective actions at D5 and D6 and a D7 recurrence prevention that addresses the wrong system.
In A3 Problem Solving, Step 5 — root cause analysis using 5 Whys and Fishbone — is the step I most often see shortchanged in workshop settings. Teams that rush through it find that their countermeasures at Step 6 feel logical but do not hold in practice. The A3 structure makes this failure visible precisely because the logic must be traceable from root cause to countermeasure on a single sheet of paper.
In the PDCA cycle, the entire Check and Act phases depend on having correctly identified the root cause during the Plan phase. Standardising a fix that addresses the wrong cause simply institutionalises the wrong practice.
The message is consistent across all frameworks: the quality of the root cause analysis is the quality of the solution.
The pitfalls that undermine RCA in practice
The tools are not difficult. What makes RCA hard is the organisational and human dynamics that push against rigorous investigation. These pitfalls appear in every industry and at every level of management.
Jumping to solutions. The single most common failure. A familiar-looking problem triggers a familiar-looking fix before any investigation has occurred. This is not problem solving — it is pattern matching. Sometimes the pattern is correct. Often it is not, and the fix addresses a previous problem's root cause rather than this one's.
Stopping at the first plausible answer. A reasonable explanation appears early in the 5 Whys chain, the team feels satisfied, and the investigation stops. Root causes that require six or seven iterations of "why" to reach remain undiscovered. The test is simple: if removing the identified cause would prevent the problem permanently, it is a root cause. If it would only reduce frequency, dig further.
Conducting RCA without the right people in the room. Root causes that live at the boundary between functions — which most serious ones do — are invisible to teams drawn from a single department. Cross-functional participation is not a facilitation preference. It is an analytical requirement.
Treating RCA as a documentation exercise. When RCA is performed to satisfy a customer corrective action request or an audit requirement rather than to genuinely understand and eliminate the problem, the quality of the investigation reflects that purpose. The form gets completed. The problem recurs.
Failing to verify the root cause before implementing the fix. A root cause is a hypothesis until it is validated. The validation test is: if we remove this cause, does the problem stop? If the team cannot answer that question with evidence, the root cause has not been confirmed.
RCA as a capability, not a project
The organisations that derive the most sustained value from Root Cause Analysis are not the ones that deploy it most frequently in response to crises. They are the ones that have built it into their daily management rhythm — where RCA thinking is applied not just to major failures but to small deviations, process anomalies, and near-misses before they escalate.
That shift — from RCA as a reactive investigation tool to RCA as a proactive operational habit — is the difference between an organisation that is perpetually firefighting and one that is genuinely improving.
The tools are accessible. The discipline required to apply them rigorously, to resist the pull toward familiar explanations, and to follow the evidence wherever it leads — that is what separates organisations that solve problems permanently from those that solve them temporarily, over and over again.
Strengthen your team's RCA capability
At Operational Excellence Consulting, I deliver customised Root Cause Analysis workshops and structured problem-solving programmes for engineering, quality, and operations teams across Singapore and the Asia-Pacific region — grounded in real operational contexts and practitioner-led from first principle to verified solution.
👉 Explore our practitioner-led RCA resources:
👉 Contact us directly or visit www.oeconsulting.com.sg
About the author
Allan Ung is the Founder and Principal Consultant of Operational Excellence Consulting, a Singapore-based management training and consulting firm established in 2009. With over 30 years of experience leading operational excellence and quality transformation in manufacturing-intensive environments, Allan's expertise spans Lean Thinking, Total Quality Management (TQM), TPM, TWI, ISO systems, and structured problem solving.
He is a Certified Management Consultant (CMC, Japan), Lean Six Sigma Black Belt, TPM Instructor (Japan Institute of Plant Maintenance), TWI Master Trainer, ISO 9001 Lead Auditor, and former Singapore Quality Award National Assessor.
During his tenure with Singapore's National Productivity Board (now Enterprise Singapore), Allan pioneered Cost of Quality and Total Quality Process initiatives that enabled companies to reduce quality costs by up to 50 percent. In senior regional and global roles at IBM, Microsoft, and Underwriters Laboratories, he led Lean deployment, quality system strengthening, and cross-border operational transformation.
Allan has facilitated structured problem-solving programmes for organisations including Lam Research, Panasonic, Micron, Tokyo Electron, NileDutch, and the Ministry of Education. He holds a Bachelor of Engineering (Mechanical Engineering) from the National University of Singapore and completed advanced consultancy training in Japan as a Colombo Plan scholar.
His philosophy: "Manufacturing excellence is achieved through disciplined systems, capable leadership, and sustained execution on the shopfloor."
Further Learning Resources
Operational Excellence Consulting offers a full catalog of facilitation‑ready training presentations and practitioner toolkits covering Lean, Design Thinking, and Operational Excellence. These resources are developed from real workshops and transformation projects, helping leaders and teams embed proven frameworks, strengthen capability, and achieve sustainable improvement.
👉 Explore the full library at: www.oeconsulting.com.sg
