Change Management

Process Guide
Version 2.1, June 2022
Table of Contents
1.0 Introduction ........................................................................................................................ 2
2.0 Principles and Basic Concepts ......................................................................................... 2
2.1 Change Management Description..................................................................................... 2
2.2 Change Management Goal ............................................................................................... 2
2.3 Change Management Objectives ...................................................................................... 2
2.4 Policies ............................................................................................................................. 3
2.5 Roles and Responsibilities ................................................................................................ 3
2.7 Change Types .................................................................................................................. 3
2.8 Change Management Priority Matrix................................................................................. 4
2.8.1 Change Process Flow Diagram .................................................................................. 5
3.0 Process and Procedure ..................................................................................................... 5
3.1 Process Overview Diagram .............................................................................................. 5
3.2 Workflow Detail................................................................................................................. 6
3.2.1 Plan the change ......................................................................................................... 6
3.2.2 Determine the Change Type ...................................................................................... 6
3.2.3 Create and submit the Change Request .................................................................... 8
3.2.4 Review the Change for Approval ................................................................................ 8
3.2.5 Implement the Change ............................................................................................... 8
3.2.6 Update and close the Change Request ...................................................................... 9
4.0 Process Governance ......................................................................................................... 9
4.1 Process Controls .............................................................................................................. 9
4.2 Measures.......................................................................................................................... 9
4.3 Key Performance Indicators (KPI’s) and Reporting ..........................................................10
4.3.1 Change Report .............................................................................................................10
4.3.2 Change Advisory Board (CAB) Report ..........................................................................10
4.3.3 Success Rate of CR’s Report .......................................................................................11
Appendix A – Glossary ...........................................................................................................12
Appendix B – Change Advisory Board ..................................................................................14

Page |1 Revision: 7/1/2022

1.0 Introduction
• Change Management definitions for process, policies, and goals. This document will
define the relationships of Change Management with other IT Service Management
processes.
• Change Management processes presented in this document defines the steps, roles and
responsibilities, timelines, and types of all changes.
• This document also describes how EasyVista (ESP) is currently supporting the WaTech
Change Management process.

2.0 Principles and Basic Concepts

2.1 Change Management Description
• Change is any addition, modification, or removal of anything that could influence an IT
service.
• Change Management is the process responsible for controlling the life cycle of all
changes to minimize the risk of disruption to IT services and communicating changes to
configuration items.
• Change Management relies heavily on related Service Management processes for
recording and communicating changes to configuration items.
2.2 Change Management Goal
The goal of Change Management is to manage the process of change and limit the introduction
of errors, while minimizing adverse impact on business operations, and ensuring the best
possible levels of service quality and availability are maintained.
2.3 Change Management Objectives
To balance the need for change against the impact of the change we must:
• Establish a common understanding for WaTech as an agency and for WaTech
customers regarding the approach to the assessment of risk, change impact, resource
requirements, and change approval.
• Provide a comprehensive picture of the organization-wide impact of change and enable
managers to make contingency plans and possible response.
• Ensure that Change Management processes receive high visibility and open channels of
communication to promote smooth transitions to support successful changes and offer
options when a change is not successful.
• Ensure standard methods are used for implementing changes and developing and
documenting reusable processes to do this.

Page |2 Revision: 7/1/2022

2.4 Policies
• All changes to IT services must follow a structured process to ensure appropriate
planning and execution.
• Use ESP for management of all changes.
• Change management must be aligned with overall service levels and objectives.
• Change management processes must be followed by all staff.
2.5 Roles and Responsibilities
The following table identifies key roles and responsibilities for managing change.

Role Responsibilities
WaTech Support • Log informational changes from customers and vendors.
Center • Ensure all fields are filled in appropriately.
Change Advisory • Review, approve and deny CHANGE REQUESTS.
Board • Lead weekly CAB meetings.
• Review, update, and communicate any changes to the Change
Management process.
• Provide coaching and guidance for teams to use and
understand the change management process.
• Ensure scheduled changes do not conflict with others.
Service Owner • Review, approve and ensure all fields are complete on the
Change Request.
• Ensure changes are communicated with impacted customers
using the Service Notification process.
• Attend weekly CAB meeting to review and discuss details of the
change.
• Ensure change will not impact other changes already
scheduled.
• Work with staff and other Service Owners to modify change
times as needed to avoid conflicting changes.
Technician • Attend weekly CAB meeting to review change if Service Owner
is not attending.
• Plan, communicate, implement, and close Request For Change.
• Ensure all fields are filled in appropriately.
• Close change ticket within three days of end date of change.

2.7 Change Types

Enterprise Solutions Platform (ESP) will be used to support change management processes.
ESP workflow will automatically route a change request to you based on your role and the type
of change request.

