How To Do Root Cause Analysis: 6 Steps, Tools, Examples

Most teams jump straight to fixing symptoms. A machine breaks down, a defect rate spikes, a project misses its deadline, and the immediate reaction is to patch whatever’s visible. The problem comes back two weeks later, and the cycle repeats. Learning how to do root cause analysis gives you a structured way to break that cycle for good by identifying what’s actually driving the issue, not just what it looks like on the surface.

Root cause analysis (RCA) is one of the foundational skills in Lean Six Sigma, and at Lean Six Sigma Experts, we’ve spent over a decade helping organizations apply it through hands-on consulting and training. It’s not complicated, but it does require discipline, a willingness to ask hard questions, follow the data, and resist the urge to stop at the first plausible explanation.

This guide walks you through six clear steps to conduct a root cause analysis, covers the most effective tools, including the 5 Whys and Fishbone diagrams, and includes real-world examples so you can see how each method works in practice. Whether you’re an operations manager tackling recurring defects or a professional building your process improvement toolkit, you’ll leave with a framework you can apply immediately.

What root cause analysis is and is not

Root cause analysis is a structured, evidence-based process for tracing a problem back to its origin point, the condition that, if eliminated, prevents the issue from returning. It’s a core component of Lean Six Sigma and applies across manufacturing, healthcare, logistics, and any field where process failures carry real operational costs. When you learn how to do root cause analysis correctly, you stop spending resources on solutions that treat symptoms instead of causes.

What RCA actually is

RCA is a systematic investigation method, not a single technique. It combines data collection, causal mapping, and verification to build a chain from the visible problem back to its origin. The goal is a verified root cause, one supported by data rather than assumption. A complete RCA also produces a corrective action that eliminates the cause at its source and a control mechanism to confirm it doesn’t return. That gives you a full problem-solving loop rather than a partial fix.

The difference between fixing a symptom and fixing a root cause is the difference between a temporary repair and a permanent solution.

What RCA is not

RCA is not a blame exercise. The moment an investigation shifts focus to who made the mistake instead of why the system allowed it, the analysis loses accuracy and team buy-in. RCA is also not a rigid checklist. Different problems require different tools, and applying a simple technique to a complex multi-factor failure produces shallow results. Finally, RCA is not a one-time event. Organizations that treat it as a reactive ritual rather than a standard operating discipline keep fighting the same fires repeatedly.

Understanding what RCA is and is not shapes how seriously you approach each step. When you treat it as a genuine inquiry into system behavior, the results hold. Treat it as incident paperwork, and expect the problem to return.

RCA tools to use and when

No single tool works for every problem. When you learn how to do root cause analysis, matching the tool to the problem’s complexity is as important as following the steps correctly. Applying a simple technique to a multi-factor failure produces shallow results. The table below maps the most practical RCA tools to the situations where they deliver the most value.

5 Whys

The 5 Whys technique works by asking "why" repeatedly until you reach an actionable origin, typically within five iterations. It suits simple, linear problems where one cause leads directly to the next. Start with a clear problem statement, ask why it happened, and treat each answer as the next starting point.

Use the 5 Whys when the failure path is straightforward and unlikely to branch into multiple independent causes.

Fishbone diagram

A Fishbone diagram (also called an Ishikawa diagram) maps potential causes across structured categories. This tool fits complex problems with multiple contributing factors across different areas of your operation. Place the problem at the head, then branch causes across these standard categories:

• People
• Process
• Equipment
• Materials
• Environment
• Measurement

Steps 1 and 2: define and scope the problem

The first two steps of how to do root cause analysis set the foundation for everything that follows. A vague problem statement leads to an unfocused investigation, and the entire analysis drifts. Get these steps right, and every subsequent step becomes faster and more accurate.

Step 1: Write a clear problem statement

Your problem statement needs to describe what is happening, where, and how often, without speculating about causes. A weak statement like "the machine is broken" tells you nothing useful. A strong statement gives your team a precise, agreed-upon starting point before anyone touches data.

Use this template to build a solid problem statement:

• What is happening: [Observable failure or defect]
• Where it occurs: [Location, process step, or product line]
• When it started: [Date or triggering event]
• How often: [Frequency or defect rate, e.g., 4.2% of units]

A good problem statement describes the effect, not the assumed cause. Resist explaining why until you’ve completed your investigation.

Step 2: Define the scope

Scope determines the boundaries of your investigation. Without it, the analysis expands into areas you can’t control, and your team loses focus. Set clear limits on which process steps, time periods, and data sources fall inside the investigation.

For example, if a defect appears at a specific assembly station, scope the analysis to that station and the two or three process steps feeding into it, not the entire production line.

Steps 3 and 4: find and verify causes

With your problem defined and scoped, you move into the investigative core of how to do root cause analysis. Steps 3 and 4 are where most teams either break through to real insight or get stuck chasing assumptions. The key is to generate possible causes broadly first, then narrow down through evidence rather than opinion.

Step 3: Map all possible causes

Use the tool that fits your problem’s complexity, whether that’s a 5 Whys chain or a Fishbone diagram. List every plausible contributing factor before filtering any out. Involve people who work directly in the process, as they often hold critical knowledge that data alone won’t surface.

Here’s a simple 5 Whys example for a recurring torque defect:

Step 4: Verify the root cause with data

Identifying a probable cause is not enough. You need data to confirm that eliminating or changing the suspected cause actually removes the problem. Run a controlled test or collect process data before and after addressing the cause to build that confirmation.

Only move to corrective action once your data confirms the cause, not before.

A verified cause meets a simple standard: it’s present when the problem exists and absent when the problem doesn’t. If you change or remove the cause and the defect rate drops, you have evidence of a real root cause. If nothing changes, keep investigating.

Steps 5 and 6: fix, control, and learn

The final two steps of how to do root cause analysis turn your verified findings into permanent process change. Most teams stop at identifying the cause, but without a structured fix and a control mechanism, the same problem resurfaces under slightly different conditions.

Step 5: Implement and document the fix

Your corrective action should target the verified root cause directly, not the symptom that triggered the investigation. Once you’ve confirmed the fix in a controlled test, deploy it to the full process and update all relevant documentation, including work instructions, training materials, and SOPs.

Use this simple corrective action template before closing out the investigation:

Step 6: Control the process and capture lessons

After implementing the fix, set up a control mechanism to monitor the process over time. This could be a control chart, an updated audit checklist, or a scheduled review interval. The goal is to catch any drift before it becomes a recurring failure.

A fix without a control is just a delayed recurrence.

Document what you learned from the investigation and share it across teams facing similar processes. This step converts a single problem-solving event into organizational knowledge that prevents related failures before they start.

Where to go from here

You now have a complete framework for how to do root cause analysis, from writing a precise problem statement to controlling the fix after implementation. The six steps work as a system, and each one depends on the one before it. Skip the verification step, and your corrective action is guesswork. Skip the control step, and your fix has no staying power.

Applying this framework consistently takes practice, and the first few investigations will take longer as your team builds the habit. The returns compound quickly once RCA becomes a standard part of how your operation responds to failures rather than a one-off exercise.

Building that discipline organization-wide is where most teams need outside support. Our team at Lean Six Sigma Experts works hands-on with you from diagnosis through full implementation, combining consulting, training, and the right talent to sustain the changes. Contact us to learn more about what that looks like for your operation.