University of North Dakota (UND) University Information Technology (UIT) has implemented an ITIL (Information Technology Infrastructure Library) aligned change management practice. The details regarding how UND UIT has crafted the change management practice and the processes supporting its function are outlined in this document. The change management practice is intended to ensure that only approved modifications to the environment are implemented.

Change Defined

ITIL defines a Change as:

"The addition, modification, or removal of any authorized, planned, or supported service or service component that could affect IT services."

This encompasses a wide range of alterations within an IT environment, including changes to:

· hardware

· software

· networks

· configurations

· policies

· procedures

· organizational structures

UIT has built the change practice with the intent that all changes are executed as controlled events that have been approved by the appropriate change authority while maintaining and adjusting the status of impacted Configuration Items (CI) to reflect the post change state. The process is intended to provide high visibility into change activity and open lines of communication between functional teams and the business, with the ultimate goal being to implement all changes in a controlled manner, minimizing risks and disruptions to the services provided.

Change Management Purpose

The main purpose of change management is to reduce risk inherent in change and to add value to a service. This is measured with the following objectives:

· Minimize any negative impact resulting from a change

· Provide accountability defining who, what, when, where, and why

· Maintain configuration information on all CI’s within the environment

· Define a clear, unambiguous change approval process

· Measure and track all changes to the production environment

· Assist in compliance with Service Level Agreements (SLA)

· Assess the impact associated with all changes

· Assessing the change meets implementation expectations

· Facilitate communication of changes to impacted groups

Types of Changes

The ITIL framework defines three levels of change which are described in this document as reflected in the table below. Change types are defined around specific parameters that measure potential impact (risk) posed by change.

Standard Change

(Minimal Risk)

Normal Change

(Moderate Risk)

Emergency Change

(High Risk)

- Routine

- Executed successfully many times

- Well understood

- Well documented

- Pre-authorized via prior introduction as a Normal Change

- No customer impact

- Service customers are impacted.

- Must be scheduled, preferably during an existing maintenance window.

- It must be assessed and authorized, and a planned outage must be communicated before implementation.

- Presents risk/potential impact to one or more departments and/or the university.

- Service customers are impacted.

- It must be implemented as soon as possible, not limited to a maintenance window.

- It must be assessed and authorized, and an outage must be communicated before implementation.

- Presents risk/potential impact to one or more departments and/or the university.

- Only executed with Emergency Change Advisory Board (ECAB) approval and in response to active service-impacting issues

When to Submit a Change Request

A change request must be submitted for all changes; Standard, Normal or Emergency.

· Standard Changes

o Automatically Approved by TDx workflow

o A Normal Change request must be submitted to gain initial approval for change candidates wishing to gain Standard Change status

· Normal Changes

o Normal changes must be approved by the Change Advisory Board (CAB) prior to implementation

· Emergency Changes

o Executed only in response to service impacting outages

o Approved by Director/Deputy CIO/CIO verbal, text or email approval

o Rapid service restoration is the priority

o Verbal/email approval must be followed by a retrospective (or simultaneously if time permits) Emergency Change in TDx which will follow the emergency change approval process (post change).

o All emergency changes will be reviewed to ensure:

o The emergency process is not being misused

o Information on steps taken, root cause and mitigation are being noted

o Problem tickets are being created where root cause is unknown

When a Change Request (CR) is Not Needed

A change request is required when making any alterations to UND technology resources. As noted above, standard changes, once submitted are automatically approved for implementation. All other changes will follow the appropriate change approval process.

Change Process Phases Overview

Request Change

UND UIT has selected the TeamDynamix system as the IT Service Management Platform.

All change requests must be made via the TeamDynamix system using the change request form.

This will allow all changes to be tracked from start to finish, providing a detailed record of what changes have occurred, who did them, and what the results were at the time of the change.

Approval

Changes to the environment can only be implemented after a change request is submitted and approved through the approval process unless it is a Standard change and therefore has been preapproved.

· All Normal and Emergency changes must be reviewed and approved by the appropriate CAB or ECAB.

· Changes scheduled to be implemented outside of agreed change windows should be scheduled at least one week post CAB approval to allow time for interested parties to learn of the change via the change calendar and Sorry App.

