Hindsight not Always 20/20 with Problem Management

When you're studying an incident, you need to be careful not to let hindsight ruin your efforts. Our columnist walks you through how to handle the review process to get the best insights.
Posted September 22, 2004
By

George Spafford

George Spafford


(Page 1 of 2)

How often have you reviewed an incident and asked, ''How could they fail to see the cause of the error before it became such a huge problem?''

Certainly there are benefits to reviewing a negative event, or series of events, and determining how to prevent them. During the review process, what must be avoided is allowing knowledge of the outcome to cloud your judgment. The affect on perception due to the knowledge of the subsequent outcome is known as ''hindsight bias'' and it can definitely affect the quality of the review process in a negative manner.

People involved with problem management must avoid this phenomenon and ask probing questions that dig deeper into the causal elements of the incident, gaining better insight.

Essentially, once you know the outcome of a chain of events, you tend to view all actions performed and decisions made through the lens of the final outcome.

For example, a series of warning alarms go off in a sequence never before considered. Shortly after, the system begins to fail and the operator makes matters worse by making a decision on the spot with very limited information and time. In going back over the accident, it is very clear to the reviewer that the chaotic warnings were indicating that a key subsystem was failing because the incident report lists the failure in detail.

In hindsight, it's obvious. But in the heat of battle, it may have been anything but obvious for a variety of reasons.

Organizations must take care not to rush to judgment prematurely. Far too often these days, groups are deploying systems with little testing, little to no documentation, and virtually no training. And in this day of compressed time and high-speed systems, once the operators do encounter an issue, the issues often compound and mushroom out of control at amazing speeds.

How can any operator, or group of operators, be expected to effectively respond without proper training and support mechanisms?

In short, they can't.

Problem Management

From ITIL, we know that Problem Management essentially involves focusing on an incident, or series of incidents, in order to identify underlying causal factors -- ''problems'' -- to prevent repetition. In order to identify the root causes accurately, problem managers and problem review boards must beware of allowing hindsight bias to cloud the problem review process, allowing for oversimplification and/or the personalization of causality.

In other words, a board must not look at an accident and literally say, ''The sequence is so simple! How could they miss it? It must be operator error.''

When complex systems are involved, there are often far more contributing factors than one might initially think.

Focus on the Processes

First and foremost, instead of personalizing the causality and blaming the operators, reviewers must recognize that there very often are levels of complexity beyond what is superficially visible. Furthermore, they need to take a step back and look at what key control points and processes are lacking.

For example, without exception, as the level of complexity increases in a system, the value of an effective change management process increases. Yet, this incredibly valuable process and the associated controls are all too often overlooked or even discounted as too bureaucratic. Returning to the point, a great many problems are rooted in process failures that are exacerbated by the human element being involved.

Continue on to find out what questions will get you the answers you need...


Page 1 of 2

 
1 2
Next Page





0 Comments (click to add your comment)
Comment and Contribute

 


(Maximum characters: 1200). You have characters left.