INFORMATION AND EDUCATIONAL TECHNOLOGY

(1)

INFORMATION AND EDUCATIONAL TECHNOLOGY

IET Change Management Process Model

This document describes the IET Change Management Process. The process seeks to minimize

business risk during a change to a service, service component, or supporting infrastructure.

This document may be used by:

 UC Davis colleges, functional units and customers who want to understand generally

accepted good practices for IET Change Management.

 Organizations that want to align with the IET Change Management process model.

 Note: Some elements of this model are specific to the IET implementation in the ServiceNow

change management system.

(2)

PROCESS OVERVIEW

IET Change Management is a systematic approach that defines the process and implements the procedures for recording and tracking the details of the service environment as it undergoes change.

 Maintain high quality service to customers

 Maintain the integrity of the IT production environment  Provide effective communications about all changes

 Provide a single set of procedures, a change management tracking system and a common database for managing change

 Ensure all changes are tested appropriately, based on risks such as their complexity, possible impact, and ability to be backed out

 Provide an approval process to manage and administer all changes

 Improve the effectiveness of change management processes, procedures and tools over time

OBJECTIVE

The overall objective of Change Management is to make sure that all changes are recorded, evaluated, authorized, prioritized, planned, tested, implemented, documented and reviewed in a controlled manner.

VALUE TO CUSTOMERS

Change management value can be summarized in two main benefits.

 The business is protected from any negative effects related to change  The business gets the improvements that they need

SCOPE

The addition, modification, or removal of services or service components will be subject to the change management process. This includes, but is not limited to:

 Application software  Application servers

 Communications equipment and software

 Databases or components supporting data storage and retrieval

 Facilities and environmental components used in connection with the delivery of IT Services  Global software pushes

 System Hardware  System Software

(4)

OUT OF SCOPE

Changes which have significantly wider impact than service changes or day to day operational tasks required for service and system operations:

 Application changes to development environments

 Build-out of servers/environments that are not part of current production or test environments and to which changes would in no way affect or impact production or test environments.

 The modification of existing, or the creation of new, software plans and procedures relevant to the running, support, and maintenance of systems and services

 File restores, data modifications, user managed application or infrastructure modifications which do not affect the functionality, data structure, or modify the output of a managed system

 Changes at an operational level such as repair to printers or other routine service components  Addition, deletion, or modifications performed at the individual workstation level.

 Changes with significantly wider impacts than service changes, e.g. departmental organization changes, policies, and business operations

(5)

PROCESS ROLES

Each person who interfaces with the IET Change Management process has a role and associated responsibilities that must be executed in order for the changes to be successfully implemented:

Role Description

Change Approver

The Change Approver reviews the Request For Change (RFC) using a risk based perspective. The change approver role may be performed by an authorized manager, supervisor, technical lead, or approval board. The change approver cannot be the same person as the Change Requestor. More than one change approver may be required for a change request, depending on risk, impact and urgency of the change.

Responsibilities include:

 Reviewing all change documentation

 Confirming that all required assessments (risk, impact, technical, business, operational) are complete

 Verifying that testing has been completed

 Verifying that production support is aware of the change  Verifying that back-out plans have been developed  Approval or rejection of the RFC

Change Requester

The Change Requester is the person who creates RFC’s for IT service components. The responsibilities of the Change Requester are to:

 Provide appropriate information to the required Change Approvers

 Ensure that the RFC is provided to the support staff so it can be entered into the Change Management Tracking System, and that it meets the qualifications for the change request, based on the risk level of the change.

 Obtain proper approval for Emergency Changes.

 Ensure that the change is Implement by Change Implementer(s) consistent with the approved plan and RFC

Change Implementer(s)

The Change Implementer in each support organization is the resource for change execution and is responsible for the installation and deployment of a change or change task.

Responsibilities include:

 Participate in the assessment and planning of the change CAB attendance  Implementing the change

 Providing status of all changes in progress

 Remediating and backing out a change if necessary

 Updating the RFC records with appropriate information and status  Closing assigned tasks within the scheduled date/time of the change

(6)

Role Description

Architecture Review Board (ARB)

The Architecture Review Board provides assessments of changes for consistency with IT architectural standards, future direction and governance requirements.

Responsibilities Include:

 Evaluate projects and related changes requests for compliance to established architectural criteria and business objectives

 Communicating architectural requirements and compliance checklists to projects in advance of development and change activities

 Providing guidance to project stakeholders to meet architectural conformance requirements

 Approval / rejection of proposed architectural changes

