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.

The post ITIL problem management: 10 practical tips to help you get started appeared first on MCG - EN.

When people talk about IT service management (ITSM), they’ll often call out the triumvirate of IPC – incident management, problem management, and change management (or “change enablement” as it’s now called in ITIL 4). Using these three letters gives the misguided impression that incident management, problem management, and change management are of equal standing in real-world ITSM. This is far from the truth: the level of ITIL problem management best practice adoption is not as high as it should be. Why is this the case?

Problem management prevents you from mindlessly fixing issues as they occur, because it makes you look for the underlying problem that causes these issues to occur in the first place.

Explaining ITIL problem management

Let’s start off with the fact that a “problem” in ITSM terms is different from the word’s everyday use. An end user with an IT issue isn’t going to call it an “incident”; they’re more likely to call it a “problem.” And so, we start off with problem management on shaky ground in terms of its meaning.

The new best practice for ITIL Problem Management offers up the definition that:

“The purpose of the problem management practice is to reduce the likelihood and impact of incidents by identifying actual and potential causes of incidents, and managing workarounds and known errors.”

Translated to a more everyday lexicon: problem management prevents you from mindlessly fixing issues as they occur, because it makes you look for the underlying problem that causes these issues to occur in the first place. Ultimately, problem management is an investment of time and money that will save you even more time and money over time. Try saying that ten times fast.

The current state of problem management

If you were to ask 100 IT departments if they undertake problem management, you might be pleasantly surprised to find out that approximately 60-70% (think they) do. Sounds good, even if problem management lags behind incident management and change management, as seen from the HDI survey data below:

Service management processes support organizations have adopted (abbreviated list)

Source: HDI, “Technical Support Practices & Salary Report,” (2018)

One could argue that all IT departments need to manage IT issues (incidents) – most of the “missing” 22% in the HDI data above are still likely managing IT issues without calling it “incident management.” Informed IT departments also know that they need a formal mechanism and capability for effectively managing changes. However, it’s less likely that they feel compelled to manage problems – the “cause, or potential cause, of one or more incidents” – well. The 40 to 50% of IT organizations that don’t use ITIL best practice probably won’t know what problem management is anyway.

In my experience as an ITSM practitioner, consultant, industry analyst, and software vendor marketer, when I see surveys that indicate that 60-70% of organizations are undertaking problem management, I know that it’s an exaggerated statistic. Because many organizations only ever use problem management tools and techniques in a reactive way – usually in response to a major incident. This is not the same as actively looking for the root causes of issues and trying to prevent them before they occur. I’d be willing to bet that the real level of (proactive) ITIL problem management adoption is half of what surveys usually say.

The root of low ITIL problem management adoption levels

In my opinion, ITIL 4 can, and should, help drive up the level of problem management adoption in order to bring in proactivity and the ability to facilitate continual improvement and better business outcomes. So, to return to the question I posed at the start of this blog, why is the level of ITIL problem management best practice adoption not as high as it should be?

The main issue here is that the value of problem management isn’t quantified enough. While I can sit here and type that problem management is potentially one of the most beneficial ITSM capabilities, where are all the case-study-based proof points for ITIL problem management? Currently, getting started with ITIL problem management is more of a leap of faith for organizations because the return on investment isn’t clear to them. I think the benefits of ITIL problem management are definitely there, but organizations will only be sparked to embark on the ITIL problem management journey once they can quantify their potential return on investment.

The new, “more detailed” ITIL 4 best practice is now available via a My ITIL subscription. However, there’s no mention of the problem management benefits or return on investment (ROI) in the 35-page downloadable PDF. So, hopefully it will be one of the supplementary ITIL 4 publications that AXELOS is committed to offering to subscribers. To help you now though, I have some practical tips that you can use while you wait. I’ll return with another blog about how to get started with ITIL problem management, or how to improve what you’re already doing.

In his second blog, Stephen Mann gives 10 practical tips to help you get started with ITIL Problem Management

The post ITIL problem management: can ITIL 4 finally fix the problem? appeared first on MCG - EN.

Now admittedly, setting up and maintaining Problem Management can seem like another job to add to your already packed list. But with a bit of an agile attitude and with the aim of being both reactive and proactive, you can easily streamline the process. Here are 5 tips to consider.

1. Separate your incidents from your problems

It’s tempting to store everything in a hold-all space. To find somewhere that functions as a one stop shop when you’re dealing with a call. But separating problems out from incidents and logging them in their own dedicated space can help to better your processes.

It means that you have full clarity and transparency about the details of the problem, an accessible record of your investigation, and insight into the resources needed to fix it.

Curious about the differences between incidents and problems?

2. Keep a Known Error-database

Once you’ve put your investigative skills to the test and identified the root cause behind the problem, you have what is known as a ‘Known Error’. Just like incidents, known problems should also be kept in a separate area from the problem. Why? Well, it simply allows you to be more dynamic in your categorization. By doing this, if you need to recategorize an error to something more suitable post-investigation then you can.