Page |3 Revision: 7/1/2022

 Change Type Description
• Reviewed by Change Advisory Board (CAB) based on regular process
and lead times. The Service Owner/Configuration Item Manager is
Normal responsible for determining lead time requirements. All normal change
requests have an associated service notification posted to
support.watech.wa.gov.
• Low risk, low impact, highly repeatable change with very little
Standard/Preapproved
possibility of adversely impacting the production environment.
• Provides information or notification about customer or vendor
Informational activities.
• Not used for WaTech changes.
• Not able to meet the minimum lead-time requirements for normal
change request. Service Owner/Configuration Item (CI) Manager will
Unscheduled/Urgent
approve instead of Change Advisory Board (CAB) due to time
constraints.
• Submitted after the fact.
• These are rare (exception only) changes made during a critical outage
Latent when there is insufficient time to submit an Unscheduled/Urgent
change request and the risk of making the change will not adversely
impact the current state of support service.

2.8 Change Management Priority Matrix

Complexity Impact Risk=Complexity + Impact -1
ESP automatically calculates the risk to
1 -Low – Proven
1 – Service Available determine level (1, 2, 3, 4, 5)
repeatable
1 = low and 5 = High
2 – Medium – Success
expected but limited to no
2 – Service Degraded
experience with proposed
change
3 – High – Success
expected but proposed
3- Service Unavailable
change complex or difficult
to implement

Page |4 Revision: 7/1/2022

2.8.1 Change Process Flow Diagram

3.0 Process and Procedure

3.1 Process Overview Diagram

Page |5 Revision: 7/1/2022

 Plan the Change

Determine the
Change Type

Create and Submit

the Change
Request

Review the
Change for
Approval

Implement the
Change

Update and Close

Change Request

3.2 Workflow Detail

3.2.1 Plan the change
It is expected that the technician responsible for the Change Request has conducted a proper
review with stakeholders including the Service Owner. It is expected that where possible,
changes have been tested, a fall-back plan is in place, and the fallback plan has been tested.
The total time requested for the Change Request must include the time required to fall back if
fall back is necessary. The Change Manager or reviewers can approve or reject the Change
Request based on whether enough information is provided in the request to make a proper
assessment and/or whether the changes are in line with the organization’s objectives. Rejected
Change Request are returned to the originator with an explanation for the rejection. Rejected
changes are not authorized for implementation. Rejected changes may be modified and
resubmitted for approval. It is the responsibility of the change implementer to obtain approval for
the Change Request.
3.2.2 Determine the Change Type
There are five (5) types of Change Requests:
1. Normal Change –
• Normal change requests are based on regular processes and lead times that are
determined by the service owner.
• Normal changes must have a Service Notification sent to impacted customers no
less than three (3) days before the change implementation date - seven (7) days
before implementation is preferred.
o Why: The change report is designed so customers that view it can click
on a hyperlink and view the associated service notification

Page |6 Revision: 7/1/2022

 o Technician can paste draft of notification in communications section of the
CR. If service notification is not posted before CAB approval, it should be
stated the notification is drafted and will be sent after CAB approval.
• Reviewed by Change Advisory Board (CAB) based on regular process and
lead times. The service owner is responsible for determining lead time
requirements.
o Example: A technician has determined a change needs to be made to a
system or applications. This will cause a system outage. The technician
creates a Normal change request.
2. Standard/Pre-Approved –
• Low risk, performed on several occasions, and highly repeatable with very
little possibility of adversely impacting the production environment. Also, the
Service Owner accepts the change as preapproved.
o Example: ESP application needs to be restarted
o Example: Monthly patching of servers, Customer request changes, new or
migrating circuits, etc.

3. Informational Change –
• Provides information or notification about customer or vendor activities. They
are reviewed by the service owner and change advisory board (CAB) but they do
not need to be approved.
o Example: Comcast (vendor) notifies WaTech because they have
maintenance activities planned with possible intermittent outages over the
weekend. Support Center creates an Informational change request.
o Example: Vendor contacts WaTech because they need access to State
Data Center (SDC). Support Center creates an Informational change
request.
o Example: An agency customer contacts WaTech because they have
maintenance activities planned for April 1 and they request a ‘change freeze’
(no changes). Support Center creates an informational change request. If
the agency customer contacts a technician directly, the technician creates
the change request or forwards the information to the Support Center.
4. Unscheduled/Urgent –
• Not able to meet the minimum lead time requirements for a normal change
or needs to be completed today. Service owner will approve instead of Change
Advisory Board (CAB) due to time constraints.
o Example: Server will fail unless reboot occurs. A technician creates an
Unscheduled/Urgent change request.
5. Latent –

Page |7 Revision: 7/1/2022

 • Submitted after the fact. These are rare (exception only) changes made