Change Advisory Board (CAB)

The Change Advisory Board (CAB) authorizes and approves or rejects changes before they are implemented and assists with the prioritization, coordination and scheduling of changes.

Responsibilities:

 Establish change management standards, policies and procedures

 Review changes for compliance to Change Management process requirements  Oversee change schedule risks

 Establish the forward schedule of changes (FSC)

 Define change classifications – Standard, Comprehensive (Normal), Emergency  Review failed changes to ensure corrective actions are implemented

 Authorize emergency change procedures

 Provide change management reporting for continual improvement

CHANGE MANAGEMENT PROCESS MODEL

The IET Change Management process model illustrates the standard flow of activities. The actual steps followed will be determined by the change classification. Depending on the classification, some activities will be bypassed or enhanced. (See below for Change Classifications and Workflow details).

(7)

Change Entry in ServiceNow (RFC)

The key objective of the Change Entry is to capture information about all change requests to be considered for implementation to any IT production system, prior to the changes being made. In addition, this activity provides a standard method of capturing change requests through ServiceNow, the standard system of record for IT changes together with the data concerning those changes.

 Capture all change requests  Create change record

 Ensure complete documentation

 Provide a central point for input of change requests  Determine / assign risk level of change request

 Provide lead time standards for change requests based on risk level  Communicate change requests to affected parties

ARB Assessment

ARB assessment provides technical and business reviews to ensure compliance with campus standards.  Ensure the change meets the requirements of the business

 Ensure the test plan is appropriate  Ensure the back-out plan is complete  Ensure the change is technically feasible

 Ensure software distribution plan is provided and complete

 Ensure the change is compatible with the system / application plans  Determine the technical impact on and interfaces with other applications

(8)

 Update change records

CAB Assessment

CAB assessment ensures change management process requirements are satisfied and changes are ready for operational deployment.

 Validate the lead time is being honored

 Determine how the change fits in with business plans  Determine impact on business partners

 Ensure user acceptance test plan is appropriate

 Assess conflicts with currently planned changes and environmental changes  Determine the business impact on and interfaces with other applications  Update change records

 Ensure documentation, procedures, and training plan is provided

Preliminary Change Scheduling

 Determine current change schedule  Approve, reject, or reschedule change  Schedule changes

 Resolve scheduling conflicts  Update change records

 Update Master Schedule / Calendar

Monitor and Test

 Ensure test plan compliance

 Validate testing completion (stress testing and user acceptance testing)  Assess test activities and results compared to standards

 Update change records

Final Change Scheduling

 Ensure completeness of prior activities  Make 'go / no-go' decision for each change  Determine final priorities

 Update Change Calendar

Monitor Install

 Verify readiness for installation  Install changes into production

 Approve or disapprove Emergency Changes  Update inventory as necessary

(9)

Change Management Reporting

 Changes bypassing the process  Number of Emergency Changes  Testing adequacy

 Provide information to users of the Change Management process  Identify changes that affect service delivery

 Develop corrective actions

RISK LEVELS AND LEAD TIMES

Risk levels are established to help evaluate uncertainty in these areas of concern:  Financial impact of the change

 Prior experience with the type of change  The degree of difficulty in managing the change



The technical complexity of the change

GUIDANCE TO ASSESS RISK

Risk Level 1- HIGH RISK/HIGH IMPACT

 Affects multiple groups on campus, a college, or a supported facility  The change is difficult or impossible to back out

Risk Level 2 – HIGH RISK/MODERATE IMPACT

 Changes affect a significant part of the customer’s business  Is hard to back out (but back-out procedures have been identified),  The change can be tested

 Similar changes have been done successfully in the past

Risk Level 3 – MODERATE RISK/ MODERATE IMPACT

 The change affects a small part of the business  Is relatively easy to back out

 Has been tested

 Similar changes have been done before successfully

(10)

 The change would have little effect on business (i.e., non-intrusive changes to individual applications that have no impact on other applications / systems, such as generating reports from a data

warehouse)

 Is simple to back out  Can be easily tested

 Similar changes have been done many times before

Risk Level 5: LOW RISK/LOW IMPACT

 Maintenance changes required to maintain system functionality but which need to be communicated to stakeholders

 Can be easily tested

 Back-out is easily done and non-intrusive to customers  Changes of this time are routinely done

(11)

