Author: Matthew A. Barsalou
_Matthew A. Barsalou_
Reading time: 20 minutes
Synopsis
The book Root Cause Analysis (2014) teaches you how to look into quality problems. It shows you how to do this in a careful way. You will use real facts and clear steps, not just guesses or blaming people. The book first explains the main ideas of root cause analysis. Then, it shows how to use cycles of “plan–do–check–act.” It also explains how to use different quality tools to find the real reasons for problems in factories and service companies.
What’s in it for me? Learn practical root cause tools to fix stubborn problems faster, cheaper, and with lasting results.
Problems hardly ever happen at a good time. A product breaks at a customer’s place, a service stops working, or a complaint arrives at your desk. Suddenly, everyone feels pressured to “fix it fast.” When you are in a hurry, it is easy to blame someone nearby. It is also easy to fix only the surface problem and then forget about it. The problem is that the same issue often comes back. It might look a little different each time. And each time it comes back, it costs more money, time, and trust than before.
Root cause analysis offers a different way to deal with problems. Instead of asking “Who made a mistake?”, it asks “What in the system allowed this problem to happen?” It treats every idea about why something happened as a guess to check. It does not treat it as a story to protect. Simple tools and clear thinking help you understand and fix even difficult problems.
In this summary, you will learn how root cause analysis works using facts. You will see how basic and advanced tools help you investigate. You will also learn how data can help you find real causes, not just things that happened by chance. Finally, you will learn how to link all this to customer complaints, fixing problems, and making lasting improvements in your daily work.
Let’s start with the basic idea: treat every idea as a guess that must be proven true by the facts.
Blink 1 – Root cause analysis works only when it is driven by evidence and clear hypotheses
When something goes wrong, it is easy to quickly believe the first idea that sounds right. In root cause analysis, you start differently. Every idea is treated as a hypothesis. A hypothesis is a specific guess about why something failed. This guess must be tested against the facts. A good hypothesis fits what you already know. It does not make many assumptions. It also makes a clear prediction that you can check. For example, you might think that steel tubes stored near loading-dock doors rust more often. This is because they are exposed to wet air from outside.
This kind of statement already has the right structure for the method. It points to one factor, like the storage place. It also suggests what you should see if it is correct: more rust on tubes near the doors than in the middle of the warehouse. In this method, hypotheses are never proven true forever. They are either shown to be wrong, or they are supported for now after tests cannot prove them wrong. Over time, the best hypotheses are those that keep surviving attempts to prove them false.
To stop this process from being just random tries, the scientific method is broken into clear steps. You observe defects and conditions. Then you form a first guess, or hypothesis. From that guess, you figure out what results you should see if it were true. Then you plan a way to look for those results. This could be a formal experiment or a careful check of existing parts and records. The result of this check then helps you form your next hypothesis. This new hypothesis should include what you have just learned.
In many companies, this back-and-forth thinking is organized using the Plan–Do–Check–Act, or PDCA, cycle. Plan means you define the problem and choose a hypothesis to test. Do is the test itself. This can be a lab test or a test during production. Check is when you compare what your hypothesis predicted with what actually happened. Act finishes the cycle. You decide whether to confirm the result with a more detailed test. Or you might decide to reject the hypothesis and start a new cycle. Each turn of PDCA makes your hypotheses better and reduces the number of possibilities. So, investigations move step by step toward the real reasons for the failure.
In the next part, you will look at some clear visual tools. These tools help you collect and organize the facts that these cycles rely on.
Blink 2 – Simple quality tools turn scattered data into practical evidence
You do not need advanced statistics to investigate many everyday problems. A few simple, common diagrams and charts can turn mixed-up experiences into clear, useful facts.
A good starting point is the Ishikawa diagram, also called a cause and effect diagram. You write the unwanted result on one side. Then you branch backward into big groups like people, methods, materials, machines, measurement, and environment. Under each group, you write down specific things that might have caused the problem. For example, unclear work instructions, worn tools, or big temperature changes. This creates a map of possible ideas. You can then check these ideas against real facts, instead of just arguing about them.
To see what is really happening, check sheets help you collect data in an organized way right where the work is done. For example, counting different types of defects as parts leave the production line. You can then plot these counts in run charts to see changes and patterns over time. You can also use histograms to see how measurements are spread out. This can show if one supplier or one machine works very differently from the others. Pareto charts then help you decide where to start. They rank problems by how often they happen or how big their impact is. This uses the common idea that a small number of causes lead to most of the problems. But it still allows you to focus on rare but very serious issues first.
Scatter plots show two things together, like temperature and how many products are wasted. This helps you see if they change in similar ways. But remember, even if they show a strong link, it does not mean one causes the other. Finally, flowcharts show the real order of steps and decisions in a process from start to finish. This makes it much easier to see where problems can start and where you need to look more closely.
With these practical tools in mind, the next section looks at planning and management methods. These methods help to organize bigger investigations that involve different teams, not just looking at data at one workstation.
Blink 3 – Management tools keep complex root cause investigations coordinated
Once charts have shown you where a problem is, another challenge appears. You need to organize the people, decisions, and follow-up work needed to solve it. As soon as a problem involves several departments or a customer, a root cause analysis becomes a project. It needs structure as well as data. Management and planning tools help with this. They give teams a shared way to organize ideas, track actions, and agree on what is most important. This happens while tests and measurements continue in the background.
The matrix diagram is a good starting point. It compares different factors like suppliers, machines, or work shifts with their features or tasks. It uses simple rows and columns. In an investigation, it can collect test results and ideas. It can also be an action list that links each task to the person responsible and a due date.
Time is managed by the activity network diagram. This is a simple chart that shows each task as a box. It connects them in the order they must be done. It also gives an estimated time for each one. This shows the critical path. This is the chain of tasks that decides how long the investigation will take. So, teams can start key activities on time and avoid delays for fixing problems, experiments, or customer reports.
When several ways to fix a problem or improve things are competing for attention, a prioritization matrix scores them. It judges each option against important things like how well it works, its cost, and how long it will take to put in place. Interrelationship diagrams help sort out confusing situations. They draw arrows between different factors. This highlights which factors are truly causing things and which are mainly just results.
Finally, tree diagrams help teams break down a big problem into smaller, easier-to-manage parts. They link each possible cause to specific tasks. They also show how suggested changes fit together. Used with the other management tools, they keep complicated investigations clear and organized. This happens while experiments and measurements move forward.
In the next section, you will look at more special tools. These analytical tools help make the problem description clearer and connect different pieces of information.
Blink 4 – Specialized tools sharpen the search for root causes
By the time basic charts and management tools have been used, many problems are already narrowed down or fixed. What is left are the difficult cases. Here, you know roughly where the problem is, but not exactly what is causing it.
A first step is often the 5 Why method. This method keeps asking “why” an event happened until you find the basic conditions that allowed it to happen. Imagine a machine stopped because a fuse blew. But simply changing the fuse is not enough. Asking “why” repeatedly might uncover poor oiling, a worn pump part, and finally a missing filter that let metal pieces get into the system. That last point is the real cause that needs to be fixed.
The is-is not matrix makes things even clearer. It compares where the problem appears with where it *could* appear but does not. By comparing machines, work shifts, suppliers, or product types, it shows differences that are worth testing. It also filters out things that are just happening by chance. Cross assembling then takes a more experimental route. You swap parts between good and bad products. This shows if the defect follows a specific part or stays with the rest of the system. This is very useful when full product tests are expensive or slow.
When the situation is messy, it is important to follow specific types of information. Treat each observation as one piece of information. Ask if it supports a possible cause, goes against it, or is probably not important.
For questions about design and whole systems, you can draw pictures to get a wider view. Parameter diagrams map inputs, the desired function, error states, and settings you can control. They also show different types of “noise,” like how users behave or conditions in the environment. Boundary diagrams mark the limits of a system and where its parts meet. This shows when a problem in one part, like a cover that will not open, might actually be caused by another part outside that boundary.
Used together, these tools guide investigations toward clearer ideas and better-targeted tests. Now let’s look at exploratory data analysis. This is a way to look at raw data for patterns that can help create these ideas.
Blink 5 – Exploratory data analysis turns raw numbers into useful clues
Once you start collecting measurements from processes, checks, or experiments, the next question is what those numbers are telling you. Exploratory data analysis, or EDA, means looking at data directly before doing formal statistical tests. You use simple charts to spot patterns, strange values, and groups. These might explain a problem.
In root cause work, EDA builds on earlier tools by asking if the data supports or challenges your current ideas. For example, on a motor assembly line, a Pareto chart of defect types can show that most problems happen at one workstation. This tells you where to focus your checks. In cell phone production, a simple histogram of a pin measurement might show two clear peaks instead of one. This suggests that parts from two different molds are being mixed. And one of them works differently. In both cases, seeing the numbers helps guide your next questions and the next round of data collection.
To help with this, EDA uses simple tools that are easy to use at a desk or on the factory floor. Stem-and-leaf plots let you quickly draw a graph of the data by hand. They also keep every original number visible. Box-and-whisker plots summarize the middle part of the data. They highlight differences between machines or conditions. They also make unusual values stand out for more checking. Multi-vari charts go a step further. They show how an output changes over time, position, or cycles across several factors. This is very helpful when a machine, operator, material, and environment might all be affecting results at once. It gives you a quick picture before you plan experiments.
The basic idea of letting patterns in the data suggest explanations is not new. During the cholera sickness in London in 1854, John Snow mapped deaths and water suppliers. He then looked at exceptions on the map to make his explanation better. He was using EDA long before the term existed. In the final part, you will see how to use this way of thinking when real customer complaints come in. You will also learn how to turn investigations into clear actions to fix problems.
Blink 6 – Effective root cause analysis links customer complaints, investigation, and lasting improvement
What happens when the defect you have been looking at suddenly appears at a customer’s place? At that moment, root cause work is no longer just an idea. You need a clear way to protect the customer, investigate the problem, and stop it from happening again.
You start by making the situation stable. You decide how to deal with the problem. You put together a team from different departments. And you decide if you need to stop any more faulty parts from getting out. This might mean keeping stock in your warehouse or checking products at the customer’s site. In serious cases, it might mean planning to recall products. Remember the Plan–Do–Check–Act cycle from before? Here you use it to choose immediate actions. You see what effect they have, and quickly change your response as you get better information.
To keep everything organized, many companies use an 8D report. This is a structured story of the problem. It goes from the first complaint to the final step to prevent it. You write down who is on the team. You describe the problem in a way that matters to the customer. You record temporary fixes. Then you summarize the root cause analysis. This includes how you checked broken parts and which ideas you decided were wrong. Once you confirm a cause, you describe the planned actions to fix it. You also describe the tests that show they work. And you list the changes to work instructions or control plans that should stop the problem from happening again. Finishing the 8D leaves you with one record that both your company and your customer can follow.
So, how does this all work in real life? Let’s say a quality engineer looks at a year of customer data. He sees that rust causes more than half of all complaints. So, that becomes the most important problem to solve. Using the right root cause tools – Pareto charts, grouping, specific tests, and structured cause analysis – he slowly narrows down the problem. From “small tubes seem to rust more often,” he finds a very specific reason: bundles stored near open loading-dock doors get wet and rust. Simple changes to storage places and door protection greatly reduce rust complaints. Just as important, he writes down the ideas, tests, and final findings. He updates standards and risk checks. And he adds the case to a system where everyone can learn from past problems. The next team facing a strange defect can use that work. They will not have to start from nothing. That is the real benefit of root cause analysis. You fix the problem and also build a company that understands its problems and solves them more easily over time.
Final summary
The main message of this summary of Root Cause Analysis by Matthew A. Barsalou is this: using an organized, fact-based way to find the root cause lets you stop fixing the same problems again and again. Instead, you can prevent them. By treating every idea as a guess that can be tested, using simple visual tools to organize facts, and using more advanced methods only when needed, you can move from guesswork and blame to clear, shared understanding. Charts, diagrams, and looking at data help you see where a problem truly is. And organized teamwork and customer-focused follow-up turn that understanding into lasting fixes and smarter standards. Over time, each problem you solve adds to a growing pool of experience. This means you and your company can handle future problems with more confidence, speed, and new ideas.
Okay, that’s it for this summary. We hope you enjoyed it. If you can, please take the time to leave us a rating – we always appreciate your feedback. See you in the next summary.
Source: https://www.blinkist.com/https://www.blinkist.com/en/books/root-cause-analysis-en