I’m asked to write this blog post for someone who has recently stepped into a new Incident Manager role. In order to help someone get started, what kind of things do Incident Managers do?
Ideally of course you’ll have worked for an effective Incident Manager yourself, in an effectively-managed IT service management operation. If not, and particularly you are promoted unexpectedly, it can be a bit daunting.
First of all, go right back to the start. Incident Managers ultimately are responsible for the Incident Management process, the goals of which can be read here. If you then expand this to include the Incident Life Cycle, you get more clues.
My brief for this blog is to focus on detail and practicalities. So what I’d do is try to give a flavour of some of the things you’d expect to do with the emphasis on practicalities. It’s not exhaustive, but I hope it will give you an idea.
1. Ownership of the Incident Management Process.
If you are an Incident Manager, you will try to describe how your Incident-handling team work with Incidents, with each other, and what you expect of them. The best Incident Managers I’ve been lucky enough to work with have been clever enough to produce easily readable, useable documents. These documents describe such things as how to escalate an Incident, how to handle Major Incidents, who has responsibility for Incidents where in the cycle, it defines some roles and assigns specific people to roles... hopefully you get the idea.
What you are trying to define is ‘how can we guarantee that, when an Incident is logged, we’ll deal with it professionally and to the customer’s satisfaction?’.
But here’s where the effective Incident Managers are marked out from the also-rans. The effective ones take the time to explain the process to the Incident team – in effect to ‘sell’ it to them. They don’t just send an email saying ‘dear all, this is what I want you to do, I’m off for a round of golf’. Instead, they hold presentations, meetings – anything that will get the message across.
2. Making Sure the Incident Management Process is followed.
It’s something I see all to often. Someone has written some guidelines, or an Incident document, emailed it to staff, and that’s the last anyone sees of it. The document (ie, the Incident Management Process) is disregarded and ignored.
The effective Incident Managers act as policemen.
If they ask for resolution information for each Incident to be complete an accurate (so as to be of use later for Knowledgebase searching) then they try to ensure that that:
a: There is some checking of this in the Incident Management process itself.
b. From time to time they examine Incident records themselves. For instance, if they are a Serio user they might look at the Incidents resolved in the past week and examine the resolution information themselves, re-opening Incidents that don’t cut the mustard (and possibly tweaking the IM process itself).
Effective Incident Managers realise that alerts and information generated by an ITSM tool are all well and good, but that many staff may ignore these at first (in fact, you set-up your tool to generate lots of alerts and notifications this is absolutely going to happen), so they look for signs of people not using their tool effectively. There are lots of subtle ways this kind of thing can be addressed, starting with ‘a quiet word’ and a little extra training.
3. Asking ‘is the Incident Management process effective’.
This is not the same thing as point 2. For the most part, the Incident Manager will use a wide range of statistics for this, and will adjust the Incident process as required. Examples of KPIs can be found here for Incidents and here for Problems, and also see our white paper. Please note, as I’ve described countless times before this does not mean simply pulling a few metrics from your ITSM tool and giving them to your boss (if an Incident Manager had done that to me, I would have given them straight back). It means the Incident Manager sitting down and deciding what data they will examine, drawing conclusions, and making recommendations for improvement.
4. Managing the work and workloads of the Incident Management teams.
What this means is this: from time to time bottlenecks appear. For instance, you might get a situation where 100 Incidents are with your one-man networks team, and virtually no Incidents being handled by others.
Incident Managers keep abreast of these kinds of issues, and take corrective or remedial action as required. For example, by re-assigning work, hiring contract staff, re-scheduling non-urgent tasks. For Serio users, this is as simple as using the Assignment and Ownership performance charts effectively.
For many Serio users, the Incident Manager is actually the supervisor for the front-line Service Desk/Helpdesk team, an arrangement that usually works very well.
As a finish, I’d recommend that our new Incident Manager pick up a copy of ‘Best Practice for Service Support’. It’s a great source of information, and you can get it from amazon.co.uk.