7.3 Root Cause Analysis (RCA), Fishbone, and 5 Whys

7.3 Root Cause Analysis (RCA), Fishbone, and 5 Whys

Overview of Root Cause Analysis (RCA)

Root Cause Analysis (RCA) is a structured problem-solving and risk evaluation methodology aimed at identifying the fundamental, underlying causes of adverse events, operational failures, or identified risks. While RCA is most frequently performed reactively following a major incident or near-miss, ISO 31000:2018 and IEC 31010:2019 emphasize its proactive application: analyzing historical failure patterns to prevent future recurrence.

A fundamental principle of RCA is distinguishing between symptoms, intermediate causes, and root causes:

• Symptom: The visible manifestation or immediate trigger of an incident (e.g., an automated server shutdown or a pipeline leak).
• Intermediate Cause: The physical or technical failure mode directly leading to the symptom (e.g., server overheating due to cooling fan motor burn-out).
• Root Cause: The underlying systemic, procedural, governance, or organizational deficiency that allowed the intermediate cause to occur and go undetected (e.g., lack of preventative maintenance schedules due to inadequate budget allocation and missing supervisory oversight).

Treating symptoms provides temporary relief but leaves the system vulnerable to identical failures. RCA ensures that risk treatment controls target systemic vulnerabilities.

+-----------------------------------------------------------------------+
|                      THE CAUSAL CHAIN IN RCA                          |
+-----------------------------------------------------------------------+
  [Symptom / Event]       --> Customer Data Outage
         |
         v
  [Direct Cause]          --> Database Storage Volume Exceeded Capacity
         |
         v
  [Intermediate Cause]   --> Log Rotation Script Failed to Execute
         |
         v
  [Root Cause (Systemic)] --> Lack of Automated Storage Monitoring &
                              Absence of Documented SOP for Disk Alerts

---

1. Ishikawa / Fishbone (Cause-and-Effect) Diagrams

Developed by Kaoru Ishikawa, the Fishbone Diagram (also called a Cause-and-Effect diagram) is a graphical technique used to organize potential contributing factors of a specific problem or risk event into structured categories.

Structural Anatomy of a Fishbone Diagram

• The Head: A box at the far right containing the clear problem statement or undesirable event (e.g., "Batch Contamination in Line 3").
• The Spine: A central horizontal line pointing to the problem statement.
• Primary Ribs (Categories): Major diagonal lines branching off the spine representing core cause categories.
• Secondary / Tertiary Bones: Smaller sub-branches detailing specific contributing factors stemming from each primary category.

  Category 1 (Manpower)     Category 2 (Machine)     Category 3 (Method)
           \                         \                        \
            \                         \                        \
-------------+-------------------------+------------------------+-----> [ PROBLEM STATEMENT ]
            /                         /                        /
           /                         /                        /
  Category 4 (Material)     Category 5 (Measurement)  Category 6 (Environment)

Standard Categorization Frameworks: 6Ms vs. 4Ps

To ensure exhaustive investigation, analysts use standardized category frameworks tailored to their operational domain:

The 6Ms Framework (Engineering, Manufacturing, & Technical Systems)

1. Manpower (People): Personnel qualifications, fatigue, training adequacy, staffing levels, and human error factors.
2. Machine (Equipment): Hardware integrity, tool calibration, machinery wear, software bugs, and physical infrastructure failures.
3. Method (Process): Standard operating procedures (SOPs), work instructions, execution protocols, and process design flaws.
4. Material: Raw material quality, component specifications, vendor consistency, and supply chain inputs.
5. Measurement: Sensor accuracy, inspection criteria, metrics, calibration drift, and audit sampling methods.
6. Mother Nature (Environment): Ambient temperature, humidity, vibration, lighting, weather extremes, and workplace ergonomics.

The 4Ps / 8Ps Framework (Service, Healthcare, & Corporate Operations)

For service, administrative, or software environments, the 6Ms are often adapted to the 4Ps:

• Policies: Inadequate corporate governance, conflicting incentives, or absent compliance mandates.
• Procedures: Poorly documented workflows, redundant approvals, or uncoordinated handoffs.
• People: Lack of training, role ambiguity, or communication breakdowns.
• Plant / Technology: Software platform instability, inadequate IT infrastructure, or poor physical facility layout.

---

2. The 5 Whys Methodology

The 5 Whys technique is an iterative interrogative method developed by Sakichi Toyoda for the Toyota Production System. It explores the cause-and-effect relationships underlying a specific problem by repeatedly asking the question "Why?"

Execution Rules and Best Practices

1. Ground Each Step in Empirical Fact: Each answer must reflect verifiable evidence rather than speculation or assumption.
2. Target Systemic Processes, Not People: Inquiries must focus on process deficiencies, control gaps, and organizational safeguards. Personal blame creates defensive reporting and obscures root causes.
3. Flexibility in Iteration: The number "5" is a rule of thumb. Simple issues may reach a root cause in 3 Whys; complex organizational failures may require 7 or 8 Whys.
4. Stop at Actionable Control Points: Questioning stops when the team identifies an underlying cause that is within the organization's control to change and where fixing it prevents recurrence.

Example 5 Whys Incident Investigation

• Problem Statement: Critical customer billing data was corrupted during a weekend software release.
• Why 1?: Why was data corrupted? -> The database migration script failed mid-execution.
• Why 2?: Why did the script fail mid-execution? -> It timed out after exceeding the maximum memory limit.
• Why 3?: Why did it exceed the memory limit? -> The script was tested against a small staging database rather than a production-scale dataset.
• Why 4?: Why was it not tested against a production-scale dataset? -> The staging environment lacks data replication capabilities to mirror production volume.
• Why 5?: Why does staging lack data replication capabilities? -> (Root Cause) IT infrastructure guidelines do not mandate production-capacity parity for staging environments prior to major deployment approvals.

---

Comparison of RCA Tools

+---------------------------------------------------------------------------------------------------+
|                                    RCA TOOLING COMPARISON                                         |
+------------------+------------------------+-----------------------+-------------------------------+
| Methodology      | Analytical Structure   | Primary Application   | Key Limitations               |
+------------------+------------------------+-----------------------+-------------------------------+
| Fishbone Diagram | Multi-branch categorical| Complex incidents with| Can become cluttered; does    |
| (Ishikawa)       | cause mapping (6Ms/4Ps)| multiple contributing | not explicitly show linear    |
|                  |                        | physical/human factors| sequential causation          |
| 5 Whys           | Linear sequential      | Single-path failure   | Susceptible to confirmation   |
|                  | cause-and-effect chain | modes & rapid incident| post-mortems          | at superficial human error    |
+------------------+------------------------+-----------------------+-------------------------------+

---

Integration with ISO 31000 Risk Treatment (CAPA)

Under ISO 31000:2018, RCA findings directly feed into Corrective and Preventive Actions (CAPA) and risk register updates. Once a root cause is confirmed, risk treatment plans must be formulated to either:

• Eliminate the risk source (e.g., revising IT deployment standards to require staging parity).
• Change the likelihood of recurrence by implementing automated monitoring safeguards.
• Update risk criteria and controls across similar operational processes to prevent cross-functional failures.