RMU IT CHANGE MANAGEMENT PROCEDURE

Change Management Overview
This document will guide the Change Management Process for IT systems and services at RMU. The purpose of the Change Management Process is to ensure that all changes are performed in a consistent, repeatable manner with risks minimized or mitigated as much as possible. The Change Management Process at RMU is based on the Microsoft Operations Framework (MOF) Change and Configuration Service Management Function, version 4. MOF defines a change as:

            The addition, modification, or removal of approved, supported, or baselined hardware, networks, software, applications, environments, systems, desktop builds, or associated             documentation.

Change Management Process Principles
The following section describes how Change Management is deployed and practiced at RMU. Below are outlines of the standards and procedures adopted over time that must frame and guide the process. More detailed descriptions of concepts and guidelines may be found in later sections. 

Basic Concepts

  1. A RFC (Request for Change) triggers the process. 

  2. The RFC becomes a change record that tracks the change through the process. Key events and timeframes are made available to stakeholders so end users are kept informed. At completion, the change is reviewed.

  3. Two key change activities are change prioritization and change categorization.
      ●      Prioritization establishes the order in which changes are considered.
      ●      Categorization examines the impact of the change on the organization.

  4. Approval authority for Minor Changes is delegated to the technical team leader (Director).

  5. For Major and Significant Changes, the IT project manager will propose the change to the Change Control meeting to seek approval for that Change. “Urgent” and “Emergency” changes must pass through pre-approved change models to expedite their path through the process. “Urgent” and “Emergency” changes require the Vice President of Information Technology’s Pre-Approval.

  6. Inputs to the Change Management process:
      ●      A request for Change (RFC)
      ●      (Configuration Information) CI data from Configuration Management
      ●      Change implementation procedures

  7. Process Outputs:
      ●      Detailed and complete change records
      ●      Implemented change
      ●      Change Control Meeting minutes and actions
      ●      Change Management reports
      ●      Information provided to Configuration Management for updates to Configuration Items (CIs)

RMU/MOF Change and Configuration Management Process Flow

Process 1

Baseline the Configuration

Process 2

Initiate the Change

Process 3

Classify the Change

Process 4

Approve and Schedule the Change

Process 5

Develop and Test the Change

Process 6

Release the Change

Process 7

Validate and Review the Change

RMU Implementation Guide
The RMU process must follow the Change and Configuration Management SMF unless a variance has been pre-approved by all IT Management. This section explains how the SMF is implemented at RMU and highlights points for emphasis or deviations from the SMF.

Process 1. Baseline the Configuration
RMU has several configuration management systems (CMS) in place, including Google Sheets, RT, RANCID, PVCS, Team Foundation Server, and Excel worksheets. The MOF states: “One option is to baseline as you make changes so that eventually the entire production configuration is known.” This is the methodology we will follow, with larger projects to baseline systems or components to be undertaken from time to time as workload permits. If no existing CMS exists for the configuration item (CI) involved in a change under consideration, the change requester must create or extend a structured Google Sheet that contains all required information. Appropriate examples of CIs are:

  • a physical or virtual server
  • a network switch, router, or firewall
  • a database instance
  • an application system, possibly involving components on multiple CIs
Configuration baselining is not required for Standard Changes.

Process 2. Initiate the Change
The key step of this process requires that all users must create a Request for Change before any change can be initiated. This is done by creating an RT ticket in the Request for Change queue. Complex RFCs may utilize a Google Doc linked to the RFC ticket in RT.

The most important aspects of the Change must be captured; particularly the justification, scope (CIs and Services involved), users affected, and risks.

