For enghanyez

5 Project Risk Management

adrian825/iStock/Thinkstock

Learning Objectives

By the end of this chapter, you will be able to:

• Define and describe project risk.

• Understand the risk management process.

• Discuss the risk identification process.

• Explain the risk analysis process.

• Describe the risk response process.

• Explain the role of risk monitoring and control.

CO_CRD

CN

CT

CO_LO

CO_TX

CO_BL

co-cn

co-cr

co-box

co-intro

co-photo

co

bar81677_05_c05_149-172.indd 149 9/9/14 10:49 AM

Introduction

Pretest

1. Brainstorming is a good initial approach for identifying risks to a project. a. True b. False

2. The risk management process is a three-step process. a. True b. False

3. When risks are identified later in the project process, the cost to address these issues will increase. a. True b. False

4. A risk that has a high probability of occurring might have little impact on a project. a. True b. False

5. A project manager who has not created a documented risk response plan has not considered risks fully enough. a. True b. False

6. An output of risk monitoring and control includes updating the risk database. a. True b. False

Answers can be found at the end of the chapter.

Introduction Have you ever visited a public park facility and seen an observation tower with a sign reading “Climb at your own risk?” That is a good example of risk, the chance that something could go wrong. The park is not only warning you about the risks of climbing the tower, but also saying that it is not liable should something happen during the climb. In other words, the park is not willing to share in the risk—it is all yours. In project management there are similar risks that something will go wrong. The best way to handle anticipated risks is to document and analyze them beforehand and decide what to do about them should they occur.

Good managers look for risks throughout the project cycle, know what the risks are before they occur, and work to communicate, prevent, and offset them in their daily decisions and routines. For instance, if the project manager is aware that a supplier of a key product component might not keep an adequate inventory of that component on hand and could potentially delay the project when it is due, the manager may adjust the relevant supply contract to include a penalty clause for late delivery or make other changes in the way the supplier’s inventory is handled.

The principle is that project managers should be able to identify what might happen, what the probabilities are that a risk event might occur, what the impacts will be, and how to prevent or mitigate risks. This principle assumes that failure can be attributed to key events or circumstances.

H1

sec_n sec_t

bar81677_05_c05_149-172.indd 150 9/9/14 10:49 AM

Section 5.1 The Risk Problem

Risk management is the process of recognizing risks and dealing with them in a project. This means that risks are identified, analyzed, tracked, and controlled through proactive project actions. The primary function of risk management is to prevent risks; but if they occur, the risk management plan includes actions to mitigate the risk—in other words, to take correc- tive actions to control its impacts.

5.1 The Risk Problem The root causes of risk and project failure are rarely a mystery—they often have to do with business or project performance, competition, social and economic conditions, technology developments, and lack of top management support.

Project managers and teams face risks in both process and product. Process risks have to do with the project cycle and all the risks in managing the work. Product risks have to do with the performance of the product and the risks associated with failure of the product to meet customer requirements.

What Is Risk?

Risk is uncertainty about the future and what things can go wrong. In a way most projects are risky by definition or they would not be important. Projects take on risks that customers decide they do not want to take on themselves.

For instance, if a customer needs a new information system to handle future demand but does not have the in-house capacity to develop the system without major risk of failure, that customer will often outsource the project and pay a contractor to take on those risks. Thus, outsourcing becomes a way of lessening the risk because an expert contractor will be in a bet- ter position to anticipate and handle risks.

Possible Risks

There are a number of different kinds of project risks that can occur:

• Internal. Internal risk is organizational and system related, which poses challenges to the company itself to support successful project management.

• Technical. Technical and technology risk can be managed using reliability and test- ing methods, which must be built into the project itself. Technical risk is handled by embedding testing in the design and development of the product.

• Nontechnical. Nontechnical risks are personnel, organizational, and process risks that the project manager faces. Some would say nontechnical risks are the most common because they stem from individual and workforce performance or from problems in trying to change social behavior (Hanson & Lynch, 2013). For instance, if a project staff member is assigned a task that is not feasible because of the lack of required equipment, the staff member may try unsuccessfully to complete the task without the equipment because it is not in the budget.

bar81677_05_c05_149-172.indd 151 9/9/14 10:49 AM

Section 5.1 The Risk Problem

• External. External risk is generated by the environment and the market and can be anticipated through environmental scanning, or the process of looking out in the world for factors that will impact the success of a given project, such as economic demand, technology, demographics, and strategic planning.

• Predictable. Predictable uncertainty becomes risk because it can be anticipated, dimensioned, and mitigated. For instance, weather is typically predictable and can be incorporated in project planning if necessary.

• Unpredictable. Unpredictable risk is uncertainty that cannot be anticipated or man- aged. For instance, changes in demand for a given product are unpredictable because of the impact of competition and market, economic, and social factors.

• Legal. Legal risk is the probability that a project will generate legal action focused on the deliverable or proprietary information.

Sometimes risks are not initially apparent in a project because the project team is unable to predict how some risk factors might change a process or outcome. But because there is always a chance of failure in a project, it pays to find ways to identify risks and plan to prevent or control them. If a project manager ignores risks, the project could fail simply because the team cannot adjust to an unanticipated risk.

Sources of Project Risk

There are many sources or causes of risk. Many risks can be identified and prevented through good planning and by following prescribed activities in the project cycle. A good approach to initial risk identification is to ask top management and the project team to think through, or brainstorm, what can go wrong in a given project and what ought to be done about it if it happens. That process can be done in a meeting or through electronic communication tools.