during a critical outage when there is insufficient time to submit an
Unscheduled/Urgent change request and the risk of making the change will not
adversely impact the current state of a support service.
o Example: Server has failed unexpectedly (it’s on fire/broken now). A
technician fixes the issue now and creates a Latent change request after the
fact.
3.2.3 Create and submit the Change Request
• All changes require an approved Change Request.
• Anyone in the organization may submit change requests. This ensures no one is
restrained from proposing changes or reporting important issues. In an emergency
break fix scenario, a latent change may be completed after the fact for the purpose of
documentation.
• All submitted Change Request will be logged and allocated an identification number
in the Change Management tool. Where a change request is submitted as a
resolution to an incident, customer service request, or problem record, it is important
to link it to the original so that the resolution is readily accessible.
3.2.4 Review the Change for Approval
Change Requests are reviewed and discussed at the weekly change meeting. The Change
Advisory Board (CAB) leads and approves the changes.

The CAB agenda includes but is not limited to a review of:

• Changes implemented in the previous 10 days.
• Changes to be implemented in the next 10 days.
• Changes to be implemented in the next 11 to 30 days.
It is the responsibility of the CAB members to conduct impact and resource assessments then
approve or reject changes. Relevant documentation such as test cases, scheduling, and back-
out plans are included in the Change Request. If the Change Request is not sufficiently
documented and/or is not represented by the Service Owner or designee, the Change Request
may be rejected. If a change is not represented by a Service Owner or technicians responsible
for the change during the weekly CAB meeting and questions arise, the change will not be
approved. All Service Owners should ensure their services are represented during all CAB
meetings.
3.2.5 Implement the Change
It is the responsibility of the change implementer to have an approved Change Request prior to
implementing the requested change. An exception may exist in an emergency change scenario
in which case an after the fact for documentation purposes is expected.

Page |8 Revision: 7/1/2022

Changes and back-out procedures must be prepared and documented in advance so that if
errors occur after implementation, these procedures can be quickly activated.
Changes are tested in advance (including back-out procedures when possible) and
implemented.
One of the keys to a successful change is having a detailed, well thought out documented work
plan. This prevents key steps from being forgotten. All Change Request contain the following
key elements:
• Complete work plan including pre- and post-implementation.
• Contact information for all change participants.
• Post implementation technical functional validation steps.
• Rollback/back-out plan.
• Adequately present the risk level associated with the change.
• Thoroughly describe the change, including how it was tested.
• Identify prerequisites and other changes that must take place in order to ensure
success.
Changes may take longer to complete than the change window communicated to the
customers. In this case the change implementer must open an incident ticket with the Support
Center for tracking purposes. The incident ticket is linked to the Change Request.
3.2.6 Update and close the Change Request
After implementing the change, the change implementer is responsible for updating the
Change Request with the status of the change (Successful, Unsuccessful, Cancelled,
etc.) and closing the change within 3 days of completion.

4.0 Process Governance

4.1 Process Controls
• ESP will be the only source record for all incidents – customers, users, technicians must
use this tool for reporting and managing all incidents.
• Service Owners/CI Managers need to approve Normal Change Request before CAB
review and approval.
• Technicians are required to attend weekly CAB meetings to discuss Normal Change
Request before CAB approval.
• Close all Change Request within three days of end date of change.
4.2 Measures
Key Objectives of Change Management

Page |9 Revision: 7/1/2022

 • Ensure that standardized methods and procedures are used for efficient change
management.
• Increase visibility and communication of changes to business and IT.
• Identify recommendations for service improvements and process improvements.

Critical Success Factors

• Reduce number of urgent/unscheduled changes.
• Increase overall change success rate.
• Maintain and improve customer satisfaction for changes.
• Identify continual service improvements.

4.3 Key Performance Indicators (KPI’s) and Reporting

Reduce Number of unsuccessful changes
• Total number of changes logged per month.
• Number of changes unsuccessful.
Reduce Number of Urgent/Unscheduled changes
• Total number of changes logged per month.
• Changes by service.
Reduce Number of Changes not closed in 3 days of end date
• Total number of changes logged per month.
• Changes by service.

4.3.1 Change Report

A report that contains high level details of all the changes and their proposed implementation
dates. We distribute the change report to our customers using two methods. One is posted on
http://support.watech.wa.gov daily. The other is sent via email in .pdf format. Customer
agencies will need to request the email versions of the Change Report.

4.3.2 Change Advisory Board (CAB) Report

• This report is used at the weekly CAB meetings for review, discussing and approving
changes.
• In ESP, select Transition, report, Change Management, Change Advisory Board (CAB)
Report.
• Use the filters to change timeframes, Forward 10 days, Previous 10 days, Forward 11-
30 days, Forward 30 days.

