Your SlideShare is downloading. ×
Risk Management Process
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Risk Management Process

1,785
views

Published on

Published in: Business, Economy & Finance

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,785
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
148
Comments
0
Likes
3
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. PR-RSKM-01 V1.1 Risk Management Process for SSC Pacific 5/12/10 Process: Risk Management Phase: Global Process Owner: SSC Pacific 5.0 Competency Description: The purpose of the Risk Management (RSKM) Process is to provide an overarching process that provides risk identification, analysis, mitigation planning, mitigation plan implementation, and tracking to ensure early identification and handling of risks. Risk is a measure of future uncertainties in achieving project performance goals and objectives within defined cost, schedule, and performance constraints. Risk can be associated with all aspects of a program or project. RSKM should begin at the earliest stages of project planning and continue throughout the total life cycle of the project. Entry Criteria/Inputs: Exit Criteria/Outputs: • Overarching plans exist to plan this process, • Risks and their mitigation and/or establish integrated schedules, assign contingency plans (for selected risks) are responsibilities, establish monitoring procedures, documented and updated and provide for improvement of this process • Risk mitigation and contingency plans have • Adequate resources are committed to RSKM been implemented as needed activities • Measurements of the status of the risk have • Personnel performing RSKM activities are been collected, analyzed, and stored trained, understand the components of risk and the • Review with higher-level management has difference between a risk and an issue. been completed to resolve issues • Action/Issues/Risk Log (see Project Estimation Process, reference (a), for a description of the log) Roles: • Senior Management/Sponsor: Provide visible and continuous support. Review risk activities, status, and results periodically. • Project Manager (PM): Responsible for planning, allocating resources, and executing RSKM in accordance with the Systems/Software Engineering Management Policy, SSC San Diego Instruction 5234.2, reference (b). Determines the best use of project resources (personnel and activities) to optimize their contribution to the RSKM Process. Participates on Risk Board. • Risk Manager (RM): Responsible for controlling the risk process and chairing the Risk Board. • Risk Board (RB) Members: As members of a risk control board or other identified risk group, provide oversight of the project’s RSKM process. Evaluate risks and their root causes, unfavorable event indications, and planned risk mitigations. • Risk Owner (RO): Develops and carries out the risk response, and tracks risk status. • Project Members: Identifies risks. Participates in or supports Risk Board as required. • Quality Assurance (QA): Reviews RSKM activities, ensures adherence to RSKM Process. • Configuration Management (CM): Controls designated risk work products. Assets/References: a. Project Estimation Process for SSC Pacific, PR-PP-09, SSC Pacific b. Systems/Software Engineering Management Policy, SSC San Diego Instruction 5234.2 c. Risk Management Guide for DoD Acquisition at: http://www.acq.osd.mil/sse/docs/2006RMGuide4Aug06finalversion.pdf d. Capability Maturity Model Integration (CMMI) for Development, Version 1.2, Carnegie Mellon University (CMU)/Software Engineering Institute (SEI), CMU/SEI-2006-TR-008, August 2006 e. SSC Pacific Risk Management Plan Template f. Risk Identification and Management Record Form g. SSC Pacific Instruction 5090.2 (series): Procedures to Ensure Compliance with the National Environmental Policy Act and Executive Order 12114 h. SSC Pacific Instruction 3900.10 (series): Protection of Human Subjects in Research and Development i. SSC Pacific 5104.1(series): Projects that engage in any use of Radioactive Sources, Radiation Producing Machines or Machines Containing Radioactive Sources j. Project Monitoring and Control Process, PR-PMC-03, SSC Pacific 1
  • 2. PR-RSKM-01 V1.1 Risk Management Process for SSC Pacific 5/12/10 k. Naval SYSCOM Risk Management Policy, SPAWAR Instruction 3058.1 Tasks: 1. Determine Risk Sources and Categories 6. Risk Mitigation/Contingency Planning 2. Define Risk Parameters 7. Risk Tracking/Communication 3. Establish a RSKM Strategy 8. Risk Mitigation/Contingency Plan 4. Risk Identification Implementation 5. Risk Analysis Measures: • Effort and funds expended in RSKM activities as compared to the plan • Number of risks identified, tracked, controlled and retired • RSKM effort and/or costs and Return on Investment (ROI) of risk mitigation activities • Occurrence of unexpected issues that were not identified earlier as risks (These are suggested measures. Use one or more or devise your own.) Process Overview Diagram Planning & Organizing: Determine Risk Sources and 4. Risk Identification Categories Identify Uncertainties and Risks Define Risk Parameters 5. Risk Analysis Define Consequence and Likelihood of Occurrence Establish a RSKM Strategy 6. Risk Mitigation/Contingency Planning Reduce Consequence and/or Likelihood of Occurrence 7. Risk Tracking/ Iterative Communication Process Track and Communicate Risk Status 8. Risk Mitigation/Contingency Plan Implementation Implement reduction/mitigation plans as directed 2
  • 3. PR-RSKM-01 V1.1 Risk Management Process for SSC Pacific 5/12/10 PROCESS TASKS: 1. Determine Risk Sources and Categories (PM/RM/RB) Determine and evaluate the sources of risk. Risk sources are the fundamental drivers that cause risk within a project/task or organization. There are many sources of risks, both internal and external to a project. Risk sources identify common areas where risks may originate. Risk sources can be identified by examining each element of the WBS and process in terms of causes or areas of risk. As the project progresses, additional sources of risk may be identified. Determine risk categories. Risk categories reflect the “bins” for collecting and organizing risks and are logical groupings of potential causes of risk. Identifying risk categories helps to consolidate the activities in risk mitigation plans, provides information about which areas of the project have the highest degree of uncertainty, and gives further insight in the identification and analysis of risks. Example categories: Project life cycle phase, type of process, type of product, project management risks (e.g., contracts, budget/cost, schedule, resources, supportability). Other example categories and sources can be found in the Risk Management Guide for DoD Acquisition, reference (c), and the CMMI Guidelines for Process Integration and Product Improvement, reference (d). 2. Define Risk Parameters (PM/RM/RB) Define consistent criteria for evaluating and quantifying the likelihood and consequence of risk, and the thresholds for each risk category. Define the parameters used to analyze risks and the parameters used to control the RSKM effort. Consistently used criteria (e.g., the bounds on the likelihood and consequence levels) allow the impacts of different risks to be commonly understood, to receive the appropriate level of scrutiny, and to obtain the management attention warranted. In managing dissimilar risks (for example, personnel safety versus environmental pollution), it is important to ensure consistency in end result (e.g., a high risk of environmental pollution is as important as a high risk to personnel safety). Define thresholds for each risk category to determine acceptability or unacceptability of risk, prioritization of risks, and triggers for management action. Define bounds on the extent to which thresholds are applied against or within a category. Definition of bounds (or boundary conditions) can be used to help scope the extent of the RSKM effort and avoid excessive resource expenditures. Additional information can be found in reference (c) and reference (d). 3. Establish a RSKM Strategy (PM/RM/RB) Define a risk strategy presenting the project’s approach to managing risk, and document the strategy in the Risk Management Plan. The RSKM strategy includes the sources, categories, and parameters from Tasks 1 and 2; risk handling options (accept, avoid, share, mitigate) and mitigation techniques; thresholds and triggers; methods, measures, and tools. Review the RSKM strategy with relevant stakeholders to promote commitment and common understanding. Refer to the SSC Pacific Risk Management Plan (RSKM Plan) Template, reference (e), for guidance in developing a risk plan and strategy. 4. Risk Identification (All roles) Risk identification should be an organized, thorough approach to seek out probable or realistic risks that could prevent achieving objectives. To be effective, risk identification should not address every possible event. Use of risk sources, categories, and parameters, can help scope risk identification efforts. Risk can be associated with all aspects of a project, and risk identification is the responsibility of every member of 3
  • 4. PR-RSKM-01 V1.1 Risk Management Process for SSC Pacific 5/12/10 the team. The intent of risk identification is to answer the question: What are the major uncertainties to the program or project and what can go wrong? Risks must be identified and described in an understandable way before they can be analyzed and managed properly. Document risks in a concise statement that includes the context, conditions, and consequences of risk occurrence. The risk context provides additional information such that the intent of the risk can be easily understood. In documenting the context of the risk, consider the relative time-frame of the risk, the circumstances or conditions surrounding the risk that have brought about the concern, and any doubt or uncertainty. Document identified risks in the project’s Actions/Issue/Risk Log and Risk Identification and Management Record Form, reference (f). A project can be examined for risks through decomposition into relevant elements or areas, such as requirements, processes, functional areas (functional analysis), technical baselines, or acquisition phases. Another method is to use the Work Breakdown Structure (WBS), which is particularly useful in identifying product and some process-oriented risks. To identify risks and their root causes, break down project elements to a level where Subject Matter Experts (SMEs) can perform valid identification by WBS or Integrated Master Schedule (IMS) line item. During decomposition, risks can be identified based on prior experience, brainstorming, lessons learned from similar projects, and guidance contained in overarching RSKM Plans. Other methods for identifying risk may include, but are not limited to, brainstorming, Delphi technique, interviewing, root cause analysis and Strengths, Weaknesses, Opportunities and Threats (SWOT) analysis. For additional information and to aid identifying risks, refer to reference (e). For environmental, safety, and radiation hazard risks, SSC Pacific projects should refer to following instructions: SSC Pacific Instruction 5090.2 (series): Procedures to Ensure Compliance with the National Environmental Policy Act and Executive Order 12114, reference (g); SSC Pacific Instruction 3900.10 (series): Protection of Human Subjects in Research and Development, reference (h); and SSC Pacific 5104.1 (series): Projects that engage in any use of Radioactive Sources, Radiation Producing Machines or Machines Containing Radioactive Sources, reference (i). It may be appropriate to refer to additional DoD, DoN, or other instructions dependent upon the type of work performed by the project. 5. Risk Analysis (RB/RM/PM) Analyze risks by: (1) evaluating, (2) prioritizing and (3) categorizing identified risks against defined parameters (Task 2), and (4) determining the risk handling options. The analysis of risks is needed to assign relative importance to each identified risk and to identify how the risk should be handled; this information is used in determining when management attention is required. The intent of risk analysis is to answer the question: How big (important) is the risk, by performing the activities listed below: a. Determine the likelihood or probability of the risk occurring b. Identify the possible consequences or impact in terms of performance, schedule, and cost c. Determine the risk rating and priority. Often it is useful to aggregate risks based on their interrelationships, and develop options at an aggregate level. When an aggregate risk is formed by a rollup of lower-level risks, care must be taken to ensure that important lower-level risks are not ignored. Note: This process may be used for risk analysis requests. Typically these would enter the RSKM Process in this task unless the previous tasks (1-4) had not been performed. 6. Risk Mitigation/Contingency Planning (RO/PM) Risk mitigation planning is the activity that (1) identifies, (2) evaluates, and (3) selects options to set risk at acceptable levels given project constraints and objectives. This can also include contingency plans to 4
  • 5. PR-RSKM-01 V1.1 Risk Management Process for SSC Pacific 5/12/10 deal with the impact of selected risks that may occur despite attempts to mitigate them, or avoidance plans to circumvent a risk before it can be realized. Risk mitigation planning is initially completed by the risk owner, and it includes the specifics of what should be done, when it should be accomplished, who is responsible, and the resources required to implement the risk mitigation plan; this is then brought to the Risk Board for review. The intent of risk mitigation planning is to answer the question: What is the best mitigation approach? For each root cause or risk, the type of mitigation must be determined and the details of the mitigation described. A person or group will have responsibility for addressing each risk that is identified, and, when applicable, the estimated quantitative benefits of implementing the risk mitigation plan are determined. Once alternatives have been analyzed, the selected mitigation option should be incorporated into existing project plans or documented separately as a risk mitigation plan. Contingency plans are developed for selected critical risks in case the impact of the risk is realized (they may include redesigning features, reallocation of resources, or others). Triggers are defined for determining when a mitigation or contingency plan is implemented. Avoidance plans may be developed for selected and avoidable risks when the cost of circumventing the risk outweighs the risk’s impact upon the project. 7. Risk Tracking/Communication (RM/RB/RO) Risk tracking is the activity of systematically evaluating the status of risks. It feeds information back into the other risk activities of identification, analysis, handling (e.g., mitigation/contingency planning), and mitigation/contingency plan implementation, and also assists in tracking risk dependencies. Risks are updated in the Actions/Issue/Risk Log and reference (f), and are tracked to closure. The risk log shall include risk name and description, likelihood, consequence, priority, and mitigation/contingency plans, as well as any metrics defined for tracking the risk and risk dependencies. The intent of risk tracking answers the question: “How are things going?” by performing the activities below to track risks: a. Regularly review and re-evaluate status of all risks b. Monitor risk mitigation and contingency efforts (the Project Monitoring and Control Process, reference (j), establishes monitoring procedures to capture issues and risks associated with planning and tracking) c. Display RSKM status for developing trends d. Track impending triggers when risk mitigation or contingency plans need to be implemented The key to the tracking activity is to establish a management indicator system. The PM uses this indicator system to evaluate the status of the project throughout the life cycle. It should be designed to provide early warning when the likelihood of occurrence or the severity of consequence exceeds established thresholds and reaches the predetermined triggers. This way, planned mitigation efforts can be applied quickly to reduce the risk or avert issues. Another objective of risk tracking is to communicate risks and risk status to all affected stakeholders, including management, to establish a clear understanding and support for the project risk management strategy; to manage stakeholder expectations; and to effectively manage risks. A sample risk reporting format can be found in the Naval SYSCOM Risk Management Policy, SPAWAR Instruction 3058.1, reference (k). 5
  • 6. PR-RSKM-01 V1.1 Risk Management Process for SSC Pacific 5/12/10 8. Risk Mitigation/Contingency Plan Implementation (RO) The appropriate members of the project take the lead and implement mitigation/contingency plans as directed by the PM. Selected risk-handling options are invoked, and a schedule is developed for each risk handling activity. Resources are committed to ensure risk mitigation activities can be carried out successfully, and performance measures are collected on the risk mitigation activities. The intent is to ensure successful risk mitigation occurs and to answer the question: How can the planned risk mitigation be implemented? Contingency plans are implemented for selected critical risks when the predefined trigger is reached and the risk is realized. Tailoring Guidance Task(s) may be added to this process or combined with other tasks but may not be deleted. Tasks may be reworded to reflect competency terminology so long as the spirit of the task is retained. 6