8308774481_07356129f6_c

Is It Time To Rethink Problem Management?

Ah problem management. I’ve written about it before (see the additional resources at the bottom) and I’m sure I’ll write about it again.

It’s one of the less commonly-seen animals in the ITIL, the IT service management (ITSM) best practice framework, farm yard — with many ITSM professionals interested in talking, reading, or listening to others talk about problem management, but far fewer ever get round to doing what I would deem to be real problem management.

So for me, problem management = lots of talk, not so much walk.

Problem management – it’s not you it’s me

I’m beginning to wonder where the blame, for lack of a better word, lies for the low adoption levels of problem management.  Some schools of thought point to the limited airtime that problem management is given in ITIL training. Some point to the common confusion between incidents and problems. My point of view is that companies don’t demand, or even know about, problem management – as they do service desk and incident management – and thus IT organizations have no obligation, nor funding, to do it.

But what if problem management, as defined and sold by ITIL and industry consultants, is fundamentally flawed? Or is a solution created to address a problem (that’s the normal human being use of the word) that isn’t there? Or perhaps it’s a solution created without fully understanding the context of the problem?

It makes one think – we are often quick to blame ITSM professionals for the low uptake of problem management but what if the problem management best practice, rather than the professionals, is really to blame? Allow me to point you to some blogs that will hopefully make you think a little more deeply about problem management per se:

Whether you want to call it problem management or something else…

… problem management techniques can be very useful and, according to John Custy’s FUSION 14 presentation, not just for problem management. If you tweet to John I’m sure he’ll send you a copy of his deck. In the meantime, here are a couple of his FUSION session pearls of wisdom.

Firstly, how we think about issues or problems. John offered up two fundamental thinking modes, in the context of problem management, based on the research and book “Thinking, Fast and Slow” by Nobel-prize-winning psychologist Daniel Kahneman:

  • System 1: “Automatic System” informed by knowledge and experience
  • System 2: “Effortful System” used to consciously think through an issue in a systematic way

With System 1 thinking best when:

  • The issue is simple
  • You have seen an issue like it many times before
  • The cost of being wrong is low and the consequences are acceptable

And System 2 thinking best when:

  • The issue is complex
  • You have not seen an issue like it before
  • The cost of being wrong is high and the consequences unacceptable
  • Time for repeated System 1 thinking is over

But how often do we try to use the same hammer to crack multiple types of nuts? Meaning that, at best, we waste time with the wrong mode of thinking, or at worst, we end up with the wrong conclusion or solution.

This, of course, if we devote enough time to thinking.

Kepner-Tregoe – it’s not just for problem management

The second eye-opener from John was that Kepner-Tregoe, probably the most-lauded problem management technique, is not just for problem management. Actually, it’s ultimately a decision making technique that can be used elsewhere in IT or the business, with four basic steps:

  1. Situation appraisal – used to clarify the situation, outline concerns, and choose a direction
  2. Problem analysis – where the problem is defined and its root cause determined
  3. Decision analysis – where alternatives are identified and a risk analysis conducted for each
  4. Potential problem analysis – where the best of the alternatives is further scrutinized against potential problems and negative consequences and actions are proposed to minimize the risk

All this – where the term problem is again the original English-language, rather than ITIL definition.

So politely stealing from John’s FUSION slides for the last time, Kepner-Tregoe should be viewed not as a new process but instead as a way of doing existing processes better. Take incident management as an example:

As John’s diagram shows – Kepner-Tregoe can be used for incident management. But I also refer you back to the two modes of thinking and the need for multiple hammers.

Well that’s over 800 words and therefore all from me (and John Custy’s FUSION slides). I’ll leave you with some additional problem management resources:

Image Credit


Posted by Joe the IT Guy

Joe the IT Guy

Native New Yorker. Loves everything IT-related (and hugs). Passionate blogger and Twitter addict. Oh...and resident IT Guy at SysAid Technologies (almost forgot the day job!).