Poorly Defined Scope Projects can go beyond their original scope and create risks of failure. Since there is no indus- try standard on what is involved in a scope of work, the quality of the scope is typically mea- sured against the number of changes or the scope creep the project experiences. Risks and cost and schedule impacts are widespread in most project areas, particularly in software and system development (Kerzner, 2014).

The scope of work statement should include all the work necessary to complete the project and meet customer requirements. If the work goes beyond the scope and incurs unantici- pated costs and time (scope creep), the project could overrun its budget, miss its deadlines, and fail to satisfy the customer.

Unrealistic Timeline and Cost Estimates Bad estimates of the duration of a project create a major risk. The natural tendency is to be overly optimistic in estimating schedule durations and costs; thus, the risk is that the schedule is not feasible and the project budget inadequate to support the job. This is why estimating is

bar81677_05_c05_149-172.indd 152 9/9/14 10:49 AM

Section 5.2 The Project Risk Management Process

so important in project management. Since there will always be the tendency to promise too much in a project proposal, a risk analysis helps bring some reality to the estimating process.

Changing Customer Expectations There is always the risk that, as a project nears completion, a customer will have different expectations for it. This is a risk that can lead to project failure simply because the customer’s views change over time. This major source of risk can be addressed by constant communica- tion with the customer, but even good communication cannot always overcome the custom- er’s changing views of the project as it progresses.

Project Team Performance There is always a risk that the project team will not perform as anticipated because of team collaboration issues or because of individual performance problems. This risk is prevalent because even the best project managers cannot always predict how individual team members are going to handle their task assignments or how the team will work together.

Unanticipated Outside Factors Many outside factors can create project risks. For instance, the market demand for a given project deliverable or product can change during the course of the project. New sources of competition can appear unexpectedly. New technologies can be developed that negatively impact the success of project deliverables.

In sum, there are many potential sources of risks. However, experienced project managers can sometimes predict certain risks simply because these have impacted previous projects; the kinds of risks that might occur could be related to the nature of a given project. For instance, in an IT project, there is likely to be a risk associated with integrating a new system into the customer’s other systems. In a construction project, it is a likely risk that low-quality materi- als will affect the project.

Now that we know various sources of risk, we can discuss the project risk management pro- cess that is designed to anticipate and address risks before they hurt the project.

5.2 The Project Risk Management Process The Project Management Institute is a good source on project risk management (Project Management Institute, 2013). Risk management is described as a process of identifying and assessing risks in a project, then preparing to prevent or control them. The concept aims to maximize the probability and consequences of positive events and to minimize the probabil- ity and consequences of adverse events.

bar81677_05_c05_149-172.indd 153 9/9/14 10:49 AM

Risk identification

Qualitative analysis

Quantitative analysis

Response planning

Monitoring and control

Section 5.2 The Project Risk Management Process

There are six steps that make up the process of risk management: risk management planning, risk identification, qualitative risk analysis, quantitative risk analysis, risk response planning, and risk monitoring and control. Figure 5.1 shows these steps in sequence.

The following is a brief description of each step, each of which will be discussed in more detail later.

Step 1: Risk management planning—deciding how to approach and plan the risk management activities for a project

Step 2: Risk identification—determining which risks might affect the project and documenting their characteristics

Step 3: Qualitative risk analysis—performing a quali- tative analysis of risks and conditions to prioritize their effects on project objectives

Step 4: Quantitative risk analysis—measuring the probability and consequences of risks and estimat- ing their implications for project objectives

Step 5: Risk response planning—developing proce- dures and techniques to enhance opportunities and reduce threats to the project’s objectives

Step 6: Risk monitoring and control—monitoring residual risks, identifying new risks, and executing risk reduction plans and evaluating their effectiveness throughout the project life cycle

Each step produces an output of some kind, usually a document containing relevant information about project risks. Perhaps the most important output of each step is that the project team becomes more aware of the things that can go wrong and thinks through ways to prevent or control them as part of their task assignment.

Table 5.1 shows the outputs, or the information and documentation produced, in each step of the risk management process.

Figure 5.1: Risk management

planning process

This figure shows an “idealized” risk management planning process. It begins with risk identification, then moves to analysis (both qualitative and quantitative), then continues with response, and ends with monitoring. In fact, the monitoring step actually is a continuing process that goes on throughout all the other steps to make sure the project is on track and moves from one step to another successfully.

Risk identification

Qualitative analysis

Quantitative analysis

Response planning

Monitoring and control

bar81677_05_c05_149-172.indd 154 9/9/14 10:49 AM

Section 5.3 Risk Identification

Table 5.1: Risk management outputs

Risk manage- ment step

Step 1: risk manage- ment planning

Step 2: risk identification

Step 3: quali- tative risk analysis

Step 4: quantitative risk analysis

Step 5: risk response planning

Step 6: risk monitoring and control

Outputs • Risk manage- ment plan

• Risks • Sources • Impacts • Corrective

actions

• Over- all risk ranking

• List of pri- oritized tasks

• List of risks for additional analysis and man- agement

• Priori- tized list of quanti- fied risks

• Proba- bilistic analysis of the project

• Residual risks

• Second- ary risks

• Contrac- tual risks

• Contin- gency reserve amounts needed

• Work- around plans

• Corrective action

• Project change requests

• Updates to the risk response plan

• Risk database

In sum, there are many sources of project risk. The best way to address and control them is to conduct a risk management planning process. We will discuss the risk planning process in terms of the outputs of the step—that is, what is produced.

