The Naivety of 5 Why's

There are many approaches to Root Cause Analysis: [1]

• Events and Causal Factors
• Change Analysis
• Barrier Analysis
• Tree Diagrams
• Why-Why Chart
• Pareto
• Story Telling
• Fault Tree
• Failure Mode and Effects Analysis

The?Why-Why approach, or the 5-Whys created by Sakichi Toyoda, is common in Agile and Lean and involves asking?why something happened and asking that same question again in a search for the cause-and-effect relationship of the underlying problem until the root cause is found.?

This simplistic approach asks the question?five times until you can no longer answer it. Five is an arbitrary number. This method produces a linear set of causal relationships and uses the problem owner's experience to determine the root cause and corresponding solution. [2] The Five Whys method is inappropriate for any complex event but can be helpful for minor problems requiring an introductory discussion of an event.

The Five Whys root cause analysis proposes that if you retrace the chain of causes that led to a particular event, you will eventually find the single reason that set everything else in motion, known as the "root cause." The theory is that finding and eliminating this single root cause will solve the problem.

Like a string of falling dominos, when we ask why, why, why, like the conventional Five Whys method, we believe that A caused B, B caused C, C caused D, and somewhere at the end of this causal chain there is a magical single cause that started everything, i.e., the root cause. In the thirteenth century, St. Thomas Aquinas of Sicily taught us the fallacy of this strategy when he proposed that "potency cannot reduce itself to act." Or, as he clarified with this example, "the copper cannot become a statue by its existence." It requires the conditional cause of the copper's existence and the actions of a sculptor. Unfortunately, this simple and essential observation has not been understood or incorporated into everyday Thinking, and most people continue to see the world linearly. [3]

We have been led to believe that effective problem-solving can be had by finding the root cause at the end of a chain of causes. This makes sense but needs to be more complex on examination because it ignores the infinite set of causes. Our world is not linear; therefore, this logic needs to be more complex and grossly compelling. As we have seen, our world comprises infinite causes, all connected through causal relationships. Feedback loops complicate some of these relationships. Some causes seem to come out of nowhere (the subconscious mind), but all should lead to a point of ignorance. Our knowledge and understanding of the problem determine the beginning and end of causation.

Once we understand the nonlinearity of our universe, limiting ourselves to a linear understanding, such as the Five Whys method, makes for terribly ineffective solutions. By understanding that infinite causes are connected in many ways, we see that many possible solutions exist. We may only need to affect one cause in a chain so that the problem does not occur—or we may need to attack several causes.

An Example of the Naivety of Five Whys

Using the Five Whys approach suffers from the typical problem-solving practices of:

• Stopping too soon—asking five questions ignores the fact that there may be dozens of questions that need to be asked before we find the terminal cause. When we reach the end of the questions, another set of causes may exist.
• The need to place blame is the belief that individuals need to be identified and their behaviors corrected to remove the cause.
• The root cause myth - the myth that root causes have solutions that can be acted upon by removing, changing, or controlling them so the problem does not recur.
• The false belief in common sense and a single reality—if the perception is reality and everyone's reality is unique, what is fact or truth? Everything is relative to our truths; the best we can hope for is to find a way to incorporate other people's truths into ours.
• Groovenation - is a term created by Dean Gano in [2] to describe the justification of beliefs. To be?groovenated is to hold solid biases and prejudices.?
• Storytelling —Our primary form of communication is storytelling, which describes an event that relates people (who), places (where), and things (what) in a linear time frame (when). Incident reports in search of the root cause are a prime example.?
• Categorical Thinking is caused by the mind's need to order what it perceives, and it is a natural process. However, it allows us to need help understanding how categorization can lead to intellectual laziness. Notions of?good and?evil are categorical Thinking. Instead of seeking to understand, the observed outcomes and the related root causes are categorized as good or?bad. It's not the categorization itself that is the problem; it is the belief that relationships can be established once categorized. Categorization is strongly linked to storytelling.

Cause and Effect, the chancellors of God - Ralph Waldo Emerson, 1856

Nothing happens without a cause. [2]

• Cause and Effect are the same thing.
• Causes and Effects are part of an infinite continuum of causes.
• Each Effect has at least two causes: a?Condition and an?Action.
• An effect exists only if its causes and actions exist at the same point in time.

The 5 Ways address NONE of these required conditions to find the?root cause.?

• What are the conditions that prevent the software from functioning correctly?
• What actions are taken on the part of the software and the user that result in non-functioning outcomes
• At what time do these non-functioning outcomes occur

In the Root Cause analysis method, used by NASA, the National Nuclear Security Agency, many services in the DOD, and most all of OSHA 1910.199 (Process Safety Management) root cause analyses, we perform by asking an answering

We can now go back to the resource and start to ask and answer, but these answers must be in the form of three elements - the Effect, the Action that creates the Effect, and the Condition that allows the Action to create the Effect.

— Primary Effect – is any effect we want to prevent

— Action – momentary causes that bring conditions together to cause an effect

— Conditions – the fundamental causal element of all that happens. It comprises an effect and its immediate causes representing a single causal relationship.

• As a minimum, the causes in this set consist of an action and one or more conditions. Causal sets, like causes, cannot exist alone. They are part of a continuum of causes with no beginning or end, which leads us to the following principle: Causes and Effects are Part of an Infinite Continuum of Causes.

