Problem Management: No Problemo
Hey! It’s Joe the IT Guy and I want to talk, well write, about problem management.
It’s a funny one – you hear people say that they do problem management but do they really? By this I mean:
Are IT organizations really identifying problems and systematically addressing their root causes as well as the issues they are causing the business?
Some might call this proactive problem management.
Let’s look at the stats
I recently tweeted a link to the SDI (Service Desk Institute) and LANDesk 2013 Service Desk Benchmarking infographic but I have to go back to the 2009 version of the report for the right statistic: that problem management, at roughly two-thirds of respondents, was the third most adopted ITSM process after incident and change management.
As much as I would love to, I just can’t believe this stated level of problem management adoption. Unless people think that, every now and then, calling an IT issue a problem and resolving it is problem management – at best it is ad hoc or reactive problem management. At worst it’s confusion over what problem management really is or should be.
Major incidents aren’t “problems”
But I guess they are problems in the language the business would use. And I guess that some major incidents could be the result of problems.
What I’m trying to say here is that doing a drains-up or post mortem after major incidents isn’t really effective problem management. For me, problem management is about investing time and resource in investigating and addressing issues, and their root causes, that cause (or may ultimately cause) repetitive and potentially serious IT and business issues or failures.
If you want to get all fancy, the ITIL definition of problem management is:
“The process responsible for managing the lifecycle of all problems. Problem management proactively prevents incidents from happening and minimizes the impact of incidents that cannot be prevented.”
Where a problem is defined as:
“A cause of one or more incidents. The cause is not usually known at the time a problem record is created, and the problem management process is responsible for further investigation.”
-Source: ITIL Glossary
A simple example
So for me, an end user that has had three replacement laptop hard drives is suffering from a problem, or the root cause of a problem. Whether we need to log it as a problem is almost irrelevant – the important thing is that we shouldn’t continue to treat the end user’s issues as separate incidents. Also consider the impact of the issue on the end user (they haven’t been able to be fully productive due to persistent laptop issues) the next time the hard drive fails – because it probably will, will you replace the hard drive again or is it better to provide them with a new laptop?
Problem management could be invoked to ascertain whether this end user has just been unlucky or whether there is an issue either with a batch or brand of either the laptops or the replacement hard drives. It could very likely be that a cost-saving decision to buy cheaper laptops or hard drives is actually costing the business more when the IT break-fix labor costs and end user lost productivity are taken into account. Thus the root cause could be the hardware on one level but on another it is the suboptimal purchasing decision to “buy cheap.” But how many IT shops would have just replaced the hard drive the next time the issue occurred?
So what can you do?
Firstly, recognize that problem management doesn’t have to be expensive. And ideally it is something that has a positive ROI. So you don’t have to start with a team of problem managers and tools. Just start with a desire to reduce IT downtime and to improve IT service delivery, and a method to identify and address problems.
Secondly, ensure that you see problem management as an end-to-end operation. There is little point in spending weeks, maybe months, analyzing incident records and other sources of input to identify problems if all you end up with is a long list of problems.
Thirdly, as with any new IT activity, you will probably need to demonstrate the value of what you are doing – whether anecdotal or on a ROI-basis. So baseline performance before you start so that you can show the difference your problem management activity does or doesn’t make.
Fourthly, remember that as with many ITSM activities there is no need to reinvent the wheel. For example, independent management consultant Barclay Rae offers some great problem management tips as part of his ITSM Goodness training. You can find that here. The important thing is to really understand why you want and why you need to do problem management and to be committed to succeeding with it.
Finally, if you want to find out more, I suggest clicking through to the following problem management resources:
And feel free to suggest more for me to add here.
