Sorry, you need to enable JavaScript to visit this website.

Root cause analysis tools

Supporting tools for conducting root cause analysis.

First published

The following tools can be useful when conducting a root cause analysis (RCA):

They can be used either to assess performance challenges or to guide meetings and interviews to help understand the root causes of a problem.

Productivity diagnostic insight tool (PDIT)

The productivity diagnostic insight tool (PDIT) is a data tool, developed within the Centre for Police Productivity, that visualises performance data through the lens of productivity.

It plots performance outputs against the inputs (for example, solve rates compared to capacity) to enable forces to identify where they are similar or different to other forces. PDIT encourages exploration to understand those similarities and differences with a view to make changes to improve performance and productivity.

PDIT currently covers:

  • residential burglary
  • robbery of personal property
  • shoplifting

PDIT is available to those who work in policing with a police.uk email address. To request access, email PDIT@college.police.uk

Event chain analysis

Event chain analysis outlines the flow of events, highlighting critical links in the process and therefore where performance ‘failure’ occurs. You can use it:

  • when trying to diagnose performance issues (to understand where issues could have happened and their effects)
  • as part of initial project planning (to understand where potential issues could happen and their potential effects)

How to use event chain analysis to diagnose causes

  • List all important events that took place during the process.
  • Identify how each event led to or influenced the following events.
  • Create a visual map showing the sequence of events and their potential links.
  • Look for any unexplained gaps in the process.
  • Consider any external events that may have affected the event chain.
  • Compare the event chain with the original project plan or expected sequence of events. Look for any differences and where they may have come from.
  • Note down main learnings, trying to understand how differences could have been predicted at the start of the project.  

You can further analyse the causes identified as part of this process using other RCA tools such as:

How to use event chain analysis to identify potential causes

You can also use event chain analysis at the start of a project, when developing corrective actions, or to inform a performance improvement plan, as any plan to improve or tackle a root issue can be affected by unexpected factors. 

  • Set out your planned actions.
  • Identify potential risk. Think about events that could interfere with these actions.
  • Map the event chain. For each potential event, note what it could lead to and how it might affect the plan.
  • Review the chains to identify the most significant risks.
  • Plan mitigations. Decide how you can reduce the likelihood or impact of those risks. 

Cause-and-effect diagrams

Cause-and-effect diagrams (Ishikawa or fishbone) visualise categories of potential causes to structure analysis. You can use this tool when you have identified a problem and want to list potential reasons why it occurred.

List the reasons under different headings. It can depend on the project, but common categories include:

  • people
  • process
  • equipment
  • environment
  • policy
An example of a cause and effect diagram using common categories: people, process, equipment, policy and environment.

How to use a cause-and-effect diagram

  • Identify the problem you want to solve (for example, long detentions in custody).
  • Agree on whether the common categories will be used or if they need to be updated for the current problem.
  • Identify potential causes of the problem that sit under the categories.  

This can be followed up with the 'five whys' method, repeatedly asking why the problem happened to identify the deeper causes.

The ‘five whys’ method

The ‘five whys’ method interrogates each issue by repeatedly asking why it has occurred, drilling down to the deeper layers of the cause of a problem. You can use this tool when you have identified an issue and want to identify a single root cause of the problem.

How to use the 'five whys' method

  • Review the definition of the issue.
  • Ask why the problem happened.
  • Keep asking why five times (why did the previous problem happen?) to help you get to the root cause of the problem.
  • Examine the root cause. Would addressing this final issue prevent the initial problem from happening again? If not, you might need to keep asking ‘why’, or focus on more actionable answers.  

The number five here is a guide. Depending on the initial problem, you might need more or fewer ‘whys’ to reach an issue that might have the desired effect if addressed.  

Keep in mind that answers should be based on data, not assumptions. You might need more information to determine whether you have reached the root cause of the problem.

Fault tree analysis

Fault tree analysis (FTA) uses logical gates to model how combinations of causes lead to specific system failures. You can use this tool when you have identified a problem and want to understand the chain of events that caused it.  

