The Logic of Root Condition Analysis (2/6)

The Logic of Root Condition Analysis (2/6)

By Discovery Lean Six Sigma

0/5 stars (0 votes)

The Logic of Root Condition Analysis (2/6)

Problem-solving and particularly the part that focuses on root cause analysis (RCA) has always been one of the topics that has had my special interest. Specifically, two questions always slumbered in my head, viz. (1) whether you could speak of one root cause, or that you should speak of multiple (root) causes; and (2) whether you should speak of the root cause or rather the root condition. In a series of six posts, I will try to explain how rigorous problem-solving logic (using an example) can help us answer these questions. At the same time, I hope the example and the logic will be of use in your problem-solving efforts or your coaching thereof. This second post will introduce concepts like necessary condition, defensive and control barrier, and will apply these to our example.


In the first post, I set the stage by defining the starting points and some basic initial concepts (like problem, cause, agent, target, event and Tripod Beta’s causal diagramming technique). I also introduced an example that I will use throughout the series. In this second post of this series of six, I will continue to introduce some more concepts (necessary condition, defensive and control barriers) and will again apply these concepts to the example.

A Necessary Condition is Not Enough for a Problem

Let’s introduce a few more typical concepts that you can come across in RCA.

A necessary condition: if x is a necessary condition of y, then the presence of y necessarily implies the prior occurrence or presence of x. The presence of x, however, does not imply that y will occur. There can be multiple necessary conditions, sometimes also referred to contributory conditions. A necessary condition is not so much an event, but a state or situation (that typically exists in multiple instances of the type of task that only in this instance has led to the undesirable change).


Let’s go back to our example where the person concerned was standing on a vehicle, not wearing a hard hat. The person was hit by a rolling pipe while these were being loaded onto the same vehicle on which the person was standing. The person was consequently knocked off, making the person fall with his head onto a hard floor which led to the head injury.

When discussing the cause of this problem, it could very well be that someone brings up that the person was not wearing his hard hat. But not all people not wearing a hard hat fall from a vehicle. It is a necessary condition, but in itself not sufficient to create the problem. It could well be that people were not wearing their hard hats already for weeks, loading pipes onto vehicles, and nothing happened.

In the same sense, the hard floor (the agent) is also a necessary condition.


As the presence of a necessary condition does not imply that the event leading to the problem will necessarily occur, it cannot be considered the cause of the problem. Also, to define a root cause as a factor that, when removed, prevents the problem from recurring is therefore incorrect.

To be clear, the elimination of the necessary conditions will prevent the prime event and the subsequent problem from happening. But it is not the cause. We will come back to the nature of such necessary conditions and the measures to eliminate these conditions later in this post.


If, in our example, the person would have worn his hard hat during this operation, this would have prevented the causing event and the subsequent problem. But it is not the cause, as people not wearing their hard hat do not fall from vehicles and suffer head injuries all the time. As the type I, gap-type of problems already indicates, we need to understand what was different this time.


Barriers and Necessary Conditions

In Tripod Beta, incidents can be prevented by so-called barriers. A barrier that prevents an agent to (wrongfully) act upon the target is called a control; a barrier that prevents a target to be (undesirably) exposed to an agent is referred to as a defense. As an example, an agent and a target can be kept apart from each other in time and space using physical barriers. But adequate and respected policies can also fulfill the role of a barrier. In a chain of events, barriers may also stop the chain of events, before things turn to worse and the prime event happens.


In our example, the person’s head suffering the head injury is the object being changed; the hard floor on which he fell the agent. It was the floor that created the injury. There was no control preventing the impact on the person (like a soft floor, or a temporary measure during work at height, like a mat, that could have reduced the impact). At the same time, there was no defense for the person’s head in the form of the already mentioned hard hat.


The purpose of a barrier, therefore, is to prevent a causing event. The lack of an adequate barrier leads to the development of a necessary condition.

Applying this to our causal diagram, our example now looks like this:


BarriersFigure: control and defense barriers that could have prevented the specific problem.


We will come back to the measures to eliminate necessary conditions through effective barriers in a later post. But we don’t want to jump to conclusions.

Next Post: Continuing the Logic

In the first post, I set the stage by defining the starting points and some basic initial concepts (like problem, cause, agent, target, event and Tripod Beta’s causal diagramming technique). This post introduced a few more concepts (like necessary condition, defensive and control barriers). In the third post of the series, I will dive into tracing back the causal event chain introducing and applying concepts like causing events, the initial causing event, and the initial active cause to our example.


The post The Logic of Root Condition Analysis (2/6) appeared first on Dumontis.

By: Rob van Stekelenborg
Posted: November 12, 2017, 5:46 pm

comments powered by Disqus

Discovery Lean Six Sigma

Dummy user for scooping articles

I'm a dummy user created for scooping  great articles in the network for the community.