DoIT Operational Framework - Section 3.0 - Change Management
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
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 CI2. Create
Technologist creates the Change Record for the planned change3. Submit
Technologist submits the Change Record4. Evaluate
Change Manager reviews the Change Request5. 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 phases6. Implement and Update
Technologist performs the work identified in the Change Record; Notifications done; CMDB updated7. Close CR
Technologist closes the Change Record8. 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
- 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
- Formulate a Work Plan and Back-Out Plan, if necessary
- Perform a preliminary Impact Analysis & Assurance Analysis of the Change on a Configuration Item
- 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
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
- Close the Change Record
- Check Tasks if relevant, Closes
- Update the Change Record
3.2.8 REVIEW
The Change Manager may
- 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.0 CHOOSING WHAT TYPE OF CHANGE REQUEST FOR SUBMISSION
This decision tree can help determine the optimal type of Change Request (CR) to submit.3.3.1 CHANGE REQUEST TYPE
There are 3 types of Change Records
Normal Change Records have 3 Levels
- Level1
- Level2
- 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
Characteristic | Requirement |
Customer & End User Notification | A lead time for notification, or knowledge that service outages can occur during designated Maintenance Window All Normal Level 1 or 2, or Emergency Change Records that impact the normal business operation, including weekends, require that all DoIT Management and Campus Users be notified of the disruption. This includes the Impact and Duration of the change. |
SNCC Sysops/NOC Notification |
Emergency Changes require additional coordination, and some Normal Changes may necessitate SNCC notice when
For SNCC notification methods, see DoIT Operational Framework section 3.3.3 |
Technologist Assurance | Dependent on Change Type. |
Time | Work is done within a Maintenance Window, or outside with Approval |
Submission Lead Time | How much lead time is needed to submit before processed by Change Management |
Approval level | Dependent on Change Type and Level |
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
Characteristic | Requirement |
Customer & End User Notification | If within established, publicly accessible Maintenance Window - As soon as possible on the DoIT Outage Page after Change Approval If outside Maintenance Window - 4 weeks' notice on the DoIT Outage Page after Change Approval |
SNCC Sysops/NOC Notification | System-related Changes: DoIT Operations Support channel (MS Teams)Network-related Changes: Network Operations Team (MS Teams) |
Technologist Assurance | Change Inter-dependency - calendar conflicts understood; Other Change dependencies noted Resource Interdependency - Staff, other IT resources conflicts understood; Other IT resource dependencies noted Experience - Noted |
Time | During Standard, Pre-Established Maintenance Window is desirable, or Alternate with Approval (4 weeks out to allow for Notification) |
Submission Lead Time | No less than 2 business days prior to required approval date |
Approval level | Change Manager submits to the Change Advisory Board (CAB), for CAB approval. |
3.3.1.1.2 Level 2 Changes
Characteristic | Requirement |
Customer & End User Notification | If within established, publicly accessible Maintenance Window - As soon as possible on the DoIT Outage Page after Change Approval If outside Maintenance Window - 2 weeks (COOP 3 or 4) to 4 weeks (COOP 2) notice on the DoIT Outage Page after Change Approval |
SNCC Sysops/NOC Notification | See DoIT Operational Framework section 3.3.3 |
Technologist Assurance | Change Inter-dependency - calendar conflicts understood; Other Change dependencies noted Resource Interdependency - Staff, other IT resources conflicts understood; Other IT resource dependencies noted Experience - Noted |
Time | During Standard, Pre-Established Maintenance Window is desirable, or Alternate with Approval (2 weeks out to allow for Notification) |
Submission Lead Time | No less than 2 business days prior to required approval date |
Approval level | Change Manager approval; Change Advisory Board (CAB) advised only |
3.3.1.1.3 Level 3 Changes
Characteristic | Requirement |
Customer & End User Notification | Service Manager or Team discretion |
SNCC Sysops/NOC Notification | See DoIT Operational Framework section 3.3.3 |
Technologist Assurance | Change Inter-dependency - calendar conflicts understood; Other Change dependencies noted Resource Interdependency - Staff, other IT resources conflicts understood; Other IT resource dependencies noted Experience - Noted |
Time | Within established, publicly accessible Maintenance Window is desirable, or Alternate with Approval |
Submission Lead Time | No less than 2 business days prior to required approval date |
Approval level | Change Manager approval |
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)
Characteristic | Requirement |
Customer & End User Notification | Unnecessary |
SNCC Sysops/NOC Notification | See DoIT Operational Framework section 3.3.3 |
Technologist Assurance | Dependent on Standardization Procedure. |
Time | Dependent on Standardization Procedure. |
Submission CR Lead Time | Dependent on Standardization Procedure. |
Approval level | Dependent on Standardization Procedure. |
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.
Characteristic | Requirement |
Customer & End User Notification | Appears on Outage Page Dictated by circumstance and may include personal contact or other notification methods, i.e., News, TP, campus email, etc. |
SNCC Sysops/NOC Notification | DoIT Operations Support Channel (MS Teams) Phone Email acceptable if no other means available To contact SNCC, use procedures in DoIT KB article #24507 How to Report an Outage |
Technologist Assurance | Dependent on the nature of the Emergency Change |
Time | Dependent on the nature of the Emergency Change |
Submission CR Lead Time | Retroactive possible; Otherwise, Immediate as situation permits |
Approval level | Emergency Change Records are expedited in the following ways:
|
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
STANDARDIZED | EMERGENCY | NORMAL LEVEL 3 |
NORMAL LEVEL 2 |
NORMAL LEVEL 1 | |
In Service's Public Maint Window | No Outage Page posting & formal communication to Stakeholders required | Can be implemented immediately, prefer as much lead time as possible. | No Outage Page posting & formal communication to Stakeholders required | Requires 2-day Public Notice on Outage Page | Requires 2-day Public Notice on Outage Page |
Outside Service's Public Maint Window | No Outage Page posting & formal communication to Stakeholders required | Requires preapproval from a DoIT Manager | No Outage Page posting & formal communication to Stakeholders required | Requires 2-week Public Notice on Outage Page | Requires 4-week Public Notice on Outage Page |
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
Roles | Responsibilities |
Submitter “ usually the Tech, sometimes the PM or Service Lead |
Planning CRs Enters and Submits Change Request. |
Technologists |
Planning CRs
Implementing & Updating CRs
|
Service Level Manager (Service Team Lead) |
Change Mgmt (Non-CR)
|
DoIT Change Manager |
Change Mgmt (Non-CR)
Evaluate CRs
Review completed changes to ensure processes/standards were followed. Identify follow-up actions; direct closure of change records. |
Tech Directors |
Planning CRs
|
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
CR Type | STANDARDIZED | EMERGENCY | NORMAL, LEVEL3 | NORMAL, LEVEL2 | NORMAL, LEVEL1 |
Approval Authority | As prescribed in the services approval process | A DoIT Manager or Change Manager | Change Manager | Change Manager | CAB or Change Manager |
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
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
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:
- 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
- Close the Change Record o Check Tasks if relevant, Closes
- Update the Change Record if relevant
- 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.
- 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.
See Also
- DoIT Operational Framework - Section 1.0 - Overview
- DoIT Operational Framework - Section 2.0 - Glossary of Significant Terms
- DoIT Operational Framework - Section 4.0 - Incident Management
- DoIT Operational Framework - Section 5.0 - Configuration Management
- DoIT Operational Framework – Section 6.0 - Event Management
- Working with the Operational Framework (Policy)
- The DoIT Operational Framework, ITIL & Service Management Contacts at DoIT