Which problem management technique should we use

By ITIL® from Experience©

Selecting the appropriate problem management method or technique is not obvious given all the choices available. ITIL® mentions:

Chronological Analysis
Pain Value Analysis
Kepner and Tregoe
Brainstorming
Ishikawa Diagrams
The Pareto Analysis

In addition, the following were added to the ITIL® 2011 Edition (i.e. v3):

5 Whys
Fault Isolation
Affinity Mapping
Hypothesis Testing
The Technical Observation Post

The technique to use depends on what it will be used for, the organization’s culture and maturity. Moreover, what is most important is to ensure that the technique is appropriate for the task at hand, or as ITIL® would put it, “fit-for-purpose.” A bit of help is provided in the 2011 Edition of ITIL's Service Operations book with the addition of Table 4.2 that lists “Problem Situations and the most useful techniques for identifying root causes” (p. 101).

Unfortunately, ITIL® does not differentiate between problem solving1 and root cause analysis2 . Problem Solving techniques such as Kepner-Tregoe or Brainstorming tend to perform better when time is of the essence like when it is used as part of incident resolution. On the other hand, Root Cause Analysis which in itself is a category of problem solving methods, are particularly good at turning a problem3 into a Known Error4 or to understand after the events that led to a Major Incident (see Should a Problem be opened for every Major Incident). When the organization does not use a formal technique, it may be advisable to use a problem solving technique as they are usually more versatile than Root Cause Analysis.

Highly analytical techniques like the Pareto Analysis which relies on statistical analysis may be a better fit for an engineering or manufacturing organization. It may also be a good fit for an organization that has a formal Quality Management practice. On the other hand, the Kepner-Tregoe technique, while based on a scientific method, may be more appropriate for a less structured organization as it leaves more room for intuition. A point often overlooked is that problems don’t get any simpler by using simple methods to analyze them.

Another consideration is the rigor required by the technique. If many sequential activities requiring significant effort are needed to get results and requires a full-time individual, it may be too expensive for the organization to regularly use.

It is important to consider the cost and availability of training for a particular method. Another element to consider is that even though people can be trained in a technique, it helps when one of the employee has experience using it even if it is not mentioned by ITIL®. Having a internal mentor greatly helps in people’s buy-in. For example, if an employee is familiar with the US Army After Action Review (AAR)5 technique, it might be most appropriate for your organization as a starting point. Once the organization has matured in the use of this method, a more sophisticated technique can be introduced for specific situations, like helping to resolve major incidents (see How to first introduce Problem Management)

When the appropriate technique is utilized, over time people will unconsciously use it and it will eventually be internalized in the day-to-day practices (i.e. the culture). If the technique is not appropriate for the task at hand, the organization’s culture and its maturity level, significant effort will be expanded trying to get people to use it. Relaunching the process with a new technique

Regardless of the technique(s) selected, what is important that it is used consistently before a new one is introduced. As with any technique, people typically need to become proficient before significant value is realized.

In closing, how you do problem management is less important than doing it.

Last updated on: 2017-06-21
Published on: 2013-06-07

"Try harder next time...is not a problem management method mentioned in ITIL®." D.Matte

More Quotes

Related: