Root Cause Analysis

Root Cause Analysis is a systematic problem-solving method designed to identify the underlying cause of an event or issue. Originally developed in the fields of science and engineering, it is now applied across numerous disciplines including information technology, telecommunications, manufacturing and industrial process control, aviation, rail transport, and accident analysis in nuclear facilities. RCA is rooted in the quality management movement. Japanese quality expert Kaoru Ishikawa developed the cause-and-effect (Fishbone) diagram in the 1960s. Similarly, the “Five Whys” technique, used by Toyota’s founder Sakichi Toyoda and manager Taiichi Ohno (analyzing problems by repeatedly asking “why?” to drill down to the root), is also considered a precursor to RCA. Over time, with contributions from Deming and other quality pioneers, RCA evolved into a standard method in industry and engineering projects by the end of the 20th century.

Primary Objectives and Function

The primary goal of root cause analysis is to identify the true underlying causes of a problem or failure in order to develop lasting solutions that prevent recurrence. This process deliberately avoids blaming individuals or groups and instead focuses on uncovering systemic and procedural deficiencies. For example, in healthcare, RCA is mandated by institutions such as the Joint Commission with the aim of identifying the root causes of medical errors and intervening at the system level to enhance patient safety. According to PSNet, RCA’s ultimate objective is to eliminate latent error sources and prevent similar incidents from recurring. Therefore, RCA relies on a systematic analysis that answers “how and why did this event occur?” rather than merely addressing surface symptoms.

Engineering Applications

In project management, RCA is used to identify fundamental issues affecting project performance. Factors contributing to delays, cost overruns, or quality failures are analyzed step by step, with findings forming the basis for corrective action planning. According to the PMI guide, RCA enables the definition of “initial conditions of an undesirable condition or event” and identifies steps to eliminate them. Similarly in engineering projects, RCA helps determine root causes of faulty products or processes using tools such as fishbone diagrams. For instance, a project engineer distinguishes between a symptom and a true cause by asking whether a customer complaint reflects an effect or a root issue, thereby focusing analysis on the actual root cause. In short, in project management, RCA is a multidisciplinary analytical process designed to develop comprehensive solutions that prevent problem recurrence.

Interdisciplinary Application Areas

Root cause analysis is used not only in engineering but also in healthcare, software development, and quality management. In healthcare services, RCA applications are mandatory for investigating serious errors and improving patient safety. In software development, RCA helps uncover the root causes of application failures, aiding improvements in product design, testing processes, and overall software quality. For example, when analyzing a software crash, the RCA team may identify an inadequate error handling mechanism as the root cause. In quality management and manufacturing, RCA is routinely used to address production defects and process nonconformities. In industrial process control, RCA is employed in chemical or manufacturing plants to analyze causes of production errors and ensure quality control. Additionally, ISO 9001 quality management standard requires root cause analysis to prevent recurrence of nonconformities. Thus, as an interdisciplinary tool, RCA plays a key role in resolving recurring problems in projects, hospital management, software systems, and quality systems.

Tools and Techniques Used in Root Cause Analysis

Root cause analysis is supported by various techniques and tools, including Five Whys, Fishbone (Ishikawa) Diagram, and Fault Modes and Effects Analysis (FMEA), as well as Pareto analysis, Fault Tree Analysis, and others.

Five Whys Analysis

• Definition: A simple technique that involves asking “why?” five times in succession to analyze a problem. This method aims to uncover a chain of contributing causes and ultimately identify the true root cause.
• Application: Particularly suited for simple or moderately complex issues such as production defects, equipment failures, or process interruptions.
• Advantage: Provides rapid and practical analysis; easily applied by frontline staff.
• Limitation: May be insufficient in complex systems where multiple root causes exist and reducing them to a single cause oversimplifies the situation.

Fishbone Diagram (Ishikawa / Cause-and-Effect Diagram)

• Definition: Classifies all potential causes of a problem under major categories: People, Machine, Method, Material, Environment, and Measurement. Developed by Kaoru Ishikawa, this tool visually represents numerous possible causes of a problem under categorical branches. The fishbone diagram systematically examines factors such as people, machines, and methods by organizing brainstorming session outputs.
• Application: Preferred for multidimensional analyses such as quality issues, process deviations, and customer complaints.
• Advantage: Provides visual clarity through brainstorming and group work; establishes detailed cause-and-effect relationships.
• Limitation: Causes may remain too general; does not include quantitative analysis.

