ITSM_Change_Management.doc

ITSM Change Management

U.S. Department of the Navy / Military Sealift Command

U.S. Navy

Military Sealift Command (MSC)

Cover Page

ITSM Change Management MSC Information Technology Service Management (ITSM) Program

July 2013 Revision 1.0 ITIL® is a Registered Trade Mark and a Registered Community Trade Mark of the Office of Government Commerce (OGC), and is Registered in the U.S. Patent and Trademark Office. Crown copyright material is reproduced with the permission of the Controller of HMSO and the Queen’s Printer for Scotland.

Executive Summary

The N6 ITSM Program is following the ITSM framework based on the ITIL V3 framework. This framework is contained in Figure 1. ITSM Processes and Functions below.

Figure 1 ITSM Processes and Functions

ITIL defines Change Management as the overall process responsible for controlling the lifecycle of all changes to an organization’s IT services. Change Management helps ensure that both business and IT goals properly align with the changes needed to build and transition new or changed IT services into operations. The primary objective of Change Management is to enable beneficial changes to be made with a minimum of disruption to service.

The remainder of this document contains the Change Management process design for MSC N6 ITSM program. It describes the goals and objectives, scope of ITSM change management for N6, roles and responsibilities of those involved in change management, policies that will need to be adopted to enact change management according to this design, overall process, a list of supporting procedures, suggested key performance indicators, and other relevant information pertaining to change management.

Document Control

Document Title:

· Provide number and name of document complying with ISO 9001/20000 standards.

· File name must match.

Military Sealift Command (MSC) Information Technology Service Management (ITSM) Change Management Design

Document Owner:

· Identify role responsible for document and approval.

· Identify last known individual assigned to role.

· Do not use groups or multiple names.

Document Content:

· Provide table of contents for document with outline and page numbers.

1.0 Purpose of this Document

2.0 Goals and Objectives

3.0 Scope

4.0 Benefits

5.0 Risks

6.0 Roles and Responsibilities

7.0 Policies

8.0 Process Flow

9.0.

Performance Reports

10.

Key Performance Indicators

Document Control:

· Do not forget to update footer with the same revision and date information.

· Revision document as follows: Draft 0.X, Released 1.0, Minor Change 1.1, Major Change 2.0.

· Created By and Document Owner do NOT have to be the same person.

· Approval through Change Management.

· Insert rows into table for a new entry if needed.

Table of Contents

Contents

1Cover Page

2Executive Summary

3Document Control

Purpose of This Document

Goals and Objectives

Scope

Roles and Responsibilities

Policies

15Normal, Standard and Emergency High Level Process Flows

Performance Reports

Key Performance Indicators (KPI’s)

21Appendix A – Unified Change Process Diagram

25Appendix C – RACI Chart

30Appendix D – List of Supporting SOPs

30TBDAppendix E – Remedy Status/Status Reason Map

31Appendix E – Remedy Status/Status Reason Map

33Appendix F – Checklist and Approval List

33TBDAppendix G – Remedy Change Management Process Overview and Procedures Process Flow Charts

34Appendix G – Remedy Change Management Process Overview and Procedures Process Flow Charts

Purpose of This Document This document describes the framework and process to initiate, develop, review, and improve Change Management within Military Sealift Command N6. This document is a process design baseline used to guide the implementation of Change Management within MSC N6. This document includes:

· Purpose: of this document

· Goals and Objectives: of the process

· Scope: of support for Change Management within MSC as well as approach to implementation

· Benefits: of implementing ITSM Change Management process

· Risks: potential risks and problems to be avoided; this section does NOT indicate existing problems with process

· Roles and Responsibilities: of individuals, organizations, and third-parties that support change

· RACI Chart: of roles and responsibilities with responsible, accountable, informed, and consulted indicators

· Policies: requirements, standards, rules, guidelines to support change management

· Process Flow: start-to-end diagram of high-level process activities and decisions

· Procedures: list of procedures (step-by-step work instructions to carry out the process in the form of standard operating procedures or operator’s manual) to support the process and where they can be found

· Outputs: list of artifacts and other outputs that support the process

· Performance Reports: further definition of reporting outputs including weekly, monthly, quarterly, and annual process reporting, reviews, and audits

· Key Performance Indicators: measurable process success criteria; no more than three is recommended

· Appendices: of supporting documentation

This document will be integrated into a quality management system to ensure it is adequately controlled through the use of a quality documentation repository, standards, revision control, an approval process, centralized posting, communication, dissemination, annual review, training, audit, improvement mechanisms, measurement, reporting, and archival. This will facilitate a common understanding of in scope processes and assist in the enforcement policy.

2 Goals and Objectives

The goals of IT service management are to successfully deliver, maintain, and improve IT services and to deliver IT solutions that are in line with the requirements of the business at an acceptable cost. N6’s goal of change management is to provide cost-effective change management at agreed levels of quality in terms the customer understands and in ways that can be measured against established performance metrics.

The objectives of Change Management are to:

· Manage an efficient, effective, and comprehensive change management process to include entrance and exit criteria for the environment.

· Receive and record changes, assess the impact, cost, benefit and risk of proposed changes, ensure business justification and appropriate approvals are obtained.

· Manage and coordinate change implementation, monitor and report on implementation, review and close change requests.

2 Scope

The scope of the Change Management process is limited to change implementations that will cause:

· addition of a new service

· removal of an existing service,

· modification to an existing service,

· a service to become unavailable or degraded during service hours,

· the CMDB to require an update,

· program or portfolio related changes (as needed).

The scope of MSC N6 ITSM Program’s Change Management process is limited to supporting those personnel authorized to request and deliver change into the MSC N6 environment. In addition, the change management process will adhere to the BMC Remedy 7.5, out of the box (OOB) workflow, processes, and procedures as much as possible.

MSC N6 ITSM Program intends to achieve the full scope of change management through an iterative approach. This will be defined for Standard, Normal, and Emergency changes. This initial iteration will be piloted in support of those services categorized as Standard changes (i.e., published in the MSC N6 service catalog [Change Type 0/1]). Future phases of implementing Change Management for Normal (Type 2/3) and Emergency changes within N6 will be determined at a later date.

Benefits

1. Infrastructure management improvement

2. Unified process to integrate all activities performed by various stakeholders throughout the process Risks

1. Lack of clarity and agreement on the responsibilities of each participant in the Change process.

2. Lack of an agreement on an enterprise definition of Standard (Type 0 or 1), Normal (Type 2 or 3), and/or Emergency change.

3. Not determining and integrating interim processes and/or procedures for those areas outside the scope of the Change Management process

4. Not taking a baseline of current Change Management performance nor defining meaningful metrics and implementing these metrics to measure performance post implementation to compare performance.

5. Push back on the use of ITIL terminology when establishing Change Management. Though important in all areas of service management, it is critical with change management to use ITIL terminology to establish a mode of operations and disseminate ITIL concepts throughout the organization.

6. Lack of training on supporting ITSM tools, e.g. BMC Remedy.

These risks will monitored and managed through Risk Management mitigation strategies tracked in a Risk Management matrix that will be reviewed according to an agreed upon schedule (or at a minimum, monthly). As risks are identified and mitigations determined they will be added to the risk management matrix.

Roles and Responsibilities The table below lists the different roles that are involved in the Change Management process, along with their respective responsibilities. A RACI chart is included in Appendix C to illustrate the roles and responsibilities across all Change stakeholders.

· Enforce Change Management process is being followed correctly

· Maintains goals and objectives within the process

· Designs and recommends metrics and reports for management

· Provides a fully functional Change Management process resulting in customer satisfaction

· Responsible for ensuring that resources have the required skill sets

· Maintains Continuous Process Improvement on a regular basis

· Decides who is invited to CAB meetings

Change Manager R

· Convenes and chairs CAB meetings

· Convenes and chairs ECAB meetings

· Reviews the risk & impact analysis to ensure that this has been performed thoroughly.

· Ensures that appropriate actions have been planned to minimize both the risk of failure and the impact on users during change implementations.

· Ensures that the timing of planned implementations does not conflict with other planned changes or events.

· Obtains approval for changes through the CAB.

· Single authority to set CRQ status for CAB approval review.

· Manages Urgent CRQs through the life cycle

· Analyzes Change records to determine any trends or apparent problems that occur

· Identifies, documents, and reports to management changes that by-pass (unauthorized changes to the environment) the Change Management process and provides information to the Change Process Owner to address compliance requirements

· Management Reporting – KPIs

· Assists the Process Owner in identifying and prioritizing process improvements

· Ensures adherence to the process

· Approves or rejects applications for Standard Pre-Approved Changes (SPACs) after CAB review

· Conducts Post Implementation Reviews

· Registers changes as needed to handle requests for change.

· Determines the initial risk & impact for requested changes.

· Initiates implementation phase by creating tasks.

· Monitors the progress of changes.

· By proxy of the Change Manager, changes CRQ status from scheduled for review to scheduled for approval.

