Yale University Incident Management

Process Guide

Yale University Incident Management Process 1 of 17

Introduction

Purpose
This document will serve as the official process of Incident Management for Yale University. This
document will introduce a Process Framework and will document the workflow, roles, procedures, and
policies needed to implement a high quality process and ensure that the processes are effective in
supporting the business. This document is a living document and should be analyzed and assessed on a
regular basis.

Scope
The scope of this document is to define the Incident Management Process, and process inputs from, and
outputs to, other process areas. Other service management areas are detailed in separate
documentation. The following is a specific list of items that are in scope for this document. Other items
not listed here are considered out of scope for this document.

In scope:

 Incident Management Overview

o Incident Definition
o Incident Management Objectives
o Incident Management Policies
 Incident Management Process Flow
 Incident Management Roles
 Incident Management RACI
 Incident Management Procedure Flows and Descriptions
 Incident Management Prioritization scheme
 Incident Management Service Categorization Model
 Incident Management Process Metrics

Yale University Incident Management Process 2 of 17

Incident Management Overview

Incident Definition
An Incident is an unplanned interruption to a technology service or reduction in quality of a
technology service. Failure of a Configuration Item or product that has not yet impacted service is also
an incident (i.e. failure of one disk from a mirror set).

Incident Management Objectives

The goal of Incident Management is to restore service operations as quickly as possible. Timely and
efficient resolution will minimize business impact and increase productivity.

Incident Management Policies

Incident reporting must go through the Service Desk, providing Users with a single point of contact
All incidents must be logged, prioritized and solutions recorded in the Incident Management System
One standard Incident Management Process is defined and used to support all IT Service users
The Service Desk manages, tracks, escalates, closes and communicates status of all incident records and is responsible for all
incident assignments
The Incident Management Process is the conduit of communication of any degradation of service, to the affected users and
IT personnel
Closure of incidents is dependent on validating with the user that the incident has been resolved and service is restored
The Service Desk will own all incidents that they themselves log or that are assigned to them from a Tier 2 provider.
Ownership will transfer to the Incident / Situation Manager for major incidents
Once a major incident has been validated by the Service Desk, escalation and communication protocols for high-
priority incidents are initiated and managed by the Service Desk

Yale University Incident Management Process 3 of 17

Incident Management Process Flow
V3 Incident Management Process
Caller /Customer

Incident Identification
Sources:
Event Mgt, Email, Self-Service, Phone
Call, Tech Staff (Tier 2 / Walkup) Management
Hierarchic
Escalation
Escalation Yes
Process
Needed?
Incident /
Group – Tier Group - Queue Situation
Manager

9.0 Major
No
Incident
Process
Functional

Manager

Yes 6.0
Investigation &
Diagnosis
Functional

2+ Analyst

2.0
1.0 4.0
Incident
Incident Logging Initial Diagnosis
Categorization 7.0
Resolution and
Recovery
Service Desk Analyst

Functional
Escalation
Required?
3.0 No
Service Major
No Incident
Request? Incident? Yes
Prioritization 8.0
Incident Closure
Yes
5.0
To Request Functional
Fulfillment Escalation
Process
Incident

Owner

Accountable for the Incident Process and its Evolution/Maturation

Roles
The following roles have been identified within the Incident Management Process.

Role Description
Incident Manager • Oversee day to day process execution
• Often the Service Desk Manager
• Manages major incidents until the appropriate situation manager is identified
Situation Manager • Manages and owns major incidents
Service Desk Manager • Manages the service desk function, including staffing management activities
• Provides guidance to Service Desk Analysts
Incident Process Owner • Owns the process end-to-end, including the RACI, process & procedural steps, role
& definitions
• Accountable for maturing and evolving the process, based on
monthly/quarterly/yearly review of process KPIs
• Adjusts the process to address performance or changing business needs
Service Desk Site Lead • Responsible for the operations of Service Desk Analysts that are geographically
disperse, reporting to the Service Desk Manager
Service Desk Analyst • Logs incidents
• Provides initial diagnosis
• Resolve incidents at first point of contact if possible
• Escalates incidents

