Sei sulla pagina 1di 32

Risk Management Plan: 1

Risk Management Plan: A Proposed Solution William Huckabee OM-8527 Advanced Risk Management September 14, 2009 Capella University

Risk Management Plan: 2


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

Risk Management Plan: 3


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.

Risk Management Plan: 4


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.

Risk Management Plan: 5


Table 1. Recommended Best Practice List of Components of a Risk Management Plan
Component Risk categories Methodology Roles and responsibility Definition A risk breakdown structure (RBS) is used to identify risks in sufficient detail to facilitate determining their causes. Describes the approaches, tools, and data sources that are used to identify, assess, track, and mitigate project risks. 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 Risk plan scope Budgeting and timing activities. Provides the boundaries of the risk management plan and its applicability. Fiscal resource allocations to deal with risks. Timing describes the frequency of risk management activities; establishes the activities to be included in the Definitions of risk probability and impact Probability and impact matrix Risk tracking Tools Report formats project schedule. Defines the probability and impacts of the different levels of risks. Facilitates the identification of risks as being high, medium or low. Identifies the tracking methods in current project and becomes knowledge base for future projects. The tools to be used. 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

Risk Management Plan: 6


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.

Risk Management Plan: 7


Figure 2 Best Practice Risk Management Processes

Adapted from Project Management Institute (2008), pp. 283-310 and Systems Analysis and Design(5 th 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 .

Risk Management Plan: 8


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.

Risk Management Plan: 9


Table 2. Project Roles and Responsibilities. Risk Management Process Steps Quantitative Risk Qualitative Risk Analysis (As Analysis Applicable) R R S S S S R R S S S S

Roles Sponsor Program Manager Project Manager Deputy Project Manager Risk Manager Project Team Risk Owner Cost Account Manager Customer Stakeholder 1 Legend R = Responsible S = Support Role A = Approve C = Concur

Risk Management Planning C C R, A S S S

Risk Identification C C R S S S

Risk Response Planning C C R, A S S S R R

Risk Monitoring and Control

R R S S R R C S

C C

C C

Note: Table adapted from Project risk management handbook: Threats and Opportunities, (2nd ed), (2007), by R. Land, (p. 7)

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

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

OM-8527 William Huckabee

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

OM-8527 William Huckabee

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 A Almost Certain B Likely Probability .08 -.10 Probability Probability over .10 Occurrence Description Very high, could occur several times during the projects lifecycle, and presents a detriment to cost, schedule, or technical aspects of the software lifecycle 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 C Possible Probability .06-.08 software lifecycle 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 D Minor Probability .04-.06 technical aspects of the software lifecycle 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 E Insignificant Probability less than .04 lifecycle 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).

OM-8527 William Huckabee

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 Ratings 5 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 failures 3 Moderate Large impact, can be managed with contingency funds 2 Minor Minor impact, can be manage at cost account level within current mitigation plan 1 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.

OM-8527 William Huckabee

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

OM-8527 William Huckabee

Risk Response: 16
Figure 4. Probability and Impact matrix.

Probability and Impact Matrix Threats


Insignificant Minor Moderate Major Catastrophic Outstanding

Opportunities
Major Moderate Minor Insignificant

A B C D E

M L L L L 1

M M L L L 2

H M M L L 3

H H M M L 4

H H H M M 5 Impact Risk Categories Medium

H H H M M 5

H H M M L 4

H M M L L 3

M M L L L 2

M L L L L 1

Probability

Low

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.

OM-8527 William Huckabee

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.

OM-8527 William Huckabee

Risk Response: 18
Table 5 Risk Response Types and Definitions.
Response Threats Avoidance Transfer Mitigation Acceptance Opportunities Exploit Share Enhance Ignore Definition This choice is taken when all attempts for risk reduction have failed and the risk remains unacceptable. This is transfer (or passing) the risk to a third party. This is the reduction of a risk to an acceptable level. Acceptance of the risk. Ensuring that risk happens. Transferring the risk to a party that is better able to influence the occurrence of the opportunity. Modify the size of the opportunity; maximizing the utility of the opportunity. 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