· Develops an agenda for CAB meetings, decide attendees, then circulates CRQs for prior consideration

· Documents minutes of CAB meetings

· Issues and maintains Forward Schedule of Change (FSC)

· Conducts ongoing review of all CRQ(s)

· Verifies initial prioritization of CRQ(s)

· Verifies initial Change Category

· Verifies initial CRQ Urgency

· Verifies completeness of CRQ

· Identifies potential Emergency Changes and advises Technical Sponsor of Emergency Change process

· Supports Change Managers in Final Approval of acceptable Minor Changes

· Updates the Change log with all progress

· Collects artifacts to present to the CAB for review gate review and approval to move CRQ to next phase

· Reviews deferred CRQs awaiting consideration or awaiting action

· Back-up for Change Manager

· Participates in the Post Implementation Review as necessary

· Advises Change Manager and Change Process Owner of process improvement opportunities

· Conducts initial Change Management review of all CRQs

· Validates initial prioritization of CRQs

· Recommends initial Change Category Type

· Validates initial CRQ Urgency

· Validates initial completeness of CRQ

· Identifies potential Urgent Changes and provides rationale

· Final approval of acceptable Minor Changes

· Final functional approval of Significant and Major Changes prior to handoff

· Represents significant and major changes at CAB for approval review

· Communicates with all necessary parties to coordinate Change build, test and implementation

· Manages implementation with user community

· Ensure functional teams update the Change log with all progress

· Reviews implemented Changes to ensure they have met their objectives

· Reviews Pre-Select decisions within assigned areas to ensure completeness

· Reviews outstanding CRQs awaiting consideration or awaiting action

· Advises Change Manager and Change Process Owner of process improvement opportunities

· Ensures that planned application changes are tested before they are transferred to production.

· Associating related CIs, incidents, and services to the change.

· Providing status updates to requestors upon request.

· Reviewing change plans and schedules.

· Reviewing all completed tasks.

· Conducting post-implementation reviews to validate the results of the change.

· Determining requestor satisfaction with the overall change request.

· Tier II/III staff performing the work to deliver the change

Change Requestor R

· Initiates Change Request (CRQ)

· Completes all mandatory information for an CRQ

· This shall be the Technical Sponsor within N6, government lead within N6 for the change.

· Initial assessment of the CRQ and returns incomplete or incorrect CRQs to Change Requestor

· Reviews CRQs that are submitted to the CAB

· Evaluates modified Significant and Major Changes for schedule impact

· Participates in all Change Advisory Board (CAB) meetings

· Assesses likely impact to the live environment of the CRQ

· Assesses the implementation resources required of the CRQ

· Assesses the ongoing costs of the CRQ as appropriate

· Assesses the impact of not doing the CRQ

· Participates in the scheduling of Significant and Major CRQs

· Validates the prioritization and Change Category

· Considers all Changes on the agenda and advises the Change Manager about which CRQs should be approved

· Reviews implemented Changes to ensure they have met their objectives

· Participates in Post Implementation reviews as needed

· Reviews Post Implementation Reviews as needed

· Membership consists of N6XX Branch Managers.

· Permanent Members include:

· Change Manager (chair)

· Change Facilitator

· Ashore Programs

· Afloat Programs

· Business Programs

· Systems Engineering

· Information Assurance

· IT Service Management

· Enterprise Architecture

· Human Capital Planning / Financial Management (Pre-Select)

· Business Systems

· Communications Security

· Ashore Operations

· Afloat Operations

· Participates in all relevant Emergency Change Advisory Board (ECAB) functions

· Quickly assesses if the Emergency CRQ is in fact an Emergency CRQ

· Quickly assesses likely impact to the environment of the Urgent CRQ

· Quickly assesses the implementation resources required of the Urgent CRQ

· Quickly assesses the impact of not doing the CRQ

· Advises the Change Manager if the CRQ should be approved

· Participates in a Post Implementation Review if necessary

· Membership includes:

· Change Manager (chair)

· Senior IT Management (most affected, back-up or designated individual)

· Change Facilitator

· Technical SME(s)

· IA, EA, DADMS, and PMs

· Service Delivery Manager.

· Additional members of the ECAB may be required based on the requirements of the Emergency CRQ.

· These may include:

· If exceeds costs thresholds, Service Delivery Portfolio Manager and/or Deputy Director of Programs or Operations (affected area)

· Others as deemed necessary to assess the Emergency CRQ

Policies

General Policies