P a g e | 10 Revision: 7/1/2022
 • Select Change type, Normal, Standard/Preapproved, Information, or
Unscheduled/Urgent.

4.3.3 Success Rate of CR’s Report

• In ESP, select Transition, report, Change Management, Success Rate of CRS.
• Select Actual End Date of the Change Request, use the filter for status closed or in
progress. The actual End Date is the end date on the Change Request.

P a g e | 11 Revision: 7/1/2022
Appendix A – Glossary
Change –
The addition, modification, or removal of anything that could have an impact on IT services. Scope should
include all IT services, configuration items (CI), and their related processes/documentation (based on ITIL
v3 definition).
Change Advisory Board (CAB)–
The team that coordinates Change Management, and that reviews, approves requested
changes, assesses the impact of changes, and prioritizes changes.
Change Calendar –
The WaTech change calendar is an online report that includes information about approved
change requests.
Change Request –
The addition, modification or removal of any authorized, planned, or supported service or
service component that could effect on IT services.
Configuration Item (CI)–
Any IT component that needs to be managed to deliver an IT Service.
A configuration item (CI) is an infrastructure component provided by an organization to its
customers. It may be an item of equipment (e.g. servers, routers), an application (e.g. SAP,
expense account, payroll software) or a corporate service (e.g. Internet access, email system,
customer portal).
CIs are strategic components critical to Watech’s business. They are monitored in a specific
way in the Configuration Management Database (CMDB) because they may have an impact on
other items in the event of an incident or request. This impact can be in terms of availability or
services provided to users.
Each CI:
• Interacts with other impacting and impacted CIs via blocking or non-blocking
relationships. These are highlighted in the CMDB Graph.
• May have blackout periods during which modifications must not be made to the CI, as
well as unavailability periods.
• Is managed by groups whose roles are defined in workflows that manage related
incidents, requests and events.
The different types of Cis include:
Equipment CIs
• These are items of equipment moved to the CMDB via a dedicated wizard.
• They are linked to entries in the Equipment Catalog.

P a g e | 12 Revision: 7/1/2022
 Application CIs (software/software packages)
• They are created directly in the CMDB.
• They are linked to entries in the CI Catalog.
• They can be managed in the Definitive Media Library (DML).
Service CIs
• They are created directly in the CMDB.
• They are linked to entries in the CI Catalog.
• They are also linked to entries in the Service Catalog so they can be monitored in
the Service Portfolio.
Enterprise Solutions Platform (ESP) –
EasyVista’s SaaS solution hosted in the cloud.
Service Owner –
Service owners are responsible for configuration items within an IT service area. They will
provide coaching and guidance for teams to support the change management process. This
includes ensuring changes to configuration items are planned to maximize business value and
reduce incidents related to unplanned changes.
Technician –
A technician is a worker in a field of technology who is proficient in the relevant skill and
technique, with a relatively practical understanding of the theoretical principles.

P a g e | 13 Revision: 7/1/2022
Appendix B – Change Advisory Board
Change Advisory Board (CAB) consist of 5 members. The members rotate leading the
CAB meetings. The CAB is responsible for the Change Management process, the metrics and
continuous improvement of the process. The rotation schedule is located here.
The agenda for each CAB meeting is as follows:
Log into ESP  Transition  Reports  Change Management  CAB Report
Select Forward 10 days – Normal Change Requests
• Inspect each request and approve if appropriate.
• Discuss impacts to other services.
Select Forward 10 days – Standard/Preapproved Change Request
• Review the type of changes being requested as Preapproved and discuss
with group if needed.
Select Forward 10 days – Informational Change Request
• Review the type of changes recorded and ensure only vendor and/or
customer changes are categorized as Informational.
Select Previous 10 days – Normal Change Requests
• Look for tickets where the status is “Pending Post Implementation
Review”.
• Report to technician to close tickets that haven’t been closed.
Select Previous 10 days – Standard/Preapproved Change Request
• Review the type of changes being requested as Preapproved.
• Are they appropriate or should they had been Normal Change Request?
Select Previous 10 days – Unscheduled/Urgent Change Requests
• Review the type of changes being requested as Urgent.
• Discuss why and help group to improve.
Select Previous 10 days – Latent Change Requests
• Review the type of changes being requested as Latent.
• Discuss why.
Select Forward 11 -30 Days – Normal Change Requests
• Inspect each request and approve if appropriate.
• Discuss impacts to other services.
Select Forward 11 -30 Days – Standard/Preapproved Change Requests

P a g e | 14 Revision: 7/1/2022
 • Inspect each request and approve if appropriate.
• Discuss impacts to other services.
Select Forward 11 -30 Days - Informational Change Request
• Review the type of changes recorded and ensure only vendor and/or
customer changes are categorized as informational.

P a g e | 15 Revision: 7/1/2022