What is root cause analysis (RCA)?

Are recurring project delays, persistent customer issues, or stubborn process bottlenecks hindering your team’s success? While quick fixes are tempting, they often only address the symptoms, leaving the underlying problem to resurface later. This is where root cause analysis (RCA) comes in.

RCA is a powerful, systematic approach designed to move beyond temporary solutions by identifying the fundamental source of a problem. By understanding and addressing the root cause, you can implement lasting changes and prevent the issue from happening again.

In this guide:

• What is root cause analysis (RCA)?
• How to create a root cause analysis.
• RCA methods and approaches.
• Choosing the right RCA method.
• Root cause analysis examples.
• What is the purpose of root cause analysis?
• Best practices for effective root cause analysis.
• How Adobe Workfront can support your process improvement efforts.

Root cause analysis (RCA) is a collective term for various structured methods to uncover the underlying causes of problems or nonconformances. It’s based on the principle that systematically preventing and solving fundamental issues is far more effective than treating surface-level symptoms. A root cause is the core factor that, if eliminated, would prevent the problem from recurring.

Think of it like weeding a garden. Pulling the visible part of the weed — the symptom — doesn’t stop it from growing back. For a lasting solution, you need to dig down and remove the entire root — the root cause.

Root causes vs. symptoms vs. contributing factors.

Understanding the difference between these is crucial for effective RCA:

• Root causes: This is the fundamental, underlying reason the problem exists. Removing or correcting the root cause should prevent the problem from happening again.
• Symptoms: These are the visible indicators or consequences of the problem (for example, project delays, customer complaints, machine downtime, or low website traffic). Addressing only symptoms provides temporary relief at best.
• Contributing factors: These are conditions or actions that help the problem occur or make it worse but aren’t the fundamental source. For example, if a tire goes flat because you ran over nails on the garage floor, the nails are a direct cause, but the reason the nails were on the floor (for example, a leaky roof caused the nail box to break) is closer to the root cause. Addressing contributing factors might slow the problem’s return but won’t eliminate it.

There are several approaches to root cause analysis, but they all follow the same general structure.

1. Define the problem or goal.

The first step in RCA is defining the problem that needs to be solved or the improvement that needs to be made. A complete and detailed understanding of the issue is crucial.

Take time to understand the problem or improvement goal fully. Collect relevant data and document your analysis. Consider the following:

• How the problem impacts the company as a whole
• How often does the problem occur, or how often is the inefficiency felt
• How the current problem or process is being measured

For example, an operations manager might notice that new product releases are frequently late. As the manager pulls together data and insights, they can confidently report exactly how often product releases are behind schedule, providing a concrete description of the problem. They will also be able to discuss issues related to the business. Releases that are consistently late degrade customer experience and customer trust, increasing churn and negatively impacting revenue.

2. Brainstorm possible root causes.

After identifying the problem, list all the possible issues or events that may have contributed to it. If you’re trying to improve a process for greater efficiency, detail every part of the current workflow. Don’t worry about validating root causes at first — brainstorm the longest list you can come up with.

Then, analyze the actual impact of each possible cause. You may need to do additional research to rule out anything that looks like a cause but isn’t. Finally, prioritize the causes you have left. Identify which ones have the greatest impact and which are minor.

Let’s revisit the operations manager dealing with late product releases. They may start with the team’s Kanban board or other product development process and brainstorm possible root causes at every stage. The ops manager might list possibilities like:

• Ideas stay in “to do” too long or don’t start on time.
• Work doesn’t get assigned to team members quickly.
• Approvals take too long.
• User feedback takes too long.
• User feedback gets lost.

With a complete list of possible root causes, the operations manager would analyze each one. For example, they may have to ask team members or review digital Kanban card data to determine how long it takes the team to get user feedback and how it gets shared internally.

3. Devise solutions.

Once you’ve identified and detailed the root cause of a problem, such as a system or process underperforming, brainstorm possible solutions. Interviewing personnel from the relevant department is a great way to gather input and recommendations from people immersed in the work.