· The Change Management process will be an overarching, unified process followed by all MSC N6 stakeholders and customers to initiate, define, plan, build/implement, deploy, and manage changes to the IT environment under N6 control. The Change Management process will align to the N6 structure, roles and responsibilities, and processes developed by the ISIDORE project and approved 20 September 2011 by RDML Wray.

· The Change Management process and supporting procedures will reflect the ITIL, CPIC, PM, Systems Engineering, Software Development, DADMS, EA, and IA touch points (and others as applicable). See Change Management Process Diagram in Appendix A.

· The Change Management process will be integrated within the ITSM tool, BMC Remedy 7.5. All changes will be logged and tracked within Remedy. Change requests and associated tasks will be recorded with a unique identification number.

· All persons implementing change must follow the Change Management process.

· Any person responsible for implementing an unauthorized change or not following the process may be held liable for the negative impact determined by management (applicable consequences will be assessed up to and including termination).

· For every change request, the CAB Membership (Branch Managers) shall review and provide final disposition. The CAB Member shall assign a government delegate who will serve as their proxy when the CAB Member is unavailable, as set forth in the CAB Charter.

· In case of an emergency, all personnel can report and submit an Emergency Change Request. A request is considered an emergency if it matches any of the criteria established in the current Emergency Change Request process.

· Emergency Change Requests will be reviewed and approved by the ECAB.

· CRQ durations thresholds will be electronically monitored and email alerts sent to the appropriate personnel when thresholds are exceeded.

· If an unsatisfactory CAB decision is received, escalation consideration can be requested through the ITSM Branch Manager, as set forth in the CAB Charter.

Role Polices

· The Change Management Process Owner (CM Process Owner) is the government staff Accountable for overall implementation of the Change Process, the accurate tracking of CRQs through completion and reporting to the CAB. The Change Management Process owner is responsible for correctly assigning the CRQ in Remedy. The CM Process Owner is the main interface with the CAB, Infrastructure Change Manager, Infrastructure Change Assignee, and/or Infrastructure Change Implementer throughout the change process.

· The Infrastructure Change Manager (Government Lead for the CRQ) is Accountable for the overall successful completion of the CRQ. The Infrastructure Change Manager is responsible for designating the correct individual as the Infrastructure Change Assignee. Infrastructure Change Managers are the main interface with the CM Process Owner, the Infrastructure Change Assignee, and the CRQ requestor. The Infrastructure Change Manager is the sponsor of the CRQ at the CAB representing the requestor. A single organization can have several Infrastructure Change Managers.

· The Infrastructure Change Assignee (Contractor or Government) is Responsible for planning and implementing assigned changes. This may be a contractor acting as the project or task lead for the CRQ. For Remedy, this is the Queue Manager of the Support Group assigned major responsibility. The Change Assignee may work actively on the change or coordinate the efforts of other groups or individuals.

· The Infrastructure Change Implementer (Contractor). Change implementers are support people or groups responsible for executing the change.

· The Change Implementer and Change Assignee will work on CRQs based on priority and date received.

· The GSD is the Single Point of Contact (SPOC) for receiving change requests via email or the Service Catalog interface as well as creating the CRQ. The CRQ is then assigned to the CM Team.

· The CM team will review CRQs for completeness, confirming appropriate timing and Tier 1 organizational categorization.

· The Change Implementer and Change Assignee will work on CRQs based on priority and date received.

Workflow Policies

· CRQs approvals are required if they have the status reason “IA Approval”, “EA Approval” , “DADMS Approval”, and “PM Approval: under Planning and Progress (PP). The CM Team will add these as ad hoc approvals for each approval required.

· The CM Team will place CRQs in Scheduled for Approval (SA) once all necessary IR approvals are received.

· CRQs in SA not approved by the CAB will be rejected for rework (“Reject, Status Reason = Insufficient Change Data, reject for rework”) by the CM Team.

· CRQs in SA not approved by the CAB shall be placed in Status “Cancelled” by the CM Team with the appropriate status reason selected.

· CRQs in SA that require Pre-Select (as determined by the CAB), will have an ad hoc approval for “Pre-Select Approval” with the status reason “Pre-Select Approval” added by the CM Team.

· The CM Team will add the following information to the Assignment tab when the CRQ is in “S” status:

a. Infrastructure Change Manager (CM) = Government Lead (Functional Sponsor)

b. Infrastructure Change Assignee (Change Assignee) = Government Task Lead, Contract Lead, or Queue Manager

c. Infrastructure Change Implementer (Change Implementer) = Queue Manager or Support Group performing the work.

· All Queue Managers shall be designated as a Change Assignee (Change Assignee).

