Let’s start with a scenario that illustrates the methodology behind using decision trees for root cause analysis. The scenario: one morning you notice a dark spot on your driveway where your car had been parked. You touch the liquid to see whether it’s condensation from the air conditioning or another type of fluid leaking out. Determining that it’s not water, you open the hood to see if you can find the source. First you examine the dipstick, finding that the engine isn’t low on oil. Next, you check the transmission fluid level. Finally, you check the brake fluid level. Having eliminated these potential sources of the leak, you decide to take it to a mechanic.

In essence, a decision tree uses the process of elimination on known issues to narrow down the root cause of a problem.

This article looks closer at how to use decision trees for root cause analysis, including how to create one and what to avoid. We also examine workflow considerations for using decision trees within the enterprise quality management system (EQMS), plus another application for decision trees that can simplify your processes.

What are Decision Trees?

Decision trees are tools for ruling out known issues and narrow in on the root cause of a problem, like the fluid leak. Decision trees also help determine the right course of action based on business rules or regulations.

An example would be how quickly to report a complaint to regulators based on whether the incident required medical attention.

Another example would show that after verifying clamping pressure, cooling time and temperature, you discover that the vents in the injection mold are, in fact, clogged. After a quick inspection, you determine it needs to be cleaned, after which products come out without any voids.

When to Use Decision Trees for Root Cause Analysis

A decision tree is useful for root cause analysis when you have ample historical data on previous problems. Industries with mature processes such as medical device manufacturers, use a lot of decision trees based on real-world product data.

When an issue has occurred many times before, you can design questions around previous root causes and the appropriate corrective actions.

In some cases, users may get to the end of the decision tree and determine that none of the issues raised apply to the problem. From there, you might do a 5 Why or 8D analysis. You might also go back to design, R&D, or process experts, armed with detailed information to initiate an investigation into the history of development of the process or product.

How to Build a Decision Tree

A decision tree uses a cascading set of yes or no questions based on real-world data to drive you down a specific path to the root cause. The diagram is comprised of a simple workflow that includes symptoms that point to potential causes, and corrective actions to bring the process back into conformance.

Questions should start with the issues that are highest risk or most likely to occur, moving through less likely or lower risk failures. Decision trees are built over time from historical data and subject matter expert knowledge. Failure modes identified in FMEAs can be incorporated into decision trees, for example information from:

  • Complaint records
  • Nonconformance records
  • The design history file (DHF)
  • The device master record (DMR)
  • Risks identified in failure mode and effects analysis (FMEA)

Mistakes to Avoid

The biggest mistake to avoid with decision trees is not keeping them updated. SMEs should regularly review the decision trees to make sure they’re current based on process changes. Furthermore, review FMEAs to find any impacts or modifications to update decision trees if necessary.

Decision trees are based on process and product knowledge. If that knowledge changes and you don’t update the tool, it becomes ineffective and may lead you to the wrong decision or action.

Areas of the EQMS to Leverage

Paper-based decision trees can be automated within the EQMS, providing a series of steps that leads the user through the root cause analysis process. This has the added advantage of tying related corrections to the compliance record. To ensure that decision trees remain up to date, you can also link them as action items within other processes such as FMEA and change management.

Decision trees can also direct users to appropriate actions, with questions based around regulatory requirements or business rules. The medical device industry, for instance, uses decision trees to determine reportability of complaints. See Figure 1 (below) for an example of a decision tree built into a complaint management record.

AssurX Decision Tree Workflow

Figure 1: A decision tree can guide the processor through a series of questions about a complaint upon intake. The decision tree helps review the context and data in order to identify the recommended actions (and potential issue reportability). The further down the branches of the decision tree, the more likely it is to identify the root cause. Configurable decision trees in an EQMS like AssurX help quality staff make informed decisions. (Click to open in a new window.)


The EQMS simplifies compliance with questions you can configure to each country’s reporting requirements. This structured path takes the guesswork out of reporting decisions. Again, keeping this updated with the latest regulations is critical.


Decision trees are a useful tool for root cause analysis. They are especially helpful for problems where you’ve already invested a lot of time troubleshooting. In addition, they can create consistent, logical paths for investigations. As with many quality management tools, the key to success is making sure to regularly update the tool. Doing so ensures the decision tree reflects current knowledge and understanding of product/process issues.

An EQMS makes decision trees more effective by allowing you to link them to FMEA updates, incidents, and other events. By drawing on SME knowledge and past lessons, organizations can leverage organizational knowledge throughout the problem-solving process.

Additional Reading: EQMS Implementation: How to Lead Organizational Change

About the Author: Eric Cooper is Vice President of AssurX. He is responsible for strategic oversight and execution of product development, implementation solutions, customer enablement, and technology operations of the AssurX organization. Eric oversees product roadmap execution, professional services, training services, validation services and IT operations in alignment with the AssurX company vision to design and deliver modern, world-class quality and compliance management solutions and services.