In the example of the operations manager, let’s assume that user feedback is a major cause of delay. The manager would sit down with their team to discuss possible solutions. They would probably talk about the channels they’re currently using to gather feedback, the strategies to collect feedback, how it is shared with the team, and more. Possible solutions might include developing a more intentional process for soliciting feedback and assigning a person to manage comments and ideas as they come in.

4. Implement solutions.

Once you’ve designed and validated solutions, implement them strategically to ensure new processes and fixes don’t slip through the cracks. You may need to get buy-in from team members close to the problem or support from executive leadership. If you’re working with a team, assign a point person or project manager to ensure implementation doesn’t slip through the cracks.

In our example, the operations manager may assign one team member to start developing a better process for requesting feedback and another to oversee incoming reviews. The manager would need to set up recurring check-ins with those team members to ensure successful implementation.

5. Monitor results.

Your monitoring period may last weeks or months, depending on the solution implemented. Adjust if your proposed solutions aren’t working. If you’ve repeatedly adjusted and the solutions haven’t worked, brainstorm and implement solutions to the other primary causes you’ve identified.

Returning to our example, the operations manager would probably monitor the new user feedback process for at least a few product release cycles. First, they would make sure that the new process for requesting feedback is effective by validating that the team gets more feedback or at least gets it faster than before. The manager would also ensure that the feedback gets shared with the team more quickly than before. Finally, the operations manager will review product release timelines to see if the improvements in the customer feedback loop have improved release times overall.

If the operations manager notices that feedback has not gotten quicker or that it hasn’t helped the team make product release deadlines, the manager can simply go back to the list of possible root causes from step two and develop solutions for another possible cause. If faster feedback loops result in more timely product releases, they may still decide to select another possible cause and improve the process even more.

Root cause analysis identifies contributing factors to a problem or event. Just as the overall RCA process is flexible, different methods and approaches to root cause analysis are also common.

• Change analysis. Also known as change impact analysis, this RCA approach compares a deviation to the norm to identify the deviation’s root cause. It explores changes in people, equipment, infrastructure, information, and other contributing factors that could have affected system performance.
• Causal factor tree analysis. An RCA technique known as causal factor tree analysis, involves recording and visually displaying all actions and conditions (or causal factors) that led to a particular problem event.
• Event analysis. Sometimes lumped together with causal factor analysis, this RCA method involves quick evidence gathering to establish a timeline for actions and conditions leading up to a problem event. From there, teams can determine causal and contributing factors. Event analysis is often used for major, one-off problems like explosions.
• Barrier analysis. Often used in safety incidents, barrier analysis is an RCA approach based on the premise that problems could have been detected and prevented if the proper barriers had been in place. Barrier analysis looks at the different effects caused by specific hazards and investigates how barriers (or controls) failed to prevent the accident.
• 5 Whys analysis. Popularized in the 1970s by Toyota, the 5 Whys analysis is an RCA technique that helps users get to the root of the problem quickly by asking the questions “Why?” and “What caused the problem?” up to five times. The 5 Whys analysis is simple, quick, and good for less complex issues. It can be susceptible to bias, may identify only one cause when multiple exist, and the results might not be repeatable.
• Ishikawa (fishbone) diagram. Also known as the cause-and-effect diagram, the Ishikawa diagram is an RCA analysis tool that looks at an event’s causes contributing to a problem. It’s designed like a fish skeleton, earning its nickname as the “fishbone diagram” because it groups a long list of causes into related sub-categories. This structure helps identify the root causes most likely to be the main problems.
• Kepner-Tregoe’s root cause analysis. Also known as the KT method, this RCA model involves disconnecting problems from decisions through four phases of problem-solving — situation analysis, problem analysis, solution analysis, and potential problem analysis.
• Pareto analysis. Named after the Pareto Principle — or the observation that 80% of problems come from 20% of causes — the Pareto analysis process selects a solution that provides the most significant benefit.

