ITIL problem management: 10 practical tips to help you get started

In his previous blog, industry expert Stephen Mann explained why ITIL problem management adoption levels are so low – and why that’s a problem. Today, Stephen shares ten practical problem management tips that’ll help you get started or improve what you’re already doing.

In my previous blog about problem management, I wrote about what I believe to be the true level of ITIL problem management adoption, which is much lower than what’s commonly reported in ITSM industry surveys. The reason for this is the absence of credible research or case studies which quantify the potential benefits – or return on investment (ROI) – of creating problem management capabilities.

ITIL 4 problem management

The latest ITIL 4 problem management guidance offers help on how to operate a problem management capability. It covers problem identification (proactive and reactive), problem control, error control, problem models, practice success factors and key metrics, organizational/people aspects, and technology-related needs.

But to actually use the capabilities that the new ITIL 4 best practice offers, your organization probably needs to already have justified investing in ITIL problem management. For organizations that are just jumping on ITIL problem management as a “good thing to do”, though, the new ITIL 4 doesn’t offer any “justification” for investing in problem management in the form of a clear ROI. Hopefully, this is something that will eventually materialize as ITIL 4 supplementary content. In the absence of such a justification, your IT organization might need to self-justify its need for, and investment in, a problem management capability.

To help, here are ten practical tips that can help you get started with problem management (or improve your existing problem management capabilities). These tips will help you demonstrate the business value of investing in problem management capabilities and make your organization’s ROI much more concrete. This way, getting started with problem management won’t feel like such a leap of faith anymore.

1. Make sure your employees understand the difference between incidents and problems

It pains me to type this, but I feel I still need to do so, even after 30 years of ITIL. As I mentioned in my previous blog, the term “problem” means something different outside of the ITIL guidance. That’s why it’s easy for people to use the terms issue, incident, or problem interchangeably. Or to confuse ITIL problem management, incident management, and even major incident management.

When you want to introduce ITIL problem management, make sure your employees know exactly how problem management capabilities will help – that is, in a different way to incident management. Once your employees actually know the basics of problem management, you can start talking about its value.

Have your service desk employees become firefighters? Problem management can help prevent service desk stress.

2. Articulate the business value of problem management to key stakeholders

Of course, credible research and case studies would definitely help quantify the benefits of problem management adoption. But in the absence of such data, there’s still the opportunity to at least quantify the negative impact on internal business operations and results of not doing problem management.

For example, identify a number of recent business-affecting issues and their associated business impact that you believe could have been prevented by problem management adoption. Then crunch the numbers, using probabilities if needed. This at least helps you identify the business costs of not doing problem management.

3. Don’t try to build Rome in a day

The reality is that your organization will likely have far more problems than your limited resources can handle. There’s nothing wrong with starting small though.

Start by addressing the problems that are causing your organization and your people real pain. Your small and humble beginnings are a great opportunity to prove and communicate the worth of problem management to the organization as well.

4. View problem management as an integrated, rather than standalone, ITSM capability

Just like with knowledge management, your ITIL problem management capability is going to be suboptimal if it’s designed and operated in a standalone mode. Instead, try to integrate it with other ITSM capabilities such as incident management, change management, availability management, capacity management, and continual improvement.

Analyzing incoming incidents helps you identify root causes of problems. You can also use this analysis as input when you’re deciding which problems to tackle first. To solve a problem, you might need to make a change in your infrastructure. When your problem management capability is integrated with other ITSM capabilities, problem management will be part of your working process instead of a separate process that you need to invest time in, promoting its adoption.

Make sure that the people responsible for proactive problem management can work unimpaired by the attention-sucking firefighting of incident management.

5. Separate the responsibilities for doing incident management and problem management

Although I believe the problem management process should be integrated with other ITSM capabilities, the responsibilities should be separated. The importance of having different people responsible for problem management and incident management was repeatedly called out in ITIL trainings. Well, at least it was for ITIL v2, which explained how there’s virtually no time for problem management when you’re also faced with a never-ending stream of incidents.

You don’t need to have a formal problem manager or a dedicated problem management team. Just make sure that the people responsible for proactive problem management can work unimpaired by the attention-sucking firefighting of incident management. This way, you can truly reap the benefits of problem management adoption.

6. Rise above the problem management process: be outcome-driven instead

Many of the promoted metrics for problem management activities focus on numbers and timeframes. But don’t get tricked into believing that the “mechanics” of problem management are the most important metric. What you really want to know is: what difference is problem management making to business operations and outcomes?

So – how can you measure the outcome of problem management? Well, start by calling out the reduction in major incidents. If you know of specific major incidents that have been avoided through problem management, collect those examples too. You can also use data from major incident reviews to quantify the positive effect of problem management adoption on business operations and results.

7. Invest in problem identification, not just problem handling

Sure, the ability to “process” problems is important. But continually feeding your problem management capability with prioritized opportunities to prevent issues and to improve is equally critical.

Here, it’s important to appreciate the many areas where problems can be identified within the IT ecosystem. For example when moving something from acceptance into production, when you implement changes or install updates or patches, and when user errors or plain-old technology failures occur. In all these cases, having a decent problem identification capability in place helps you detect issues more quickly and fix them where necessary.

8. Give support staff and other affected teams access to some form of known error database

Here’s another reference to knowledge management. And another reason why you should make your ITIL problem management part of an integrated ITSM capability.

Provide different teams with access to a known error database and the workarounds they need until a known problem is eradicated (if it’s feasible to do so). Such an approach will save your teams time and, more importantly, will help make sure your organization and its people are as productive as possible.

9. Appreciate that problem management doesn’t work in all scenarios

Problem management is useful in many occasions – but not in all. This has been well articulated by Aale Roos: “In Cynefin terms, incident and problem management works only in the Simple and Complicated domains. Simple problems can be categorized and there is a known solution. With complicated problems it’s not possible to categorize problems directly, but problems can be solved through analysis. Unfortunately, many important problems exist in the Complex and Chaotic domains and there the solutions are political or business decisions.”

Say your organization has a CRM tool that’s causing a lot of issues that affect sales revenue, and your IT department can’t fix the problem. You may be dependent on your vendor to solve these issues, but your IT department isn’t confident that the CRM tool will ever be fit for purpose. Replacing the CRM tool altogether might be the best way to solve the root cause of all the related incidents. But this isn’t a decision your IT department can make by themselves: it’s a situation that also demands choices on a political and business level.

10. Don’t expect problem management to prevent all your problems

Yes, problem management can be a valuable capability for IT organizations seeking to reduce the impact of IT issues and the associated costs. Yet it only helps you cure problems, not prevent them.

Think of it as sitting in an overflowing bath: what would you do? Turn off the taps or uselessly try to bail out the water? You should also invest in making IT systems and services more resilient in the first place – reducing both incidents and problems upfront.

Hope for the future

Hopefully, these ten tips are all food for thought for your organization’s problem management capabilities. Still, if you ask me, what the ITSM industry really needs is more quantified real-world examples and data that will help organizations justify their initial investment in problem management activities. What do you think would help the higher adoption of problem management? Please let me know in the comments.

In Stephen’s next blog, he’ll talk about incident management best practices that’ll help you improve your IT support capabilities. Subscribe to our blog to be sure you don’t miss it.