Attachment 12 - Risk Management Plan.pdf

IAMD Program IAMD-00024 Risk Management Plan January 28, 2016

Use or disclosure of this report is subject to the restriction on the title page.

Integrated Air and Missile Defense (IAMD) Risk Management Plan (RMP)

Prepared For:

United States Army Program Executive Office Missiles and

Space IAMD Project Office

Bldg. 5250 Martin Road Redstone Arsenal, AL 35898-8000

Prepared By:

United States Army Program Executive Office Missiles and

Space IAMD Project Office

Bldg. 5250 Martin Road Redstone Arsenal, AL 35898-8000

DISTRIBUTION STATEMENT D: Distribution authorized to the Department of Defense and U.S. DoD contractors only;

Critical Technology, 24 Sept 08. Other requests shall be referred to the Program Executive Office Missiles and Space, Integrated Air and Missile Defense (IAMD) Project Office, ATTN: SFAE-MSLS-IAMD, Bldg. 5250 Martin Road, Redstone Arsenal, AL 35898-8000.

UNLESS OTHERWISE APPROVED BY THE INTEGRATED AIR AND MISSILE DEFENSE PROJECT OFFICE, ALL ENGINEERING TECHNICAL DATA, SOFTWARE AND COST DATA SHALL BE SUBJECT TO EXPORT RESTRICTIONS AS

FOLLOWS:

WARNING - This document contains technical data whose export is restricted by the Arms Export Control Act (Title 22, U.S.C., Sec 2751 et. Seq.) or the Export Administration Act of 1979, as amended. Title 50, U.S.C., app 2401 et. Seq. Violation of these export laws are subject to severe criminal penalties. Disseminate in accordance with provisions of DOD Directive 5230.25.

DESTRUCTION NOTICE - For classified documents, follow the procedures in DOD 5220.22-M, National Industrial Security Program Operating Manual (NISPOM), Chapter 5, Section 7, or DOD 5200.1-R, Information Security Program Regulation, Chapter IX. For unclassified, limited documents, destroy by any method that will prevent disclosure of contents or reconstruction of the document.

Contract W31P4Q-08-C-0418 Attachment 0013 iii Use or disclosure of this report is subject to the restriction on the title page.

REVISION HISTORY

Revision Description Date

DRAFT Draft version to support IBCS RFP. July 20, 2007

Initial Release January 23, 2009

A Periodic Update August 24, 2010

B

Periodic Update

- Figures 1-1, 2-1, and 3-1 updated for correctness

- Schedule and Cost Analysis sections updated and combined

- Updated to reflect that RWG is precursor to

RMB as opposed to WIPTs/Product Teams

- Added Opportunity Management section

- Updated TPM section to align to SEP

- Updated Reporting section to include DAES, P(S), and SAR

- CAPs added as formal RMB members

- SLAMRAAM removed

- Definitions of “Issue” and “Opportunity” added

January 4, 2012

C Updated to align with DoD Risk, Issue, and Opportunity Management Guide for Defense Acquisition Programs dated 15 June 2015

January 28, 2016 iv Use or disclosure of this report is subject to the restriction on the title page.

CONTENTS

1 INTRODUCTION 1

1.1 PURPOSE

1.2 OBJECTIVE

2 PROGRAM SUMMARY 2

3 DEFINITIONS 2

4 RISK MANAGEMENT STRATEGY 6

5 RISK MANAGEMENT BOARD AND RISK WORKING GROUP 7

5.1 RISK MANAGEMENT BOARD

5.2 RISK WORKING GROUP

6 ROLES, RESPONSIBILITIES, AND AUTHORITIES 7

6.1 PROJECT MANAGER

6.2 PROGRAM OPERATIONS DIRECTOR

6.3 RISK MANAGEMENT LEAD

6.4 RISK POINT OF CONTACT

6.5 RISK RETIREMENT

7 RISK MANAGEMENT PROCESS AND PROCEDURES 10

7.1 RISK PLANNING

7.2 RISK IDENTIFICATION

7.3 RISK ANALYSIS

7.3.1 Technical Risk Analysis

7.3.2 Technical Performance Measurement Relationship to Risk Management

7.3.3 Schedule and Cost Risk Analysis

7.3.4 Quantifying Risk

7.4 RISK HANDLING

8 RISK MANAGEMENT AND OTHER PROGRAM MANAGEMENT TOOLS 18

9 RISK EVALUATION AND TECHNIQUES 19

9.1 OVERVIEW AND SCOPE OF THE EVALUATION PROCESS

9.1.1 Risk Ratings (High, Moderate, Low)

9.2 LIKELIHOOD AND CONSEQUENCE PARAMETERS AND THRESHOLDS

9.2.1 Likelihood of Occurrence Attributes

9.2.2 Consequence of Occurrence Attributes

9.2.2.1 Consequence to Technical

9.2.2.2 Consequence to Schedule

9.2.2.3 Consequence to Cost

10 COMMUNICATION AND FEEDBACK PROCESS 29

11 OPPORTUNITY MANAGMENT 30

12 ISSUE MANAGEMENT 31

v Use or disclosure of this report is subject to the restriction on the title page.

FIGURES

Figure 4-1 IAMD Risk Management is a Continuous Process

Figure 6-1 IAMD Risk Management Responsibilities

Figure 7-1 IAMD Risk Management Process

