Hello and welcome to this week’s column focused on interviewing and evidence collection for root cause analysis of workplace incidents and accidents. Last week we talked about the value of a planning SnapCharT®. I’d like to take a moment to expand on that thought.
Grasping at the “why” before the “what” is a common mistake that even experienced investigators make. But you have to understand “what” happened before you can understand why it happened. The goal of interviewing and evidence collection is to provide facts for the “what” so you can continue with the “why” (identifying causal factors and root causes).
When I worked in the legal field, I felt that most investigations were hypothesis-based. It seemed that more often than not, we started with several hypotheses and then began a process of elimination until we were left with one we liked. Instead of collecting evidence before we determined “why” an incident happened, we came up with our guesses and then looked for evidence that supported the guesses.
When an investigator reaches for the “why” before the “what,” this is what occurs:
- Tunnel vision. The investigator only focuses on the hypotheses presented, and none of them may be correct.
- Abuse of evidence. The investigator may force the evidence to “fit” the hypothesis he/she feels most strongly about. Further, any evidence collected that does not fit the hypothesis is ignored or discarded.
- Confirmation bias. The investigator only seeks evidence that supports his/her hypothesis.
It is a tenet of psychology that the human brain immediately desires a simple pattern that makes sense of a complex situation. So, there is really nothing that the investigator is intentionally doing wrong when he or she falls into that trap. Not to mention, humans simply do not like changing their minds when they become emotionally attached to an idea. And then there is social pressure… when a strong personality on the investigation team thinks he/she knows the “why” – and the rest of the team goes along with it.
TapRooT® helps investigative teams avoid reaching for the “why” before the “what.” The 7-Step Major Investigation Process taught during our 5-Day training offers a systematic way to move through the investigation and takes the investigator beyond his/her knowledge to determine the “what” first so that the causal factors and root causes identified are accurate. Learn how to collect the evidence you need to understand the “what” in our 1-day Interviewing and Evidence Collection Techniques course on November 8 in Houston, Texas.
Have you fallen into the trap of trying to decide the “why” before the “what”? Do you have something additional to share about this common problem? How has TapRooT® helped you avoid it? Comment below and be entered into our August drawing to win a copy of our new “Evidence Collection and Interviewing Techniques to Sharpen Investigation Skills” book!
Category: Investigations, Root Cause Analysis Tips, Root Causes
2 Comments »
RSS feed for comments on this post.
Several years ago, I was involved in an investigation of some electrical gear that was severely damaged upon start-up immediately following a PM service — what seemed to be a “Maintenance Induced Failure” as we called them. Early on in the investigation, a mechanical defect was discovered that could only have resulted from human error during the Preventive Maintenance. This defect could have produced the sequence of events leading to the damage and was the original conclusion of those first involved in the investigation. Digging deeper, there were electrical controls in place that should have detected the mechanical defect and provided interlocks to shut down the system and prevent the damage, yet these interlocks hadn’t activated.
Ultimately, we determined that a single electronic control relay received inputs from the electrical controls — this relay served to shutdown the system started by another controller, and this relay had suffered a failure on start-up — it wasn’t required as a permissive to let the system start, but was required to cause a shutdown on failure. But, since it wasn’t working itself, it failed to force a shutdown when necessary. The failed controller also provided an analog input signal to the overall process controller. The start-up technician had commented to others, “Hey, I’m not seeing an indication of process conditions on the screen,” something that was chalked-up at the time to an instrumentation error, that would be addressed after start-up.
Grabbing the first reasonable “Why” that had been identified would have led to a failed root cause analysis (and probable firing of one or more personnel), but digging deeper and completing a thorough investigation illustrated the true root cause and led to appropriate corrective and preventive measures.
Marty Krongold
TapRooT(R) Trained – 2015
Comment by Marty Krongold — June 7, 2017 @ 4:52 pm
Thanks for sharing, Marty! That’s a great example.
Comment by Barb Phillips — June 30, 2017 @ 2:41 pm