5.3 Risk Identification Risk identification helps start the process by drawing on the team and stakeholders to list potential risks. There are many ways to initially identify project risks. Top management, proj- ect sponsors, the project team, stakeholders, and customers participate in anticipating and addressing risks. The project manager can ask, “What can go wrong in this project, and how can we prevent things from going wrong and offset them if they do?” Out of this process will come a wide variety of potential risks that could challenge the project team.

For instance, a member of a new product project team might identify the risk that a competi- tor could create a new product similar to his or her team’s and bring it to the market faster, at a lower price, or at a higher performance level. This potential risk is then associated with a task, such as initial requirements analysis and product design; an impact, such as failure to obtain customer acceptance; an intensity, such as a showstopper; and a contingency action, such as to monitor a competitor’s new product development activities or to seek a partner- ship should a competitor beat the team product to market.

Problems result from not identifying a task in the WBS that later creates real risk exposure, such as if a project manager misses a major risk in the initial stages because of a missing function or component. If it is not visible early, a major risk can show up later. For instance, a project manager may have identified a major software engineering task in the WBS that is not very challenging, so it is considered low risk. But the real risk lies in the availability of a

bar81677_05_c05_149-172.indd 155 9/9/14 10:49 AM

Section 5.3 Risk Identification

key software engineer to do the work—which was not identified in the WBS and can cause issues later.

The risk identification process is important—if risks are not identified early in project plan- ning, the problems and costs of dealing with them later will increase. Unanticipated risks dis- rupt projects simply because the team has not thought them through. No project team wants to be surprised by a development that no one anticipated.

The output of risk identification is a listing of project risks and documentation on the poten- tial impact of each on the project. In addition, this step describes what actions can be taken to prevent the risk or control its impacts.

Identify Sources of Risk

All potential sources of risk must be identified. These include indicators of possible risk events during or after the project that could result in project problems and even failure. Risks are normally associated with project tasks.

For instance, in a contract negotiation in the outsourcing process, a contractor might enter into a contract that requires successful completion of the project on a tight schedule even though the contractor knows the schedule cannot be met. This happens when contractors assume that they can overestimate their capacity to meet a schedule and underestimate con- tract costs in order to secure the contract based on a low bid, then in the middle of the project when it is clear they cannot meet requirements, get more funding.

The same risk can occur with any project in which the project manager assumes the best case in meeting requirements in order to please the customer and get approval and funding, but in practice cannot perform as promised.

Identify Impacts

Here the risks are reviewed to identify what impacts are possible, from schedule slippage to budget overruns to quality problems. This step is in preparation for the next step, risk analysis, where each risk is analyzed to help understand its probability of occurring and the severity of its impact.

Risk identification is an important step because it establishes the agenda for later risk analy- sis and control. It is in this step that initial ideas on how to prevent a risk event from occur- ring or how to control its impact is first documented. Later, in risk response planning, these actions are fleshed out, but it is here that connections are first made between a project risk and actions that might be taken to control it. If this initial process misses big risks and actions to control them, it can be costly down the road.

bar81677_05_c05_149-172.indd 156 9/9/14 10:49 AM

Section 5.4 Risk Analysis

5.4 Risk Analysis Risk assessment or analysis is the process of analyzing project risks to learn more about them, quantify probabilities when it makes sense, and help decide what to do about them. The PMBOK separates the risk analysis process into two parts: (a) qualitative and (b) quantitative.

Qualitative risk analysis connotes a better description of the risk, its dimensions, and its char- acteristics. Risk qualification involves listing risks and using a risk matrix to determine how they should be categorized and ranked according to their impacts on schedule, quality, cost, and overall success of the project.

Quantitative risk analysis involves getting a finer view of risk by applying mathematical and other quantitative tools. Quantitative assessment applies probability and other analytic tools such as decision trees to pin down the extent of risk and risk impacts.

The Links Corporation Private Sector Case Study

As you will recall from the last meeting at Links Corporation, the project goal, objective, charter, and scope of work were proposed by the vice president of manufacturing, Stewart Levi.

Now the vice president of project management, Desiree Aubert, and the project manager, Lorenzo Costa, are meeting to discuss the risks associated with their proposed project.

Aubert is concerned about the risks involved in the new product project. She knows that if the manufacturing department does not accept it or its outputs, the project will fail, since one of its goals is to convince the department that new product projects can be useful to them. She wants to spend time anticipating risks that would hinder their ability to meet this objective.

Luckily, Costa already has a plan. He plans to prepare a risk document that summarizes the actions of selecting and communicating the project deliverable and how to offset any prob- ability that manufacturing will not agree with the selection. He knows that they must choose the right project from the get-go and plans to include the department in the discussion on risks to ensure that the project is considered from their perspective.

Costa points out that one of the key challenges will be to anticipate how this new project will affect manufacturing schedules. He uses the example of creating a prototype product and the effect that it will have on manufacturing to produce one unit for testing. He states that the risk is that the department will likely regard prototype production as interfering in manufac- turing’s revenue-producing operations.

Questions for Discussion

1. What do you think about the company’s plan to identify risks? 2. Did they include the key risk that the manufacturing department would not

cooperate in a project to produce a new product?

bar81677_05_c05_149-172.indd 157 9/9/14 10:49 AM

Section 5.4 Risk Analysis

In practice, companies rarely split the two. The point of risk analysis is to zero in on poten- tially high-risk tasks and obtain a more detailed picture of their impacts.

