Change Management Process

Change Management Process

Version 1.0

1
Change Management Process

Table of Contents
1 About This Document ......................................................................................................................... 3
1.1 Document Objective .................................................................................................................. 3
1.2 Process Objectives.................................................................................................................... 3
2 Change Request Lifecycle Stages ..................................................................................................... 4
3 Change Request (CR) Requirements ................................................................................................ 4
4 Approval Requirements ...................................................................................................................... 5
5 Change Board (CB) Requirements .................................................................................................... 5
6 Work Info Entry Definitions ................................................................................................................. 5
6.1 Risk Assessment: ...................................................................................................................... 5
6.2 Service Impact Assessment: ..................................................................................................... 6
6.3 Install Plan: ................................................................................................................................ 6
6.4 Backout Plan: ............................................................................................................................ 7
6.5 Test Plan: .................................................................................................................................. 7
6.6 Communication Plan: ................................................................................................................ 7
6.7 Approvals: ................................................................................................................................. 8
6.8 Install Results – Details ............................................................................................................. 8
6.9 Test Results – Details ............................................................................................................... 8
6.10 Post Implementation Review (PIR) ........................................................................................... 9
7 Inquiries ............................................................................................................................................ 10
8 Definitions and Acronyms ................................................................................................................ 10
9 Reference ......................................................................................................................................... 13

Revision History
Author Version Description Date
Ken Merkel 1.0 Document Creation August 13, 2015
Sandy Stout
Gemma Tungul
Ken Merkel 1.0 Document August 31, 2015
Sandy Stout Publication
Gemma Tungul
Caroline Schulte
Sandy Stout 1.1 Document review Feb. 4, 2016
and update of links.

2
Change Management Process

Sandy Stout 1.2 Update of May 4, 2016

Definitions and
Acronyms
Sandy Stout 1.3 Document Review
and Update Oct. 26, 2017

1 About This Document

1.1 Document Objective

The Change Management Process document provides guidelines in order to conduct a change
according to the Service Alberta Change Management process.

This document applies to the changes that are managed under the Government of Alberta (GoA)
Change Management control.

1.2 Process Objectives

The primary objective of the Change Management process is to enable beneficial changes to be
made, with minimum disruption to IT services.

The Change Management process has several other objectives:

 To standardize Requests for Change (RFC), and formalize their handling.

 To investigate the impact and risk of the change to the existing infrastructure or processes,
and assess the appropriateness of the change.
 To obtain authorization for the change by the appropriate approver(s).
 To schedule the implementation of the change into production.
 To coordinate multiple changes across the GOA service providers and customers

3
Change Management Process

2 Change Request Lifecycle Stages

These are the 5 Change Request Stages/Phases:

Initiate – A Request for Change (RFC) is initiated and populated by Change Coordinator/Change
Implementer. Initial classification and impact/risk assessments are performed and the ticket is
populated with the required information.

Review & Authorize – The Change Manager reviews the change for completeness, confirms the
impact of the change and identifies the appropriate approvers for the change.

