risk management plan a proposed solution

7/27/2019 Risk Management Plan A proposed Solution

1/32

Risk Management Plan: 1

Risk Management Plan: A Proposed Solution

William Huckabee

OM-8527

Advanced Risk Management

September 14, 2009

Capella University


2/32


Risk Management Plan: A Proposed Solution

Preface

Project risk management is an important element in all projects. Part of the risk management

process is constructing a risk management plan (RMP) that will help the project manager (PM) to

mitigate the impact of project risks (Halverson, Kautzky, Jenni, and Redus, 1998, p. 8). Further, it could

be suggested that risk management does not always lead to a projects success, however, a plan does

support the PM in achieving his or her primary goal (Heemstra and Kusters, 1996, p. 342), which is the

identification of and response planning for risks early in the project to avoid moving into a crisis

management mode, thus allowing the PM to achieve his or her goals.

Gottwald (2009) suggests that this component of project management can often be the hardest

project management knowledge area to master (p. 1). Therefore, to facilitate easier mastery of this

knowledge area in the current project, the goal of this study is to define and present a model RMP that

project managers can use to meet the projects objectives through the adequate mitigation of risks.

Project Background

This model RMP would be a good tool for use in managing risks that are associated with a

software development project employed in the Defense Industry. The current project efforts consist of the

software design and build activities for an enterprise resource planning (ERP) solution. These activities

include software testing (unit, scenario, integration, and load testing), business process procedure (BPP)

development, and organizational change management activities, which is the source for the development

of user training materials.

Project Interfaces (Risk Categories)

As a starting point, it could be postulated that a risk can come from many sources in a project.

The Project Management Institute (2008) suggests that risk can typically originate in from two sources;

those that are internal to the organization and those external to the organization.

That being said, this project has three internal interfaces, which originate from the organization,

the project, and technical activities; Figure 1 below defines each of these interfaces in further detail. Also,

this project has six external interfaces (see Figure 1). First, there are two interfaces with external

agencies, such as the Office of the Secretary of Defense (OSDEF) and the projects sponsor, the PEO


3/32


Enterprise Information Systems (PEO-EIS). Second, there are two regulatory statutes that govern this

program such as the Clinger-Cohen Act the Joint Capabilities Integration and Development System

(JCIDS) as well as other applicable Army and Department of Defense regulations.

Figure 1.

Project Risk Breakdown Structure.

(Project Management Institute, 2008, p. 280).

According to the Project Management Institute (2008) Figure 1 could be considered to be the risk

breakdown structure (p. 280) (RBS) for the project. The RBS breaks project risks down into categories

and sub-categories (p. 280). The RBS is a pictorial representation of where potential risks in a project

may originate. This tool also helps in the risk identification process to remind participants of the many

sources (p. 280) of risk in a typical project.

Components of a Risk Management Plan

As suggested above, a RMP is needed to help PMs to contain and mitigate risk. These plans, like

many others are composed of many different components that direct and prescribe actions in the event

that some action occurs, much like a disaster recovery plan in the aftermath of a natural disaster, for

example.


4/32


Methodology

With that said, the Project Management Institute (2008) suggests that there are some essential

components that must be included in a RMP. This includes a methodology (p. 279), which explains the

approaches, tools and data sources that are used to identify, assess, track, and mitigate project risks. In

addition to a methodology, the Project Management Institute suggests that other essential components

include (a) roles and responsibilities of the project team and stakeholders, (b) budgeting information, (c)

timing, and (d) risk categories (pp. 279-280), among others. Table 1 describes the best practice

components of this RMP model. Together, these components form the methodology for managing risk in

this project.


5/32


Table 1.

Recommended Best Practice List of Components of a Risk Management Plan

Component Definition

Risk categories A risk breakdown structure (RBS) is used to identify risks in sufficient detail to

facilitate determining their causes.Methodology Describes the approaches, tools, and data sources that are used to identify,

assess, track, and mitigate project risks.Roles and responsibility Identifies the lead, support, and risk management team members associated

with each activity in the plan as well as their responsibilities. This also includes

any roles that project stakeholders may have with regard to risk management

activities.Risk plan scope Provides the boundaries of the risk management plan and its applicability.Budgeting and timing Fiscal resource allocations to deal with risks. Timing describes the frequency

of risk management activities; establishes the activities to be included in the

project schedule.Definitions of risk probability and

impact

Defines the probability and impacts of the different levels of risks.

Probability and impact matrix Facilitates the identification of risks as being high, medium or low.Risk tracking Identifies the tracking methods in current project and becomes knowledge

base for future projects.Tools The tools to be used.Report formats The description of how risks will be documented, analyzed, and

communicated.Note: Data in Table 2 are taken from A guide to the project management body of knowledge (PMBOK Guide). (4 th ed) by project

Management Institute, 2008, pp. 279-282 and GCSS-Army by Northrop Grumman, 2007, pp. 1-15.

Each component of this methodology interacts differently with the other components. For

instance, this methodology provides insight on how the RMP is to be carried out in conjunction with the

objectives of the project or program as a whole. Furthermore, a PM cold look to the methodology to

determine where to go for certain data sources (Project Management Institute, 2008, p. 279) such as

financial information in the funding interface, for example.

Project Risk Management Process

The methodology above aligns with the following risk management processes. Figure 2 below

depicts the best practice application of risk management processes that will be followed in this project.

The figure describes the inputs and outputs of each of the processes for each functional area within the


6/32


risk management process. Additionally, since this project will be used in the software development

industry, it was helpful to overlay the risk management process on the software development lifecycle

(SDLC) (Shelly, Cashman, and Rosenblatt, 2003) for clarity in identifying project risks and reducing

associated project uncertainties.

By overlaying the risk management process on the SDLC it reminds project stakeholders that

risks can come from other areas beside the triple constraints as defined in Project Management Institute

(2008). For example, during the systems planning phase, risks can be identified in the SDLC that PMs

and stakeholders may not be aware of, such as in the software requirements documents, for example.

One example of a risk issue that forms in the SDLC process is associated with the design phase.

For instance, one of the most common risks that is associated with the design phase is in the

transition period between design and implementation (production) phases. Here it is suggested that

designers often fail to design for production (Kerzner, 2006, p. 750), therefore, even if the product is

designed well and does not do well in production, the product will fail (Zerzner). For this reason,

overlaying the SDLC over the risk management processes would seem to be an efficient addition to the

risk management process.


7/32


Figure 2

Best Practice Risk Management Processes

Adapted from Project Management Institute (2008), pp. 283-310 and Systems Analysis and Design(5th ed), (2008), by G. Shelly,

T. Cashman, and H. Rosenblatt, pp. 24-25.

Roles and Responsibilities

Establishing the roles and responsibilities for project members in risk management activities is

important. A list of the roles that team members take in the project provides a point of reference where

project members can look to for guidance. Table 2 below describes the roles and responsibilities for this

project. Also, this component provides clear boundaries for each member of the project team, including

the activities that are associated with each role.

For instance, by using the roles and responsibility matrix, the project sponsor could determine

what his or her role with respect to risk management activities. Also a risk owner could use this roster to

determine his or her role and who to go to when a new risk is identified. In line with this roles and

responsibilities theme, Chapman and Ward (2003) suggest that there is a great deal of uncertainty with

respect to relationships (p. 101) involved in a project.


8/32


It would seem presumable that some stakeholders have a stake in the projects success as well

as the identification, assessment, and mitigation of associated risks. In fact, Chapman and Ward suggest

that stakeholders have some responsibility (p. 101) in the role of risk management; therefore,

stakeholders that have a direct role would be listed in Table 2. This helps to reduce the uncertainties

associated with project relationships. For this project, placeholders have been placed in Table 2 to

account for their roles in risk management.


9/32


Table 2.

Project Roles and Responsibilities.

Roles

Risk Management Process Steps

Risk ManagementPlanning

Risk IdentificationQualitative Risk

Analysis

Quantitative RiskAnalysis (AsApplicable)

Risk ResponsePlanning

Risk Monitoringand Control

Sponsor C C CProgram Manager C C C

Project Manager R, A R R R R, A RDeputy ProjectManager

S S R R S R

Risk Manager S S S S S SProject Team S S S S S SRisk Owner S S R RCost AccountManager

S S R R

Customer C C CStakeholder 1 C C SLegendR = ResponsibleS = Support Role

A = ApproveC = ConcurNote: Table adapted from Project risk management handbook: Threats and Opportunities, (2nded), (2007), by R. Land, (p. 7)


10/32

Risk Response: 10

Scope and Budget

This RMP is applicable to all project team members, team leads, CAMs, Stakeholders, and the

organizational staff members involved directly with the project, and the RMP is valid until the project is

officially closed in 2015, which is the projects scheduled completion date, or when the next years option

has been extended to the contractor. For instance, the project has some unfunded requirements that

have been captured and pushed out to software release version 1.x and if funding is obtained for these

requirements, the contract will be extended beyond 2015.

Additionally, the Project Management Institute (2008) suggests that a contingency fund (p. 304)

is established for and is used to mitigate accepted and unforeseen risks. This project has a sizable

contingency fund. The budgeted amount is $3.2 million for the duration of the project; however, during the

current fiscal year only $500,000 is allocated for risk mitigation (these figures are skewed due to the

confidentiality of program financial details).

Timing

Risk management activities should occur regularly on a predetermined routine basis, with special

events occurring on an adhoc basis. Also, this process allows the PM to monitor the progress and status

of risks at these events. In this model, project level risk update meetings will occur monthly; at the team

lead level, risks will evaluated on a bi-weekly basis. The format for communicating risks will be discussed

later in the communications section of this model.

Risk Analysis and Prioritization

Risks are inherent in every project, but which risks are more important than others? This is one

task that PMs must be proficient in; putting risks into the perspective of the current project. For instance,

JISC infonet (n.d.) suggests that PMs and stakeholders must have a thorough understanding of the

relative priority and absolute significance (para. 1) of each source of project risk that is identified in order

to adequately assign and focus project resources.

OM-8527 William Huckabee


11/32

Risk Response: 11

That being said, there are a number of tools and techniques that can be used by PMs to put risks

into the proper perspective. Further, these tools help PMs to identify and properly order risk for adequate

management. For instance, Kerzner (2006) describes over 20 techniques that range from relatively

complex modeling and simulation that require extensive quantitative analysis to simpler risk mapping

matrices (p. 729), which are based on qualitative analysis, and are quite simple, but effective in risk

prioritization.

Because of the simplicity of risk mapping matrices, PMs can conduct more efficient risk

prioritization processes. In fact, Hillson and Hulett (2004) suggest that prioritization is an important step in

the risk assessment process. Further, mistakes made in the earlier stages of the assessment process