The goals of risk assessment include:

1. to increase understanding of the project; the more project managers know about risks, the more they know about the project;

2. to rank order risks in terms of severity and impact so that project managers know which to address first;

3. to serve as the basis for identifying alternative approaches to response and risk management and integrating risk into the risk management process; and

4. to offset the normal tendency to be optimistic in project planning; that is, the basic human trait of expecting the best will take over unless you weigh it against a risk analysis that identifies impacts and pessimistic scenarios. A scenario is a projection into the future to see what might happen under given conditions, helping manage- ment prepare for action steps it might have to take.

Now that you have an idea of the types of risk analysis, we will take a closer look at the quali- tative process.

Qualitative Analysis

Qualitative risk analysis describes each risk in detail and establishes the relative priority of each risk, given its probabilities and impacts. The major outputs of this type of analysis are a risk ranking and risk description.

Risk Ranking Once the qualitative process is finished, two rankings are produced: (a) how the project’s overall risk is ranked compared to others (this may be completed by comparing and selecting a portfolio of projects); and (b) how individual risks rank within the project, usually limiting the list to five or less. The list of prioritized risks is incorporated in a project report to stake- holders along with supportive information, including the risk matrix and contingency plans. For instance, a new product project in the field of remote home controls has been selected for approval and funding and is ranked against two other related projects. One project is aimed at solar home energy systems and the other at delivering new home irrigation and landscaping systems. Because the company has discovered a fast-growing market in remote home con- trols, the home control project is ranked higher than the other two and is fully funded first. Within the project, of the three major risks identified—market risk, technical risk, and safety risk—technical risk is ranked highest because of a new discovery that the radio signals for remote home controls can interfere with satellite TV reception; thus, the risk exists that they will not sell well.

bar81677_05_c05_149-172.indd 158 9/9/14 10:49 AM

Section 5.4 Risk Analysis

Risk Description The risk description describes risks in terms of how they might occur and what impacts they might have. The purpose of the description is to communicate to the team and stakeholders what is known about each risk and to alert the team—and potentially the customer—to the need to reflect each risk into their thinking about the project and their planning. The key point in describing risk is to communicate the risk and its impacts to those who will have to address it.

Sometimes risks occur regardless of good planning to avoid them. For instance, in managing projects in the public sector, there will always be a risk of outside interference and criticism since almost all projects can create conflict among interest groups.

State Department of Health and Human Services Public Sector Case Study

When we last saw our health leaders in Chapter 4, they had a proposed project goal, objec- tive, charter, and scope of work.

Now the secretary, Robert Mikawa, and the assistant secretary for programs, Rebecca Daw- son, have scheduled a meeting to analyze the risks involved in their project, particularly the risk that their program and projects may fail because of the weight of public criticism.

Dawson begins by listing the many different levels of risk in their project, from broader political and socioeconomic risks to operational risks. She knows that they will be inter- related because of the public nature of the project and their agency. If the HHS website does not identify and secure critical health information for various stakeholders, it will be a product failure and a political and program-wide failure.

Mikawa plans to create a checklist of how to position the project for political acceptance, while Dawson continues to evaluate risks from a project and product standpoint. Then Mikawa would like to integrate the two and move forward from there. He believes one of their challenges is to demonstrate to all stakeholders, political leaders, and interest groups that they anticipated all possible risks and developed plans to address them. He knows that if they miss any key risks, they will be criticized for bad planning, but if they anticipate all potential risks and involve stakeholders in identifying them, then they can defend their actions.

Questions for Discussion

1. The secretary mentions political risk; how does political risk figure into risk management?

2. What is political risk for a public agency, and how does it differ from risks facing a private sector organization?

Quantitative Risk Analysis

Quantitative risk analysis measures potential risks and produces detailed data on potential impacts. Quantitative data includes detailed impacts, probabilities, and analysis of all impacts.

bar81677_05_c05_149-172.indd 159 9/9/14 10:49 AM

Section 5.5 Risk Response

For instance, in an IT project, quantitative analysis would assess how a given risk—say poten- tial incompatibility of a new system with existing platforms or the failure of a product to pass required performance tests—would impact management and decision making.

This information helps calculate the risk ranking and probability analysis of the risk occurring.

Prioritized Risk List Based on the quantitative analysis, each risk is ranked again, this time based on more data and information on the risk. Sometimes the original ranking in the risk identification pro- cess is fundamentally changed after quantitative analysis. For instance, a new product may be ranked high initially because of potentially high sales in a growing market, but after more testing the product fails to perform to standards 10 times in 100 tests, and its ranking is reduced and funding disapproved.

Probability Analysis In this analysis the probabilities are worked to a finer level of detail. A probability set at 25% in the qualitative phase might be fine-tuned to 38% with more input from intensive analysis of past projects and simulations, and perhaps some experiments. The qualitative risk is simply a judgment made based on observations and past experiences, with little or no real data or facts. A project manager in an environmental cleanup project may decide that the probability of find- ing a toxic chemical in the process is low, say 25%, based on comments from other project man- agers and their experiences with similar projects. But later the project manager finds research in the literature that suggests a highly toxic agent is likely to exist in the particular location of the project. As a result, the probability is raised from 25% to 38% based on technical advice from experts in the field. The higher the risk probability, especially if there are potential severe impacts, the more resources are likely to go into risk prevention and control in the project.

Risk analysis is extremely important to project success; if the project team does not complete a detailed review of risks and impacts, it will not have enough information to set priorities and plan for risk control.

