Approver(s):

Executive Council

Authorizes Release:

Vice President for Information Services

Responsible Area:

Information Services

Review Cycle:

Annually or as required

Last Review:

October 2023

Related Policies and Additional References:

Information Services Systems Change Management

Purpose

Change management refers to a formal process for making changes to IS (Information Services) services or systems. The goal of change management is to increase awareness and understanding of proposed changes across an organization and ensure that all changes are made in a thoughtful way that minimizes disruption to services and customers. Change management includes the following steps:

  • Planning: Plan the change, including the implementation design, scheduling, communication plan, testing plan, and rollback plan.
  • Evaluation: Evaluate the change, including determining the priority level of the service and the risk of the proposed change; determine the change type and the change process to use.
  • Testing: Change is thoroughly tested in to verify the impact change will have on overall system functionality.
  • Review: Review the Change Plan with peers and/or the Change Advisory Board as appropriate for the change type.
  • Documentation: Document the change and any review and approval information.
  • Approval: Obtain management’s approval of the Change Plan as needed.
  • Communication: Communicate about changes with the appropriate parties.
  • Implementation: Implement the change.
  • Post-change review: Review the change with an eye for future improvements.

Scope

This policy applies to all changes to IS services and systems provided by St Mary’s University Information Services. The primary functional components covered in the Change Management process include:

Hardware – Installation, modification, removal, or relocation of servers or network-related equipment.

Software – Installation, patching, upgrade, or removal of software products, including operating systems, integrations between systems, third-party applications, authentication to AD (Active Directory), and internally developed packages and utilities.

Database – Changes to databases or files such as major upgrades, additions, reorganization, and major maintenance.

Application – Application changes being promoted to production, as well as the integration of new application systems and the removal of obsolete elements.

Changes to major systems configuration for conflict between integrations.

Scheduled Changes – Requests for creation, deletion, or revision to job schedules, backup schedules, or other regularly scheduled jobs managed by the IS Units.

Telephony – Installation, modification, de-installation, or relocation of PBX/VOIP equipment and services.

Classroom Technology – Any modification or relocation of desktop equipment and services for users or classroom labs.

Changes made to non-priority IS components – such as systems that are not yet in production, development environments or testing environments – are outside the scope of this policy.

Policy

All changes to IS services and systems must follow a standard process to ensure appropriate planning and execution.

Changes will be categorized as Standard change, Significant change, or Emergency change.

Appropriate processes and levels of review shall be applied to each type of change commensurate with the potential of the change to disrupt university operations.

It is the responsibility of the IS unit Director to ensure that all areas under their direction have followed the documented process.

Minimum Standards

  1. All changes must follow a process of planning, evaluation, review, approval, and documentation.
  2. All changes deemed Significant must be presented to the Change Advisory Board (CAB) for review and approval through the Request for Change.
  3. All changes deemed Emergency must be presented to the Emergency Change Advisory Board (ECAB) for input and advice unless time constraints require that changes be made prior to submission.
  4. Documentation of Significant or Emergency changes must be made in a Request for Change that is stored in SharePoint so that coordination of changes across the organization can be managed appropriately. This documentation must occur in a timely manner post change.
  5. Documentation of Standard changes must be done in a Request for Change that can be audited for process improvement and root cause diagnosis.

Section A – Types of Changes

Types of Changes

There are three types of changes based on approvals needed through the change management process.

  1. Standard Change – A low-risk change with well-understood outcomes that is regularly made during business. A Standard change follows a pre-determined process, is pre-approved by change management processes, and may be made at the discretion of an individual employee, provided it has been defined as Standard per the Change Management assessment process.
  2. Significant Change – A Significant change is one that has medium to high risk for critical services, involves less understood risks, has less predictable outcomes, and/or is a change that is not regularly made while business. Because of the ability to affect downstream or upstream services, any proposed Significant change must be reviewed by the Change Advisory Board and authorized by the Change Authority.
  3. Emergency Change Is significant change but must be executed with utmost urgency. There may be fewer people involved in the change management process review, and the change assessment may involve fewer steps. However, any Emergency change must still be authorized by the Change Authority, even in cases where the Change Advisory Board cannot review the change in advance.

Section B – Risk Assessment

Risk and Change Type Matrix

How to use this matrix:

First, determine the priority level of the component or service. Then assess the risk of the proposed change – low, medium, or high. The matrix shows whether the type of change is then Standard or Significant. (Note: an emergency change is the same as a significant change, but with an expedited timeline.)

For example: A high risk change to a priority 1 IS service (or IS component) is a significant change. A low-risk change to a priority 3 service is a standard change. A medium risk change to a priority 2 service may be standard or significant.

RISKLowMedHigh/Guaranteed
Priority 1 Service/System 
Crosses functional boundaries, serving the business functionality of many units. It is critical to the ability of the University to meet its business and regulatory obligations, support the delivery of education, or administer research.  It has strategic value to the campus such that encouragement of widespread use is desirable.  
StandardSignificant or EmergencySignificant or Emergency
Priority 2 Service/System 
The system is a feeder to Priority 1 systems; or is a system that does not cross functional boundaries but is still critical to the ability of the University to meet its business and regulatory obligation. 
StandardStandard
or
Significant
or
Emergency
Standard
or
Significant
or
Emergency
Priority 3 Service/System  
Any departmental system that supports the internal operations of any department or departmental function and does not cross functional boundaries.  
StandardStandardStandard
Risk and Change type Matrix.

Sample Priority, Risk and Change Type Assessment

What is the Priority Level of the service? 

See the list of IS Components, or the “Risk and Change Type Matrix,” to determine priority of the service.  

What is the risk associated with the change?  

To calculate risk, consider assurance (our confidence that the change will go as planned) and potential negative impact on services from a customer perspective. Then take the combined score to assign a risk score.  

Assurance Calculation: 

YesNo
Have we made this change before? Risk +0Risk +1
Is the change simple to make? Risk +0Risk +1
Do we have a clear understanding of everything the change will do? Risk +0Risk +1
Assurance Calculation

Impact Calculation: 

NoYes
Will this change be noticeable to customers? Risk +0Risk +1
Could this change impact on other services or systems? Risk +0Risk +1
Could this change result in an extended service interruption if it goes badly? Risk +0Risk +1
Impact Calculation

Change Type: 

This is a combination of priority and the overall risk score. 

Risk Score 1-2 LowRisk Score 3-4 MediumRisk Score 5-6 High
Priority 1StandardSignificantSignificant
Priority 2StandardStandard or SignificantSignificant
Priority 3StandardStandardStandard
Change Type

Section C – Change Management Roles

Change Advisory Board (CAB)

The members of the Change Advisory Board (Please refer to RFC – Change Advisory Board Membership) provide a due diligence readiness assessment and advice about the timing for any change requests (CR) that are referred to it for review. This assessment should ensure that all changes to the IS environment are carefully considered to minimize the impact on campus users and existing services or systems.  

CAB members are responsible for:  

  • Thoroughly reviewing all change requests, ensuring that they:   
    • Have undergone proper planning and testing  
    • Are planned to ensure the lowest possible risk to services and systems  
    • Are coordinated so changes do not impact each other  
    • Are coordinated with the campus calendar to avoid times of high impact for affected services or systems 
  • Providing guidance regarding any additional measures that should be considered prior to the change 

Any decision to move forward with a CR should include an advisory review by the CAB in advance for Significant changes and after the fact for Emergency changes.  

Section D – Process Examples

Change Plan Documentation

All changes, evaluations and approvals will be documented to allow customers to understand what has changed, the reason the change was implemented and the process that was used to make a change. The following details will be logged for each change and are found in the Request for Change (RFC). 

RFC must be submitted for review two weeks prior to the monthly maintenance window.

Emergency RFC’s will be submitted in a timely manner and may occur post change, an e-mail notification is required from the ECAB membership to identify the change.

Request for Change (RFC)

  • All Significant and Emergency changes are submitted on an RFC  
  • Standard changes should also be submitted on an RFC
  • An RFC should include:  
    • Name
    • Requestor
    • Dates to be performed
    • Priority
    • Reason for change
    • Description of change
    • Pre-Change Testing
    • Risk
    • Work Plan
    • Communication Plan
    • Post Change Test Plan  
    • Back-out contingencies  
    • CAB review documentation  
    • Indication of approval by manager or director  
    • Post Change summary including successful or unsuccessful determination, related incidents, rollbacks, and business impacts.  

Definitions

Definitions adapted from Information Technology Infrastructure Library (ITIL).  

Assurance – The level of confidence that the change will go as planned and is determined by experience and complexity.

Change – The addition, modification, or removal of approved, supported, or baselined hardware, network, software, application, environment, system, or associated documentation.

Change Advisory Board – A group of people who can advise on change management and the implementation of these changes.

Change Control – The procedure to ensure that all changes are controlled, including the submission, analysis, decision making, approval, implementation, and post-implementation of the change.

Change History – Auditable information that records, for example, what was done, when it was done, by whom and why.

Change Management – Process of controlling changes to the infrastructure or any aspect of services in a controlled manner, enabling approved changes with minimum disruption.

Request for Change (RFC) – The compilation of changes described by the service owner that will affect existing services. Submitted for each change.

Emergency Change – This is a significant change but must be executed with utmost urgency. (See “Section A – Types of Changes” for more information.)

Impact – Determined by potential disruption to customers and dependent systems.

IT Component – A system, device, application, or document that is part of an IS service or system.

IT Service – An IS service or system is a customer-oriented offering and/or consumption of a technology-based transaction. 

Significant Change – A change with fewer well-known risks or less predictable outcomes, and/or a change that is not regularly made during business. (See “Section A – Types of Changes” for more information.)

Peer – Another IS professional that can review a change and understand the technical elements involved.  

Process Log – A central repository of all Significant and Emergency changes that documents the process followed for a particular change. The purpose of the process log is to ensure that high-impact changes have been carefully considered and to serve as a basis for process improvement when changes do not go as planned.

Risk – Is determined by a combination of the relative assurance that a change will happen as expected and the potential impact of a change should it not go as expected.

Standard Change – A change with readily known risks that is regularly made during business and whose outcomes are predictable. (See “Section A – Types of Changes” for more information.)

Back to top