Section_J-Section_H.3_Attachment_ChM_Process_Description_V0_09_09_28_2012.pdf

OS:CIO:EO:ChM-PD-ChM_PD-V0.8-09282012 Page 1 of 31

Internal Revenue Service

Solicitation Number: TIRNO-16-R-00026 IRS Integrated Enterprise Portal 1.5 (IEP 1.5)

H.3 IRS IT Change Management Process Description

September 28, 2012

OS:CIO:EO:ChM-PD-ChM_PD-V0.8-09282012 Page 2 of 31

IRS IT Change Management Process Description

Transmittal

Date:

09/28/12

Reason for Transmittal:

This transmits a new Change Management (ChM) Process Description (PD).

Nature of Material/Changes:

The Change Management process provides an IRS IT-wide method of documenting change to Configuration Items (CIs), assessing impact, scheduling, implementing and closing Requests for Change (RfCs).

Applicable Audience The Change Management process description is applicable to all IRS IT staff.

Implementation language This PD is effective upon signature.

Signature

Lauren Buschor, ACIO Enterprise Operations Date

NOTE: This document has not been reviewed by the ACIO EO and is a discussion draft only.

OS:CIO:EO:ChM-PD-ChM_PD-V0.8-09282012 Page 3 of 31

Table of Contents

1. INTRODUCTION

1.1 ADMINISTRATION

1.2 PURPOSE OF PROCESS DESCRIPTION

1.3 DOCUMENT OVERVIEW

2. PROCESS OVERVIEW

2.1 WORK PRODUCTS

2.2 ROLES AND RESPONSIBILITIES

2.3 CHANGE MANAGEMENT PROCESS FLOW DIAGRAM

3. CHANGE MANAGEMENT PROCESS STEPS

3.1 STEP 1: CHANGE PRE-COORDINATION AND PLANNING

3.2 STEP 2: CHANGE LOGGING

3.3 STEP 3: CHANGE REVIEW

3.4 STEP 4: ASSESS AND EVALUATE CHANGE

3.5 STEP 5: AUTHORIZE CHANGE

3.6 STEP 6: PLAN, DESIGN, BUILD, AND TEST CHANGE

3.7 STEP 7: SCHEDULE AND APPROVE CHANGE

3.8 STEP 8: CHANGE IMPLEMENTATION

3.9 STEP 9: REVIEW AND CLOSE CHANGE

4. TAILORING GUIDELINES

5. PROCESS MEASUREMENT

6. TRAINING

7. CMMI, ITIL, PMI COMPLIANCE

8. DEFINITIONS, REFERENCES

8.1 IRS IT DEFINITIONS

8.2 REFERENCES

Table of Figures

FIGURE 1 - ROLES AND RESPONSIBILITIES

FIGURE 2 - CHANGE MANAGEMENT PROCESS FLOW DIAGRAM

OS:CIO:EO:ChM-PD-ChM_PD-V0.8-09282012 Page 4 of 31

Title:

Change Management

Process Description

Version: 0.9

09-28-2012

Supersedes: 0.8

06-13-2012

1. Introduction

1.1 Administration

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

1.2 Purpose of Process Description

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.

1.3 Document Overview

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.

2. Process Overview

2.1 Work Products

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.1.1 Work Products (Inputs) Used by This Process

The following work products are used to assist in the implementation of the Change Management process:

OS:CIO:EO:ChM-PD-ChM_PD-V0.8-09282012 Page 5 of 31

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

OS:CIO:EO:ChM-PD-ChM_PD-V0.8-09282012 Page 6 of 31

2.2 Roles and Responsibilities

Many roles1 are involved in the Change Management process. This section defines the roles used throughout this document in terms of their responsibilities.

Figure 1 - Roles and Responsibilities

Role Description Definition of Responsibility

Change Advisory Board (CAB)

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 Change being reviewed.

Assigned Change Analyst

The assigned Change Analyst for a given RfC is considered responsible for advancement and execution of the RfC through the Change process. They are responsible for coordinating the assessment of the RfC and ensure that the tasks necessary to complete the Change are planned, scheduled, resourced, and executed as planned. Assigned Change Analysts are delegated this responsibility by their Change Coordinator. The Assigned Change Analyst may be the Change Initiator.

Supporting Change Analyst

Supporting Change Analysts are those persons performing an analytical, developmental, or testing task somewhere within the Change Management life cycle. They are typically considered Subject Matter Experts (SMEs), with specific expertise in some aspect of the proposed Change.