5.5 Risk Response Risk response covers all of the possible actions to prevent or control risks. The key purpose of response planning is to outline preventive and corrective actions and to incorporate those actions in the plan.

Factors in Determining a Risk Response

There are many potential factors in determining a risk response. These include earned value, risk intensity, people, technology, customers, processes, costs and benefits, and corrective action. This is represented in Figure 5.2.

bar81677_05_c05_149-172.indd 160 9/9/14 10:49 AM

Risk Response

People

Cost/Benefit

Technology

Customer

Processes

Earned Value: Cost/Schedule

Variance

Risk Intensity

Corrective Action

Section 5.5 Risk Response

Earned Value Cost and schedule variance are key inputs to risk response, particularly root causes. Variance is a measure of how much a given indicator of project performance, such as schedule or cost, is varying from the plan. A minor (3%) variance is nothing to worry about, but a major (15% or more) variance suggests either that the original estimate was inaccurate or that new factors have changed performance from the original plan. A variance is followed up by an analysis of root causes—looking for what underlying factors caused performance to divert from the plan. The root causes of schedule slippage and cost escalation are typically related to underlying risks that should have been addressed in the planning process. Risk planning should uncover potential root causes before the final baseline schedule is completed. Earned value can be seen as an indicator that a risk has not been attended to; a late wake-up call that is often diffi- cult to address. Earned value is the measurement of whether a project is “earning” its funding by performing according to plan, or whether its variance from the plan suggests a problem.

Figure 5.2: Risk response factors

Note that there are a wide variety of factors to consider in determining a response to a given risk. This figure helps identify a checklist of factors that would be analyzed as a project manager considers potential responses.

Risk Response

People

Cost/Benefit

Technology

Customer

Processes

Earned Value: Cost/Schedule

Variance

Risk Intensity

Corrective Action

bar81677_05_c05_149-172.indd 161 9/9/14 10:49 AM

Section 5.5 Risk Response

Risk Intensity Despite quantitative tools for calculating probabilities and intensities, there is considerable personal and professional judgment involved in aligning a risk response with the intensity and impact of that risk. In the end a project manager must make the decision on the expected value of a given decision at a key project milestone or crossroad. Intensity is best described by those closest to the point of impact, like customers, project team members, and functional and technical professionals, so they are the most accurate sources for evaluating intensity.

People Risk management is essentially a people issue, not a technical or analytic issue. Project man- agers must depend on the awareness and judgment of those closest to the work to assess and respond to risk. The key is placing responsibility for risk identification and response in the hands of those planning and designing the work early enough to incorporate all worst-case scenarios. Key stakeholders will respond to a culture that encourages and enables early con- tingency planning by anticipating risks and integrating them into project schedules and bud- gets. In the absence of such a culture, the organization can deteriorate into finger-pointing when unanticipated risks impact a project schedule or budget (Irwin, 2008).

Technology Technology creates risk simply because projects often involve designing and testing new tech- nologies or integrating new systems. New systems and products are risky by definition and involve key decision points based on risk. But these risks should be addressed in the design and testing process itself—in other words, technology risk is integrated into every step of the design process. For instance, in the development of a new electronic instrument, the project team faces the risk that the instrument will fail in tough industrial applications. That risk is translated into a design function to test the instrument in those conditions, thereby respond- ing to the risk at the point of design.

Customers The customer is a major factor in responding to risk since it is the customer who will likely foot the bill for response and pay the price for unanticipated risk impacts. Thus, the customer must be involved in every step, from concept through prototyping and production. The most practical approach here is to report any risks in a project, specifically in terms of customer expectations. That involves a firm understanding of the requirements and regular reporting on progress against those expectations.

Processes Often a key process will determine how a risk is addressed and how risk response is man- aged. For instance, if prototyping is built into a systems development process, the risk of cus- tomer rejection of the product can be offset early. It is in defining the process that key risks and responses are designed into the way work is done.

bar81677_05_c05_149-172.indd 162 9/9/14 10:49 AM

Section 5.5 Risk Response

Costs and Benefits Two kinds of costs occur in risk management: the costs of responding to unanticipated impacts of risk and the costs of planning and addressing risk proactively as part of the process. It is not the cost of risk response that determines next steps as much as the relationship between costs and benefits, as well as the timing of the response. “Pay me now or pay me later” might well be the guiding principle. The cost of a given product test in the design process is likely to be much lower than the cost of responding to a product failure on a performance standard that was not tested in design.

Corrective Action Despite the best-laid plans and schedules, project management is largely a process of midstream adjustments and corrections based on the dynamics of a project in progress. That means that close monitoring of key project indicators is imperative to real-time response to actual progress.

Corrective action, the process of continually bringing a project in line with its performance objectives and aiming the process to completion, is facilitated by contingency plans already built into the schedule in anticipation of risks and uncertainties. Without such plans, correc- tive actions are often ill conceived in the heat of the crisis and often generate counterintuitive results. What is expected as a result of a given action not only does not happen, but other things happen in the project as a result, which creates new problems.

Here the project manager and team identify possible corrective actions to prevent the risk from happening in the first place and to correct or control its impacts if it does occur. These actions are sometimes called contingencies: Taking an action is dependent on the risk event actually occurring.

In sum, it is important to come up with responses to various risks and plan them into the proj- ect instead of simply reacting as they occur. This gives the project team information that may help in preventing risks simply by making them visible early in the project.

Outputs from Risk Response Planning