Plan & Schedule – The Change Manager approves and submits the change to the appropriate
approvers ((optional) Change Board, Service Owner. If communication is required, the Change
Manager requests the communication to be distributed. The change is then scheduled for
implementation.

Implement – The Change Implementers perform and record the required tasks and activities to
implement the Change.

Closed – The Change Manager will perform a Post-Implementation Review to determine if the
Change met its objectives. The change is then closed.

3 Change Request (CR) Requirements

In order to conduct a change, the following work info entries must be entered into a Change Request
(CR).

These are required prior to CR implementation:

1. Risk Assessment
2. Service Impact Assessment
3. Install Plan
4. Backout Plan
5. Test Plan
6. Communication Plan

These are required after CR implementation

7. Install Results – Details

8. Test Results - Details
9. Post Implementation Review (PIR)

4
Change Management Process

4 Approval Requirements
Approvals are required within the CR Lifecycle.

5 Change Board (CB) Requirements

Change Board Requirements must adhere to the Change Board classification and follow the
appropriate lead time.

Change Board Review is required on all changes that falls under the following guidelines:

 All outages longer than 10 minutes (Operational Change Board).

 All changes visible to the end users (Business Change Board).

6 Work Info Entry Definitions

6.1 Risk Assessment:

Risk Assessment is the risks to the service during the change implementation and the risks
to the service should the change not be implemented.

The risk assessment may include:

1. What is the risk level assessment (Low, Medium, or High)?

2. Have you done this before successfully?
3. Can you test before and after implementation?
4. Risk of not doing the change (optional).

Examples:
 Risk is assessed as low. This is a repeatable process done many times before
and has been tested in UAT.
 Risk is assessed as low. Switch and router reloads are usually uneventful with
the device coming back online within 5 minutes. There is always a chance
(though very remote) that a device will fail it’s reload and not come back online.
In such a case a new switch or router would be provisioned during the block time.
 The risk of this change is low as the changes of similar type has been completed
on other parts of the network and implemented as planned. The risk of not doing
the change is that the current infrastructure is aged and does not meet security
requirements. This could lead to vulnerabilities that may be exploited to
compromise our network.

5
Change Management Process

6.2 Service Impact Assessment:

Service Impact Assessment is the impact of the change to end user during and after the
change.

The Service Impact Assessment should include:

1. How does this impact users of the service during the change?
a. Is there an outage?
b. How long is the outage?
(Change Board review is required for all outages longer than 10 minutes).
c. What time is the outage?
2. Will this impact the users after the change,
a. Will there be a visible change to end users?
(Change Board review is required for all changes visible to the end users).
b. Will they have to do something different?
3. What Ministries are affected by this change (change board requirement only).
(Change Board review is required if more than one ministry is affected).

Examples:
 No service impact & no outage are expected during the change window. This
change will be implemented seamlessly as there are 2 devices are serving
user traffic simultaneously and there is no need for reboot.
 During this change, email and file services will be unavailable. Outage should
only be 15 minutes at the start of the change although I have scheduled the
entire hour in case more time is required. Ministries affected are: Service
Alberta, Energy.
 The switch will be replaced during the lunch with Ministry approval to be
attached to this ticket. While connections are moved from the old to the new
switch, workstations and printers will not have network access throughout the
entire building. This change will affect the Ministry of Service Alberta.

6.3 Install Plan:

Install Plan is the detailed description of the installation. The install plan should be detailed
enough so that another team member can complete the change.

Examples:
 1-Rack new router; 2-power up the router: 3-Move cables from the old to the
new router; 4-check network connectivity
 Alter Channel CLIENT.TO.QNA3 parameter HBINT from 50 to 300 using ISPF
interface. Change QNA3.PARMLIB(QNA3SGCO) member HBINT parameter
from 50 to 300 for channel CLIENT.TO.QNA3 definition

6
Change Management Process

6.4 Backout Plan:

Backout Plan is the detailed description of the backout. The backout plan should be detailed
enough so that another team member can complete the backout.
If a backout plan is not required, describe the reason why.

Example:
 Old router can be reconnected within 1 hour. 1-Rack old router back; 2-power
up the old router: 3-Move cables from the new to the old router; 4-check network
connectivity

6.5 Test Plan:

Test Plan is the detailed description of the test. The test plan should be detailed enough so
that another team member can complete the test.

The test plan should include:

1. What is the pre-testing plan? (if no pre-testing can be done explain why)
2. If applicable, detailed information on what pre-testing was done and the outcome
3. What is the post-testing plan?

Example:
 After the migration, logon to the SPIN2 prod database servers and verify they are
working fine.

6.6 Communication Plan:

Communication Plan should include detailed information on what communication is required
and to who it is going to. If no communication is required enter “no communication required”
and explain why.

The communication plan should include:

1. Communication Email
2. Communication Distribution Checklist
3. Communication Approval (email)

Communication information and templates can be found at:

https://sharedservices.gov.ab.ca/SM/COMM/default.aspx

7
Change Management Process

6.7 Approvals:
The following approvals are required within the lifecycle of a change.

1. Review – CR Requirement Completion Approval – Approver: Change Manager

2. Business – Implementation Approval – Approver: (One or more of the following) Service

Owner/Ministry/Change Board
a. Service Owner approval is required for all changes prior to implementation.
b. Service Owner or an alternate Change Approving authority is required for all
Emergency and Latent changes. Alternate change approving authorities are as
follows: Service Owner or Team Director/Manager or Team Lead
c. Ministry approval is required for all changes that impacts one ministry only.
d. Change Board approval is required for all changes prior to implementation
according to predefined Change Board Classification
3. Close Down – PIR Completion – Approver: Change Manager

6.8 Install Results – Details

Install Results is the detailed description of the success of the change.

The install results should include:

1. Information on whether the change was successful or unsuccessful (e.g. Change was
successful and completed in the scheduled time frame).
2. Information on what post testing was done and the outcome.

Examples:
 Change was Successful; Change was implemented within the allowed time
without any incidents. Communication task were successfully completed. Testing
Plan was successfully complete.
 Change had to be backed out by restoring previous settings. This change was
not successfully implemented. Will be recreated and scheduled at another time.

6.9 Test Results – Details

Test Results must be added to describe what post testing was completed after the change
was implemented and the outcome This work info entry should be relative to the Test Plan in
ticket.

Examples:
 Both the NetOps and ADS team have tested the console access and it is working
as required.
 Confirmed sync script finished running successfully. When ncc esm201 was
back up, confirmed events flowing to 201 again.

8
Change Management Process

6.10 Post Implementation Review (PIR)

Post Implementation Review is the final review completed by the Change Manager to ensure
change management process compliance prior to closure.

Examples:
 Post-Implementation Review Results - This Change implementation has been deemed
successful.

9
Change Management Process

7 Inquiries
Refer your inquiries to ict.change@gov.ab.ca.

8 Definitions and Acronyms

Term Definition
Change A change is the addition, modification, or removal of approved, supported or
standard hardware, network, software, environment system, or associated
documentation (collectively known as Configuration Items). The need for a
Change can arise as a result of an Incident, Problem, Known Error and its
resolution, or from proactively seeking business benefits.

Change Board All Changes are classified into one of the following two classes:
Classification
Operational changes are those changes which may impact the availability
and/or quality of IT services while the changes are being performed, but which
will not result in any visible change to customers and/or their end users once
the changes are completed. Operational changes include regular maintenance
and upgrades, expansion of the IT environment, etc.

Business changes are defined as those changes which, once implemented,

will result in a visible change in a service and its functionality to its customers
and/or end-users. Business changes may include service support process and
procedure changes, or upgrades or new releases of services which change the
features of the service and/or how it is used by customers and/or end-users.
Change Management Change Management is the process responsible for controlling the lifecycle of
all changes. The primary objective of Change Management is to enable
changes to be made, with minimum disruption to IT services.
Class Class specifies the relative urgency of the change, so that the approvers can
assess its magnitude.

Normal is the default timing for a change. Approval from the Change Manager
and the Service Owner is required.

Emergency - This type of change would be created during business hours and
would follow the normal change management process by requiring all the work
info entries to be added in the ticket, but, communication and Change Board
requirements do not apply. Change Management approval and Service Owner
approval is required prior to implementation.

Latent - This type of change could be completed during business hours or

outside of business hours and is only used when, due to the urgency of the
situation, the change needs to be implemented immediately. A ticket must be
created after the change has been implemented, and approval from the Service

10
Change Management Process

Term Definition
Owner or an alternate change approver must be attached to the ticket.
Required work info entries must include an entry identifying what was done and
why, and an “Install Results” entry prior to the ticket being moved forward for
final review.

No Impact: Pre-approved by BCB and listed in the Standard Change

Sharepoint site
Customer The recipient of a service. In this environment, the ministries of the Government
of Alberta are the customers.
End-user or user The person who uses the services on a day-to-day basis. In classifying
Changes as operational or business changes, service provider users who are
involved in the delivery of the service are not considered users of that service,
although they are affected by the quality and availability of those services.
Impact Means the known or anticipated effect of a Change to service availability,
service quality, business continuity, etc. Typically this will relate to the number
and type of users affected by the Change being proposed. It is often equal to
the extent of a distortion of agreed or expected service levels. Impact can be:

Minor/Localized: The Change will have little or no effect to end users during
working hours, but may require the service to be unavailable for less than 10
minutes during non-working hours.

Moderate/Limited: The Change may affect a moderate number of users,

probably limited to a single branch or large user group and may require the
service to be unavailable for longer than 10 minutes or have a visible change to
end users.

Significant/Large: The Change may affect a single Ministry or several

branches across multiple Ministries and may require the service to be
unavailable for longer than 10 minutes or have a visible change to end users.

Extensive/Widespread: The Change affects multiple Ministries and may

require the service to be unavailable for longer than 10 minutes or have a
visible change to end users.
Lead Time Implementation Lead Time is the recommended amount of time the
submission of a Change Request and the earliest time that the proposed
Change implementation should begin.

The following are the implementation Change Board lead times required by
Service Alberta Change Management:
Minimum Lead Description
Time
7 business days - Must be submitted no later than Monday,
4:30pm in order for the change to appear on
the Wednesday Change Board Agenda.
- In case of holidays (ie. Holiday Monday)

11
Change Management Process

Term Definition
preference would be to have the CR ready by
Friday, 4:30pm BUT CRs will be accepted until
Tuesday at noon.
- Additional 5 days for Communication
Distribution
Priority Priority is an indicator of the relative importance of a change. It is used to
determine the sequence in which a change needs to be resolved, and therefore
the speed at which the resolution will be approved and deployed. It is based
primarily on the Impact and Urgency, although the business risk of not
implementing the change is another important criterion for determining the
priority of a change. Priority can be:

Low: A Change that impacts few users, and can be implemented in the long-
term

Medium: A Change that impacts a moderate number of users, and can be

implemented in the medium-term

High: A Change that impacts a significant number of users, and must be

implemented in the short term

Critical: A Change that impacts both a large number of users and must be
implemented quickly

Urgency
Priority
Critical High Medium Low
Extensive Critical Critical High High
Significant Critical High High Medium
Impact

Moderate High High Medium Low

Minor High Medium Low Low
Request for Change Form (or screen) used to record the details of a Change Request to any service
(RFC) or Change and/or Configuration Item. This includes a description of the change, the
Request affected components, the business justification, an impact and risk assessment,
resource requirements, and approval status of the change. Submission of this
form or screen is the required initial step in Change Management process.
Risk Risk assessment is concerned with analyzing threats and weaknesses that
have been or would be introduced as a result of a service change. A risk occurs
when a threat can exploit a weakness. The likelihood of threats exploiting a
weakness, and the impact if they do, are the fundamental factors in determining
risk.

Risk Level 1-2 (Low): (E.g. Routine change with proven success; minimal
impact if Change fails; no back out required or back out is simple)

Risk Level 3-4 (Medium): (E.g. High probability of success; back out is
involved but not difficult; moderate visibility potential to customers)

12
Change Management Process

Term Definition
Risk Level 5 (High): (E.g. Change is complex or high risk; implementation is
difficult; back out is lengthy and/or difficult; high visibility potential to customers.)

9 Reference
Change Management Documentation is located here.

Change Management Sharepoint site is located here.

Service Alberta Change Board Sharepoint Site (OCB/BCB) is located here.

13