Figure 7-2 Process for Risk Identification and Assessment Figure 7-3 IAMD Risk Survey Form………………………………………………………………………….15 Figure 7-4 Risk Handling Options……………………………………………………………………...……18 Figure 9-1 IAMD Risk Rating Process Figure 9-2 Technology Likelihood Attributes and Evaluation Criteria

Figure 9-3 Design and Engineering Likelihood Attributes and Evaluation Criteria

Figure 9-4 Performance Likelihood Attributes and Evaluation Criteria

Figure 9-5 Manufacturing Likelihood Attributes and Evaluation Criteria

Figure 9-6 Supportability Likelihood Attributes and Evaluation Criteria

Figure 9-7 Cost Pf Attributes and Evaluation Criteria

Figure 9-8 Schedule Likelihood Attributes and Evaluation Criteria

Figure 9-9 Consequence Attributes and Evaluation Criteria

Figure 10-1 External Risk Reporting Summary

Figure 10-2 Risk Mitigation Template

Figure 12-1 Issue Reporting Matrix vi

ACRONYMS

ACD Actual Completion Date APB Acquisition Program Baseline Cf

CAP

Consequence of Occurrence Component Acquisition Program

CDRLs Contract Data Requirements List CMDS Cruise Missile Defense Systems COTS Commercial off the Shelf CSCI Computer Software Configuration Item DAES Defense Acquisition Executive Summary DAG Defense Acquisition Guidebook D&E Design and Engineering DoD Department of Defense DoDD Department of Defense Directive DoDI Department of Defense Instruction ECD Expected Completion Date HW Hardware IAMD Integrated Air & Missile Defense IBCS IAMD Battle Command System IMS Integrated Master Schedule JLENS Joint Land Attack Cruise Missile Elevated Netted Sensor System LTPO Lower Tier Project Office OSD Office of the Secretary of Defense Pf Probability of Occurrence PM Project Manager PO Project Office POC Point of Contact PRR Production Readiness Review R&D Research and Development RCD Revised Completion Date RE Risk Exposure RFP Request For Proposal RM Risk Management RMB Risk Management Board RML Risk Management Lead RMP Risk Management Plan ROMB Risk and Opportunity Management Board RWG Risk Working Group SAR Selected Acquisition Report SI Software Item SME Subject Matter Expert SW Software T&E Test and Evaluation vii to the restriction on the title page.

TPM Technical Performance Measure WBS Work Breakdown Structure WIPT Working Integrated Product Team viii

REFERENCES

1. Department of Defense Directive (DoDD) 5000.1: The Defense Acquisition System

2. Department of Defense Instruction (DoDI) 5000.2: Operation of the Defense Acquisition System

3. Defense Acquisition Guidebook (DAG)

4. DoDD 5000.4: OSD Cost Analysis Improvement Groups

5. DoD Manual 5000.4-M: Cost Analysis Guidance and Procedures

6. Department of Defense Risk, Issue, and Opportunity Management Guide for Defense Acquisition Programs

7. Better Buying Power 3.0 ix to the restriction on the title page.

PREFACE

The purpose of this Risk Management Plan (RMP) is to provide guidance on the implementation and execution of risk, issue and opportunity management for the IAMD Program. Specifics include the methodology of identification, analysis, and control of risk, issues and opportunities as well as process, procedures and organizational reporting structure.

This RMP is in compliance with the policies of Department of Defense (DoD) publications listed in the References section of the front matter of this plan. The Department of Defense Risk, Issue and Opportunity Management Guide for Defense Acquisition Programs states that “risk, issue and opportunity management should be forward-looking, structured, continuous and informative. Effective qualitative and quantitative risk, issue and opportunity management are critical to a program’s success.” The objectives and procedures in this plan are applicable to the entire IAMD Project Office (PO), i.e. both Government personnel and System Engineering Technical Advisors.

to the restriction on the title page.

1 INTRODUCTION

Some degree of risk always exists in technology, design and engineering, performance, manufacturing, supportability, integration, interoperability, cost, or schedule areas. The key to effective control is to identify and manage the risks early.

This RMP documents the IAMD Program’s approach to Risk Management (RM). This plan is a living document and is updated periodically to reflect changes in the program scope, focus, content, or program phase.

This section provides an overview of the RM initiative as applied to the IAMD Program. The purpose and objectives of the IAMD Program risk management activities and requirements are also included in this section of the document.

Opportunity and issue management are included in the scope of the risk management program, and are specifically addressed in sections 11 and 12, respectfully, of this document.

1.1 Purpose

The purpose of this plan is to define IAMD’s approach to risk management, including organizational relationships and methodology for identification, assessment, and mitigation planning and implementation.

The risk management process is a disciplined management technique allowing all Working Integrated Product Teams (WIPTs)/Directorates/Product Offices, program management, and other stakeholders to monitor the identified risk elements of the IAMD Program. This proactive, iterative process permits the early identification of risk elements; provides the basis for aggressive management actions to control risk elements; and establishes management techniques to track identified risks and monitor compliance with associated mitigation plans.

1.2 Objective

The IAMD risk management objective is to identify risk areas, both technical and non-technical, and take necessary action to handle them before they become issues that seriously impact cost, schedule, or performance.

The IAMD risk management process is comprised of five interrelated activities performed in a continuous process. Figure 4-1 depicts the IAMD risk management concept which is an iterative process of planning, identification, analysis, handling and monitoring risks.

Effective risk management tools support program management and all stakeholders in the early identification, analysis, and control of program risks that may become significant during the IAMD system development. One of these tools is the IAMD Risk Database, which is used to track and monitor risks and mitigation progress across the program. Data residing in the Risk Database is gathered via a program-wide standard Risk Survey Form, which is further explained in Section 7.3.

2 PROGRAM SUMMARY

The IAMD Program represents a shift from a traditional system-centric weapon systems acquisition to a component-based acquisition approach. This component-based acquisition approach, defined in the IAMD Acquisition Strategy document, will provide the most efficient way to acquire and integrate the components of the incremental IAMD architecture. Unlike traditional acquisition programs that focus primarily on the development of a single system or platform, the IAMD Program is uniquely structured to enable the development of an overarching System of Systems capability with all participating AMD components functioning interdependently to provide total operational capabilities not achievable by the individual element systems.

3 DEFINITIONS

The terms used in this plan are defined below, to ensure consistency and commonality in program risk analysis and reporting.

Accept: Acknowledge that a risk event or condition may be realized and have sufficient resources in place to deal with the risk when it occurs.

Avoid: Reduce or eliminate a risk event or condition by taking an alternate path.

Actual Completion Date (ACD): Date the mitigation step is actually complete.

Closure Criteria: Those aspects of a system's capability (operational, technical, or other) that must be satisfied before a risk can be retired.

Consequence of Occurrence (Cf): The consequence or impact, based on Consequences of Occurrence Table in Section 3 of this plan, that an unmitigated risk event may cause to the technical, schedule, and/or cost objectives.

Contingency Plan: The contingency plan is a potential “fallback plan” to be used if the risk mitigation plan is not successful.

Critical Path: The longest sequence of activities through the project, which represents the shortest duration possible.

Decision Point Milestone: The event or point that a “Go/No-Go” decision must be made to begin implementation of the contingency plan based on the expected failure of the mitigation plan.

Exit Criteria: Those aspects of a system's operational, technical, or other capability that must be questioned before a system's overall suitability can be known and that are of primary importance to the decision authority in reaching a decision to allow the system to advance into the next phase of development.

Expected Completion Date (ECD): Date the mitigation step is initially expected to complete.

Handle: Develop and implement a plan to address the risk by examining the four handling options (accept, avoid, transfer, mitigate), choosing the best option (or hybrid of options), obtaining suitable resources associated with the plan, and implementing the plan.

to the restriction on the title page.

IAMD Risk Database: A central repository for all risks identified by the program team and approved by the Risk Management Board. The database records details of all risks identified throughout the life of the project. It includes information for each risk such as category, likelihood, consequence, risk level, risk handling plans, and resources required to implement them, actual versus planned progress versus time, and where applicable, expected closure dates. The Risk Database is maintained by the Risk Management Lead and is an information source for documentation, prioritization, and reporting of risk data.

Identify: Examine the aspects of a program to determine risk events and associated cause(s) that may have negative cost, schedule, and/or performance impacts.

Issues: Events or conditions with negative effect that have occurred (such as realized risks) or are certain to occur in the future that should be addressed.

Key Performance Parameter (KPP): Performance attribute of a system considered critical or essential to the development of an effective military capability. KPPs are contained in the Capability Development Document and the Capability Production Document and are included verbatim in the Acquisition Program Baseline. KPPs are expressed in terms of parameters that reflect Measures of Performance using a threshold/objective format. KPPs must be measurable, testable, and support efficient and effective test and evaluation.

Key System Attribute (KSA): Performance attribute of a system considered important to achieving a balanced solution/approach to a system, but not critical enough to be designated a Key Performance Parameter. KSAs must be measurable, testable, and support efficient and effective test and evaluation.

KSAs are expressed in terms of Measures of Performance.

Likelihood: Assessed probability that an event will occur given current conditions. Likelihood is also referred to as probability of occurrence (Pf).

Mitigate: Implement a strategy to reduce the risk to an acceptable level.

Opportunities: Potential future benefits to the programs cost, schedule, and/or performance baseline, usually achieved through reallocation of resources.

Programmatic Risks: Non-technical risks that are generally within the control or influence of the program manager or Program Executive Office. Programmatic risks can be associated with program estimating (including cost estimates, schedule estimates, staffing estimates, facility estimates, etc.)

program planning, program execution, communications, and contract structure.

Potential Impact: A statement of quantification of the effect that a component and/or element may experience due to the occurrence of a risk. The effect is quantified in terms of its detriment to technical, cost, and/or schedule objectives.

Revised Completion Date (RCD): Date the mitigation step is currently expected to complete.

Risks: Future events or conditions that may have a negative effect of achieving program objectives for cost, schedule, and performance. Risks are defined by (1) the probability of an undesired event or condition occurring and (2) the consequences of the undesired event were it to occur.

Risk Categories: Seven categories for evaluating risks are technology, design and engineering, performance, manufacturing, supportability, cost and schedule.

Risk Assessment: The process of examining each identified risk to refine its description, isolating its cause, and determining its effects. It includes risk rating and prioritization in which risk events are defined to the restriction on the title page.

in terms of their probability of occurrence, severity of consequence/impact, and relationship to other risk areas or processes.

Risk Control: The process related to achieving the desired outcomes by continual application of management techniques to the risk drivers.

Risk Exposure: The risk exposure is derived by mapping the probability of occurrence (Pf) and the consequence of occurrence (Cf) to a five-by-five matrix. The intersection of these two variables results in a number between 1 (lowest risk) and 25 (highest risk).

Risk Exposure (RE) Step-down Percent: As steps in the mitigation plan are completed, the risk is reduced and thus the risk exposure is reduced. Cumulative RE step-down percentages must not exceed 100%.

Risk Management Approach: The organization, tools, and methods a program chooses to carry out its risk management process.

Risk Management Board (RMB): The senior program group, chaired by the program manager that approves candidate risks and their causes. The board reviews and/or approves risk analysis results, risk handling plans and associated resources, and actual versus planned progress associated with implemented risk handling plans. It is an advisory board to the program manager and provides a forum for all stakeholders and affected parties to discuss their concerns.

Risk Manager: Program team member responsible for implementing the risk management process, updating the RMP, and assisting team members to (1) identify and document candidate risks, (2) develop risk analysis results, (3) develop draft risk handling plans, (4) include risk information in the risk database,

(5) develop risk reports, and (6) update this information versus time.

Risk Monitoring: The process that systematically tracks and evaluates the performance of risk-handling actions against established metrics throughout the acquisition process and develops further risk-handling options, as appropriate.

Risk Rating: The rating assigned to a risk by the IAMD Risk Management Board (RMB) based on the probability and consequence of a risk in terms of meeting technical, cost, or schedule objectives at the IAMD Program level. The IAMD Risk Working Group (RWG) reviews each risk and recommends its rating to the IAMD RMB. The three levels of risk rating that can be assigned by the IAMD RMB are the following:

• Low Risk: A condition where a risk has been identified, but the combination of the probability and consequences of the occurrence has minimal impact on program objectives.

Existing hardware is available and/or proven technology application can overcome risk.

Occurrence is unlikely to cause disruption in program schedule or degradation in system performance. Normal efforts from contractor and/or the Government can overcome risk.

The color, green, is associated with risks rated low.

• Moderate Risk: A condition where a risk has been identified and the combination of the probability and consequences of the occurrence has moderate impact on program objectives. Major design changes in hardware/software may be required with moderate increase in complexity. If risk occurs, it will cause disruption in schedule and/or degradation in performance. Special attention and close monitoring from contractor and/or the Government can overcome the risk. The color, yellow, is associated with risks rated moderate.

to the restriction on the title page.

• High Risk: A condition where a risk has been identified and the combination of the probability and consequences of the occurrence has a significant impact on meeting program objectives. State-of-the-art research is required. Occurrence is likely and will cause serious disruption of program schedule and/or degradation of system performance even with special attention from contractor and/or the Government monitoring. The color, red, is associated with risks rated high.

Risk Rating Template: A table of attributes of this plan to assist with assessing the probability of occurrence in each of the seven risk areas and consequence of occurrence. The table contains the scoring associated with each attribute.

Risk Retirement: The RWG recommends and the IAMD RMB approves a risk for retirement once all mitigation steps are complete and the risk is no longer a threat to meeting program objectives.

Risk Survey Form: A standardized IAMD format used to document risks and mitigation plans. The Risk Survey Form is used to populate the IAMD Risk Database.

Risk Watchlist: Sometimes a threat is identified which is determined to not be a risk at the time but could become a risk at a later time. The threat requires further consideration at a future time. In this case, the item is captured in the Risk Database in a similar manner as other risks; however, they are coded as a watchlist item and reviewed at least quarterly for changes.

Stakeholder: Person, group, or organization that has responsibility and influence over the success of a program or system. Stakeholders include the program manager, the Milestone Decision Authority, acquisition commands, contractors, contract managers, suppliers, test communities, and others.

Technical Performance Measure (TPM): TPMs are specific technical values to be achieved through the planned technical program effort, measures differences between achieved values and those allocated to the product element by systems engineering processes, and determines the impact of those differences on system effectiveness. TPMs are typically related to Key Performance Parameters, Key System Attributes, key technical risks, and Measures of Effectiveness.

Technical Risks: Risks that may prevent the end item from performing as intended or from meeting performance expectations. Technical risks can be internally or externally generated. They typically emanate from areas such as requirements, technology, engineering, integration, test, manufacturing, quality, logistics, system security/cybersecurity, and training.

Transfer: Reassign or reallocate the risk responsibility to another entity. This approach may involve reallocating a risk from one program to another, between the government and the prime contractor, within government agencies, or across two sides of an interface managed by the same organization.

4 RISK MANAGEMENT STRATEGY

The IAMD risk management activities described in this plan provide a methodology and process for the initial and continuing planning, identification, analysis, handling and monitoring of all risk areas. The plan is implemented across the IAMD PO.

Other objectives of the Risk Management Program include:

• Inform management and all stakeholders of changing risk priorities

• Provide a tracking and reporting system for effective prioritization of risks and funds

• Provide summary and detailed risk reports

• Coordinate and summarize information from stakeholders

• Provide risk metrics for the program

• Participate in Contractor Risk Management Programs/Activities

• Training

Figure 4-1 IAMD Risk Management is a Continuous Process to the restriction on the title page.

5 RISK MANAGEMENT BOARD AND RISK WORKING GROUP

5.1 Risk Management Board

The RMB is the forum for Risk Management coordination and decision-making by consensus on risk management issues. The RMB meets quarterly or as required. The individuals identified below attend or send a representative from their respective area if they cannot attend for some reason.

The IAMD PO members of the RMB are the Project Manager (PM), the Deputy PM, the Program Operations Director, the System Engineering Director, the Test Director, the Software Director, the Logistics Director, the IBCS Fire Control Product Manager, the IBCS Engagement Operations Center Product Manager, The Technical Director and the Risk Management Lead. Upper level management representatives from the Prime Contractors, Lower Tier Project Office (LTPO), Counter- Rocket, Artillery, Mortar (C-RAM) and Cruise Missile Defense Systems (CMDS) PO are also members of the RMB. The IAMD RMB is chaired by the PM or designee. A minimum of 4 members must be present in order to have a quorum to:

