Root Cause Analysis by Matthew A. Barsalou A Step-By-Step Guide to Using the Right Tool at the Right Time

What's it about?

Root Cause Analysis (2014) explains how to investigate quality problems systematically using empirical evidence and structured methods rather than intuition or blame. It introduces the theoretical foundations of root cause analysis and then shows how to apply cycles of plan–do–check–act together with a range of quality tools to identify underlying causes of failures in manufacturing and service environments.

Things rarely go wrong at a convenient moment. A product fails at a customer site, a service grinds to a halt, a complaint lands on your desk, and suddenly everyone is under pressure to “fix it fast.” In the rush, it’s tempting to blame the nearest suspect, patch the symptom, and move on. The problem is that the same issue often comes back wearing a slightly different mask, and each repeat costs more money, time, and trust than the last one.

Root cause analysis offers a different way of responding. Instead of asking "Who messed up?", it asks "What in the system made this outcome possible?" It treats every explanation as a hypothesis to be tested, not a story to defend. Simple tools and structured thinking help you understand and address even complex failures.

In this lesson, you’ll learn how evidence-based root cause analysis works in practice, how basic and advanced investigation tools support it, how data can guide you toward real causes rather than coincidences, and how to connect all of this to customer complaints, corrective actions, and lasting improvement in everyday work.

Let’s start at the foundation: treating every explanation as a hypothesis that has to earn its place by matching the facts.
When something goes wrong, it is tempting to latch onto the first explanation that sounds plausible. In root cause analysis, the starting point is different: every explanation is treated as a hypothesis, a specific guess about why the failure happened that has to survive contact with the facts. A good hypothesis fits what is already known, keeps assumptions modest, and makes a clear prediction you can check. For instance, you might suspect that steel tubes stored near loading dock doors rust more often because they are exposed to damp outside air.

That kind of statement already has the structure the method needs. It singles out a factor, such as storage location, and implies what you should observe if it is right: more rust on tubes near the doors than in the middle of the warehouse. Hypotheses in this approach are never finally proven. They are either rejected or they remain provisionally supported after tests fail to contradict them. Over time, the better ones are those that repeatedly survive attempts to disprove them.

To keep this process from turning into random trial and error, the underlying scientific method is broken into practical steps. Observations of defects and conditions are used to form a tentative hypothesis. From that hypothesis, you work out what concrete results you ought to see if it were true, then design a way to look for those results, whether through a formal experiment or a structured check of existing parts and records. The outcome of that comparison feeds directly into the next hypothesis, which should now reflect what you have just learned.

In many organizations, this logical back-and-forth is organized through the Plan–Do–Check–Act, or PDCA, cycle. Plan means defining the problem and selecting a hypothesis worth testing. Do is the test itself, from a lab trial to an on-line trial in production. Check is the comparison between what the hypothesis predicted and what actually occurred. Act closes the loop. You decide whether to confirm the result with a more thorough test or to reject the hypothesis and start a new cycle. Each turn of PDCA sharpens the hypotheses and narrows the possibilities, so investigations move step by step toward the conditions that truly enabled the failure.

In the next section, you’ll look at some concrete graphical tools that help gather and organize the evidence those cycles depend on.
You don’t need advanced statistics to investigate many everyday failures. A handful of simple, widely used diagrams and charts can already turn messy experience into clear, practical evidence.

A good place to start is the Ishikawa diagram, also called a cause and effect diagram. You write the unwanted result on one side and then branch backwards into broad categories such as people, methods, materials, machines, measurement, and environment.Under each category, you capture specific possible contributors: unclear work instructions, worn tools, temperature swings. This creates a map of hypotheses that can later be checked against real data, not argued about.

To see what is really happening, check sheets bring discipline to data collection right where the work is done, for example tallying different defect types as parts come off the line. Those counts can be plotted in run charts to spot shifts and patterns over time, and in histograms to see how measurements are distributed, which can reveal that one supplier or one machine behaves very differently from the rest. Pareto charts then help decide where to start by ranking problems by frequency or impact, drawing on the long observed tendency for a small share of causes to account for most of the effect, while still leaving room to treat rare but severe issues as top priority.

Scatter plots pair variables such as temperature and scrap rate to see whether they move together. Remember, though, that even a strong relationship does not by itself prove cause and effect. Finally, flowcharts lay out the real sequence of steps and decisions in a process from start to finish, making it much easier to see where defects can enter and where more detailed analysis is needed.

With those hands-on tools in mind, the next section turns to planning and management methods that coordinate larger, cross-functional investigations rather than just charting data at a single workstation.
Once charts have revealed where a problem sits, another challenge appears. You need to coordinate the people, decisions, and follow-up work needed to solve it. As soon as an issue spans several departments or involves a customer, a root cause analysis becomes a project that needs structure as well as data. Management and planning tools answer that need by giving teams a shared way to organize ideas, track actions, and agree on priorities while experiments and measurements continue in the background.

The matrix diagram is a good starting point. It compares factors such as suppliers, machines, or shifts with characteristics or tasks in simple rows and columns. In an investigation, it can collect test results and hypotheses. It can also act as an action list that links each task to a responsible person and due date.

Time is handled by the activity network diagram, a simplified chart that shows each task as a box, connects them in the order they must be done, and assigns an estimated duration to each one. This makes the critical path visible – the chain of tasks that determines how long the investigation will take – so teams can start key activities on time and avoid delaying containment, experiments, or customer reports.

When several corrective actions or improvement projects compete for attention, a prioritization matrix scores alternatives against weighted criteria such as effectiveness, cost, and implementation time. Interrelationship diagrams help untangle messy situations by drawing arrows between factors and highlighting which ones are genuine drivers and which are mainly outcomes.

Finally, tree diagrams help teams break a broad problem into manageable branches linking each possible cause to concrete tasks, and highlighting how proposed changes fit together. Used alongside the other management tools, they keep complicated investigations visible and coordinated while experiments and measurements move ahead.

In the next section, you’ll look at more specialized analytical tools that sharpen the problem description and connect different strands of evidence.
By the time the basic charts and the management tools have done their work, many issues are already narrowed down or resolved. What is left are the stubborn cases where you know roughly where the problem sits, but not exactly what is driving it.

A first step is often the 5 Why method, which keeps asking why an event occurred until you reach the conditions that allowed it to happen. Imagine a machine that stopped because a fuse blew. But, simply changing the fuse is not enough. Repeated questioning might uncover insufficient lubrication, a worn pump shaft, and finally the missing strainer that allowed metal scrap into the system. That last point is the ultimate cause that needs to be addressed.

The is-is not matrix tightens things further by comparing where the problem appears with where it could appear but does not. By contrasting machines, shifts, suppliers, or product variants, it highlights differences that are worth testing and filters out coincidences. Cross assembling then takes a more experimental route, swapping parts between good and bad assemblies to see whether the defect follows a specific component or stays with the rest of the system. This is especially useful when full functional tests are expensive or slow.

When the picture is messy, following specific lines of evidence is important. Treat each observation as one strand, asking whether it supports a possible cause, contradicts it, or is likely irrelevant.

For design and system questions, you can visualize the situation to widen the view. Parameter diagrams map inputs, desired function, error states, controllable settings. They also show different types of noise, such as user behavior and environmental conditions. Boundary diagrams mark system limits and interfaces, revealing when an apparent problem in one assembly, like a sliding cover that will not open, may really be caused by another component outside that boundary.

Used together, these tools steer investigations toward sharper hypotheses and better targeted tests. Now let’s look at exploratory data analysis as a way to scan raw data for patterns that can spark those hypotheses.
Once you start collecting measurements from processes, inspections, or experiments, the next question is what those numbers are trying to tell you. Exploratory data analysis, or EDA, is about looking at data directly before formal statistical tests. You use simple displays to spot patterns, odd values, and groupings that might explain a problem.