Now, as you make discoveries about the problem at hand, the system has an up-to-date record of your thinking and your shifting priorities. Your Known Error-database then becomes an accessible and comprehensive archive of problems and their workarounds for future use. Once you resolve these Known Errors, you can happily close them and you have everything separated out when it’s time for reporting. Hooray!

How does ITIL 4 handle problem management?

3. Use the 5 Whys

Don’t get stuck in a rut. Be proactive in researching different techniques for identifying and interrogating problems. Challenging your tried and tested methods can provide a different perspective – and a different route to identifying root causes. For instance, adopting the 5 Whys method might lead you to ask a different question from usual when identifying the cause behind a server problem. Rather than forming a base conclusion, it encourages you to ask a series of questions until you arrive at the fault.

Researching different resolution methods is the kind of proactive background task that can pay dividends next time a problem arises. The 5 Whys is essentially to persistently ask why something is happening.

You know, that slightly annoying thing toddlers do: Why is the sky blue? Because blue light waves scatter more. Why? Because blue light waves are of higher frequency. Why? Because that’s how physics works! … Why…? You get the point. Do this until you really find the root cause of a problem and not a quick fix.

Challenging your tried and tested methods can provide a different perspective – and a different route to identifying root causes.

4. Have a Problem Manager

Having someone that is ultimately responsible for Problem Management can vastly help to improve your overall process. It means you have a colleague in charge who is enthusiastic about solving problems – and who can motivate the team towards the same goal.

But not only that. They’ll also have the crucial insight needed to monitor and analyse trends, which can help to validate the efforts and up-front energy that you’ve put into Problem Management. Beneficially, a Problem Manager can help to maintain momentum in the team, whilst supporting better internal organization when solving problems.

Industry-expert Stephen Mann has 10 practical tips to help you get started with ITIL Problem Management.

5. Let your operators contribute: Share Knowledge

Having a manager is great, but collaboration is key. Invite your team to make the most of their knowledge and experience by allowing them to contribute to Problem Management. This can add some interesting variation to their roles, and can help you to identify a root cause more quickly if you have keen colleagues who are good at detecting issues. If they have been on the front line reacting to incidents, they might have some thought-provoking insights in to the underlying Problems.

Using the knowledge of your team helps to embed cultural change, which ultimately means better Problem Management.

Take steps towards better processes

If you’re looking for an easy way to use ITSM processes better, without slavishly following every single step every time, find some inspiration in our Best Practice Service Management e-book.

The post Improving Problem Management: 5 best practices appeared first on MCG - EN.

A quick look at Google reveals that a lot of posts about Incident and Problem management are titled “Incident vs. Problem management”. Comparing these processes to understand the difference between them makes sense. But titles like that one also suggest something that isn’t true: these aren’t opposing process, they are complementary.

In a nutshell, Incident Management means a user has found a breach in their level of service, and you restore the issue so that everything is back on track. Problem Management is fixing this issue at the core.

When does an Incident become a Problem?

An Incident never becomes a Problem. That is to say: while most Incidents are a problem, no Incidents are a Problem.

A common analogy is that of the flat tire (see this post, for example). If you were curb your car and give yourself a flat tyre, this is an Incident – and can be fixed by the roadside. An example of a Problem would be if you were driving on a bald tyre. This is bound to lead to an Incident.

So the question isn’t when an Incident becomes a Problem. It’s: when does a Problem become an Incident?  And the answer to this is almost always. So what do you do?

Industry-expert Stephen Mann has 10 practical tips to help you get started with ITIL Problem Management

Proactive Problem Management

There’s a great post from Vawns Murphy over at ITSM.tools about the difference between the processes and how to work more proactively with Problem Management.

It boils down to less firefighting and more proactivity. And the way to get there is with a customer centric approach. Think of it like this: the customer will be happier if your Servers are always up, rather than if you fix the issue quickly every time they go down.

The point is to not wait for an Incident to happen but to always be on the lookout for things that may happen. Use trend analysis (or gut feeling in some cases) to argue that a problem needs to be addressed, and then go ahead and fix it before your Service Desk users are affected. Do the Servers always go down at the same time each month for some reason? There must be an underlying problem that has to be addressed.

Put the right people in charge

The key to success is to have dedicated problem solvers, and put someone in charge of this team of analysts. This person should ideally be separate from the person handling Incidents and have a different focus.

Incident Management analysts are out-ward facing, focusing on delighting the customer with speedy fixes of issues that arise. Your inward facing Problem Manager and team take care of the root causes of Incidents.

Your analyst(s) need to be aware of what Incidents occur, how often and what the root cause is. They can then begin to extrapolate and identify other sources of potential issues, before too many arise. The problem team and the incident team should be in constant contact and work towards the same shared goal: better service.

And while it may be attractive to do so, don’t spend all resources on fixing the major problems. Incremental adjustments to smaller sets of issues are just as important and will save frustration in the long run and stop these small problems from becoming bigger ones.

The post The key to proactive Problem Management appeared first on MCG - EN.