• Review/approve proposed risk items and mitigations

• Review status of moderate and high-rated risks

• Prepare requests for funds to support new risks or mitigations

• Approve retirement of risks

• Document RMB actions and decisions

• Review/approve risk quantification criteria

• Review adverse metric trends and take appropriate actions

Other individuals as required and/or assigned by the RWG to support the RMB may also be in attendance.

5.2 Risk Working Group

The RWG is the forum chaired by the RML to formulate the program level risk rollup for the RMB. The RML convenes the RWG monthly or on an ‘as needed’ basis. The membership of the RWG is representative of all major aspects of the IAMD Program. Each WIPT/Directorate/Product Office is represented by its leader or Risk POC with authority to make decisions concerning risk matters. Other attendees are functional area representatives as needed (such as producibility, test, cost, schedule, quality and configuration management). The Prime Contractors are encouraged to send representatives to the RWG. Other Component Acquisition Programs (CAPs), i.e. Patriot, IFPC Inc 2, C-RAM and Sentinel are invited to send a representative to the IAMD RWG meetings and it is expected that likewise, an IAMD representative will be included in the CAPs risk working meetings. This will enhance flow of information and provide for coordination of tasks and events. The primary objective of the RWG is to plan and review potential risks as a team at the lowest level possible with consideration of both technical and programmatic input from all stakeholders.

6 ROLES, RESPONSIBILITIES, AND AUTHORITIES

Risk, issue and opportunity management is a requirement that applies across the program and is implemented within all layers of management to include all WIPTs, Directorates, and Product Offices.

IAMD uses a structured assessment approach to identify, assess and analyze processes and products that to the restriction on the title page.

are critical to meeting program objectives. Stakeholders work together to develop risk-handling options to mitigate the risks and monitor the effectiveness of the selected handling options. Key to the success of the risk management effort is the identification and allocation of the resources required to implement the developed risk handling options.

Figure 6-1 depicts how risk is integrated into the program’s organization with the risk responsibilities of the program entities. The IAMD PM has ultimate responsibility for the oversight, management and reporting of risk with technical and programmatic guidance provided by the IAMD Risk Management Board (RMB).

The Risk Management process is contingent upon the participation of everyone on the IAMD Program.

All IAMD Program personnel should consider RM as an essential part of their jobs. Any IAMD stakeholder can submit a risk, via the Risk Survey Form, for consideration by the RWG and/or RMB. The major risk management responsibilities of the assigned team members are outlined in the following subsections.

6.1 Project Manager

The IAMD PM has ultimate responsibility for the oversight and management of cost, schedule, and technical risk(s) and:

• Approves the IAMD RMP

• Approves the Program Acquisition Profile and Affordability Parameters

• Provides risk management direction (when consensus can’t be reached)

• Allocates funds and/or resources, if necessary, to support approved risk mitigation plans

• Provides Risk Management Oversight

• Ensures Flowdown to the WIPTs& IPTs

• Ensures RMP Compliance

• Member of the RMB

• Reports Risks to the PM

• Appoints Risk Management Lead

Program Operations Directorate

• Develops the RMP

• Develops Risk Quantification Criteria

• Implements Risk Management

Process

• Monitors RMP Compliance

• Reports Risk Metrics Monthly

• Maintains Risk Database

• Provides Recommendations to RMB

• Reports RMB Actions/Decisions

• Conducts Risk Management Training

• Prepares Risk Presentations

Risk Management Lead (RML)

• Reviews/Approves Moderate & High Rated Risks Monthly

• Conducts System -level Review of Risks

• Coordinates Risks Among WIPTs& IPTs

• Reviews Risk Schedule and Cost

Impacts

• Recommends Risk Actions to RMB

• Chaired by RML

Risk Working Group (RWG)

Risk Management Board (RMB)

• Reviews/Approves Proposed Risk

• Conducts Periodic Risk Reviews

• Requests Funds for New Risks

• Approves Retirement of Risks

• Documents RMB Actions/Decisions

• Approves Risk Quantification Criteria

• Reviews Adverse Risk Metrics Trends

• Chaired by IAMD PM or Designee

• Identifies and Quantifies Risk

• Develops, Documents, Executes, and

Reports Mitigation Plans

IAMD Stakeholders

• Identifies and Quantifies Risk

• Develops, Documents, Executes, and

Reports Mitigation Plans

IAMD Stakeholders

• Identifies and Quantifies Risk

• Develops, Documents, Executes, and

Reports Mitigation Plans

IAMD Stakeholders

• Provides Risk Management Oversight

• Ensures Flowdown to the WIPTs& IPTs

• Ensures RMP Compliance

• Member of the RMB

• Reports Risks to the PM

• Appoints Risk Management Lead

Program Operations Directorate

• Develops the RMP

• Develops Risk Quantification Criteria

• Implements Risk Management

Process

• Monitors RMP Compliance

• Reports Risk Metrics Monthly

• Maintains Risk Database

• Provides Recommendations to RMB

• Reports RMB Actions/Decisions

• Conducts Risk Management Training

• Prepares Risk Presentations

Risk Management Lead (RML)

• Provides Risk Management Oversight

• Ensures RMP Compliance

• Member of the RMB

• Reports Risks to the PM

