University of Missouri System DoIT has established this change process to support the needs around changes to its IT services.  A change enablement practice aims to ensure that changes to services and their components are controlled and that they meet the organization’s change-related needs. Authorized changes should enable the desired outcomes and meet the balance the organization’s need for changes, speed to complete changes and risk tolerance.

Definitions

To set the stage for the Change Enablement process, it is important to understand the basic definitions and concepts.  Each definition is expanded upon as to how it relates to the process.

Change

The addition, modification, or removal of anything that could have a direct or indirect effect on services.  As this definition applies to a wide variety of situations, changes are further classified by types.

Change Types

Changes to IT services are broken down into the following types:

• Standard Change – No or low-risk changes that are carried out regularly and  only needs approval once. Standard changes should follow their respective standard operating procedures to capture any necessary information about those changes. 
• Minor – Low risk changes that have no or low impact to services that are not critical and thus only need minimal governance. These are approved by the requester’s supervisor.
  • Little to no impact
• Major – Moderate to high-risk changes that will have a significant impact to services and require review, communication, and coordination. These are approved by CAB.
  • High number of people impacted
  • Critical services with any downtime or user impact
  • Non-critical services with downtime of more than  4 hours, impacts entire units, or impacts more than 50  users
• Emergency Change – Changes that require quick implementation typically to address a significant outage or other urgent matter.  These have a streamlined approval process and must be approved by a member of ECAB and reviewed in the following CAB meeting

 

Service

A means of enabling value co-creation by facilitating outcomes that customers want to achieve, without the customer having to manage specific costs and risks.  For IT services, the IT organization has products and skill sets available that customers can leverage to get value from and without having to get these on their own.  This uses greater economies of scale and provides optimal value to the university.

For change management, it allows for associating the change to the appropriate service for reporting and understanding impact.  This is helpful for planning and management of the service.

Incident

An incident is an unplanned interruption to a service or reduction in the quality of a service.  It can also be the perceived interruption or reduction of quality experienced by a customer.  Essentially, these are activities to address something that is broken or not working properly, commonly referred to as “break/fix” work.

 Within change management, incidents can occur as the unexpected action of making a change. Even planned changes can cause interruptions or drops in quality for users. Keeping Incidents and Change Management tied together benefits it two ways. First, it reminds those executing changes to be mindful of potential incidents and it also provides us with a helpful metric to collect data on the effects of change management.

Ticket

A generic term used to describe incidents, service requests, problems, and changes collectively, especially in relation to using TDX/TDNext.

Maintenance Activities

 

Team Dynamix Tickets have start and end dates, but do not have time associated with them. Maintenance Activities are tasks in change tickets that allow to log times along with Start and End Dates. Minor and Major tickets will require times along with dates, so Maintenance Activities will be necessary for those two types of Change Types.

Roles

The following roles have been identified for the change enablement process.  It is possible for a person to take on multiple roles within the process as these do not always imply titles or jobs.

Requester – the technician or end user who is requesting the change.

Responsible Technician – the person who is assigned as owner of the change ticket who will oversee the work.

Change Manager – the day-to-day facilitator of the Change Management process.

Service Owner – Key stakeholder accountable for the day-to-day service performance and managing changes related to their service.  Facilitates prioritization for service enhancements and may be involved in the approval process. 

Change Advisory Board (CAB) – a group representing technology and business stakeholders that advises the organization and/or change manager on the assessment, scheduling, and prioritization of changes. Will be responsible for reviewing & approving Major changes, post-hoc review of Emergency changes, and ensuring that all details related to the change have been considered, reviewed, and prepared for.

Emergency Change Advisory Board (ECAB) – (Current this is at the director level) a group representing senior technology leadership that advises regarding emergency changes that are urgent and must circumvent normal approval processes and be performed outside of typical change windows.

Change Management Process Owner –  The coordinator of the Change Management Process. This person is responsible for aggregating and organizing documentation, ensures standards are being upheld, and serves as a liaison for change management on the campus.

 

 

1. Create / Update Request – A technician requestor (or select clients) who will coordinate a potential change will create a new change ticket. 

• Technicians will submit RFCs through TDNext
• Client RFCs may be submitted via the client portal
• Change Type – select the appropriate change type, following guidance provided within the form
• Assets/CIs – this is optional, but helps with conflicts in scheduling. Associate any assets/Cis involved in the change to the ticket.  This helps in understanding the impact and risk of the change.
• Publish to Portal – this will indicate that the change should be published to the public dashboard. Should be left to No, until CAB review, unless it’s a Minor change.
• TDX Change Management Documentation

 

Change Type – The request will be routed based on the change type identified.

2. Emergency Changes
   1. ECAB Approval – For emergency changes, the emergency change advisory board will review requests submitted and advise. The review can be conducted by any one member of ECAB.
