Change Management is the Process responsible for controlling the life cycle of all Changes. The primary objective of Change Management is to enable beneficial Changes to be made, with minimum disruption to IT Services .

If you have questions, please email Change Management.

Supplemental Reference

• KB article DoIT Operational Framework - Section 2.0 - Glossary of Significant Terms

Section 3.1 - Why Change Management?

All changes to Configuration Items (CIs) may have unintended consequences and introduce risk to service availability, reliability, or performance. Within DoIT's large, complex, interdependent environment, management of these IT changes mitigates operational risk and improves operating efficiency.

Change Management delivers the processes and techniques required to allow DoIT to manage IT change. The Configuration Management Database (CMDB) Is the repository for these CIs.

Goal

Change Management processes and related standards strive to ensure the best possible operational efficiency, service and up-time for DoIT-managed services

Scope

Change Management controls the introduction of change to an IT environment, for example the DoIT Production Infrastructure, via the Change Management Process, which coordinates and schedules changes to systems via Change Requests and tracks Changes via Change Records.

The following activities fall within the scope of Change Management for DoIT-managed services.

• Changes that increase the probability of any customer-perceived or end-user-perceived reduction of service or a service outage must engage the Enterprise Change Management System.
• Changes that are non-customer affecting can be tracked via Enterprise Change Management or by a method designated by DoIT Management.
• Delegated service delivery where service impact is local and sanctioned is outside the scope of this document.

Benefits

Change Management benefits Technologists because it

• Provides greater awareness of changes to other systems which could affect your technological area and the success of your system and service maintenance work
• Enables standardized communications regarding timing and impact of your changes to service and CI Stakeholders and other key people

Change Management benefits Units & Directors because it

• Ensures the best possible operational efficiency, service and up-time for DoIT-managed services.
• Improves communication regarding system updates and maintenance

Change Management benefits DoIT because it

• Helps keep customers aware of work performed on the IT Services they use
• Helps set customers' expectations for planned system downtime
• Helps develop better partnerships with customers of DoIT

Section 3.2 - Change Process

3.2.0 OVERVIEW OF CHANGE MANAGEMENT PROCESS

There are 8 activities of the Change Management Process

1. Plan
Technologist plans the Change to the CI

2. Create
Technologist creates the Change Record for the planned change

3. Submit
Technologist submits the Change Record

4. Evaluate
Change Manager reviews the Change Request

5. Approve
Change Manager or the CAB (for high-impact changes) approve the Change Request; Approver provides feedback to responsible Technologists of the Plan and Create phases

6. Implement and Update
Technologist performs the work identified in the Change Record; Notifications done; CMDB updated

7. Close CR
Technologist closes the Change Record

8. Review
Change Management reviews

These phases are handled differently depending on the Change Type and Level - see Section 3.3.1 CHANGE REQUEST TYPE for more information.

The Roles in the Change Management process include the following. Please see the DoIT Operational Framework section 3.4.1 for the associated responsibilities in the Change Management process:

• Submitter
• Usually the Technologist, but could be Project Manager or Service Lead
• Technologist
• Implementation Manager
• Service Level Manager
• DoIT Change Management
• Tech Directors
• Stakeholders
• May include Change Manager, Management, Technologist relevant to Change, Customer, etc.

Supplemental Reference

• KB article #76225 Change Management Quick Reference

3.2.1 PLAN 

The purpose of the Planning phase is for Submitters to

1. Solicit customer or Service Team input and feedback o DoIT Change Management anticipates that the Submitter has cleared the date and time of the Change with customers and other CI Stakeholders
2. Formulate a Work Plan and Back-Out Plan, if necessary
3. Perform a preliminary Impact Analysis & Assurance Analysis of the Change on a Configuration Item
4. Plan the timing of a Change, based on the Impact Analysis & Assurance Analysis

Supplemental References 

• To avoid conflicts, please check your CR date against dates for existing Planned Service Changes on the published Outages calendars or Combined Calendar
• DoIT Outages
• UW System Outages
• Combined Calendar

3.2.2 CREATE

The purpose of the Creation Phase is to create and record a needed Change to DoIT's IT infrastructure Required information for a CR includes:

• WHAT is being Changed (Configuration Item)
• WHAT work is planned (Details/Plans of the Change & Back-Out Plan)
• WHY is the Change needed (upgrade, migration, etc.)
• WHEN is the Change
• WHO is doing the Change, and WHO needs to know about the Change

A Change Request can be created and withheld from submission. However, because the Change Manager can begin to resolve any possible time conflicts once a CR is submitted, it benefits the Submitter, the Technologists, and the Service Team to submit the CR as soon as a likely date is determined. This CR can be a placeholder CR while details for the Change are being finalized.

Supplemental References

• DoIT Operational Framework section 3.3.0 for a decision tree diagram on which type of Change Request to choose.
• DoIT Operational Framework section 3.3.1 for detailed information on Change Levels and Types
• KB Article #47246: Cloning a Normal or Emergency Change in WiscIT

3.2.3 SUBMIT

A CR is submitted, preferably at least 2 business days prior to required approval date; Lead Time should be based on DoIT Operational Framework section 3.3.2 for the various Change Types and Levels.

Supplemental References

• KB Article #42213 Filing a Normal Change in WiscIT
• DoIT KB Article #44432 WiscIT - Cherwell - Normal Change - When Emails are Sent
• KB Article #29200 Submitting an Emergency Change Request
• KB article #47245 Cloning Normal or Emergency Change Requests

3.2.4 EVALUATE

Change Manager reviews the Change Request and

• Verifies CR information is complete
• Performs Impact Analysis & Assurance Analysis
• Impact Analysis dictates Approval Authority Level and Notification Level
• Assurance Analysis dictates
• The need for Change Management to further investigate the Change and resources available
• Change Notification to include other forums within and without DoIT
• provides feedback to the Plan and Create phases

Supplemental References

• DoIT Operational Framework section 3.5.4.1 for detailed information on the Impact Analysis process and factors
• DoIT Operational Framework section 3.5.4.2 for detailed information on the Assurance Analysis process and factors

3.2.5 APPROVE

3.2.5.1 Responsibility

It is the responsibility of the person/team performing the change to ensure that authorization has been granted.

Approval Authority by CR Type

• The Change Advisory Board (CAB) approves Level 1 CRs or asks a designatee to mark CR as approved.
• The Change Manager approves Normal Level-2 or Normal Level-3 CRs
• The Change Advisory Board (CAB) approves Emergency CRs.
• If the Emergency CR requires urgent response, a DoIT Manager can approve an Emergency CR

3.2.5.2 CR Approval Criteria

A Change Request (CR) is approved if

• there is sufficient notification time and
• no other factors such as a Change Freeze, service Time Frame, or other changes conflict with the Change's schedule.

All CRs are subject to Change Manager scrutiny.

3.2.5.3 CR without Approval

A Change Request (CR) may not be approved. In this case, the CR status may change to

• On Hold 

If more information is needed, the Change Manager will place the Change Request On Hold and contact the Submitter for updates. A Submitter may also request that a CR status be changed to On Hold

• Rejected

The Change Manager will reject the Change Request, give the reason for rejection to the Submitter, and require resubmission if

• Information is incorrect or incomplete, or
• Incorrect forms or templates of the Change tool were used, or
• Change or Change Record bypasses accepted policies.

Supplemental References

• DoIT Operational Framework section 3.5.5 Approval/Authorization for approval matrix

Any person in one of the defined roles in a Change may choose or be required to provide updates to the Change Record. Submitter and/or Assigned Technologist or Workgroup has primary responsibilities both for Change implementation and for updates to the Change Record fields.

The responsible person will

• Update Change Record tasks, as needed
• Fill in Actual Start time to
• Change status to Implementation in Progress
• Fill in Actual Finish date/time to indicate a change of status to Implementation Complete
• Modify Status if needed, when status is On Hold, To Be Approved (Any Date Change after approval requires the CR be cancelled and re-submitted)
• Coordinate any needed modifications to relevant Configuration Items or Service in the CMDB with Configuration Manager
• Select the CR's appropriate Closure Code
• Options: Successful, Rolled Back, Canceled
• Provide Progress Report - as warranted, to describe completion of various steps of the Change Plan, issues encountered, hand-off of responsibility, etc.
• Notify SNCC NOC/SysOps - Changes that are interdependent with other Changes, or that have great resource dependencies, or that occur the same day with multiple other Changes, may necessitate direct communication with the NOC/SysOps. Notification media are listed in section 3.3.3.

The Change Manager has the responsibilities to

• Provide Progress Report - as warranted
• Modify Change Record Status - On Hold, Approved
• Coordinate any needed modifications to relevant Configuration Items or Service in the CMDB with Configuration Manager
• Select the Change Record's appropriate Closure Code
• Options: Successful, Rolled Back, Canceled

Supplemental References

