2.125.2 Change Management Process

Manual Transmittal

October 21, 2022

Purpose

(1) This transmits revised IRM 2.125.2 Change Management Process.

Material Changes

(1) Revised to satisfy IRM internal control requirements.

Effect on Other Documents

IRM 2.125.2 dated September 24, 2018 is superseded.

Audience

The Change Management Process is applicable to all Information Technology (IT) organizations, contractors, and other stakeholders having responsibility for managing change and control of the IT infrastructure.

Effective Date

(10-21-2022)

Nancy Sieger
Chief Information Officer

Program Scope and Objectives

  1. Purpose. This document describes the formal process for implementing the requirements of the Change Management (ChM) process. It provides an operational definition of the major components of the process and how to perform each step in the process. This document also describes the logical arrangements of steps that are essential to successfully completing the process and achieving its desirable outcome. The objective of Change Management is to ensure that standardized methods and procedures are used for efficient and prompt handling of all changes to control the IT infrastructure, to minimize the impact of any related incidents upon the service. All changes must be recorded and managed in a controlled way. The scope of Change Management covers changes to all configuration items (CIs) across the whole service lifecycle.

  2. Audience. The Change Management process is applicable to all IT organizations, contractors, and other stakeholders having responsibility for change, management, oversight, and successful day-to-day operations of the IRS IT enterprise hardware, software, and services.

  3. Policy Owner. Demand Management & Project Governance (DMPG) Division, within Enterprise Operations (EOps) - Information Technology (IT).

  4. Program Owner. Governance & Resource Management Branch (GRMB), within DMPG - EOps - IT.

  5. Primary Stakeholders. IT organizations having responsibility for establishing an internal or local Change Management process and/or managing and controlling their IT system and/or system components are stakeholders in the IT Change Management process.

  6. Contact Information. To recommend changes or to make any suggestions to this IRM section, email the IT ChM PMO: it.chm.pmo@irs.gov

Background

  1. The IRS Information Technology (IT) organization supports hundreds of servers, applications, software, databases, and services, in addition to various network configurations, resulting in a large and complex environment. A change to any of these configuration items may introduce risk to availability, capacity, reliability, and performance. Managing changes to these configuration items mitigates risk and improves operating efficiencies. A formalized IT Change Management Process is designed to ensure that changes are authorized and operate as intended.

Process Definition

  1. Process Description. Change Management is the process responsible for managing all changes to all environments from inception thru completion. To be successful in managing change, the Change Management process must ensure that all changes are recorded and authorized at the appropriate level within IT and the Business without being overly bureaucratic. Simple (standard) changes would need minimal authorization but should still go through the process to ensure they are correctly recorded and appropriately tested. Complicated, high impact changes may need to be authorized at the Business Executive level, as well as the IT Executive level, before the implementation is initiated.

  2. Process Goal. The goal of the Change Management process is to conduct a formal, standardized methodology in the handling of all changes. With a standard, formal approach the potential for change-related Incidents are diminished, the quality of the changes is improved and the impacts upon the day-to-day operations of the organization are controlled.

  3. Process Objectives. Process objectives describe material outcomes that are produced or achieved by the process. The following is a list of objectives for this process:

    • Respond to the customer’s changing business requirements while maximizing value and reducing incidents, disruption and rework.

    • Respond to the Business and IT requests for change that will align the services with the business needs.

    • Ensure that changes are recorded and evaluated, and that authorized changes are prioritized, planned, tested, implemented, documented, and reviewed in a controlled manner.

    • Ensure that all changes to configuration items are recorded in a configuration management system (CMS), such as the configuration management database (CMDB).

    • Optimize overall business risk.

Authority

  1. The IRMs listed below establishes the authority for this process to be established:

    • IRM 2.125.1 Change Management Policy

    • IRM 2.150.1 Configuration Management Policy

    • IRM 10.8.1 Information Technology (IT) Security, Policy and Guidance

