Branimir Valentic
July 29, 2014
Remember this situation? You’re running Windows. The blue screen forces you to reboot your PC. And then it happens again.
Incident Management = reboot your PC. And your service (usage of PC) is available again.
Problem Management = figuring out what actually happened (why does that PC get the blue screen), and how to prevent such incidents from occurring.
Incidents are straightforward – you need to provide your users with the agreed functionality as soon as possible (to use their PC and be able to send/receive e-mails, write documents, do calculations… etc.). And – that’s it. Complications take place when we start to deal with problems. Problem resolution methodologies are well known:
Any of the chosen methodologies require an organization to get the problems resolved. The more critical issue is when Problem Management organization has to be set.
Before declaring something to be complex, let me elaborate. Getting to the problem resolution is not a one-dimensional process. Well, if you have just a few (but, really few) services – it could be. But companies strive to extend their offerings and, there you go – many different parties, know-how, technologies… etc. are the common ground that lead things to become complicated.
Problem Management has to the find root cause of one or more incidents. Root cause means to figure out what caused an incident. Take a telecom as an example. Many, many customers using a bunch of services. In the background, there are many departments inside the telecom organization that are supporting those services. Problem Management organization has the following challenges:
Well, so far about challenges. Let’s see what could be done to overcome them.
First of all, there is no recipe for how to organize a Problem Management support organization. Every situation and organization is unique and requires its own approach. From my experience, there are several possibilities; let me describe the two most common:
Figure: Two different kinds of Problem Management organizations
Roles and responsibilities are another important parameter when organizing for Problem Management. According to the ITIL Service Operation book, there are two important roles in Problem Management organization: Problem Manager and Problem Analyst.
Problem Manager is responsible to organize processes, resources and tools that are needed to resolve the problems. This is much easier when there is a stand-alone organization. When shared resources are used, the Problem Manager is responsible to organize needed resources and coordinate their activities. This could get even more complicated when, e.g., external resources are used. Operational Level Agreement (OLA, for internal resources) and Underpinning Contracts (UC, for external resources) are within the Problem Manager’s responsibility. Read more about OLA and UC here: SLAs, OLAs and UCs in ITIL and ISO 20000.
Problem Analyst – this is the person who actively and productively contributes to problem resolution. Independent of the organizational setup, the most important characteristic of a Problem Analyst is – expertise. If the problem requires different kinds of expertise, then several analysts will be involved (as a team).
Problem resolution targets are defined in the Service Level Agreement (SLA), or at least it should be, though I rarely found an explicit definition of Problem Management in the scope of a SLA. But within the SLA, there should be a time determinant that makes problem resolution a serious “game.” Depending on the situation, there are many challenges when organizing for Problem Management. Given customers and respective SLAs as drivers, and our own know-how and experience as instruments, problem resolution should not be hard – but rather a fun game.
Download a free sample of the Problem Management process to gain a deeper understanding of how to set up the organization and the process itself.