· Changes occurring within a scheduled change window may be implemented upon approval within the standard change window.

Communicate

All Changes must be communicated.

UIT will communicate changes via:

· TDx Change Calendar

· Sorry notification app

· Direct contact with impacted user groups when appropriate

The TDx change calendar is available for viewing by all members of the UND community. The UND Sorry notification system is also available to all community members and allows community members to subscribe to notification streams that are of concern for them.

Implement

Once approved a change can be implemented. Changes must be implemented:

· By the change implementor or other qualified person acting on their behalf

· Through the execution of the steps outlined in the change implementation plan

· Within the approved change window

In the event an approved Change Request cannot be implemented within the approved change window the change cannot proceed and must be moved to a failed or backed out status (based on circumstances) with a detailed explanation as to why the change was not implemented per the approved window.

Actions permitted are limited to only those move/add/change/delete activities reviewed and approved in the Change Request. Modifications outside of the scope of the approval MUST not be made. Change Implementers that violate the scope of their approved change requests may be subject to the loss of their change implementations privileges.

Once the change has been implemented and validated through the execution of the approved test plan, the assignee must place the change request in the appropriate state. Changes that can not be successfully implemented using the approved change steps must be backed out within the change window. A failed change must be noted as Backed Out with notation in the change record as to what went wrong to assist in reviewing the failed change and aid in future change attempts.

Change Status Codes

· Created

o Change created in TDx but not yet submitted for CAB review

o Default status for newly created change request

· Submitted for Review

o Change submitted for CAB review

o Automatically set by TDx upon submission

· Approved for Implementation

o Change Approved by CAB for implementation

o CAB Change Manager will set this status upon approval

· Rejected

o CAB rejected – CAB Must provide rational for rejection

· In Progress

o Change is actively being implemented

o Change Implementer is responsible for setting the change to this status at the start of implementation

· Implemented – Successful

o The change was completed as planned

· Implemented – With Exceptions

o The change was completed with minor deviations

§ Start time

§ Minor functionality concerns

§ Required minor correction of change steps

· Backed out – Failed Implementation

o Could not be implemented as approved

· Backed out – Unexpected Impact

o Implemeted as approved but had unexpected impact on other service

· Cancelled – Change not attempted

o The change was not attempted (never started)

o Note the cause of the cancellation

· Closed – Successful

· Closed – With Exceptions

· Closed – Backed out

· Closed – Cancelled

Change Closure

As part of the regularly scheduled CAB meeting, the CAB will review all Normal and Emergency changes that are in the Implemented, Backed Out or Cancelled Status to ensure they were implemented as scheduled and produced the expected results, review the reason for back out or cancellation. The CAB will place the change in the appropriate closure status

Regular review will ensure a continual improvement in the quality of changes.

Changes will be moved to closed status by the Change Manager.

Changes must be submitted by noon on Friday the following week or it will not be discussed within the CAB meeting and therefore will not be approved.

A representative to the proposed change from the submitting group must be present at the meeting in order for the change to be discussed, otherwise it will be postponed to the following week.

Change Management Practice RACI Matrix

Change Practice RACI	Change Requestor	Peer Reviewer	Implementor	Change Manager	Change Advisory Board (CAB)	Director	DCIO	CIO
Create and Maintain Change Policy	C	C	C	R	R	R	R	A
Create and Submit Change	A	I	I	I	I	I	I	I
Peer Review Change	I/C	A	I/C	-	-	-	-	-
Represent Change at CAB	A	C/R	R	I
Change Review	C		C		A
Emergency Change Approval	C	-	C	I	I	A
Approve/Reject/Set Status	I	I		R	A
Implment Change	A
Test Change			A
Back Change Out			A
Update Post Implemenation Status			A
Closure Review	I	I	C	R	A	I	I	I

Change Management Hierarchy

Roles and Responsibilities

Change Requestor

The Change Requestor is the staff member requesting the change via creation of a Change Request Record in TeamDynamix. Requestors may initiate Change Requests based upon operational need, external requests (request or incident tickets).

The Change Requestor initiating the change must provide a clear rationale for creating the change and be able to articulate the change's purpose.