could lead to the loss of confidence in the risk process (p. 85), which could further result in project

failure.

Qualitative and Quantitative Risk Assessment

The evidence above suggests that proper prioritizations of risks is important and must be done

correctly, and begins with risk identification. For example, Chapman and Ward (2003) suggest that the

identification of risks is an iterative process that increases in scope with each pass through the risk

identification process; the focus of which is in the identification of project uncertainty and its affect on the

projects objectives (Hillson and Hulett, 2004, p. 1).

One tool that especially useful in the risk identification process is the cause and effect diagram

(Gottwald, 2009). It is easy to use can even be used during a brainstorming session. Figure 3 below

describes a cause and effect diagram that is used to determine the risk causes associated with a late

deliverable. Examining this diagram, the effect of a late deliverable has four primary causes, such as poor

skills, for example. Each of the four primary causes have secondary causes, such as a poor labor market,

as an example leading to poor skills. This tool has identified several areas were a risk to a deliverable

exists. Other tools include influence diagrams, strengths, weakness, opportunities, and threat analysis

(Gottwald, 2009, pp. 6-7) (SWOT).



12/32

Risk Response: 12

Figure 3

Late Deliverable Cause and Effect Diagram

Next a complete and comprehensive list, usually in a risk register (described later in this model),

is created so that each risk issue can be further analyzed. This is considered to be the third in the step in

the process (Kerzner, 2006). Further, Chapman, Cooper, Debelius, and Pecora (1985) suggest that once

the identification process is complete and a list is created, each risk issue is defined for all reasonable

possibilities associated with the realization of each primary risk (p. 173).

With this thinking in mind, once risks are compiled in the risk register, each risk is addressed in

terms of probability and impact (Hillson and Hulett, 2004, p. 2). Here, probability describes the

likelihood of a risk occurring (p. 1); the impact describes the extent of what would happen if the risk

occurred (p. 1). This suggests that the prioritization process occurs on a two-dimensional spectrum;

probability versus impact (Hillson and Hulett, 2004; Black, 2006).

Probability of Occurrence

In determining the probability of occurrence, Kerzner (2006) suggests that the process should

begin with a strawman approach (p. 731). As such, the risk issues are initially prioritized with differing

definitions. Using this strawman approach, risk issues in this model will initially be rated on a scale

between insignificant in the event of low probability of occurrence to almost certain in the event of high



13/32

Risk Response: 13

probability of occurrence. Table 3 below defines these ratings as well as those ratings that are in between

these two extremes.

Table 3

Occurrence Scale

Occurrence Ratings

Rating Probability Occurrence Description

A Almost

Certain

Probability over .10 Very high, could occur several times during the projects lifecycle, and

presents a detriment to cost, schedule, or technical aspects of the software

lifecycleB Likely Probability .08 -.10 High, may occur once in the design/build phase of the product lifecycle, and

presents a significant impact to cost, schedule, or technical aspects of the

software lifecycleC Possible Probability .06-.08 Possible, could occur in the analyze phase of the software lifecycle but can

be managed with effort using current risk management procedures,

standard procedures, presents a moderate impact to cost, schedule, or

technical aspects of the software lifecycleD Minor Probability .04-.06 Will not occur, but possibly could occur at any time in the projects lifecycle,

in the Impact minor with routine management procedures, presents a

minimum impact to cost, schedule, or technical aspects of the software

lifecycleE Insignificant Probabil ity less than .04 Very low, or very unlikely, minimal impact to cost, schedule, or technical

aspects, and can be handled with routine management procedures.

Note: Data in Table are from a compilation of various sources.

Impact

Differing from probability of occurrence, the impact of a risk on project objectives provides more

relative information to management in terms of the economic impact to the project or firm. For instance,

the impact on project objectives could be a delay in time (schedule), increased resources (cost), or in

product quality (lost sales or poor reliability) (Kerzner, 2006; Cooper, Grey, Raymond, and Walker, 2006;

Chapman and Ward, 2003).



14/32

Risk Response: 14

For instance, Cooper, et al. (2006) suggests that the impacts of risk issues are purely economic

(p. 47). Also, Cooper, et al. suggests that when defining a risk impact, the definition must be clear and

consistent (p. 48) with regard to the consequence of the risks occurrence. This is extremely important in

the event that a cap or limit (p. 48) is placed on a potential risk exposure. Table 4 below lists the impact

scale and definitions to be used in this project. They are rated on a numerical scale from 1 having an

insignificant impact on the projects objectives to 5, having a catastrophic impact on the projects

objectives.

Table 4

Impact Scale

Impact Ratings5 Catastrophic Extreme event, potential for large scope increase resulting in contract negotiations or loss of contract

4 Major Critical event, potential for major costs or delays or possible operational testing failures3 Moderate Large impact, can be managed with contingency funds2 Minor Minor impact, can be manage at cost account level within current mitigation plan1 Insignificant Insignificant impact and can be placed on watch list.Note: Data in Table are from a compilation of various sources.

With Cooper, et al. (2006) suggestions in mind, a review of various RMPs indicated that impact

varies across the industry. For instance, Cooper, et al. (2006) suggests that providing a rating with a

consequence definition such as those described in Table 4. Further, Kerzner (2006) agrees and adds that

well described impact definitions allow less experienced managers and others to view the impact to

project objectives in the same frame of reference.

Finally, what has been described so far is a qualitative risk analysis process. When the processes

above will not provide an adequate measurement of probability and impact of a particular risk, a

quantitative risk analysis should be conducted. According to the Project Management Institute (2008) this

method of analysis is conducted after the risks have been listed in the risk register and it has been

determined that the risks have a potential and substantial (p. 294) impact on the projects objectives.



15/32

Risk Response: 15

Furthermore, the initiation stage of quantitative risk analysis process is conducted in the same

fashion as described above (Project Management Institute, 2008). Also, this process should be repeated

(p. 295) at various points in the projects lifecycle, such as during the monitoring and control process, for

example.

One commonly used method of determining probability and impact is the use of continuous

probability distributions, which is used in conjunction with modeling and simulation (Project Management

Institute, 2008, p. 297). This method provides a view of uncertainty in discrete values (p. 297) in the

form of either beta or triangular distributions (p. 298). A less complex method to use is the decision tree

diagram, or expected monetary value analysis (p. 298).

Also, when considering qualitative versus quantitative risk analysis, one must look to the

advantages and disadvantages of each. For example, the primary advantage of conducting a qualitative

analysis would be to identify areas for immediate improvements in addressing the project vulnerabilities

(Stoneburner, Goguen, and Feringa, 2002, p. 23).

Finally, a qualitative analysis does not provide managers with any specific quantifiable

measurements (Stoneburner, Goguen, and Feringa, 2002, p. 23) like a quantitative analysis. On the

other hand, a quantitative analysis provides measurement data that can be further used in a cost-benefit

analysis (p. 23) that is typically associated with determining the type of risk response to initiate. This

method often requires further quantitative interpretation (p. 23), which can be time consuming and

costly.

Probability and Impact Matrix

The probability and impact matrix assists in determining the responses required for a particular

risk (Project Management Institute, 2008). Figure 4 below describes the probability and impact matrix

used for this project. The matrix is broken down into two zones; one for threats and one for opportunities.

This tool allows the PM to choose the appropriate weight for each type of uncertainty, which will

be discussed in detail later in this model. For now, however, the color coding of the matrix indicates

different scales of risk/opportunities. For instance, red areas indicate a high risk or opportunity that often

needs priority action and aggressive response strategies (Project Management Institute, 2008, p. 292).



16/32

Risk Response: 16

Figure 4.

Probability and Impact matrix.

Probability and Impact Matrix

Threats Opportunities

Insignificant Minor Moderate Major Catastrophic Outstanding Major Moderate Minor Insignificant

Probability

A M M H H H H H H M M B L M M H H H H M M L C L L M M H H M M L L D L L L M M M M L L L E L L L L M M L L L L

1 2 3 4 5 5 4 3 2 1 Impact

Risk Categories Low Medium High

Note: Figure adapted from Project Management Institute (2008)

Risk Response Planning

Risk response planning is a major component of a RMP. For instance, the Project Management

Institute (2008) suggests that risk response planning is the process for PMs to define the options and

actions (p. 301) that should be taken to reduce a threat or enhance an opportunity. However, it could be

suggested that risk responses are typically be biased (Kerzner, 2006, p. 746) towards the PMs

tolerance for risk, among other factors.

What typically leads to this bias is the firms methodology toward project management. For

instance, Kerzner (2006) suggests that if the firms project managements methodology is flexible, such as

being based on guidelines (p. 747) versus rigid policies and procedures (p. 747), the PMs tolerance to

risk is higher and affects the responses developed for a particular risk. Therefore, this evidence suggests

that a risk response strategy must be based on a commonsense, structured, and proactive (Hillson,

2001, p. 2) approach that reduces the firms level of risk exposure (p. 2) allowing for a suitable, bias

free, response strategy for each targeted risk event.



17/32

Risk Response: 17

That being said, a literature review of different risk management plans from industry suggests that

there are no established methodologies to be included in a risk response plan. As an example, the Project

Management Institute (2008) describes only inputs, tools and techniques, and outputs (p. 301).

Therefore, it would be a best practice scenario to include the Project Management Institutes

recommended methodology and expand on it for establishing a standard to use with this project.

Types of Risk and Uncertainty

Uncertainty is typically associated with both variability and ambiguity (Chapman and Ward,

2003, p. 7), which can be further described as a lack of clarity in all aspects of the project and in all

phases of the projects life cycle. Hillson (2001) adds that uncertainty has two components; risk (p. 1),

which is associated with a threat and has a negative tone and effect, and opportunity (p. 1), which is

associated with a positive tone and effect on the projects objectives.

Also, Hillson (2001) suggests that there are really two sides of a risk; the negative side, which is

indicative of a threat and the positive side, which is indicative of an opportunity. While uncertainty and risk

as described above seem to be looked at in the same fashion, Chapman and Ward (2003) suggest that

there are wider implications for uncertainty over risk. For example, the understanding and interpretation of

uncertainty with respect to where and why (Chapman and Ward, 2006, p. 6) uncertainty exists is key

component in risk management activities and may have important implications with regard to responding

to uncertainty. This suggests that the where and why affects the responses assigned to a particular risk

and this often involves tradeoffs between scope, costs, and schedule (Cooper, et, al., 2006, p. 74).

Types of Risk Responses

There are typically four responses that a PM can take with regard to a risk event (Hilson, 2001;

Project Management Institute, 2008; Kerzner, 2006, among others). Further, Hillson suggests that these

responses (see Table 5) can be used for both negative and positive risk events, with only slight

modifications to terminology and definitions in the risk assessment phases. As an example, acceptance

can be associated with both risks and opportunities (Project Management Institute, 2008), while some

authors use ignore (Hillson, 2001, p. 4) versus acceptance when responding to opportunities. These are

described in more detail in the next section.



18/32

Risk Response: 18

Table 5

Risk Response Types and Definitions.

Response DefinitionThreatsAvoidance This choice is taken when all attempts for risk reduction

have failed and the risk remains unacceptable.Transfer This is transfer (or passing) the risk to a third party.Mitigation This is the reduction of a risk to an acceptable level.Acceptance Acceptance of the risk.OpportunitiesExploit Ensuring that risk happens.Share Transferring the risk to a party that is better able to

influence the occurrence of the opportunity.Enhance Modify the size of the opportunity; maximizing the utility

of the opportunity.Ignore Hoping to get lucky.

Note: Data in Rows 3-6 are from Risk response planning: Selecting the right strategy, (2002). C. Piney, pp. 3-4. Data in rows 8-11

are from Effective strategies for exploiting opportunities, (2001), by D. Hillson, pp. 3-4.

Responses for Negative Risks

Negative responses are associated with threats or risks that can negatively affect a projects

objectives (Project Management Institute, 2008). As suggested in Table 5 above, negative responses

include avoidance, transfer, mitigation, and avoidance, and are described below.

Avoidance

Avoidance can be considered to be a type of risk reduction (Cooper, et, al., p. 76) (mitigation or

control) tasks. Additionally, avoidance requires that the project management plan to be changed to

entirely eliminate the threat (Project Management Institute, 2008, p. 303), often at little or no costs

(Piney, 2002, p. 3). Actions that can be used to remove the risk include extending the projects schedule,

changing the projects strategy, or by reducing the scope of the activity where the risk had been identified.

Further, Piney (2002) suggests that cancelling a project is a mandatory (p. 3) action if the risk

reduction actions still allow the risk to be unacceptable (p. 3). Finally, the Project Management Institute

(2008) suggests that shutting down a project (p. 303) is a worst case action.

Transfer

Transferring a risk does not eliminate the risk (project Management Institute, 2008, p. 303); it

only transfers the accountability and management to another party, and often requires the firm to pay a

risk premium (Piney, 2002, p. 4). Piney suggests further that transferring a risk affects a project in



19/32

Risk Response: 19

different ways. For instance, when a best case scenario is transferred to a third party, it makes the

scenario less good (p. 4) and makes the worst case look less bad (p. 4).

Further, the financial rewards are typically lower when risk is transferred to a third party,

therefore, transfer should only be used in a worst case scenario (p. 4). Additionally, some of the tools

used to transfer a risk can be insurance policies, performance bonds, warrantees, and guarantees

(Project Management Institute, 2008, p. 303), which is where the risk premium originates. Finally, this

strategy is best employed very early in the project such as during the requirements analysis phase, for

example, when it is determined that the firm does not have the capabilities, expertise, or resources to

handle the risk.

Mitigate

Mitigation, or in some cases, control (Kerzner, 2006) are actions taken by a PM to reduce the

implications of probability or impact of risk,not the source of risk. This can sometimes lead to the complete

elimination (Piney, 2002, p. 4) of a risk if employed properly. Early action works best in this case.

However, employing this strategy has cost implications, which should be balanced among the response

approaches, such as those as suggested above, and the cost effectiveness and the projects schedule

(Kerzner, 2006, p. 744).

Sometimes however, the probability of occurrence cannot be reduced, therefore, mitigation works

to reduce the impact (p. 304) when the risk does occur. Here the Project Management Institute (2008)

suggests that a prototype development (p. 304) can be used in the reduction of risk in a complex

program. Some additional methods that can be employed with this strategy include design of

experiments (Kerzner, p. 744) incremental development (p. 744), which is the methodology being used

in the authors project. This strategy is best employed in circumstances where high to medium risks

(Kerzner, 2006, p. 744) can be replaced with a lower-risk solution (p. 744).



20/32

Risk Response: 20

Accept

This strategy, sometimes called assumption (Kerzner, 2006, p. 743) is used when none of the

strategies suggested above work in reducing or eliminating a risk. Therefore, the PM will be required to

accept the risk. This takes a concerted conscious decision by the PM, however (Kerzner). Further, there

are two strategies to be used here; passive and active acceptance, which can be associated with merely

documenting (Project Management Institute, 2008, p. 304) a risk, or developing a workaround (Land,

2007, p.18) such as drafting a recovery plan (p. 18) or developing a contingency reserve (Project

Management Institute, p. 304) with the latter, which includes time, money, and resources (p. 304).

Also, the difference between a workaround and a contingency plan is that the contingency plan is

for risks that are very likely to occur (p. 18). A contingency plan would be best employed in a situation

where the risk is highly likely but has a low impact (Kerzner, 2006). This strategy is best employed with

risk having a medium to low probability with a low impact.

Responses for Positive Risks

When considering opportunities, positive deviations (Cooper, et al., 2006, p. 125) in the project

metrics help PMs identify potential opportunities that should be exploited (p. 125), which if recognized

and acted on early enough can provide the project with potentially large benefits (Cooper, et al.). Further,

the exploitation of opportunities requires different thought processes (Cooper, et al., 2006, p. 126).

Additionally, a literature review revealed relatively few RMPs that give attention to positive

opportunities. For example, Caltrans (Land, 2007) was one exception. This firms RMP indicated that the

PM is actively looking for opportunities to exploit, share, enhance, and accept the positive effects of

uncertainty. Furthermore, the Project Management Institute (2008) suggests that accept (acceptance) can

be used for both types of uncertainty; threats and opportunities, and is it seems that Land (2007) followed

this lead. That being said, this area of responses, like the negative responses above contains four key

categories (see Table 5). These categories include exploit, share, enhance, and ignore (accept).

Exploit

Exploitation of an opportunity ensures that the targeted event occurs. For instance, Hillson (2001)

suggests that this is the most aggressive type of action and should only be used for golden opportunities

(p. 3) that would have a high positive impact (p. 3) on the projects objectives. The goal according to



21/32

Risk Response: 21

Hillson is to raise the probability of occurrence to 100% (p. 3) thus making the targeted event

unavoidable. Furthermore, strategies here could include using the firms best qualified talent, which

reduces a tasks time to completion at the lowest cost possible (Project Management Institute, 2008).

Cooper, et al. (2006) agrees and adds that this strategy is best employed for those extreme

opportunities (p. 130); those with the highest impact on the projects objectives.

Share

Sharing is much like transferring as discussed earlier. The exception here is that the PM should

transfer the targeted event to a third party who is best able to maximize the probability of occurrence

(Hillson, 2001, p. 4) for the purpose of taking advantage (Project Management Institute, 2008, p. 304) of

the opportunity and benefiting the project. This strategy has a cost in the form of lost financial gains

because this strategy is used in conjunction with joint ventures, incentive contracts, and the like (Copper,

et al., 2006). This strategy would be best employed in a situation where the expertise did not exist in the

firm to exploit and maximize an opportunity.

Enhance

This strategy is targeted at those opportunities that cannot be exploited or shared (Hillson,

2001, p. 4). The trick here is to increase the probability (Project Management, 2008, p. 305) of the

targeted opportunity or to increase its positive impact (p. 305) of the target. Hillson suggests that the

goal here is to strengthen the occurrence of the opportunity by reinforcing the trigger conditions (p. 4).

This strategy would be used best in a situation where a high to medium opportunity exists and the impact

on the projects objectives is moderate.

Ignore

Much like acceptance as described above, this strategy is the last in the line to be used when all

other responses have failed in achieving the opportunity. For example, the Project Management Institute

(2008) suggests that accepting, or in this case, ignoring an opportunity, indicates a willingness to take

advantage (p. 305), and not actively pursuing it (p. 305). This strategy often involves a bit of luck

(Hillson, 2001).



22/32

Risk Response: 22

Risk Communication Strategy

Before moving on to the next process in the risk management plan, attention needs to be given to

the communication strategy used in the risk management process. For instance, communication is an

important component of any activity, whether it is personal or business related. Further, a good

communications strategy facilitates the next process in a typical RMP. Therefore, a communication

strategy must be developed to assist the PM in the monitor and control processes. A communications

strategy ensures that the projects stakeholders and team members are able to react to risks in the same

way.

In many instances, a simple communication tool will enhance the communication capabilities of

any team. However, it has been suggested by some authors (Cooper, et al., 2006; Project Management

Institute, 2008) that a risk response communication strategy begin with a risk register, which is created in

earlier project during project planning work as well as other forms that facilitate response

communications.

A risk register provides input into the risk response planning processes because it lists current

risks, their root causes, and potential responses (Project Management Institute, 2008, p. 302), among

others. Figure 5 below provides a risk register template for use in the risk response strategy. The top

portion of the template is self explanatory, and requires no formal directions. The other components of the

template are described in Table 6 below. This table is provided as a set of instructions for the templates

use.



23/32

Risk Response: 23

Table 6.

Risk Register Description and Content.

Column Heading Description and ContentRisk ID number The identification number assigned to the risk.Risk Register Number Self Explanatory.Initial impact rating. This is the impact rating the risk item was given in the

risk assessment phase.Response to be implemented. Using the criteria discussed in the Responses for

Positive Risks and Responses for Negative Risks

sections above to determine the appropriate response,

and enter it in this column.Risk Rating after response is applied. This is the estimated risk rating after response is applied.Person responsible for implanting response(s). Self explanatory; the risk is assigned ownership.Time Frame. The time frame in the project that the risk will be

apparent.Date Completed. Date the risk response was appliedRisk and response was audited, how and when How was the risk and response audited to determine if

the response applied is working and the date of the audit.Date Completed The date the risk was closed.



24/32

Risk Response:

Figure 5.

Risk Register Template

Activity/Project: _____________________________________ Division/Unit: ________________________________

Completed by: ______________________________________ Date: ________________________________

Reviewed by: ______________________________________ Date: ________________________________

Risk ID

Number

Risk

RegisterNumber

Initial

Impactrating

Response to be

implemented

Risk Rating after

response isapplied

Person responsible for

implantingresponse(s)

Timeframe Date

Completed

Risk and response was

audited

Date

compleHow When

016 001 C,3 (Med) Mitigate; search for

alternative sources

for servers; prepared

request for quote, and

proposal.

D,3 (Low) Huckabee Beginning of

the hardware

procurement

phase

8/10/2009

025 002 D, 5 (Med) Exploit; evaluate

COTS ERP software

choices; use the

vendor that requires

the least custom

coding

A, 5 (High) Joan Before

beginning of

the software

development

phase.

Note: Table was adapted from Risk management framework, (2005), by R. Barnes, p. 16. Retrieved August 10, 2009 from

http://www.det.act.gov.au/__data/assets/word_doc/0011/19487/Oseas_Excurs_Att8C_RiskManagementFramework.doc



25/32

Risk Response: 25

The next tool to be used in the communications area is the risk response options worksheet. This

worksheet (Figure 6) is used to capture and update the responses to the identified risk events that are

being monitored through the risk management process (Cooper, et al., 2006). Table 7 below describes

the worksheets content and serves as a set of instructions for completing the worksheet.

Table 7.

Risk Response Options Worksheet Instructions.

Column Heading Description and ContentRisk Number The number assigned to the risk.Risk The risk title.Risk Register Number The corresponding numbers from the risk register.Likelihood and impact columns The initial impact assigned to the risk. This can be

obtained from the risk register.Agreed Risk Level The risk level after the response is applied. Can be

obtained from the risk register.Risk Description Contains all pertinent data related to the risk, including

causes, consequences, and implications.Current Controls Lists the current controls that have been applied (if any).Possible Additional Actions. Describes any additional actions required. This is a good

place to describe any secondary issues.Response, Effectiveness, and Cost Columns. Describes the response implemented, its effectiveness,

and current cost of the response.Comments and Recommendations Self explanatory.Sources of Information and List of Attachments Describe the sources, such as WBS, tables, drawings,

manuals, etc., of where data was obtained.Compiler and Reviewer, and dates. Complier (risk owner); Reviewer (project manager)

signatures and dates.



26/32

Risk Response: 26

Figure 6.

Risk Response Option Worksheet.

Risk ID Number: Risk: Risk Register Number:

Likelihood: Impact: Agreed Risk Level:

Risk description (Causes, Consequences, implications):

Current Controls and plans:

Possible Additional Actions:

Response Effectiveness Costs

Comments and Recommendations:

Sources of Information and the List of Attachments.

Compiler: Date: Reviewer: Date:

Note: table is adapted from Project risk management guidelines: Managing risks in large projects and complex procurements,

(2005), by D. Cooper, Grey, S., Raymond, G., & Walker, P., p. 83.



27/32

Risk Response: 27

The final communication tool to be used as part of the communication strategy is the risk

response communication matrix. This matrix (Figure 7) is used to describe the communication

events and activities that the project team must adhere to for proper response management and

control. Further, the communications matrix provides a description of the type and purpose of

communications, the owner of the sessions, as well as the frequency of the events and the

documentation required for the meetings. This matrix is self explanatory, therefore, needs no

formal instructions for its use.



28/32

Risk Response: 28

Figure 7.

Risk Response Communication Matrix Template.

Risk Response Communications

Type ofCommunication

Purpose of Communication Meeting Owner Target Audience Meeting Frequency Documentation

Risk Review Board Update Risk Register;Update Risk Database;Discuss Risk Status;

Discuss Risk Audits;Reprioritize Risks asRequired;Report New Risks, Analyzeand Assign to Owners

Project Manager Risk Owners; Teamleads;Risk Manager

Monthly Current Risk Database;Current Risk Register;Risk Response Option

Worksheet;Risk Management Plan;Project Management Plan

Risk Audit Update Risk Status Risk Manager Risk Owners Weekly Current Risk Database;Current Risk Register;Current Risk ResponseOption Worksheet

Stakeholder Review To Discuss New Risks andObtain Approval ofResponse Strategy

Project Manager Stakeholders;Project Team

As Needed Current Risk Database;Current Risk Register;Risk Response OptionWorksheet;Risk Management Plan;Project Management Plan

Risk Database Update Risk Database Risk Manager Risk Owners As Needed Current Risk ResponseOption Worksheet;

Current Risk Register



29/32

Risk Response: 29

Monitoring and Controlling

The last process in risk management activities is monitoring and controlling risks. This is where

all activities are documented for evaluating and correcting identified risks. This process also provides a

baseline for future projects as it is in this process that organizational assets, such as a risk database, as

well as other project documentation are updated as an output activity.

That being said, this is an eyes-on process where a PM makes risk decisions through evaluating

work and project performance information. These decisions can range from applying corrective actions,

such as contingency funds, to correct a problem, or retire a risk in the event that it is no longer valid. This

process can also involve choosing alternative responses (Land, 2007, p. 19) in the event that a

particular response is not working to control a risk event.

It is presumable that during the activities of monitoring and controlling, that as risks are modified,

secondary and residual risks can be added to the risk register. In fact, the Project Management Institute

(2008) suggests that this process often results in the identification of new risks (p. 310) as wells as the

modification of risks, including retiring old risks.

For this process to be effective and efficient, risks should be regularly assessed. For example,

earlier in this model, it was suggested that project level risk meetings should occur monthly and lower

level risk assessments should occur bi-weekly. This frequency should give project risks the appropriate

visibility to ensure that this process is successful, however, other projects, depending on their size and

complexity could meet less or more frequently. In fact, the Project Management Institute (2008) indicates

that the amount and detail of repetition depends largely on the projects progress toward meeting the

stated objectives (p. 310). However, Kernzer (2006) warns that risk meetings as well as other types of

project meeting should be held only when the team benefits (p. 238) from the meetings.

Further, it is worth noting that there are tools that can make this process easy and accurate. For

instance, the Project Management Institute (2008) suggests that earned value analysis, status meetings,

and risk audits (pp. 310-311) are some of the more common tools used in this process. As and example,