Once the project manager knows what the project risks are likely to be, the next step is to plan a response, an action to prevent or control the risk. The outputs from this step include a risk response plan, residual risks, and possibly a contingency reserve.

Risk Response Plan Although a formal, written risk response plan is not always feasible because of the cost and effort involved, it is via the process of preparing the risk plan that the project team actually discovers risks, not in writing the plan. Once a project manager is past the process of defining risks, planning to respond, and folding the results into planning documents such as the sched- ule and budget, he or she “owns” those risk responses and incorporates them into the plan.

A separate, documented risk response plan is not always necessary. The point is to make sure that the team thinks through what actions can be taken in the event of a given risk and to

bar81677_05_c05_149-172.indd 163 9/9/14 10:49 AM

Section 5.6 Risk Monitoring and Control

incorporate those actions into the project plan and schedule. The danger of relying entirely on a document is that once it is prepared, team members may ignore it, especially if they have not been involved in its preparation.

Identify Residual Risks Residual risks continue to exist after corrective action. Sometimes residual risks are created that were not anticipated in the original project planning process. For instance, suppose there is a risk in a construction project that a supplier will deliver bad construction materials and supplies to the site, and that risk occurs. A corrective action is then taken to change suppliers, but the new supplier brings on a new, unanticipated risk of late delivery.

Assess the Need for a Contingency Reserve A risk response plan must include the cost of response because there is always a trade-off between the cost of corrective action and the benefits it brings. The cure might be more costly than the damage from the risk impact. Sometimes a project must be protected with a reserve fund or insurance program so that the company is not financially exposed from a given risk even though it is mitigated.

5.6 Risk Monitoring and Control The PMBOK places emphasis on monitoring controlling and risks, but this process is again an integral part of the project review and control process. Keeping up with risk involves equip- ping team members and suppliers with the tools necessary to monitor risk and the sensitivity to catch risk problems before they occur. It is mostly an interpersonal process, rather than a formal project review process.

It takes some planning and effort to monitor how risks change as the project progresses, how those changes affect the original risk assessments, and how they will affect project outcomes. This is typically done through a project review process in which individual project risks are reviewed as part of the broader review of the whole project. For instance, when a software design project has some bugs, a software design review might be scheduled, and during the project review prior to that design review, a checklist might be constructed to “flag” debug issues.

The other part of the monitoring process is making sure that the team members closest to the job are aware of risks and communicate risk information while the design and development is occurring. They are the most likely to know the extent of change in a risk assessment and how it will impact the project.

Project Control Systems

Since one purpose of risk management planning is to control risks and their impacts, we will discuss the control process here. Project control implies a systematic response that attempts to control risks and their impacts. Below are some of those systems.

bar81677_05_c05_149-172.indd 164 9/9/14 10:49 AM

Section 5.6 Risk Monitoring and Control

Cost and Schedule Integration If the project schedule is integrated with the cost estimate, or each cost item is associated with a project task, then when a risk associated with a task occurs, the new costs of respond- ing can be added to the current task costs.

Information Flow and Ties to the WBS Baseline schedules are developed from the WBS, and schedule and cost data are related to particular tasks. Since costs are directly associated with tasks, each task can be assessed in terms of cost and schedule impacts.

Network Planning and Schedule Development Scheduling is the most important function of project managers, and risk determines the amount of buffer that is withheld by the project manager based on the probabilities of risk occurrence and contingency action.

Project Cash Flows and Commitments Cash flows committed beyond customer agree- ments or contracts represent separate risks; thus, cash flows are aligned with work performed and scope boundaries.

Reporting Responsibilities Project managers report risk and cost information to top management, stakeholders, and customers; functional managers report technical and technol- ogy risks and costs to top management.

Outputs From Risk Monitoring and Control

Good monitoring alerts project managers that a risk is about to occur or has occurred. As risks actu- ally occur, actions are taken to address them. These actions rely on earlier listings of preventive and corrective actions in the risk management plan, but when bad things actually happen, the project man- ager has to do something—sometimes quickly and deliberately. The more plans and potential actions have already been proposed, the easier it is for a project manager to act and control impacts.

Monkeybusinessimages/iStock/Thinkstock

A major role in project management is reporting the project’s current state to key stakeholders. Reporting is an aspect of the risk management process.

bar81677_05_c05_149-172.indd 165 9/9/14 10:49 AM

Section 5.6 Risk Monitoring and Control

There are a number of outputs of risk monitoring and control, including workaround plans, corrective action, project change requests, and updated risk response plans or risk databases.

Workaround Plans The workaround plan is a way of avoiding the impact of a risk by taking an action that off- sets it. Workaround sometimes takes advantage of innovative options to overcome or avoid a project risk, and is often the result of outside-the-box thinking that can be generated in a brainstorming session. For instance, consider a project to test a new business aircraft design that has planned to pay the local airport fee every time it conducts the many required tests, but finds that the risk of higher airport runway fees has actually happened. This increase has made the aircraft testing too expensive for the budget, so the workaround may be to test the aircraft in simulations in its early stages instead of flying it every time.

Corrective Action Corrective action is taken when the project is not performing to plan, according to schedule, cost, and quality. Corrective actions could include changes in the schedule or budget, changes in task assignments, or actions to train or even replace team members. Corrective action is an adjustment in how the project is managed based on the occurrence of risk events that threaten the project.

Project Change Requests Often in monitoring, there is a need to fundamentally change a project scope or key deliver- able, which triggers a change request. This corrective action is a formal one that may result in a new set of plans, requirements, schedules, budgets, and assignments.