Yale University Incident Management Process 4 of 17

Role Description
• Owns non-major incidents

Caller / Customer • The end user having or reporting the service interruption
Functional Group – Queue • Assigns incidents to individual Tier 2+ Analysts in the functional group
Manager • Monitors and manages support resolution performance
• May directly manage (reporting manager) the day to day activities of Tier 2+
analysts outside of process activities
Functional Group – Tier 2+ • Group of technical support experts that will handle issues escalated by the Service
Analyst Desk
• For example, a Network Engineer
• Receive process direction for a functional group queue manager, staff
management from a reporting manager

RACI
Caller / Service Service Incident Situation Functional Functional Incident
Customer Desk Desk Manager Manager Group – Group – Tier Process
Analyst Site Lead Queue 2+ Analyst Owner
Manager
1.0 Incident
C R A R
Logging
2.0 Incident
Categorization C R A R
3.0 Incident
Prioritization C R A,C,I

4.0 Initial
Diagnosis R A,C,I R
5.0 Functional
Escalation R A, C

6.0
Investigation & A R
Diagnosis
7.0 Resolution
& Recovery I R A R

8.0 Incident
Closure C R R A R

9.0 Major
Incident A R R
Process
Process
Maturity and C, I C R R C R C A
Evolution

Yale University Incident Management Process 5 of 17

Process Procedures
1.0 Incident Logging
/ / Functional Group– –

1.1 Verify Issue

Exists
Group

1.2 Update Incident

Existing Activity Log &
Yes Status Provided
Incident? Communicate
Status
No
Func tional

tAnalys
Analyst

1.3 Validate
Analyst

2+ +2Tier

Caller / Customer
Analyst

Contact details
and update if
required
eServicService Desk
Tier
kDes

1.4 Capture and

4.0 2.0
Document Incident
Details

Step Activities
1.1 Verify Issue Exists Take steps to validate or replicate the interruption. Gather any data about the issue
(screenshots, descriptions).
Associate to any concurrent incident (e.g. major outage).
1.2 Update Incident Activity Log & If the Caller is inquiring about status of an existing incident, provide the caller with
Communicate Status status as available in the incident record and update the record indicating that the
caller was inquiring and update with additional details if available.
1.3 Validate Caller / Customer Complete caller data and ensure contact details are accurate and update if necessary.
Contact details and Update if
Required
1.4 Capture and Document Incident Complete the short and long description, ensuring they are clear and can be
Details understood by others.
Collect incident symptoms.

2.0 Incident Categorization

––

2.2
2.0 2.1 Associate 2.3 3.0
//

Identify Incident Complete Incident

Group

Configuration
Type Categorization
Group
Desk

Item(s)
Analyst
kDes

Analys
t
Analyst

Tier Tier 2+
Analyst

2+
ServiceService

lFunctionaFunctional

Yale University Incident Management Process 6 of 17

Step Activities

2.1 Identify Incident Type Capture the incident type based on the customer-reported symptoms.

2.2 Associate Configuration Items(s) If a Configuration Management System (CMS) is If there is no CMS present,
present, associate the incident to the capture the device name or ID,
Configuration Item(s) (CI) diagnosed to have and based on the primary failed
failed and are causing the incident. Note, IT device, capture the component
Business and Provider Services may be captured categorization.
as CI’s, if implemented.
2.3 Complete Incident Capture IT Business Service categorization, as defined by the customer. Based on the
Categorization symptoms and incident diagnosis, capture the IT Provider Service categorization.

3.0 Incident Prioritization

Service Desk Analyst

2.0 3.1 Major 4.0

No
Prioritize Incident Incident?
Analy st

Yes
Desk

3.2
Escalate Incident
to Incident
Manager
Manager Manager Service

9.0
Incident Incident

Step Activities

3.1 Prioritize Incident Select the impact and urgency of the Incident according to guidelines if it is not
present. This will determine the priority.
If priority-based service level monitoring is enabled, the selected priority to define the
response and resolution time service level targets for the incident.
If service-based monitoring is enabled, the selected priority will only define the
response time service level targets for the incident. If the reported service does not
have any restoration service level targets defined, a generic priority-based restoration
service level target may be used.
3.2 Escalate Incident to Incident Determine if this is a major incident. If so, the service desk agent will escalate to the
Manager / Situation Manager incident manager accordingly.

