DoIT Operational Framework - Section 3.0 - Change Management

Change Management is the Process responsible for controlling the lifecycle 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 If you have questions, please email Change Management. Supplemental Reference: • KB article DoIT Operational Framework - Section 2.0 - Glossary of Significant Terms

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

Change-Request-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

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 

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

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

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

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

3.2.6 IMPLEMENT & UPDATE

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.0 CHOOSING WHAT TYPE OF CHANGE REQUEST FOR SUBMISSION

This decision tree can help determine the optimal type of Change Request (CR) to submit.

Change Request Choice - Decision Tree

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

 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

  • multiple concurrent or serial Changes are occurring. See section 3.6.3.3 "Breathing Space"; or
  • work is registered via a group's specific, management-sanctioned change management system

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:
  • Preventative - Before Incident (Service Outage not present) -Change Manager - the Change Manager or proxy must authorize prior to implementation; CAB notified
  • Restorative - After Incident (Resolve Service Outage) Any DoIT Manager - A DoIT manager or director must authorize prior to implementation

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

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

Supplemental References

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

  • Identify needed changes during administration and security reviews.
  • Identify anomalies that may indicate the need for change.
  • Prepare & Maintain Change Plan,
    • Including a back-out plan.
    • Identify the availability of needed staff and resources to perform the change.
    • Perform change plan testing before and after change implementation, as applicable.
    • Provide technical leadership.
    • Evaluate security, disaster recovery, and other technical impacts.
  • Identify and Communicate
    • the technical risks to the change manager/change approver.
    • the impact of the Change to the DoIT leadership.
  • Seek approval from appropriate group manager or change manager for all changes (per standards above).
  • Maintain technical support response documentation.
  • Often assumes the role of Submitter.

Implementing & Updating CRs

  • Perform change plan testing before and after change implementation, as applicable.
  • Perform changes with or without the help of SNCC.
  • Invoke Remediation plan, if appropriate.
  • Uphold DoITs change standards and process.
  • Communicate change start to SNCC in service support, and be aware of any change freezes in place
Service Level Manager (Service Team Lead)

Change Mgmt (Non-CR)

  • Focus on providing high-quality DoIT infrastructure services with a particular customer.
  • Understand the complex relationships between inter-dependent and supporting services.
  • Set up service level agreements that function coherently, and also monitor the targets within these agreements.
DoIT Change Manager

Change Mgmt (Non-CR)

  • Enforce process and standards, and work to improve process.
  • Analyze the effectiveness of the change process.
  • Identify and lead implementation of necessary improvements.
  • Ensure procedures, tools, and documentation is updated.
  • Lead integration of change management process with other processes.
  • Update DoIT management on the state of change management.
  • Assure there is a Change Record for every Change Request
CRs 
Evaluate CRs
  • Provide business Impact Analysis of a Change.
  • Provide business Impact Analysis of any incident resulting from this change.
  • Confirm the availability of needed staff and resources to perform the change (special attention may be given to holidays and other periods for which resources and staff may be more difficult to leverage).
 Approve CRs
  • Approve changes.
  • Forward necessary Approvals to the SEO Director and the Tech Directors.
  • Identify additional approvers, as appropriate for higher-risk changes.
  • Identify potential time conflicts during which multiple changes may be planned.
  • Review change plan and ensure its adherence to standards.
  • Ensure Public Notification is completed according to DoIT change standards.
Close & Review CRs
Review completed changes to ensure processes/standards were followed. Identify follow-up actions; direct closure of change records.
Tech Directors

Planning CRs

  • DoIT management team responsible for assessing, authorizing and scheduling both Level 1, 2 and Emergency Change Requests requiring additional discussion which are brought forth by the DoIT Change Manager.
  • Responsible for preparing for, attending reviews and following up on issues involving their areas.
  • Possess key expertise necessary for ensuring the Change Requests affecting their areas are planned, tested, and implemented correctly.
  • Must be available on short notice due to importance of implementing the change quickly.
  • Assign situational manager if one has not been identified already.

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:

  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.
    • 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.

    See Also:



    Keywords:OpFram OF Full version operational framework print version entire section itil infrastructure technology infrastructure library change freeze   Doc ID:8942
    Owner:Andy B.Group:DoIT IT Service Management
    Created:2009-01-27 19:00 CDTUpdated:2022-06-07 12:10 CDT
    Sites:DCTeam, DoIT Continuity of Operations Plan (COOP), DoIT Help Desk, DoIT IT Service Management, DoIT Staff, Network Services, Systems & Network Control Center, Systems Engineering, Systems Engineering and Operations
    Feedback:  0   0