OM-8527 William Huckabee

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

OM-8527 William Huckabee

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

OM-8527 William Huckabee

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

OM-8527 William Huckabee

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.

OM-8527 William Huckabee

Risk Response: 23
Table 6. Risk Register Description and Content.
Column Heading Risk ID number Risk Register Number Initial impact rating. Response to be implemented. Description and Content The identification number assigned to the risk. Self Explanatory. This is the impact rating the risk item was given in the risk assessment phase. Using the criteria discussed in the Responses for Positive Risks and Responses for Negative Risks sections above to determine the appropriate response, Risk Rating after response is applied. Person responsible for implanting response(s). Time Frame. Date Completed. Risk and response was audited, how and when Date Completed and enter it in this column. This is the estimated risk rating after response is applied. Self explanatory; the risk is assigned ownership. The time frame in the project that the risk will be apparent. Date the risk response was applied How was the risk and response audited to determine if the response applied is working and the date of the audit. The date the risk was closed.

OM-8527 William Huckabee

Risk Response: 24
Figure 5. Risk Register Template Activity/Project: _____________________________________ Completed by: ______________________________________ Reviewed by:
Risk ID Number 016

Division/Unit: Date: Date:


Person responsible for implanting response(s) Huckabee Timeframe

________________________________ ________________________________ ________________________________


Date Completed Risk and response was audited How When Date completed

______________________________________
Initial Impact rating C,3 (Med) Response to be implemented Mitigate; search for alternative sources for servers; prepared request for quote, and Risk Rating after response is applied D,3 (Low)

Risk Register Number 001

Beginning of the hardware procurement phase

8/10/2009

025

002

D, 5 (Med)

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

OM-8527 William Huckabee

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 Risk Number Risk Risk Register Number Likelihood and impact columns Agreed Risk Level Risk Description Current Controls Possible Additional Actions. Response, Effectiveness, and Cost Columns. Comments and Recommendations Sources of Information and List of Attachments Compiler and Reviewer, and dates. Description and Content The number assigned to the risk. The risk title. The corresponding numbers from the risk register. The initial impact assigned to the risk. This can be obtained from the risk register. The risk level after the response is applied. Can be obtained from the risk register. Contains all pertinent data related to the risk, including causes, consequences, and implications. Lists the current controls that have been applied (if any). Describes any additional actions required. This is a good place to describe any secondary issues. Describes the response implemented, its effectiveness, and current cost of the response. Self explanatory. Describe the sources, such as WBS, tables, drawings, manuals, etc., of where data was obtained. Complier (risk owner); Reviewer (project manager) signatures and dates.

OM-8527 William Huckabee

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.

OM-8527 William Huckabee

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.

OM-8527 William Huckabee

Risk Response: 28
Figure 7. Risk Response Communication Matrix Template. Risk Response Communications Type of Purpose of Communication Communication Risk Review Board Update Risk Register; Update Risk Database; Discuss Risk Status; Discuss Risk Audits; Reprioritize Risks as Required; Report New Risks, Analyze and Assign to Owners Risk Audit Update Risk Status

Meeting Owner Project Manager

Target Audience Risk Owners; Team leads; Risk Manager

Meeting Frequency Monthly

Documentation Current Risk Database; Current Risk Register; Risk Response Option Worksheet; Risk Management Plan; Project Management Plan Current Risk Database; Current Risk Register; Current Risk Response Option Worksheet Current Risk Database; Current Risk Register; Risk Response Option Worksheet; Risk Management Plan; Project Management Plan Current Risk Response Option Worksheet; Current Risk Register

Risk Manager

Risk Owners

Weekly

Stakeholder Review

To Discuss New Risks and Obtain Approval of Response Strategy

Project Manager

Stakeholders; Project Team

As Needed

Risk Database

Update Risk Database

Risk Manager

Risk Owners

As Needed

OM-8527 William Huckabee

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.

OM-8527 William Huckabee

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.

OM-8527 William Huckabee

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

OM-8527 William Huckabee

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.

OM-8527 William Huckabee

Potrebbero piacerti anche