In 2012, I was working for a M&O contractor for The U.S. Government. I was attached to a medical team as an Occupation Ergonomist (2012, University of Colorado). My area of expertise included the optimal performance of specialized teams operating in locations including Andrews AFB, Nellis, AFB, Creech AFB, Kirtland AFB, Los Alamos National Laboratory, Livermore National Laboratory, NYC Operations, and DC Operations, to name a few. In 2014, I was appointed as Chair of the Surgical Performance and Simulation Training team for the International Healthcare Symposium in Chicago, Illinois. In 2016, I conducted research on the effects of Daylight Saving on personnel at the largest nuclear site in the U.S (NNSS) through the application of predictive analytics. The Predictive Analytics Project “If it can be Predicted, It Can Be Prevented,” was published by the U.S. Department of Energy in August 2016. Both of my accomplishments above were the result of conducting root cause analyses, based on quantitative data, assigning numerical values to qualitative data, and removing all beliefs.
Data is a lagging indicator. It's a snapshot in time that may, or may not, exist in the future. How do you know if it will exist in the future? That's a mathematical equation. Where the variables of the equation exist, under the same circumstances, with the same values, without the introduction of new variables, the sum of the equation will be the same. That leads to predictive analytics, with the addition of regression analytics, to accommodate new variables, attaining their ultimate variable value. If you can predict it, you can solve for it, in advance, and you can prevent it. What is the foundation of separating a variable from a belief? That the sum of that equation becomes quantified through a root cause analysis.
A root cause is defined as a factor that caused a nonconformance and should be permanently eliminated through process improvement. The root cause is the core issue—the highest-level cause—that sets in motion the entire cause-and-effect reaction that ultimately leads to the problem(s).
Root cause analysis (RCA) is defined as a collective term that describes a wide range of approaches, tools, and techniques used to uncover causes of problems. Some RCA approaches are geared more toward identifying true root causes than others, some are more general problem-solving techniques, and others simply offer support for the core activity of root cause analysis.
History of root cause analysis
Approaches to root cause analysis
Conducting root cause analysis
Root cause analysis resources
HISTORY OF ROOT CAUSE ANALYSIS
Root cause analysis can be traced to the broader field of total quality management (TQM). TQM has developed in different directions, including a number of problem analysis, problem solving, and root cause analysis.
Root cause analysis is part of a more general problem-solving process and an integral part of continuous improvement. Because of this, root cause analysis is one of the core building blocks in an organization’s continuous improvement efforts. It's important to note that root cause analysis in itself will not produce any results; it must be made part of a larger problem-solving effort for quality improvement.
TYPES OF ROOT CAUSE ANALYSIS
Change analysis: This approach is applicable to situations where a system’s performance has shifted significantly. It explores changes made in people, equipment, information, and more that may have contributed to the change in performance.
Barrier analysis: This technique focuses on what controls are in place in the process to either prevent or detect a problem, and which might have failed.
Management oversight and risk tree analysis: One aspect of this approach is the use of a tree diagram to look at what occurred and why it might have occurred.
Kepner-Tregoe Problem Solving and Decision Making: This model provides four distinct phases for resolving problems:
1. Situation analysis
2. Problem analysis
3. Solution analysis
4. Potential problem analysis
CONDUCTING ROOT CAUSE ANALYSIS
When carrying out root cause analysis methods and processes, it's important to note:
While many root cause analysis tools can be used by a single person, the outcome generally is better when a group of people work together to find the problem causes.
Those ultimately responsible for removing the identified root cause(s) should be prominent members of the analysis team that sets out to uncover them.
A typical design of a root cause analysis in an organization might follow these steps:
A decision is made to form a small team to conduct the root cause analysis.
Team members are selected from the business process/area of the organization that experiences the problem. The team might be supplemented by:
A line manager with decision authority to implement solutions.
An internal customer from the process with problems.
A quality improvement expert in the case where the other team members have little experience with this kind of work.
The analysis lasts about two months. During the analysis, equal emphasis is placed on defining and understanding the problem, brainstorming its possible causes, analyzing causes and effects, and devising a solution to the problem.
During the analysis period, the team meets at least weekly, sometimes two or three times a week. The meetings are always kept short, at maximum two hours, and since they are meant to be creative in nature, the agenda is quite loose.
One person in the team is assigned the role of making sure the analysis progresses, or tasks are assigned to various members of the team.
Once the solution has been designed and the decision to implement has been taken, it can take anywhere from a day to several months before the change is complete, depending on what is involved in the implementation process.
MANAGEMENT OVERSIGHT AND RISK TREE ANALYSIS
A tree diagram is a management planning tool that depicts the hierarchy of tasks and subtasks needed to complete and objective. The tree diagram starts with one item that branches into two or more, each of which branch into two or more, and so on. The finished diagram bears a resemblance to a tree, with a trunk and multiple branches.
It is used to break down broad categories into finer and finer levels of detail. Developing the tree diagram helps you move your thinking step by step from generalities to specifics.
WHEN TO USE A TREE DIAGRAM
When an issue is known or being addressed in broad generalities and you must move to specific details, such as when developing logical steps to achieve an objective
When developing actions to carry out a solution or other plan
When analyzing processes in detail
When probing for the root cause of a problem
When evaluating implementation issues for several potential solutions
After an affinity diagram or interrelationship diagram has uncovered key issues
As a communication tool, to explain details to others
TREE DIAGRAM PROCEDURE
Develop a statement of the goal, project, plan, problem, or whatever is being studied. Write it at the top (for a vertical tree) or far left (for a horizontal tree) of your work surface.
Ask a question that will lead you to the next level of detail. For example:
For a goal, action plan, or work breakdown structure, ask: "What tasks must be done to accomplish this?" or "How can this be accomplished?"
For root-cause analysis, ask: "What causes this?" or "Why does this happen?"
For a Gozinto chart, ask: "What are the components?" ("Gozinto" literally comes from the phrase, "What goes into it?")
Brainstorm all possible answers. If an affinity diagram or interrelationship diagram has been done previously, ideas may be taken from there. Write each idea in a line below (for a vertical tree) or to the right of (for a horizontal tree) the first statement. Show links between the tiers with arrows.
Do a "necessary-and-sufficient" check. Are all the items at this level necessary for the one on the level above? If all the items at this level were present or accomplished, would they be sufficient for the one on the level above?
Each of the new idea statements now becomes the subject: a goal, objective, or problem statement. For each one, ask the question again to uncover the next level of detail. Create another tier of statements and show the relationships to the previous tier of ideas with arrows. Do a "necessary-and-sufficient" check for each set of items.
Continue to turn each new idea into a subject statement and ask the question. Do not stop until you reach fundamental elements: specific actions that can be carried out, components that are not divisible, root causes.
Do a "necessary-and-sufficient" check of the entire diagram. Are all the items necessary for the objective? If all the items were present or accomplished, would they be sufficient for the objective?
TREE DIAGRAM EXAMPLE
The Pearl River, NY School District, a 2001 recipient of the Malcolm Baldrige National Quality Award, uses a tree diagram to communicate how district-wide goals are translated into sub-goals and individual projects. They call this connected approach "The Golden Thread."
The district has three fundamental goals. The first, to improve academic performance, is partly shown in the figure below. District leaders have identified two strategic objectives that, when accomplished, will lead to improved academic performance: academic achievement and college admissions.
Lag indicators are long-term and results-oriented. The lag indicator for academic achievement is Regents’ diploma rate: the percent of students receiving a state diploma by passing eight Regents’ exams.
Lead indicators are short-term and process-oriented. Starting in 2000, the lead indicator for the Regents’ diploma rate was performance on new fourth and eighth grade state tests.
Finally, annual projects are defined, based on a cause-and-effect analysis, that will improve performance. In 2000-2001, four projects were accomplished to improve academic achievement. Thus, this tree diagram is an interlocking series of goals and indicators, tracing the causes of systemwide academic performance first through high school diploma rates, then through lower grade performance, and back to specific improvement projects.
Data Scientist is a new breed of analytical data expert who have the technical skills to solve complex problems – and the curiosity to explore what problems need to be solved. They’re part mathematician, part computer scientist and part trend-spotter. It is the application of data and behavioral science that gives you a 360-degree view to understand the "why" of the data presented to solve for X on a human level.
The application today, it is no different than when I started my career in the 1990s. Much of what we learned and applied back then; you find in textbooks on the subject today. We were just a head of our time, blazing a trail into a new and budding industry, to solve for complex problems on a human level.
The Art of Root Cause Analysis (Quality Progress) Five whys analysis is the art of systematically drilling down to a real root cause. Essentially, you can find the root cause of a problem and show the relationship of causes by repeatedly asking the question, "Why?"
Under Scrutiny (Quality Progress) A new definition of root cause could help people realize a systematic process beyond cause and effect is needed for root cause analysis.
Digging For the Root Cause (Six Sigma Forum Magazine) At the philosophical level, there is no absolute root cause in the infinite chain of causation. With this concept in mind, the challenge is to know when to stop drilling down and conclude the root cause has been reached. In Six Sigma training there are three keys that can help achieve that end, which this article explores.
The Impact Of Human Factors On Lead Time (Journal for Quality and Participation) EDR, a provider of property management software solutions, applies the DMAIC process to uncover and address the root causes of a customer lead time problem.
Root Cause Analysis for Beginners, Part 1 Jim Rooney, an ASQ Fellow and quality veteran with more than 30 years' experience in numerous industries, walks through the basics of root cause analysis in this first of a two-part webcast series.
Root Cause Analysis for Beginners, Part 2 Jim Rooney, an ASQ Fellow and quality veteran with more than 30 years' experience in numerous industries, walks through the basics of root cause analysis in this second of a two-part webcast series.
Getting The Defects Out Of Root Cause Analysis In this 50-minute presentation, author Duke Okes introduces root cause analysis, covering topics including defining important terminology, describing types of causes, determining how deep to take an investigation, defining the problem clearly, and more.
What is the application of a tree diagram (root cause analysis) in addition to the application of human behavior? That's a Data Scientist. Simply put, without understanding the variables of internal and external