• Appoints Risk Management Lead

Program Operations Directorate

• Provides Risk Management Oversight

• Ensures RMP Compliance

• Member of the RMB

• Reports Risks to the PM

• Appoints Risk Management Lead

Program Operations Directorate

• Develops the RMP

• Develops Risk Quantification Criteria

• Implements Risk Management

Process

• Monitors RMP Compliance

• Reports Risk Metrics Monthly

• Maintains Risk Database

• Provides Recommendations to RMB

• Reports RMB Actions/Decisions

• Conducts Risk Management Training

• Prepares Risk Presentations

Risk Management Lead (RML)

• Develops the RMP

• Develops Risk Quantification Criteria

• Implements Risk Management

Process

• Monitors RMP Compliance

• Reports Risk Metrics Monthly

• Maintains Risk Database

• Provides Recommendations to RMB

• Reports RMB Actions/Decisions

• Conducts Risk Management Training

• Prepares Risk Presentations

Risk Management Lead (RML)

• Reviews/Approves Moderate & High Rated Risks Monthly

• Conducts System -level Review of Risks

• Coordinates Risks Among WIPTs& IPTs

• Reviews Risk Schedule and Cost

Impacts

• Recommends Risk Actions to RMB

• Chaired by RML

Risk Working Group (RWG)

• Reviews/Approves Moderate & High Rated Risks Monthly

• Conducts System - level Review of Risks

• Coordinates Risks Among Stakeholders

• Reviews Risk Schedule and Cost

Impacts

• Recommends Risk Actions to RMB

• Chaired by RML

Risk Working Group (RWG)

Risk Management Board (RMB)

• Reviews/Approves Proposed Risk

• Conducts Periodic Risk Reviews

• Requests Funds for New Risks

• Approves Retirement of Risks

• Documents RMB Actions/Decisions

• Approves Risk Quantification Criteria

• Reviews Adverse Risk Metrics Trends

• Chaired by IAMD PM or Designee

Risk Management Board (RMB)

• Reviews/Approves Proposed Risk

• Conducts Periodic Risk Reviews

• Requests Funds for New Risks

• Approves Retirement of Risks

• Documents RMB Actions/Decisions

• Approves Risk Quantification Criteria

• Reviews Adverse Risk Metrics Trends

• Chaired by IAMD PM or Designee

Figure 6-1 IAMD Risk Management Responsibilities to the restriction on the title page.

• Authorizes or delegates authority to report risk data to outside agencies

• Represents IAMD in Contractor Risk Management Board Meetings

• Provide opportunity and issue management oversight and direction

6.2 Program Operations Director

• Establishes the Program Acquisition Profile and Affordability Parameters

• Implements the allocation of funds and/or resources, if necessary, to support approved risk, issue and opportunity plans

• Appoints Risk Management Lead (RML)

• Supports the PM in all risk, issue and opportunity matters

• Ensures RMP compliance

• Provides risk reports to the PM

• Provides oversight and guidance to the RML

6.3 Risk Management Lead

• Develops the RMP

• Develops the risk, issue and opportunity quantification criteria

• Implements the processes of the RMP

• Chairs the RWG

• Supports the RMB administrative functions (sets meeting / agenda / minutes / tracks actions to closure)

• Reports the RMB actions and decisions via meeting minutes

• Prepares and presents risk, issue and opportunity data to the Program Operations Director and

PM

• Supports the Program Operations Director and PM in all risk, issue and opportunity matters

• Maintains the Risk Database

- Records updates to risks, issues and opportunities

- Records changes in likelihood/consequence as agreed upon in RWG/RMB meetings

• Reviews the risks, issues and opportunities for compliance to this plan

• Conducts the risk management training

• Reports the monthly risk metrics

• Represents IAMD at contractor risk meetings

• Reviews and reports on contractor monthly risk report CDRLs

6.4 Risk Point of Contact

The Risk Point of Contact (POC) is a member of the IAMD Team owning the risk, issue or opportunity. The duties of the POC are:

• Work with their directorate/product office to identify potential risks, issues or opportunities to the restriction on the title page.

• Ensures risk planning is documented on Risk Survey Form

• Reviews Risk Survey Form for completeness

• Submits Risk Survey Form to RML

• Provides updates for their risks, issues or opportunities to the RML

• Attends the RWG meetings

• Reports changes to a risk that may have an impact on likelihood and consequence

6.5 Risk Retirement

There are normally four conditions in which a risk may be retired. These conditions are documented below:

1. Whenever a risk is identified, part of the risk documentation process requires that the closure criteria be documented and captured in the risk management database. These criteria may be achieving a specific value, completion of acceptance test, some artifact, etc. After this closure criterion is achieved, a request for the risk retirement is appropriate.

2. When a risk’s mitigation plan is completed, a request to close the risk may be appropriate.

Consideration must be given as to whether the risk was mitigated completely or was mitigated to a manageable and acceptable level. Risk retirement, replanning or opening a new risk may be appropriate options.

3. Sometimes the risk becomes an issue (likelihood reaches 100%) before the risk is fully mitigated.

In this case, the consequences must be minimized by management action. Management action may be to implement a contingency plan that was originally captured in the risk documentation process, request Management Reserve, accept the consequences, etc. At the time that the risk becomes an issue, a request for the risk retirement is appropriate.

4. Whenever some event has occurred that has reduced the risk’s probability and/or consequences to a point where it is no longer considered to be a threat to program goals/objectives, a retirement request is appropriate.