How to use fault tree analysis

  • Define the main issue. Being specific will help you better identify potential causes. Write this at the top of your tree.
  • Identify immediate causes. Understand what must have happened for the failure or issue to occur, and add this to the second level of the tree.
  • Analyse the relationship between events. Examine whether either event could have caused the main issue, or a combination of events had to take place. Use different shapes placed between events on the tree to show different types of relationships.
  • Identify potential causes of the event on the second level. Not every event must have a deeper cause. In that case, the event chain can end there, this is called a basic event.
  • Repeat until you reach the underlying causes. Continue breaking events down until you cannot identify any further immediate causes. 

Like event chain analysis, you can use FTA at the start of a project, when developing corrective actions, or during a performance improvement plan. You can do this by: 

  • identifying a risk or issue that could affect the improvement work
  • following the steps above to understand what could cause the potential issues
  • identify what could be put in place to decrease the likelihood of the issue taking place

Categories of root cause

Categorising the root causes enables the performance problem to be explored from several perspectives to ensure a complete understanding of why it occurred. You can use this tool when you have identified multiple root causes and want to understand any potential trends.

An example of how to determine categories of root cause, laying out causes and events.

Categories of root causes can include the following:

  • Human error, such as an action or error that has unintended consequences. It is important not to just identify that human error may have occurred, but to question whether any systemic conditions could have increased the chance of human error.
    • Is it an isolated incident, or has this happened before? If applicable, when else has this occurred?
    • Is the training appropriate?
    • Is there enough time and resources to complete the job?
    • Does the team have the suitable skills?
  • Systemic conditions such as underlying organisational, environmental, and structural factors. Systemic conditions can be quite wide-ranging, so it is important to understand which types could have affected your project. Examples include:
    • organisational culture
    • tools or systems used
    • procedures
    • resource constraints
    • external environmental factors
  • Design issues such as weaknesses or problems in the process plan and/or structures.  

There may be other relevant categories depending on the project. If unsure, identify common themes between the different root causes. 

Categorising the root causes is also a good opportunity to review them and make sure they align with the principles of RCA.

Ensuring causal inferences are valid

Defining causality 

The purpose of RCA is to identify the causes behind an event, identifying factors that directly contributed to the event happening.

However, causality can often be hard to prove. Just because two things happened at or around the same time does not necessarily mean they are directly linked.  

The following questions can act as a guideline on whether the identified root causes have affected the problem or event you are looking at:

  • Was the root cause present before the problem happened?
  • Is there a plausible explanation for how the root cause led to the problem?
  • Does the suggested cause simply describe the context, without explaining how that situation actually contributed to the problem?

Mitigating bias in analysis 

No one is fully objective when looking at a problem, we all make assumptions or are influenced by bias, whose impact has been widely studied (Haselton, Nettle, Andrews, 2005). Various cognitive biases can come into play during analysis.

Cabinet Office guidance from the Professional Head of Intelligence Analysis (PHIA) recognises that ‘cognitive limitations cause people to employ various simplifying strategies and rules of thumb to ease the burden of mentally processing information to make judgements and decisions’. 

One way to mitigate bias is to be mindful of different types of bias and try to mitigate their influence. Examples of bias, as defined by the PHIA, include the following:

  • Confirmation bias: the tendency to search for or interpret information in a way that confirms what you may have already thought.
  • Anchoring effect: the tendency to rely too heavily, or to ‘anchor’, on one trait or piece of information when making decisions, rather than considering the wider picture.
  • Loss aversion effect: the tendency for people to strongly prefer avoiding losses to acquiring gains.
  • Bandwagon effect: the tendency to do (or believe) things because many other people do (or believe) the same.
  • Congruence bias: the tendency to test an idea by looking for evidence that proves it, rather than also looking for evidence that could disprove it.  

Reducing bias in an RCA

  • Try to include and consult people with a wide variety of experience and perspectives on the issue. This broadens the range of ideas and makes it more likely you will understand the issue fully.
  • Gather data from a wide range of sources rather than relying on a single dataset or anecdote. Good-quality data can challenge your initial assumptions and reveal things you may not have spotted otherwise.
  • Consider the whole system. There might be more than just one root cause for an issue. Tools like event chain analysis and cause-and-effect diagrams can help you understand how different factors can feed into an issue.  
Was this page useful?

Do not provide personal information such as your name or email address in the feedback form. Read our privacy policy for more information on how we use this data

What is the reason for your answer?
I couldn't find what I was looking for
The information wasn't relevant to me
The information is too complicated
Other