Yale University Incident Management Process 7 of 17

4.0 Initial Diagnosis
Customer

4.3 Acquire
Caller /

Additional
Information
ServiceService Desk Analyst / / Functional

3.0 4.1 Perform Initial

Yes 1.0
Diagnosis
Functional

Analyst

Analy
st
Tier 2+

4.2 Search 4.4 4.6 Update Incident

Knowledge Base, More 4.5
+
2

Incident Details linking to Known 5.0

Known Error Information No Resolution No Recurring No Error, Knowledge Article,
Database and Required? Possible? Incident? Change as required
Analyst

Tier

Change Schedule

Yes Yes
Group Group ––
kDes

7.0 Problem
Management
Process

Step Activities

4.1 Perform Initial Diagnosis Document all trouble-shooting steps within the incident record.

4.2 Search Knowledge Base, Known Use initial diagnosis details to search the knowledge base for relevant knowledge.
Error, Database and Change Also check the known error database to see if a workaround exists and the change
Schedule schedule to see if this is issue could be related to a recently implemented change.
Ensure the incident record is coded appropriately.
4.3 Acquire Additional Information If additional information is required, contact the customer. If the customer cannot be
reached, place the incident on hold.

4.4 Incident Resolution Possible? If a resolution is possible, proceed to step 7.0 Resolution and Recovery. If resolution
is not possible, the incident may need to be assigned to a functional group for
resolution.
4.5 Recurring Incident? Determine if other incidents of the same nature have been experienced. If others
exist and no root cause has been determined, this may be a good candidate for
problem management.
4.6 Update Incident Details linking to Confirm that the incident record is updated and coded according to the diagnosis
Known Error, Knowledge Article, steps. Selection of a knowledge record may update (e.g. provider service, component
Change as required category, urgency) incident categorization and details.

Yale University Incident Management Process 8 of 17

 5.0 Functional Escalation

4.0
Service Desk Analyst

5.1 5.3 Assign

Monitor Incident
Internal Yes Incident to
(Incident Ownership Activity)
Provider? Functional Group
6.0
Analyst

No
Des
k

8.0 5.2 Dispatch to

6.0
Vendor and
Monitor Incident
Servic

9.0
e
rd

Vendor
rd
//33

Diagnosis
7.0
VendorProvider

and Incident
Resolution If
Possible
rVendo

Provide
r
Party

Party

Step Activities

5.1 Internal Provider? If assignment is necessary, determine if the functional group that is equipped to
resolve the incident is an internal support group or an established external partner
that has a support agreement and process established for incident resolution.
5.2 Dispatch to Vendor and Monitor If the functional group is an external group, ensure that the established incident
Incident process is followed.

5.3 Assign Incident to Functional If the functional group is an internal group, determine the proper group for
Group assignment and assign it to the Group.

5.4 Monitor Incident Optimally, the Service Desk owns the monitoring of incident to resolution and
closure. Guidelines for ownership/monitoring include:
- Providing customers with desk contact info for updates
- Progress notifications originate from a desk monitored email account
- Incidents that have not been accepted within response time targets should
be initially escalated to the assignment group manager, and ultimately to
the Incident Manager if required
- Ownership of major incidents should be transferred to the incident
manager/ situation manager

Yale University Incident Management Process 9 of 17

 6.0 Investigation and Diagnosis
Caller / /

5.0 6.3 Contact

Requestor for
Additional
Information if
rCalle

C us to mer

required and
Custome
r

update Activity
Functional Group– – Tier 2+ Analyst

Log
6.2
5.0 Update Incident
and Assign to
Yes
Service Desk for
Analys
t

Re-Diagnosis and
Re-assignment
2+

Functional No 7.0
Escalation?
No
Tier

6.1 Perform Initial Yes

Accept
Incident Review
Incident? 6.4 Tier 3
and Diagnosis
Grou
p