Retirement of watchlisted items may be requested at any time after it is determined that their threat has subsided and they are no longer anticipated to become a risk. The PM is the approval authority for retirement decisions.

7 RISK MANAGEMENT PROCESS AND PROCEEDURES

The IAMD Risk Management process, as shown in Figure 7-1, is designed to ensure risks are identified and handled as early in the program as possible and at as low a cost as possible. This process is comprised of risk planning, identification, analysis, handling and monitoring by the stakeholders. The RWG and the RMB perform initial and periodic review and approval of risk items. Risk items are recorded and reported in our risk database. Once risks are identified and mitigation plans approved, key mitigation activities are integrated into the Program IMS. The following tasks and descriptions are basic to the IAMD Risk Management process.

Risk planning consists of activities to develop, implement, and document the risk management process.

to the restriction on the title page.

Risk identification involves examining the program to determine risk events and associated causes that may have negative cost, schedule, and/or performance impacts. All program personnel are encouraged to identify candidate risks.

Risk analysis provides an estimate of each risk’s likelihood of occurrence and consequence of occurrence, and the resulting risk level in order to more effectively manage risks and prioritize handling efforts.

Risk handling includes the handling options or combination of options and the specific implementation approach. After analyzing the risks, program personnel develop a strategy to manage risks by evaluating the four risk handling options: accept, avoid, transfer and mitigate. Risk mitigation plans are developed for all moderate and high rated risks not classified as avoided, transferred, or assumed as discussed in Section 7.4. Risks are tracked to closure when they are “retired” and maintained in the Risk Database.

Risk monitoring includes a continuous process to systematically track and evaluate the performance of risk handling plans against established metrics throughout the acquisition process. Risk monitoring includes recording, maintaining, and reporting of risks. This process supplies information back into the other risk management activities of planning, identification, analysis and handling as shown in Figure 4- 1.

Fi gu re

-1 I

A M

D R is k

M an ag em en t P ro ce ss to the restriction on the title page.

7.1 Risk Planning

Risk management is integral to effective program management.

Key risk planning attributes include:

• The IAMD RMP has been written, approved, and implemented since 2007

• RMB and RWG are in place and functioning

• RMP is a living document and will be updated to reflect changes in the IAMD program scope

• Training is conducted on a recurring basis

The following sections discuss the IAMD risk management process.

7.2 Risk Identification

Risk identification begins by systematically surveying the IAMD System requirements with established technical, cost, and schedule constraints. IAMD stakeholders evaluate the element(s) within their area for risks and/or shortfalls that may prevent IAMD from reaching its program objectives within its constraints.

The objective of risk identification is to identify and analyze program areas for determination of which problems require the most attention (e.g., resources, effort) for resolution. IAMD stakeholders assess their areas of responsibility to evaluate potential problems that may prevent the successful accomplishment of their scope of work. Risk identification is an element of the IAMD iterative risk management process, and therefore, stakeholders should continually assess the risks in their areas, reviewing risk-mitigation actions and the critical areas whenever necessary to evaluate progress. Figure 7-2 shows the process for identifying and assessing risks on the IAMD Program.

Risk areas generally have one or more of the following characteristics:

• New technology development

• A limited set of subcontractors able to develop critical components or services

• Unique requirements or designs that exceed the capability of currently available manufacturing processes or require new, immature manufacturing processes or test techniques

• Engineering approaches or techniques identified as technical risk areas in recent programs

• Unique test or manufacturing resources with potential schedule conflicts

• Uncertain interface requirements

• Unstable requirements

The first step to risk assessment is identifying and assessing all program areas for potential risks. All risks are evaluated relative to the following seven categories: Technology, Design & Engineering, Performance, Manufacturing, Supportability, Cost and Schedule. Scoring Criteria for the probability of risk occurrence in these areas is defined in Section 3.2.4.1. The thoroughness of the identification process determines the effectiveness of the Risk Management Program. Risks are constantly changing during the life of a program; consequently, risk identification must continue through all program phases.

to the restriction on the title page.

All risk data identified by the Risk POCs is documented to thoroughly describe each risk and the rationale for the risk. This documentation clarifies the source and impact of the risk and prevents different interpretations of the same risk or the redundant identification of risks.

Figure 7-2 Process for Risk Identification and Assessment

7.3 Risk Analysis

Once risk items have been identified, the level of risk they pose in terms of technical, cost, and schedule are analyzed. The analyzed risk associated with elements of the IAMD Program determines the level of risk mitigation activity, if any. Therefore, risk analysis is updated periodically to account for any progress in risk mitigation and ensure the mitigation activities continue to proceed effectively.

Risk analysis requires examining different alternatives to managing a risk. Plans are developed and analyzed to determine the appropriate action to take. The chosen risk mitigation options for handling a risk and the rationale for recommending a certain course of action should be documented in the Risk Database. The risk should be assigned closure criteria such that it can be tracked to its “retirement”. The risk is also associated with a program milestone in this stage. For instance, risks may need to be re-evaluated after a flight test or at a key decision point.

Potential risk areas are documented on a form identified as a Risk Survey Form. This form is used to initially populate the Risk Database. An example of a Risk Survey Form is shown in Figure 7-3. The Risk Survey Form is automated with pull down menus and check boxes with a brief description of each selected field displayed in the Status Bar at the bottom of the screen.

to the restriction on the title page.