Change Authority The Change Authority 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 for each RfC is accountable for the overall execution and success once it has been assigned to a technical team to review. The Change Coordinator is responsible for assigning a Change Analyst to act upon each assigned RfC. While they are primarily overseeing the assessment, planning, and implementation work done by others, they will sometimes act in the role of Change Initiator, Assigned/Supporting Analyst, or Implementer. For those RfCs requiring Governance Approval prior to authorization, they coordinate the transmission and return receipt of the dispositioned RfCs.

Change Implementer (Change Analyst)

The Change Implementer is the Change Analyst who implements or installs the changed CI, or modifies the device, as specified. Because of Segregation of Duties, the Change Implementer should be a different person than the Change Analyst who built the Change.

Change Initiator (Change Analyst)

The Initiator is the Analyst or Manager responsible for initiating the technology RfC, typically associated with an Incident or Work Request.

Other triggers may require initiation from a Problem Manager, Release Manager, or Service Desk Technician. Maintenance work not covered by a Work Request would also trigger an RfC.

1 Roles and responsibilities should be assigned to individuals who have the knowledge and skills to perform the tasks required. Project roles vary from project to project and may be performed by a variety of skilled individuals in many different position titles at the IRS.

OS:CIO:EO:ChM-PD-ChM_PD-V0.8-09282012 Page 7 of 31

Role Description Definition of Responsibility

Change Manager

The Change Manager role supports the Change Authorization and Schedule/Approve Change Steps by reviewing the submitted RfCs.

They validate that the RfC was completed correctly and ensure it follows the appropriate work flow. The Change Manager decides how the authorization of a Change will proceed through the workflow either via a Board meeting, virtual Board meeting, or individual. The Change Manager collects and reviews the Change Authority decisions and registers whether the Change is authorized or not. The Change Manager role, though probably a different individual, decides how an RfC’s schedule and release is approved, and provides administrative support to the Change Advisory Board. The Change Manager will review the closure of RfCs and may select changes for post implementation reviews.

Change Management Analyst

The PMO Change Management Analyst has responsibility for ensuring adherence to the Change Management process and to verify correct closure of an RfC. These analysts may review a Change at any step in its life cycle.

Configuration Management Analyst

The Configuration Management Analyst is responsible for reviewing CIs to ensure that changes were made as documented in the RfC.

Front Line Manager The Change Initiator’s Front Line Manager is responsible for reviewing and authorizing the RfC after it has been submitted by the Change Initiator.

Quality Assurance Representative

The Quality Assurance (QA) Representative is an external third party assuring compliance with the documented Change Management process. The QA Representative may audit a process anywhere in its lifecycle.

OS:CIO:EO:ChM-PD-ChM_PD-V0.8-09282012 Page 8 of 31

2.3 Change Management Process Flow Diagram2

Figure 2 - Change Management Process Flow Diagram

Log Request for Change

Change Initiator

Plan/Design/Build/Test

Change

Change Analyst / Coordinator

Authorize Change

Change Authority

Review Change

Change Coordinator

Implement Change

Change Implementer

Schedule/Approve Change for Deployment

Change Approver / CAB

Review & Close Change

Change Coordinator

C

M

S

Assess & Evaluate Change

Change Analyst

Change Pre-Coordination and Planning

Change Initiator

Emergency * Standard

Low Risk

Normal

Moderate/High

Risk

Development or

Core Engineering

Effort

* Emergency change workflow will expedite deployment, but change will be documented before closure of the RFC

2 508 Compliance requires that a text version of a process flow diagram be included in any document or the diagram is not permitted.

Refer to http://www.section508.gov for further direction.

http://www.section508.gov/

OS:CIO:EO:ChM-PD-ChM_PD-V0.8-09282012 Page 9 of 31

3. Change Management Process Steps

3.1 Step 1: Change Pre-Coordination and Planning

3.1.1 Purpose

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

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

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

3.1.5 Process Activity

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

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

OS:CIO:EO:ChM-PD-ChM_PD-V0.8-09282012 Page 10 of 31

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

3.2 Step 2: Change Logging

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

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

3.2.3 Entry 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

3.2.4 Input

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

3.2.5 Process Activity

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

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.

OS:CIO:EO:ChM-PD-ChM_PD-V0.8-09282012 Page 11 of 31

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.

3.2.6 Output

A logged RfC

A withdrawn RfC

3.2.7 Exit Criteria

