IT Services Implementation Plan/Project Plan Skeleton Outline Process: Incident Management Status: Version: Release Date: 0.1 Planning and implementation for Incident Management This document as described provides guidance for the planning and implementation of the Incident Management ITIL process.
The document is not to be considered an extensive plan as its topics have to be generic enough to suit any reader for any organization.
However, the reader will certainly be reminded of the key topics that have to be considered for planning and implementation of this process.
Initial planning When beginning the process planning the following items must be completed: CHECK DESCRIPTION ??? or ?? or date Get agreement on the objective (use the ITIL definition), purpose, scope, and implementation approach (e.g.
Internal, outsourced, hybrid) for the process.
Assign a person to the key role of process manager/owner.
This person is responsible for the process and all associated systems.
This will person will generally be the Service Desk Manager.
However, it is important to understand the differences and common conflicts that can occur between the two roles, for example, the Service Desk Manager may be concerned with call volumes and answer times, whereas the Incident Manager may be concerned with percentage of resolution at first point of call.
Conduct a review of activities that would currently be considered as an activity associated with this process.
Make notes and discuss the “re-usability” of that activity.
Three key activities of Incident Management should always remain with the Service Desk.
They are: ? ? ? Tracking, Monitoring and Co-ordinating of Incidents and Service Requests Incident Recording Incident Closure Create and gain agreement on a high-level process plan and a design for any associated process systems.
NOTE: the plan need not be detailed.
Too many initiatives get caught up in too much detail in the planning phase.
KEEP THE MOMENTUM GOING.
Review the finances required for the process as a whole and any associated systems (expenditure including people, software, hardware, accommodation).
Don’t forget that the initial expenditure may be higher than the ongoing costs.
Don’t forget annual allowances for systems maintenance or customizations to systems by development staff.
Agree the policy regarding this process 2.
Create Strategic statements.
Refer to the Policies objectives & scope document (available within this toolkit) for more template information regarding Policy, Objective and Scope statements.
Policy Statement The policy establishes the “SENSE OF URGENCY” for the process.
It helps us to think clearly about and agree on the reasons WHY effort is put into this process.
An inability to answer this seemingly simple, but actually complex question is a major stepping stone towards successful implementation The most common mistake made is that reasons regarding IT are given as the WHY we should do this.
Reasons like to make our IT department more efficient are far too generic and don’t focus on the real issue behind why this process is needed.
The statement must leave the reader in no doubt that the benefits of this process will be far reaching and contribute to the business in a clearly recognizable way.
Objective Statement When you are describing the end or ultimate goal for a unit of activity that is about to be undertaken you are outlining the OBJECTIVE for that unit of activity.
Of course the activity may be some actions for just yourself or a team of people.
In either case, writing down the answer to WHERE will this activity to me/us/the organization is a powerful exercise.
Read more about ITIL: