Sie sind auf Seite 1von 11

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 organizations 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 programs 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.

RMPR001

Risk Management Procedure

26 September 2012

To be successful, risk management activities must be started early and performed continuously throughout a programs 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 programs 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 programs schedule. Examples include: Planned activities and interdependencies Key events and reviews Milestones Contract performance (dates and deliverables)

RMPR001

Risk Management Procedure Human resource availability

26 September 2012

2.1.2.3. Lead Engineer: Identify performance risks. Identify risks associated to the programs 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: <Program Abbreviation>-<Risk No.> (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).

RMPR001

Risk Management Procedure

26 September 2012

2.2.7. Source: Identify the most relevant source of the risk associated to the root cause indicated (budget, manpower, requirements, schedule, technology, etc.). 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 4

RMPR001

Risk Management Procedure

26 September 2012

3.2.2. Consequence. 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% increase in PAUC/APUC from current baseline estimate, or last approved program cost estimate 3 For Milestone A-B Programs: >10% to 15% increase from MS A approved estimate For Post-Milestone B & Other Programs: >1% but <5% increase in PAUC/APUC from current baseline estimate, or last approved program cost estimate 2 For Milestone A-B Programs: > 5% to 10% increase from MS A approved estimate For Post-Milestone B & Other Programs: <=1% increase in PAUC/APUC from current baseline estimate, or last approved program cost estimate, with potential for further cost increase 1 For Milestone A-B Programs: 5% or less increase from MS A approved cost estimate For Post-Milestone B & Other Programs: limited to <=1% increase in Program Acquisition Unit Cost (PAUC) or Average Procurement Unit Cost (APUC) from current baseline estimate, or last approved program cost estimate Figure 2: Standard AF Consequence Criteria Cost Level 5 4 3 2 1 Standard AF Consequence Criteria Schedule Cannot meet key program or project milestones. Changes required to the program or project critical path. Schedule slip; impacts the ability to meet key dates (e.g., PDR, CDR, etc.) Schedule slip; does not impact the ability to meet key dates (e.g., PDR, CDR, etc.) Negligible schedule slip Figure 3: Standard AF Consequence Criteria - Schedule Level Standard AF Consequence Criteria Performance

RMPR001 5 4

Risk Management Procedure

26 September 2012

2 1

Severe degradation in technical/supportability threshold performance; will jeopardize program success; or will cause a KPP Threshold not to be met. Significant degradation in technical performance or major shortfall in supportability with a moderate impact on program success. Technical performance is unacceptably below the goal; or, no technical design margins available and system performance will be below threshold values. Moderate shortfall in technical performance or supportability with limited impact on program success. Technical performance will be below the goal, but approaching unacceptable limits; or, technical design margins are significantly reduced and jeopardize achieving the system performance threshold values. Minor reduction in technical performance or supportability, can be tolerated with little impact on program success. Technical performance will be below the goal or technical design margins will be reduced, but within acceptable limits. Minimal consequence to technical performance but no overall impact to the program success. A successful outcome is not dependent on this issue; the technical performance goals or technical design margins will still be met. Figure 4: Standard AF Consequence Criteria - Performance

3.2.3. Impact dates. These dates differ from the date the risk was first identified (initiation date) and the review dates which were previously documented. Document the earliest date the risk could impact the program Document the latest date the risk could impact the program 3.2.4. Target Resolution. Document the date by which the risk is expected or desired to be mitigated or resolved 3.3. Program Risk Manager: Prioritize risks. The current priority ranking of a risk is relative to all other risks and based on the analysis performed as calculated using the probability and consequence. Rank 1 is the highest priority; rank 2 is next, and so on. Risk ranking must always be carefully maintained. 4. Program Manager: Handle risks. This step answers the questions, What is the approach for addressing this potential unfavorable consequence? and How do we implement that approach? 4.1. Program Team: Develop risk handling plans. Develop a risk handling plan for each risk. A handling plan for a given risk includes techniques and methods to be used to avoid, reduce, and control the likelihood of occurrence of the risk, the extent of damage incurred, or both. 4.1.1. Determine handling strategy. This activity identifies, evaluates, selects and implements options in order to set risk at acceptable levels given program constraints and objectives. 4.1.1.1. Accept/Assume: assume the level of risk and continue with the current program. 4.1.1.2. Monitor: take no immediate action, but watch for changes.

RMPR001

Risk Management Procedure

26 September 2012