· The Change Assignee is responsible for change the CRQ status to “Implementation in Progress,” selecting the appropriate status reason, and managing the necessary tasks to be tracked in the Tasks tab. Multiple tasks require a final task of CM Review to be assigned to the CM Team for final closure. In the case of one Implementer with no tasks required, the Change Implementer is the Queue Manager.

· When the Change Assignee puts the CRQ in the status of “Implementation in Progress,” (s)he will add an Actual Start Date to the Dates tab.

· The CRQ will be assigned to an individual assignee by the Change Implementer; however, tasks to complete under the CRQ may be assigned to more than one assignee.

· The Change Assignee is responsible for changing the CRQ’s status reason to reflect the appropriate progress phrase, which shall include at a minimum:

a. In Build

b. In Test

c. In Deployment

· If no tasks are used in the CRQ, the Change Implementer or Change Assignee shall change the status to “Completed” when all work is completed.

· The requestor shall confirm positive completion within 30 days of the CRQ being requested. If no response is received, then the CRQ is automatically closed.

· If the requestor responded negatively to the completed status, the CM Team shall place the CRQ in “Pending” status with a status reason of “Task Review.” The CM Team shall provide this information to the CM for appropriate action and also to be brought as information to the CAB.

· The CM Team will be able to manually close a CRQ after CAB review.

· CRQs may be placed into “Pending” status by the CM Team, the CM, a Change Assignee, or a Change Implementer. The CM Team shall be responsible for verifying the “Pending “status with the CM. The CM shall be responsible for approving the reason for placing the CRQ in “Pending” status. The CM Team shall notify the CAB of all CRQs placed in “Pending” Status. The CM shall be responsible for explaining the status reason to the CAB if required.

· CRQs placed in “Cancelled” status may be restarted.

· CRQs in “Cancelled” status may not be closed.

· CRQs may only be placed in “Cancelled” status by the direction of the CAB on behalf of the requestor or by the CM Team for administrative purposes (e.g., duplicate CRQs). The CM Team is solely responsible for cancelling a CRQ or restarting a cancelled CRQ.

· CRQs that result in a project will have a Project Ticket created to which the CRQ will be related.

· If a CRQ is being tracked as a project, am Effort Log will be implemented to track timeframes for each phase of the CRQ.

· The CM Team will have the ability to change the status of a CRQ in every phase of the workflow to send the CRQ backward or forward in the workflow as needed.

· A CRQ’s Change Reason shall be designated by the CRQ requestor.

· CRQ business justification is required and shall be provided by the CRQ requestor.

· The Change Environment affected by the CRQ is required and shall be designated by the GSD or the CM Team.

· The Tier I Op Cat is required in the CRQ and shall be designated by the GSD or the CM Team.

· The Tier I Product Cats are required in the CRQ and shall be designated by the GSD or the CM Team

· The “Requested For” field in the CRQ is for the Functional Owner.

· The “Requested By” field in the CRQ is for the actual CRQ requestor.

· The Change Implementer and Change Assignee are required to enter work log information to provide the most recent update to work performed on a CRQ.

· Task Implementers are required to enter work log information to provide the most recent update to work performed on a CRQ.

· Incidents and CRQs should be related to each other where applicable.

· Scheduled Start and End Dates shall be captured during IR. The CM Team shall be responsible for entering these dates into the CRQ.

· The GSD shall complete the MSC CCR Values tab with data submitted by the requestor.

· Impact and Urgency will be determined using the Remedy business rules pertaining to Impact and Urgency. The GSD or the CM Team shall enter the Impact and Urgency for the CRQ.

· The Risk Level shall be entered by the CM Team as determined by the IR and reflect the risk of failure on a scale of 1 to 5 where 1 is the lowest and 5 is the highest.

Question

· MSC N6 will utilize ITIL change type definitions (see Appendix B) that will determine the change process followed. These change types are Standard, Normal and Emergency. Within each type, further classifications will be defined and agreed upon by the N6 change management stakeholders. Tier 1, 2, 3 (excluded external third-party vendors) support personnel and management should request Change Management process / system training once granted access to the Change Management module.

Normal, Standard and Emergency High Level Process Flows The overall process flow for Change as aligned to Remedy 7.5 is depicted in the Figure 2 below. This process is for Normal Changes. Standard Changes will exercise an expedited process flow based on the Normal Change flow, skipping specified steps, CAB reviews and/or Status Gates. Emergency Changes will also be an expedited process flow based on the Normal Change flow but with additional communication requirements. These process flows are depicted in Figure 3 – MSC Standard Change Management High Level Process View and Figure 4, MSC Emergency Change Management High Level Process view.

