Change Management Plan (CMP)

Change Management Plan (CMP) i

Version/Change Record Revision Date Description ii

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

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 Table 3-1. Change Classes... 13 iv

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 SCOPE The 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. 5

Figure 1.1 Overview of the Change Management Approval Process 6

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 Process Section 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 Incident Management Problem Management Capacity Management Availability Management Configuration Management Title 7

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 Chief Engineer Project Manager Change Manager Change Coordinator Change Builder Configuration Manager Customer Change Request Responsibility/Authority Member of the ERB and CCB Ensures that changes to CIs are controlled, managed, and documented Reviews Change Requests (CR)for impact Manages schedule of changes to technical infrastructure Member of the ERB and CCB Manages the change review/approval process Reviews the risk & impact analysis 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 Member of the ERB and CCB Technical subject matter expert Responsible for implementing and testing changes 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 Accepts/rejects the Engineering Change Request (ECR) through their change board Has final approval authority on customer changes after baseline approval 8

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 Change Coordinator(s) Change Builder(s) ERB Secretariat Security Manager Plans and schedules change requests Represent respective team(s) Provide technical input Acts as ERB Secretariat Assesses security impact of the change 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 Advises ERB on the system impact of the change from perspective of respective team Act as an information resource Ensures compliance with the change management process Keeps minutes Develops and maintains schedule/timeline Advises ERB on the security impact of the change 9

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 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 Integrated Development Provide integrated Environment (IDE) assessment of program Cost/schedule/performance executability to PM reviews Prime Contracts Manager Subcontracts Manager Business Manager Interface with customer contracts team Contract management Execution of subcontracts Subcontract management Teaming agreements/work share Proposal estimating/pricing Business case analysis Commit enterprise to support new and/or revised contracts using enterprise processes as requested by PM Commit enterprise to support new or revised subcontracts using enterprise processes as requested by PM 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 Evaluate the request for program-wide impacts from the Chief Engineer 10

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 executable The 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 Business Manager PIT Lead Configuration Manager Change Coordinator(s) Change Builder(s) Security Manager Represents engineering Represents NGC enterprise and business operations interests Facilitates CCB Represents PIT Act as CCB Secretariat Represent respective team(s) Provide technical input Assesses security impact of the change Advises PM on NGC technical perspective, customer perspective, and integrity of product baseline Advises PM on NGC enterprise perspective Implements PM direction on contract matters Advises PM on integrity (executability) of program baseline Keeps minutes Develops and maintains schedule/timeline Advises CCB on the system impact of the change from perspective of respective team Prepares and share change implementation plans with CCB Act as an information resource Advises CCB on the security impact of the change 11

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 CUSTOMER The 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. 12

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 Class I Criteria 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 Introduce significant and measurable Approval Authority CCB final approval Authority ERB reviews and approves all submitted changes prior to escalation to CCB PIT if the change affects cost, 13

Table 3-1. Change Classes Change Class Class II Criteria 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 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 Approval Authority schedule or performance, the PIT will provide data for analysis 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, 14

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 PITapproved 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 Configuration Manager for delivery. 2. The Configuration Manager delivers the Formal ECR to the customer and then awaits acceptance/rejection of the ECR. 15

3. Upon approval, the ECR is assigned for completion of the change. 4. The assignee processes the change and submits it to the Configuration Manager for 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. 16

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

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. REVIEW The 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. 18

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

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 All acronyms are defined and managed in the Master Acronym List. 20