TABLE OF CONTENTS:
A good understanding of Root Cause Analysis (RCA) is critical to your success as a project manager. There is always the potential for something to go wrong, and when it does, RCA is how you will most effectively identify, manage, and correct it.
What Is a Root Cause Analysis?
As the name implies, the goal of Root Cause Analysis is to uncover the root causes of a problem.
When your project encounters an adverse event, your project team can use RCA as a systematic process for figuring out what went wrong and why.
When you have a clear understanding of what happened and the contributing factors, you can implement corrective action and add preventive steps to avoid a problem in the future. This approach does a deep dive into the situation to identify the chain of events, conditions, or circumstances that led to the problem.
The investigation is typically conducted by a team of individuals with different backgrounds, perspectives, and expertise. The team will gather information, analyze data, and identify the root causes of the problem. The results are documented and shared with stakeholders, including management and customers. This gives transparency to the process and ensures action is taken to correct and prevent the problem from reoccurring.
What is the Purpose of a Root Cause Analysis?
The purpose of an RCA is to understand the root cause of a problem in a systematic and comprehensive manner, rather than simply addressing its symptoms. In that way, effective solutions can be developed and implemented to prevent similar incidents from occurring in the future.
This type of analysis also helps those in project management to improve their processes and procedures, increase their efficiency, and enhance customer satisfaction. It is a mechanism for helping businesses and organizations continuously improve.
What Is in a Root Cause Analysis?
The Root Cause Analysis process includes a chronology of events leading up to and following the problem. This timeline includes names, times, and detailed descriptions of all activities. The investigative team and their methods are also described, including data used in the analysis and the clear roles and responsibilities of each team member.
The following sections should be included in a simple Root Cause Analysis. Although, depending on your project, your RCA may include additional information.
- Introduction. The introduction highlights the purpose and importance of the Root Cause Analysis and serves as a summary of sorts. It includes the how the investigation will be approached, and what actions will be taken to address the root causes of the problem.
- Event Description. This is a detailed description of the event that triggered the RCA. It’s important that it be well documented in this section.
- Chronology of Events/Timeline. In this section, you will create a timeline of events leading up to and following the problem, including details such as names, times, and descriptions of activities.
- Investigative Team and Method. List who is on the team and what role they play, as well as how data will be gathered and analyzed.
- Root Causes and Supporting Evidence. This is the place to sum up your findings. However, this is not the place to talk about corrective action. That is done in the next section.
- Correction and Prevention Actions. This section will discuss the corrective action that needs to be taken in response to the finding above. These actions may affect the project’s scope, schedule, and cost so it is important that it be shared with the project team.
This report must be formally communicated to all interested parties because corrective action will likely involve the change management process.
What Are the Steps of a Root Cause Analysis?
There should be an introduction and five main steps in developing a Root Cause Analysis report. In our Root Cause Analysis (RCA) Template, we list each section with a description and an example to give you a clear understanding of how that portion should be written.
Use our written copy as a guide and after you’ve written your version, you simply delete our example. Creating your final report couldn’t be easier. By downloading and following our template, you can feel confident nothing has fallen through the cracks.
Or, you can write a report from scratch, following the steps we’ve outlined below.
Introduction
The introduction outlines the reason the analysis was undertaken (identifies the triggering event), the investigative approach taken (broadly, who is involved), and how the follow-up will be handled to address the root causes that were identified.
Event Description
In paragraph form, give a detailed description of the problem. It should include date, time, and exactly what happened. Who discovered the problem? Who was affected by it, and what impact does it have on the project and stakeholders? For instance, how might it affect the timeline, deliverables, and budget? This section explains the reason why you’re doing a Root Cause Analysis so make sure you’ve fully covered the bases.
Chronology of Events / Timeline
This section is a list of events organized in chronological order leading up to the event, the event itself, and then after the problem occurred. You start this timeline before the event took place (pick a starting point based on whatever makes sense for the problem you’re investigating) because it may help to shed light on why the problem occurred.
You’ll also want to document what happened after the fact so the investigation can determine if those actions also had some affect the outcome. This may dictate a change in operating procedure.
For each entry, document the time and day, which equipment and employees were involved, and what was happening at that time.
Investigative Team and Method
Since data collection about the event (problem) is a huge part of this process, you’ll need to document how the investigative team was chosen, who is on it, and how they will gather information. Just as it is with any part of project management, it is important to establish clear roles and methodologies so the process can proceed in a controlled manner.
Findings and Root Cause
In this section, you will share the analysis of your data collection. Describe the findings of your investigation including an explanation of the root causes.
Corrective Action
The logical conclusion to a report of this nature is to provide suggestions for corrective action so this problem can be fixed and a similar one avoided in the future. Typically, problems large enough to warrant a RCA, are large enough to affect the scope, schedule, and cost of a project, so it is important that this report be formally shared with all interested parties.
Root Cause Analysis Methods/Tools
There are several root cause analysis methods that can be used to identify the underlying causes of a problem. Some of the most popular methods include:
- Fishbone (Ishikawa) Diagram: This method uses a visual representation of the potential causes to help identify the root cause. It typically focuses on people, machines, methods, measurements, materials, and environment.
- 5 Whys: This method involves asking cascading “why” questions until the root cause of a problem is identified. This method can work well if the problem does not involve complex math.
- Fault Tree Analysis: This method is typically used at the time of design to predict problems and plan for redundancies.
- Pareto Chart: This is a bar graph that helps to visually depict which situations are most significant.
- Statistical Process Control: This method uses statistical analysis to identify patterns and relationships in data that can indicate root causes.
- Process Mapping: This method involves creating a visual representation of the workflow that led to the problem to identify where it went wrong.
Choosing an analytical method depends on the problem you’re trying to solve and the data available. Whichever route you choose, it’s important to use a systematic and structured approach to ensure the root cause is accurately identified.
Embrace Root Cause Analysis
RCA is most often used to determine the cause of a problem; however, it can be used to troubleshoot for problems ahead. Either way, it is a helpful method for getting answers to specific problems and devising ways to avoid them in the future.