Functional Diagnosis
Escalation to Tier and Incident
3 Resolution
Functional

Step Activities

6.1 Perform Initial Review & Perform initial review to determine if the incident has been properly assigned.
Diagnosis

6.2 Update Incident and Assign to If the incident was improperly assigned, the Functional Group assigns it back to the
Service Desk for Re-diagnosis and Service Desk for further diagnosis and assignment.
Re-assignment
6.3 Contact Requestor for If assignment is proper, accept the incident (work in progress) and determine if
Additional Information if Required further information is required contact the customer to obtain then proceed to step
7.0 Resolution and Recovery.
6.4 Functional Escalation to Tier 3 if If the incident requires further assignment to Tier 3 or an external Vendor, the
required Functional Group is responsible to work with the external partners and maintain
oversight of the incident record.

Yale University Incident Management Process 10 of 17

 7.0 Resolution and Recovery

7.4 Service Desk

Desk

4.0 Analyst Contact

Functional Group
k Des

or Vendor for 8.0

ServiceAnalyst

Additional
7.2 Work to Resolution Details
Problem Management
7.1 Communicate Resolve Incident Process - Document Known if Required
Workaround if Updating Incident No
Service
Analys

Error or Workaround (if

t

Appropriate with Necessary

5.0 applicable)
Details
rTie
Group –– Tier+22+

6.0
Resolution
Incident
requires Change No Yes
Resolved?
Request?
pGrou

Analyst FunctionalAnalys

Yes 7.3 Update

Incident
Change Resolution Details
t

Management and Assign to

Process Service Desk
Functional

Step Activities

7.1 Communicate Workaround if Investigate sources of information to see if a workaround exists. Check relevant
Appropriate knowledge, known error database, problem records, etc. and provide the work
around to the customer.
7.2 Work to Resolve Incident If no workaround exists, begin resolution activities making sure to update the incident
Updating Incident with Necessary record with all details related to resolution activities.
Details If resolution requires that a change be introduced, a Request for Change must be
submitted and flow through the Change Management Process.
7.3 Update Incident Resolution Once the incident has been resolved it is good practice to review the solution and
Details and Assign to Service Desk determine if knowledge could be authored for future occurrences, or if there is a
systemic issue that needs to be addressed through the Problem Management
Process.
Upon resolution, the incident is updated with the proper resolution information and
coding, and is assigned to the Service Desk for final closure activities.
7.4 Service Desk Analyst Contact In preparation for closure activities, review the incident details to ensure it is
Functional Group or Vendor for completed properly and has the appropriate resolution details.
Additional Resolution Details if
Required

Yale University Incident Management Process 11 of 17

 8.0 Incident Closure
Caller /
/

8.3 Trigger
Incident Yes Customer Incident Closed
9.0 Resolved? Satisfaction
Caller

Survey
Custome
r

Custome
r

8.1 No
Service Desk Analyst

Validate Incident
Resolution with
Caller / Customer
8.2 Update
7.0 5.0
Analyst

Incident for Re-

Diagnosis
Des
k
Service

Step Activities

8.1 Validate Resolution with Caller / Follow proper procedures to validate with the Customer that the incident has in fact
Customer been resolved. If it has been resolved, the incident will be closed according to
procedures.
8.2 Update Incident for Re-Diagnosis If the Customer indicates that the incident has not yet been resolved, it must be sent
back for further diagnosis before the incident is closed.
NOTE: If the incident is in a closed state when the customer indicates it was not
resolved, a new incident should be opened and associated to the original incident.
8.3 Trigger Customer Satisfaction Once the customer has confirmed resolution and the incident is in process of being
Survey officially closed, a customer satisfaction survey is to be provided to inform future
improvement opportunities.

Yale University Incident Management Process 12 of 17

 9.0 Major Incident Process
IncidentManager

3.0 9.1 Validates

Major Incident 9.4 Prepare Major Incident
documentation as defined 8.0
& Perform Post Resolution
Manager
Incident

Review

9.3 Trigger and

execute
communications
as required until
Incident Resolved
Situation Manager

9.2 Ensure
Assignment of 5.0
Incident to
Functional Team

