One Root Cause

One Root Cause

Post by CatalinaNJB


There can only be one root cause when analysing an occurrence for the root cause. The objective with a root cause analysis is to identify the time and location when a different direction would have generated another outcome. At that time of intercepting time and location, or the fork in the road, a risk assessment is applied to the decision in form of a checklist risk assessment tool, or in the form of a crew-experience risk assessment tool. A risk assessment in the form of a predetermined checklist decision maker, or crew-experience risk assessment tool could have produced two different outcomes. Not only is the fork in the road a point when a decision needs be made of what action to take but is also a time to make a decision of what risk-assessment tool should be applied. 

The root cause is what supports a system in operations

What if there could be more than one root cause. In a different scenario and if several root causes were identified, this would require operators to develop corrective action plan (CAP) for each one of the root causes and to implement multiple CAPs, for all root causes. 

Since there are several root causes, the weight of each corrective action plan would be applied indiscriminately equal to each one. If the weights of each CAP are assigned different weight, then the one with most weight becomes the primary root cause and the other are secondary root causes. Still, with this scenario we are back to one root cause.

"So, what is actually a root cause?"

The root cause of a nonconformity or an undesirable event, is the course of action applied at a decision point within a process at a “fork in the road”. In other words, at the point when there is a time or location to make a decision (which there will be). That decision is based on data, information, knowledge and comprehension of how interacting systems may shape the future. A root cause is not just something to consider when things go wrong but is something to consider when things are going right. There are no reasons to wait for something to go wrong before assigning a root cause. In an SMS world root causes are identified proactively. The question then becomes how to identify a root cause before an event has occurred. It’s just as simple as identifying the root cause after an event. The root cause is based on the safety risk level in the risk assessment. Prior to changes or implementation of new processes a risk assessment should be conducted. In this risk assessment the risk is accepted with the known hazards or accepted with mitigation of these hazards. Simple example of mitigation is that an airplane is de-iced prior to departure when icing conditions exists. 

A risk analysis sets the bar and draw the line in the sand

Going a step further with the de-icing scenario, it is already known what the root cause is if the aircraft departs in icing condition and crash-lands in the trees. The root cause is not that the airplane was not de-iced, but that the de-icing system is broken down. This is simply known by the fact that flight crews operating in icing conditions have knowledge of the effect of ice on critical surfaces, but elected not to apply the mitigation of de-icing. 

The flight crew did not comprehend the de-icing system. There was no comprehension of how other systems interact with other systems. (If it was, it is assumed that the flight crew would not depart in icing conditions without mitigation). There are several systems included in a de-icing system, being environmental factors, human factors, organizational factors, supervision factors, technical factors and performance factors. The process flow of system comprehension is derived from data (collected by hazard reports), information (data is turned into information), knowledge (absorbed information) and comprehension (interacting systems) When comprehension is missing the system is faulty, or data is not analyzed, system comprehension is faulty. This faulty system comprehension does not rest with the flight crew but with the operator. 

It is the organization that conduct the risk assessment and what mitigation to apply for operations of the de-icing system. This risk assessment includes environmental factors. Is the de-icing equipment suitable for that type of aircraft? A spray bottle is no suitable to de-ice a large passenger jet. Human factors are assessed of what impact on the deicing system the flight scheduling might have. Organizational factors may have overlooked holdover times weather information availability. Supervision factors may have expected the flight crew to “remember” to de-ice with another million tasks to take care of on this flight. There might be other technical factors causing a de-icing unit to malfunction, or the operator accepted standard performance data for takeoff. All these factors are affecting the total de-icing system, which is the system that makes the airplane fly after takeoff. 

With all this information, the root cause becomes predictive in scope that there is a high probability and above an acceptable risk level of an aircraft incident while operating in icing condition if the operator overlooked or disregarded one or more of these affecting factors. The root cause to prevent an aircraft crash in icing condition is an organizational system that had a catastrophic failure. This is simply true since an operator under these conditions did not comprehend the complete de-icing system…which makes it only one root cause. 

CatalinaNJB