• DoIT Operational Framework section 3.4 for detailed information on the Change Record responsibilities
• DoIT Operational Framework section 3.3.3 for detailed information on Notifying the SNCC NOC/SysOps staff during Changes

3.2.7 CLOSE CR

When implementation is completed, the Technologist will

1. Close the Change Record

• Check Tasks if relevant, Closes
• Update the Change Record

3.2.8 REVIEW

The Change Manager may

1. Review the Change in more detail, as warranted (Changes are not automatically reviewed)

• Are Start/Stop times given?
• Is a CI specified?
• Are there other follow-up issues to be pursued?
• Status = Closed
• Hold aside for CAB review, as warranted

Section 3.3 - Change Requests 

3.3.1 CHANGE REQUEST TYPE

There are 3 types of Change Records

1. Normal
2. Standardized
3. Emergency

Normal Change Records have 3 Levels

1. Level1
2. Level2
3. Level3

Change Records can be used to:

• Register work to be done during a previously established Maintenance Window
• Register work to be done outside these Maintenance Windows for business reasons with customer consent, with specified communication lead times

Characteristics of Changes by Type

Specific characteristics and requirements for all Change Records include

3.3.1.1 Normal Changes

Normal Changes constitute 90% of all CRs processed.

All Normal Changes need at least 2 business days' notice prior to needed approval date. Otherwise, the change should be filed as an Emergency Change.

3.3.1.1.1 Level 1 Changes

3.3.1.1.2 Level 2 Changes

3.3.1.1.3 Level 3 Changes

3.3.1.2 Standardized Changes

Standardized Changes are usually routine and non-disruptive pre-approved changes which follow an agreed-upon procedure. These CRs can be Service Request or possibly Service Maintenance (Service Outage Possible).

The Characteristics of a Standardized Change are

• Low or No Impact/High Assurance - the probable Change outcome is the typical outcome
• Common - the work is so routine it may in some cases be considered a Service Request
• Specific Procedure - whether simple or complex, the instruction set for the work is always the same and well understood
• Always maintains or supplements an existing service, never detracts from Service availability (assuming a Standardized Change-Service Maintenance is performed during a Maintenance Window, see below)

3.3.1.3 Emergency Changes

Emergency Changes are for changes needed quickly to prevent interruption of a service or return functionality to a service.

The DoIT Change Manager is responsible for noting all commitments and conflicts. It is possible for change activities associated with an Emergency Change Record to preempt other scheduled changes.

An Emergency Changes may be needed for restoring service and resolving a service outage, that is, it is spawned from an Incident record, see DoT Operational Framework Incident Management chapter, Section 4.1. An Emergency Change also may be needed to prevent an incident, when a Service Outage is not present yet, that is, it can be spawned from a Change Record.

If it is necessary for the Change to be implemented as soon as possible, a Change Record approval process may occur after the Emergency Change has been implemented. The authorizing manager determines if the change should be done before the Change Record has been though the Approval Process.

Note: Change Requirements may be waived by Management due to circumstance Note: It is the responsibility of the person/team performing the change to ensure that Change authorization has been granted.

3.3.1.4 Expedited Changes

Expedited Change Requests are obsolete as of 6/20/2018.

3.3.2 CHANGE REQUEST SUBMISSION (CR LEAD TIME FOR NOTIFICATION)

Change notification guides the lead time needed for submitting change requests. Change Management requires 2 business days for processing all Change Requests.

Table 3-2. Change Record Submission Lead Times for Notification

Supplemental References

• DoIT KB article #42213 Filing a Normal Change in WiscIT (Cherwell)
• DoIT KB article #29200 WiscIT - Submitting an Emergency Change Request
• DoIT wiki: WiscIT Powered by Cherwell - example CR screenshot
• DoIT Operational Framework section 3.3.3 for detailed information on notifying the SNCC NOC/SysOps staff during Change
• DoIT KB article #44716 When WiscIT sends email notifications
• DoIT KB Article #44432 WiscIT - Cherwell - Normal Change - When Emails are Sent
• DoIT KB article #24507 How to Report an Outage

3.3.3 SNCC SYSOPS/NOC NOTIFICATION METHODS

Technologists implementing changes must inform the SNCC staff before a Change initiates. This notification can be done via

• DoIT Operations Support Channel (MS Teams)

• Network Operations Team (MS Teams) for Network-related Changes

• To contact SNCC for Emergency Changes, use communication media documented in DoIT KB article #24507 Incident/Problem/Outage Management Quick Links and Resources

Supplemental References

• DoIT KB article #91687 DoIT Operations Support Channel - MS Teams
• DoIT KB article #44716 When WiscIT sends email notifications

Section 3.4 - Roles & Responsibilities for Change Management

3.4.1 ROLES AND RESPONSIBILITIES MATRIX

Table 3-1 outlines the Roles and associated Responsibilities of CR processing and overall Change Management.

Table 3-1. Roles and Responsibilities Matrix

Section 3.5 - Change Request Process Details

3.5.4 EVALUATION DETAILS

3.5.4.1 Impact Analysis

Impact Analysis looks at CI and Service relationships and availability. Impact Analysis dictates:

• Approval Level: Change Manager or Change Advisory Board
• Notification Level: Maintenance Window or 2/4-Week Public Notice.

Impact is analyzed by assessing

• Is the CI affected by the Change?
• What dependencies exist, i.e. what other CIs or Services are related to the Changes CI?
• What notifications are necessary for this Change, given the CI, and dependencies? See Section 3.3.2 for Table of Change Record Submission Lead Times.

3.5.4.2 Assurance Analysis

Assurance Analysis looks at the Confidence that a Change can go well. Assurance Analysis dictates

• The need for Change Management to further investigate the Change and resources available
• Change Notification to include other forums within and without DoIT

The Change Manager weighs these factors in the Assurance Analysis phase Does the Technologist have Experience with this Change? Does the work depend on resources aside from those brought to bear by the Technologist/submitter? Are other technologists or 3rd parties needed for the Change? Is the Change dependent on another Change to be successful?

3.5.5 APPROVAL/AUTHORIZATION

In this phase, the Change Manager or CAB (or, in the case of an Emergency Change, a DoIT Manager) approves the Change.

Table 3.5.5: Approval Matrix

3.5.5.1 Process to Standardize a category of Change

A request for change standardization is submitted to the ITSM Team, from any source (PIR, Infrastructure Collaboration, ITSM Team, any Sub-Group, OF Team, Service Team, etc.) Once submitted 1. The ITSM Team delegates the work to the Change Sub-Team for consideration 2. The Change Sub-Team, working with Stakeholders who would be part or have great interest in the particular changes process, considers and makes its Recommendation to the ITSM Team 3. The ITSM Teams recommendation is sent to the Change Advisory Board (CAB) for Approval

3.5.5.2 Process to De-standardization a category of Change

The process to de-standardize a category of Change initiates with a Report of a problem from any source, submitted to the ITSM Team (PIR, Infrastructure Collaboration, ITSM Team, any Sub-Group, OF Team, Service Team, etc.) 1. The ITSM Team delegates the work to the Change Sub-Team for consideration 2. The Change Sub-Team considers De-Standardization and makes its Recommendation to the ITSM Team 3. The ITSM Teams recommendation is sent to the Change Advisory Board (CAB) for Approval

3.5.5.3 Emergency Change Approval Authority

A DoIT Manager will approve Emergency Changes via the Change Management tool or via direct communication with the Change Manager

Supplemental Reference

• KB article #29200: WiscIT - Submitting an Emergency Change

3.5.5.4 Rescheduling a Non-Standardized Change Request

If the Change has been approved when you choose to reschedule it, it will need a new approval.

Supplemental Reference

• KB article #74249 Rescheduling a Non-Standardized Change Request

3.5.5.5 Other Approval Change Statuses

Change Requests may be assigned one of the following statuses:

• Risk Analysis in Process
• For Normal Level 1 or 2 Change Requests, this is a transitional œpending  status while Change Manager solicits CAB Approval or more information regarding Change. The Outage Page will still have a notice posted while CRs are in this Status.
• Rejected 
• If directed by CAB - Management Prerogative.

3.5.6 IMPLEMENTATION & UPDATES

Any person in one of the defined roles in a Change may choose or be required to provide updates.

Primary Responsibilities for updates to the Change Record and implementation of the Change belong to:

1. Submitter and/or Assigned Person or Workgroup

• Update Change tasks, as needed
• Update Actual Start - triggers a change of status to Implementation in Progress
• Update Actual Finish - triggers a change of status to Implementation Complete
• Update on the progress - as warranted, to describe completion of various steps of the Change Plan, issues encountered, hand-off of responsibility, etc.
• Notify SNCC “ Changes that are interdependent with other Changes, or that have great resource dependencies, or that occur the same day with multiple other Changes, may necessitate direct communication with the NOC/Sysops.
• See SNCC Notify for details
• Status - On Hold, To Be Approved (Date Change)
• Configuration Item - Coordinate with Configuration Management any modifications to relevant CI or Service in the CMDB
• Closure Code - Successful, Rolled Back, Canceled
• Change Manager o Update Progress Report - as warranted

