Posted: Fri Oct 31, 2008 12:18 pm Post subject: The role of the incident manager... and who it is...

Hi.

My organisation is in the process of putting together an process that encompasses the end to end incident process (we currently have a robust one for major incidents, but nothing formalised for the others). There is general agreement of most of the roles and responsibilities with one exception.

The Incident Manager. (My job title may say 'Incident Manager' but I am the process owner)

Our service desk is not skilled or resourced to a level that would allow the individual analysts to step into the role of the incident manager, so a few options to counter this have been raised in discussion.

The 5 alternatives we have come up with are:

[list=]Task our service operations team with the role (they currently provide this for major incidents)
Task our customer managers with the role (they do this for the occassional incident)
Task our support team leaders with the role.
Train and resource our service desk to the point where they are able to perform the role.
Appoint staff into the role of Incident Manager, thereby creating a team of people who are fully responsible for the process from end to end.[/list]

My preference, obviously, is the last one (with a slight leaning towards upskilling the desk), but others don't necessarily see it as thus - the question of cost comes into things here; hiring at least 2 new staff will not be cheap. As a result, I have been asked to draw up a list of pros and cons of each area.

I've got a standard list of these, covering off areas such as cost (some of the options are cheaper than the others), resourcing and understanding of the process/service. Just wondering if anyone would like to share their thoughts in case I (with the help of my brains trust) have missed anything.

Cheers
Ants_________________Be the change you want to see in the world

if you start by documenting the detailed and specific objectives and requirements of the role and how it fits within your service management, then you may find that some of your options are non-starters and others are more likely.

This way you will understand more about the resource, skill, knowledge and capability requirements. You will begin to understand where control has to lie and whether there are conflicts of interest with other roles.

If the role you have in mind is capable of strong detailed prescription, that is very different than if it requires good strategic perspective and wide ranging decision making.

There are a lot of incident processing activities that are fairly mechanical in nature (i.e. they are carried out according to instructions and triggers), but tasks like co-ordinating, prioritizing, evaluating and escalating require a certain perspective, authority and independence._________________"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718

We've progressed quite a way down the path of developing the roles and responsibilities already. So far, what we've managed to agree the following for the role of the Incident Manager

• Ownership of the incident
• Monitoring of the incident and reporting on process compliance across BTS
• Tracking of the incident
• Ensuring effective communication to Senior Management, Customers, Users and Technical Staff
• Escalation and engagement
• Ensuring that all details of the incident are recorded including service impacts and management summaries.
• Ensures the quality of the process
• Governing the incident process through the life of an incident and ensuring it is followed
• Liaising with all required parties through the life of an incident
• Co-ordinate activities between multiple ‘n’ level support groups to ensure adherence to the Service Level Requirements (SLR) where multiple groups are needed to resolve a single incident.
• Ensuring compliance across processes and collaborate with other Process Managers.

This has allowed me to rule-out 3 of the options - Our Shift Operations, Customer Managers and Service Desk - due to the way they are currently set up and the overheads involved in changing these. However, the issue(and why I've turned here for a little advice) is that our management want to see strong arguments against for and against any of the afore mentioned roles stepping into the role of Incident Manager.

So, any further advice?_________________Be the change you want to see in the world

Incident Commander - Svc Desk agent - responsible for 1 or more individual incidents. Includes assigning to other tiers (functional escalations) and determining if hierarchical escalation is needed. Verifies resolution with customers. Ensures incident record reflects the actual work done. Closes incident. The person in the IC role may change, for example, during long-running incidents.

Incident Assignee - person with appropriate skills/authorities - responsible for investigating and resolving incidents. The IC and the assignee may be the same person.

In summary, within Incident Management, one person drives the process while others drive the individual incidents.

Where I'm getting the push back is who should fulfill the role of Incident Manager/Commander. The ideal would be to have dedicated resource that sits on the Service Desk fulfilling this role, what management want to see is how this will be more beneficial than utilising a technical manager, customer manager or other to do the role.

As mentioned earlier, we have a fairly robust Major Incident process which I am trying to replicate across the board, just with different priorities and people filling each role._________________Be the change you want to see in the world