Figure 2 – MSC Normal Change Management High Level Process View

The Change Management Process Flow in BMC Remedy 7.5 for Normal Changes is as follows:

· The CRQ is submitted by the requestor and is placed in the “Request for Authorization” Status.

· The CM Team reviews the CRQ, ensuring all fields have been correctly completed. If there is sufficient information provided the CRQ is placed in the “Request for Change” Status

· Next, it is reviewed at the Initial Review/Technical Review Board meeting and Impact Analysis is conducted. During this time the CRQ is placed in the “Planning in Progress” Status, with the appropriate Status Reason (DADMS, IA, EA, or PM Approval).

· Once the Impact Analysis is complete, and the CRQ is ready for review, and is placed in the “Scheduled for Approval” Status, it is presented to the CAB.

· Once approved for implementation by the CAB, the CRQ is placed in the “Scheduled” Status.

· When the assigned teams are ready to implement the change, the Queue Manager will place the CRQ in the “Implementation in Progress” Status, with the appropriate Status Reason (Build, Test, and Deployment), and assign tasks accordingly.

· Once all tasks have been completed, the CRQ is automatically placed in the “Completed” Status. An email needs to be sent to the CAB inbox indicating that the change has been completed and can be closed, and the CM Team will place the CRQ in the “Closed” Status.

· If tasks were not assigned, an email will need to be sent to the CAB inbox indicating that the change has been completed and can be closed, and the CM Team will place the CRQ in the “Completed” & “Closed” Status.

Figure 3 - Standard Change High Level Process Flow

The Change Management Process Flow in BMC Remedy 7.5 for Standard Changes is as follows:

· The CRQ is submitted by the requestor and is placed in the “Request for Authorization” Status.

· The CM Team reviews the CRQ, ensuring all fields have been correctly completed. Standard Changes are preapproved and preauthorized; therefore, if there is sufficient information provided the CRQ moves directly to the “Scheduled”.

· When the assigned teams are ready to implement the change, the Queue Manager will place the CRQ in the “Implementation in Progress” Status, with the appropriate Status Reason (Build, Test, and Deployment), and assign tasks accordingly.

· Task templates are created for Standard Changes, once these tasks have been completed the CRQ moves into the “Completed” status.

· The CM Team will receive an automated message from Remedy, indicating the change in status, and the CM Team will place the CRQ in the “Closed” Status.

Figure 4 - Emergency Change High Level Process View

The Change Management Process Flow in BMC Remedy 7.5 for Emergency Changes is as follows:

· The Emergency Change flow is similar to the Normal Change flow; however, there are additional communication requirements.

· A CRQ is considered an emergency when the change is:

· associated to a configuration item that is defined as critical in the CMDB

· related to a security breach

· associated with an unplanned service outage (production)

· associated when service is down in production

· required to prevent service outage that cannot be mitigated or a work around to be put in place in production

· The CRQ is submitted to the GSD by the requestor; it should be marked as Emergency, an email should be sent to the CAB Chair, and to the CAB inbox (MSC_CM_CCB@us.saic.com).

· The CAB Chair is authorized to either approve or reject the change directly, or convene an emergency meeting of the CAB.

· If the CAB Chair approves the change as an Emergency, the CRQ will go through the Normal Change Process in an expedited manner.

· Once all Impact Analysis has been conducted, and approvals have been received, the CRQ is placed in the “Implementation in Progress” Status, with the appropriate Status Reason (Build, Test, and Deployment), and assign tasks accordingly.

· Task templates are created for Standard Changes, once these tasks have been completed the CRQ moves into the “Completed” status.

· The CM Team will receive an automated message from Remedy, indicating the change in status, and the CM Team will place the CRQ in the “Closed” Status.

Performance Reports

1. Change Management Report: change numbers/statistics, growth trends, key performance indicator(s), number of reopened CRQs, number of misclassified CRQs, breakdown by classification, priority, status, and location.

2. Top Ten Change Request Report: Most prevalent change requests by classification and longest change request by duration (mean time to resolve).

3. Metrics Report: report of metrics against baseline for Change Management KPIs.

Key Performance Indicators (KPI’s) The table below lists the key performance indicators (KPIs) that have been selected for tracking the success of the Change Management process and available through Remedy 7.x. Others maybe added.

Appendix A –Change Management Process Diagram

Appendix B – Change Type Definitions

Request Fulfillment

No

overhead

