16 Tips For Getting Started With Problem Management – Part 2
Last week I posted a blog offering my thoughts and advice on getting started with problem management, based on the premise that it involves much more than just adopting a best practice IT service management (ITSM) process from a book. Today, I want to continue with even more.
My second list of eight tips for getting started with problem management
- Don’t just start problem management, justify it first (and maybe again). Otherwise it’ll probably be a victim of the endless flow of annual IT budget cuts that many corporate IT organizations now face.
- Ensure that you justify it in business terms. As with any new IT activity, you’ll probably need to demonstrate the value of what you are doing to the business (or at least to those who manage the purse strings) – whether anecdotal or on a ROI-basis. So baseline performance before you start, so that you can easily demonstrate the difference your problem management activity does or doesn’t make.
- Don’t expect your people to automatically know how to do problem management (and especially problem analysis). Instead you will need to train your staff on problem solving techniques. In my experience, while technical staff are often trained on how to install and manage technology, and maybe receive ITSM training to ensure that they understand the concept of IT-as-a-service and the ITIL processes they need to follow, few technical staff receive any formal training in problem analysis. There are a number of proven approaches, with Kepner-Tregoe one that is commonly used.
- Understand the benefits and limitations of an ITSM tool. While such a tool might be great in terms of workflow, automation and improving general organization, problem management is really about people. As with any other ITSM activity – having the right people with the right skills is key (and the right process too). Only then can technology really start to help.
- Consider your metrics carefully – don’t just steal the metrics suggested by ITSM best practice, such as ITIL, or used by other IT shops that you might have benchmarked against. Instead pick metrics that are relevant to your organization and what you need to achieve. To quote my good friend Stuart Rance: “KPIs need to INDICATE the PERFORMANCE of the KEY things you care about (that’s why they’re called Key Performance Indicators).”
- Don’t underestimate the need for knowledge management. While many problems will be fully-resolved via your problem management activities, others won’t be and will instead require workarounds. These workarounds will need to be easily accessible by either IT support staff or end-users via self-service. Improving knowledge management capabilities, to make these workarounds available when needed, can significantly reduce the business impact of incidents, and the cost to IT of managing those incidents.
- Don’t overly focus on root cause analysis (in addition to not overly focusing on problem identification). Root cause analysis is great for identifying workarounds or the changes required to stop incidents recurring; but it shouldn’t be the focus of all your problem management activities. Instead ensure that you consistently get to the end of the “problem lifecycle” by creating a relevant knowledge article or effecting the change to prevent future instances of the associated incidents.
- Measure and communicate success; and stop trying to sell problem management and start selling positives business outcomes (which are of course the result of effective problem management). It’s like trying to sell ITIL or ITSM as a whole, your business stakeholders aren’t interested in what you do as IT people – instead they’re only interested in what you achieve. And that’s business-level rather than IT-level achievements.
My getting started with problem management list is in no way definitive; it’s just a start. So what would you add?
- Get problem management working by Barclay Rae
- A guide to problem management by the Universities and Colleges Information Systems Association (UCISA)
- Defining Metrics for Problem Management by Stuart Rance
Posted by Joe the IT Guy