Process 3. Classify the Change
Changes are organized into the following categories:

  • Normal. A change that is not an Emergency Change or a Standard Change.  Normal changes are further classified by impact:  
    • Major. A change where the impact on the group could be massive—for example, a departmental or corporate-wide change, or a network-wide or service-wide change.
    • Significant. A change where the effect is widespread, but not massive—for example, a change affecting a group within a department or a specific group of configuration items (CIs), or a single building.
    • Minor. A change affecting small numbers of individuals or CIs—for example, a change to a printer used by a department consisting of just a few members, a single network switch, or an application used by a small number of users.
  • Standard. A change that has been performed before and is part of the operational practice of the business—for example, an update to a user profile, Windows updates, creation of firewall objects and rules, addition of DNS records, password changes, etc.  Standard changes are preapproved and do not need to go through an approval process.  They must be logged or otherwise recorded according to the procedure for the standard change.
  • Emergency. A change that must be implemented as quickly as possible.  An example justification for emergency changes may be:
    • Major incident
    • Critical, exploitable security vulnerability or compromise
    • Urgent business need  

Process 3. Classify the Change
From MOF:
        Every organization should develop a collection of standard changes, ensuring predictability and the efficient use of resources by using a “tried, tested, and true” standard             process for common change requests. This is accomplished by identifying common recurring changes and optimizing their execution. Ideally, 80 percent or more of all                 Operation Phase changes should be standard—this signals a mature change management process.

        A standard change begins as a minor, significant, or major change. After the change has been thoroughly tested, deployed, and validated and the execution steps have                been documented, a change may become standard. Examples of standard changes include desktop refresh, standard software deployment, password reset, and patch                management.

The MOF states: “Effective use of standard changes is important for keeping the process manageable and usable." See this link.

More Change Category Examples
These are typical category assignments. The circumstances surrounding any particular change could trigger a higher or lower category assignment.

Change

Category

Code upgrade on single access switch

Minor

Code upgrade on aggregation switch

Significant

Code upgrade on core or data center switch

Process 4. Approve and Schedule the Change
The RMU Change Control meeting is held on Wednesdays at 10:00am. Requests for changes must be submitted by 5 pm on the Tuesday immediately before the Change control meeting. An RT dashboard will show all change requests waiting for approval. Change initiators or any member may request the presence of others at the Change control meeting to discuss any change. The standing members of the Change control team include the Director/Sr. Director level direct reports of the CIO. The Director, Information Security is the designated Change Manager (CM), and chairs the CAB.

Standard Changes are effectively pre-approved and must only be recorded in an RT ticket, CMS, and/or the appropriate systems change log, depending on the type of the change. Required approvals and appropriate windows for these changes, if applicable, will be defined as part of the Standard Change Procedure.

The approval level required by category of change is shown below:

Category of Change

Approval Required

Minimum Lead Time

Standard

Pre-approved

N/A

Minor

Director

24 hours

Significant

Change Manager (CM)

1 week

Major

Change Advisory Board (CAB)

2 weeks

Minimum Lead Time is the minimum period of time between the Request for Change and the scheduled change.

Approved Changes must be added by the Requestor to the Scheduled Changes Google Calendar.

Process 5. Develop and Test the Change
Major changes warrant a full development and testing process as well as test environments, while Minor changes will typically involve much simpler design and testing.

Development and Testing requirements do not apply to Standard Changes, because the procedures have been extensively tested prior to approval. The Change must, however, still be verified after implementation.

The Directors will monitor updates to in-process RFCs in the Significant and Major categories. When the Change is deemed ready for release, final approval for release will be given. This corresponds to the Release Readiness Management Review (MR) step in the Deliver Phase of a larger solution.

Process 6. Release the Change
This process is the implementation or deployment of the change into the production environment. After release, the following steps are performed:

  1. Stabilize the change, which means that all monitoring systems report normal status and there are no unresolved user issues.
  2. Obtain final customer approval.
  3. Document and communicate the released Change.
  4. Transfer responsibility to operations and support teams.  At RMU, this primarily means that the Service Desk has been trained on the Change and is able to take over customer questions from the project team.
  5. RT must not be closed until all appropriate documentation is complete and approved.

Process 7. Validate and Review the Change
The key output of this process completes the Post-Implementation Review (PIR) component of the RFC. At this point, the RFC is closed. The scope of the data gathered and reported in the PIR depends on the magnitude and complexity of the change.

After all final reviews and documentation are completed, the RFC is officially closed.