For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone
Note: ® ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.
The Itil Community Forum: Forums
ITIL :: View topic - The role of the incident manager... and who it is...
Joined: Oct 30, 2008 Posts: 3 Location: New Zealand
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
Joined: Mar 04, 2008 Posts: 1277 Location: Newcastle-under-Lyme
Posted: Fri Oct 31, 2008 7:50 pm Post subject:
Ants,
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
Joined: Oct 30, 2008 Posts: 3 Location: New Zealand
Posted: Wed Nov 05, 2008 5:45 am Post subject:
Diarmid,
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
We are setting up Incident Management and here's how we've divided it. It's not too late for us to veer a little from this path.
I'm paraphrasing:
Service Desk - function - owns all incidents.
Incident Manager - management person - responsible for the process and process-related issues.
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.
Joined: Oct 30, 2008 Posts: 3 Location: New Zealand
Posted: Wed Nov 05, 2008 11:53 am Post subject:
Thanks RP,
That's pretty much how we are targeting it also, though we do have different terminology for the names:
Incident Process Owner = Your Incident Manager
Incident Manager = Your Incident Commander.
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
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum