• No results found

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


Academic year: 2021

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


Loading.... (view fulltext now)

Full text


RETTEW Associates, Inc.



(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.



Table of Contents



1.2PURPOSE... 3


1.3.1 Risk Analysis Tools ... 4

1.3.2 Aspects of Risk ... 4

1.3.3 Severity of Risk ... 4

Figure 1.3.3 – Risk Assessment Assignment Matrix ... 4

1.3.4 Risk Verification ... 5



2.1.1 Technical Risk ... 6

2.1.2 Programmatic Risk ... 6

2.1.3 Supportability Risk ... 6

2.1.4 Cost and Schedule Risk ... 7


2.2.1 Techniques Applied ... 7

Figure 2.2.1 – Key Indicator... 4

2.2.2 Programmatic Risk ... 8



3.1.1 Step 1: Planning for Risk Assessment ... 8

3.1.2 Step 2: Identifying Program Objectives or Requirements ... 9

3.1.3 Step 3: Defining Program Risks ... 9

Figure 3.1.3 – Affinity Diagram ... 4

3.1.4 Step 4: Ranking Program Risks ... 10

3.1.5 Step 5: Managing Program Risks ... 11

3.1.6 Step 6: Managing Action Plans ... 11

3.1.7 Step 7: Continually Assessing Program Risks ... 11


3.2.1 Avoidance ... 11

3.2.2 Control ... 12

3.2.3 Retention ... 12








RETTEW Associates, Inc., 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.



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.


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.



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.

1.3.2 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

1.3.3 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 1.3.3 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:



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.

1.3.4 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




Approach to Risk Management


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:

2.1.1 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.

2.1.2 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

2.1.3 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.



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.


Methods Overview

There are a multitude of risk management engagement methods. There is no one-size-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.

2.2.1 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



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 1.3.3 to develop the key indicator. Figure 2.2.1 demonstrates:

Figure 2.2.1- Key Indicator

2.2.2 Communication.

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.




Risk Assessment

A good risk assessment and management process is essential to the success of any program. RETTEW’s 7-step process consists of:

3.1.1 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.

Resource Requirements Applications Output

co st P ro p er fa cil it ies a n d eq u ip m en t Im p lem en tatio n ti m e Eas e o f u se Ti m e co m m it m en t P ro jec t sta tu s rep o rti n g M ajo r p lan n in g d ec isio n s Co n trac t stra teg y se lec ti o n M il esto n e p re p ara ti o n De sig n g u id an ce S o u rc e se lec ti o n Bu d g et su b m it tal Ac cu ra cy Lev el o f d etail u ti li ty



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.

3.1.3 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 3.1.3 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.



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

91-100%: 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.

3.1.4 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 multi-voting technique such as ‘sticky dots’ or ‘weighted multi-voting’. Multi-multi-voting narrows a large list of possibilities to a smaller list of the top priorities or to a final



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.

3.1.5 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.

3.1.6 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.

3.1.7 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.


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:

3.2.1 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.



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.

3.2.3 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.


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.




References and Foundational Data Attributed to:


The American Society for Quality


The MITRE Corporation


Risk Management

, ESI International


Department of Defense 4245.7-M,

Transition from Development to

Production – Solving the Risk Equation


Related documents

Keywords: Critical Systems, Formal Model-Based, Model-Driven, Domain Specific Languages, Model Transformation, Model Template, Model Composition, Railway Sys- tems,

All bulk materials for piping systems and structural components shall comply with relevant NORSOK Material Data Sheets. Note that it is the manufacturer's responsibility to confirm

The association between RAI treatment failure and various clinical parameters includ- ing age, sex, height, weight, body mass index (BMI), thyroid gland volume, and isthmus length

Through a process of qualitative case study, pilot questionnaire surveys, workshops and qualitative in-depth interviews, the research has identified how the

 Engineering students CAN incorporate a global experience in their undergraduate career.  There are multiple programs with flexible options to explore with regard to program

Satellite-Derived Bathymetry (SDB), a new method which derives bathymetric data from multi-spectral satellite imagery, has yet to be recognised as a new acquisition method for

Nursing Topics Discussed During Rounds The Society of Critical Care Medicine & Sutter Health (2015) highlight the importance of members of the interprofessional team