To create a change or to review existing changes, see ITS Change Management.
Change Management Operating Guidelines
Purpose, Process, and Objective
The purpose of Change Management (CM) is to ensure that an effective change management process is followed for production environments. The Change Management process provides a standardized method to efficiently execute change.
Change management is a methodology used to track changes through the change cycle. It is used for IT production systems. This method ensures that the technicians did due diligence in testing the change, documenting, having a backout plan if necessary, and assessing the impact on customers and possible conflict with other changes or systems. This process also holds Leads and CAB members (Service managers) accountable for reviewing the changes, verifying there are no conflicts with their service, proper communication was provided, and notice was posted to the calendar and ITStatus if necessary. Once the change has been implemented, the technician needs to update the Change Order (CO) indicating if it was successful or not. This helps to create the historical information to hopefully avoid repeating unsuccessful changes.
Changes where the impact on the customer are unclear are also submitted through the change management process for better visibility, impact analysis, and communication.
The Change Management process is a structured approach that involves the following:
Recording
Evaluation
Authorization
Planning
Testing
Communication
Documentation
Implementation
Review
Through adherence to this process, CM can achieve its overarching objective to facilitate successful changes while minimizing risk and impact on the University. As the stewards of changes to IT systems at UConn, CM is also responsible for continually evaluating the success of and making informed improvements to the process and tool.
Roles and Responsibilities
ITS departments vary greatly in size and scope of services provided. For this reason, an ITS employee may have multiple roles in the change management process.
Implementation
Technician – A Technician’s role is to implement the change and document any issues that have occurred. Technicians report to and require functional approval from a Team Leader.
Team Leader – ITS Team Leads are responsible for overseeing the Technicians' work and functionally approving change requests.
Oversight
Change Advisory Board (CAB) – The CAB is comprised primarily of Team Leaders and Service Managers within ITS. The members have a clear understanding of services and processes across a wide range of stakeholders’ business needs. They represent their areas and the best interests of IT service stakeholders.
Service Manager – A Service Manager is responsible for determining what changes are required to a system, determining the impact, and providing a backout plan if necessary. They are the subject matter expert of a service or application. Service Managers are members of the Change Advisory Board (CAB).
Change Manager – A Change Manager’s role is to oversee the change process from start to finish. Change Managers are not subject matter experts and are not directly involved in implementing the change, but they ensure that proper change procedures are followed.
Change Management Requests
ITS staff and service managers can create change requests through Jira. The ITS Change Management project in Jira is for raising requests to be reviewed by the Change Administration Board (CAB) and includes a pre-built form to fill out every time a change management request is raised.
To follow the workflow of a change request, click Raise a request.
Change Types
The sections below describe different types of change management requests.
Request Types | Description |
|---|---|
Expedited Change | Used to address a Break/Fix, an unplanned change based on a customer's request, vendor availability, or degradation of service. |
Standard Change | Change that is low risk, has little to no impact, and is of routine nature. |
Non-Standard Change | Often non-trivial changes to systems, services, and infrastructure. Require communication to end-users or the campus community and may require internal and external planning, assessment, authorization, CAB review, and scheduling before implementation. |
Firewall Change | Firewall Changes are a subset of Standard changes used for routine firewall alterations. This change type follows the Standard Change workflow, automatically sets fields related to impact, and includes additional prompts for Firewall specific information. Firewall Changes require team lead approval but do not require CAB approval. Changes to the firewall that will have significant impacts on major services should be planned and completed as Non-Standard Changes. |
Standard
Standard changes have a very low risk and a predictable outcome. They are relatively common, follow a procedure or work instruction, and require minimal communication.
Standard changes only require approval from the assignee’s supervisor. CAB approval is not needed.
Non-Standard
Non-standard changes are often non-trivial changes to services, processes, and infrastructure. The change may have a significant impact or effect on a critical service. The change requires communications to end-users or the campus community and must allow for internal and external planning.
Non-standard changes require functional approval from the assignee's Team Lead as well as CAB approval. See the timeline below.
Expedite
Expedite Changes are used to address a break/fix or an unplanned change based on a customer’s request, vendor availability, or degradation of service. A notification is sent to CAB and eCAB. The Expedite Change may be documented after the problem has been resolved and may be linked to an issue or global issue ticket.
Expedite changes should not be used due to a lack of planning. Expedited changes do not require team lead functional approval in Jira; however, verbal approval should be obtained when time permits.
Complete the form. All RFCs that alter production configurations or programs need to have been tested in a non-production environment and include documented procedures to regress the change via a set of well-understood back-out procedures.
If this is not possible, the Functional Approver must indicate the reason why such practices are bypassed.
The Approvers field is for your Team Lead. While approval is not required for Expedite Changes, adding your Team Lead will allow them to receive notifications for the ticket. To enter the Team Lead, enter their email address or lastname, firstname.
Additional technicians are any technicians who will be working on or must remain updated about the change order. To enter the additional technicians enter their email address or lastname, firstname. They will be added as Watchers to the ticket.
At the bottom of the form, you can choose to publish a notice on the IT Status page.
Choose Yes from the dropdown for Post to IT Status.
Enter a brief description of the change. This description will be displayed when a site visitor clicks on the link for the change.
When you are writing a message for the IT Status page,
Keep it concise and focused.
Identify the issue, who it impacts, and how it affects them.
For the Services Impacted field, select the appropriate service. If multiple services are affected, you can select each affected service. To do so,
Hit Ctrl + click (for Windows) or Command + click (for macOS).
If the service is not listed, choose Other.
Enter the service in the Service Impacted (Other) field below.
Click Create to complete the request.
Firewall Change
Firewall Changes are a subset of Standard changes used for routine firewall alterations. This change type follows the Standard Change workflow, automatically sets fields related to impact, and includes additional prompts for Firewall specific information. Firewall Changes require team lead approval but do not require CAB approval. Changes to the firewall that will have significant impacts on major services should be planned and completed as Non-Standard Changes.
If you choose the wrong Change type, you may move it to the correct type.
Click the Actions menu. Click the three dots in the upper right to expand the drop-down menu.
Select Move.
Choose the appropriate New Issue Type.
Click Next.
You will see Current Status and New Status.
There is a drop menu where you can choose the New Status of the issue type you chose.
Click Next.
Non-Standard Timeline and Review Process
Non-Standard changes must be approved by the CAB members prior to implementation. The request for change must be completed and submitted with any required information attached. The CAB receives email notification once a request has been functionally approved.
Non-Standard changes must be functionally approved by the requestor's lead/supervisor prior to escalating to the CAB.
The CAB receives a weekly agenda on Tuesdays at 10:00 am of all changes submitted for CAB approval during the prior seven days.
The CAB members have until 3:00 pm Tuesday to update the change order of any concerns or conflicts with other changes.
The Change Managers will review comments made to change orders and act as a liaison for all parties involved or approve any changes that have no concerns/comments.
The assignee is notified of the approval and is responsible for Tuesday's 10:00 am report.
Considerations when Reviewing the Agenda
Approve or reject proposed Non-Standard RFCs.
Address any calendar conflicts and negotiate a change window (date/time).
Communication to stakeholders and the University community.
Allow others time to plan for the change as an assignee or a stakeholder.
Expedite Changes: justified or lack of planning?
Unplanned Outages: causes; submission of RFC?
POST-IMPLEMENTATION REVIEW
Review of unsuccessful changes.
Changes related to Unplanned Outages.
Issues and lessons learned are documented for future changes.
Change Advisory Board Members
The Change Advisory Board (CAB) membership is comprised primarily of Team Leaders and ITS Managers within ITS. The members have a clear understanding of services and processes across a wide range of stakeholders’ business needs. They represent their areas and the best interests of IT service stakeholders.
Joshua Bartlett
Chris Bernard
Kevin Brown
Josh Boggis
Andre Corsini
Griffin Freiberg
Steve Fletcher
Matt Grimm
Haleh Ghaemolsabahi
Jason Hamley
Jessica Henderson
Dhanoop Jose
John Khairallah
Les Martin
Noel McAvoy
Gil Milone
Rob Morrell
Ann Nunes
Mike Oatley
Keith Parks
Brett Paulson
David Plamondon
Catherine Rhodes
Rich Ritchie
Zach Robert
Mitch Saba
Chris Tarricone
Hengameh Vosough
Michael Williams
John Wrynn
Yi Zhang
Emergency CAB (eCAB)
Emergency CAB (eCAB) is composed of these Directors:
Haleh Ghaemolsabahi
Jila Kazerounian
Mike Williams
Josh Boggis
Christopher Bernard
Roles and Responsibilities
Reporter / Assignees
Submit requests to make changes to a production environment.
Ensure that all required documentation (e.g., testing, back-out plans, communication, etc.) has been completed.
View the Events Calendar of Changes to ensure that there are no conflicts.
Follow up with the supervisor for Functional Approval (including Standard Changes).
Do not implement change without prior approval.
Once implementation is complete, update the status of CO accordingly.
If there are issues with implementation, change the status to “Issues with Implementation.” Indicate what the issues were and what the plan is for re-implementation or cancellation. The status will then change to “Post-Implementation Review” and be reviewed by CAB on the following Tuesday.
Link issues with changes.
Functional Approver
Team Lead or Manager is responsible for:
Reviewing the justification for the change to ensure that the work being performed is necessary.
Reviewing the date and time of the change to ensure that it conforms to the Non-Standard Change Timeline.
Determining if the change meets the specified requirements (Test Plan, Back-Out Plan, Calendar, Verbiage for IT Status, Communication, etc.) and ensuring that there is no conflict with other changes.
Verifying that all criteria within the ticket are complete and accurate.
Indicating approval of the change by changing the status to Functional Approval.
Change Manager
The Change Manager is responsible for:
Reviewing all COs prior to the agenda going out on Tuesday at 10:00 am.
Communicating with the Requestor/Assignee/Stakeholders, notifying them of any quality issues.
Scheduling emergency meetings when applicable.
Managing the scheduling of CM and other related meetings.
Escalating CO to the eCAB for the resolution of any conflicts.
Preparing Post-Implementation Review data for CM review when applicable.
CAB Members
CAB Members are responsible for:
Reviewing and assessing COs for risk, impact, and schedule.
Representing and speaking to all COs from their area.
Improving day-to-day operation (i.e., planned outages, support readiness).
Facilitating a Post-Implementation Review change review when necessary.
Reviewing Expedite Changes.
Assisting with establishing guidelines related to Risks, Impact, Change Types, and Unplanned Outages.
Identifying the appropriate change window based upon business activity, length of time needed, vendor availability, risk, etc.
Attempting to remediate outstanding quality issues.
Approving Non-Standard Changes prior to implementation.
Reviewing Expedite Changes for proper planning, testing, communication, backout plan.
Reviewing Post-Implementation Changes.
Communications
All phases of the CM process are communicated through email, Jira Service Desk, ITStatus, and the Events Calendar. Communication occurs throughout the Change process.
IT Status Page
Planned Changes and Notices can be found on the IT System Status page.
Notices should be posted when the change is expected to cause an outage or impact users.
It is the Technician's (Reporter's) responsibility to add the verbiage to the change order for the information on the IT Status page.
Events Calendar
All changes will be posted to the Events Calendar upon being functionally approved. The Summary, Description, and Change Start Date fields will be used to generate an event. Requestors and Assignees should be aware of the public-facing nature of these fields and include only relevant information.
Roles
Assignee
The Assignee is automatically notified through email whenever a status change takes place in JIRA (i.e., functional approval, CAB approved).
Team Lead
The Team Lead / Manager is notified when approval of an RFC is required.
Change Managers
Change Managers get notifications of all status changes in Jira.
CAB Members
CAB members are notified when a Non-Standard RFC is Functionally Approved, Expedite RFC is submitted, or a Post Implementation is required. The CAB also receives a weekly report of all changes for review (Non-Standard, Expedite, and Post-implementation) on Tuesdays at 10:00 am.
eCAB
eCAB is notified of Non-Standard and Expedite Changes.
Additional Support
You can reach out to the following individuals for questions pertaining to this document:
Keith Parks, Change Manager, Service Management
(860) 486 6676
Email: keith@uconn.edu
Andre Corsini
(860) 486-3372
Email: andre.corsini@uconn.edu