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
Customer
Caller /

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

Manager
Group – Tier Group - Queue Situation

9.0 Major
No
Functional

Incident
Manager

Process

Yes 6.0
Investigation &
Diagnosis
2+ Analyst
Functional

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

Functional
Escalation
Required?
Service 3.0 No
Major
Request? No Incident
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
Group––

1.1 Verify Issue

FunctionalGroup

Exists
Analyst/ /Functional

1.2 Update Incident

Existing Activity Log &
Yes Status Provided
Analyst
Tier 2+ Analyst

Incident? Communicate
Status
No
2+

1.3 Validate
DeskAnalyst

Caller / Customer
Tier

Contact details
and update if
required
ServiceDesk
Service

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

Group––
Analyst
Functional Group
2+Analyst
Desk

2.2
ServiceDesk

2.1 2.3
Analyst / /

2.0 Associate 3.0

Identify Incident Complete Incident
Analyst

Configuration
Type Categorization
Functional

Item(s)
Service

Tier2+
Tier

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

Analyst

2.0 3.1 Major 4.0

DeskAnalyst

No
Prioritize Incident Incident?

Yes
ServiceDesk
Service

3.2
Escalate Incident
to Incident
Manager
Manager
Incident
Manager
Incident

9.0

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
Caller /

4.3 Acquire
Additional
Information
Functional
Analyst/ /Functional

3.0 4.1 Perform Initial

Yes 1.0
Diagnosis
Analyst
2+Analyst
DeskAnalyst

4.2 Search
Tier2+

4.4 4.6 Update Incident

Knowledge Base, More 4.5
Incident Details linking to Known 5.0
Group––Tier

Known Error Information No No Recurring No Error, Knowledge Article,

Resolution
Database and Required? Incident?
Possible? Change as required
Change Schedule
ServiceDesk
Group

Yes Yes
Service

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
Analyst
DeskAnalyst

5.1 5.3 Assign

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

No

8.0 5.2 Dispatch to

Service

6.0
Vendor and
Monitor Incident

9.0
Provider
PartyProvider
Vendor/ /33rdrd

Vendor
Diagnosis
7.0
and Incident
Vendor

Resolution If
Party

Possible

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
Customer
Customer
Caller/ /

5.0 6.3 Contact

Caller

Requestor for
Additional
Information if
required and
update Activity
Analyst
2+Analyst

Log
6.2
5.0 Update Incident
and Assign to
Service Desk for Yes
Tier2+

Re-Diagnosis and
Re-assignment
Group––Tier

Functional 7.0
No
No Escalation?
FunctionalGroup

6.1 Perform Initial Yes

Accept
Incident Review
Incident? 6.4 Tier 3
and Diagnosis
Functional Diagnosis
Functional

Escalation to Tier and Incident

3 Resolution

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
Desk

7.4 Service Desk

ServiceDesk

4.0 Analyst Contact

Analyst
Analyst

Functional Group
8.0
or Vendor for
Service

Additional
7.2 Work to Resolution Details
Problem Management
7.1 Communicate Resolve Incident if Required
Process - Document Known
Workaround if Updating Incident No
Error or Workaround (if
5.0 Appropriate with Necessary
applicable)
Details
2+
Tier2+
Group––Tier

6.0
Analyst

Resolution
FunctionalGroup
Analyst

Incident Yes
requires Change No
Resolved?
Request?

7.3 Update
Functional

Yes
Incident
Change Resolution Details
Management and Assign to
Process Service Desk

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
Customer
Customer
Caller/ /
Caller

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

8.1 No
Analyst

Validate Incident
DeskAnalyst

Resolution with
Caller / Customer
7.0 8.2 Update
5.0
Incident for Re-
ServiceDesk

Diagnosis
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
Manager
Incident
Manager
Incident

3.0 9.1 Validates

Major Incident 9.4 Prepare Major Incident
documentation as defined 8.0
& Perform Post Resolution
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