4.1.1.3. Research: collect additional information needed for a decision or reduce uncertainty surrounding risk estimates. 4.1.1.4. Transfer: shift the root cause elsewhere. 4.1.1.5. Mitigate/control: apply methods aimed at eliminating the risk, or reducing the likelihood and/or consequence of the risk. 4.1.1.6. Avoid: Eliminate the root cause of the risk (e.g., not performing an activity that may drive risk). 4.1.2. Develop detailed risk handling steps. The risk handling plan will describe the approach that will be taken to reduce the likelihood or consequence of occurrence thus reducing overall risk exposure. Producing good handling steps requires planning out the following details for each step in your plan. Descriptions Priority Start and due dates Potential costs Deliverables Target Score: the new likelihood and consequence should this response plan be successful. 4.1.3. Develop contingency plan (fallback plan). A contingency or fallback plan is a set of actions to take in the event critical risks materialize. The contingency plan should include, at a minimum, alternative courses of action, work-arounds, and fallback positions, with a recommended course of action. All High (Red) risks require a contingency plan (fallback plan). 4.2. Program Manager: Report and Escalate Risks For all risk reporting, Programs will use the standard 5x5 Risk Matrix and Details Table as shown in Figures 5, 6, and 7 below.

RMPR001

Risk Management Procedure

26 September 2012

5
H IGH

4 L ikelihood 3 2
L OW MED IUM

1 1 2 3 4 5

C onsequence
Figure 5: Standard 5X5 Program Risk Matrix
R a nk R iskD es cription

Figure 6: Risk Descriptions

RMPR001

Risk Management Procedure

26 September 2012

R ank

R iskD escription

H a ndling/ Mitig a tion

T arg et D ate

POC

Figure 7: Risk Details Table Program Managers and Division Directors will follow the criteria depicted in Figure 8 below to determine when conditions warrant the escalation of program risks to higher authority. Document the escalation strategy in your Risk Management Plan.

Figure 8: Risk Escalation Criteria 4.3. Implement risk handling activities. Implement the risk handling steps as approved by the Program Manager. 5. Program Manager: Manage and track risks. This step answers the question How are things going? The Program Manager must be proactive and monitor these risks throughout the programs life cycle. 5.1. Assign responsibility.

RMPR001

Risk Management Procedure

26 September 2012

Document the name of the person responsible for tracking or managing each risk. 5.2. Monitor risks. Monitor the status of each risk throughout the program's life cycle. 5.2.1. Update Status. Systematically review initially identified and baselined risks. Analyze them to determine their status. Archive risks when they are no longer present or have been closed. 5.2.2. Update handling step progress. 5.2.3. Update contingency plan (fallback plan). 5.2.4. Maintain risk history. Maintain a historical events log on each risk. This log is the recording of events about the risk that might be useful in evaluating its importance or in justifying specific actions that were taken. For instance, external events might occur that caused a change to the impact or probability of the risk. It can serve as a repository of thoughts and decisions that affect how the risk was perceived, mitigated, and/or retired. 5.2.5. Report Status to Management. Program Managers must perform periodic reviews of program risks. The Program Manager is responsible for briefing senior management and senior functional staff members to provide visibility into the programs overall risk exposure. 5.3. Monitor and control the risk management process. Include all members of the Program Team in monitoring and controlling risks. Implement corrective actions or mitigation actions as required. Use metrics to help in monitoring and controlling risks. Recommended metrics may include the following: Number of risks identified, managed, tracked, and controlled; include a breakdown based on priority Risk age; risk growth within the program Risk exposure and changes to the risk exposure for each assessed risk Change activity for the risk mitigation plans (e.g. processes, schedule, funding) Impact timeframes/dates (initiation date, trigger dates, expiration dates, target resolution dates, etc) Occurrence of unanticipated risks Risk categorization volatility Comparison of estimated vs. actual risk mitigation effort and impact 5.4. Continuously identify new and potential risks. As the program progresses, new risks will become a threat to its success. When they do, follow this procedure to identify, document, analyze, mitigate, and track those risks. Exit Criteria: The following are a result of completing this procedure: Risk Management Plan or Documented Risk Management Strategy Updated Risk Management Tool: o Identified, analyzed, and documented program risks

10

RMPR001

Risk Management Procedure

26 September 2012

o Handling plan steps for all documented risks o Contingency/Fallback plans for all High (Red) risks Escalated Risks (as appropriate)

11