What is a root cause analysis?

The expression “root cause analysis” is an umbrella for different methods that allow us to analyse failures and fix them, or at least troubleshoot. This means that a root cause analysis isn’t one particular method but rather a set of tools that examines errors in security, manufacturing, internal processes, assets or systems.

Root cause analysis is routinely performed in many differet areas, contexts and problems — including in project management, software development, manufacturing or even healthcare — though we’ll focus on the maintenance context throughout this article.

What are the main root cause analysis tools?

There are dozens of tools to perform a root cause analysis. Each has its own advantages, disadvantages, and applications. It’s not the first time we discuss how significant analysis tools are for effective maintenance, so today we’ll highlight five tools that are particularly valuable in this field.

Needless to say, none of them are mutually exclusive. You can employ different tools according to criticality, and occasionally even use more than one at the same time.

5Ws (The 5 Whys Analysis)

Does the “six degrees of separation” theory ring a bell? (Here’s the gist: everyone in the world is 6 connections away from each other). The 5 whys analysis has a similar premise – you need to ask  “why?” 5 times until you find the root cause. For example:

Defective part? Why? ⟶  There was a manufacturing problem. ⟶  Why? ⟶  The machine malfunctioned. ⟶  Why? ⟶  Preventive maintenance failed. ⟶  Why? ⟶  It wasn’t performed this semester. ⟶  Why? ⟶  The maintenance plan did not take into account the manufacturer’s guidelines (root cause).

This tool is appropriate to solve simple failures, with low to moderate risk. It’s not advisable for more critical or complex problems, which demand a deeper understanding of cause-effect. To find the root cause of critical problems, keep reading.

Learn more about the 5 Whys Analysis here.

Root Cause Analysis Ebook

Fault-Tree Analysis

The fault-tree analysis (FTA) is a logical-deductive method to find the root cause. First, we identify a failure and describe all the failure modes. Then, according to the data, each failure mode is either validated or discarded – until we reach the root cause. In the end, it looks like a diagnosis.

Árvore de falhas

Apart from being a diagnostic tool, FTA is also useful to establish reliability and safety requirements. That’s why it is extremely valuable in the chemical, pharmaceutical, aviation, petrochemical, and nuclear industries, as well as other high-risk sectors. However, it can also have more… ordinary applications, such as debugging our own Infraspeak app.

The big disadvantage of an FTA is that each failure mode is either validated or discarded (by assigning it a logical value corresponding to either 1 or 0), which means that it doesn’t consider partial flaws. So while it is an accurate analysis tool for controlled mechanical processes, it’s not for human resources, marketing or communications.

You can read more about fault-tree analyses here

Ishikawa diagram

The Ishikawa diagram (also known as the “fishbone diagram”, for its shape) consists of organising causes and effects in a diagram, split into 6 categories, until we find the root cause. The categories are as follows: measurements, materials, personnel, environment, methods, and machines.

Diagrama de ishikawa | fish bone diagram

This root cause analysis tool highlights the relationship between the company’s different departments. As a result, it’s suitable for solving failures that don’t have a single root cause. Suppose a factory produces a defective lot after manufacturing thousands in good condition. What could have happened? Was there an issue with the raw materials? Human error during production? Why wasn’t it discarded after quality control? Is there more than one root cause to explain it? 

The Ishikawa diagram has applications in maintenance but also in marketing and management, making it extremely versatile. The “fishbone” will improve internal processes, promote team spirit and expose nonconformities. On the other hand, it can “diffuse” your attention or complicate the root cause analysis unnecessarily.


FMEA (Failure Modes and Effects Analysis) is one of the most complex tools for root cause analysis, and it’s particularly well-suited to maintenance and facility management. This analysis answers the question “what if…?”, meaning (1) what is the probability of failure, and (2) if it does happen, what will be the consequences?

FMEA analysis goes hand in hand with the asset criticality analysis (which is known as FMECA). But it’s also compatible with other tools from this list, like the FTA. It’s an appropriate root cause analysis tool to assess the impact of the failure, design contingency plans, establish cause-effect interactions, and plan improvements or programmed maintenance.


Since describing all of the failure modes requires a lot of time and effort, it’s more common in assets with higher criticality, industrial maintenance, and high-risk industries.

See here how to perform a FMEA and how to use it for maintenance.

Curious to know how FMEA compares to fault-tree analysis? Read our article about the differences between FTA and FMEA.

Data analysis

Lastly, but not any less important or effective, there’s data analysis. As the name suggests, it consists of collecting, modeling and processing information in a way that allows managers to obtain valuable insights about what is underperforming. This task becomes simpler if you’re using a CMMS or an Intelligent Maintenance Management Platform (IMMP) to streamline and manage all of the data: assets, maintenance plan and executions.

Inserting the data “religiously” into the software helps calculate indicators such as the compliance rate, planned maintenance percentage, and scheduled maintenance in a heartbeat. It also gives you a global perspective about the history of each asset and, after a failure, it may help pinpoint the exact moment when maintenance failed.

In a way, all of the methods we’ve listed depend on data analysis. So, it can (and should) be a part of any root cause analysis tool of your choosing.