Production Environment

(Risk/ Responsible)

N6 Operations implementation/support- places in production required; other resources maybe required from other divisions; does not impact security posture as assessed by N65 requiring a complete C&A package High

N6 Operations implementation/support- places in production required; requirement for other resources from other divisions; new hardware required to support the change; impacts security posture as assessed by N65 requiring a complete C&A package N/A (includes all)

· Change Type checklist

· IA Template

· TRR (Test Readiness Review)

· Integration Test Report

· User Acceptance Test (UAT) Report

· Implementation Report

· Operational Acceptance Checklist

· Validation Report

· CRQ

· Change Type checklist

· IA Template

· TRR (Test Readiness Review)

· Integration Test Report

· User Acceptance Test (UAT) Report

· Implementation Report

· Operational Acceptance Checklist

· Validation Report

· CRQ Ticket with assigned Work Orders

· After Action Report (AAR)

· IA documentation identified

Standard Change

Type 0 Changes – minor/pre-approved change, typically requested from the User Service Catalog

· Type 0 Changes align with the IT Infrastructure Library (ITIL) standard change category. These changes contain routine activities which are well know, documented, and proven, low risk, and are ongoing required activities in order to support the environment. Type 0 Changes do not alter the core executable code, change ports, protocols or services, the hardware or software, or not have any impact on the IA posture or controls. These changes are well documented, repeatable, pre-approved, and considered standard change requests available on the Service Catalog self service.

· Type 0 Changes are initiated via a clear trigger, and are entered into the ITSM tool as a CRQ but are not required for review at the CAB meetings for approval prior to implementation.

Type 1 Changes – minor/pre-approved change, typically requested from the Technical Service Catalog

· Type I Changes align with the IT Infrastructure Library (ITIL) minor category. These changes contain small enhancements and fixes. These fixes, or patches, are small pieces of software or updates that are used to correct a problem with the functionality of the program or an operating system. Type I Changes do not alter the core executable code, change ports, protocols, or services, the hardware or software, or negatively impact the IA posture or protocols.

· Type 1 changes are typically executed by MSC N63/MSFSC N651 and do not require direct involvement from other N6 divisions until implementation. Other divisions will, however, be kept informed of impending Type 1 Changes.

Normal Changes

Type 2 Changes – medium to complex change/application change/only requires C&A Phase IV activity

· Type 2 Changes align with the ITIL Major Change category. Type 2 Changes involve the distribution of core executable changes, encompassing service packs (pieces of code to correct a problem in a software release), service releases, an updated version of a software product, the introduction of a new piece of software within the MSC environment or the removal of a piece of software from the environment. This software product may be a COTS, GOTS or custom-developed application. Type 2 Changes typically result in the introduction of new functionality or capabilities and require comprehensive integration testing. Type 2 Changes are managed as an N6 project and require participation across MSC N6. Type 2 Changes require a review/evaluation to verify the security posture has not changed. Type 2 Changes do not change the boundary of the C&A package and only require an administrative update to may require reaccreditation of or modification to the existing DIACAP Implementation Plan. Type 2 Changes may require obtaining an Interim Authority to Test (IATT) during testing.

Type 3 Changes – medium to complex change/infrastructure change/requires C&A package update

· Type 3 Change align with the ITIL Major Change category. The distinction between Type 3 and Type 2 Major Change is the requirement for involvement from MSC Engineering Team (N62). For existing software, a Type 3 change involves the distribution of an updated version of a software product and results in updated core executable code. The software update may be major and produces impact to the basic, underlying framework or features of the system. As such, Type 3 Changes are often accompanied by hardware updates. A Type 3 Change may also include the introduction of a new software product or patches to the MSC environment. Type 3 Changes may also involved the development of new system interfaces, either internal or external to MSC.

· Due to the complexity and interdependence of the IT and Engineering divisions, Type 3 Changes are executed as join projects between MSC N6 IT program Management and MSC N62. The project Manager is assigned from one of the two divisions. N64 approval is required for Type 3 changes. N62 is responsible to ensure that Type 3 Changes are submitted to the Technical Capacity Investment Board (TCIB) review and follow CPIC guidelines. Type 3 Changes impact the IA posture and require a new Certification and Accreditation (C&A) package.

Emergency Change

Emergency change is a Priority 1 change. Emergency changes are unplanned and unexpected. Emergency changes are defined as changes that need to be evaluated, assessed and either rejected or approved immediately. Simply defining a change as an emergency does not automatically entail the change should be implemented. The Emergency Change Advisory Board (ECAB) will assess the change and approve or reject emergency changes. Emergency changes are those required to restore service due to a Priority 1 incident (reactive) or a change that needs to be implemented quickly in order to avoid a Priority 1 incident (proactive).

Appendix C – RACI Chart

Roles

R

I

Decides whether to approve or reject changes

R

I

A

Ensures that planned application changes are tested before they are transferred into production

R

Completes tasks and updates them with relevant information and status changes

R

Transfers releases after their development in the dev environment to test environment

R

Transfers releases after their test in the test environment to production environment

R

Convenes and chairs CAB

Convenes and chairs ECAB

Conducts initial change reviews (IR)

Manages critical and EC CRQs through the change process lifecycle

Communicates with all necessary parties to coordinate Change build, test and implementation

Confirms classification, approves and authorizes or rejects urgent CRQs

Confirms classification, approves and authorizes or rejects Type 1/2/3 CRQs

Confirms classification, approves or rejects applications for Standard Pre-approved changes (SPACs)

Analyzes change records to determine any trends or apparent problems that occur

Reports on Change KPIs

Identifies and documents changes that by-pass the Change process

Initiate Request for Change (CRQ)

Creates CRQ

Ensures CRQ complete and correctly categorized by Type

Implements process improvements

Manages implementation of the change

Conducts post implementation reviews

Determines and Reports on post implementation reviews and recommendations for improvement

Appendix D – List of Supporting SOPs

This list of supporting SOPs will be updated as they are developed.

TBD

Appendix E – Remedy Status/Status Reason Map This will be completed after final Remedy 7.5 requirements and design are completed.

Request for Authorization

GSD – Type 0 CM – Type 1,2,3 GSD – No

CM – Yes

Request for Change

CM – Type 1,2,3

S/ECRQ

GSD – N/Type 0

CC (SDBM) – N/Type 1 No

Scheduled for Approval

Yes – CM (N) Yes – SDBM (S/Type1) Yes – ECAB (ECRQ)

Yes – PS (N)

Scheduled

Tasks are created and assigned to appropriate implementation teams

Not used.

Yes – CAB (N)

Yes – CAB (N)

Yes – CAB

Rejected

Completed

Notification is sent to requestor for confirmation.

Closed

GSD – S/Type 0 CM – S/Type 1/N/ECRQ Or Auto-close after 10 days

No Longer Required

Appendix F – Checklist and Approval List

This will be populated as these checklists and approvals are created.

TBD

Appendix G – Remedy Change Management Process Overview and Procedures Process Flow Charts Change Management Process

Procedure 1, Request for Change Review

Procedure 2, Change Planning

Procedure 3, Change Approval

Procedure 4, Infrastructure Change Implementation

Procedure 5, Application Change Implementation

Procedure 6, Planned Change Closure

Procedure 7, Emergency Change Implementation

Procedure 8, Emergency Change Closure

RA

RFC

PP

SA

S

IP

P

R

Complete

Closed

Cancel

MSC N6 ITSM Change Management Process Revision 0.9 DRAFT

May 2012

_1392630388.vsd

Request for Authorization

(RA)

(CD)

Request for Change

(RFC)

Planning in Progress

(PP)

Scheduled for Approval

(SA)

Scheduled (S)

Implementa-tion in Progress (IP)

Completed (C)

MSC N6 Standard Change Process Aligned to Remedy 7.5

Service Delivery

Technical Service

_1392632929.vsd

MSC N6 Emergency Change Process Aligned to Remedy 7.5

_1397996362.vsd

<Process Name>�

<Function>�

Change Management Process

Requestor�

GSD�

Impact Analysis Approvers

IR Attendees

Change Management�

CAB Members�

Implementers�

Submit

CRQ

Create CRQ in Remedy

Review

Is it a Valid Request

Update Remedy and Add to IR Agenda

Provide Additional Information

No

Review CRQs

IR Meeting

Is CRQ ready for CAB Review

Review for Impact Analysis by DADMS, IA, EA, and PM

Impact Analysis Decision

Review CRQs

CAB Meeting

Yes

Pre-Select Board�

Is Pre-Select Required

Implement

PSB Meeting

Is it a Valid Request

End

Approved

Notify CM Team CRQ is Complete

Update Remedy & Agendas

Review CRQ

Disapproved

Approved

Legend

Approved

Disapproved / Cancelled

_1392628264.vsd

MSC N6 Normal Change Process Aligned to Remedy 7.5

Scheduled for Review

(SR)

MSC N6 Normal Change Process Aligned to Remedy 7.5