<img height="1" width="1" style="display:none;" alt="" src="https://dc.ads.linkedin.com/collect/?pid=42246&amp;fmt=gif">

8 September 2017

The key to proactive Problem Management (Incidents vs. Problems)

bleh-472651-edited.png

Incident Management is a core task for any Service Desk. And we all know that Problems lead to more Incidents. How then, do you avoid more Incidents with proactive Problem Management?


A quick look at Google reveals that a lot of posts about Incident and Problem management are titled "Incident vs. Problem management". I understand that you want to compare these processes and understand the difference between them. But that title also suggests 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?

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 everytime 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.

Dude with PC and Arrows.png

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. Incramental 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.

Download the BPSM eBook

 

Comments