Hide and Seek With Problem Management

If I asked you how your organization does problem management, would you, like so many of the people I have worked with over the years, tell me that you don’t do it? You know you ought to, of course, but you simply don’t have the time and resources to get started.

I’m willing to bet that if you’re one of those people, and you asked me to take a close look at the running of your IT operation, you’d be surprised. Because, quite often, when I look at what people who work in IT organizations actually do, as opposed to listening to what they tell me they do, I find that they’re already quietly getting on with many of the things that need to be done to manage problems. They just don’t call what they do problem management. Too often people believe that problem management is something formal and complex that can’t be put in place without specialized tools and extensive training. And so they fail to recognize the power – or the potential – of the steps they’ve already put in place.

I’m always really pleased when I come across a situation like this, because it’s a great position for an organization to be in. It only takes a very small amount of effort to create an effective problem management capability when you’re building on what’s already being done. (See my blog Back to ITSM Basics: Start Where You Are for some more thoughts on this idea.)

So what should you look for if you want to know whether or not your IT organization already has in place the foundation it needs to build an effective problem management capability? Where do you start?

Well, you start by understanding the difference between managing incidents – which any IT organization must do routinely – and managing problems.

What’s the Difference Between Incident Management and Problem Management?

In case you aren’t familiar with the difference between incidents and problems here’s a brief summary.

An incident is “An unplanned interruption to an IT service or reduction in the quality of an IT service” (ITIL Glossary). Most incidents are detected by users who phone the service desk to report that something is wrong. The purpose of incident management is to get the business working again, and to reduce the overall impact of the incident as far as possible. For example, if a user reports that a printer isn’t working, then you could resolve the incident by routing their printout to another nearby printer so that they can get the document they need.

Incident management activities include:

• Identifying, categorizing, logging, and prioritizing incidents
• Diagnosis and escalation (where needed)
• Incident resolution and closure
• Ensuring that users are kept informed about status
• Managing the lifecycle of incidents and ensuring that SLA targets are met

For more information, see ITSM Basics: A Simple Introduction to Incident Management.

A problem is “The cause of one or more incidents” (ITIL Glossary). The purpose of problem management is to prevent incidents from happening and to minimize the impact of incidents that can’t be prevented. For example, you could identify that a particular model of printer tends to fail after two years of use and plan to replace these printers before they fail. This would completely prevent the associated incidents. Alternatively, you could order a stock of spare printers so that you can replace them very quickly when they do fail, which would minimize the impact of the failures when they occur.

Problem management activities include:

• Analyzing incident trends to identify problems that should be investigated
• Reviewing information from other sources, such as vendors or development teams, to identify problems that need to be managed
• Investigating problems to identify what is causing the incidents
• Developing and testing workarounds that can help to minimize the impact of future incidents
• Identifying remedial actions that can prevent future incidents

Hidden Problem Management

I started this blog by saying that many IT organizations are actually doing some problem management, even if they claim not to be. Here are some examples of things that I have seen in place:

• A major incident review being held after every major incident, where everybody involved helps to understand:
  • What caused the incident
  • What can be done to prevent future similar incidents
  • What can be done to minimize the impact if the same thing happens again

This then results in improvement activities.

• Technical support teams keeping up to date with information from vendors, identifying patches that need to be installed, and other proactive actions that can be taken to help prevent future incidents.
• A service desk manager identifying frequent incidents, and reporting them to vendors or technical support teams for investigation.
• A service desk agent developing a workaround for an incident and discussing it with co-workers, so it can be used whenever similar issues arise.

I have no doubt that there are many other examples of hidden problem management taking place. So, if you “don’t do problem management” why not take a close look at your organization and see what you discover?

Building an Effective Problem Management Capability

If you know you should be doing problem management, but keep putting it off because you think that it would involve too much effort and expense, then you should think about using three of the ITIL Practitioner guiding principles to help you get started: Observe Directly, Start Where You Are, and Progress Iteratively.

• Observe Directly – Go and talk to people who work on the service desk, and in technical support teams. Make sure you know and understand what they are already doing. Identify the things that help your organization manage problems – there will almost certainly be some, if you look for them.
• Start Where You Are – Think about how you could build on the things that people are already doing. If there really is nothing, introduce something, however small, making sure it’s straightforward but capable of producing useful results. But it’s more than likely that there will be a lot of good practice around, once you go looking for it. Start measuring and reporting the good practice that already exists; share best practice between teams; gradually increase the scope of the work that is already being done.
• Progress Iteratively – Make small improvements, and measure how effective they are. Build on the ones that work well, and modify the ones that work less well. Then do it again.

If you follow these guiding principles you should find that you’re building an effective problem management capability at a very low cost and with minimum effort. And 2017 could be the year your increasingly proactive approach results in better service and happier customers. You can’t ask for better than that, can you? So why not give it a try?