In a recent webinar, Chris Pope and I discussed the barriers to proactive problem management, and good practices, before looking at how problem management thinking and technology is evolving. This blog covers the common barriers – how many do you recognize?

 

The deck can be downloaded here.

 

5650719702_4b089f2b6a_z.jpg

 

Barrier #1: the “starting position”

 

Many providers of opinion have traditionally said that people should, and tend to, start IT service management (ITSM) or ITIL* adoption initiatives with one of:

 

  • Incident and problem management
  • Incident and change management, or
  • Change and configuration management.

 

Sadly I’ve done it myself.

 

But the more astute advisor will say something akin to starting with continual service improvement. That is preparing the organization for improving over time from day one. One could argue that problem management would fit here too.

 

For me the traditional starting points are the beginning of an unhealthy focus on process or, more importantly, an unhealthy focus on what we do rather than what we achieve through what we do in IT operations. And we then continue that focus on the processes we are already doing and most-likely never add to them – at best trying to get better at the stuff we are already good at.

 

But, in many ways the pushing of the most commonly-adopted processes, and they are by no means the easiest of processes to adopt, should help problem management’s cause if people are being encouraged to start with incident and problem, say. But, as with configuration management and service level management, how many organizations never complete what they start to implement or adopt?

 

Although, having said this, many industry surveys show problem management with a two-thirds-ish adoption rate. Personally, however, I think this is indicative of Barrier #2 …

 

Barrier #2: confusion over what problem management is

 

We often hear talk of one possible cause of corporate problem management inattention being that problems are often confused with incidents (with the terminology interchanged wrongly), or problems seen as an incident state rather than a separate entity requiring a different type of ITSM response.

 

Now Rob England – the IT Skeptic – has opened up an interesting can of worms in a recent blog. A blog titled ITSM incident and problem: two names for three things. For me it further adds to the conversations around the confusion between incident and problem management.

 

So I really don’t believe that two out of every three IT shops are doing proactive problem management. Instead I think that many of those organizations that say they are doing problem management are probably using root cause analysis techniques post-major incidents rather than proactively trying to remove faults from the IT environment. It’s a shame, as problems can be identified just about anywhere within the IT ecosystem and they are probably causing the parent organization pain.

 

Barrier #3: too busy firefighting?

 

Unfortunately, many organizations fall down before starting Problem Management. With IT support attention so focused on incident resolution that it’s in a perpetual state of “bailing water out of an overflowing bath” rather than looking to “turn off the taps.” We just never find the time to address problems amongst the firefighting.

 

But it’s no excuse, IT management needs to appreciate that far too much costly, and possibly scarce, IT resource is spent fighting repetitive fires and that this resource would be better utilized supporting problem management-focused personnel in tackling the root causes, rather than the symptoms, of IT failures.

 

Barrier #4: getting the financial support for problem management

 

Incident management and the service desk will always be far more visible than problem management to those with the purse strings. Colleagues demand and expect IT support, and they personally have IT or productivity issues that require support. Thus they sort of understand the need for a service desk and incident management. The need for problem management on the other hand is not so obvious. Plus the lack of clarity or desire to focus on problem management (barriers #2 and #3) doesn’t help either.

 

Thus many organizations struggle to get the required investment in problem management. And I use the word investment deliberately – problem management is an investment. If done properly, problem management can be shown to be the proverbial spending a penny to save a dollar, euro, pound … or whatever your currency is.

 

Barrier #5: it’s so much more than logging problems, it’s about PEOPLE people!

 

“Let’s buy a shiny problem management tool.” Sound familiar?

 

Sadly, the technology will not do everything for you … yet. As with any other ITSM activity – having the right people with the right skills is key (and process too). Only then can technology really start to help.

 

Barrier #6: selling problem management vs. selling business outcomes

 

OK it’s similar to Barrier #4 … but it’s worth breaking it out.

 

Whether it be creating a job description for a problem management position or responsibility, or the metrics used to assess and report upon problem management success, how often are people focused on what is done (the mechanics of problem management) rather than what is achieved through what is done?

 

Take a job description for instance, how many of its points will help get funding for the role or inspire the new recruit to focus on the outcomes of problem management rather than the process itself? In my experience, few if any. Or the metrics? It’s a little bit better but how often are people trying to measure and report on the mechanics of problem management rather than what is really achieved at a business level?

 

Also, how many organizations have problem management as BAU – not all problems need to be identified, or even managed, by a problem management team.  Sadly if problem managers are just seen as administrators of problem records they will struggle to challenge the status quo and to bring about change.

 

So that’s six barriers to proactive problem management, and I’m sure you could add in more

 

But no matter how many we list, the result is that, for many organizations, problem management is somewhat of a poor relation to corporate service desk and incident management activity.

 

Even if an organization undertakes reactive problem management in response to a major incident, say, proactive problem management (where focused resource actively identifies problems) may never receive due attention.

 

And, going back to Barrier #2 – the Rob England quote – how many organizations don’t do proactive problem management because they already kid themselves that they’re doing problem management? I’d bet it’s half of the two-thirds

 

The webinar can be watched on demand here. And the blog on good or best practices here.

 

Related ServiceNow Community content includes:

 

How have you quantified and communicated the value of problem management?

 

Which problem management methodology do you prefer to use?

 

Problem Management Webinar Q&A Responses

 

Learning From Others: How Does One Stand on the Shoulders of Giants?

 

When is a Major Incident a Problem?

 

* The ITSM best practice framework formerly known as the IT Infrastructure Library

 

Image source: Flickr: Tomasz Stasiuk's Photostream