3. Minor/Major Changes
   1. Schedule Maintenance Activities – For Minor/Major changes, additional information is needed to understand the timing of the work to be performed.  Maintenance Activities may be created in the ticket via the +Add Maintenance Activity.
   2. Manager/Service Owner Approval – The technician’s supervisor and/or the owner of the service will provide their approval.  The approver will review the change for completeness and confirm its proper classification of change type.  If there are concerns, the approver can reject the request and return it back to the requestor.

Minor changes are low risk and upon approval will move forward with the change.Major changes are moderate to high risk and will require CAB approval.

1. CAB Approval – The CAB reviews the requested change and will highlight any concerns or provide approval to complete.  Additional details including deadlines for submission can be found in CAB section of this document.

4. Communicate & Perform Change – The responsible technician coordinating the work will provide proper communication to the service desk, impacted users accordingly, and to any communication plan before, during and after the change.  The change will be completed as documented and approved.
   1. Outcome – Successful changes are documented as such in the ticket and the ticket is closed.  Unsuccessful changes will employ any rollback plans.  If the change will no longer be considered, it will be closed out as rejected.  If the requestor will re-attempt the change, they will update the change and restart the workflow.

Membership

 

• CAB members were selected by their Directors.

Meetings & Agenda

Meetings occur weekly on every Thursday (excluding holidays) at 1:15 pm.  To have a request added to the agenda for consideration and approval, it must be submitted by end of day Wednesday prior to the next CAB meeting. Any changes submitted the day of a CAB meeting will be held until the next week’s meeting.

Attendance

Permanent members representing business and technology stakeholders will attend each week regardless of agenda.  If a permanent member cannot make a particular week’s meeting, they will have a stand-in to represent their domain. If there is no representation for a given ticket, the ticket will be held until the next week’s meeting.

The Responsible Technician will be expected to attend or have a representative present at the meeting for their agenda item.  They do not have to attend meetings for other agenda items they are not affiliated with.

Review Considerations

The CAB will review the following aspects of changes:

• Business justification
• Impact analysis
• Risk analysis
  • Review infrastructure diagram, assets and CIs and their relationships to other assets/CIs
• Scheduling analysis, checking for blackout periods and standard change windows
• Communication considerations/plan
• Testing plan
• Backout plan

In the event of an emergency change, the ECAB does not meet, but rather will review requests as they are submitted. Any member of the ECAB will have the ability to approve of the change as a member of the senior leadership team.

An emergency change occurs when a vital service at the university experiences issues. ECAB is contacted for approval if the change is urgent and needs a short turnaround time. ECAB does not meet. Instead, one member of ECAB may review the change and approve, allowing for quick changes to be implemented to return services to normal.

 

Membership

The ECAB consists of the directors at the Division of IT.

 

 

 

Managing a continuous stream of production changes at any time can be challenging for teams and end users. Establishing guidelines for scheduling changes that impact end users helps set clear expectations within the community, the service desk, and supporting teams.

Maintenance Windows

To establish a cadence and rhythm of change in the organization, maintenance windows are used to provide standard times for when changes occur.  There can be multiple windows for changing services to ensure that progress is not hindered by applying fixes and improvements.  When appropriate and necessary, exceptions may be granted to make changes outside of these windows.

The following will be the standard maintenance windows for Normal change types:

 

 

 

 

 

Day of Week	Time of Day	Type of Change
Tuesdays	5 a.m. until 7 a.m.	Standard changes
Wednesday	4 a.m. until 6 a.m.	Standard or Emergency changes
Thursdays	10 a.m. - 5 p.m. 1:15 a.m. - 3:15 a.m.	1st Thursday of Month (S&T DR Site) 3rd Thursday of Month (Hospital Significant/Major)
Fridays	5 a.m. until 7 a.m.	Standard changes
Saturdays	6 p.m. until Midnight	Standard and Major changes
Sundays	Midnight until Noon	Standard and Major changes
Monday-Friday	2 p.m. until 4 p.m.	Standard PeopleSoft Batch Program Changes
Urgent changes may occur at any time with ECAB approval. Customer (non-DoIT) approved changes can be scheduled outside established maintenance windows, however, normal business hours (Mon - Fri, 7 a.m. - 5 p.m.) and peak/normal usage times should be avoided where possible. All other changes must be scheduled to minimize customer impact within an appropriate maintenance window. Systems with least impact times that fall outside the established maintenance windows can be scheduled as such with a documented justification.

 

Blackout Windows

There will be periods of time where services need to be stable, and incidents minimized due to important events or holidays.  Blackout Windows are identified within the TDNext ticketing application.  During these times, there will be no changes allowed to be scheduled.  In the event of an urgent change that must be considered during a blackout window, the Emergency Change process can be followed. 

 

The following will be the standard blackout windows for Normal change types:

• Fall Semester: Blackout starts Sunday of move-in week and goes to the first day of classes.
• Winter Semester: Begins the Sunday before 1^st day of class and goes 1 week to Saturday

For additional help please contact the Change Manager for assistance