Fault Modes and Effects Analysis (FMEA)

• Definition: Evaluates potential failure modes, their effects, and likelihood of occurrence to calculate a Risk Priority Number (RPN). It examines possible failure modes and their consequences before a product or process is finalized. FMEA determines which failure modes require priority attention by calculating RPN based on severity, occurrence, and detectability. This enables engineers to anticipate potential failures and correct system designs proactively. Other RCA methods with similar objectives include Fault Tree Analysis, which traces causes of a failure backward through a hierarchical structure, and Pareto Analysis, which ranks problems by importance.
• Application: Used in high-safety industries such as aerospace, automotive, healthcare, and defense.
• Advantage: Enables proactive risk assessment and guides design or process changes before implementation.
• Limitation: Subjective assignment of numerical values can influence results.

Pareto Analysis

• Definition: Based on the 80/20 rule, which assumes that 80% of problems typically stem from 20% of root causes.
• Application: Ranks fault categories to identify the most frequently occurring problems.
• Advantage: Enables prioritization; helps allocate time and resources more effectively.
• Limitation: Focuses only on frequency and does not provide deep analysis of root causes.

Fault Tree Analysis (FTA)

• Definition: Analyzes potential causes graphically starting from a top event, using logical gates (AND/OR) to trace downward.
• Application: Used in failure investigations of high-safety systems such as nuclear energy and aviation.
• Advantage: Shows combinations of causes through logical modeling.
• Limitation: Complex structure may require expertise and software support.

5W2H Method

• Definition: Conducts detailed analysis by answering questions: What? Where? When? Who? Why? How? How much?
• Application: Used in process improvement initiatives and problem analysis in service sectors.
• Advantage: Evaluates all dimensions of an event holistically.
• Limitation: May introduce subjectivity when working with ambiguous data.

Gemba Analysis

• Definition: Gemba, meaning “real place” in Japanese, refers to direct observation at the location where the problem occurs.
• Application: Used in production, maintenance, and process engineering to identify problems on-site.
• Advantage: Based on actual data; reduces assumptions.
• Limitation: Risk of bias depending on the observer’s perspective.

Relations Diagram

• Definition: Visually illustrates how multiple factors influence each other through complex interrelationships.
• Application: Used in sociotechnical systems, policy analysis, and multi-factor decision environments.
• Advantage: Encourages systems thinking.
• Limitation: May show correlations rather than causation.

Implementation Steps

The application of RCA typically involves the following stages: First, the problem is clearly and precisely defined. Then, all relevant evidence is collected: records, reports, witness statements, and an event timeline are prepared. A multidisciplinary team is assembled to approach the problem from multiple perspectives. Based on the gathered data, cause-and-effect relationships are mapped. For example, each identified “problem statement” is questioned: “Is this a cause or an effect?” In this phase, successive “why?” questions are asked to trace the chain of causes backward. The most probable root cause(s) are highlighted and validated, after which solution proposals are developed. Solutions identified in the RCA report typically focus on eliminating the root causes directly or strengthening weak defenses. Neutrality and data-driven analysis are essential throughout the process; bias or hindsight bias must be avoided. Open communication within the team is critical to ensure participants can voice opinions without fear. According to the PMI procedure guide, similar statements are merged, redundant records are removed, and the chain of relationships among problems is visualized using graphical methods such as fishbone diagrams. Finally, corrective and preventive actions are implemented and their effectiveness monitored. Critically, follow-up mechanisms and feedback systems must be established after implementation; otherwise, lessons learned will not be adequately disseminated.

Starting the risk management process effectively in projects is critical for long-term success. Conducting a comprehensive risk assessment at the outset helps identify potential threats early and engage stakeholders in the process. However, the real challenge lies not merely in listing risks but in transforming this information into sustainable risk response strategies.

In many projects, risk analysis is viewed only as a mandatory activity to be completed during the planning phase, losing its relevance as the project progresses. Even the most well-intentioned teams often document risks but fail to develop sufficiently detailed action plans for managing them. In such cases, the team may become a structure that recognizes threats but does not know how to act on them.

Often, the risk response plans developed contain abstract and general statements such as “we will do our best to prevent the issue.” If the problem occurs, measures such as staying within budget and schedule or reducing project scope are proposed. Such statements are far from effective governance. At this point, the Root Cause Analysis (RCA) method, long used in industrial safety to analyze the causes of accidents, can be adapted proactively. This enables the development of more concrete risk definitions and targeted solution strategies. This approach can be applied throughout all stages of risk management—identification, analysis, evaluation, and response planning—to create a more effective process.