In root cause work, EDA builds on earlier tools by asking whether the data support or challenge your current hypotheses. On a motor assembly line, for example, a Pareto chart of defect types can show that most failures originate at one workstation, telling you where to focus checks. In cell phone production, a basic histogram of a pin measurement might show two clear peaks instead of one, suggesting that parts from two molds are being mixed and that one of them behaves differently. In both cases, visualizing the numbers guides the next questions and the next round of data collection.

To support this, EDA uses lightweight tools that are easy to apply at a desk or on the shop floor. Stem-and-leaf plots let you sketch a distribution by hand while keeping every original value visible. Box-and-whisker plots summarize the middle of the data, highlight differences between machines or conditions, and make outliers stand out for further checking. Multi-vari charts go a step further by showing how an output changes over time, position, or cycles across several factors, which is especially helpful when machine, operator, material, and environment may all be influencing results at once and you want a quick picture before planning experiments.

The basic idea of letting patterns in the data suggest explanations is not new. During the 1854 cholera outbreak in London, John Snow mapped deaths and water suppliers. He then examined exceptions on the map to refine his explanation, effectively using EDA long before the term existed. In the final section, you’ll see how to apply this way of thinking when real customer complaints come in, and how to turn investigations into concrete corrective actions.
What happens when the defect you have been analyzing suddenly shows up at a customer’s line? At that moment, root cause work is no longer abstract; you need a clear way to protect the customer, investigate the failure, and stop it from coming back.

You start by stabilizing the situation. You decide how to address the problem, pull together a cross-functional team, and judge whether you need containment so no more suspect parts escape. Containment might mean quarantining stock in your warehouse or checking inventory at the customer. In severe cases, it might mean planning a recall. Remember the Plan–Do–Check–Act cycle from earlier? Here you use it to choose immediate actions, see what effect they have, and quickly adjust your response as better information comes in.

To keep everything coordinated, many companies rely on an 8D report. This is a structured story of the issue, from the first complaint to the final prevention step. You document who is on the team, describe the problem in terms the customer cares about, record temporary fixes, and then summarise the root cause analysis, including how you examined failed parts and which explanations you ruled out. Once you confirm a cause, you describe planned corrective actions, the trials that show they work, and the changes to work instructions or control plans that should stop the problem reappearing. Closing the 8D leaves you with a single record that both your organisation and your customer can follow.

So, how does this all come together in practice? Say a quality engineer reviews a year of customer data and sees that rust makes up more than half of all complaints, so that becomes the single most important problem to solve. Using the appropriate root cause tools – Pareto charts, stratification, targeted experiments, and structured cause analysis – he gradually narrows the trail from “small tubes seem to rust more often” to a very specific condition: bundles stored near open loading-dock doors pick up moisture and corrode. Simple changes to storage locations and door protection cut rust complaints dramatically. Just as important, he documents the hypotheses, tests, and final conclusions, updates standards and risk analyses, and adds the case to a lessons-learned system. The next team facing a puzzling defect can build on that work, instead of starting from scratch. That is the real payoff of root cause analysis: you fix the failure while also steadily building an organization that understands its problems and solves them more easily over time.
The main takeaway of this lesson to Root Cause Analysis by Matthew A. Barsalou is that systematic, evidence-based root cause analysis lets you stop fighting the same fires over and over and start preventing them instead. By treating every explanation as a testable hypothesis, using simple visual tools to organize facts, and applying more advanced methods only when needed, you can move from hunches and blame to clear, shared understanding. Charts, diagrams, and exploratory data analysis help you see where a problem really lives, while structured teamwork and customer-focused follow-up turn that understanding into lasting corrective actions and smarter standards. Over time, each solved problem becomes part of a growing pool of experience, so you and your organization can handle future failures with more confidence, speed, and creativity.