• Update Status - On Hold, Approved
• Specify and Link Configuration Item - Coordinate with Configuration Management any modifications to relevant CI or Service
• Update Closure Code - Successful, Canceled, Rejected, Rolled Back

3.5.7 CLOSURE & REVIEW

The Change Manager will

1. Close the Change Record o Check Tasks if relevant, Closes
2. Update the Change Record if relevant
3. Review the Change in more detail, as warranted (Changes are not automatically closed and are subject to review)

• Are Start/Stop times given?
• Is a CI specified?
• Are there other follow-up issues to be pursued?
• Update Status = Closed
• Hold aside for CAB review, as warranted

Section 3.6 - Schedule Management

3.6.1 CHANGE CALENDAR

The Change Calendar contains actual Change Request execution dates and times. The DoIT Change Manager is responsible for ensuring that the Change Calendar is current and accurate. This schedule will reside within the DoIT Change Management application. It is the responsibility of the DoIT Change Manager to disseminate reports, as requested. While the Change Calendar reflects all changes, the DoIT Outage Page provides a view of service-effecting changes in the Change Calendar.

3.6.2 WINDOWS, FREEZES & BREATHING SPACE

3.6.2.1 Maintenance Windows

All Services should have pre-established, regular Maintenance Windows; maintaining and improving IT services will, at times, necessitate a service outage which needs to be communicated to customers. The Maintenance Windows for each service is tracked in the CMDB within the CI for the service.

3.6.2.2 Change Freezes

The Change Manager, DoIT Technologists or DoIT Management may declare a œchange freeze  during which time Changes undergo additional controls. Among the reasons for Change Freezes are: Critical processing that cannot be interrupted is taking place. A critical application or new technology is being implemented. A large problem has surfaced and the blackout is needed for resolution. Standard Change Freeze dates are: Finals period (Fall/Spring) The first two weeks of each semester (Fall/Spring), and Fall University Housing Move-In Halloween period ("FreakFest") Any time during which the Change/Incident Management system itself has a Change-related Service Outage The schedule for periods of upcoming Change Freeze is in KB# 33270 Change Freezes.

3.6.2.3 TimeFrames

In the CMDB, a service can define TimeFrames - one or more time periods used to track non-IT impacts or activities on IT Services. Examples include Housing Move In/Out, Campus Events (Enrollment Periods, Breaks, Final Exam Periods, etc). Changes requested during a services identified TimeFrames will receive additional scrutiny, similarly to Changes requested during a Change Freeze.

3.6.2.4 Breathing Space

Days with many serially-scheduled Changes in the Change Calendar may have a period of 30 minutes "Breathing Space" between the end of 1 Change or set of Changes and the beginning of a new Change or set of Changes. Breathing Space allows for staff, monitoring systems and Change Management to better understand when a Change is complete.

3.6.3 CHANGES WITH SERVICE OUTAGE RUNNING LONG

For Changes with a Service Outage, where the Change will exceed the Planned Finish Time, the Technologist must contact SNCC.

1. SNCC will ask the Technologist:

• Do you plan on the Change going forward, or will the Change be "backed-out"? 
• In either case, how long will the Change take?

        2. SNCC will then:

• Create an Problem with Outage (Unplanned Outage)
• Report to the Duty Manager

3.6.4 DOIT CHANGE STATUS REPORT

The DoIT Change Manager will report as requested on the status of the Change Calendar and the status of the DoIT Outages Page.

Section 3.7 - Supplemental References

• DoIT Operational Framework section 3.3.0 for a decision tree diagram on which type of Change Request to choose.
• DoIT Operational Framework section 3.3.1 for detailed information on Change Levels and Types
• DoIT Operational Framework section 3.3.2 for detailed information on the Lead Time needed for the various Change Types and Levels
• DoIT Operational Framework section 3.3.3 for detailed information on Notifying the SNCC NOC/SysOps staff during Changes
• DoIT Operational Framework section 3.4 for detailed information on the Change Record responsibilities
• DoIT Operational Framework section 3.5.4.1 for detailed information on the Impact Analysis process
• DoIT Operational Framework section 3.5.4.2 for detailed information on the Assurance Analysis process.