Some of these methods and techniques are also known as “tree” diagrams or analysis because they identify the root causes of a factor and list the possible corrective actions. For example, change analysis is also called “change tree analysis” because you can use a tree diagram to illustrate the causes and effects of a change.

Selecting the best root cause analysis methodology depends on the situation. Use this table as a guide:

RCA isn’t just for manufacturing or IT failures. It’s highly applicable across business functions. Here are a few root cause analysis examples:

Improving project delivery times.

Problem: Key projects are consistently delivered late.

Simplified RCA (5 Whys):

• Why late? Tasks underestimated.
• Why? Scope creep during execution.
• Why? Initial requirements were unclear.
• Why? Stakeholder input was incomplete during planning.
• Why? Kickoff process was rushed.

Root cause: Inadequate stakeholder alignment and requirements gathering during project initiation.

Solution: Implement a more robust project kickoff process with mandatory stakeholder signoffs on scope and requirements.

Reducing customer churn rate.

Problem: Higher than acceptable customer churn rate in Q3.

Simplified RCA (Fishbone categories):

• Product: missing features, bugs
• Service: slow support response, poor onboarding
• Pricing: too high vs. competitors
• Communication: lack of engagement
• Brainstorming reveals that slow support response is a major factor.

Root cause (drilling down on service): The support team was understaffed during peak hours due to inaccurate forecasting of support needs.

Solution: Improve support staffing models based on historical data and predictive analytics; implement self-service options.

Increasing marketing campaign ROI.

Problem: The recent email marketing campaign had a significantly lower ROI than expected.

Simplified RCA (Fishbone categories):

• Audience: wrong segment, list fatigue
• Content: unclear message, weak CTA
• Timing: sent wrong day/time
• Technical: delivery issues, broken links
• Analysis points to poor audience segmentation.

Root cause: Segmentation based on outdated demographic data, not recent engagement behavior.

Solution: Update segmentation strategy to prioritize recent behavioral data and implement A/B testing for future campaigns.

The primary purpose of root cause analysis is to identify and implement solutions that prevent the problem from recurring, a core component of continuous improvement efforts.

The key benefits of conducting a root cause analysis include:

• Improving processes and systems. Identify and fix workflows, procedures, and organizational structure flaws.
• Enhancing efficiency and reducing costs. Minimize waste, rework, downtime, and associated financial losses.
• Increasing safety and reducing risk. Crucial for preventing accidents, errors, and harm, especially in regulated or high-risk environments.
• Driving continuous improvement. Integrate RCA into ongoing efforts to refine operations and performance.
• Improving decision-making. Provide data-driven insights for developing effective, targeted solutions.

To get the most out of your root cause analysis, keep these best practices in mind.

• Be specific and data driven. Clearly define the problem and base your analysis on facts and evidence, not assumptions.
• Involve a diverse, knowledgeable team. Bring together people with different perspectives and direct knowledge of the process or system.
• Maintain a system focus and avoid blame. Look for failures in processes and systems, not just individual errors. The goal is improvement, not punishment.
• Follow a structured process. Use a systematic methodology to ensure thoroughness.
• Dig deep and verify root causes. Don’t stop at symptoms or intermediate causes. Use techniques like the 5 Whys. Verify that addressing the identified root cause would prevent recurrence.
• Develop specific, actionable solutions. Solutions should address the root cause(s) and include clear steps, owners, and deadlines.
• Ensure follow-through and monitoring. Implement the solutions and track their effectiveness over time. Close the loop.

Root cause analysis is fundamentally about understanding and improving processes to prevent future problems. While RCA itself is an analytical exercise, implementing and monitoring the resulting solutions requires robust work management capabilities.

Adobe Workfront provides a centralized platform to manage the corrective actions identified through RCA. You can plan and track corrective actions, enhance collaboration, monitor process performance, and document processes. By connecting RCA findings to actionable plans within a work management system like Workfront, organizations can ensure that insights lead to tangible, sustainable improvements.

Sign up for a free demo to see the Workfront in action.