Roles and Responsibilities

  1. Each process defines at least one role. Each role is assigned to perform specific tasks within the process. The responsibilities of a role are confined to the specific process. They do not imply any functional standing within the hierarchy of an organization. For example, the process manager role does not imply the role is associated with or fulfilled by someone with functional management responsibilities within the organization. Within a specific process, there can be more than one individual associated with a specific role. Additionally, a single individual can assume more than one role within the process although typically not at the same time. Many roles are involved in the Change Management process. This section defines the roles used throughout this document in terms of their responsibilities.

    1. Process Role Description
      Change Approver/Change Advisory Board (CAB) The Change Approver is the manager or decision-making body that approves the implementation of a Request for Change (RfC) to an environment. The CAB is the group of people that advises on the assessment, prioritization, and scheduling of changes, approving their release. The board is usually comprised of representatives from all areas of IRS IT. There may be standing members, who are considered regular members of the CAB, and other individuals who will participate on an ad hoc basis, depending on the nature of the RfC being reviewed.
      Change Authority The Change Authority, Approval Groups/Individuals, is the manager or decision-making body that has the authority to allow the CI to be modified as documented in the RfC.
      Change Coordinator The Change Coordinator takes responsibility for an RfC when it has been assigned to a technical team to Review. The Change Coordinator is responsible for coordinating the assessment of the RfC and ensuring that the tasks necessary to complete the Change are planned, scheduled, resourced, and executed as planned. While primarily coordinating the assessments, planning, and implementation work done by others, the Change Coordinator will sometimes act in the role of initiating Change Analyst, assigned Change Analyst, or supporting Change Analyst.
      Frontline Manager The initiating Change Analyst’s Frontline Manager is responsible for reviewing and authorizing the RfC after it is submitted by the initiating Change Analyst.
      Change Manager The Change Manager role supports the Technical Authorization and Schedule & Approve Phases by reviewing the submitted RfCs. They validate correct completion of the RfC and ensure it follows the appropriate workflow. The Change Manager decides how the authorization of an RfC will proceed through the workflow via a Board meeting, virtual Board, or an Approval Group/Individual. The Change Manager collects and reviews the Change Authority and Change Approver decisions and records whether the RfC is authorized. The Change Manager role, though probably a different individual, oversees the RfCs schedule and release for disposition, and provides administrative support to the Change Approvers/CAB. The Change Manager will review the closure of RfCs and may select changes for post-implementation reviews.
      Change Analyst A Change Analyst can initiate an RfC, be assigned to manage the execution of an RfC, support the plan, design, build and test tasks for an RfC or implement the RfC within the Change Management life cycle. The role of the Change Analyst includes the following responsibilities:
      • The initiating Change Analyst for a given RfC is considered responsible for initiating the RfC, typically because of an Incident ticket, a Problem Management ticket or Work Request.

      • The assigned Change Analyst for a given RfC is considered responsible for advancement and execution of the RfC through the Change Management process. They are responsible for coordinating the assessment of the RfC and ensuring that the tasks necessary to complete the RfC are planned, scheduled, resourced, and executed as planned.

      • The supporting Change Analyst for a given RfC is considered responsible for performing an analytical, developmental, or testing task. They are typically considered Subject Matter Experts (SMEs), with specific expertise in some aspect of the proposed Change.

      • The implementing Change Analyst for a given RfC is considered responsible for implementing or installing the changed CI, or modifying the device, as specified. Because of separation of duties, the implementing Change Analyst should be a different individual than the one who built the RfC.

      Note:

      Assigned, Supporting and Implementing Change Analysts are delegated this responsibility by the Change Coordinator and should be a different individual than the person who initiated the RfC.

Program Management and Review

  1. The IT ChM PMO shall manage and evaluate the process based on the following guiding principles:

    1. Process Management.The Change Management process will have a single Process Owner and a separate Process Manager, responsible for implementation and ensuring adherence to the process. The process will be reviewed regularly to ensure that it continues to support the business requirements of the enterprise. Process metrics will be focused on providing relevant information as opposed to merely presenting raw data.

    2. People. Roles and responsibilities for the process must be clearly defined and appropriately staffed with people having the required skills and training. The mission, goals, scope and importance of the process must be clearly and regularly communicated by upper management to the staff and business customers of IT. All IT staff (direct and indirect users of the process) shall be trained at the appropriate level to enable them to support the process. It is imperative that people working in, supporting or interacting with the process in any manner understand what they are supposed to do. Without that understanding, Change Management will not be successful.

    3. Process. Modifications to the Change Management process must be approved by the Process Owner. The design of the process must include appropriate interfaces with other processes to facilitate data sharing, escalation and workflow. The process must be capable of providing data to support real-time requirements as well as historical/trending data for overall process improvement initiatives. The process must be fully documented, published and accessible to the various stakeholders of the process. The process will be reviewed on a periodic basis to ensure it continues to support organizational goals and objectives (continuous improvement). The process must include Inputs, Outputs, Controls, Metrics, Activities, Tasks, Roles and Responsibilities, Tool and Data requirements along with documented process flows. The process will be kept straight forward, rational, and easy to understand. The process must meet operational and business requirements.

    4. Technology and Tools All tools selected must conform to the enterprise architectural standards and direction. Existing in-house tools and technology will be used wherever possible, new tools will only be entertained if they satisfy a business need that cannot be met by current in-house tools. The selection of supporting tools must be process driven and based on the requirements of the business. Selected tools must provide ease of deployment, customization and use. Automated workflow, notification and escalation will be deployed wherever possible to minimize delays, ensure consistency, reduce manual intervention and ensure appropriate parties are made aware of issues requiring their attention. Technology and tools should be used to augment the process capabilities, not become an end themselves.

Program Control

  1. Program controls are driven by the policies and guiding principles on how the process will operate.

Controls
  1. Controls provide direction over the operation of processes and define constraints or boundaries within which the process must operate.

    Name Description
    Policies Policies and criteria for the inclusion of a component and its attributes in the CMS.
    Scope Applicable to any change that might affect the IT systems, infrastructure, and services in the IT environment. This should also include changes to all architectures, applications, software, tools and documentation, as well as changes to all configuration items across the whole service lifecycle.
    Management Reports The frequency and distribution for regularly produced management reports.

Metrics
  1. Metrics are used for the quantitative and periodic assessment of a process. They should be associated with targets that are set based on specific business objectives. Metrics provide information related to the goals and objectives of a process and are used to take corrective action when desired results are not being achieved and can be used to drive continual improvement of process effectiveness and efficiency.

  2. Management will regularly set targets for process performance, gather quantifiable data related to different functions of the Change Management process, and review that data to make informed decisions and take appropriate corrective action, if necessary. All Measurements will have a defined data dictionary, map to the organizational strategic goals, and be documented in a Process Measurement Plan.

  3. Enterprise and local Change Management processes, including Change Management tool owners, must produce metrics and measurement reports to measure the effectiveness and efficiency of the Change Management process.

Tailoring Guidelines
  1. The tailoring guidelines identify the allowable variations of the IT organization’s standard process as needed for adjustments (adding, deleting, modifying) relative to specific operational or functional needs of another organization. Process tailoring is about roles and procedures, not the standard process or major activities defined in this process. All tailoring requests, with supporting rationale, must be submitted in writing to and approved by the Change Management Program Management Office (ChM PMO). A critical success factor for this Change Management process is that it be followed consistently across all IT organizations. At a minimum, all organizations shall follow the mandates from the Change Management Policy document and the specific steps shall be identified for each category of change in the process flow. However, organizations can request to tailor such items as the authorization levels for changes or the combination of steps per Agile development methods, as long as the tailoring does not result in changes affecting other organizations not being reviewed.

Terms/Definitions/Acronyms

  1. The tables in the Terms/Definitions and Acronyms list commonly used terms and acronyms in the Change Management process..

Terms and Definitions
  1. This table list commonly used terms in the Change Management process.

    Term Definition
    Approval The activity required to implement a Change.
    Artifact A work product created by a process or procedure step, for example plans, design specifications, etc.
    Authorization The activity required to allow modification of a Configuration Item.
    Backout Method See Remediation Plan.
    Change Category The type of Change, such as Emergency, Standard, Normal, or Development or Core Engineering. The Change Category determines the required workflow steps to be followed in the Change-Management Process.
    Change Any addition, modification or deletion to a constituent part of a CI.
    Change Management (ChM) The process of managing a Change to a CI from inception to closure.
    Change Request The same as a Request for Change (RfC).
    Change Type See Change Category.
    Closure The state of an RfC when all associated work is successfully completed.
    Configuration Baseline A configuration baseline is the configuration of a service, product or infrastructure that has been formally reviewed and agreed, which thereafter serves as the basis for further activities and can be changed only through formal change procedures. It captures the structure, contents, and details of a configuration and represents a set of CIs that are related to each other.
    Configuration Control Board (CCB) A group of stakeholders responsible for evaluating and approving or disapproving proposed changes to a system, prioritizing the incorporation of approved changes, and scheduling the changes for forthcoming releases.
    Configuration Item (CI) Any component or other service asset that needs to be managed to deliver an IT service. It is the fundamental structural unit of the configuration management system. It is the basic data element that is used in the CM process and can be applied to anything that needs to be under configuration management. Typically, CIs include IT services, hardware, software, and documentation.
    • A CI can also be an aggregate CI (an aggregation of hardware, software, and/or documentation treated as a single entity within the Configuration Management process, designated as a Cl, and that satisfies an end use function. The aggregate Cl typically consists of component Cls.)

    • Each CI is uniquely identified in the CMDB so that it can be distinguished from all other configuration items.

    Configuration Management The process responsible for providing accurate and complete configuration information about the infrastructure components, including their attributes and relationships, to support the other CMMI and ITSM processes, such as Asset Management, Change Management, and Release & Deployment Management.
    Configuration Management Database A database used to store the records of Configuration Items and their attributes throughout their Lifecycle, as well as the relationships between CIs.
    Deferral A state of ‘waiting’ imposed on an RfC because a decision has been postponed.
    Demand Management The process where work is requested and resources are requested, allocated, and reported.
    Development or Core Engineering Change Complicated changes, usually unique, that require design and engineering work. They receive strong scrutiny from the review boards because they usually involve significant configuration changes to one or more CIs.
    Emergency Change A Change whose trigger is an interruption of service requiring expedited or immediate action. Emergency RfCs bypass all MF Service Manager, Change Management module approvals. There must be an associated Priority 1/Priority 2 (P1/P2) with every Emergency Change.
    Environment A set of infrastructures designated for a purpose. In the IRS, the principal environments are Development, Test, Production, Disaster Recovery and Alternate Site Processing (ASP).
    Governance Boards Executive Steering Committee (ESC) – consists of Executives, Management, Investment Project Managers, and Stakeholders; the ESCs govern decisions at the Control and Evaluate phases of the Capital Planning and Investment Control process.
    Lower level Governance Board (GB) – consists of Executives, Management, Investment Project Managers, and Stakeholders.
    Incident The cessation, or temporary failure, of a service.
    Incident Management The process of managing the restoration of service after an Incident.
    Known Error Problems that are understood, documented, and have a temporary correction available.
    Normal Change The default ITIL type of change - changes that are not Standard, are not Emergencies, and do not require the additional review needed by Development or Core Engineering RfCs.
    Priority An RfC field based on Impact and Urgency.
    Problem Management The process for managing Problems, including investigating Root Cause and developing workarounds for Known Errors to prevent Incidents.
    Rejection or Denial The activity performed by a Change Coordinator or Change Manager, returning an RfC to its Initiator for additional work. A rejection or denial of the RfC stops it from proceeding through the workflow for implementation.
    Release Management The process for assuring that Changes are planned, scheduled, and controlled as they are moved from one environment to the next.
    Remediation Plan A plan that defines how to recover to a known state after a failed Change or Release.
    Request for Change (RfC) The record of a Change proposal that is worked from Initiation through Review and Close.
    Service Level Management The process of managing Service Level Agreements (SLAs), addressing required levels of service. Proposed Changes must be reviewed for their effect on SLAs.
    Standard Change A frequently performed Change that has a known low level of risk and has a documented, well-tuned procedure for execution. Because it is a repeated, standardized procedure, it bypasses some of the Change Management rigor, like detailed impact assessments using a standard template.
    Successful Change A Change that has been implemented as scheduled and planned.
    Urgent (Urgency) The defined time indicator to get a service restored for use. Urgency combines with the Impact factor to define Change Priority.
    Withdrawal The activity of the Initiator voluntarily removing the RfC from the workflow. Withdraw reasons may include:
    • A request from the Change Trigger to withdraw..

    • The Planned End date has passed without significant progress to unanswered questions.

    • Insufficient resources to implement the RfC.

    • A Request by management not to implement the RfC

    Work Request The principal artifact of the Demand Management process, requesting work from IRS IT. It typically engenders Change.

Acronyms
  1. This table lists commonly used acronyms in the Change Management process.

    Acronym Definition
    CAB Change Advisory Board
    CCB Configuration Control Board
    ChM Change Management
    CI Configuration Item
    CMS Configuration Management System
    ITIL Information Technology Infrastructure Library
    KISAM Knowledge, Incident/Problem, Service and Asset Management
    RfC Request for Change
    SLA Service Level Agreement
    SME Subject Matter Expert

Related Resources

  1. The following resources either are referenced in this document or were used to create it.

    • IRM 2.150.2 Configuration Management Process

    • IRM 2.22.1 Unified Work Request (UWR) Process

    • ISO/IEC 20000-1:2011, Information Technology - Service Management – Part 1: Service Management System Requirements, Section 9.2 Change Management

    • ITIL Service Transition, 2011 Edition, Chapter 4.2 Change Management

Training

  1. Process training involves training all stakeholders about key processes that are crucial for an organization to deliver business objectives. . Training provides clarity to employees on a set of procedures that needs to be carried out as part of the process and the best possible way to do them. Some of the training resources available for this process are listed below:

    • Change Management Process Overview (ELMS Course #43161)

    • Configuration Management Overview (ELMS Course #23279)

    • Configuration Management Combo Course (ELMS #64877)

Process Workflow

  1. A process workflow consists of Activities and Tasks, Inputs and Outputs, Roles, and Flow Diagrams. . It describes the tasks, procedural steps, organizations or people involved, required input and output information, and tools needed for each step of the process..

Main Process Diagram

  1. The phases listed in the diagram below - Change Management Process Flow Diagram for each Change Category is described in the MF Service Manager - Change Module User Guide.

    Figure 2.125.2-1

    This is an Image: 70895001.gif

    Please click here for the text description of the image.

Inputs

  1. Process inputs are used as triggers to initiate the process and to produce the desired outputs. Users, stakeholders or other processes provide inputs. The following is a list of inputs for this process:

    Name Description Supplier
    Emergency Change A Request for Change (RfC) with a Change Type of Emergency; to implement a change as soon as possible to correct (or prevent) a high priority incident. Emergency Changes must be initiated from a P1 or P2 Incident Management ticket. Change Analyst
    Standard Change A Request for Change (RfC) with a Change Type of Standard; an accepted solution to an identifiable and relatively common set of requirements, where authority is effectively given in advance of implementation. A change that recurs, is repetitive, and is implemented routinely. Typically, but not always, a low risk change. Standard Changes must use the Standard Change Templates. Change Analyst
    Normal Change A Request for Change (RfC) with a Change Type of Normal; any service change that is not a Standard or Emergency Change and typically requires an important change to a service or the IT infrastructure. A normal change is subject to the full change management review process, including review by the Change Advisory Board (CAB) and authorization/rejection. Change Analyst
    Development or Core Engineering Change A Request for Change (RfC) with a Change Type of Development or Core Engineering Change; usually unique, that require design and engineering work. They receive strong scrutiny from the review boards because they usually involve significant configuration changes to one or more Cis. Change Analyst

Outputs

  1. Each process produces tangible outputs. These outputs can take the form of products or data and can be delivered to a user or stakeholder, or, they can be used as inputs to other processes. Outputs are measurable in terms of quantity and quality.

    Name Description Supplier
    Approved RfC Management and board approvals for what is being changed/modified. Change Analyst Change Coordinator Change Manager
    Deployed RfC Complete implementation and associated work products. Change Analyst Change Coordinator Change Manager
    Closed RfC Review and close RfC. Change Analyst Change Coordinator Change Manager

Activities

  1. An activity is a major unit of work to be completed in achieving the objectives of the process. A process consists of a sequence of related activities that transforms inputs into outputs and performed by the roles defined in the process. Activities are measurable in terms of efficiency and effectiveness. The activities must correspond with the high-level process flow diagram above.

    ID Name Description
    ChM 1.0 Change Pre-Coordination Phase The main purpose is to translate Work Requests, Incident and Problem Management tickets, or general statements of desired changes into a planned structure of specific changes and to align them with responsible technical teams for implementation. The Step is accomplished outside of the tool.
    ChM 2.0 Change Logging Phase This activity initiates the documentation of the life cycle of the Change from inception to completion in the MF Service Manager, Change Management module.
    ChM 3.0 Frontline Manager Approval Phase Responsible for determining a certain disposition of the RfC before it progresses to the next phase in the process. This phase occurs for all Change Categories, except Emergency.
    ChM 4.0 Coordinator Review Phase Ensures the RfC is “actionable”, correctly categorized and contains sufficient information for planning. This phase occurs for all Change Categories, except Emergency.
    ChM 5.0 Assess and Evaluate Phase Performing the required detail analysis and planning that prepares the RfC for the authorization decision.
    ChM 6.0 Plan, Design, Build &Test Phase Activities based upon the work performed for Development or Core Engineering Changes that will be designed and built as determined in Step 5: Assess & Evaluate Phase.
    ChM 7.0 Technical Authorization Phase Conducting a review of the RfC to ensure process compliance has been met, the RfC has been properly categorized, the supporting artifacts are attached, and the RfC is ready for review and authorization.
    ChM 8.0 Schedule and Approve Phase (IT-wide CAB) Refers to the scheduling of Standard, Normal, and Development or Core Engineering Changes for implementation and obtain approval from the Change Approvers.
    Required Elevated Approvals also occur during this phase
    ChM 9.0 Implementation Phase Implementing the RfC into the designated environment(s). This phase occurs for all Change Categories.
    ChM 10.0 Review and Close Change Phase Occurs to review the execution of the RfC and close the RfC. Some RfCs may be selected for Post-Implementation Reviews by the Change Manager. This phase occurs for all Change Categories.