CHANGE MANAGEMENT FLOW BASED ON RISK LEVELS

LEAD TIMES

Lead times are established for planning and scheduling changes based on risk levels. The requested change implementation date must be based on the lead time required for the assigned risk level

Emergency – Submitted after change has been implemented, if possible approved via Emergency CAB Urgent – Approved via Emergency CAB

Risk Level 1 - Must be submitted 3 days prior to ARB meeting. Risk Level 2 - Must be submitted 3 days prior to ARB meeting.

Risk Level 3 - Must be submitted no later than 3 days prior to implementation. Risk Level 4 - Must be submitted no later than 3 days prior to implementation.

(12)

CHANGE CATEGORIES, CHANGE TYPES AND WORKFLOWS

CHANGE CATEGORIES

Two categories of changes are established as follows:

 Planned - Changes that follow the standard change management process and are reviewed, approved and

scheduled in advance.

 Emergency– Changes that are required as a result of unforeseen events for which planning is not feasible

to avoid service disruptions/outages.

Note: See the IET Change Management ServiceNow Implementation.docx document for a description of the workflows implemented in ServiceNow to process these change types.

PLANNED CHANGES

Planned changes are categorized as Standard and Normal.

 Standard: changes are pre-authorized changes that are generally low risk, commonly done and have a pre-established and approved procedure or work instruction to perform the change.

 Normal: Any change that is not a Standard or Emergency type change.

EMERGENCY CHANGES

Emergency changes are required to restore normal services to campus customers after an unexpected service disruption or to prevent a priority 1 or 2 incident from occurring.

CHANGE ADVISORY BOARDS

A Change Advisory Board is a body that exists to assist Change Management in the assessment (impact/risk), prioritization, and scheduling of changes. Members ensure that all changes are adequately assessed from a business, technical, deployment and emergency viewpoint. Emphasis is placed on balancing Client business needs with the risks and effects of services interruptions.

ARCHITECTURE REVIEW BOARD (ARB/TCAB)

Purpose

The Architecture Review Board (or Technical Change Advisory Board) consists of specific technical and business experts that can assess and validate changes proposed for risk, impact, and need going into the production environment.

(13)

Scope

 Reviews all RFCs flagged for ARB/TCAB review to assess and validate their technical feasibility  Ensures RFCs are adequately assessed for cross boundary systems, apps, Geos, Domains etc. impacts  Ensures documentation and plans for testing/mitigating cross boundary impacts are identified  Assesses the change for scheduling impacts

DEPLOYMENT CAB (DCAB)

Purpose

The Deployment Change Advisory Board (DCAB) evaluates the readiness and gives approval of any change to be introduced into the managed environment.

Scope

 Makes decisions on Service, Implementation and Operational readiness and the final decision on the actual release date

 Ensures all changes in the scope of the CAB comply with defined Change Management Processes  Ensures that post implementation emergency changes (meeting defined criteria) to the managed

environments in the scope of this body are justified, and that corrective action is being taken  Tracks all expiration dates of all Standard Change approvals

 Verifies risk associated with change is correct

EMERGENCY CAB (ECAB)

Purpose

The Emergency Change Advisory Board (ECAB) evaluates the readiness and gives approval of any emergency and urgent changes to be introduced into the managed environment. The ECAB meets via email in an Ad-hoc manner to evaluate changes immediately upon receipt of the RFC.

Scope

 Makes decisions on Service, Implementation and Operational readiness and the final decision on the actual release date

 Ensures all changes in the scope of the CAB comply with defined Change Management Processes  Ensures that post implementation emergency changes (meeting defined criteria) to the managed

environments in the scope of this body are justified, and that corrective action is being taken

(14)

(15)

APPENDIX

The appendix contains addition exhibits and standards used to support the Change Management Process (Beta)

APPENDIX B – REQUIRED DOCUMENTATION

In addition to the required fields in the ServiceNow, additional documentation is required. The following table outlines the artefacts that are required for each approval.

ARB Deployment CAB Emergency CAB

Required Artifacts  Impact Assessment  Technical Design  Test Plan

 Risk Assessment  Implementation Plan  Back Out Plan  Validation Plan  Test Results

 Communication Plan

 Implementation Plan  Impact Assessment  Back Out Plan  High priority Incident

Record

Post Deployment

 Post Implementation Review

 Any other required artifacts per the request of the ECAB or TCAB

INFORMATION AND EDUCATIONAL TECHNOLOGY