Risk Management Procedure

RMPR001

Risk Management Procedure

26 September 2012

Risk Management Procedure Systems Engineering Discipline: Risk Management Description: Risk Management addresses future uncertainties that could endanger achievement of program objectives and identifies potential problems before they occur so that risk-handling activities may be planned and implemented to mitigate adverse impacts should a risk be realized. Risk must be captured within individual programs and initiatives as well as an integrated systems perspective. Risks may have dependencies to other programs within the Directorate or outside the organization. This procedure documents the organization’s enterprise risk management strategy and provides the details necessary to support the execution of a disciplined and effective risk management program within the Directorate. Entry Criteria: Complete the following before beginning this procedure: 

Risk Management Stakeholders Identified

Procedure Steps: (These steps are not always performed sequentially.) Although the Program Manager is ultimately responsible to ensure risk management activities are performed throughout the life cycle of any work effort, key roles are identified below as the lead for certain steps or activities. 1. Program Manager: Plan risk management activities. 1.1. Document the program risk management strategy. A program unique Risk Management Plan (RMP) is recommended for all programs/projects. Refer to the Risk Management Plan Template in Attachment 2 of AFMCPAM 63-101, Life Cycle Risk Management. However, if a program does not prepare a RMP, a documented strategy or plan for how risk management activities will be conducted throughout the life cycle of the program must be incorporated into the program’s Life Cycle Management Plan or Systems Engineering Plan. To be complete, this strategy should, at a minimum, document the following:  The specific roles and responsibilities of program team members in the risk management process.  The processes used to identify, capture, analyze, handle, and monitor risks within the program.  The tools that will be used to execute the risk management strategy.  The frequency of risk management activities (meetings, reviews, customer briefs, etc.). 1.2. Resource the Risk Management Plan.

1

RMPR001

Risk Management Procedure

26 September 2012

To be successful, risk management activities must be started early and performed continuously throughout a program’s life-cycle. The Program Manager should:  Formally designate a Program Risk Manager  Establish a battle rhythm of risk management workshops/reviews  Provide a mechanism for team members to present risks or updates outside of scheduled reviews 2. Program Team: Identify risks. 2.1. Program Team: Identify risks. Any Program Team member or stakeholder may identify risks. 2.1.1. Determine risk sources. Risk sources are the common areas where risks may originate. Risk sources can be internal or external to the program and in some cases may be both. Additional risk sources may be identified throughout the program life cycle. Early identification of sources leads to early identification of risks, and early mitigation plans may preclude occurrence of or reduce consequences if they occur. Listed below are some typical examples of risk sources:  Requirements (i.e., unclear operational needs, attributes, constraints, technology, or design processes; change frequency, etc.)  Technical Baseline (infeasible or incomplete design)  Schedule (unrealistic schedule estimates and/or allocation, concurrency)  Manpower (inadequate staffing and/or skills)  Cost/Budget (uncertainty of estimates, funding issues)  External Factors (facilities, infrastructure, subject matter expertise, etc.) 2.1.2. Identify risk categories. There are three designated risk categories. These categories identify risks associated with cost, schedule, or performance. Risks should be examined during all phases of the life cycle to the extent they impact program objectives. Listed below are the main categories of risks and some examples: 2.1.2.1. Financial Manager: Identify cost risks. Identify risks associated to the program’s cost. Examples include:  Development costs  Product acquisition costs  Cost of spare or replacement products  Product disposition costs that have design implications  Funding levels, estimates, or distributed budgets 2.1.2.2. Program Manager: Identify schedule risks. Identify risks associated to the program’s schedule. Examples include:  Planned activities and interdependencies  Key events and reviews  Milestones  Contract performance (dates and deliverables)  Human resource availability

2

RMPR001

Risk Management Procedure

26 September 2012

