2.150.3 Change Management (ChM) Policy

Manual Transmittal

November 25, 2013

Purpose

(1) This transmits revised IRM 2.150.3, Configuration and Change Management, Change Management (ChM) Policy.

Background

This IRM defines service Change Management (ChM) policies per the Configuration and Change Management Directive.

Material Changes

(1) This IRM describes the functions of ChM that incorporates usage of ITIL Compliant tools and processes.

Effect on Other Documents


IRM 2.150.3, dated July 30, 2013, is superseded.

Audience


All Information Technology organizations, employees and contractors.

Effective Date

(11-25-2013)

Related Resources

The following IT CM artifacts are still in effect:

  • Information Technology Configuration Management Plan

Terence V. Milholland
Chief Technology Officer

Introduction
Administration

  1. All proposed changes to this document should be directed to the Change Management Program Management Office (ChM PMO), owner of this process description, and be pursued via the Integrated Process Management (IPM) process.

Purpose of Process Description

  1. This Change Management Process Description describes what happens within the IRS IT Change Management process and provides an operational definition of the major components of the process. This description specifies, in a complete, precise and verifiable manner, the requirements, design, behavior and characteristics of the Change Management process. This process is applicable to any managed environment including Development, Test, Production, and Disaster Recovery. The Process Description is a documented expression of a set of activities performed to achieve a given purpose. Tailoring of this process in order to meet the individual needs of a project is covered in the Tailoring Guidelines section of this document.

Document Overview

  1. This document describes a set of interrelated activities, which transform inputs into outputs, to achieve a given purpose and states the guidelines that all projects should follow with regard to the Change Management process. The format and definitions used to describe each of the process steps of the Change Management process are described below:
    Purpose – The objective of the process step
    Roles and Responsibilities – The responsibilities of the individuals or groups for accomplishing a process step
    Entry Criteria – The elements and conditions (state) necessary to trigger the beginning of a process step
    Input – The data or material needed to perform the process step
    Process Activity – The list of activities that make up the process step
    Output – The data or material that is created as result of performing the process step
    Exit Criteria – The elements or conditions necessary to trigger the completion of a process step
    For the purpose of this document, roles such as Change Manager, Change Coordinator, etc. are provided to describe a set of responsibilities for performing a particular set of related activities.

Process Overview
Work Products

  1. This section describes the work products (known as inputs) needed to execute the process as well as those produced by the Change Management process (known as outputs).
    2.150.3.4.1 Work Products (Inputs) Used by This Process
    The following work products are used to assist in the implementation of the Change Management process:
    • WRMS Work Request requiring a modification to an existing Configuration Item (CI) or any change to an IRS IT system including the addition of a system
    • KISAM ticket identifying an Incident requiring a modification to an existing CI
    • Test Status Reports
    • Known Errors
    • Current Baselines
    • Service Level Agreements (SLAs)
    • Transmittal Memoranda
    • Forward Schedule of Change
    • Change or Maintenance Windows, Planned Outages, or Change Moratoria
    2.150.3.4.2 Work Products (Outputs) Produced by This Process
    The following work products are produced by the Change Management process and may be used as inputs to other processes, such as Demand Management, Configuration Management or Release Management:
    • Requests for Change (RfC) – Completed, Partially Completed, Cancelled, or Withdrawn
    • Assessment documentation (i.e. Detailed Technology Impact Assessments, Security Impact Assessments, assessments of business impact)
    • RfC-Specific Governance Board Decision Document
    • Detailed Forward Schedule of Change
    • Updated Configuration Management records
    • New Configuration Baselines
    • Change Implementation plans
    • Change Back-Out Plans
    • Change Management Reports

  2. This figure represents the processes that are affected by a request for change..

Change Management Process Steps

  1. 2.150.3.5Step 1: Change Pre-Coordination and Planning

  2. 2.150.3.5.1Purpose
    The purpose of the Change Pre-Coordination and Planning Step is to translate Work Requests, complicated KISAM tickets, or general statements of desired changes into a planned structure of specific changes that can be aligned with responsible technical teams for implementation. Engagement is made to plan the changes with the areas likely to be directly affected by or involved with the proposed change, including engineering, development, and implementation teams, as well as areas potentially impacted based on the service or configuration items covered.
    This step may serve as the initial input to the Impact Assessment activity, but may not take the place of complete technology and security impact assessments and evaluations.

  3. 2.150.3.5.2 Roles and Responsibilities
    Change Analysts (as Change Initiators) are responsible for identifying what solution(s) are required for the proposed change, who is affected by the proposed change, collaborating on proposing one or more solutions to the proposed change, and engaging appropriate knowledge resources within their organizations as required.

  4. 2.150.3.5.3 Entry Criteria
    Generally, Change Pre-Coordination and Planning occurs after any of the following events have occurred:
    • Work Request has been received
    • KISAM ticket has been received
    • Solution to a Known Error has been identified and implementation is desired
    • Control Board has issued a request to plan a change

  5. 2.150.3.5.4 Input
    The following are inputs to this process step:
    • Initiating document (for example, a Work Request or KISAM ticket)
    • CI List or Topological Diagram of affected and related components
    • CI Specifications

  6. 2.150.3.5.5 Process Activity
    2.150.3.5.5.1 Analyze Change
    Analyze the request or requirement for the change(s) and determine what action is really required. Identify what specific services or components would need to change to fulfill the request, and the teams that would be involved in implementing the change(s)
    2.150.3.5.5.2 Plan Change

    Ensure all affected participants and knowledge resources are engaged. Identify the specific changes that will need to be made and any dependencies, or sequencing and scheduling issues. Verify any conditions of the Entry Criteria (for example, Work Request proposed operational dates) affecting the plan. Document the tasks, dates and responsible assignment groups necessary to effect the change.

  7. 2.150.3.5.6 Output
    The following are outputs to this process step:
    • Change Statement for RfC
    • ICA Details for Work Request in WRMS
    • Other planning documentation that will support the logging of the change

  8. 2.150.3.5.7 Exit Criteria
    This process step is complete when either:
    • The requested change is planned
    • The requested change is withdrawn or cancelled in WRMS or KISAM
    2.150.3.6Step 2: Change Logging
    2.150.3.6.1 Purpose
    The purpose of Change Logging is to register an RfC to document the life cycle of a change from inception to completion in the official system of record. Traceability to the affected CI(s) and to other components affected by the change is systemically provided. RfC will be authorized by the initiator’s manager before they progress to the next step in the process. This step occurs for all types of change.
    2.150.3.6.2 Roles and Responsibilities
    The Change Initiator logs the Change.
    The Front Line Manager of the Change Initiator reviews the RfC and approves it for submission, documenting the validity of the requested change.
    2.150.3.6.3Entry Criteria
    • Requirement for a Change has been identified
    • Initial agreement on the approach for the Change during pre-coordination, with one or more specific requests for change
    2.150.3.6.4Input
    • Change Statement that can be used as the description of the RfC
    • Planning documentation stored in WRMS or KISAM from the original request
    • CI details from the CMDB
    2.150.3.6.5 Process Activity
    2.150.3.6.5.1 Create a New Request for Change (RfC)
    The Change Initiator logs the RfC into ECMS. The Change Initiator identifies the category of RfC as Emergency, Standard, Normal, or Development or Core Engineering Effort (see definitions in the Glossary).
    2.150.3.6.5.2 Gather Required Information
    The RfC is held in the Change Logging Step as a draft for up to 5 days to allow the Initiator to complete the RfC in more than one ECMS session. To save a request initially, the required fields are Category, Title, Requested End Date, Service and Initiated By. When the RfC has all the information completed, the Change Initiator can submit the proposed RfC to their Front Line Manager or decide to withdraw it. The additional fields required to submit the RfC to the Front Line Manager are Impact, Urgency, Description, and Assignment Group.
    2.150.3.6.5.3 Review by Initiator’s Front-Line Manager
    Notification is sent to the Initiator’s manager to review and approve the RfC. If there is not sufficient information included in the RfC, the Front Line Manager can send the RfC back to the Change Initiator to complete the information, or send it to another staff member in their section. If there is sufficient information and the Front Line Manager agrees with the RfC, they submit the RfC and it flows to the Change Review Step. If the Front Line Manager does not want the RfC to proceed, they choose to deny it and it is sent to the Review and Close Change Step.
    2.150.3.6.5.4.Withdraw Change
    If the Change Initiator decides to withdraw an RfC, a notification is sent to the Change Initiator and the Front Line Manager with the withdrawal disposition. Withdrawal Criteria include the Initiator’s statement that the Change is no longer needed, was determined not to meet organizational policy, or is technologically unfeasible.
    2.150.3.2.6 Output
    A logged RfC
    • A withdrawn RfC
    2.150.3.2.7 Exit Criteria
    • The completion of the Logging step, or
    • The completion of the Withdraw action
    2.150.3.3 Step 3: Review Change
    2.150.3.3.1 Purpose
    The purpose of the Change Review Step is to ensure an “actionable” RfC has been logged. It is checked to ensure that it is correctly categorized and that there is sufficient information for the Change to be planned. This step occurs for all types of Change, except Emergency.
    2.150.3.3.2 Roles and Responsibilities
    The Change Coordinator reviews the RfC to ensure it is complete, correct, and valid, assumes accountability for the RfC, and assigns it to a Change Analyst.
    The assigned Change Analyst is delegated responsibility for the RfC, gathering additional information in this phase before deciding to proceed to the next step or reject the RfC
    2.150.3.3.3 Entry Criteria
    • The RfC completes the Change Logging Step by being submitted by the Initiator’s Front-Line Manager
    2.150.3.3.4 Input
    • A logged RfC ready for review with the Assignment Group presumed to be primarily responsible for carrying out the RfC
    2.150.3.3.5 Process Activity
    2.150.3.3.5.1 Review the RfC
    The Change Coordinator selects the RfC from their Assignment Group queue for validation. The Change Coordinator ensures that Assignment Group is correct, that the RfC has been correctly assigned to the Change Coordinator’s section. If the assignment is incorrect, the Change Coordinator will move to the Assign to Correct Group Activity. If the assignment group is correct, the Change Coordinator will continue to verify the Change Category, Service and the rest of the key information on the RfC.
    2.150.3.3.5.2 Assign to Correct Group
    If the Change Coordinator believes that another section should have the lead for the RfC they will change the Assignment Group to the one that they think is correct. A notification of the modification is sent to the Change Initiator, and the Change Coordinator for the new Assignment Group is notified as well. The RfC restarts the Change Review Step at the Review the RfC Activity with a new Assignment Group and Change Coordinator.
    2.150.3.3.5.3 Select Correct Category and Service
    The Change Coordinator will review the Change Category and Service, and select the correct Change Category and Service if they are not valid. They will validate the Change Subcategory and correct if necessary. The Change Coordinator verifies that the other required fields are correct and complete. If the information is complete, the RfC moves to the Verify Change is Valid Activity. If the Change Coordinator determines the information is incomplete, they will decide if there is sufficient information available to them to move the RfC forward. If sufficient information is available, the Change Coordinator will add it to the RfC. If sufficient information is not available, the RfC moves to the Request more Information from the Change Initiator Activity.
    2.150.3.3.5.4 Assign RfC to Change Analyst
    The Change Coordinator assigns a Change Analyst from their team to be responsible for managing the RfC through the remainder of the ChM process. The assigned Change Analyst could be the same as the Change Coordinator on the RfC.
    2.150.3.3.5.5 Verify Change is Valid
    The assigned Change Analyst decides whether the RfC is valid: If the Change is logical, feasible, necessary, and aligns with IRS policy and IT strategy. If the Change passes the validity test, the Change Coordinator submits the RfC to the Change Assessment & Planning Step. If the assigned Change Analyst does not believe the RfC is valid, the RfC moves to the Reject the RfC Activity.
    2.150.3.3.5.6 Request more Information from the Change Initiator
    The assigned Change Analyst updates the RfC to state the reason the Change is returned to the Change Initiator, specifying the missing or incomplete information. The Change Coordinator will create and add a Task to the RfC to request the additional information, assigned to the Change Initiator. A notification will be sent to the Change Initiator informing them of the Task. Once the Change Initiator has provided additional information and marked the Task as complete, the RfC moves to the Provide Change Details Activity.
    2.150.3.3.5.7 Provide Change Details
    The assigned Change Analyst completes the required information for the RfC with information that was available to them and not automatically provided from the Change Category or pre-defined form. Once all details are completed, the RfC moves to the Verify Change is Valid Activity.
    2.150.3.3.5.8 Reject the RfC
    If the assigned Change Analyst does not believe the proposed Change can or should be processed further, they record their reasons and the RfC is moved to the Review & Close Change Step. A record is retained in the system, as “previously rejected” Changes are tracked. A rejection notification is sent to the Change Initiator and their Front Line Manager.
    2.150.3.3.6 Output
    • RfC moved to Change Assessment and Planning step, or
    • A Rejected RfC, with reasons
    2.150.3.3.7 Exit Criteria
    • An RfC pushed to the next step, or
    • The rejection of the RfC
    2.150.3.4Step 4: Assess and Evaluate Change
    2.150.3.4.1 Purpose
    The purpose of the Assess and Evaluate Change Step is to perform the required detail analysis and planning that prepares the RfC for the decision to authorize or approve. The RfC is assessed for its risk and impact, the work required to accomplish the change is identified and planned, and the RfC is tentatively scheduled. This Step documents the planned change to the CI(s).
    2.150.3.4.2 Roles and Responsibilities
    The assigned Change Analyst manages the RfC through its flow among the required technical reviews and, if necessary, the Governance review, taking responsibility to see that the RfC is fully assessed and planned.
    Supporting Change Analysts perform assessments of the change, analyze impacts and risks, and recommend plans for implementation.
    The Change Coordinator supervises the Change Analyst(s) in processing the RfC and is ultimately accountable for the quality and completeness of the assessment of the RfC.
    2.150.3.4.3 Entry Criteria
    • The RfC has completed the Change Review step with the Change Coordinator.
    • A Change Analyst has been assigned as responsible for the RfC.
    2.150.3.4.4 Input
    •The RfC has been reviewed and is valid.
    • Responsibilities for the work to be done are identified based on the ownership of the CIs involved in the RfC, as documented in the CMDB.
    • IT Project/Investment Cost, Schedule, IT Scope and Business Results Baseline, if applicable
    2.150.3.4.5 Process Activity
    2.150.3.4.5.1 Assess Change and Validate Risk Categories The assigned Change Analyst designates one or more supporting Change Analysts to review, assess and document technical requirements and impacts of the proposed Change. A Task form in ECMS is used by the Change Coordinator to assign these responsibilities, and a notification is then sent to the Change Analysts so they are aware of this pending responsibility. The risk assessment focuses on the potential for failure and the impact to the business. The remediation or “Back-out” Plan for the change is also started with this assessment.
    2.150.3.4.5.2 Gather Impacts and Technical Assessments The assigned Change Analyst receives the completed assessment Tasks, assuring that all were completed, and that all potentially impacted areas have responded. This should include assessments of Security, Enterprise Architecture and affected Standards, such as server and desktop images. If the RfC assessment indicates impact to the project’s cost, schedule, IT scope, or business results baselines, the Change Coordinator will direct the RfC to the owning Governance Board for review and approval, and only if approved will the RfC be presented to the Change Authority.
    2.150.3.4.5.3 Evaluate Change The assigned Change Analyst validates that the proposed Change is logical, feasible and necessary, now basing the validation on the input of expert Change Analysts. If the Change is large and/or complex, with multiple Sections, involved, there may be justification to change the Primary Change Coordinator and assigned Change Analyst based on the analysis from the impact assessments, determining that another Section should take the lead. In that case the RfC moves to the If Necessary, Change Primary Change Coordinator Activity. In this Activity the assigned Change Analyst discusses the assessment results with the Change Coordinator and may decide the Change should be rejected, resulting in the RfC moving to the Reject Change Activity. Alternatively, the assigned Change Analyst may decide that more information is required from the Change Initiator, and will create a Task to collect it assigned to that individual, holding the RfC until the Task is complete. Configuration Control Boards (CCBs) are encouraged to establish a formal Engineering Review Board (ERB) or Technical Review Board (TRB). Where such an ERB or TRB exists, the Change Coordinator will submit the RfC to that Board, and collect their assessment and recommendation as part of the Evaluate Change Activity. When the evaluation work is complete, the RfC moves to the Plan and Schedule Change Activity.
    2.150.3.4.5.4 Evaluate Change-If Necessary If necessary, based on the analysis of the technical assessments of the work to be done, the Primary Change Coordinator can be changed. This is accomplished, with the agreement of the receiving Change Coordinator, through revising the Assignment Group for the RfC. The RfC then moves to the Plan and Schedule Change Activity under the control of the new Primary Change Coordinator.
    2.150.3.4.5.5 This schedule should be in an established window for deploying changes. The assigned Change Analyst will verify that there are no schedule collisions with other RfCs using the HP Release Control module to look at the Forward Schedule of Change. If necessary, they will adjust the schedule of the RfC to avoid a collision. For Normal and Standard Changes, the assigned Change Analyst creates a Transmittal for implementation once the Change has been planned and preliminarily scheduled. The RfC then moves to the Verify Change Priority and Risk Category Activity.
    2.150.3.4.5.6 Verify Change Priority and Risk Category The assigned Change Analyst verifies the Change Priority is correct. The priority establishes the order in which Changes will be processed when there are multiple RfCs scheduled for the same schedule period. The assigned Change Analyst reviews the impact assessments and the Risk categorization of the RfC in the Release Control module of ECMS, and adjusts the Risk Assessment value for the RfC as needed in HP Service Manager. The assigned Change Analyst determines if the RfC is ready to move to the Authorize Change Step. If the assigned Change Analyst determines that the RfC is not ready for the next step, it is returned to the Plan and Schedule Change Activity.
    2.150.3.4.5.7 Verify Change does not exceed Governance Thresholds, as appropriate The assigned Change Analyst verifies the Change has not exceeded the approved cost or schedule, and has not deviated from the planned IT scope and business results. If the thresholds have been exceeded, the assigned Change Analyst will refer the RfC to the responsible Governance Board for review and will not submit the RfC for Authorization until the Governance Board’s disposition is received. This may result in the RfC needing revisions with a new plan, being rejected, or continuing on to Authorization.
    2.150.3.4.5.8 Reject Change The assigned Change Analyst may reject the RfC during this Activity. If rejected, the Change is then sent to the Review & Close Change Step. A rejection notification is sent to the Change Initiator and their Front Line Manager.
    2.150.3.4.6 Output
    •Updated RfC
    •Completed Tasks for planning and assessing the Change
    •Plan for performing the work required to implement the Change
    •Start of Back-out Plan for the Change
    •Completed impact assessments, including the ERB or TRB report
    • Deployment/release schedule date.
    •Transmittal for implementation of RfC (For Normal and Standard Changes)
    •RfC-Specific Governance Board Decision Document
    2.150.3.4.7 Exit Criteria
    • All Tasks for this Step have been completed
    • The RfC completes the Assess & Evaluate Change step, or
    • The RfC is Rejected
    2.150.3.5Step 5: Authorize Change
    2.150.3.5.1Purpose
    The Change Manager reviews the Change to assure that process compliance has been met, the RfC has been properly categorized and the RfC is ready for review and authorization by the Change Authority. The Change Authority makes its decision on authorizing or rejecting the Change.
    2.150.3.5.2Roles and Responsibilities
    The Change Manager coordinates the review of the RfC, following the rules established by their CCB or Change Authority for authorizing Changes. The Change Authority reviews the proposed change and makes a decision on authorization.
    The Change Authority can vary depending upon the risk and impact of the Change. For high risk Changes the Change Authority would usually be a CCB, but for many other changes it could be just the manager who owns the CI being changed.
    2.150.3.5.3Entry Criteria
    •The RfC has completed the Assess and Evaluate Change Step and requires Authorization.
    2.150.3.5.4 Input
    •An assessed and evaluated RfC, with a plan and schedule for deployment, with all assessments included.
    2.150.3.5.5Process Activity
    2.150.3.5.5.1 Review Change by Change Manager The Change Manager reviews the RfC to ensure it meets the level of completeness necessary for CCB or Change Authority approval. If the Change is not ready for authorization, it is returned to the Change Coordinator in the Change Returned to Assigned Change Analyst Activity. If the Change is ready for Authorization, the Change Manager reviews the RfC plan, schedule, risk, and impact assessments. If the plan and schedule are satisfactory, the RfC moves to the Determine Change Authority Activity.
    2.150.3.5.5.1.2 Change Returned to Assigned Change Analyst The change is returned to the assigned Change Analyst for additional information. This is done using a Task for additional information with the assigned Change Analyst as the assignee. Once the additional information is provided, the RfC is sent back to the Review Change by Change Manager Activity. Until then the RfC is held in this Step.
    2.150.3.5.5.1.3 Determine Change Authority The Change Manager reviews the RfC and supporting artifacts to determine if the Change requires CCB review and approval, or just sign-off by the manager responsible. They will flow the RfC to the appropriate Change Authority.
    2.150.3.5.5.1.4 Review Change by Change Authority (Individual or Board) The Change Authority reviews the proposed Change and determines whether the Change should be made or denies the RfC. The Change Authority may ask for additional information, placing the RfC in a Deferred State. The Change Manager verifies the decision and treats the RfC appropriately. If authorized, the RfC then moves to the Record Approval Activity. If not authorized, the RfC moves to the Record and Review Denial or Deferral Reason Activity.
    i.The Change Manager reviews the reason the Change Authority provided for not authorizing the RfC to proceed and records it. A notification is sent to the Change Initiator, Front Line Manager and Change Coordinator.
    ii.If authorization is conditional on additional information, the RFC is placed in a Deferred State. A Task will be assigned to the Change Coordinator to gather the additional information. Once the additional information is received, the RfC moves to the Review Change by Change Authority Activity.
    iii.If additional information is not required, the RfC moves to the Reject Change Activity.
    2.150.3.5.5.1.5 Record Approval The Change Manager updates the RfC with the determination of the Change Authority. A notification is sent to the assigned Change Analyst, Change Initiator, Front Line Manager and Change Coordinator with the RfC disposition. After approval, the Change Manager determines if the Change is ready for deployment or must be designed, built and tested first. If the RfC is not ready for deployment, it moves to the Plan/Design/Build/Test Change Step. If it is ready for deployment, it moves to the Schedule and Approve Change for Deployment Step.
    2.150.3.5.5.1.6 Reject Change Per the decision of the Change Authority, the Change Manager rejects the RfC and moves it to the Review and Change Closure Step. A rejection notification is sent to the assigned Change Analyst, Change Coordinator, Change Initiator, and Front Line Manager.
    2.150.3.5.6Output
    • An authorized RfC with Attachments, or
    • A Rejected RfC
    • RfCs that remain for an excessive amount of time in the Deferred state will be marked as Rejected
    2.150.3.5.7Exit Criteria
    • The assessed RfC is authorized for Change, or
    • The RfC is rejected
    2.150.3.6Step 6: Plan, Design, Build, and Test Change
    2.150.3.6.1Purpose
    Changes needing to be designed and built, as determined in the Assess and Evaluate Step, have that activity done in this Step. The work is performed by one or more Change Analysts on Tasks under the RfC, with the Change Coordinator monitoring the completion of the Tasks and submitting the Change to the next Step when all Tasks are done and the RfC is ready. Notifications are sent for each Task to ensure that the Change Analysts are aware of pending work. This Step is used for Development or Core Engineering efforts only.
    2.150.3.6.2 Roles and Responsibilities
    The assigned Change Analyst assigns Tasks to supporting Change Analysts and ensures activities are completed as planned.
    Supporting Change Analysts plan, design, build and test the proposed Change in assigned Tasks.
    The Change Coordinator supervises the assigned Change Analyst and is ultimately accountable for the final plan and product for implementation.
    2.150.3.6.3Entry Criteria
    •An Authorized RfC requiring Plan/Build
    2.150.3.6.4 Input
    • An RfC requiring Plan/Build with any attachments and a plan of the Tasks for the work developed in the Assess and Evaluate Change Step plus any required information.
    • Standard practices and procedures for the technical activity required for planning, designing, building, and testing.
    2.150.3.6.5Process Activity
    2.150.3.6.5.1 Review the Schedule and Adjust as necessary
    The assigned Change Analyst reviews the scheduled implementation date for the RfC against the time available and the work to be done and adjusts implementation date as necessary.
    2.150.3.6.5.2 Create and Manage the Tasks
    The assigned Change Analyst creates the tasks on the RfC for each of the required plan/design/build/test activities. The activities can be cross-organizational and may have dependencies on other projects or RfCs. Each task is assigned to a Change Analyst with a given schedule for when it should be completed.
    2.150.3.6.5.3 Validate Task
    The supporting Change Analyst assigned to each task verifies that the task has been correctly assigned and the information required to execute it is available. The Change Analyst will determine if the task assignment/schedule is correct and feasible or needs revision. If the assignment and schedule are correct, the RfC moves to the Plan and Design Change, Build Change, and Test and Document Change activities. If incorrect, the RfC moves to the Return for Reassignment or Rescheduling Activity.
    2.150.3.6.5.4 Return for Reassignment or Rescheduling
    The assigned Change Analyst reassigns the task to another supporting Change Analyst, and/or modifies the schedule for the task. The Change Coordinator may need to escalate resource issues.
    2.150.3.6.5.5 Plan and Design Change\Build Change\Test and Document Change
    These are separate tasks which can be performed in parallel or in any order depending on the nature of the change. These tasks are executed with the assigned Change Analyst monitoring their performance to validate timing and completeness. The tasks are assigned to supporting Change Analysts who complete the tasks, update the RfC and revise design documentation as necessary to include the newly approved baseline specifications. Supporting Change Analysts performing testing are “third-party” Analysts, different than those who designed and built the products to be tested. The testers perform their tasks according to IRM 2.6.1.
    Note: Other types of testing may be performed per the ELC, based on the complexity of the development or engineering performed.
    The RfC then moves to the Passed Test Activity.
    2.150.3.6.5.6 Passed Test
    The Change Coordinator receives a notification of the testing result and verifies the change has passed the test criteria. If the change passes, the assigned Change Analyst creates a Transmittal for implementation and moves the RfC to the Schedule and Approve Change for Deployment Step. If the change did not pass testing, and another solution is determined to be needed, the RfC is moved back to the Assess and Evaluate Change Step by the Change Coordinator.
    2.150.3.6.5.7 Reject RfC
    If the assigned Change Analyst makes a decision to reject the RfC based on a failed test, the change is sent to the Review and Close Change Step. A rejection notification is sent to the Change Initiator, Change Coordinator, and the Front Line Manager. If the assigned Change Analyst determines after a failed test not to reject the RfC, it is returned to the Plan and Design Change Activity for revision and retesting.
    2.150.3.6.6Output
    • A change that has been successfully built and tested and is ready for implementation
    • Updated Documentation
    • Test Result
    • Updated RfC
    • Transmittal for implementation of RfC (For Development and Core Engineering Effort Changes
    2.150.3.6.7Exit Criteria
    •Change has been planned, designed, built, and tested, as required, and is ready for release and deployment.
    2.150.3.7Step 7: Schedule and Approve Change
    2.150.3.7.1 Purpose
    The purpose of this step is to schedule and approve the change for deployment by the Change Advisory Board (CAB). This step occurs for all types of change.
    2.150.3.7.2 Roles and Responsibilities
    The Change Manager or the CAB verifies that the RfC is ready for review and release, coordinating the approval of the RfC.
    The Change Coordinator and/or the assigned Change Analyst may be asked to participate in the CAB meeting, or to obtain additional information.
    The Change Approvers or CAB members review the readiness and schedule of RfCs and approve their release.
    2.150.3.7.3Entry Criteria
    • The RfC has been planned, built and tested with planned schedule for release and deployment
    • The Transmittal and/or other Release documentation has been prepared and checked
    2.150.3.7.4Input
    • An updated RfC
    • The Transmittal and/or other Release documentation
    2.150.3.7.5Process Activity
    2.150.3.7.5.1 Review Change by Change Manager
    The Change Manager reviews the RfC for readiness to be released, examining the assessments and authorization decision as well as reviewing the RfC’s planned schedule for deployment to ensure alignment with the relevant maintenance window(s) and with strategic implementation dates.
    Changes with the Change Category of Standard are checked to make sure that they are indeed valid standard changes and that they have been scheduled in a normal window without collisions. If these conditions are met, the RfC is moved to the Record Approval activity.
    For all other changes, if all is satisfactory, the RfC moves to the Determine Change Approver Activity. If the RfC is not satisfactory, the Change Manager will add a task to collect additional information. Once the information is received, the RfC goes back through review by the Change Manager.
    2.150.3.7.5.2 Determine Change Approver
    The Change Manager reviews the risk categorization of the RfC along with the supporting artifacts to determine if the change requires review by a CAB meeting, a review by all CAB members virtually, without a meeting or only requires the review of one or a limited number of CAB members. The Change Manager adjusts the workflow for the RfC so that it will be sent to that Change Approver for disposition.
    2.150.3.7.5.3 Review Change by Change Approver (Individual, Virtual Board or Board)
    The Change Approver reviews the RfC for its impact, urgency and risk, the quality of the Change design, the results of testing and the schedule for implementation (looking for potential conflicts and collisions with other RfCs). They either approve or disapprove the RfC, recording any comments regarding the decision on the RfC. The Change Approver may ask for additional information.
    i.If the release of the RfC is approved, it moves to the Record Approval Activity.
    ii.Once the approval is recorded, a determination is made about the type of approval. If the release of the RfC is conditionally approved, a task is added to collect additional information. If the RfC is approved without conditions, the RfC moves to Implement Change.
    iii.If the release of the RfC is not approved, a determination is made to Defer or Reject the RfC.
    iv.If the RfC is deferred by the Change Approver, the Change Manager determines if additional information is needed. If additional information is not needed, the RfC moves to the Place Change in Waiting State Activity. If additional information is needed, the RfC moves to the Place Change in Deferred State Activity.
    v.Once the additional information is received, the RfC moves back through the Review by Change Authority (Individual or Board) Activity.
    2.150.3.7.5.4 Record Approval The Change Manager updates the RfC to have the status of Approved, including any comments from the Change Approvers. A notification of the approval is sent to the assigned Change Analyst, Change Coordinator, Change Initiator and Front Line Manager for the RfC. If there is a conditional approval, the RfC moves to the Update Change Activity. If the RfC is approved unconditionally, it moves to the Implement Change step.
    2.150.3.7.5.5 Reject Change The Change Manager updates the RfC to rejected status based on the decisions made by the Change Approvers, including comments and an explanation for the rejection. A notification is sent to the assigned Change Analyst, Change Coordinator, Change Initiator, Front Line Manager, and Change Authority. The RfC is then moved to the Review and Close Change step.
    2.150.3.7.5.6Place Change in Waiting State The Change Manager sets a time at which the RfC will be brought back to the beginning of the Schedule/Approve Change for Deployment Step. A reason code and a comment must be given for the waiting state.
    2.150.3.7.5.7Place Change in Deferred State If additional information is required, the RfC is placed in the deferred state. A Task is created to request the information needed. The RfC comes out of the deferred state when the required information is provided, and moves back to the Review Change by Change Approver (Individual, Virtual Board or Board) activity. If the required information isn’t provided the Change Manager will move the RfC to the Reject Change activity.
    2.150.3.7.6Output
    • Updated RfC
    • Completed Transmittal or Release package
    2.150.3.7.7Exit Criteria
    • The Implementation schedule has been approved
    • The associated work products have been staged for deployment
    2.150.3.8Step 8: Change Implementation
    2.150.3.8.1Purpose
    The purpose of the Change Implementation step is to implement or deploy the change into the designated environment(s). This step is performed for all types of change.

    2.150.3.8.2Roles and Responsibilities
    The assigned Change Analyst is responsible for managing the implementation activities per the plan, assigning tasks to Change Implementers.
    The Change Coordinator supervises the assigned Change Analyst in implementing the RfC and is accountable for success or failure of the plan.
    Change Analysts act as Change Implementers, performing the work to implement the change. Segregation of duties requires that implementers are different individuals than those who built the change.
    2.150.3.8.3Entry Criteria
    • The Implementation and release schedule has been approved
    • There is a completed Transmittal, and the Build Package or release has been staged for deployment
    2.150.3.8.4Input
    • Updated Approved RfC
    • Completed Transmittal
    • Completed Build Package or Release
    2.150.3.8.5Process Activity
    2.150.3.8.5.1 Coordinate Implementation Schedule
    The assigned Change Analyst manages the change’s implementation according to the plan, creating tasks assigned to the Change Implementers where these are needed to coordinate the tasks.
    2.150.3.8.5.2 Pre-Deployment Check
    The Change Coordinator ensures all requirements have been satisfied and the affected components are ready before giving the okay to the Change Implementers to perform their work.
    2.150.3.8.5.3 Implement Change
    The Change Implementer(s) implements the change into the designated environment(s). The Change Implementers may be different individuals for each environment. The implementation activities may be staged as needed for multiple environments. For example, implementing the change into the Test environment should precede implementing it into the Production environment, with the preceding testing being the developer testing, rather than systems acceptability testing performed per IRM 2.6.1.
    Post-Deployment Testing is performed to check the environment (i.e. file comparisons, general connectivity, file validation, etc.). A decision must be made to determine if the environment can be tested for the successful implementation of the change at the time. If the environment can be tested, the RfC moves to the Perform Environment Test Activity. If the environment cannot be tested due to such constraints as the application is not ready to be deployed, the RfC moves to the Close Change with Exception activity.
    2.150.3.8.5.4 Perform Environment Test
    The Change Implementer(s) perform environment verifications or tests depending upon the environment. The intent is to demonstrate the change has been implemented successfully. For less complex implementations, it may be sufficient to verify successful installation of the package. A decision will be made to determine if the implementation was successful. If it was completely successful, the RfC will move to the Record Success of Change Activity. If it was partially successful, it will move to the Record Partial Success of Change and clone change with remaining scope activities. If it is deemed unsuccessful, it will move to the Record Failure of Change activity.
    2.150.3.8.5.5 Record Success of Change
    When the Change is identified as successful, the Change Implementer or assigned Change Analyst updates the Implementation Task with that information. A notification of the success is sent to the Change Initiator, Front Line Manager, assigned Change Analyst, and the Change Coordinator. The RfC then moves to the Review and Close Change Step.
    2.150.3.8.5.6 Record Failure of Change
    A failed Change must be recorded as such by the Change Implementer or assigned Change Analyst and comments on the Implementation Task should specify areas where it was not successful. A notification is sent to the Change Initiator, assigned Change Analyst, Change Coordinator, and Front Line Manager. The RfC is then moved to the Remediate Unsuccessful Change Activity.
    2.150.3.8.5.7 Remediate Unsuccessful Change
    When the Change is identified as unsuccessful, the assigned Change Analyst updates the RfC with the required information and initiates remediation activities according to the “Back-out Plan.” The RfC is then moved to the Plan/Design/Build/Test Change Step to determine an alternative approach.
    2.150.3.8.5.8 Record Partial Success of Change
    The assigned Change Analyst updates the RfC with information regarding the partial success, identifying which CIs or Tasks were successfully completed and which were not. A notification is sent to the Change Initiator, Change Coordinator, and the Front Line Manager of partial success and reason.
    The original RfC is cloned by the Change Coordinator, to avoid re-entering all the information, but with only the CIs and Tasks that were not successfully completed included. This new, cloned RfC is moved to the Change Logging step so that it can be assessed, planned, reviewed and authorized by the Change Authority, and given a schedule for implementation. The original RfC is moved to the Review and Close Change step.
    2.150.3.8.6Output
    • Updated RfC
    Implemented Change
    • Backed-out Change
    • Cloned Change including portion of original RfC that was not completed
    2.150.3.8.7Exit Criteria
    • All activities associated with Implementing the Change or Backing out the change, have been completed
    2.150.3.9Step 9: Review and Close Change
    2.150.3.9.1Purpose

    In this Step the execution of the Change is reviewed and the Change Coordinator or Change Manager closes the RfC. This step occurs for all types of change. Some RfCs will be selected for Post Implementation Reviews by Change Management Analysts, because the change wasn’t fully successful or to audit process compliance.

    2.150.3.9.2Roles and Responsibilities

    The Change Coordinator reviews the change and the record of tasks performed and closes the RfC.
    Quality Assurance staff and Change Managers review RfCs for the purpose of identifying process improvements.
    Change Management Analysts validate adherence to process, analyze any deviations and conduct Post Implementation Reviews of selected RfCs.
    The Configuration Management Analyst will validate the Configuration Items were changed as planned.

    2.150.3.9.3Entry Criteria

    • All activities associated with implementing the change, or backing out the change, have been completed
    • The RfC has been rejected in a prior step

    2.150.3.9.4 Input

    • Implemented or Backed-out Change
    • Updated RfC ready for closure

    2.150.3.9.5Process Activity

    2.150.3.9.5.1 Evaluate Change Handling
    The Change Coordinator reviews the activities performed on the RfC with each Step in the process, and verifies that the RfC was categorized and handled correctly. They ensure every task and all required documentation updates have been completed.
    Quality Assurance staff will also sample RfCs to conduct their own evaluation of change handling, to identify potential process quality issues and opportunities for process improvement. See IRM 2.5.14 for more information on QA reviews.
    2.150.3.9.5.2 Review Change
    The Change Coordinator reviews all RfCs prior to closure for their effectiveness and results. The Change Coordinator’s review includes verification of the completion of all planned activities; notifications to stakeholders; no issuance of Incidents related to the changed CIs.
    i.A Change Manager supporting a CCB or the CAB may select changes for review on behalf of the Board(s) based on the results or the impact of the Change.
    ii.A Change Management Analyst will select RfCs that were not fully successful, that resulted in incidents, or have the potential for providing useful lessons learned, for a Post Implementation Review.
    2.150.3.9.5.3 Validate Change
    A Configuration Management Analyst will verify that the CIs in scope for the RfC were modified as specified in the RfC.
    2.150.3.9.5.4 Close Change
    The Change Coordinator changes the status of the RfC to Closed. A Change Manager for the responsible CCB may also perform this task if the Change Coordinator is unavailable.
    2.150.3.9.5.5 Post Implementation Reviews (PIR)
    A Change Management Analyst will conduct a review of each RfC selected for a PIR, with the objective of identifying whether the change was performed successfully, and if not, the root cause(s) of an RfC not achieving its intended objectives or causing incidents or other issues. All steps in the process may be reviewed, as well as interactions with other processes, such as Incident Management or Event Management. The PIR results in a report that describes the root cause, where the change was not completely successful, and recommendations for actions that would prevent similar problems in the future. The PIR report would be an input to IRS IT’s Problem Management process.
    2.150.3.9.6Output
    • Closed RfC
    2.150.3.9.7Exit Criteria
    • All activities associated with the RfC have been successfully completed.
    2.150.3.4 Tailoring Guidelines
    A critical success factor for this new Change Management process is that it be followed consistently across all IRS IT ACIO organizations. At a minimum, the mandates from the Change Management Directive document would be followed by all organizations, and the specific steps identified for each category of change in the process flow. However, organizations can tailor the authorization levels for changes and the scope of the changes that will be subject to the process prior to Production. It is recognized that some projects will want to limit the internal reviews required prior to FIT testing, or in some cases, prior to deployment into production. A tailoring of the process that limits the scope of changes subject to authorization, or that combines steps per agile development methods, could be requested, as long as the tailoring doesn’t result in changes affecting other organizations not being reviewed.
    All tailoring requests, with supporting rationale, should be submitted in writing to and approved by the Change Management PMO.
    2.150.3.4.5 Process Measurement

    Information on procedure measurements can be found in the Change Management Metric's Document which is located on the Change Management Program Share-Point site.
    2.150.3.4.6 Training
    All IT practitioners are asked to complete the Change Management Process Overview web-based course as an introduction to the guiding principles and process for Change Management. Additionally, a web-based course is planned for development to introduce ECMS and the activities necessary to initiate an RfC. However, this course will not be finished prior to wave one deployment of the process. In the interim, content planned for this course will be appended to the role-based courses, and removed once the web-based course is available in ELMS.
    Following web-based training, practitioners will be asked to consume Centra-recorded role-based courses role-based courses that are designed to teach individuals all procedural activities related to each role. Practitioners will complete these courses per the progression displayed in the graphic above until they have received all necessary training for the role assigned to them.
    2.150.3.4. 7 CMMI, ITIL, PMI Compliance
    The Capability Maturity Model Integration (CMMI) can be used to judge the maturity of an organization’s processes and related procedures and process assets and can be used to plan further improvements. CMMI sets the standard for the essential elements of effective and mature processes, improved with quality and efficiency.
    The Information Technology Infrastructure Library (ITIL) contains a collection of best practices, enabling organizations to build an efficient framework for delivering IT Service Management (ITSM) and ensuring they are meeting business goals and delivering benefits to facilitate business change, transformation, and growth.
    The Project Management Institute (PMI) organization advances the project management profession through globally recognized standards and certifications.
    This document uses CMMI, ITIL and PMI as a guide, to deploy leading practices to provide current and future business value to the IRS.
    2.150.3.4.8 Definitions, References
    2.150.3.4.8.1 IRS IT Definitions
    An IRS IT Glossary is available on the IPM Process Asset Library (PAL).
    2.150.3.4.8.2 References
    The following resources are either referenced in this document or were used to create it.

    • HP Service Manager, Processes and Best Practices Guide, Software Version 9.20 (June 2010)
    • IRM 1.5.1, Managing Statistics in a Balanced Measurement System (08/21/2009)
    • IRM 2.5.2, Systems Development, Software Testing Standards and Procedures (09/03/2010)
    • IRM 2.5.14, Systems Development, Quality Assurance (06/30/2010)
    • IRM 2.6.1, Test Assurance and Documentation, Standards and Procedures (11/05/2010)
    • IRM 2.150.1, Configuration and Change Management (07/24/2013)
    • ISO/IEC 20000, Volume 1, Service Management System Specifications, 2011
    • ITIL Glossary of Terms and Definitions, Version 3 (30 May 2007)
    • ITIL Service Transition, Version 3, Chapter 4.2, Change Management (2007)