Update the Risk Response Plan Updates to the risk response plan result from lessons learned in the monitoring process. As a result of monitoring data on project progress, the plan of response is typically updated.

Update Risk Database The risk database, or the documentation of project risks, impacts, and potential corrective actions, is usually an electronic documentation of risk information that is useful in designing corrective actions and in identifying lessons learned for future projects. Updating the risk database involves entering new data and analyzing it for new impacts. For instance, if a risk database on a military surveillance software product is updated to reflect new threats from terrorists that involve new security-breaching technologies, the risks inherent in the new technologies and their impacts on schedule, cost, quality, and overall performance must be analyzed and corrective actions reevaluated.

bar81677_05_c05_149-172.indd 166 9/9/14 10:49 AM

Summary and Resources

In sum, the risk management process involves systematic steps, but the actions involved in these steps should be integrated and embedded in the project process, rather than exist sepa- rately from them. The whole idea of risk management is to enable good decision making to address risks, not simply to document them.

Summary and Resources

Chapter Summary • Risks are uncertainties that could affect project success. • Risks can have a variety of impacts on schedule, cost, quality, and other measures of

project performance. • It is important to find the root causes of risks so these risks can be controlled at

the source. • The steps in risk management planning are identification, analysis, response, and

monitoring and corrective action. • Risk identification is the process of anticipating risks and documenting them. • Risk analysis helps to define and describe a project risk and its impacts in detail so

that it is easier for the team to determine preventive or corrective action. • Qualitative risk analysis describes and ranks risks in terms of their impacts and costs. • Quantitative risk analysis involves actually testing the risks to get more detailed

information on impacts and probabilities. • Risk response is the process of determining what actions to take to adjust the proj-

ect either to prevent or control the risk. • Risk monitoring is the process of monitoring, or tracking, the project to make sure

any major variances are identified early and controlled. • Corrective actions are actions that can prevent or control risks, and they include

changes in schedule, resources, budget, materials, processes, documents, and team composition.

Posttest 1. Risks related to managing work and the project cycle are called __________. a. product risks b. scale risks c. technical risks d. process risks

2. Risk is best understood as __________. a. separate from the process of management b. an integral part of business and planning c. an unfortunate but unavoidable rare occurrence d. a common problem that is nonetheless preventable

bar81677_05_c05_149-172.indd 167 9/9/14 10:49 AM

Summary and Resources

3. Which of the following is a reason the author suggests the PMI’s PMBOK framework needs updating?

a. The PMBOK underemphasizes quantitative tools for risk management. b. The current PMBOK guide places too much emphasis on the human element of

the risk process. c. The PMI’s guide does not cover how to plan for risk when necessary inputs are

missing. d. The PMBOK’s focus on process is practical in work settings but not useful for

ensuring discipline and quality.

4. The BEST way to avoid scope creep, a major risk in any project, is to __________. a. allow team members and contractors to add tasks to the project as needed b. use a realistic timeline and cost estimate to create the project schedule c. focus only on high-risk, resource-consuming tasks d. make sure the WBS is well prepared and complete

5. On which documents is risk identification generally based? a. qualitative or quantitative analysis results b. risk management plan or WBS c. strategic plan or meeting notes d. probabilistic analysis of the project

6. Identifying risk impacts is the step before __________. a. risk analysis b. risk correction c. risk identification d. risk reporting

7. Which of the following is NOT a goal of risk assessment? a. Understand the project better. b. Prioritize the order in which risks should be addressed. c. Determine different approaches to respond to risk. d. Improve the optimism in project planning.

8. __________ risk analysis involves describing risks to learn more about them, whereas __________ risk analysis includes categorizing and ranking risks based on their antici- pated impacts.

a. Quantitative; qualitative b. Assumptive; sensitivity c. Qualitative; quantitative d. Sensitivity; assumptive

9. In risk response, plans for corrective action should be __________. a. incorporated into baseline schedules so corrections are not considered changes

later on b. prioritized so that only the corrective actions that least affect project costs are

undertaken first c. simulated using mathematical representations so that project managers can see

how effective they will be d. linked to the optimistic estimates of duration in a PERT analysis to make sure

risks that are only potential do not distort the schedule

bar81677_05_c05_149-172.indd 168 9/9/14 10:49 AM

Summary and Resources

10. The BEST way to make sure all worst-case scenarios are considered and planned is to __________.

a. use data-precision ranking to determine how the project’s overall risk compares to others

b. test assumptions by confirming that the assigned risk probability is a good estimation

c. incorporate the risk causes common to the industry into all risk planning d. place responsibility for identifying risks in the hands of those closest to the work

early on

11. Project control is defined as __________. a. managing the flow of information to stakeholders b. using a systematic response to control risk and its impact c. maintaining the baseline schedule and cost estimate d. employing a hierarchical structure to meet a project’s needs

12. Which of the following is an output that may result from the risk monitoring and control process?

a. a list of prioritized risks b. a project change request c. a probability of achieving the cost and time objective d. an overall risk ranking for the project

Review Questions 1. How is risk identified, categorized, and documented in the project planning process? 2. What is the difference between uncertainty and risk? 3. What is the difference between qualitative and quantitative risk assessment? 4. What are the key steps in project risk management according to the Project Manage-

ment Institute’s PMBOK?

