Three Accident Investigation Traps
How Can You Avoid These Three Accident Investigation Traps By Using TapRooT® RCA?
In the video below, Johan Bergstrom from Lund University explains three accident investigation traps:
- Counterfactual Reasoning
- Normative Language
- Mechanistic Reasoning
Watch the video below, and after it, we will discuss how to avoid these accident investigation traps by using TapRooT® Root Cause Analysis (especially proper use of the SnapCharT® Diagram).
That was a rather complex description of how investigators may jump to conclusions, put words or ideas of the people involved in an incident in their mouths, and conclude that safety systems worked while the humans failed. Let us look at each of the three accident investigation traps in more detail and how an investigator using TapRooT® RCA and a SnapCharT® Diagram could (and if used properly should) help you avoid these traps.
Counterfactual Reasoning
The counterfactual trap deals with “did not” statements or statements like “would likely” or projecting their beliefs by saying that if something, then someone “would have.”
How do you combat this type of accident investigation trap?
Use your SnapCharT® Diagram and only record things that did happen rather than things that people didn’t do.
The events on a SnapCharT® Diagram should be things that happened.
For example, if an operator opened valve 40B but by the procedure, they were supposed to open valve 40D, the action step would be “Operator opened valve 40B.” Then as a condition under that step, the investigator could write, “The procedure called for opening valve 40D.” Also, any factors that could cause confusion for the operator could be listed. For example, if the operator did not have a copy of the procedure and was being read the directions over a radio with intermittent reception (some communications would be truncated or cut off near the end) would be a condition about this step. That the operator thought he heard 40B, and the person reading the procedure swore they said 40D, would also be conditions (and perhaps be in dotted ovals unless you could confirm what was said and what it sounded like).
When you stick to the facts written by the evidence you collect and not by what you think happened, you will avoid counterfactual reasoning.
Normative Language
Normative language happens when the investigator’s judgment becomes a part of the investigation. One example they use is the investigator saying the flight crew “mismanaged” the airplane’s vertical profile.
Once again, the investigator is not listing a fact but rather their evaluation of the situation.
In the example, using a SnapCharT® Diagram, the investigator could record what did happen. In the example, they could report the airplane was at 5000 feet when it reached the five mile point as an event. They could then record the decent rate that the pilot used to make an approach as another event. These are facts without judgment.
If actions were unusual or exceeded guidelines, the guidelines could be listed as conditions under the event. Also, if the pilot was alive to be interviewed, the pilot’s explanation for the actions could be added to the SnapCharT® as conditions, and the investigator could look for factors (displays, automation actions, automation failure, or other factors) that the pilot described as influencing their decision.
Of course, it is much easier to decide what the pilot was doing and thinking by substituting your judgment for facts, but this becomes normative language.
Mechanistic Reasoning
When investigators try to eliminate working systems and find those malfunctioning, Johan calls it mechanistic reasoning.
Once again, you can include on your SnapCharT® that the automation was working as designed, but that doesn’t mean that the interface between the automation and the human was clearly displaying what was happening with the automation to the human.
Again, on your SnapCharT® Diagram, you should record what was happening, what the operator thought (as they described to you), and how the operator’s perception of what the automation was doing was different from what the automation was actually doing. That might lead to an understanding of why the operator thought that the actions taken by the automation were and how those actions were different than the actual actions that were occurring.
For example, if the throttles were thought by the pilot to be in automatic mode but, because of some combination of functions and design parameters, the throttles were actually in manual mode, the pilot wasn’t “slow to react” to an underpowered approach. Rather, there was a reason why the pilot did not discover the mode was manual until they were 100 feet below the glide slope guidance just short of the runway.
Trivial or Important?
Some might say that these three accident investigation traps are trivial differences. That the NTSB investigator was stating what they thought was true.
However, when investigators start making assumptions and judgments and then jump to conclusions, they can miss reasons that people do things that contribute to an accident. The investigator is quietly inserting blame into the investigation. The blame gets in the way of discovering actual factors that can be corrected so that others don’t have the same reactions that lead to accidents.
I once talked to a pilot that had survived a crash and went to the NTSB presentation of the investigation to the NTSB Board. He said it was like an out-of-body experience. One of the board members asked the investigator about what the pilot was thinking. The investigator replied. The pilot said that no investigator had ever asked what he was thinking, so the answer was a total fabrication.
Don’t be that investigator. Base your investigation on facts. Even if you ask, you probably won’t know for sure what was going through the person’s head when they made a decision. No matter what they tell you, you can’t substitute your ideas, beliefs, and judgments for the people involved in the accident. That is what makes accident investigations so difficult.
One more thing. If you think you know something but don’t have two sources of information to verify it, use the dotted lines on your SnapCharT® to indicate that your thought is an assumption.
Learn More About TapRooT® RCA
Of course, investigating an aircraft crash is a complex task. Not something that an inexperienced investigator should tackle alone. Therefore, we recommend extensive training, practice on smaller incidents, and coaching for any investigator preparing for complex investigations.
We suggest attending the 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Course. When and where are our public 5-Day TapRooT® Courses? CLICK HERE for upcoming dates and locations.
If you would like to schedule a course at your site, CLICK HERE to send us a note, or call one of our TapRooT® Implementation Advisors at 865-539-2139.