To create this chart above, there are Seven steps [3], [4]

— Define the problem

• What is the primary Effect that creates the problem?
• When does this Primary Effect occur?
• Where is the Primary Effect seen?
• What is the significance of the Primary Effect and its impact on the goals of the project or operations?

— Determine the Causal Relationships between each Action or Condition cause

• For each Effect in the chart beyond the Primary Effect, define a Cause By Effect that is an Action or a Condition

— Make a graphical representation of the Causes, labeling each as?a Condition or?Action.

— Provide the evidence that can be

• Observation - I saw it
• Written - I read it
• Verbal - I was told it
• Sound - I heard it
• Sensed - I smelled it
• Touch - I felt it

— Determine if the Causes are Sufficient and Necessary

• For each cause on the path in the chart, provide the reason for stopping, any feedback loops (one cause ending that starts another cause), and how to obtain the information needed?

— Identify the Effective Solutions for each Cause

—Implement and Track the Identified solutions?

With this approach, we can see that cause?and Effect?are the same thing

Then, of course, I need to do more investigation as to why the seal was maintained. The method used in our Software Intensive System of Systems domain, ranging from Enterprise IT, Cyber Security, manned and uncrewed space flight, petrochemical process plants, all the way to nuclear weapons, design, development, and testing, treats the Root Cause Analysis process as having potential an infinite number of causes (conditions and actions)

A Case Study Using Flawed and Naive Root Cause Analysis

The PMI Disciplined Agile approach to root cause analysis provides an example that makes a good case study of why the 5 Whys is naive, flawed, and doesn't find the cause of the problem, only collects a set of symptoms that require further Root Cause investigation:

• Q1: "Why are we having to rework the system?"
• A1:" Because the programs do not function properly on our customers' servers."
• Q2: "Why do the programs not function properly on our customers' servers?"
• A2: "Because the code was designed one way, but the servers are configured for another way."
• Q3: "Why are our customers' servers being configured differently from how it was expected?"
• A3: "Because our customers are not following our guidelines for server configuration."
• Q4: "Why are our customers not following our guidelines for server configuration?"
• A4: "Because they aren't aware of the guidelines."
• Q5: "Why aren't these customers aware of them?"
• A5: "Because sales, who is supposed to make sure they know of this configuration requirement, isn't telling them."
• Q6: "Why isn't sales telling our customers they need to do this?"
• A6: "When a customer is ready to buy, sales tend to shut up and get the contract signed. Closing the deal seems to be the most important thing to sales."

The Five Whys suffers from three flaws:

• Incomplete problem definition - we communicate by telling each other stories because we don't think causally, and we then infer. The software must function correctly because it was misdesigned (Q1,2/A1,2). What's the evidence that the software is not functioning correctly? What's the definition of?properly? What were the initially needed capabilities observed as not functioning correctly? What's the evidence it was designed wrong?
• Unknown causal relationships - causal relationships often remain unknown because we do not think causally; instead, we communicate by storytelling, making inferences surrounding the stories, and considering those stories as causes. Regarding human error, lack of training,?and other categorical causes like?management?or user inaction (Q3,3/A3,4), What's the evidence that customers need to follow our guidelines? Do you know if our guidelines are adequate for properly using our software? Are the customers trained and verified to enable them to follow our guidelines? What's the?reason?they need to follow our guidelines? Need more time? Overworked? No access to instruction at the time of need? Please let me know why customers are aware of this.?(Q5,6/A5,6) What's the evidence that sales need to tell customers what they need? Why is this a sales task and not a training and support task? What's the cause of?sales tending to shut up?
• A focus on the solution - by focusing on solutions without clearly and concisely defining the problem and the cause of the problem, we end up solving the wrong problem. Focusing on solutions is often caused by Groovenation, where we think we already know the solution before and we know what the problem is. A use that?false belief and cease to look further?

References

With these starting points, here is a compendium of resources we use in our software-Intensive Systems domain for determining the Root Cause and identifying the corrective and preventive actions needed to Handle the risk created by the Root Cause.

1. Root Cause Investigation (RCI) Best Practices Guide Product Overview, May 8, 2014, Roland Duphily, Acquisition Risk and Reliability Engineering Department Systems Engineering Division Prepared for National Reconnaissance Office 14675 Lee Road, Chantilly, VA 20151-1715
2. Apollo Root Cause Analysis: Effective Solutions to Everyday Problems Every Time, 3rd Edition, Dean L. Gano, Apollonian Publications, LLC, Richland Washington.
3. Seven Steps to Effective Problem-Solving and Strategies for Personal Success, Dean L. Gano, Apollonian Publications, LLC, Richland Washington. (A National Nuclear Security Agency (NNSA) site).
4. "Reality Charting: Creating the Reality Chart," Apollonian Publishing, 2017.
5. Dean Gano participated in the Root Cause Analysis of the Three Mile Island nuclear power station accident. The common understanding was a?stuck coolant valve, and that's when the public came to consider the root cause. The actual?root cause was the alarm printer indicating the valve was stuck, which was many minutes behind real-time. Had the operators been aware of the stuck value in real-time, they would have initiated corrective Action, and we'd have nuclear power in America today.