Risk Management Procedure Example：风险管理程序example

Risk Management ProcedureSystems Engineering Discipline:Risk ManagementDescription: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 IdentifiedProcedure 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.To be successful, risk management activities must be started early and performedcontinuously 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 reviews2. 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 beinternal or external to the program and in some cases may be both. Additional risksources may be identified throughout the program life cycle. Early identification ofsources leads to early identification of risks, and early mitigation plans may precludeoccurrence of or reduce consequences if they occur. Listed below are some typicalexamples 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 lifecycle 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 budgets2.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 availability2.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/Security2.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 toensure that all aspects of the work effort have been considered.For example, the Contracting Officer should lead the identification of any risksassociated with:•Acquisition strategy•Contract management•CompetitionIn another example, the Customer should lead the identification of any risksassociated 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 tablesand 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 documentingtheir 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 categoriesidentified above (cost, schedule, performance, other).2.2.7. Source: Identify the most relevant source of the risk associated to the root causeindicated (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 a nswers 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 ProgramTeam. 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 thefunctional team member that leads that program area, the thorough analysis andevaluation of those identified risks also remains the responsibility of those functionalleads.3.1.2. Each risk is evaluated and scored in accordance with the defined risk parametersidentified 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 berequired.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 impacttime frame. It is measured in percent and based on professional judgment or historicaldata. Chapter 12 of AFPAM 63-128, Guide to Acquisition and Sustainment Life CycleManagement, identifies values that range from 5% (extremely unlikely) to 99% (almostcertain). The likelihood value will likely change over time as the risk is activelymanaged. Use the ratings in Figure 1 below as a guide in assigning the likelihood ratings:Figure 1: Likelihood Rating Criteria3.2.2. Consequence.Consequence is an undesirable event or impact which would negatively affect theprogram should the risk materialize. Consequence is a subjective ranking made by theProgram 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:Figure 2: Standard AF Consequence Criteria – CostFigure 3: Standard AF Consequence Criteria - ScheduleFigure 4: Standard AF Consequence Criteria - Performance3.2.3. Impact dates.These dates differ from the date the risk was first identified (initiation date) and thereview dates which were previously documented.•Document the earliest date the risk could impact the program•Document the latest date the risk could impact the program3.2.4. Target Resolution.Document the date by which the risk is expected or desired to be mitigated or resolved3.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 highestpriority; 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 consequ ence?”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 includestechniques 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 atacceptable levels given program constraints and objectives.4.1.1.1. Accept/Assume: assume the level of risk and continue with the currentprogram.4.1.1.2. Monitor: take no immediate action, but watch for changes.4.1.1.3. Research: collect additional information needed for a decision or reduceuncertainty 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 thelikelihood 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 risksmaterialize. 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 RisksFor all risk reporting, Programs will use the standard 5x5 Risk Matrix and Details Table as shown in Figures 5, 6, and 7 below.Consequence L i k e l i h o o d Figure 5: Standard 5X5 Program Risk MatrixFigure 6: Risk DescriptionsFigure 7: Risk Details TableProgram 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 Criteria4.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 a nswers the question “How are things going?” The Program Manager must be proactive and monitor these risks throughout the program’s life cycle.5.1. Assign responsibility.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 theimpact 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 ProgramManager is responsible for briefing senior management and senior functional staffmembers to provide visibility into the program’s 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 impact5.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 riskso Handling plan steps for all documented riskso Contingency/Fallback plans for all High (Red) risks•Escalated Risks (as appropriate)。