October 24, 2018

Without a Root Cause Analysis, No Corrective or Preventive Action is Credible - Part 1

When you hear project failure statistics, and no Root Cause for those numbers, there is no hope that any suggested corrections can be credible. As well when you hear those statistics, many times those numbers have no credibility themselves to start with.

But before going further, let's establish the definitions we need to understand and apply Root Cause Analysis needed to discover the corrective and preventive actions to increase the probability of project success - especially Software Project Success. AND to learn how to detect the bogus approaches to solving problems we see everywhere in software development.

A Correction fixed the immediate non-conformance. Corrections can stop the bleeding but do not necessarily address the underlying reasons for the wound.

A Corrective Action addresses the cause of the non-conformance do it does not reoccur. Corrective actions are put in place to address the "reason" for the bleeding and prevent additional wounds from occurring from the same cause.

A Cause is an answer to a why question. It should be stated as a noun and verb it comes in two forms - an action cause and a condition cause.

Root Cause is any cause in the cause continuum that is acted upon by the solution so that the problem does not recur. It is not the Root Cause we seek, it is effective solutions that are sought.

Root Cause is the fundamental initiating cause on a causal chain leading to a failure of a process which results in a recurrence of the problem.

Root Cause is the factor that, when addressed and corrected, ensures that the problem does not come back.

Root Cause Analysis is a systematic documented approach to arrive at the true Root Cause of the process problem.

This last statement needs further clarification,

Actions are momentary causes that bring conditions together to cause an effect.

Conditions are causes that exist over time before an Action brings them together to Cause an effect.

A fact is a cause supported by evidence. Facts outside of a causal relationship have no value.

Evidence is data used to conclude something. Evidence comes in different quality levels - sensed by the five senses, inferred, intuited, or emotionally sensed.

Event-Based Problems are centered around people, objects, and rules that occur in time and space. These type of problems are distinguished from rule-based problems by having more than one possible solution.

Rule-Based Problems do not require people, object, or time and space and always have a predefined right answer.

There are some more definitions needed before we get started,

Stakeholder is a term taken from Dr. Stephen Covey's Principle-Centered Leadership, describing all persons who have a stake in the success or failure of an enterprise or group.

Common Sense is the common feeling of humanity. Common sense is an illusion that results from ineffective problem-solving.

The True problem must be identified before any corrective or preventive action can be taken.

The causal chain of Actions and Conditions must be traced back to the initiating root cause. The outcome is not likely the root cause. An underlying factor or root cause is determined by a set of multilayered “why” questions or some other predefined method.

To the Big Foot hunter, all things point to the existence of a Sasquatch. If you've already decided what the cause of the problem is before you start looking for the Root Cause, you have inadvertently distorted the data to support your hypothesis.

The classic example is in Animal Planet's Finding Bigfoot where the investigators have pre-determined the cause of the occurrence. To them, any footprints found in the forest are Big Foot's prints. When the hunter state Sasquatch can disguise their voices to sound like other animals. So if you heard a coyote, it could be a Sasquatch ..."

Begin with an open mind, don't start looking for Big Foot.

An example of a Root Cause Analysis is Benjamin Franklin's Why Analysis †

For want of a nail a shoe was lost,

For want of a show a horse was lost,

For want of a horse a rider was lost,

For want of a rider an army was lost,

For want of an army a battle was lost,

For want of a battle the war was lost,

For want of the war the Kingdom was lost

All for the want of a nail.

Why All This Setup?

There is a group in our software development community that has a predefined solution to almost any common problem that - projects run over time and cost and don't provide the needed business value. This solution is usually proposed before the root cause is discovered.

#NoEstimates is the prime example of a solution looking for a problem to solve before any causes have been identified.

Part 2 will take these Root Analysis principles and apply them to actual software problems, and the fallacies that simple and simple-minded corrections will fix anyting - stay tuned.

References

† This proverb comes in many variations over the centuries. It describes a situation in which a failure to anticipate or correct some initially small dysfunction leads by successively more critical stages to an egregious outcome. Benjamin Franklin repeats it, in Poor Richard's Almanack, June 1758.

Anytime you hear the suggestion of any solution to any problem must have a set of principle on which to base that solution. When you hear a solution without references - reference that is not self-referenced or simple-minded reference, stop listening or reading. This approach is core to any credible improvements in our complex software development domains. This approach separates personal anecdotes from actual corrective and preventive actions to increase the probability of project success.

Comments

Without a Root Cause Analysis, No Corrective or Preventive Action is Credible - Part 1

When you hear project failure statistics, and no Root Cause for those numbers, there is no hope that any suggested corrections can be credible. As well when you hear those statistics, many times those numbers have no credibility themselves to start with.

But before going further, let's establish the definitions we need to understand and apply Root Cause Analysis needed to discover the corrective and preventive actions to increase the probability of project success - especially Software Project Success. AND to learn how to detect the bogus approaches to solving problems we see everywhere in software development.

A Correction fixed the immediate non-conformance. Corrections can stop the bleeding but do not necessarily address the underlying reasons for the wound.

A Corrective Action addresses the cause of the non-conformance do it does not reoccur. Corrective actions are put in place to address the "reason" for the bleeding and prevent additional wounds from occurring from the same cause.

A Cause is an answer to a why question. It should be stated as a noun and verb it comes in two forms - an action cause and a condition cause.

Root Cause is any cause in the cause continuum that is acted upon by the solution so that the problem does not recur. It is not the Root Cause we seek, it is effective solutions that are sought.

Root Cause is the fundamental initiating cause on a causal chain leading to a failure of a process which results in a recurrence of the problem.

Root Cause is the factor that, when addressed and corrected, ensures that the problem does not come back.

Root Cause Analysis is a systematic documented approach to arrive at the true Root Cause of the process problem.

This last statement needs further clarification,

Actions are momentary causes that bring conditions together to cause an effect.

Conditions are causes that exist over time before an Action brings them together to Cause an effect.

A fact is a cause supported by evidence. Facts outside of a causal relationship have no value.

Evidence is data used to conclude something. Evidence comes in different quality levels - sensed by the five senses, inferred, intuited, or emotionally sensed.

Event-Based Problems are centered around people, objects, and rules that occur in time and space. These type of problems are distinguished from rule-based problems by having more than one possible solution.

Rule-Based Problems do not require people, object, or time and space and always have a predefined right answer.

There are some more definitions needed before we get started,

Stakeholder is a term taken from Dr. Stephen Covey's Principle-Centered Leadership, describing all persons who have a stake in the success or failure of an enterprise or group.

Common Sense is the common feeling of humanity. Common sense is an illusion that results from ineffective problem-solving.

The True problem must be identified before any corrective or preventive action can be taken.

The causal chain of Actions and Conditions must be traced back to the initiating root cause. The outcome is not likely the root cause. An underlying factor or root cause is determined by a set of multilayered “why” questions or some other predefined method.

To the Big Foot hunter, all things point to the existence of a Sasquatch. If you've already decided what the cause of the problem is before you start looking for the Root Cause, you have inadvertently distorted the data to support your hypothesis.

The classic example is in Animal Planet's Finding Bigfoot where the investigators have pre-determined the cause of the occurrence. To them, any footprints found in the forest are Big Foot's prints. When the hunter state Sasquatch can disguise their voices to sound like other animals. So if you heard a coyote, it could be a Sasquatch ..."

Begin with an open mind, don't start looking for Big Foot.

An example of a Root Cause Analysis is Benjamin Franklin's Why Analysis †

For want of a nail a shoe was lost,

For want of a show a horse was lost,

For want of a horse a rider was lost,

For want of a rider an army was lost,

For want of an army a battle was lost,

For want of a battle the war was lost,

For want of the war the Kingdom was lost

All for the want of a nail.

Why All This Setup?

There is a group in our software development community that has a predefined solution to almost any common problem that - projects run over time and cost and don't provide the needed business value. This solution is usually proposed before the root cause is discovered.

#NoEstimates is the prime example of a solution looking for a problem to solve before any causes have been identified.

Part 2 will take these Root Analysis principles and apply them to actual software problems, and the fallacies that simple and simple-minded corrections will fix anyting - stay tuned.

References

† This proverb comes in many variations over the centuries. It describes a situation in which a failure to anticipate or correct some initially small dysfunction leads by successively more critical stages to an egregious outcome. Benjamin Franklin repeats it, in Poor Richard's Almanack, June 1758.

Anytime you hear the suggestion of any solution to any problem must have a set of principle on which to base that solution. When you hear a solution without references - reference that is not self-referenced or simple-minded reference, stop listening or reading. This approach is core to any credible improvements in our complex software development domains. This approach separates personal anecdotes from actual corrective and preventive actions to increase the probability of project success.