Traditional Approach

The root cause analysis method, long used in industrial safety to analyze accidents, aims to systematically uncover the causes of events. In this approach, not only the direct events leading to an accident but also the underlying conditions that enabled those events are considered. For example, suppose a worker suffers vision loss due to a chemical leak. Initial investigation reveals that the chemical spilled because a maintenance worker entered the area and collided with the worker. However, the analysis does not stop there. Why was the worker not wearing proper protective equipment? Was safety training provided? Are procedures being monitored? Why did the maintenance worker enter the hazardous area? If a warning light was present, why was it ignored?

These types of questions are pursued by repeatedly asking “why?” until root causes are reached. For instance, recurring categories such as “inadequate training,” “lack of oversight,” or “noncompliance with existing rules” emerge. At this point, solution proposals can be developed: updating policies, enhancing training, strengthening monitoring mechanisms, and so on.

This visual represents a schematic of the traditional root cause analysis. The undesirable event at the top forms the center of the analysis process. Each lower layer lists factors contributing to the event. These factors are categorized as direct causes (C), conditions that enabled the event (P), and elements representing critical information (I).

Each box connects downward to the answer of the question “Why did this occur?” Thus, the chain of causes is mapped in a layered structure. If a box represents a desired condition, it can be marked as “no corrective action needed (N/C).” In other cases, tracing cause-and-effect relationships reveals underlying systemic weaknesses.

Root Cause Projection

This logic of root cause analysis can also be applied not to past events but to potential future risks. In this case, the technique is called Root Cause Projection. While traditional RCA examines past events to prevent recurrence, root cause projection aims to identify underlying causes of possible risks now and develop effective preventive measures.

In this approach, the project team imagines a potential negative scenario that could occur in the future. For example, suppose there is a risk that a third-party system component will not be delivered on time, causing the product to miss its market launch date. This risk could lead to serious consequences such as revenue loss.

The team poses the question “Why could this happen?” to uncover sub-causes: supplier delivery delay, faulty system delivery, communication gaps, exhaustion of the technical team, and so on. For each primary cause, further sub-causes are explored. For instance, “Why does the supplier delay?” → Did they receive requirements late? Did they prioritize other work? Did they face material shortages in the supply chain?

Unlike traditional methods, here the analysis is not based on an actual event but on a potential risk scenario that has not yet occurred. The top box contains a possible negative scenario (e.g., “11th-hour crisis”). The analyzing team begins discussing how this adverse situation could arise. Each cause is written in lower boxes as answers to the question “Why could this happen?” For example, potential factors such as supplier delay, faulty system delivery, or communication breakdown are identified.

This visual shows how primary causes identified in the root cause projection process are further analyzed. Each primary cause is probed with the “why?” question, expanding into new sub-boxes. This deepens the causal network. For example, under the box “Supplier delivered late,” sub-causes such as unmet requirements not communicated on time, supply chain disruptions, or competing priority projects may be listed. These causes, representing different risk roots, lead to the formation of additional “sub-risk” layers.

Difference of Root Cause Projection

In traditional root cause analysis, causes are typically linked by a logical “AND” relationship—meaning the event occurs only when multiple causes coincide simultaneously. However, in future-oriented projections, “OR” relationships must also be considered. Multiple independent causes can trigger risk in different ways. Therefore, during analysis, it is essential to distinguish whether causes are dependent or independent.

This visual helps distinguish logical relationships between causes. In traditional root cause analysis, most causes are interdependent—meaning the event occurs only when all causes happen together (logical AND). However, in future-oriented analysis, some causes may act independently as triggering factors (logical OR). Independent causes, having separate probabilities of occurrence, must be addressed differently.

Application Scenario

In a project, a critical subsystem is expected to be delivered by an external supplier. The project plan and schedule are clear, but the team has identified a “delay” risk. In this case, the team can initiate analysis by simulating a scenario such as “serious problems occur one week before the delivery date.”

Why could this crisis occur?

• The supplier delivers late.
• The system is faulty.
• The team is exhausted.
• Problems were not reported to management in time.

For each of these, the “why?” question is asked again to elaborate the risk tree. The branches of this tree will guide the necessary actions: early communication of requirements, more frequent communication with the supplier, intermediate control points, personnel reinforcement, and so on.