This form provides a standard format for defining the issues, documenting areas impacted, and developing plans to handle risks. In the Risk Mitigation Planning area of the form, descriptions of its entries are documented in the notes area. The value for the percentage of risk exposure (RE) to step down when step is completed is a subjective estimate based the subject matter expert’s (SME) experience. The SME may use the Attributes and Evaluation Criteria of Figures 9-2 through 9-9 to assist in developing intermediate reference points. For instance, the SME may know that when one of the steps is completed the RE is reduced to a lower number based on the change of attributes and evaluation criteria. Even in this case a subjective estimate must be made for the intermediate steps.

The Work Breakdown Structure (WBS) provides the framework for identifying and relating issues to the technical, cost, and schedule baselines. In summary, risk identification provides a finite list of issues to be evaluated and tracked. The next step is to assess the issues and quantify their potential impacts to the program.

Figure 7-3 IAMD Risk Survey Form

7.3.1 Technical Risk Analysis

IAMD technical risk is associated with evolving the IAMD architecture to provide a level of expected performance, as delineated in the requirements, within cost and schedule constraints. Technical risk covers five areas: Technology, Design and Engineering, Performance, Manufacturing, and Supportability. The highest risk exposure of the five technical areas becomes the technical rating for the risk. The primary method of initially assessing technical risks is through structured interviews with the Risk POC and applying the risk rating templates contained in this plan.

Technical risks may prevent the end item from performing as intended or from meeting performance expectations. Technical risks can be internally or externally generated, they are typically found in the following areas:

• Physical or material properties

• Testing/modeling

• Integration/interface

• Safety/transportability

• Requirement changes/software design

• Software development

• Fault detection

• Operating environment

• Unproven or immature technology, and system complexity

• Parts obsolescence

• Producibility/manufacturing

7.3.2 Technical Performance Measurement Relationship to Risk Management

Technical Performance Measures (TPMs) gauge design progress, compliance to performance requirements, and technical risks. Early identification and mitigation of program technical risks greatly diminishes the chance of project failure. By carefully selecting and tracking TPMs, project management can assess progress throughout development and make design decisions that ensure the system will meet technical performance objectives that are included in the Acquisition Program Baseline (APB). IAMD System Engineering and the Prime Contractors work together monitoring TPM progress and ensuring threshold levels are maintained. Any TPMs that fall outside of defined threshold levels will enter the IAMD Risk Management process until brought back within acceptable levels. All TPMs must be at threshold levels before work can begin in production. TPM monitoring and risk management are directly related and TPMs are an important tool in the risk management process.

7.3.3 Schedule and Cost Risk Analysis

Schedule risk is uncertainty that the estimated time is sufficient to complete specific IAMD Program activities or milestones. In most cases, schedule risk is a reflection of some other technical or programmatic risk. Cost risk determines the potential cost impacts to the program. Because program costs to the restriction on the title page.

are reported by WBS elements rather than schedule activity, a variety of tools as listed below are used in developing a cost estimate:

• Existing program cost databases

• Government and industry cost models

• In-house-developed cost-estimating relationships

The cost risk analysis includes the impacts to the program for all affected elements identified in the schedule risk analysis. SMEs from the IAMD Cost and Analysis Division may be utilized as needed to assist the RML and Risk POC in conducting a detailed schedule and cost risk analysis.

7.3.4 Quantifying Risk

Once specific program risks are identified, they are quantified in terms of Likelihood and Consequence to estimate their potential impact. This requires that the Risk POC consider the probability of the event occurring and its impact. The highest of the technical, schedule, or cost risk exposure rating becomes the overall risk exposure rating.

7.4 Risk Handling

Once a risk is identified, an appropriate risk handling option is selected. Risk handling answers the question, "What do I do to eliminate or reduce the risk once it has been identified and analyzed?" The following five categories are typically used to describe the possible handling of risk:

Acceptance: Avoiding risk often means revising the system or element design or planning to eliminate those sources of risk. This often means the substitution of one technology for another with lower risk.

Transfer: Transferring or sharing risks can sometimes reduce program risks. Reallocating requirements or resources, or changing the acquisition strategy may accomplish this. A trade study and/or simulation can help determine the optimum balance of system risk.

Avoidance: The program reduces or eliminates the risk event or condition by taking an alternative path.

Mitigation: Seeks to reduce risk to an acceptable level. Mitigation generally entails taking action to reduce the likelihood, and on occasion the consequence, of a risk to as low as possible in order to minimize potential program impacts.

The IAMD Program attempts to reduce program risks by applying the mitigation technique that provides the optimum opportunity for the system to meet program objectives, whether technical, cost, or schedule.

The process depicted in Figure 7-4 can be utilized to assist in the selection of the most appropriate handling option for controlling risks.

8 RISK MANAGEMENT AND OTHER PROGRAM MANAGEMENT

TOOLS

The IAMD Risk Database is a management tool to support decision-making. This MS Access® tool augments the risk management process with an easy-to-use graphic user interface with the capability to store, retrieve, maintain, and report risk data via a relational database. The Risk Database contains risk data generated by the Risk POCs. Risks can easily be added, deleted, and stored to history within the database along with their quantification ratings, mitigation plans, closure criteria, and contingency plans.

Reports containing risk information can be generated in a variety of well-structured formats based on user-specified selection and sorting criteria. Standard database functionality is provided as well as the flexibility to maintain and report risk data within the IAMD Risk Database.

Figure 7-4 Risk Handling Options to the restriction on the title page.

Items of information for each risk in the database include:

• Description of risk

• Point of contact

• Assigned WIPT, Directorate, or Product Office (owner of risk)

• Risk…