2.1.2.3. Lead Engineer: Identify performance risks. Identify risks associated to the program’s performance. Examples include:  Requirements  Interface and interoperability complexities  Infrastructure limitations  Data Conversion  Analysis and design  Application of new technology  Technical performance and operation such as throughput  Verification and Validation  Development and Test Environments  Information Assurance/Security 2.1.2.4. Program Manager: Identify other risks. Identify any other risks that fall into the cost, schedule, or performance categories. Program Teams should review all elements of their work breakdown structure to ensure that all aspects of the work effort have been considered. For example, the Contracting Officer should lead the identification of any risks associated with:  Acquisition strategy  Contract management  Competition In another example, the Customer should lead the identification of any risks associated with operational suitability or funding availability. 2.2. Program Risk Manager: Document program risks. It is important to be thorough in this step of the process. One of the keys to writing good risk and issue statements is to focus on a tangible, measurable event that may occur rather than a vague statement. Once a risk has been identified, the following minimum information should be captured: 2.2.1. Identifier: - (e.g., ABC-001) 2.2.2. Title: Use a short, meaningful title so that the risk can be easily identified in tables and standard reporting systems. 2.2.3. Owner: Identify the individual best suited to manage the risk. 2.2.4. Description of the risk: Teams should use the "If, then" logic when documenting their risks remembering that the “If” is the cause and the “Then” is the effect of the risk on the project. 2.2.5. Phase: Identify the phase of the acquisition life cycle the risk may impact. 2.2.6. Category (program area): Use this element to place risks into the categories identified above (cost, schedule, performance, other). 2.2.7. Source: Identify the most relevant source of the risk associated to the root cause indicated (budget, manpower, requirements, schedule, technology, etc.).

3

RMPR001

Risk Management Procedure

26 September 2012

2.2.8. Initiation Date: Insert the date the risk was identified. 2.2.9. Next Review Date: Insert the date of the next anticipated review. 3. Program Team: Analyze and evaluate risks. This step answers the question “How big is the risk?” 3.1. Program Team: Analyze risks. Analyzing risks is a key part of risk management and should involve the entire Program Team. It includes maintaining a database of program risks so that the most important risks can be prioritized based on the judgment of the Program Team. 3.1.1. Just as the identification of certain types of risk is the responsibility of the functional team member that leads that program area, the thorough analysis and evaluation of those identified risks also remains the responsibility of those functional leads. 3.1.2. Each risk is evaluated and scored in accordance with the defined risk parameters identified below. The goal is to identify the highest-priority risks and focus risk handling resources on them as the program evolves over time. As risk handling steps are put into place, risk parameters may change over time and therefore frequent adjustments may be required. 3.2. Program Team: Score risk parameters. To ensure consistent and rigorous execution and reporting, all programs, without deviation, must use the standard 5x5 risk matrix, likelihood criteria and consequence criteria to analyze program risks (see below). Realizing that every risk may have multiple consequences (performance, cost, and schedule) to be assessed, the matrix should depict the consequence with the most severe impact. Risk handling plans will be prepared for all Medium (Yellow) and High (Red) program risks. Parameters for evaluating, categorizing, and prioritizing risks include the following: 3.2.1. Likelihood. Likelihood is the current estimate of probability that the risk will occur over the impact time frame. It is measured in percent and based on professional judgment or historical data. Chapter 12 of AFPAM 63-128, Guide to Acquisition and Sustainment Life Cycle Management, identifies values that range from 5% (extremely unlikely) to 99% (almost certain). The likelihood value will likely change over time as the risk is actively managed. Use the ratings in Figure 1 below as a guide in assigning the likelihood ratings: Rating 5 4 3 2 1

Probability of Occurrence 81 – 99 % 61 – 80 % 41 – 60 % 21 – 40 % 5 – 20 %

Likelihood Near Certainty Highly Likely Likely Low Likelihood Not Likely

Figure 1: Likelihood Rating Criteria 3.2.2. Consequence.

4

RMPR001

Risk Management Procedure

26 September 2012

Consequence is an undesirable event or impact which would negatively affect the program should the risk materialize. Consequence is a subjective ranking made by the Program Team using past experience, historical data or comparison to other systems. The primary purpose of the consequence value is to help rank program risks. This value may change over time as the risk is actively managed. Use the Standard AF Consequence Criteria for each category of risk (cost, schedule, and performance), as described within Chapter 12 of AFPAM 63-128, Guide to Acquisition and Sustainment Life Cycle Management, to assign a consequence value to each risk. See Figures 2, 3, and 4 below as a guide in assigning consequence levels: Level Standard AF Consequence Criteria – Cost 5  For Milestone A-B Programs: >20% increase from MS A approved cost estimate  For Post-Milestone B & Other Programs: >=10% increase in PAUC/APUC from current baseline estimate (danger zone for significant cost growth and NunnMcCurdy breach), or last approved program cost estimate 4  For Milestone A-B Programs: >15% to 20% increase from MS A approved estimate  For Post-Milestone B & Other Programs: 5% but 10% to 15% increase from MS A approved estimate  For Post-Milestone B & Other Programs: >1% but 5% to 10% increase from MS A approved estimate  For Post-Milestone B & Other Programs: