Change Management Plan
(CMP)
Version/Change Record
Table of Contents 1.0 Introduction... 5 1.1 Purpose ... 5 1.2 Plan Scope ... 5 1.3 Document Overview... 7 1.4 Referenced Documents ... 7 2.0 Plans... 8
2.1 Work Products, Documents, and Records... 8
2.2 Roles and Responsibilities ... 8
2.3 Engineering Review Board (ERB)... 9
2.4 Program Integration Team (PIT) ... 10
2.5 Change Control Board (CCB)... 10
2.6 Configuration Management... 12
2.7 Customer ... 12
3.0 Change Management Process and Procedures... 13
3.1 CR – Submit ... 13 3.2 CR – ERB decision ... 13 3.3 CR – ERB Review ... 13 3.4 CR – PIT Review... 14 3.5 CR – CCB Review... 15 3.6 CR... 15 3.7 ECR...15 3.8 CR – Customer Review... 15 3.9 CR – Engineer Resolution ... 15 3.10 CR – Change Closure ... 15 4.0 Metrics ... 17
4.1 Number of unplanned outages related to changes ... 17
4.2 number of unauthorized changes... 17
4.3 Backlog of change requests... 17
4.4 average time to implement changes... 17
5.0 Process Best Practice Guidance ... 18
5.1 Notes on What Makes a Good change request ... 18
6.0 Notes... 20
6.1 Glossary ... 20
6.2 Acronyms... 20
List of Figures Figure 1.1 Overview of Change Management Decision Process ... 6 Figure 3.1. Change Management Process... Error! Bookmark not defined.
List of Tables
Table 1-1. Referenced Procedures... 7
Table 2-1. Change Management Resources... Error! Bookmark not defined. Table 2-2. Stakeholders and Responsibility/Authority ... 8
Table 2-4. Engineering Review Board Membership ... 9
Table 2-5. PIT Membership ... 10
Table 2-6. Change Control Board Membership... 11
1.0 INTRODUCTION
This document provides the plan for managing changes to Configuration Items (CIs) for the program. From this point forward, any type of change to any CI, whether it is to the infrastructure, applications or documentation, will simply be referred as a “change to the baseline.”
1.1 PURPOSE
The purpose of this Change Management Plan (CMP) is to define how changes to CIs are requested, evaluated, adjudicated, documented and incorporated. As the design evolves from one configuration to the next, changes must be recorded and documented in terms of their possible impact on the initial system requirements.
Key Plan Objectives
Establish an efficient methodology for requesting, evaluating, and adjudicating proposed changes to CIs.
Establish reasonable controls for affecting changes to CIs.
Define the roles and responsibilities of the parties involved in requesting, adjudicating, and implementing changes to CIs.
Create an audit trail of all changes to CIs. 1.2 PLAN SCOPEThe effort specifically addressed by this plan encompasses all of the change management activities to be undertaken by the program team, including its leadership and subcontractors (where applicable), to manage the program CIs and adherence to customer requirements. The CMP controls the changes to all CIs on the program. As shown in Figure 1.1, for a change to be approved, the first decision is whether the change is major enough to warrant sending it to the Engineering Review Board (ERB). If the change being requested is determined to be of minor impact, and therefore not in need of ERB approval, the change can be approved at this stage.
If the decision is made to send it to the ERB, the CMP requires the change request to pass through as many as four different decision points before approval. The decisions points are the Engineering Review board (ERB), the Program Integration Team (PIT) for Class 1 changes, the Change Control Board (CCB) and the customer. All participants play a vital role in the change management process.
This plan may be updated due to changes in the contract, customer direction, program scope, or requirements. Plans and processes are reviewed for update as needed and revised as required, to ensure consistency with customer requirements. More frequent reviews and updates are performed as necessary to ensure plans are current and useful.
1.3 DOCUMENT OVERVIEW
Section 1.0: Describes the scope and content of this plan and its relationship to other program plans and processes. Most of Section 1 will be defined in the Management Plan.
Section 2.2.0: References the plans and stakeholders for performing change request/approval activities.
Section 0: Describes the Change Management Process
Section 4.0
:
Details the metrics used to monitor the Change Management ProcessSection 4.0: Describes best practices for generating CRs and ECRs
Section 6.0: Provides direction to the glossary and list of acronyms used in this plan 1.4 REFERENCED DOCUMENTS
The documents listed in this section form a part of this plan to the extent specified herein. In the event of conflict between the documents referenced herein and the contents of this plan, as defined by approved waivers and deviations, the contents of this plan, upon final approval, are considered the superseding authority. For all other conflicts, higher level manuals or plans are considered the superseding authority, until the conflict is resolved. The latest versions of these documents are assumed to be applicable unless otherwise specified by including the specific version. Refer to the Master Document List for the latest revision and date.
1.4.1 REFERENCED PRCEEDURES
The following procedures are specifically referred to in this document. Table 1-1. Referenced Procedures
Title Incident Management Problem Management Capacity Management Availability Management Configuration Management
2.0 PLANS
This section defines the plans for performing change management activities. 2.1 WORK PRODUCTS, DOCUMENTS, AND RECORDS
All program work products, documents and records to be placed under Configuration Management (CM) control, including the appropriate levels of control, are defined in the CMP.
2.2 ROLES AND RESPONSIBILITIES
Stakeholders specific to change management are identified in Table 2-1. Table 2-1. Stakeholders and Responsibility/Authority
Stakeholder Change Request Responsibility/Authority Chief Engineer Member of the ERB and CCB
Ensures that changes to CIs are controlled, managed, and documented
Project Manager Reviews Change Requests (CR)for impact Manages schedule of changes to technical
infrastructure
Change Manager Member of the ERB and CCB
Manages the change review/approval process Reviews the risk & impact analysis
Change Coordinator Member of the ERB and CCB
Advises the ERB and CCB on perspective of their respective teams
Manages the change process, including risk and impact assessment
Documents all changes to CIs in Remedy Responsible for updating the CIs
Prepares change implementation plans
Responsible for implementing approved changes Monitors the progress of changes
Change Builder Member of the ERB and CCB Technical subject matter expert
Responsible for implementing and testing changes
Configuration Manager Member of the CCB
Ensures compliance with the CMP
Maintains change management tools and processes Acts as CCB Secretariat
Maintains status accounting records Updates CIs upon change approval
Customer Accepts/rejects the Engineering Change Request (ECR) through their change board
Has final approval authority on customer changes after baseline approval
2.3 ENGINEERING REVIEW BOARD (ERB)
The ERB is a critical part of the change management process. The ERB membership is shown in Table 2-2. Its main responsibility is to ensure compliance to the functional requirements, as well as CIs by reviewing, analyzing, and recommending approval/disapproval of proposed technical solutions for modifications and risk mitigation activities. The ERB ensures a thorough integrated technical review of requirements and recommended corrective actions has occurred.
The ERB may meet formally or review/approve the proposed change electronically. The ERB Chair determines the appropriate review method. The standard review time for both electronic and formal reviews is 5 business days unless otherwise directed by the ERB Chair.
Upon ERB decision to proceed with an engineering change, the change is reviewed by the PIT (if the change impacts cost, schedule, performance, or presents a risk) and then by the CCB, or it goes straight to the CCB (if there is no impact to cost, schedule, or performance).
Table 2-2. Engineering Review Board Membership
Board Member Responsibility Authority
Chief Engineer Chairs and
facilitates ERB Directs ERB activities Authorizes changes to CIs that do not affect program cost, schedule, and/or risk Change
Manager Plans and schedules change requests
Reviews the change request for completeness and adequacy Assess risk and impact
Routes the change request for approval based on the change class, priority, risk and impact
Plans, prepares and supports delivery to the CCB of all proposed Class 2 changes Change
Coordinator(s) Represent respective team(s)
Advises ERB on the system impact of the change from perspective of respective team
Change
Builder(s) Provide technical input Act as an information resource ERB Secretariat Acts as ERB
Secretariat
Ensures compliance with the change management process
Keeps minutes
Develops and maintains schedule/timeline Security
Manager Assesses security impact of the change
Advises ERB on the security impact of the change
2.4 PROGRAM INTEGRATION TEAM (PIT)
The PIT plans, prepares and supports delivery to the CCB of all proposed Class 1 changes (i.e., changes that impact cost, schedule or performance). PIT membership is shown in Table 2-3.
Table 2-3. PIT Membership
Position Responsibility Authority
PIT Chair Daily program performance
management Program integration Risk management
Executability of program baseline
Quality management system Configuration/change
management
Planning and scheduling Integrated Development
Environment (IDE)
Cost/schedule/performance reviews
Make day-to-day
operational decisions within constraints of contracted commitment and customer expectations
Act in absence of Program Manager (PM)
Implement and enforce integrity of program processes Provide integrated assessment of program executability to PM Prime Contracts
Manager Interface with customer contracts team Contract management
Commit enterprise to
support new and/or revised contracts using enterprise processes as requested by PM Subcontracts Manager Execution of subcontracts Subcontract management Teaming agreements/work share Commit enterprise to support new or revised subcontracts using enterprise processes as requested by PM Business Manager Proposal estimating/pricing
Business case analysis
Commit enterprise to
support new and/or revised contracts using enterprise processes as requested by PM
2.5 CHANGE CONTROL BOARD (CCB)
The CCB governs all of the programs CIs. The CCB responsibilities include:
Evaluate the scope of the change request and involve relevant functional teams in the technical evaluation
Evaluate the request for risks and consequent impacts on cost, schedule, and performance
Accept the change as a valid modification to the applicable CIs
Assign the change to a Change Coordinator
Determine the time frame of the change delivery
Generate the Engineering Change Request (ECR) to be submitted to the customer
Document the change and update the configuration status accounting
Interface with the customer to ensure that the CIs are internally consistent and executableThe core members of the CCB are shown in Table 2-4. Representatives associated with other program support operations, such as Business Administration, Contracts and Quality Assurance (QA), support the CCB as required. CCB members review the disposition of proposed ERB accepted changes, and determine the total impact of the change.
Table 2-4. Change Control Board Membership
Board Member Responsibility Authority
Change
Manager Chairs CCB Directs CCB activities Authorizes expenditure of program resources
Chief Engineer Represents engineering
Advises PM on NGC technical perspective, customer perspective, and integrity of product baseline Business
Manager Represents NGC enterprise and business operations interests
Advises PM on NGC enterprise perspective
Implements PM direction on contract matters
PIT Lead Facilitates CCB
Represents PIT
Advises PM on integrity (executability) of program baseline Configuration Manager Act as CCB Secretariat Keeps minutes
Develops and maintains schedule/timeline Change
Coordinator(s)
Represent respective team(s)
Advises CCB on the system impact of the change from perspective of respective team
Prepares and share change implementation plans with CCB Change
Builder(s) Provide technical input Act as an information resource Security
Manager Assesses security impact of the change
Advises CCB on the security impact of the change
Table 2-4. Change Control Board Membership
Board Member Responsibility Authority
Customer Insight as a
consultative member and approver of ECRs
Advises PM on customer perspective Approves ECRs
2.6 CONFIGURATION MANAGEMENT
Configuration Management provides integral control functions in support of the technical baseline management process. Configuration Management includes the process of managing requirements and physical configurations and the documents, data, and other records that identify those configurations.
Configuration Management responsibilities in the change management process include:
Ensure compliance with the change management process
Maintain change management tools and processes
Act as CCB Secretariat
Maintain status accounting records
Update baseline upon change approval 2.7 CUSTOMERThe customer has insight into the change management process as a consultative member and ECR approver of the CCB. All Class I changes to an approved baseline are handled through the ECR process. (See class definitions Table 3-1.) Refer to Configuration Management Process overview below. Once an ECR has been created, the change is forwarded to the customer and is approved or rejected through their change board. They are the final approval authority on changes after baseline approval.
3.0 CHANGE MANAGEMENT PROCESS AND PROCEDURES
This section describes the Change Management Process, shown in Error! Reference source not found., to request, evaluate, and adjudicate proposed Change Requests (CRs) to the technical and non-technical baselines.
3.1 CR – SUBMIT
Anyone may identify a CR. Whomever identifies the change is responsible for entering the CR (or changing the incident to a CR). The request can be a result of management direction, customer direction, changes in the contract, etc. A CR can be made for any controlled program baseline such as design, requirements, schedule, documentation, etc. The request, along with all pertinent information, is entered into the Remedy OnDemand Change Management database. In this manner, all of the details of the CR can be accessed and reviewed by the ERB members during the ERB.
3.2 CR – ERB DECISION
Once a change is entered into Remedy, the Project Manager and Change Manager will receive and email notification. The two will review the CR and determine whether it will have a major or minor impact to the systems and the CIs. If the impact is minor, they will initiate an immediate change in the Remedy system. If the impact is major, they will move it to ERB, changing the status in Remedy to reflect their decision.
3.3 CR – ERB REVIEW
The ERB chair will receive email notification when a CR is submitted to the Remedy database and indicate a major change. The ERB chair will determine if and when formal meetings will be scheduled to address any CRs. The ERB has the initial authority to approve or reject all requests. All CRs and ECRs are reviewed in Remedy. They can be viewed in order of highest to lowest priority if more than one is up for review. A CR may be sent back to the submitter for more details, rejected, or approved.
If approved, the ERB determines the Class of the change. See Table 3-1 for Change Classes. Class I Changes go to the PIT for analysis. Class II changes go straight to the CCB for review.
Table 3-1. Change Classes Change
Class
Criteria Approval Authority
Class I Any impact to cost, schedule, product
performance, the customer, and/or that may increase program risk. Specifically:
Affect system, maintenance, or other incremental cost elements
May push program scheduling or milestones outside tolerances
Impact on form, fit, or function of a CI, particularly interface and compatibility characteristics
CCB – final
approval Authority ERB – reviews and approves all
submitted changes prior to escalation to CCB
Table 3-1. Change Classes Change
Class Criteria Approval Authority
change in the operational or performance characteristics of the capability, including reliability and logistic supportability or processes
Require retrofit action
Have safety or security implications (including safety-critical software issues) Require amendment to delivered
operational or maintenance documentation
Require operator or maintainer training if accepted
Affect guarantees or warranties on deliverables
Impact to any customer expectation where we are exceeding and now can only meet, or exceed by a lesser amount
schedule or performance, the PIT will provide data for analysis
Class II Any change to a CI that is not Class I (does not impact cost, schedule, product
performance, the customer, and/or increase program risk)
Example: Documentation amendments to correct errors or update version/edition numbers
Example: Any proposal to substitute a component with one that is built to the same Build Standard
Example: Manufacturer-imposed changes to the internals of a spare that do not affect the item’s functional or physical
performance or substitution of technical components built to the same Build
ERB – reviews and approves all
submitted changes
3.4 CR – PIT REVIEW
The PIT chair receives an email notification when a new CR is assigned for review. The PIT members review the proposed change, perform an analysis, and disposition the CR in Remedy to include the PITs recommendation. The PIT has the authority to approve or overturn and reject any ERB-approved CR. A CR may be sent back to the submitter for more details, rejected, or approved.
If the change is accepted, the PIT determines if the change will impact the customer. If it does not, the change package/briefing, working with the Change Coordinator(s), is updated and the CR is sent to the CCB for review. If the CR does impact the customer,
the PIT will create an ECR (in Remedy), update the package/briefing, and the ECR will be sent to the CCB for review.
3.5 CR – CCB REVIEW
The CCB chair will receive an email notification that there is a CR that needs to be reviewed. The CCB has final authority to approve or overturn and reject any ERB or PIT-approved CR/ECR. A CR may be sent back to the submitter for more details, rejected, or approved. If a CR or ECR is rejected by the CCB, a determination will be made for inclusion in the “Unapproved Change List” for future opportunity monitoring.
3.6 CR
If a CR is approved, and there is no impact to the customer, the Change Coordinator is notified to make the change to the CI.
3.7 ECR
If an ECR is approved, the Change Coordinator is notified to create a formal ECR from the ECR record in the Remedy database for submission to the customer.
3.8 CR – CUSTOMER REVIEW
The customer receives and reviews the formal ECR. If rejected, the change is closed. The CCB will consider if the change will be included in the “Unapproved Change List” for future opportunity monitoring.
If accepted, the CCB notifies the NGC team (item owner, and scheduler, and/or Business Manager, as applicable) to proceed with the approved change. The Change Coordinator implements the change, updates the CIs and the Configuration Manager updates the baseline.
3.9 CR – ENGINEER RESOLUTION
When a CR/ECR is assigned to someone to make the change or resolve the problem, an email is sent notifying them of their assignment. When completed, the assignee reports the completion of the change, or resolution of the problem, in Remedy.
3.10 CR – CHANGE CLOSURE CR
When a CR is approved by the CCB, an email is sent to the assignee to complete the change. The assignee processes the change and submits to the Configuration Manager to update the baseline. The Configuration Manager will close the CR once the change has been received and the item is back under CM control.
Note: Only the Configuration Manager can close a CCB approved CR. ECR
When an ECR is approved by the CCB, it is assigned to the appropriate Functional Lead to process a formal ECR for delivery to the customer.
1.
The assignee generates the formal ECR and submits it to the ConfigurationManager for delivery.
2.
The Configuration Manager delivers the Formal ECR to the customer and then3.
Upon approval, the ECR is assigned for completion of the change.4.
The assignee processes the change and submits it to the Configuration Managerfor to update the baseline. The Configuration Manager will close the ECR once the change has been received and the item is back under CM control.
4.0 METRICS
The primary objective of Change Management is to enable beneficial changes to be made with a minimum of disruption to IT services. The metrics recommended here are deemed to be effective in identifying procedures that lead to efficient, accurate, controlled and prompt handling of changes.
4.1 NUMBER OF UNPLANNED OUTAGES RELATED TO CHANGES
Changes may very well involve a planned system outage to implement, but should not result in unplanned outages. This number should be very low over any time period and ideally zero. And number other than zero should initiate an evaluation into the efficacy of the procedures used to evaluate changes in the test environment.
4.2 NUMBER OF UNAUTHORIZED CHANGES
The number of unauthorized changes in a properly-operating CM system is zero. This is the number expect over any time period. Any number other that zero should trigger an investigation into the cause.
4.3 BACKLOG OF CHANGE REQUESTS
As the system matures, the backlog of CRs in Remedy is expected to decline. Should there be a material increase in the backlog of CRs in Remedy over some time period, a root cause analysis should be performed to understand why.
4.4 AVERAGE TIME TO IMPLEMENT CHANGES
As the system support staff gains experience implementing changes on the system over time, there should be a decrease, if even slightly, in the average time to implement changes to the system. Should there be a material increase in the average time to implement changes, a satisfactory explanation should be ascertained, and additional personnel training may be necessary.
5.0 PROCESS BEST PRACTICE GUIDANCE
In practice, it may prove advisable to by-pass certain aspects of the defined process. This is allowable so long as the intent of the process is maintained, which is to control and document product changes and problems/defects. The ERB or CCB must approve such actions. As they are determined, these allowable expediencies will be documented here.
The intent of this section is to allow program staff to follow the process, while not being held back due to time constraints on the program. The intent is NOT to allow the process to be circumvented.
5.1 NOTES ON WHAT MAKES A GOOD CHANGE REQUEST
The following are notes to help authors and engineers adhere to good CR practice.
SUBMIT
All applicable CR definition fields should be filled in by the submitter.
The Short Title should be a brief descriptive name evoking the basic nature of the change/problem. Leave the details for the Description field.
The Description should describe the change being requested or observed behavior that indicated there was a problem, and what was expected. For problems, be aware that the submitter, analysis assignee, and resolution assignee may be different people, possibly separated in both space and time. A good description is key to valuable troubleshooting.
The steps to re-create the observation should detail the process necessary (test setup and steps if applicable) to reproduce the observed behavior.
The Priority should be suggested. REVIEWThe ERB/CCB may choose to expedite a CR/ECR through the process by advancing it to an appropriate state. The ERB/CCB should maintain notes in the Comments field describing such decisions.
PROBLEM ANALYSIS
All applicable CR analysis fields should be filled in by the analysis assignee.
The Comments field should describe the nature of the error discovered by troubleshooting the described problem. The assignee should execute the procedure detailed in the Steps to Re-create. If either the Detail Description or the Steps to Re-create are inadequate to allow re-creation of the problem, the assignee should endeavor to elicit the information from the CR author, or have the ERB/CCB return the PCR to the author for enhancement. Every time the CR is analyzed (assuming Failed Regression), the analysis is appended to the Analysis field. Never delete previous data.
The Time to Complete Analysis field should include the number of minutes it took to perform the analysis. Increment the value each time the PCR is analyzed. Never delete previous data.
The Impacts field should describe how the PCR will impact the program, whether it is cost, schedule, etc.RESOLUTION
All applicable CR fields should be filled in by the Resolution Assignee.
The Comments field should detail what the actual fix was. Each time the CR is fixed (assuming Failed Regression), the resolution is appended to the Comments field. Never delete previous data.
The Time to Correct time should include the number of minutes it took to implement the fix, including testing. Increment the value each time the PCR is fixed. Never delete previous data.TEST
All applicable CR fields should be filled in by test personnel.
The Name Tester field should contain the name of the tester who performed the System Test.
The Actual Time to Complete Testing should indicate the number of minutes it took to test the CR. Never delete previous data.
The Version Fix Verified field indicates in which version the fix was tested.
Any new observations about the CR should be included in Comments. Assignees should review the Comments when a CR is returned after a Failed Regression.6.0 NOTES
This section defines terms and acronyms typically used across the program. 6.1 GLOSSARY
All glossary terms are defined and managed in the Master Glossary of Terms. 6.2 ACRONYMS
