1615 PR.01 Information Technology Infrastructure and Application Change Management

Revision Date: 
April 17, 2015

Contents

Overview. 1

CAB Approval Required for ITS Systems. 1

Foundational CAB Policies. 2

Change Types for Change Management 2

Change Submission Priorities. 2

Change Management 2

Release Types. 3

Release Management 3

Deployment Management 4

Overview

  1. During change planning and prior to change implementation and/or release into production environment(s), owners of ITS-managed and ITS-owned configuration items shall contact the Change Advisory Board and advise it of the planned change.
  2. This procedure provides an overview of the change, release and deployment management processes put in place by Information Technology Services (ITS) and used by the Change Advisory Board (CAB). This document may also function as a basic outline for a change management process for system owners of non-ITS-managed configuration items. The official, detailed ITS processes for managing changes, releases and deployments are maintained through Service Now and the Service Now Knowledge Base. Please see:
    1. Change Management
      1. KB0000462          ServiceNow CAB Meeting Notes
      2. KB0000789          ServiceNow change Guide
      3. KB0005371          ServiceNow CAB Guide Lines
      4. KB0005372          ServiceNow Change Process Document
      5. KB0005373          ServiceNow CAB Charter
    2. Release Management
      1. KB0005392       Standard Bi Weekly (BMR) Release
      2. KB0005403       SPOT Release
      3. KB0005406       Maintenance Window Release
      4. KB0005405       Emergency Release
      5. KB0005409       Pre-Approved Release

CAB Approval Required for ITS Systems

  1. No changes to a configuration item may be implemented until approval or an exception from the CAB is received.
  2. Initial contact can be made by contacting the Change Manager changemanager@yale.edu.

Foundational CAB Policies

  1. The Change Owner is ultimately accountable for the success of their respective change.
  2. The approving Change Manager is accountable for the successful execution of the process, as a means to mitigate impact and risk for stakeholders/customers.
  3. Change Management will manage all changes made to the production environment, including the operational test environment. This includes changes implemented by vendors and external organizations.
  4. Effective Risk and Impact Assessment is enforced and is considered the foundation of Change Management.
  5. All customers are informed of changes that affect the Service(s) they receive prior to change implementation.
  6. There is a mechanism to implement URGENT changes to the managed environment with minimum destabilization of that environment.
  7. The number of changes deemed URGENT is reduced to a pre-specified and progressive metric through proper planning.
  8. A CAB exists and the Change Manager is the ultimate decision making authority within the CAB.
  9. A Change implementation plan is required prior to change deployment.
  10. All Service Providers will fulfill their roles in compliance with the Change Management process.
  11. A Request for Change (RFC) should not be approved for implementation unless relevant back-out plans are in place.

Change Types for Change Management

  1. Standard Change - Changes with a standard approach and pre-authorized procedure and/or detailed instructions.
  2. Normal Change
    1. Minor Change - Low impact and risk to the organization,
    2. Significant Change - Medium to high impact or risk to the organization,
    3. Major Change - High impact and high risk to the organization.
  3. Emergency Change - Significant and Major changes that require implementation before the normal CAB review. Emergency changes shall be linked to a specific Incident or Problem ticket and this linkage shall be reflected in the Change ticket.

Change Submission Priorities

  1. Planned Change – The change has been planned for and is submitted prior to lead time criteria for the applicable change type.
  2. Urgent Planned – The change does not require emergency change handling however it has not been submitted within the lead time criteria for the applicable change type.
  3. Urgent Emergency – The change requires immediate escalation and approvals, often as a result of an incident or problem.
  4. Latent - The change has already been executed, either a result of an emergency or to record the details of an unauthorized change.  

Change Management

  1. Request Change
  2. Review & Accept Change
  3. Assess Technical and Business Impact/ Risk
  4. Approve Change for Build
  5. Build and Test Change
  6. Confirm Implementation Schedule and Impact / Risk Review
  7. Approve Change for Implementation
  8. Implement and Validate Change
  9. Close Change
  10. Process Maturity and Evolution (Perpetual State)

Release Types

There are five (5) release management release types:

  • Pre-Approved
  • Standard Maintenance
  • Maintenance Window
  • Spot Release
  • Emergency

Release Management

  1. Request Release
  2. Review & Accept Release
  3. Assess Technical and Business Impact/ Risk
  4. Approve Release for Build
  5. Build and Test Release
  6. Confirm Implementation Schedule and Impact / Risk Review
  7. Approve Release for Implementation
  8. Implement and Validate Release
  9. Close Release

Deployment Management

  1. Request Deployment
  2. Review & Accept Deployment
  3. Assess Technical and Business Impact/ Risk
  4. Approve Deployment for Build
  5. Build and Test Deployment
  6. Confirm Implementation Schedule and Impact / Risk Review
  7. Approve Deployment for Implementation
    1. Technical Approval
    2. Functional Approval
  8. Implement and Validate Deployment
  9. Close Deployment