RETTEW Associates, Inc. RISK MANAGEMENT PLAN. for. (client project/rfp number) (date of proposal submission)

Transcription

1 RISK MANAGEMENT PLAN for (client project/rfp number) (date of proposal submission) This proposal includes data that shall not be disclosed outside the government and shall not be duplicated, used, or disclosed in whole or in part for any purpose other than to evaluate this proposal. If, however, a contract is awarded to this offeror as a result of or in connection with the submission of this data, the government shall have the right to duplicate, use, or disclose the data to the extent provided in the resulting contract. This restriction does not limit the government s right to use information contained in this data if it is obtained from another source without restriction.

2 Table of Contents 1.0 DESCRIPTION INTRODUCTION PURPOSE PROJECT RISK ANALYSIS Risk Analysis Tools Aspects of Risk Severity of Risk... 4 Figure Risk Assessment Assignment Matrix Risk Verification APPROACH TO RISK MANAGEMENT RISK DEFINITIONS Technical Risk Programmatic Risk Supportability Risk Cost and Schedule Risk METHODS OVERVIEW Techniques Applied... 7 Figure Key Indicator Programmatic Risk APPLICATION RISK ASSESSMENT Step 1: Planning for Risk Assessment Step 2: Identifying Program Objectives or Requirements Step 3: Defining Program Risks... 9 Figure Affinity Diagram Step 4: Ranking Program Risks Step 5: Managing Program Risks Step 6: Managing Action Plans Step 7: Continually Assessing Program Risks RISK RESPONSE DEVELOPMENT Avoidance Control Retention RISK RESPONSE CONTROL REFERENCES AND FOUNDATIONAL DATA SOURCES

3 1.0 Description 1.1 Introduction, is proud to offer our Risk Management Plan (RMP) in support of (client RFP number). RETTEW presents a unique blend of private and public sector skills and historical success in identifying, reducing, and managing client project risk to achieve client goals and objectives. Our diverse, talented team incorporates a best-of-breed strategy by using cutting edge risk management tools and methodologies as described within this RMP to maximize our client s resources and RETTEW s value as a world-class contracting partner. 1.2 Purpose Risk Management, according to T.V. Caver, is a method of managing that concentrates on identifying and controlling the areas or events that have a potential of causing unwanted change it is no more and no less than informed management. This RMP presents RETTEW s process for implementing proactive risk management as part of the overall management of the (client RFP number). Risk management is a program management tool used to assess and mitigate events that might adversely impact a project. Successful implementation of risk management will increase the program s likelihood of success. This RMP will: Serve as a basis for identifying alternatives to achieve cost, schedule, and performance goals; Assist in making decisions on schedule and task priorities; Provide risk information for Program Reviews or Milestone decisions; and Allow monitoring the health of the program as it proceeds. The RMP also describes methods for identifying, analyzing, prioritizing, and tracking risk drivers, developing risk-handling plans, and planning for adequate resources to handle risk. It assigns specific responsibilities for the management of risk and prescribes the documenting, monitoring, and reporting processes to be followed. 1.3 Project Risk Analysis Project risk analysis is initially performed in the early stages of a project s lifecycle usually during the planning stage to identify potential risks, the associated impacts, and potential mitigation plans. In addition to performing the initial risk analysis, it is recommended that the analysis be periodically reviewed and updated especially if an identified risk is realized. 3

4 1.3.1 Risk Analysis Tools. Risk analysis is a formal process that can be performed using dedicated tools such as: Strength-Weakness-Opportunity-Threat (SWOT) analysis Risk Priority Number (RPN) or risk priority matrix Failure Mode and Effects Analysis (FMEA) These tools can be combined with other tools like brainstorming to ensure effective coverage for risk identification, analysis of potential impact if the risk is realized, and potential mitigation plans Aspects of Risk. Successful risk analysis depends, in part, on ensuring that appropriate organizations are represented during risk analysis meetings and that all aspects of potential risk are considered. Aspects of risk to consider include, but are not limited to, the potential impact on: Meeting established goals or objectives The planned schedule Identified resources Safety Produceability Serviceability Reliability Meeting customer expectations and requirements Severity of Risk. Risk assessment involves determining the impact of severity if the risk occurs and the probability that the risk will occur. Determining the impact of severity is usually done by performing analysis of like risks from other projects, historical data, and through the use of other methods such as brainstorming. Risk probability is determined based on the likelihood that the risk will occur during the execution of the project. A risk assessment assignment matrix, as shown in Figure below, helps the project by having each risk individually ranked on a color-coded R/Y/G scale for severity and probability. Figure 1.3.3: 4

5 After identification of the risks, risk mitigation and verification are performed throughout the project s lifecycle. Risk mitigation begins with identifying activities the team or organization can perform to reduce the likelihood that an identified risk will occur and/or to reduce its impact. Once risk mitigation planning occurs, the plans are implemented during the project and should be reviewed on a regular basis to assess the status of existing risks and determine whether new risks have been identified or if identified risks were realized Risk Verification. Risk verification is the process of ensuring that the risk mitigation activities reasonably prevent the risk from occurring. An example is the security risk for an automated teller machine the risk that someone else can access your bank account. The mitigation is the additional requirement of a secured numeric password, along with a restriction of three false attempts before the account would freeze, locking out even the owner of the account. The verification is the attempt to access a secured account with an invalid, null, or otherwise compromised password. 5

6 2.0 Approach to Risk Management 2.1 Risk Definitions Risk must be classified in order to make it manageable. Four facets of risk are used to manage cost, schedule, and performance issues faced on a project. Classifying a risk into one or more of the four facets requires examining the source of the risk. The four facets are: Technical Risk. Technical risk (performance related) is the risk associated with evolving a new design or approach either to provide a greater level of performance or to accommodate some new constraints. Many technical risks are borne out of from the always present requirement to minimize or maximize physical properties of processes, systems, and equipment. Describing technical risk is difficult, because when examined at the lowest level of detail, there are many details to examine and consider. As the design architecture, performance, and other requirements and project constraints become known on a given project, a more detailed list of risks should be prepared based on project-specific information Programmatic Risk. Programmatic risk (performance related) is the risk associated with obtaining and using applicable resources and activities that can affect project direction but that may be outside the project manager s control. Programmatic risks are grouped into categories based on the nature and source of factors that have the potential to disrupt the project s implementation plan, such as: Disruptions caused by decisions made at higher levels of authority directly related to the project Disruptions caused by events or actions affecting the project but not directed specifically at it Disruptions caused primarily by a failure to foresee production-related problems Disruptions caused by imperfect capabilities Disruptions caused primarily by a failure to foresee problems other than those included in the first four categories Supportability Risk. Supportability risk (environment related) is the risk associated with fielding and maintaining systems or processes that are currently being developed or that have been developed and are being deployed. Supportability risk comprises both technical and programmatic aspects. 6

7 2.1.4 Cost and Schedule Risk. Risk of cost and schedule growth is a major concern. This problem is further complicated because performance and design technical problems are sometimes solved by increasing the planned project scope, thereby increasing project cost and/or schedule. Two major risk areas have an effect on cost and growth schedule: (1) Unreasonably low cost or schedule estimates; and (2) A project not carried out efficiently enough to meet reasonable cost or schedule objectives. Final costs and schedules are primarily a function of the skill of the project manager and project team in accommodating unanticipated problems related to technical, programmatic, and supportability risks. An unrealistically low baseline cost or schedule estimate can result from any of four categories (prior to a pricing decision): (1) Inadequate system description; (2) Inadequate historical cost or schedule database; (3) Lack of sound methods relating historical costs and schedules to new project costs; and (4) Incomplete cost or schedule estimates. 2.2 Methods Overview There are a multitude of risk management engagement methods. There is no onesize-fits-all method for project managers or teams to follow for risk assessment. To the point, it is incumbent for the project manager and team to fully understand their risk environment in order to carry out the risk management process Techniques Applied. There are many techniques to consider when managing risk. The below list represents, but is not limited to, the most often employed techniques: Analogy comparisons Cost risk/wbs simulation modeling Decision analysis Estimating relationships Expert interviews Life-cycle cost analysis Network analysis Performance tracking Plan evaluation Project templates Risk factors 7

8 These techniques are not used in stand-alone fashion; rather they are cross-walked against three other key indicators resource requirements, applications, and output. This cross-walk of techniques and key indicators uses markers (e.g., High, Medium, Low and Difficult, Easy, etc. ) much like the Risk Assessment Assignment Matrix in Figure to develop the key indicator. Figure demonstrates: Resource Requirements Applications Output cost Proper facilities and equipment Implementation time Ease of use Time commitment Project status reporting Major planning decisions Contract strategy selection Milestone preparation Design guidance Source selection Budget submittal Accuracy Level of detail utility Figure Key Indicator Communication. 3.0 Application An important part of executing the RMP, identifying the methodologies, and executing the techniques is the role of communication. If ignored, it can render the best risk assessment and analysis ineffective. Properly communicating risk data to decision makers must be clearly defined. Inherent to clear delivery is the understanding that data must be thoroughly documented in order for risk management processes to be effective. Sources of data, assumptions made about the project, the assessment, analysis, and handling techniques used must be consistently documented and communicated in order for the project leader and project team to accomplish goals and objectives. 3.1 Risk Assessment A good risk assessment and management process is essential to the success of any program. RETTEW s 7-step process consists of: Step 1: Planning for Risk Assessment. Planning the activity. A Project Manager may begin this process by selecting the Risk Assessment Team, setting ground rules, and determining supporting tools. The Risk Assessment Team should include representatives from all affected areas of the project. 8

9 3.1.2 Step 2: Identifying Program Objectives or Requirements. Once the Project Manager identifies the Risk Assessment Team and tools, the team should identify the key project objectives and associated requirements. These objectives and requirements will assist the team in identifying risks Step 3: Defining Program Risks. The Project Manager or facilitator leads the team through a structured brainstorming process to identify the program risks. Once all ideas are heard and vetted, an affinity diagram is created to group, merge, and eliminate duplicate risks and to identify dependent risks. Affinity diagrams are used to produce many possible answers to identified risks, e.g., in an open-ended question such as What are some of the ways to reduce cycle time for process A? Figure shows an example of a notional affinity diagram with five identified risk areas: With an affinity diagram, verbal information can be transformed into a visual pattern. Through grouping and association, identified risks may be merged if similar or dependent, and eliminated if the same. Following the identification of risks, the team assigns various attributes to each risk. At a minimum, relevant time frame, impact, and probability of occurrence are assigned. Then the team sets impact definitions. In a standard Risk Matrix, impact definitions are: C (Critical): If the risk event occurs, the project will fail. Minimum acceptable requirements will not be met. 9

10 S (Serious): If the risk event occurs, the project will encounter major cost or schedule increases. Minimum acceptable requirements will be met. Secondary requirements may not be met. Mo (Moderate): If the risk event occurs, the project will encounter moderate cost or schedule increases. Minimum acceptable requirements will be met. Some secondary requirements may not be met. Mi (Minor): If the risk event occurs, the project will encounter small cost or schedule increases. Minimum acceptable requirements will be met. Most secondary requirements will be met. N (Negligible): If the risk event occurs, it will have no effect on the project. All requirements will be met. Probability of occurrence is the team s assessment of the likelihood of a risk happening. In a standard Risk Matrix, it is sufficient to estimate probabilities using a relative scale: 0-10%: very unlikely the risk event will occur 11-40%: unlikely the risk event will occur 41-60%: even likelihood the risk event will occur 61-90%: likely the risk event will occur %: very likely the risk event will occur This approach may be used to translate subjective probability estimates into numbers in the absence of hard data. However, if hard data is available for some risks, the other probability estimates must be chosen to be consistent with the hard data Step 4: Ranking Program Risks. At this point, the team should have all the information needed to rank the risks. If using a Risk Matrix tool, this process is simple and automated. A popular, easy to use ranking method is the Borda Voting Method. For the Borda Count Method, each risk (or risk solution) gets 1 point for each last place vote received, 2 points for each next-to-last point vote, etc., all the way up to N points for each first place vote (where N is the number of risks/solutions). The risk or risk solution with the largest point total wins the election. For instance, in a 4 candidate election, each 4th place vote is worth 1 point, each 3rd place vote is worth 2 points, each 2nd place vote is worth 3 points, and each 1st place vote is worth 4 points. The Borda Count Method, or some variation of it, is often used for things like polls which rank sporting teams or academic institutions. If the team chooses not to use an automated tool, an alternative is to use a multivoting technique such as sticky dots or weighted voting. Multi-voting narrows a large list of possibilities to a smaller list of the top priorities or to a final 10

11 selection. Multi-voting is preferable to straight voting because it allows an item that is favored by all, but not the top choice of any, to rise to the top. A good time to use multi-voting is after a brainstorming session, when a list must be narrowed down, or when a decision must be made by group judgment Step 5: Managing Program Risks. All risks require some form of management, whether it involves a plan for handling risks (action plan) or merely keeping status. After risks are ranked, the team should identify the risks that are high priority, need to be managed, and require resources. Working with the Project Manager, some risks will be eliminated because of changing requirements and others will be transferred out of the organization due to lack of internal resources Step 6: Managing Action Plans. Whenever feasible, usually after a baseline assessment, the project team should develop detailed action plans and enter an initial status, assign primary responsibility, and determine criteria surrounding the risk event. The status of each action plan should be reviewed and assessed periodically as risk rankings are adjusted accordingly Step 7: Continuously Assessing Program Risks. Continuously assessing risks is essential to good program risk management. As a project progresses, risks should be reassessed periodically to determine whether their level of importance has changed or whether new risks have developed that should be identified, assessed, ranked, and managed. 3.2 Risk Response Development Risk response development is a critical element in the risk management process that determines what action (if any) will be taken to address risk issues evaluated in identification and quantification efforts. Generally, response strategies fall into one of the following categories: Avoidance. In many situations, a lower risk choice is available from a range of risk alternatives. Selecting a lower risk option represents a risk avoidance decision. Not all risk should be avoided, however. On occasion, a higher risk can be deemed more appropriate because of design flexibility, enhanced performance, or the capacity for expansion. 11

12 3.2.2 Control. Risk control is the most common of all the risk-handling strategies. It is the process of taking specific courses of action to reduce the probability, reduce the impact, or deflect the risk to another party. This often involves using reviews, risk reduction milestones, development of fallback positions, and other similar management actions. The project manager must develop risk reduction plans and then track activities based upon those plans. Action plans are generally built into the project plan and, ultimately, into the work breakdown structure (WBS). Through risk control, the project manager may emphasize minimizing the probability that the risk will occur or minimizing the impact if the risk does occur. Risk may also be controlled through means of deflection by sharing with other organizations Retention. Risk retention is a decision to accept the consequences if the event occurs. Projects inherently involve retention of some risk. The project manager must determine what level of risk can be safely assumed in each situation as it evolves. 3.3 Risk Response Control After risks are identified and quantified, and clear responses developed, those responses must be put into action. Risk response control is the daily active management of risk. It takes place as the project progresses. Risk response control involves implementing the RMP, which should be part of the project plan. The challenge is dealing with risk events as they occur. Flaws in carefully structured plans become evident when those plans are implemented. Some strategies work very effectively; others prove far less effective. Thus, it often becomes necessary to begin the cycle anew, which involves either reconsidering risk responses or migrating even further back in the process to reevaluate identified risks. 12

13 4.0 References and Foundational Data Attributed to: 4.1 The American Society for Quality 4.2 The MITRE Corporation 4.3 Risk Management, ESI International 4.4 Department of Defense M, Transition from Development to Production Solving the Risk Equation 13