Service Modernization
IM 3.0 P1/P2 Incident Process
Document Review
1.0
02/18/15
Version
Effective Date
02/18/15
Last Revised
Annual Review October 2
CRQ
Ad-Hoc Review Paula Pacitto
Change
Document Owner
Prepared by
Darren Undershultz
Andrew SJ Mah
Name
Name
Director, ICT Processes
Business Analyst
Role
Role
http://imtdocs.alberta.ca/operations/585.aspx
Document Location
Document Sensitivity Unrestricted
C000004
Document Number
Document Last Modifies
Date
Name
Notes
Page #
Purpose:
The purpose of this document is to define the process and tasks associated with the classification
and management of Priority 1-2 Incidents in the GOA domain. The goal is to minimize the
adverse impact on business operations and ensure prompt communication to clients and
infrastructure support teams.
Scope:
Priority 1-2 Incidents managed in the GOA domain.
Page 1 of 17
IM 3.0 P1P2 Incident Process
Service Modernization
Out-of-Scope:
Scope does not include Priority 3-4 Incidents.
Scope does not include Expedite, or Escalate requests.
Scope does not include any associated Change Management or Problem Management processes.
Exceptions:
Where the process limits the ability to complete the required work, exceptions will be applied.
Document the need to deviate from the process and the action that was taken to facilitate those
needs. Consideration for Continuous Service Improvement (CSI) on process will be done during
regular review cycles.
Page 2 of 17
IM 3.0 P1P2 Incident Process
Enterprise Services
Process Key:
Subprocess (IN) – Child process that performs work to return a value.
Subprocess(OUT) – Outcome of work provided to initiate the current process in use.
Process – Work being perform. Involves steps and actions taken place.
Decision Box – Indicates a question, often a branch in the flow chart that contains yes or no. Can also be used to
depict several outcomes.
Flow Line – An arrow that connects objects based on the direction indicated by the arrow.
On page connector – A connector used to show a jump from one point to another point on the page. Usually
labeled with alpha letters in caps.
Terminal Point (Trigger) – Initiates a trigger action that sets the process in motion.
Terminal Point (End) – Initiates an end to the process where no work is being performed.
Page 3 of 17
IM 3.0 P1P2 Incident Process
Enterprise Services
Process Map:
P1/P2 Incident Ticket Process
Assigned Service
Service Desk
Provider Support Team
December 17, 2013
Incident
Creation
Process
PIP 3.1
Sign Off
Required by
Team Lead
Incident
Creation
Process
PIP 3.2
Validate P1/P2
CIM Managed
Outside Operational
Hours
No
Corporate Incident Management
Yes
PIP 3.12
Investigation
Occurs
A
PIP 3.20
Workaround?
No
PIP 3.6
Notified Via
ITSM & Page
Yes
PIP 3.21
Continue Efforts
to Resolve
PIP 3.22
Resolve Incident
No
B
Yes
Service Provider
Incident Manager
PIP 3.3
Misroute?
ITSM
Automation
PIP 3.6
Notified Via
ITSM & Page
D
No
PIP 3.4
Misroute
Ticket Process
(Warm HandOff)
PIP 3.5
Confirm
Priority on Not
Misrouted
PIP 3.14
Inform of Ticket
Status
Concurrent
Activity
Concurrent
Activity
Yes
PIP 3.16
Major Incident
Communication
PIP 3.7
Reprioritize
PIP 3.15
P1/P2 Client
Facing?
yes
PIP 3.16
Major Incident
Communication
no
E
PIP 3.9
Informed &
Confirmed of
P1/P2
PIP 3.6
Notified Via
ITSM & Page
Page 4 of 17
PIP 3.8
Major Incident?
(P1/P2)
E
No
PIP 3.10
Agree?
No
Incident
Lifecycle
Process
Yes
D
Yes
PIP 3.11
Manage Service
Provider Team
Resources
PIP 3.17
Conference
Call Required?
A
B
yes
yes
PIP 3.18
Facilitate
Conference Call
no
PIP 3.13
Provide Update
Status
no
PIP 3.19
Incident
Resolved?
IM 3.0 P1P2 Incident Process
PIP 3.23
Was Client
Facing
Previously
Initiated?
yes
Incident
Lifecycle
Process
No
PIP 3.16
Major Incident
Communication
Service Modernization
Business Rules:









All Priority 1-2 Incidents follow the same process throughout the Incident Lifecycle.
The Corporate Incident Management (CIM) team and affected Service Provider Incident
Manager will be engaged upon any Priority 1-2 Incident within 15 minutes of notification
of the Incident.
Priority 1 Incidents will be managed 24/7 until resolution.
Priority 2 Incidents reported off-prime will begin at 8:15am on the following business
day and will be managed 24/7 until resolution.
Priority 2 Incidents that are reported during prime time will be continued in off-prime
hours until at minimum; a suitable workaround is in place at client’s request.
All Priority 1-2 Incidents will have a Post Review managed by CIM.
All communication must be approved by designated Executive Director.
CIM retains the right to designate any Incident as P1/P2 at their discretion.
Service Provider Support Teams are responsible to make a work log entry each time work
is performed as well as validate status and priority is correct each time work is
performed.
Terms of Reference:




Priority 1 (Critical) Incident: Critical system, key application failure, or imminent
outage that causes total loss of production service. The outage is critical to business and
will significantly impact a single ministry or moderately impact multiple ministries.
These tickets are managed 24/7 and support teams are to contribute continually as needed
until resolution is met.
Priority 2 (High) Incident: Degradation of service on key components of the business
that may have a negative impact on the ability to meet Service Level commitments.
Moderate impact to a single ministry or significantly impacts functions of a ministry.
Depending on business justification, impact on a single user may also be a Priority 1 or 2
if there is no reasonable alternate solution available (workaround). Any Priority 2 tickets
reported outside of prime will be addressed next business day. Any Priority 2 tickets
being worked on before end of day should be continued to be worked on to resolution
when on call teams are available at client’s request.
Prime Hours: These are GOA business operating hours, and are 8:15 am to 4:30 pm
weekdays, excluding holidays.
Off-Prime Hours: These are all times that are not currently included in Prime Hours.
Support for these hours is typically handled by on-call personnel.
Page 5 of 17
IM 3.0 P1P2 Incident Process
Service Modernization
Activities:
Table 1: P1/P2 Incident Process Activity Matrix
Activity
Inputs
Description
Outputs
PIP 3.1
Incident Creation
Process.
The Service Desk verifies with
Team Lead for approval of a
P1/P2 prior to assigning the
ticket to the support team.
Approval confirmed by
Team Lead.
Sign Off
Required by
Team Lead
*Off-Prime Hours – CIM
provides lead support for
approval of P1/P2*
PIP 3.2
Validate P1/P2
P1/P2 is
confirmed by
Lead.
Decision Point:
If yes, a P1/P2 process is
initiated.
If Urgency and Impact levels
are set to trigger a P1/P2, the
support teams will determine if
the Incident meets the P1/P2
Priority criteria.
If no, validate if it’s a
misroute.
If YES: Move to PIP 3.9
If NO: Move to PIP 3.3
PIP 3.3
Misroute?
Validated for
misroute.
Decision Point:
Check if the P1/P2 was
actually misrouted.
If yes, the misroute ticket
process is initiated.
If no, inform CIM of the
ticket priority.
If YES: Move to PIP 3.4
Misroute Ticket Process.
If NO: Move to PIP 3.5
PIP 3.4
Misroute Ticket
Process (Warm
Hand-Off)
Page 6 of 17
Informed by
Service Desk or
Support Team.
CIM is notified via telephone
and an email notification in the
Misroute Ticket Process
whenever it is a P1/P2 (or
where incorrectly marked &
should be P1or P2).
CIM is notified of P1/P2
misroute.
IM 3.0 P1P2 Incident Process
Service Modernization
Activity
Inputs
Description
Outputs
PIP 3.5
Service Desk or
Support Team
validated the
appropriate
priority.
Decision Point:
Yes, go to Confirm
Prioritization
Confirm Priority
on Not
Misrouted
CIM is notified by the Service
Desk or Support Teams of the
validated priority.
CIM confirms if priority needs
to be changed.
No, continue to same
priority & allocate resources
to work on ticket.
If YES: Move to PIP 3.7
If NO: Move to PIP 3.11
PIP 3.7
Confirm
Prioritization
PIP 3.8
Major Incident?
(P1/P2)
PIP 3.6
Automated
Notification Via
ITSM & Page
PIP 3.9
Informed &
Confirmed of
P1/P2
PIP 3.10
Agree?
Page 7 of 17
CIM is notified of
priority or any
changes needed on
accepted ticket.
Ensure appropriate
prioritization is in place.
CIM approved priority.
CIM approved
priority.
Decision Point:
If yes, resume P1/P2
Incident Process.
Disagreement on
P1/P2
prioritization by
assigned IM
Is the ticket still a major
incident?
If no, return to Standard
Incident Lifecycle.
If YES: Move to PIP 3.11
If NO: Standard Incident
Lifecycle Process
Incident Creation
Process.
CIM, support teams and
assigned groups are notified
and paged by HIPLINK that a
P1/P2 has been created by
either the assigned support
group or Service Desk. An
automated ITSM email
notification is also sent.
Page has been received and
CIM to relay a
communication to all IT
support teams.
New P1/P2
Incident initiated
and a page has
been issued.
Service Provider Incident
Manager is informed of a
P1/P2 and initiates the
appropriate procedures for
hand off to support teams.
Informed and engaged on
the P1/P2.
Informed and
engaged on the
Decision Point:
If yes, IM manages support
teams resources.
Confirms priority and if it
IM 3.0 P1P2 Incident Process
Service Modernization
Activity
Inputs
Description
Outputs
P1/P2.
needs to change.
If no, inform CIM of non
P1/P2.
If YES: Move to PIP 3.11
If NO: Move to PIP 3.8
PIP 3.11
Manage Service
Provider Team
Resources
PIP 3.12
Investigation
Occurs
Agreement on
P1/P2
The Incident Manager will
delegate/triage and ensure that
the appropriate resources are
provided for the Support
Teams to troubleshoot the
issue successfully.
Appropriate resources are
assigned and approved.
The Support Team
investigates, & may engage
other teams in functional
escalation as needed. The
focus is to provide either
workaround or full resolution
of the P1/P2 issue.
P1/P2 issue is worked on.
P1/P2 issue is
worked on.
The Support Teams provide a
status update to the Incident
Manager on the progress of the
issue.
Update status received.
Update status
received.
CIM is updated on the status
of the P1/P2 by the Incident
Manager ensuring that the
problem continues to be
worked on and resolved.
Informed of P1/P2 status
update.
Informed of P1/P2
status update.
Decision Point:
If yes, proceed to relay
major incident
communication.
IM manages
support teams
resources.
Appropriate
resources are
assigned and
approved.
No Workaround
confirmed
PIP 3.13
Provide Update
Status
PIP 3.14
Inform of Ticket
Status
PIP 3.15
P1/P2 Client
Facing?
Corporate Incident
Management will determine if
P1/P2 Incident will have a
Client Facing impact.
If YES: Move to PIP 3.16
If no, a conference call is
required.
If NO: Move to PIP 3.17
PIP 3.16
Major Incident
Communication
Page 8 of 17
Communication
with SDM.
Communication
with CIM
Manager.
CIM will manage
communication to Ministries
based on an email template for
Incident Communications.
(Communication is a
concurrent activity.)
Major Communication
Process initiated following
the progress and status of the
P1 P2 lifecycle.
IM 3.0 P1P2 Incident Process
Service Modernization
Activity
Inputs
Description
Outputs
Refer to Sub-Process details,
and continue with concurrent
P1/P2 process.
PIP 3.17
Conference Call
Required?
Management of
Support Team(s)
troubleshooting
Incident.
Decision Point:
CIM and Service Provider
Incident Manager will
determine if a conference call
is required to aid in
management of Incident. If a
conference call is needed, one
will be setup within 15
minutes of major incident
identification.
Decision regarding need for
Conference Call.
(functional escalation FEP 3.3
Sub Process Inter-Team
Consult activity)
If YES: Move to PIP 3.18
If NO: Move to PIP 3.19
PIP 3.18
Facilitate
Conference Call
PIP 3.19
Incident
Resolved?
Conference Call
decision reached.
CIM will conduct a conference
call with all supporting Service
Providers and Service Provider
Incident Managers to better
understand issue and provide
guidance to support teams on
what is required in order to
resolve the incident.
P1/P2 Conference Call.
P1/P2 Conference
Call.
Decision Point:
Resolved Incident.
Service Provider Incident
Managers will determine if
Incident has been resolved.
Unresolved Incident.
Updated work log.
If YES: Move to PIP 3.21
If NO: Move to PIP 3.20
PIP 3.20
Workaround
provided?
Unresolved
Incident.
Decision Point:
Was a workaround established
that meets business
requirements?
If yes, continue efforts for
resolve.
If no, resume investigation.
If YES: Move to PIP 3.21
If NO: Move to PIP 3.12
Page 9 of 17
IM 3.0 P1P2 Incident Process
Service Modernization
Activity
Inputs
Description
Outputs
PIP 3.21
Workaround
provided.
Assigned Support Team will
continue to provide continuous
efforts to resolve the incident
with workaround in place.
Efforts to continue resolve.
Resolved Incident.
Assigned Support Team will
resolve the incident once
required resolution details
have been updated in the
P1/P2 ticket & it has been
confirmed by the client.
Update ticket status.
Continue Efforts
to Resolve
PIP 3.22
Resolve Incident
*Where a Master Ticket is
resolved, the resolution details
are written for the audience
who will receive ITSM
resolution notification emails.
PIP 3.23
Was Client
Facing
Previously
Initiated?
Update ticket
status.
Decision Point:
If yes, end the process.
Was client facing initiated
previously by CIM.
If no, go to major incident
communication process.
If YES: End the process
If NO: Go to Major Incident
Communication process
Page 10 of 17
IM 3.0 P1P2 Incident Process
Service Modernization
Sub-Process Map:
PIP 1.4 Sub-Process: Major Incident Communication
Executive Director
Service Provider
Incident
Corporate Incident Management
Manager
December 17, 2013
Yes
MIC 3.16.1
Front End
Message
Required?
P1/P2
Incident
Process
Yes
MIC 3.16.2
Inform SD to
Create Front
End Message
MIC 3.16.1
Front End
Message
Required?
MIC 3.16.2
Inform SD to
Create Front
End Message
Yes
MIC 3.16.5
Create Template
Communication
MIC 3.16.11
Issue
Resolved?
MIC 3.16.9
Send
Communication
No
No
MIC 3.16.4
Provide
Information
MIC 3.16.8
Resolved or
Workaround in
Approval
Interim?
Yes
Yes
MIC 3.16.7
Communication
Required?
MIC 3.16.13
Inform SD of
Resolve Not
Communicated
MIC 3.16.14
Issue Resolution
Communication
MIC 3.16.10
Inform SD
Update Front
End Message
No
MIC 3.16.3
Sufficient
Information
Available?
No
No
MIC 3.16.6
Approve
Communication
?
Yes
No
MIC 3.16.12
Monitor for
Updates from
Assigned IM/
Workaround
No
Yes
MIC 3.16.6
Approve
Communication
?
Yes
No
P1/P2
Incident
Process
Page 11 of 17
IM 3.0 P1P2 Incident Process
MIC 3.16.15
Update SD to
Remove Front
End Message
P1/P2
Incident
Process
Service Modernization
Sub-Process Activities:
Table 2: PIP 3.4 Sub-Process Activity Matrix
Activity
Inputs
Description
Outputs
MIC 3.16.1
CIM determines
communication
for P1/P2
necessary
Decision Point:
Yes, SD will create a front
end message
Front End
Message
Required?
CIM will determine if a front
end message is required to
inform clients of a P1/P2
incident.
No, Determine sufficient
information.
IF YES: Move to MIC 3.16.2
IF NO: Move MIC 3.16.3
MIC 3.16.2
Inform SD to
Create Front End
Message
MIC 3.16.3
Sufficient
Information
Available?
CIM notifies
Service Desk for
a front end
message.
CIM approves front end
message.
Phone message has been
created.
Phone message
has been created
and updated on
the portal.
Decision Point:
If yes, information regarding
extent of Incident.
CIM will determine if there is
sufficient information
available to begin creating
Incident Communication.
If no, information required
regarding extent of Incident.
If YES: Move to PIP 3.16.5
If NO: Move to PIP 3.16.4
MIC 3.16.4
Provide
Information
MIC 3.16.5
Create Template
Communication
MIC 3.16.6
Approve
Communication?
Information
required
regarding extent
of Incident.
Service Provider Incident
Manager(s) will provide CIM
all available information
regarding current issue noting
if any workaround is known.
Information regarding extent
of Incident.
Information
regarding extent
of Incident.
CIM will issue an email
communication based on the
Incident Communication
process to Ministry IT
Contacts.
Draft Communication is
formed for intended
audience for approval.
Information
regarding extent
of Incident.
Decision Point:
Communication approved.
Based on information
provided, designated
approvers will determine if
communication is acceptable
for distribution to Ministry.
Communication not
approved.
Communication
is sent
widespread for
Page 12 of 17
IM 3.0 P1P2 Incident Process
Service Modernization
Activity
Inputs
Description
the Ministry.
If YES: Move to PIP 3.16.8
Outputs
If NO: Move to PIP 3.16.7
MIC 3.16.7
Communication
Required?
Communication
not approved.
Decision Point:
CIM and the Service Provider
Incident Manager will
determine if a communication
is required at this point.
If yes, relay to CIM for
additional details.
If no, return to P1/P2
Incident Process.
If YES: Move to PIP 3.16.3
If NO: Return to P1/P2
Incident Process
MIC 3.16.8
Resolved or
Workaround in
Approval
Interim?
Communication
approved.
Decision Point:
Was the Incident resolved or a
workaround confirmed during
the interim period of approval?
If YES: Move to PIP 3.16.13
If yes, message is sent to
approver for approval of
update communication.
If no, CIM sends
communication.
If NO: Move to PIP 3.16.9
MIC 3.16.9
Send
Communication
MIC 3.16.10
Inform SD
Update Front End
Message
MIC 3.16.11
Issue Resolved?
Unresolved
Incident.
CIM sends approved
communication as issue has
not been resolved.
Communication has been
sent.
Update required
for existing front
end message.
CIM will inform Service Desk
to update the existing front end
message with the updated
approved message.
Front end message updated.
Updated Front
End Message
Decision Point:
Resolved Incident.
CIM will be notified if the
issue has been resolved.
Unresolved Incident.
Updates from
assigned Incident
Manager.
If YES: Move to PIP 3.16.6
If NO: Move to PIP 3.16.12
MIC 3.16.12
Monitor for
Updates from
Assigned
Page 13 of 17
Issue not
Resolved.
CIM will monitor for updates
from assigned Incident
Manager and convey update to
Ministry until the issue is
Communication Update
approval.
IM 3.0 P1P2 Incident Process
Service Modernization
Activity
Inputs
Incident
Manager/
Workaround
MIC 3.16.13
Inform Service
Desk of
Unresolved
Incident
MIC 3.16.14
Issue Resolution
Communication
MIC 3.16.15
Update Service
Desk to Remove
Front End
Message
Description
Outputs
resolved.
Unresolved
Incident.
CIM informs Service Desk
that the issue has not been
resolved
Service Desk informed
Approved
Communication.
CIM sends resolution
communication.
Communication sent to
Ministry IT Contacts.
Service Desk
informed of
communication
update.
CIM will contact Service Desk
to remove the Front End
Message
Phone message removal
Roles and Responsibilities:
Table 2: P1/P2 Incident Process RACI Matrix
P1/P2 Incident Process RACI Matrix
R = Responsible, A = Accountable, C = Consulted, I = Informed
Page 14 of 17
IM 3.0 P1P2 Incident Process
Page 15 of 17
Affected Service Provider
Manager
Designated Executive
Director
Service Delivery Manager
Corporate Incident
Management
Service Provider Support
Team Incident Manager
Assigned Service Provider
Support Team
Client
Activity
PIP 3.1 Sign Off Required by Team Lead?
PIP 3.2 Validate P1/P2
PIP 3.3 Misroute?
PIP 3.4 Misroute Ticket Process (Warm HandOff)
PIP 3.5 Inform Not P1/P2
PIP 3.6 Notified Via ITSM & Page
MIC 3.16.1 Front End Message Required?
MIC 3.16.2 Inform SD to Create Phone Message
& Portal
MIC 3.16.3 Sufficient Information Available?
MIC 3.16.4 Provide Information
MIC 3.16.5 Create Template Communication
MIC 3.16.6 Approve Communication?
MIC 3.16.7 Communication Required?
MIC 3.16.8 Resolved or Workaround in
Approval Interim?
MIC 3.16.9 Send Communication
MIC 3.16.10 Inform SD Update Front End
Message
MIC 3.16.11 Issue Resolved?
MIC 3.16.12 Monitor for Updates from
Assigned IM/Workaround
MIC 3.16.13 Inform SD of Resolve Not
Communicated
MIC 3.16.14 Issue Resolution Communication
MIC 3.16.15 Update SD to Remove Phone
Message & Portal
PIP 3.7 Agree?
PIP 3.8 Reprioritize
PIP 3.9 Informed & Confirmed of P1/P2
PIP 3.10 Agree?
PIP 3.11 Manage Service Provider Team
Resources
PIP 3.12 Investigation Occurs
PIP 3.13 Provide Update Status
PIP 3.14 Inform of Ticket Status
PIP 3.15 P1/P2 Client Facing?
Service Desk
Service Modernization
R,A
R
R
I
R,A
R,A
R,A
R,A
I
I
C
R,A
I
I
I
I
I
R,I
R,A
I
I
I
R,A
R,A
C
I
I
I,C
R,A
R,A
I
R,A
R,A
R,A
I
I
I
I
I
I
I
I
R,A
I
I
I
I
R,A
R,A
I
I
I
I
I
I
R,A
I
I
I
I
R,A
R,A
R,A
R,A
C
C
R,A
R,A
R,A
R,A
R,A
R,A
I
I
I
R,A
IM 3.0 P1P2 Incident Process
Service Modernization
PIP 3.16 Major Incident Communication
PIP 3.17 Conference Call Required?
PIP 3.18 Facilitate Conference Call
PIP 3.19 Incident Resolved?
PIP 3.20 Workaround?
PIP 3.21 Continue Efforts to Resolve
PIP 3.22 Resolve Incident
PIP 3.23 Was Client Facing Previously Initiated?
I
I
I
C
R,A
R,A
R,A
R,A
I
R,A
R,A
R,A
I
I
I
I
R,A
Measurements:
Every Process will have a balanced set of measurements (Key Performance Indicators) against
which its performance can be tracked, communicated and improved. As the process matures,
the KPI’s and review cycle may be modified based on the Process Owner’s discretion. The
tables below identify the KPI/report and the measurement criteria.
Table 3: P1/P2 Incident Process Measurements
X
X
X
X
Yearly
Every 6 Months
Every 3 Months
Monthly
Weekly
KPI/Report
Average time to resolve Priority 1-2 Incidents
Number of Breeched Priority 1 Incidents
Number of Breeched Priority 2 Incidents
Number of P1/P2 with Communication(s)
Report and Review Cycle
Daily
P1/P2 Incident Process
X
X
X
X
Document Review:
The document will follow the Review schedule below:
Annual Review: The document shall be reviewed for completeness and accuracy every October
2nd. The Document Owner is accountable for performing an annual Document Review.
Ad-hoc Review: Ad-Hoc requests for document revision should be directed to the Document
Owner and submitted using the Change Management Process and supporting systems. The
Document Owner is accountable for managing the ad-hoc document revisions.
Associated Documents:

Incident Creation Process
Page 16 of 17
IM 3.0 P1P2 Incident Process
Service Modernization



Misroute Ticket Process
Major Incident Communication
Incident Lifecycle Process
Page 17 of 17
IM 3.0 P1P2 Incident Process