The completion of the Logging step, or

The completion of the Withdraw action

3.3 Step 3: Change Review

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.

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.

The Change Initiator may be requested to provide additional information during this step.

3.3.3 Entry Criteria

The RfC completes the Change Logging Step by being submitted by the Initiator’s Front-Line Manager

3.3.4 Input

A logged RfC ready for review with the Assignment Group presumed to be primarily responsible for carrying out the RfC

3.3.5 Process Activity

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

OS:CIO:EO:ChM-PD-ChM_PD-V0.8-09282012 Page 12 of 31

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.

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.

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.

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.

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.

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.

3.3.6 Output

RfC moved to Change Assessment and Planning step, or

A Rejected RfC, with reasons

3.3.7 Exit Criteria

An RfC pushed to the next step, or

The rejection of the RfC

OS:CIO:EO:ChM-PD-ChM_PD-V0.8-09282012 Page 13 of 31

3.4 Step 4: Assess and Evaluate Change

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

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.

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.

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

3.4.5 Process Activity

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

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.

OS:CIO:EO:ChM-PD-ChM_PD-V0.8-09282012 Page 14 of 31

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

4. If Necessary, Change Primary Change Coordinator

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.

5. Plan and Schedule Change

The assigned Change Analyst ensures that the RfC is given a schedule for deployment/release.

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

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.

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.

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.

OS:CIO:EO:ChM-PD-ChM_PD-V0.8-09282012 Page 15 of 31

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

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

3.5 Step 5: Authorize Change

3.5.1 Purpose

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.

3.5.2 Roles 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.

3.5.3 Entry Criteria

The RfC has completed the Assess and Evaluate Change Step and requires Authorization.

3.5.4 Input

An assessed and evaluated RfC, with a plan and schedule for deployment, with all assessments included.

3.5.5 Process Activity

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

OS:CIO:EO:ChM-PD-ChM_PD-V0.8-09282012 Page 16 of 31

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.

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.

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.

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.

3.5.6 Output

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.

3.5.7 Exit Criteria

The assessed RfC is authorized for Change, or

The RfC is rejected

3.6 Step 6: Plan, Design, Build, and Test Change

3.6.1 Purpose

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

OS:CIO:EO:ChM-PD-ChM_PD-V0.8-09282012 Page 17 of 31 ensure that the Change Analysts are aware of pending work. This Step is used for Development or Core Engineering efforts only.

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.

3.6.3 Entry Criteria

An Authorized RfC requiring Plan/Build

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.

3.6.5 Process Activity

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

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.

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.

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.

OS:CIO:EO:ChM-PD-ChM_PD-V0.8-09282012 Page 18 of 31

The RfC then moves to the Passed Test Activity.

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

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.

3.6.6 Output

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)

3.6.7 Exit Criteria

Change has been planned, designed, built, and tested, as required, and is ready for release and deployment.

3.7 Step 7: Schedule and Approve Change

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.

3.7.2 Roles and Responsibilities

The Change Manager for 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.

3.7.3 Entry 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

3.7.4 Input

An updated RfC

The Transmittal and/or other Release documentation

OS:CIO:EO:ChM-PD-ChM_PD-V0.8-09282012 Page 19 of 31

3.7.5 Process Activity

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

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.

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.

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

OS:CIO:EO:ChM-PD-ChM_PD-V0.8-09282012 Page 20 of 31 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.

6. Place 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.

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

3.7.6 Output

Completed Transmittal or Release package

3.7.7 Exit Criteria

The Implementation schedule has been approved

The associated work products have been staged for deployment

3.8 Step 8: Change Implementation

3.8.1 Purpose

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.

3.8.2 Roles 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.

3.8.3 Entry 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

3.8.4 Input

Updated Approved RfC

Completed Transmittal

Completed Build Package or Release

3.8.5 Process Activity

1. Coordinate Implementation Schedule

OS:CIO:EO:ChM-PD-ChM_PD-V0.8-09282012 Page 21 of 31

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

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.

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.

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.

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.

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.

OS:CIO:EO:ChM-PD-ChM_PD-V0.8-09282012 Page 22 of 31

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.

3.8.6 Output

Implemented Change

Backed-out Change

Cloned Change including portion of original RfC that was not completed

3.8.7 Exit Criteria

All activities associated with Implementing the Change or Backing Out the Change, have been completed

3.9 Step 9: Review and Close Change

3.9.1 Purpose

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.

3.9.2 Roles and…