earned value analysis allows PMs to compare current project progress against the planned progress,

which then facilitates the employment of proper and appropriate corrective actions when required.



30/32

Risk Response: 30

Risk Management Tools

As noted throughout this model, there are various tools that are employed to ensure that the risk

management process is effective. These tools range from communication forms, which are submitted to

the appropriate manager or stakeholders, when prescribed in the RMP communication matrix. Further,

the probability and impact matrix provides a method of communicating the probability and impact of a risk

in the same method to each member of the project team, regardless of experience, as well as members

of the firms leadership and other stakeholders.

The roles and responsibility matrix facilitates the identification of assigned roles to each member

of the project team to include the customer and the project sponsor, among others. The forms described

in this model provide a method by which team members can communicate risk activities to all team

members.

Also, the risk management communication strategy forms the baseline for all members to look to

determine which communication actions are due, when and where meeting occurs, what documentation

products are required, and who is required to attend. Raz and Michael (2001) suggest that many of these

tools can often have the greatest impact (p. 16) on a projects success. In fact, many of the tools

described in this model are described in Raz and Michaels list, which are associated with better

performing project management practices and good risk management activities (p.16). Finally, the risk

assessment tools described in this model are the top three tools used by successful projects (Raz and

Michael).

Lessons learned would be considered a tool, at least from the authors point of view as this is a

process of learning from past experience, which is then applied to current and future projects. This tends

to enhance the project management capabilities of a firm (Project Management Institute, 2008). Kerzner

(2006) suggests that experience is often the best teacher (p. 750) and applying lessons learned teaches

PMs to overcome past mistakes. This facilitates improvements of stated best business practices and the

formation of a competitive advantage in project management firms. For instance, Kerzner suggests that

the entire firm will benefit (p. 369) from lessons learned. One last note with regard to lessons learned;

the project sponsor, prject manager, and the entire project team are responsible for capturing and

applying lessons learned in a project.



31/32

Risk Response: 31

Conclusion

Risk management is an important aspect of project management. This is because if risks are not

managed properly and accurately, the projects sponsor will not realize the benefits of the project. A RMP

provides a PM, project sponsor, and team members with a structured, common sense method by which

risk are identified, assessed, and mitigated. This facilitates the removal of much of the uncertainties

associated with a project. For instance, Kerzner (2006) suggests that a RMP allows the project teams to

recognize project risks elements allowing the team to turn traps into advantages (p. 750).

Monitoring and controlling is the facilitating part of the risk management process. Sure,

identification, assessment, and communication are important, but monitoring and controlling is the eyes-

on process that determines where the project is against the plan. For example, during this process, the

earned value management system (EVMS) can be used to accurately display the projects status,

facilitate early identification of trends and problems, and is the basis of problem correction, with an

emphasis on prevention (Kerzner, 2006, p. 614).

Finally, lessons learned should be applied by all project team members throughout the entire

project and particularly at the projects closure (Kernzer, 2006, p. 750). From the authors perspective,

applying lessons learned in a project setting is just as important for the success of a project. For instance,

as Soldier, the author continually applied lessons learned in combat operations. When applied in combat

operations, the survival of the combat team is enhanced, enabling it to better perform in the field in

achieving the organizational mission; the same could be said for a project.



32/32

Risk Response: 32

References

Chapman, C., & Ward, S. (2003). Project risk management: Processes, techniques and insights. (2nd ed.).

New Jersey: John Wiley & Sons, Inc.

Cooper, D., Grey, S., Raymond, G., & Walker, P. (2005). Project risk management guidelines: Managing

risk in large projects and complex procedures. United States: John Wiley and Sons, Ltd.

Halverson, T. G., Kautzky, J. D., Jenni, K., & Redus, K. (1998). Overview of the Hanford risk

management plan. U.S. Department of Energy. Retrieved July 30, 2009 from

http://www.osti.gov/energycitations/servlets/purl/10149043-TLnQX8/webviewable/10149043.pdf

Heemstra, F. J., & Kusters, R. J., (1996). Dealing with risk, and practical approach. Journal of Information

Technology, 11, 333-346.

Project Management Institute. (2008).A guide to the project management body of knowledge: (PMBOK

Guide) (4th ed.). Newton Square: Project Management Institute, Inc

Hillson, D. (2001). Effective strategies for exploiting opportunities. Paper presented at the Proceedings of

the Project Management Institute Annual Seminars & Symposium.

Kerzner, H. (2006). Project management: A systems approach to planning, scheduling, and controlling.

(9th ed.). New Jersey: John Wiley & Sons, Inc.

Land, R., D. (2007). Project risk management handbook: Threats and opportunities. Retrieved August 10,

2009. from

http://www.dot.ca.gov/hq/projmgmt/documents/prmhb/caltrans_project_risk_management_handb

ook_20070502.pdf.

Piney, C. (2002). Risk response planning: Selecting the right strategy. Paper presented at the Fifth

European Project Management Conference, PMI Europe 2002.

Project Management Institute, I. (2008).A guide to the project management body of knowledge: (PMBOK

Guide) (4th ed.). Newton Square: Project Management Institute, Inc.

Raz, T., & Michael, E. (2001). Use and benefits of tools for project risk management. International Journal

of Project Management, 19, 9-17.

Shelly, G. B., Cashman, T.J., & Rosenblatt, H.J. (2003). Systems analysis and design. (5th ed). Boston:

Thomson.

risk management plan a proposed solution

Documents