The change requestor will be responsible for documenting the steps required to implement the proposed change. Changes must be defined in detail sufficient to allow someone with appropriate technical knowledge to interpret, review, and implement the change using the provided change steps. In general each change must include:

· Change Type

o Standard, Normal, Emergency

· Title

o Short title description for the change

· Textual Change Description

o Detailed verbiage outlining the changes intent and expected outcome

· Impact/Urgency Rating

o Calculated via the matrix

· Risks

o Risks to service, data, etc

· Implementation Plan

o Implementation plans must be written in sufficient detail to allow any properly trained staff member to both evaluate a change prior to approval and to implement the change once approved.

· Test Plan

o Defines steps specific to how the change will be tested to verify the expected outcome

§ Includes specific expected outcomes

· e.g. Version x upgraded to version x+1 as proven by system version output screen capture

· Backout Plan

o Defines steps specific to how the change will be reversed should the expected outcome fail or other issue occur that prevent the change from passing the tests outlined in the test plan

o Note that changes not complete at the close of the approved change window are considered failed changes and must be backed out (or obtain emergency change approval to continue)

· Implementation Dates/Times

o Changes must occur within the requested/approved change window

o Implementation Date/Time is used to populate the Change Calendar

§ Changes cannot be made prior to the approved Date/Time and cannot continue beyond the close of the change window

· Other information may be required dependent upon change type

Requestors will also shepard the change through the approval process. Generally the process will flow as follows:

Peer Reviewer

o Ocurrs prior to moving into CAB Review Cycle

o Qualified staff member reviews change and approves it as safe/effective for the intended purpose

o Once approved in peer review, Change moves to CAB review

CAB Manager

CAB

o High Impact Changes

§ Impact is determined by the Impact/Urgency Matrix

§ Reviewed Live in the Weekly CAB meeting every Wednesday at 3:00PM

§ Changes must be in the review queue for an upcoming CAB no later than Change Cutoff 5PM the preceeding Friday afternoon.

· Allows CAB participants time to properly read/review changes prior to the live CAB meeting Wednesday at 3:00PM

§ Unanimous approval required for a change to be eligible to move to Approved

§ Any approver can reject a change

· Rejection reasoning must be supplied

· Changes that are not represented by the Requestor (or Implementor) will be rejected and must be rescheduled for review at the next CAB

§ Changes will be moved to Approved/Rejected Status by the CAB leader upon approval/rejection by the CAB participants.

§ While changes can be implanted upon approval at the Weekly CAB, requestors should allow enough time to publish the change and communicate to any impacted user groups at least 1 week prior to High Impact Changes

o Medium/Low Impact Change

§ Reviewed dynamically following automate workflow in TDx

§ Changes reviewed by each approver electronically

§ Once approved by all approvers change moves automatically to Approved/Implementation Status

§ Implementation may begin as soon as the change has moved to approved status and the change calendar and Sorry App are updated to reflect the time/date of the change.

Implementor

The Implementor is the staff member who will be executing the steps required to implement the change. The Implementor is ultimately responsible for completing the change.

· If acting as the Requestor

o Document and submit the Change Request as per the Requestor Guidelines above

o Obtain technical Peer Review

o Represent the change during CAB or ECAB.

· Ensure that all tasks within the change implementation plan are completed as approved

· Implement the change as planned (no more, no less), including validation, and close the change before the scheduled end date/time if possible, but no later than 24 hours of the Change execution.

· Update the change request with installation notes, status changes, and results.

· Update any Configuration Items (CIs) that may arise from a change.

· Update the CR in TDx, including any needed changes to asset/CI records, to reflect the status of the change post implementation

· Participate in a Post Implementation Review (PIR) for all emergency changes and changes that were Backed- Out, Incomplete, Completed with Issues, or Latent Changes.

Peer Reviewer

The Peer Reviewer is a staff member on the Requestors team with appropriate knowledge and qualifications relevant to the environment where the Change will occur. The peer has the following responsibilities:

· Review the details of the Implementation plan to ensure the technical steps planned are complete and the change is correct.

· Review the backout and validation (test) plans to ensure there is sufficient detail to be effective.

· Represent the change during CAB if the implementer cannot do so. The peer must be familiar enough with the change to answer any questions that may be asked during CAB.

· Back up the Implementor during the actual change implementation.

Group Manager

The technical supervisor or team lead has the role of the Group Manager and has the following responsibilities:

· Review all changes for the Assignment Group for accuracy and approve those that meet scheduling and resource requirements.

· Ensure that the plan includes the requirements for communicating the change to stakeholders.

· Represent the change during CAB if the Assignee and/or Peer Reviewer cannot do so. The Group Manager must be familiar enough with the change to answer any questions that may be asked during CAB.

IT Director

An IT Director has the responsibility to:

· For High Impact changes unrelated to an incident, approve, deny, or send changes back for more information.

· Ensure that High Impact changes align with the business' direction and strategy.

· Approve emergency changes via, phone, email, text as may be expedient in the moment and follow up with approval of the Emergency Change when the formal request is submitted post Emergency resolution.

· Ensure that emergency changes are executed in compliance with the change policy.

Change Advisory Board (CAB)

UIT will have one Enterprise Change Advisory Board. CAB members may include:

· UIT Leaders

· Subject Matter Experts

· Project Management

· Security

The CAB has the following specific responsibilities:

· Attend the Weekly High Impact CAB meeting

· Approve/Reject Change Requests via TDx and associated automated workflows

o Assess proposed changes for impact.

o Approve, deny, or request more information as appropriate.

· Supports adherence to Change Management policies and processes.

Emergency Change Advisory Board (ECAB)

The ECAB only approves emergency-level change requests that are required to be actioned outside of the normal CAB process due to an active high impact incident (zero day event, broad based network outage, server failure, application failure etc).

Emergency change approval consists of with a verbal (direct phone conversations) or written (email/text) approval of the action proposed in the ECR. Upon approval by one of the ECAB members below the propose change may be implemented as requested. The Requestor will follow up post resolution of the outage with a posthumous Emergency Change in TDx to document the change and formalize the approval. The emergency cab approvers are:

· Janna Kruckenberg

· Chadd Damm

· Phil Goldblum

· Madhave Marasinghe

Requesting a Change

UIT members with valid change privileges can submit a Change Request. Changes can come from user requests, incidents, or operational processes that need a change to be resolved. All changes must link to the related Incident, Request, or Operational process ticket that causes/requires the change. Changes cannot start without this input.

UIT members who violate the policy in this document may have their change privileges revoked.

Change requestors may lose their change privilege if they:

o Implement any change without approval

o Alter/deviate from the approved change plans

o Do not execute the approved test plan

o Execute a change at the wrong time

o Failing to back out CRs that cannot complete within the approved change window

o Failing to back out CRs that cause service outage,

o Failing to closing out changes properly

o Other items as the change process owner may determine

Rating the Impact and Risk/Complexity

An impact and risk/complexity matrix has been created to help calculate a risk/complexity score for each change type. This score will determine the type of change and the required authorization process.

To minimize risk to UIT Services - changes should always be tested in a test environment before they are scheduled for the production system.

Impact Level Table

3 - Low Impact (Standard)

2 – Medium/High

(Normal)

1 – Emergency

(Emergency)

- Preapproved change

- The outage will affect the system's end users.

- This may or may not impact administrators.

- The outage affects all end users on the system.

- This may or may not impact administrators.

Risk/Complexity Level Table

Standard

Normal

Emergency

- Review preapproved list

- Complex change has not been done before in production.

- Change has been tested on the test environment unless it is not possible.

- An outage may be needed.

- Rollback plan needed/discussed.

- We need to mitigate the issue with the system ASAP.

- Complex change that has not been done before on production or has been done, but change has significant risks.

- Change has been tested on the test environment unless it is not possible.

- Rollback plan needed/discussed.

Calculating Risk/Urgency Level

The table below is used to determine the impact level of a change. The risk/urgency level assigned to a change will determine the required approval flow for that change. The assignment of a rating is accomplished by selecting the appropriate risk and urgency levels for a given change based on the parameters noted in table 2 and cross referencing these in table 1 to find the appropriate risk urgency score (1-3).

Table 1 – Risk/Urgency Score

Impact vs. Urgency Rating Table
	IMPACT	Low	Medium	High	Emergency
RISK	Low	3	3	2	1
	Medium	3	3	2	1
	High	3	2	2	1
	Emergency	1	1	1	1

Table 2 – Risk Urgency Parameters

Risk Rating and Parameters		Urgency Rating and Parameters
Low	Proven to be successful	Low	1 to 10 users impacted. Or unlikely to cause notable impact.
Medium/High	Complex / difficult to Implement	Medium/High	11-50 users impacted or could cause moderate functionality impact Or Executive/VIP or > 51 users impacted. Or could cause - significant loss or degradation of a service
Emergency	Requires Immediate Fix and/or imminent danger of further damage	Emergency	Requires Immediate Fix to avoid further damage or required to address total outage of a service

Change Score and Approval flow

A changes over all rating, and thus its required flow through the approval process is determined by its impact rating as defined here. The rating itself (1-3) is assigned based on the matrix and parameters above.

Rating	Legend	Change Approver	Required Notice
3	Standard Change	Automated	Executed in Maintenance window – same day Executed outside Maintenance window – 24 hours after auto-approval
2	Normal Change	CAB	Execute in Maintenance window = same day as CAB approval Executed outside of Mantenance window = 48 hours after CAB approval
1	Emergency Change	ECAB Member	Immediate as per needs of change – Notify ECAB member, obtain verbal approval in the moment, follow up with EChange

Review and Approval

Review and approval refer to the workflow that evaluates the documentation within the change request.

The review and approval workflow includes review, evaluation, and approval by a peer, manager, IT director, and a Change Advisory Board (CAB) or Emergency Change Advisory Board (ECAB) as appropriate for the specific change type as indicated in the Risk/Impact Table.

Change Authority

A change’s approval path is dependent upon the rating of the change based on the table below. These approval paths are automated within TDx for Standard/Normal Changes and executed manually by the requestor for emergency changes.

Table 3 – Change approval path for Standard, Normal and Emergency Changes

Level of Change	Change Authority
Standard	Preapproved by: · Peer Reviewer (formal) · Group Manager · IT Director · CAB · Automated After initial Approval of the change
Normal	Change Request to: · Peer Reviewer (formal) · Group Manager · IT Director · CAB
Emergency	Change Request to: · In the moment, Initial Approval for Emergency Service Restoration can be requested by phone / text conversation with IT Director, DCIO or CIO · Post Change approval of Emergency changes along with a review of the change made to restore service - ECAB

Scheduling a Change

The change requestor specifies the desired implementation time/date in the TDx change request. The CAB may alter the requested implementation time to avoid conflict with other changes.

Change the Status

Upon approval the Change manger (Staff Member running the CAB) will change the status to Scheduled in TDx.

Communication

Communication of planned changes will be via (up to) three separate channels to ensure the broadest visibility of upcoming change activities. The communications for the various types of changes are noted below:

o TDx Change Calendar

§ All changes will be displayed in the TDx Change Calendar/

o Sorry Status and Notification Application

§ Standard Changes will be displayed

§ Normal Changes will be displayed

§ Emergency Changes will be displayed

§ Note that any interested community member can sign up to receive notifications for change types of interest

o Team Dynamix Status Page

§ Planned High Impact Changes

o Direct Communication to impacted users

§ High Impact changes will be communicated to the impacted user community by the change requestor via email and where appropriate, meetings to convey the scope impact and timing of the change

Implementing a Change

Change the Status

Before initiating the actual change activity, the assignee must change the status from Scheduled to In Progress. This action informs others that the change is now underway. The change cannot move to “In Progress” before the scheduled start date/time. This can be of great value in troubleshooting issues that result from the change itself or interaction of the change with other systems.

Enter the Actual Start Time

After changing the status to WIP, the assignee must enter the actual start date/time in the change request form (TDx). This action informs others of the specific time the change activity started. This can be of great value in troubleshooting issues that result from the change itself or interaction of the change with other systems.

Document activity in the Work Log

The implementer must document the change activities in the TDx work log. Activities should where possible be updated as the change proceeds but in all cases must be updated as part of the change close out process. Examples of the kind of information that would be appropriate are:

