Branimir Valentic Incident management is always “hot stuff” in IT Service Management (ITSM). While reading ITIL literature you will notice many elements that need to be considered. But, one of the fundamental issues (not emphasized enough) is – to make a good start, i.e., successfully implement the incident management process.
Incident management is the most “lively” process among all ITIL-recommended processes. It deals with difficulties or errors users face on (usually) a daily basis. That puts even higher pressure on the process implementation. That’s why it is important to start well.
5 biggest challenges
Let’s be honest – there are many issues that arise while setting up a process. While being in contact with many different organizations I’ve chosen five most common challenges that arise while setting up the incident management process:
Organizational complexity – there is no “one size fits all” solution. What I want to say is that every organization is different. So are the management of the organization, relationship between organizational units, technology in place, etc. As an organization grows, complexity of the processes is increasing, too. To minimize the impact of those factors, managed incident management process implementation is necessary. Meaning – opposite of ad-hoc implementation like “We need to do something, and we need to do it immediately.” You would wonder how many organizations are doing exactly that. Further on, I found quite often that the trigger for the incident management process implementation is – a serious incident, resulting in huge service outage or service loss. Don’t wait for that – it’s too late. Think one (if possible – two) step ahead and be in front of potential pitfalls (i.e., situations when incidents with significant impact already took place).
People – you (significantly) rely on people. I have seen excellent process implementation, but once they get into the operational stage – people were the “knock-out” factor (i.e., cause of the process inefficiency). First of all, people like to do things they always did, meaning they don’t accept changes easily. Education, communication, and keeping them involved in the implementation project usually help. One of the critical issues is that when people see that the process implementation project is not running well (the usual consequence is that even more chaos is created) – some of them will leave. But, that’s usually the organization’s best people. How to keep them? Well, everyone has their own trigger. Someone likes to be involved from the beginning of the project (having some significant role during the implementation), somebody else likes to have everything ready and prepared and doesn’t like to interfere, somebody is expecting to get a more important (or, higher ranked) role inside the IT organization, etc. So, approach them individually, but don’t lose them.
Getting management buy-in – Well, I’m sure you can’t go without them. But, the question is – how to get them on board? The usual answer is – it’s hard. And, it is so. But, what they like to hear about is the efficiency, savings, and monetary-based explanation or needs for resources (both human as well as any other like technology that needs to be implemented). So, you should better prepare facts and figures and adapt to the way managements talks. The latter part is not that complex. Remember that they don’t like long discussions. What they do is – make decisions. So, prepare the options, argumentation for the options, and your recommendation. They will ask questions, but they will know – you are prepared and you know what you are talking about. Believe me, they appreciate that. The article How to translate ITIL/ISO 20000 language into business language understandable by your management can help you understand how your management communicates in order to prepare yourself for meeting with them.
Roles and responsibilities – ITSM can be (easily) complex from an organization and process point of view. There are a variety of activities and people involved. The incident management process is very sensible on how the process is set and who is doing what. So, one of the concerns while setting up the incident management process is how to assign roles and respective responsibilities and not to create too much overhead and bureaucracy. A RACI matrix is one of the ways you can do that. Read the article ITIL / ISO 20000 RACI matrix – How to use it to clarify responsibilities to learn more about the RACI matrix.
How to organize the implementation – As a project? Or not? The incident management process implementation has most of the aspects found in projects – time frame, milestones, resources, inputs, deliverables, roles and responsibilities, etc. So, it’s logical that you will organize implementation of the incident management process as a process. But, don’t complicate it too much. Narrow project structure and strong leadership should be enough. Read the article ITIL and ISO 20000 – What does Project Management have to do with it? to learn more about how to use ITIL and project management.
What’s afterwards (once the process is implemented)?
Well, then the real “fun” starts. Incidents will start coming and your incident management process is on test. The incident management process involves the customer as well, and that makes the efficiency of the process even more visible. Using the services (by the customer) takes place for a long time. Therefore, once implemented, the incident management process will dictate daily activities of many ITSM employees for a long time. That puts even more weight on the implementation.
And, that’s not the end. You can have the best people working for you, but you have to be aware of the fact that there will be always places for improvement. Here I don’t mean only services, but also processes. They are good material for improvements. And that’s good. On one side, the business dictates constant adaptation (to the changed business requirements) and on the other side, the ITSM organization grows in experience. And that’s opening new ideas of how to be better. On a day-to-day basis.
Use this free ITIL Gap Analysis Tool to check ITIL recommendation towards the incident management process.