Consult with
Business & IT to
invoke Business/IT
Service Continuity
Plans as defined

Step Activities

9.1 Validate Major Incident If an incident is escalated to a “Major Incident” status, the Incident Manager
must first ensure that it should be treated as a Major Incident and be given
the enhanced communication and management attention that a Major
Incident requires.
9.2 Ensure Assignment of Incident to Ensure that the incident has been assigned to the appropriate team for
Functional Team resolution and works with the management structure to coordinate a cross-
functional team to address the situation if needed and where the underlying
issue is unclear.
9.3 Trigger and execute communications as Ensure that the communication is planned and executed according to internal
required until Incident Resolved procedures and triggers. At a minimum communication is to be shared at the
beginning and end of a Major Incident and perhaps at specific intervals
throughout the resolution process. This communication can be to either
internal IT stakeholders or Customers or a combination of both.
9.4 Prepare Major Incident documentation Upon resolution of a Major Incident, documentation must be prepared that
as defined & Perform Post Resolution summarizes the issue, actions taken and resolution details. It should also
Review trigger root case analysis if required and allow for improvements that can be
made to avoid the situation in the future.

Yale University Incident Management Process 13 of 17

Prioritization scheme
The prioritization scheme is based on a combination of Impact and Urgency and used to:

 Generate a simplified value in order to drive escalation and notification

 Establish appropriate ‘order and extent of work effort to achieve resolution

Impact:

 Measure of scope and criticality to business

 Often equal to the extent to which an incident leads to distortion of agreed or expected
service levels
 Impact is often measured by the number of people affected, critical systems, or financial
loss as a result of the service interruption

Urgency:

 Measure of how quickly an incident needs to be responded to based on the business

needs of the customer
 Prioritizes workload; incidents with higher urgency will be addressed before others,
unless SLA breaches are imminent

The follow table shows the resulting priority based on impact and urgency.

Service Categorization Model

A Service Categorization model is an important aspect that:

 Recognizes need to capture service vs. technology details

 Future-proofed for introduction of Service Asset and Configuration Management
 Enhances value of reporting by defining IT service view in terms the business should
understand

Yale University Incident Management Process 14 of 17

The following shows the 2 Service Categorization levels that enable views from both Customer/Business
and Provider perspectives:

Process Metrics
The following table describes the Incident Management KPIs identified.

Yale KPI KPI Name OM DESCRIPTION

#
2.1 % Incidents logged How many tickets are incidents? Incidents are tickets
excluding service requests and complaints
DERIVED Incidents by Source (e.g. Call, Email etc.) How many incidents are logged via calls
11 First incident resolution How many incidents were resolved correctly in first
attempt?
12 Incidents resolved at Help Desk How many incidents were resolved at the help desk?
13 Incidents that bypassed help desk support How many incidents were not reported to help desk
17 Reassignment Count How many incidents are reassigned to another work-
group?
14 % Incidents assigned incorrectly How many incidents are assigned to the wrong work-
group?
% Incidents escalated Inaccurately How many incidents are assigned from Tier 2 to Tier 2,
vs. being reassigned to Tier 1

15 % Incidents escalated Incidents that are escalated to another group

17 Average time for second level support to Time elapsed between a call being assigned to second
respond level support and the call being accepted

Yale University Incident Management Process 15 of 17

Yale KPI KPI Name OM DESCRIPTION
#
18 Incidents reopened How many incidents were reopened?
19 Ageing incidents How many incidents are unresolved past threshold
20 Incidents responded on time (Tier 2) How many incidents were responded on time by Tier 2

NEW Incidents responded on time (customer- How many incidents were responded to on time from
perspective) logging to last in-progress

21 Incidents resolved on time How many incidents were resolved on time

DERIVED Incidents by Priority
24.1 Cost per Incident Ratio of operational budget to users of IT services

Yale University Incident Management Process 16 of 17

Document History
Version Date Changes Author
01 12/31/2011 Initial Document Angie Massicotte /
Michael Oas
02 01/02/2012 Minor Updates Michael Oas

Yale University Incident Management Process 17 of 17