· reaching key milestones in the implementation reached

· unexpected issues with the implementation

· the start/stop of validation, as well as any unexpected results

· the reasons for backing out a change or closing the record as incomplete

Closing a Change

Update the Change Request

The implementer must document the following information in the closure of any Change:

1. Results Status: (TDx DropDowns?)

a. Successful

b. Backed out

c. Completed with issues

d. Incomplete

2. Provide a work log

a. the reasons for backing out of a change

b. issues that delayed or complicated the implementation

c. issues that result in closing the record as incomplete (if appropriate)

3. Document the start and end times

Update the Cis

The implementer must update the Configuration Item impacted by the change if any configured items were added or removed or if any documented attributes changed.

CIs impacted by a change must be associated with the change request.

Missing CIs (that have not been added to the CMDB should be added as part of the change).

Post Implementation Review

If the change is not successful, a post-implementation review will occur.

A Results Code of any value except Successful will require the approving Assignment Group Manager to perform a Root Cause Analysis (RCA) of the exception.

The RCA must document:

· A description summarizing why the change was not successful

· A description of the business impact

· A description of the root cause

· A description of effort that will be put in place to prevent a similar exception

The objective of the Post Implementation Review is to:

· Define the change and events that resulted in the exception

· Identify the root cause

· Identify potential actions to mitigate future occurrences

Close the Ticket

The assignee can close the Change Request ticket if the change was successful or after a post implementation review is completed.

Adding a Service to Change Management (IS THIS AN APPENDIX?)

Configuration Items (CIs)

A configuration item is an identified part of a service that manages the settings and configuration to avoid the risk of unplanned outages for end users.

Configuration Items	Examples
Software	Application, database, virtual machines, containers, licenses
Infrastructure	Servers, routers, firewalls, load balancers, switches
Endpoint	Laptops, tablets, smartphones, printers
Locations	Data centers, server rooms, comm closets

Documenting Configuration Items CIs

1. Create a network diagram of the service.

a. Examples of information include Servers, firewalls, VLANs, load balancers, and location.

2. Identify and document systems/processes that this service relies upon.

a. Example: User accounts are created within the service nightly using a file feed from HRMS.

3. Identify and document systems/processes that rely on the service.

a. Example: Usage report of the service is provided nightly to a customer using data from the system.

4. Identify and document peak times and maintenance windows.

Creating Change Lists

1. Review the change list template and remove any changes that are not applicable.

2. Expand the list to include changes to the service in the past.

3. Add a list of hypothetical changes that could occur to the system.

a. This does not need to be exhaustive, as it will be added as new changes are discovered.

4. The change lists categorize each change as Standard, Normal, or Emergency. A change classified as Standard must be presented to the CAB for pre-approval.

Documenting Change Authority Hierarchy

Documenting the individuals in each role for a change approval can prevent confusion and mistakes.

Appendices

Definitions

Service: An IT service is the product that IT provides to a customer. It is "the stuff IT does," which includes traditional IT items such as endpoints and applications. However, it also encompasses the advice, knowledge, and support provided to a customer.

Change Request Form Questions

1. The change will be to what service?

· Drop down of services.

2. What is the risk/complexity of the change?

· Low

· Medium

· High

· Immediate

3. What is the scope of impact on end users of the service during or after the change?

· No impact on end users

· Impact on limited groups of end users

· Impact on groups of end users (i.e. Students, Faculty or Staff)

· Impact on all end users

4. What type of change is this?

· Standard

· Normal

· Emergency

5. Has the change been tested?

· Yes

· No

6. What is the backout effort?

· Difficult, impossible, or undesirable

· It is possible, though not quickly executed, but it would extend beyond the maintenance window.

· In place and quickly executed within the maintenance window

· Minimal

7. Are there other departments involved in making the change?

· Yes

· No

8. When will the change occur?

· During a scheduled maintenance window

· Non-peak hours, on non-peak days

· Business hours on non-peak days

· Any time on peak days

9. Proposed Start Date and Time

10. Proposed End Date and Time

Was this helpful?

0 reviews

Print Article

Updating...

IT Change Management Practice

Enter the Actual Start Time

Document activity in the Work Log

Deleting...