Problem Management is not the Incident Graveyard

November 12, 2015 1 Comment

For those that are unaware, the purpose of problem management is the reduction of incidents in amount and severity that impact a business. It should not be a place for incidents to rot in search of a root cause. Problem management should help to drive service management from a reactive to a more proactive place. This statement would suggest that any team which is experiencing incidents should also logically have some level of problem management, right?

Whether formalized or not, the trouble is some organizations are not looking at problem management in a context of business value. Instead they view problem from an IT or worse yet an incident management perspective. You might be saying to yourself “of course that’s how we view it, problems are the result of incidents which impact IT”, and that I may have lost my mind. Simply because we have done something from a certain perspective in the past doesnt mean we can’t look at it from another perspective now.
 
By sticking with the same viewpoint on problems, we may be inadvertently focussing our efforts on issues which have no solution, root cause and may be low on the priority scale when it comes to business impact. While it’s good that they are looking at these issue at all, they have low value in terms of what really matters to our business.
The reason that problem might be getting a raw deal in your ability to produce results is that when we focus on these low impact issues, the urgency and in turn ability to assign resourcing of any kind to resolve this issue also remains low. The result is that when we talk about what problem management is doing to improve service delivery it looks relatively low, leaving those in leadership to ask what value it brings to the table at all.

The first thing we as practitioners need to do is stop thinking like IT. Not all incidents are going to require a technical resolution. Take a closer look at the top escalations to the service desk and see what drives them in the first place. Here is an example of some typical escalations:

  • Application errors
  • Password resets
  • Questions
  • Hardware failure
  • Network issues

While some of these are still technical in nature, some things such as questions and password resets are everyday common place in some organizations.  While your company may not have this issue to deal with there are still may that come into work on a Monday morning faced with the repetitive task of addressing the forgotten password. This costly use of resources could be resolved with an automated reset tool of some sort. The problem analysis would support the cost benefit to implementing a tool or the effort to automate this activity versus your service desk resources spending their valuable time to reset a password.

Another heavy hitter is the area of questions. This is where a knowledge repository of some type could reduce the calls for people who are asking how to map a network drive over and over again. People want to be able to search and execute a simple fix for themselves if given the opportunity. They are already .accustomed to searching online to solve small issues or address questions that they may have. Just make sure that the place where people go to consume your knowledge records provide some metrics so that you can quantify what people are looking up and using.
What you need to keep in mind is that while we will get problems that have low impact we also need to proactively look to address larger issues which are impacting our business. Find that balance and you can improve the value of problem management.

 

1 thought on “Problem Management is not the Incident Graveyard”

  1. Good points Ryan,

    I've seen many organizations attempt Problem Management & simply end up with Incident Management for less complex incidents, and Problem Management a queu for complex issues. This is a failure.

    Everytime someone wants to open up a problem ticket, they should be hearing a cash register sound in their head, because of the time and effort to resolve.

    Problem Management is about removing systemic issues that are causing business impacts. The organizations commitment to the projects, tools, consultants, to weed out these systemic issues is directly proportionate to the ROI & feasibility of the resolution.

    Every organization running Microsoft Office has numerous incidents due to the Office Suite having bugs, memory management, and other conflicting issues. Unless it's an environmental setting, there is very little an organization can do to fix it. Creating a Problem Ticket is not the solution. We don't need ITIL's guidance of using Problem to create knowledge and workaround's, we can do that at anytime.

    On the same level, if we do not use a corollary like Configuration Items to track Incident trends, then we will never be able to use analytics to drive proactive measures. User Types impacted by a common CI, is the easiest way to determine if we should declare and justify the removal of a problem.

    Great stuff
    -Hoop

Comments are closed.