IT Change Management process

 

Purpose

Ensure that all changes to University of Delaware IT services and infrastructure are recorded, assessed, approved, implemented, and reviewed in a controlled manner to minimize disruption and risk.

Scope

This process applies to all changes to the production IT environment, including infrastructure, applications, systems, and services.  This process also covers changes to non-production environments if the potential risk of impact to the user community is high.  

When is a Change needed?

Changes should be logged for any activities that will functionally alter the configuration or state of a Production system.  This includes (but may not be limited to) servers, network infrastructure, and databases.   

 

Additionally, a change should be logged for any modifications in non-production environments that will potentially affect the operations of a team or multiple teams.  For example, if a college is utilizing a non-production environment to develop new functionality but the servers need to be upgraded, a change should be logged to provide visibility to those utilizing the system.    

Activities that don’t need Change tickets

Some activities do not need change tickets submitted, due to  incredibly low risk, administrative work, or various other reasons.  Examples of these activities are:

 

• Server Restarts with no code/configuration changes and redundancy in place.

• Changes for a single user, including passwords or computer configuration changes (TDX tickets should still be logged for these issues).

• Changes within an application (GUI updates, functionality within the application, etc)

  • These changes should have a change ticket associated for tracking, but is not required from a risk perspective.

• Adding server or database storage that doesn’t require a server restart.

• Reindexing or creating new indexes for a database that won’t require a restart.

• Updating intents within an AI agent/bot

 

If you aren’t sure whether an activity needs an associated change ticket, it’s better to submit one to cover the work being performed.  Feel free to contact the Change Management Team for any questions or concerns.  

 

Change Categories

Normal Change

• Definition: A change that is not pre-approved and requires full assessment and approval by the Change Manager.

• Lead Time: Two business days before Change Control Review.

• Examples: Server upgrades, system patching with downtime, firewall rule changes.

• Approval Path: Present in Change Control Review Meeting

Emergency Change

• Definition: A change that must be implemented immediately to resolve a critical incident or security vulnerability.

• Lead Time: Immediate.

• Examples: Fixing a production outage, zero-day vulnerability patch.

• Approval Path: Review by UDIT-Operations Zoom chat

Retroactive Emergency Changes

In some situations, a change needs to be made immediately to help mitigate impact or prevent imminent impact from occurring.  It is recommended to pursue an Emergency Change for this work, however sometimes time is of the essence and awaiting approval could cause significant impact.  In these cases, the change may be implemented without a pre-approved change record.

 

The Implementer should notify the IT Operations chat in Zoom to let them know what the change will be and why it needs to be implemented immediately.  Following the completion/validation of the change, it is the responsibility of the implementer to submit a followup retroactive emergency change once the issue has been resolved.  The change can be reviewed in the next scheduled Change Control meeting.

 

 

Roles and Responsibilities

Role	Responsibility
Change Requester	Submits and updates change records.   Can also be the Implementer.
Implementer	Executes the change per approved plan.   Can also be the Change Requester.
Change Manager	Reviews all change requests, facilitates Change Control Review meetings, ensures process adherence/maturation.

 

 

Change Lifecycle

Submission

• Change Requester logs a change in TDX-Client.
   

Peer Review and Assessment

• Implementer will review the change and ensure that the details are clear, the implementation and backout plans are documented, and the success criteria is understood.  If there are any discrepancies, these should be discussed with the Change Requester prior to reviewing the ticket at the Change Control Review meeting.

Implementation

• Must begin after the approved Start Date & Time on the approved change

• Implementer must follow the documented implementation plan.

• If the change takes longer than the approved timeframe:

  • The Implementer should notify the IT Operations chat that the change is going to extend beyond the End Date & Time that was agreed upon.

 

 

Change Control Review Meeting Structure

• Frequency: Weekly, Wednesdays at 9:30 AM ET
   

• Attendees: Change Management Team, Service Owners, Technical SMEs, Business Stakeholders as needed.  

While there will be a core team that meets weekly, Requesters and Implementers will be invited on an as-needed basis to discuss upcoming changes.
 

• Agenda:
  The meeting will be conducted by the Change Management team.  The standard agenda is as follows:

  • Review each pending change occurring within the next seven days.  Implementer or representative of the Implementer’s team should present a short summary of the work being done and be able to answer questions from the audience.

  • Briefly read over the completed changes from the past seven days.

  • Briefly review upcoming changes beyond the next seven days.

 

Lead Times

Change Type	Lead Time
Normal	Submitted at least 2 business days before CAB
Emergency	Approval ASAP via UDIT-Operations chat.  Should be submitted/approved retroactively if needed to mitigate the impact of a major incident.

 

Metrics and Reporting (to be developed)

• % of successful changes

• % of changes with incidents

• % of Emergency vs. Normal changes

• Change volume by category/type/department