ITIL 4 problem management<\/h2>\n
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.<\/p>\n
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 \u201cgood thing to do\u201d, though, the new ITIL 4 doesn\u2019t offer any \u201cjustification\u201d 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.<\/p>\n
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\u2019s ROI much more concrete. This way, getting started with problem management won\u2019t feel like such a leap of faith anymore.<\/p>\n
1. Make sure your employees understand the difference between incidents and problems<\/h3>\n
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 \u201cproblem\u201d means something different outside of the ITIL guidance. That\u2019s why it\u2019s easy for people to use the terms issue, incident, or problem interchangeably. Or to confuse ITIL problem management, incident management<\/a>, and even major incident management.<\/p>\n When you want to introduce ITIL problem management, make sure your employees know exactly how problem management capabilities will help \u2013 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.<\/p>\n Have your service desk employees become firefighters? Problem management can help prevent service desk stress.<\/a><\/p>\n 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\u2019s still the opportunity to at least quantify the negative impact on internal business operations and results of not doing problem management.<\/p>\n 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.<\/p>\n The reality is that your organization will likely have far more problems than your limited resources can handle. There\u2019s nothing wrong with starting small though.<\/p>\n 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.<\/p>\n Just like with knowledge management, your ITIL problem management capability is going to be suboptimal if it\u2019s designed and operated in a standalone mode. Instead, try to integrate it with other ITSM capabilities<\/a> such as incident management<\/a>, change management<\/a>, availability management, capacity management, and continual improvement.<\/p>\n Analyzing incoming incidents helps you identify root causes of problems. You can also use this analysis as input when you\u2019re 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.<\/p>\n Make sure that the people responsible for proactive problem management can work unimpaired by the attention-sucking firefighting of incident management.<\/p><\/blockquote>\n Although I believe the problem management process should be integrated with other ITSM<\/a> 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\u2019s virtually no time for problem management when you\u2019re also faced with a never-ending stream of incidents.<\/p>\n You don\u2019t 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.<\/p>\n Many of the promoted metrics for problem management activities focus on numbers and timeframes. But don\u2019t get tricked into believing that the \u201cmechanics\u201d 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?<\/p>\n So \u2013 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.<\/p>\n Sure, the ability to \u201cprocess\u201d problems is important. But continually feeding your problem management capability with prioritized opportunities to prevent issues and to improve is equally critical.<\/p>\n Here, it\u2019s 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.<\/p>\n Here\u2019s another reference to knowledge management. And another reason why you should make your ITIL problem management part of an integrated ITSM capability.<\/p>\n Provide different teams with access to a known error database and the workarounds they need until a known problem is eradicated (if it\u2019s 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.<\/p>\n Problem management is useful in many occasions \u2013 but not in all. This has been well articulated by\u00a0Aale Roos<\/a>: \u201cIn\u00a0Cynefin\u00a0<\/a>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\u2019s 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.\u201d<\/p>\n Say your organization has a CRM tool that\u2019s causing a lot of issues that affect sales revenue, and your IT department can\u2019t fix the problem. You may be dependent on your vendor to solve these issues, but your IT department isn\u2019t 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\u2019t a decision your IT department can make by themselves: it\u2019s a situation that also demands choices on a political and business level.<\/p>\n 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.<\/p>\n 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 \u2013 reducing both incidents and problems upfront.<\/p>\n Hopefully, these ten tips are all food for thought for your organization\u2019s 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.<\/p>\n In Stephen\u2019s next blog, he\u2019ll talk about incident management best practices that\u2019ll help you improve your IT support capabilities. Subscribe to our blog to be sure you don\u2019t miss it.<\/p>\n","protected":false},"excerpt":{"rendered":" In his previous blog, industry expert Stephen Mann explained why ITIL problem management adoption levels are so low \u2013 and why that\u2019s a problem. Today, Stephen shares ten practical problem management tips that\u2019ll help you get started or improve what you\u2019re already doing. In\u00a0my previous blog about problem management, I wrote about what I believe<\/p>\n","protected":false},"author":1,"featured_media":20698,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_searchwp_excluded":"","inline_featured_image":false,"editor_notices":[],"footnotes":""},"class_list":["post-20704","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry"],"acf":{"blog_author":"","blog_hubspot_cta_link":"","toc_display":"not-visible","blog_promotion_overwrite":false,"blog_promotion":false},"yoast_head":"\n2. Articulate the business value of problem management to key stakeholders<\/h3>\n
3. Don\u2019t try to build Rome in a day<\/h3>\n
4. View problem management as an integrated, rather than standalone, ITSM capability<\/h3>\n
5. Separate the responsibilities for doing incident management and problem management<\/h3>\n
![\"\"](\"https:\/\/www.topdesk.com\/en\/wp-content\/media\/sites\/30\/Inline_10_problem_management_tips.png\")
<\/div>\n6. Rise above the problem management process: be outcome-driven instead<\/h3>\n
7. Invest in problem identification, not just problem handling<\/h3>\n
8. Give support staff and other affected teams access to some form of known error database<\/h3>\n
9. Appreciate that problem management doesn\u2019t work in all scenarios<\/h3>\n
10. Don\u2019t expect problem management to prevent all your problems<\/h3>\n
Hope for the future<\/h3>\n