Think About It! Reflective Exercises to Enhance Your Learning 1. Choose a project and identify the risks. 2. Associate the risks listed with specific tasks in the WBS. 3. Prepare a risk matrix and include all risks and required information to complete

the matrix.

Additional Resources Barkley, B. T. (2004). Project risk management. New York: McGraw-Hill.

Project Management Institute. (2012). Practice standard for project risk management. New York: Author.

An article on project risk management that emphasizes early identification and analysis of risks: Symonds, M. (2013). Risk management for project managers. Retrieved from Project Management Hut website: http://www.pmhut.com/risk-management-for-project-managers

bar81677_05_c05_149-172.indd 169 9/9/14 10:49 AM

Summary and Resources

Answers and Rejoinders to Chapter Pretest 1. True. A good method for beginning to think about a project’s risks is to ask the proj-

ect team and top management to brainstorm, either in a meeting or electronically, a list of things that might go wrong with a particular project and what could be done about these possibilities.

2. False. The PMI’s PMBOK is a good guide for project risk management. The process of risk management consist of six steps, which include risk planning, identifying risk, qualitative risk analysis, quantitative risk analysis, response planning, and monitor- ing and control.

3. True. As the project progresses, unplanned risks that arise can disrupt the project because the team has been taken by surprise and will need to take time to address them, which can impact the cost of the project.

4. True. A risk matrix ranks all risks in terms of severity. It is possible for a risk that is very likely to occur to have a low severity ranking if it would not greatly affect the project’s cost, schedule, or deliverables. On the other hand, it is possible for a risk that has a low probability to occur to have a high severity ranking if it were to occur.

5. False. A formal response plan cannot always be drafted, due to constraints of cost and effort. However, more important than having a written plan is the incorpora- tion of risk into the project schedule and the expected, optimistic, and pessimistic estimates.

6. True. Risk management involves documenting, tracking, and organizing risk data. This information is commonly stored electronically. Updating the risk database can help determine decisions to address problems and can be used to plan future proj- ects better.

Answers and Rejoinders to Chapter Posttest 1. d. While product risks are related to a product’s performance and possible failure,

process risks have to do with the project life cycle and all the risks involved in managing the work.

2. b. Another way of thinking about risk is that it simply means the things that can go wrong. These things should be anticipated and addressed when work is defined and scheduled, and in fact, they are the reason that projects are planned in the first place. Thus, risk is central to doing business and to planning.

3. c. The PMI’s PMBOK guide emphasizes methods and process for managing risk will be in place. However, this is not always the case in practical work settings.

4. d. The scope of work should define all of the work needed to complete the project in a WBS. To make sure tasks outside the WBS are not added later in the project process, a thorough WBS takes into account the perspectives of the team, stake- holders, customers, and top management.

5. b. If a risk management plan has been created, it is used as the major input to risk identification. If there is no risk management plan, the identification of risk usu- ally begins with review and finalization of the WBS.

6. a. Identifying risk impacts is an important stage in risk identification because it pre- cedes the next step of risk analysis in the risk management process. Identifying impacts considers how risks can affect the project schedule, budget, and quality. During risk analysis, each of these risks are further analyzed to assess the prob- ability that the risk will happen and how severely it can impact the project.

bar81677_05_c05_149-172.indd 170 9/9/14 10:49 AM

Summary and Resources

7. d. One of the goals of risk assessment is to offset the human trait of expecting the best outcomes for a project. Implementing risk analysis can help identify prob- lems that can occur, their impacts, and possible solutions to address these prob- lems, which can improve the overall success of the project.

8. c. The risk analysis process is composed of two parts: qualitative and quantitative. In qualitative risk analysis, the dimensions and characteristics of the risk are defined. In quantitative risk analysis, the risks are listed and a risk matrix is used to catego- rize and rank risks according to how they might affect the project’s success.

9. a. The project manager should outline corrective actions and incorporate them into the baseline schedule to prevent them from being viewed as changes or addi- tional tasks in the future. Later on, corrective actions can be included in the pes- simistic duration estimates in the PERT analysis.

10. d. In assessing and responding to risk, the project manager has to rely on the judg- ment and awareness of the people closest to the work. Doing this early in the process is essential so that all possible risk can be identified and planned for.

11. b. Project control is not the use of a command-and-control organizational structure, nor the control of information or even schedule. Instead, it implies a systematic attempt to control risk and its impact on a project by using cost–schedule integra- tion, network planning, schedule development, and project cash flows and com- mitments, among other methods.

12. b. In the risk monitoring and control process, a plan for responding to previously identified risks is in place, and the project is being monitored so corrective action can be taken as needed. This can lead to project change requests, since monitor- ing may uncover the need to change a project’s scope or key deliverable. The other outputs listed here tend to result from the earlier stage of risk analysis, in which more is learned about risks that have been identified.

Key Terms

earned value A term used to represent, in dollar terms, what portion of a project task has been completed successfully.

process risk Uncertainties on how long a given process or procedure such as product testing will take and whether it will be suc- cessful, leading to a project risk of schedule delay or inadequate quality control.

product risk Uncertainty that the product deliverable will meet customer performance requirements even if it passes testing.

risk assessment The process of reviewing and analyzing risks to identify intensity of impact, probability, and contingency actions to prevent or control the risk.

scenario A graphic projection or “scene” of the way things might work in the future for a project in order to anticipate problems and identify corrective actions before they occur.

bar81677_05_c05_149-172.indd 171 9/9/14 10:49 AM

bar81677_05_c05_149-172.indd 172 9/9/14 10:49 AM