16 Tips For Getting Started With Problem Management – Part 2

In a previous blog, I offered 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. Now, in this blog, I want to continue with even more – well, eight more – tips for getting started with problem management.

Again, these second eight tips of 16 for getting started with problem management are relevant to both IT departments and the other business functions (such as human resources (HR), facilities, and customer service) than can benefit from the sharing of proven ITSM capabilities through an enterprise service management approach (or whatever your organization wants to call the sharing of ITSM capabilities outside of IT to improve operations, services, experiences, and outcomes).

Eight more tips for getting started with problem management

1. Don’t just start problem management, justify it first (and maybe again). Problem management might simply look like a logical and great thing to do (it is). But don’t let this fool you into simply starting with it. Instead, create the business case for starting it such that everyone can see the benefits and ambitions. If you don’t do this, your fledgling problem management capability might eventually be a victim of the IT budget cuts that many corporate IT organizations now face.
2. Ensure that you justify it in business terms. So, as with the above tip, ensure that the results of your problem management activities can be articulated to relevant business stakeholders in a manner that resonates with them. As with any new IT activity, it’s important to demonstrate the value of what you’re doing (especially to those who manage the purse strings) – whether anecdotally or on a ROI-basis. Also, remember to baseline performance before you start, so that you can easily demonstrate the difference your problem management activity does or doesn’t make to business operations and outcomes.
3. Don’t expect people to automatically know how to do problem management. Instead, you’ll need to train relevant staff on problem analysis and 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 practices they employ, few technical staff receive any formal training in problem analysis. There are a number of proven approaches, with Kepner-Tregoe one that’s commonly used.
4. 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 success is really about what people do (or don’t do). As with any other ITSM activity – having the right people with the right skills is key (and the right processes too). Only then can the technology really start to help.
5. Consider your  problem management metrics carefully. Importantly, 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 problem management 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).”
6. Don’t underestimate the need for knowledge management. While many problems will be fully-resolved via your new problem management activities, others won’t be and will instead require “workarounds.” These workarounds – what to do when the problems occur – will need to be easily accessible by either IT support staff or end users via self-help. Improving knowledge management capabilities, to make these workarounds available when needed, can significantly reduce the business impact of problems, and the cost to IT of managing the related incidents.
7. 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 “lifecycle” for each problem by creating a relevant knowledge article or effecting the change to prevent future instances of the problem-related incidents.
8. Measure and communicate success. Importantly, once “in flight,” stop trying to sell problem management and start selling the positive business outcomes (which are of course the result of your effective problem management capabilities). It’s like trying to sell ITIL or ITSM as a whole, your business stakeholders aren’t interested in what you do– instead, they’re only interested in what you achieve. And this is business-level, rather than IT-level, achievements.

My two-part getting started with problem management list is in no way definitive; it’s just a start. So, what would you add? Please let me know in the comments.