Home �   ITIL�  Index

Incident Decision Making and Cognitive Bias

Cognitive bias can and does get in the way of effective incident management, writes ITSM Watch columnist George Spafford of Pepperweed Consulting.
Jul 23, 2007

George Spafford

From an ITIL perspective, an Incident is a deviation from the normal operation of a system that impact, or may impact, the quality of a service. Rapid decision making around what has happened and how best to quickly restore service is critical as actions, or inactions, will affect customer satisfaction, costs, security and many other factors.

One challenge is that cognitive biases can, and will, affect personnel during these situations, especially ones involving high stress.

A cognitive bias is anything that affects how we perceive reality. To improve the Incident Management process, it would behoove IT groups to recognize biases and consider means to counter them. The following are some of the many cognitive biases that a group may encounter:

Anchoring - This refers to taking the first piece of evidence and then relying on it too heavily at the expense of later evidence. Imagine seeing a network traffic spike just before a system crashes and then focusing on the spike as to why a system crash versus equaling weighing other evidence collected later.

Attribution Errors - When a user calls in for assistance with an incident, there is a tendency to place too much emphasis on the person calling and to de-emphasize the situation at hand. If a caller is type-cast as a problem user, the tendency will be to immediately think it is something he did wrong versus listening to the symptoms of what is going on as communicated by the user and investigating accordingly.

Bias Blind Spot - People tend to not know their biases and what bias(s) are affecting them during decision making. A database architect may be diagnosing an Incident and not realize that he is succumbing to one or more biases such as anchoring.

Confirmation Bias - This relates to people interpreting new data in a means that confirms previously held beliefs. If a network engineer believes that network congestion is an issue then he will collect and review incident data in such a way that it confirms his beliefs and discount the data that does not.

Déformation Professionnelle - This interesting French phrase relates to one’s profession affecting how one makes decisions. A developer may focus her efforts entirely on a possible application defect versus viewing the incident at a higher level and realizing that the cause of incident is not in the application layer.

Information Bias - This is the tendency to search for more information even when having it will not make a difference. Even when armed with sufficient information, some people will tend to try and collect additional information beyond what is necessary. A manager may collect data for months and still not act because he thinks more data will help the situation.

Hofstadter's Law - It can be a challenge to estimate how long a complex incident will take to resolve. During planning, there is a tendency to underestimate the time needed. Hofstadter's Law reflects this and articulates that a task always takes longer than expected, even when factoring in Hofstadter's law.

Compensating - The above are just a few examples of the many cognitive biases that will always exist. What Incident Management teams can do is recognize that biases do, in fact, exist and look for means to recognize them when they are taking place and also to develop procedures and automation to mitigate the risks associated with them. Consider the following options:

  • Formalize the Incident Management process and the Service Desk function and pursue continuous process improvement.
  • Instead of informal questioning, develop formal scripts and supporting automation that walk the user and the person taking the call through the incident and collects the needed information.
  • Use workflow systems that can automatically route and escalate calls if a duration of time threshold is reached or if a given type of configuration item is involved, etc. The idea is that in some cases it might be wise to involve additional parties due to time, type of technology, etc.
  • Review decision support tools that can take the data collected from the scripts and make recommendations independent of personality conflicts.
  • Education Incident Management personnel on how to make effective decisions.
  • Conduct post mortems on select incidents to review the decision making process and look for means to improve.
  • Process improvement is a journey because there will always be new business requirements to address, new types of incidents to take into account and a constant need to improve availability and customer service while controlling costs. Biases can negatively affect process and smart groups will work on their decision making skills to minimize the negative impacts of cognitive biases.

    George Spafford is a principal consultant with Pepperweed Consulting and a long-time IT professional. George's professional focus is on compliance, security, management and overall process improvement.

    IT Management Daily Newsletter

    Related Articles

    Most Popular