THE PMP® EXAM CONTENT FROM THE PLANNING THE PROJECT PERFORMANCE DOMAIN COVERED IN THIS CHAPTER INCLUDES THE FOLLOWING:
Identify Risks and Define Risk Strategies
Hold on to your hats! I'm going to cover a lot of material in this chapter, but it will go fast, I promise.
Every one of us takes risks on a daily basis. Just getting out of bed in the morning is a risk. You might stub your toe in the dark on the way to the light switch or trip over the dog and break a leg. These events don't usually happen, but the possibility exists. The same is true for your project. Risk exists on all projects, and the potential that a particular risk will occur depends on the nature of the risk.
Risk, like most of the elements of the other Planning processes, changes as the project progresses and should be monitored throughout the project. As you get close to a risk event, that's the time to reassess your original assumptions about the risk and your plans to deal with the risk and to make any adjustments as required.
Not all risks are bad. Risks can present future opportunities as well as future threats to a project. They may occur due to one reason or several reasons, and they may have multiple impacts. All risks have causes, and if the risk event occurs during a project, there are consequences. Those consequences will likely impact one or more of the project objectives, and you'll need to know whether the consequences have positive or negative impacts.
Risk is, after all, uncertainty. The more you know about risks and their impacts beforehand, the better equipped you are to handle a risk when it occurs. The processes that involve risk, probably more than any other project Planning process, concern balance. You want to find that point where you and the stakeholders are comfortable with the risk based on the benefits you can potentially gain. In a nutshell, you're balancing the action of taking a risk against avoiding the consequences or impacts of a risk. The rest of this chapter will deal with finding out what risk events might occur (and how to deal with those risks that are unknown), determining an organization's tolerance for risk taking, and developing action plans for those risks you've determined have hefty impacts. The first step is performing the Plan Risk Management process. Here, you determine the approach you'll use for risk management activities and document your plans for them in a risk management plan. You'll look at that process now.
Risks come about for many reasons. Some are internal to the project, and some are external. The project environment, the planning process, the project management process, inadequate resources, and so on can all contribute to risk. Some risks you'll know about in advance and plan for during this process; others risk events will occur unannounced during the project. The Plan Risk Management process determines how you'll plan for risks on your project.
To document the risk management plan, you need to gather some inputs that will help you determine your organization's risk policies and tolerance for risk. You'll look at those inputs next.
Risks associated with a project generally concern four project objectives—time, cost, scope, and quality—or any combination of the four. As you might have guessed, the project scope statement is an input to this process since it describes your project deliverables. The inputs of this process are as follows:
Project scope statement
Cost management plan
Schedule management plan
Communications management plan
Enterprise environmental factors
Organizational process assets
One of the key elements of the enterprise environmental factors to consider as in input in this process is the risk tolerance levels of the organization and the stakeholders. Risk tolerance is that balance I talked about earlier where stakeholders are comfortable taking a risk because the benefits to be gained outweigh what could be lost—or just the opposite. They will avoid taking a risk because the cost or impact is too great given the amount of benefit that can be derived. Here's an example to describe risk tolerance: Suppose you're a 275-pound brute who's surrounded by three bodyguards of equal proportion everywhere you go. Chances are, walking down a dark alley in the middle of the night doesn't faze you in the least. That means your risk tolerance for this activity is high. However, if you're a petite 90-pounder without benefit of bodyguards or karate lessons, performing this same activity might give you cause for concern. Your risk tolerance is low, meaning you wouldn't likely do this activity. The higher your tolerance for risk, the more you're willing to take on risk and its consequences.
Note
Organizations and stakeholders, as well as individuals, all have different tolerances for risk. One organization might believe that the risk of a potential 7 percent cost overrun is high, while another might think it's low. However, either one of these organizations might decide to accept the risk if it believes the risk is in balance with the potential rewards. It's important for the project manager to understand the tolerance level that the organization and the stakeholders have for risk before evaluating and ranking risk.
Remember that organizational process assets include policies and guidelines that might already exist in the organization. Your organization's risk categories, risk statement formats, and risk templates should be considered when planning for risks. Defined roles and responsibilities and the authority levels the stakeholders and project manager have for making decisions regarding risk planning should also be considered when developing the risk management plan.
The project scope statement, as mentioned earlier, contains the project deliverables. This is the first place you'll start looking when identifying risks and it should be considered when determining the process you'll use to evaluate risks. The risk management plan (the only output of this process) will become part of the project management plan; therefore, other project management processes and guidelines should be considered when performing this process so that the risk management plan is in line with the overall direction and management of the project.
The Plan Risk Management process has only one tool and technique: planning meetings and analysis. The purpose of these meetings, which are held with project team members, stakeholders, functional managers, and others who might have involvement in the risk management process, is to contribute to the risk management plan. During these meetings, the fundamental plans for performing risk management activities will be discussed and determined and then documented in the risk management plan.
The key outcomes of performing these planning meetings are as follows:
Risk cost elements are developed for inclusion in the project budget.
Schedule activities associated with risk are developed for inclusion in the project schedule.
Risk responsibilities are assigned.
The risk contingency reserve process is established or reviewed.
Templates for risk categories are defined or modified for this project.
Definitions of terms (probability, impact, risk types, risk levels, and so on) are developed and documented.
The probability and impact matrix is defined or modified for this project.
Note
I'll discuss risk responsibilities, define the terms associated with risk management, and help you construct your own probability and impact matrix in the remaining sections of this chapter.
Ultimately, your goal for this process concerns documenting the risk management plan (the output of this process). This document is the basis for understanding the remaining risk processes. Since the risk management plan encompasses a wealth of information, I've given this topic its own section. Let's get to it.
The purpose of the Plan Risk Management process is to create a risk management plan, which describes how you will define, monitor, and control risks throughout the project. The risk management plan is a subsidiary of the project management plan, and it's the only output of this process.
The risk management plan details how risk management processes (including Identify Risks, Perform Qualitative Risk Analysis, Perform Quantitative Risk Analysis, Plan Risk Responses, and Monitor and Control Risks) will be implemented, monitored, and controlled throughout the life of the project. It details how you will manage risks but does not attempt to define responses to individual risks.
Note
I'll talk about how to develop the risk response plans in the section "Developing a Risk Response Plan" later in this chapter.
According to the PMBOK® Guide, the risk management plan should include the following elements:
Methodology
Roles and responsibilities
Budgeting
Timing
Risk categories
Definitions of risk probability and impact
Probability and impact matrix
Revised stakeholder tolerances
Reporting formats
Tracking
You'll take a look at most of these elements next. However, risk categories, probability and impact, and probability and impact matrix are pretty meaty topics, so I'll cover those in their own sections following this one.
- Methodology
Methodology is a description of how you'll perform risk management, including elements such as methods, tools, and where you might find risk data that you can use in the later processes.
- Roles and responsibilities
Roles and responsibilities describe the people who are responsible for managing the identified risks and their responses and for each type of activity identified in the risk management plan. These risk teams might not be the same as the project team. Risk analysis should be unbiased, which might not be possible when project team members are involved.
- Budgeting
The budget for risk management is included in the plan as well. In this section, you'll assign resources and estimate the costs of risk management and its methods. These costs are then included in the project cost baseline.
- Timing
Timing documents the timing of the risk management processes (including when and how often they'll be performed on the project) and includes the activities associated with risk management in the project schedule.
- Revised stakeholder tolerances
This is just as it implies. As you proceed through the risk management processes, you might find that risk tolerances will change. Document those new tolerance levels in the risk management plan.
- Reporting formats
Reporting formats describe the content of the risk register and the format of this document. (I'll talk more about the risk register later in this chapter.) Reporting formats also detail how risk management information will be maintained, updated, analyzed, and reported to project participants.
- Tracking
This includes a description of how you'll document the history of the risk activities for the current project and how the risk processes will be audited. You can reference this information when you're performing risk-planning processes later in the current project or on future projects. This information is also helpful for lessons learned, which I'll cover in Chapter 11, "Controlling Work Results."
Risk categories are a way to systematically identify risks and provide a foundation for understanding. When determining and identifying risks, the use of risk categories helps improve the process by giving everyone involved a common language or basis for describing risk.
Risk categories should be identified during this process and documented in the risk management plan. These categories will assist you in making sure the next process, Identify Risks, is performed effectively and produces a quality output. The following list includes some examples of the categories you might consider during this process (or modify based on previous project information):
Technical, quality, or performance risks
Project management risks
Organizational risks
External risks
You can go about describing categories of risk in a couple of ways. One way is simply listing them. You could, and should, review prior projects for risk categories and then tailor them for this project.
You could also construct a risk breakdown structure (RBS), which lists the categories and subcategories. Figure 6.1 shows a sample of an RBS.
Note
The organizational process assets input might include an RBS that you can reference for this project. And don't forget your PMO. They might have templates or an RBS already developed.
Risk categories might reflect the type of industry or application area in which the project exists. For example, information technology projects will likely have many risks that fall into the technical category, whereas construction projects might be more subject to risks that fall into the external risks category. The categories do not have to be industry specific, however. Keep in mind that project management, for example, is a risk for every project in every industry. You can find a description of each of the categories next:
- Technical/quality/performance risks
Technical, quality, or performance risks include risks associated with unproven technology, complex technology, or changes to technology anticipated during the course of the project. Performance risks might include unrealistic performance goals. Perhaps one of the project deliverables concerns a component manufactured to specific performance standards that have never been achieved. That's a performance risk.
- Project management risks
The project management risk category includes improper schedule and resource planning, poor project planning, and improper or poor project management disciplines or methodologies.
- Organizational risks
The organizational risk category can include resource conflicts because of multiple projects occurring at the same time in the organization; scope, time, and cost objectives that are unrealistic given the organization's resources or structure; and lack of funding for the project or diverting funds from this project to other projects.
- External risks
The external risk category includes those aspects that are external to the project, such as new laws or regulations, labor issues, weather, changes in ownership, and foreign policy for projects performed in other countries. Catastrophic risks—known as force majeure—are usually outside the scope of Plan Risk Management and instead require disaster recovery techniques. Force majeure includes events such as earthquakes, meteorites, volcanoes, floods, civil unrest, terrorism, and so on.
When you're writing the risk management plan, you'll want to document the definitions for probability and impact as they relate to potential negative risk events and their impacts on the four project objectives. Probability describes the potential for the risk event occurring, while impact describes the effects or consequences the project will experience if the risk event occurs. This definition can be sophisticated or simple. For example, you might use numeric values to define probability and impact or simply assign a high-medium-low rating to each risk. What's important to note now is that you don't use these probability and impact definitions here. You use these definitions later in the Perform Qualitative Risk Analysis process. (I'll talk in depth about probability and impact in the section "Analyzing Risks Using Qualitative Techniques" later in this chapter.) But you should define and document them here in the risk management plan.
A probability and impact matrix prioritizes the combination of probability and impact scores and helps you determine which risks need detailed risk response plans. For example, a risk event with a high probability of occurring and a high impact will likely need a response plan. This matrix is typically defined by the organization, but if you don't have one, you'll need to develop this now—during your planning meeting and analysis (the tool and technique of this process). You'll use this matrix in the Perform Qualitative Risk Analysis process, and I'll talk more in depth about it in the section "Analyzing Risks Using Qualitative Techniques" later in this chapter. Again, you want to define (or modify) and document the probability and impact matrix in the risk management plan.
Note
The key point about this process is that you'll define what the probability and impact tools look like now during Plan Risk Management so that the team has an agreed-upon basis for evaluating the identified risks later during the Perform Qualitative Risk Analysis process.
To recap, the steps associated with these last few elements of the risk management plan are as follows:
Define the risk categories (these will assist the risk team in the Identify Risks process).
Determine how probability and impact will be defined (to be used in the Perform Qualitative Risk Analysis process).
Develop or modify the probability and impact matrix (to be used in the Perform Qualitative Risk Analysis process).
Doing all these steps, together with the other elements of the risk management plan, gives you and the risk management team a common understanding for evaluating risks throughout the remainder of the project.
The Identify Risks process involves identifying all the risks that might impact the project, documenting them, and documenting their characteristics. Identify Risks is an iterative process that continually builds on itself. As you progress through the project, more risks might present themselves. Once you've identified or discovered a potential new risk, you should analyze it to determine whether a response plan is needed. You can see that the risk management cycle starts again with Identify Risks and progresses through the remaining risk processes to determine what to do about them.
You can include several groups of folks to help identify risks, including project team members, risk team members, stakeholders, subject matter experts, users of the final product or service, and anyone else who you think might help in the process. Perhaps in the first round of Identify Risks you could include just the project team and subject matter experts and then bring in the stakeholders or risk management team to further flesh out risks during the second round of identification. Risk events can occur at any time during the project, and all project participants should be encouraged to continually watch for and report potential risk events.
Note
I'll talk more about the techniques you can use to identify risks in the section "Tools and Techniques for Identify Risk."
Risks might or might not adversely affect the project. Some risks have positive consequences, while others have negative consequences. However, you should identify all risk events and their consequences. Here's a partial list to get you thinking about where risk might be found:
Budgets/funding
Schedules
Scope or requirements changes
Project plan
Project management processes
Technical issues
Personnel issues
Hardware
Contracts
Political concerns
Business risk
Legal risk
Environmental risk
Management risk
This is by no means an exhaustive list. Remember that risk is uncertainty, and realize that risk (uncertainty) is lurking almost anywhere on your project. It's your job to discover as many of the potential risks as possible using the tools and techniques of this process and to document these risks.
The inputs to the Identify Risks process are as follows:
Risk management plan
Activity cost estimates
Activity duration estimates
Scope baseline
Stakeholder register
Cost management plan
Schedule management plan
Quality management plan
Project documents
Enterprise environmental factors
Organizational process assets
We have covered each of these inputs previously, with the exception of the quality management plan. We'll talk about that in Chapter 7, "Planning Project Resources." For purposes of the Identify Risk process, understand that the quality management process, identified in the quality management plan, has the potential to produce or prevent risks itself. We'll touch on a few of the key elements of some of these other inputs also.
You should pay particular attention to the roles and responsibilities section of the risk management plan and the budget and schedule for risk activities. Don't forget to examine the categories of risks as well. This is a great place to start when you get the team together and begin brainstorming your list of risks.
The project scope statement, part of the scope baseline, contains a list of project assumptions. You'll recall that assumptions are things believed to be true. It's imperative during the risk-planning stages of your project and throughout the work of the project to revisit and revalidate your project assumptions. At the time you recorded an assumption about vendor deliveries, for example, the vendor had a great track record and never missed a date. Months later on the project, that vendor merges with one of its competitors. Now you'll need to reexamine your assumptions about delivery times and determine whether the assumption is still valid or whether you have a risk on your hands.
The project management plan contains several other management plans (such as schedule, quality, and cost) that can be helpful sources also when identifying risks. You should also consider network diagrams, baselines, work performance reports, and other project information during this process.
The enterprise environmental factors input concerns aspects from outside the project that might help you determine or influence project outcomes. Be certain to check for industry information (commercial databases, checklists, benchmarking studies, and so on) or academic research that might exist for your application areas regarding risk information.
As always, don't forget about historical information such as previous project experiences via the project files. Project team knowledge is another form of historical information.
Note
Although the PMBOK® Guide doesn't mention it, I've found that other elements of your project are helpful when identifying risk, such as the work breakdown structure (WBS), the staffing management plan, project staff assignments, and resource availability. In practice, you should examine the outputs of most of the Planning processes when attempting to identify risks.
The Identify Risks process is undertaken using seven tools and techniques:
You'll learn more about each of these in the following sections.
Documentation reviews involve reviewing project plans, assumptions, and historical information from previous projects from both a total project perspective and an individual deliverables and activities level. This review helps the project team identify risks associated with the project objectives. Pay attention to the quality of the plans (is the content complete, or does it seem to be lacking detail?) and the consistency between plans. An exceptionally documented schedule is great, but if the budget isn't as well documented, you might have some potential risks.
Information gathering encompasses several techniques, including brainstorming, the Delphi technique, interviewing, and root cause identification. The goal of these techniques is to end up with a comprehensive list of risks at the end of the meeting. Let's take a quick look at each of these techniques.
Brainstorming is probably the most often used technique of the Identify Risks process. You've probably used this technique many times for many purposes. Brainstorming involves getting subject matter experts, team members, risk management team members, and anyone else who might benefit the process in a room and asking them to start identifying possible risk events. The trick here is that one person's idea might spawn another idea, and so on so that by the end of the session you've identified all the possible risks. The facilitator could start the group off by going through the categories of risks to get everyone thinking in the right direction.
This technique is mentioned in the brainstorming tool and technique in the PMBOK® Guide. The Nominal Group Technique is a type of brainstorming or can be conducted as a mass interview technique.
This technique requires the participants to be together in the same room. Each participant has paper and pencil in front of them, and they are asked to write down what risks they think the project faces. Using sticky-backed notes is a good way to do this. Each piece of paper should contain only one risk. The papers are given to the facilitator, who sticks them up to the wall or a white board. The panel is then asked to review all the risks posted on the board; rank them and prioritize them, in writing; and submit the ranking to the facilitator. Once this is done, you should have a complete list of risks.
The Delphi technique is a lot like brainstorming, only the people participating in the meeting don't necessarily know each other. In fact, the people participating in this technique don't all have to be located in the same place and usually participate anonymously. You can use email to facilitate the Delphi technique easily.
What you do is assemble your experts, from both inside and outside the company, and provide them with a questionnaire to identify potential risks. They in turn send their responses back to you (or to the facilitator of this process). All the responses are organized by content and sent back to the Delphi members for further input, additions, or comments. The participants then send their comments back one more time, and the facilitator compiles a final list of risks.
The Delphi technique is a great tool that allows consensus to be reached quickly. It also helps prevent one person from unduly influencing the others in the group and thus prevents bias in the outcome because the participants are usually anonymous and don't necessarily know how others in the group responded.
Interviews are question-and-answer sessions held with others, including other project managers, subject matter experts, stakeholders, customers, the management team, project team members, and users. These folks provide you with possible risks based on their past experiences with similar projects.
This technique involves interviewing those folks with previous experience on projects similar to yours or those with specialized knowledge or industry expertise. Ask them to tell you about any risks that they've experienced or that they think might happen on your project. Show them the WBS and your list of assumptions to help get them started thinking in the right direction.
Did you ever hear someone say you're looking at the symptoms and not at the problem? That's the idea here. Root cause identification involves digging deeper than the risk itself and looking at the cause of the risk. This helps define the risk more clearly, and it also helps you later when it's time to develop the response plan for the risk.
Checklists used during the Identify Risks process are usually developed based on historical information and previous project team experience. If you typically work on projects that are similar in nature, begin to compile a list of risks. You can then convert this to a checklist that will allow you to identify risks on future projects quickly and easily. You can also use the lowest level of the RBS as a checklist. However, don't rely solely on checklists for Identify Risks because you might miss important risks. It isn't possible for a single checklist to be an exhaustive source for all projects. You can improve your checklists at the end of the project by adding the new risks that were identified.
Assumptions analysis is a matter of validating the assumptions you identified and documented during the course of the project-planning processes. Assumptions should be accurate, complete, and consistent. Examine all your assumptions for these qualities. Assumptions are also used as a jumping-off point to further identify risks.
The important point to note about the project assumptions is that all assumptions are tested against two factors:
The strength of the assumption or the validity of the assumption
The consequences that might impact the project if the assumption turns out to be false
All assumptions that turn out to be false should be evaluated and scored just as risks.
Three types of diagramming techniques are used in Identify Risks: cause-and-effect, system or process flowcharts, and influence diagrams. Cause-and-effect diagrams show the relationship between the effects of problems and their causes. This diagram depicts every potential cause and subcause of a problem and the effect that each proposed solution will have on the problem. This diagram is also called a fishbone diagram or Ishikawa diagram after its developer, Kaoru Ishikawa. Figure 6.2 shows an example cause-and-effect diagram.
The system or process flowchart shows the logical steps needed to accomplish an objective, how the elements of a system relate to each other, and what actions cause what responses. This flowchart is probably the one with which you're most familiar. It's usually constructed with rectangles and parallelograms that step through a logical sequence and allow for "yes" and "no" branches (or some similar type of decision). Figure 6.3 shows a flowchart to help determine whether risk response plans should be developed for the risk (I'll talk about response plans in the section "Developing a Risk Response Plan" later in this chapter).
Note
Cause-and-effect diagrams and system or process flowcharts are used in the Identify Risks process as well as in the Perform Quality Control process.
A third diagramming technique used during Identify Risks is called influence diagramming. According to the PMBOK® Guide, influence diagrams typically show the causal influences among project variables, the timing or time ordering of events, and the relationships among other project variables and their outcomes. Simply put, they visually depict risks (or decisions), uncertainties or impacts, and how they influence each other. Figure 6.4 shows an influence diagram for a product introduction decision. The weather is a variable that could impact delivery time, and delivery time is a variable that can impact when revenues will occur.
Each of these techniques provides a way for you to help identify project risks. It's important that you identify all the risks early in the process. The better job you do of identifying the project's risks at the Planning stage, the more comprehensive the risk response plan will be. Identify Risks is not an area of project planning that you should skip.
Strengths, weaknesses, opportunities, and threats (also known as SWOT analysis) is a technique that examines the project from each of these viewpoints. It also requires examing the project from the viewpoint of the project itself and from project management processes, resources, the organization, and so on to identify risks, including those that are generated internally to the project. Strengths and weaknesses are generally related to issues that are internal to the organization. Strengths examine what your organization does well and what your customers, or the marketplace, view as your strengths. Weaknesses are areas the organization could improve upon. Typically negative risks are associated with the organization's weaknesses and positive risks are associated with its strengths. Opportunities and threats are usually external to the organization. SWOT analysis is sometimes known as internal-external analysis and can be used in combination with brainstorming techniques to help discover and document potential risks.
Experts for risk identification purposes can include anyone who has experience working on similar projects, experience working in the business area for which the project was undertaken, or specific industry experience. You should consider any bias your experts may have regarding the project or potential risk events when using this technique.
The output of the Identify Risks process is the risk register. Everything you've done in this process up to this point will get documented here. The risk register contains the following elements:
List of identified risks
List of potential responses
The risk register also often contains warning signs or triggers, although these aren't listed as an official part of the register. You'll take a look at each of these next. Understand that all risks should be documented, tracked, reviewed, and managed throughout the project.
Risks are all the potential events and their subsequent consequences that could occur as identified by you and others during this process. You might want to consider logging your risks in a risk database or tracking system to organize them and keep a close eye on their status. This can easily be done in spreadsheet format or whatever method you choose. List the risks, assign each risk a tracking number, and note the potential cause or event and the potential impact. This list gives you a means to track the risks, their occurrence, and the responses implemented.
You might identify potential responses to risk at the same time you're identifying the risks. Sometimes just identifying the risk will tell you the appropriate response. Document those responses here. You'll refer to them again in the Plan Risk Responses process a little later in this chapter.
A sample risk register is shown in Table 6.1. As you progress through the risk, planning processes and through the project itself, more risks may be identified and more information will become know about the risks. You should update the risk register with new information as it becomes known.
Triggers are warning signs or symptoms that a risk event is about to occur. For example, if you've ever suffered from a hay fever attack, you can't mistake the itchy, runny nose and scratchy throat that can come on suddenly and send you into a sneezing frenzy. Signals like this are known as triggers and work the same way when determining whether a risk event is about to occur. For example, if you're planning an outdoor gathering and rain clouds start rolling in from the north on the morning of the activity, you probably have a risk event waiting to happen. A key team member hinting about job hunting is a warning sign that the person might be thinking of leaving, which in turn can cause schedule delays, increased costs, and so on. This is another example of a trigger.
Triggers are not listed as one of the risk register elements, but in practice this is an appropriate place to list them. You will likely encounter questions on the exam about triggers, so don't say I didn't warn you. Also, throughout the remainder of the project, be on the alert for triggers that might signal that a risk event is about to occur.
The Perform Qualitative Risk Analysis process involves determining what impact the identified risks will have on the project objectives and the probability they'll occur. It also ranks the risks in priority order according to their effect on the project objectives. This helps the team determine whether Perform Quantitative Risk Analysis should be performed or whether you can skip right to developing response plans. The Perform Qualitative Risk Analysis process also considers risk tolerance levels, especially as they relate to the project constraints (scope, time, cost, and quality) and the time frames of the potential risk events.
The Perform Qualitative Risk Analysis process should be performed throughout the project. This process is the one you'll find you'll use most often when prioritizing project risks because it's fast, relatively easy to perform, and cost effective. The PMBOK® Guide notes that you should identify and manage the risk attitudes of those assisting with this process, and if bias is introduced, you should evaluate it and correct it if necessary.
The Perform Qualitative Risk Analysis process has four inputs:
Risk register
Risk management plan
Project scope statement
Organizational process assets
The critical element in this process, as with most of the processes where the risk register is an input, is the list of risks. The risk management plan documented the roles and responsibilities of risk team members, budget and schedule factors for risk activities, the stakeholder risk tolerances, the definitions for probability and impact, and the probability and impact matrix, all of which should be utilized when prioritizing risks. You'll examine probability and impact more closely in the next section, "Tools and Techniques for Perform Qualitative Risk Analysis."
The project scope statement describes the deliverables of the project, and from there you should be able to determine whether you're dealing with a high level of uncertainty or a project that's similar in size and scope to one you've performed before. Projects with high levels of uncertainty or that are more complex than what the team has undertaken before require more diligence during the Perform Qualitative Risk Analysis process.
As with the Identify Risks process, you should examine historical information and lessons learned from past projects as a guide for prioritizing the risks for this project. Risk databases from your industry or application area can be used here as well. These are part of the organizational process assets input.
The real key to this process lies in the tools and techniques you'll use to prioritize risks. Hold on tight because you're going in the deep end.
The Perform Qualitative Risk Analysis process's tools and techniques are primarily concerned with discovering the probability of a risk event and determining the impact (or consequences) the risk will have if it does occur. The output of this process is a risk register update where you'll document the prioritized risks you've scored using these tools and techniques. All the information you gather regarding risks and probability needs to be as accurate as possible. It's also important that you gather unbiased information so that you don't unintentionally overlook risks with great potential or consequences.
The purpose of this process is to determine risk event probability and risk impact. You'll use the tools and techniques of this process to establish risk scores, which is a way of categorizing the probability and risk impact. The Perform Qualitative Risk Analysis process includes the following tools and techniques:
Risk probability and impact assessment
Probability and impact matrix
Risk data quality assessment
Risk categorization
Risk urgency assessment
Expert judgment
We'll look at each of these tools and techniques next.
This tool and technique assesses the probability that the risk events you've identified will occur, and it determines the effect their impacts have on the project objectives, including time, scope, quality, and cost. Analyzing risks in this way allows you to determine which risks require the most aggressive management. When determining probabilities and impacts, you'll refer to the risk management plan element called "definitions of risk probability and impact."
Probability is the likelihood that an event will occur. The classic example is flipping a coin. There is a .50 probability of getting heads and a .50 probability of getting tails on the flip. Note that the probability that an event will occur plus the probability that the event will not occur always equals 1.0. In this coin-flipping example, you have a .50 chance that you'll get heads on the flip. Therefore, you have a .50 chance you will not get heads on the flip. The two responses added together equal 1.0. Probability is expressed as a number from 0.0—which means there is no probability of the event occurring—to 1.0—which means there is 100% certainty the risk will occur.
Determining risk probability can be difficult because it's most commonly accomplished using expert judgment. In non-PMP terms, this means you're guessing (or asking other experts to guess) at the probability a risk event will occur. Granted, you're basing your guess on past experiences with similar projects or risk events, but no two risk events (or projects) are ever the same. It's best to fully develop the criteria for determining probability and get as many experts involved as you can. Carefully weigh their responses to come up with the best probability values possible.
Impact is the amount of pain (or the amount of gain) the risk event poses to the project. The risk impact scale can be a relative scale (also known as an ordinal scale) that assigns values such as high-medium-low (or some combination of these) or a numeric scale known as a cardinal scale. Cardinal scale values are actual numeric values assigned to the risk impact. Cardinal scales are expressed as values from 0.0 to 1.0 and can be stated in equal (linear) or unequal (nonlinear) increments.
Table 6.2 shows a typical risk impact scale for cost, time, and quality objectives based on a high-high to low-low scale. You'll notice that each of the high-medium-low value combinations on this impact scale have been assigned a cardinal value. I'll use these in the next section when I talk about the probability and impact matrix.
When you're using a high-medium-low scale, it's important that your risk team understands what criteria was used to determine a high score versus a medium or low score and how these should be applied to the project objectives.
Table 6.2. Risk Impact Scale
Objectives | Low-Low | Low | Medium | High | High-High |
|---|---|---|---|---|---|
0.05 | 0.20 | 0.40 | 0.60 | 0.80 | |
No significant impact | Less than 6% increase | 7–12% increase | 13–18% increase | More than 18% increase | |
Time | No significant impact | Less than 6% increase | 7–12% increase | 13–18% increase | More than 18% increase |
Quality | No significant impact | Few components impacted | Significant impact requiring customer approval to proceed | Unacceptable quality | Product not usable |
The idea behind both probability and impact values is to develop predefined measurements that describe what value to place on a risk event.
If the risk impact scale has not been previously defined, develop one for the project as early in the Planning processes as possible. You can use any of the techniques I talked about earlier in the section "Tools and Techniques for Identify Risk," such as brainstorming or the Delphi technique, to come up with the values for probability and impact.
During the Perform Qualitative Risk Analysis process, you'll determine and assess probability and impact for every risk identified during the Identify Risks process. You could interview or hold meetings with project team members, subject matter experts, stakeholders, or others to help assess these factors. During this process, you should document not only the probability and impact but also the assumptions your team members used to arrive at these determinations. The next technique—probability and impact matrix—takes the probability and impact values one step further by assigning an overall risk score.
The outcome of a probability and impact matrix is an overall risk rating for each of the project's identified risks. The combination of probability and impact results in a classification usually expressed as high, medium, or low. According to the PMBOK® Guide, high risks are considered a red condition, medium risks are considered a yellow condition, and low risks are considered a green condition. This type of ranking is known as an ordinal scale because the values are ordered by rank from high to low. (In practice, ordinal values might also include ranking by position. In other words, the risks are listed in order by rank as the first, the second, the third, and so on.)
Now let's look at an example. You have identified a risk event that could impact project costs, and your experts believe costs could increase by as much as 9 percent. According to the risk impact rating matrix in Table 6.2, this risk carries a medium impact, with a value of 0.40. Hold on to that number because you're going to plug it into the probability impact matrix—along with the probability value—to determine an overall risk value next.
You'll remember from the discussion previously that probability values should be assigned numbers from 0.0 to 1.0. In this example, the team has determined that there is a 0.2 probability of this risk event occurring. The risk impact scale shows a medium or 0.4 impact should the event occur.
Now, to determine whether the combination of the probability and impact of this risk is high, medium, or low, you'll need to check the probability impact matrix. Table 6.3 shows a sample probability and impact matrix.
First look at the probability column. Your risk event has a probability of .2. Now follow that row across until you find the column that shows the impact score of .40 (it's the Medium column). According to your probability and impact matrix values, this risk carries an overall score of .08 and falls in the low threshold, so this risk is assigned a low (or green condition) value.
The values assigned to the risks determine how Plan Risk Responses is carried out for the risks later during the risk-planning processes. Obviously, risks with high probability and high impact are going to need further analysis and formal responses. Remember that the values for this matrix (and the probability and impact scales discussed earlier) are determined prior to the start of this process and documented in the risk management plan. Also keep in mind that probability and impact do not have to be assigned the same values as I've done here. You might use 0.8, 0.6, 0.4, and 0.2 for probability, for example, and assign .05, 0.1, .03, 0.5, and 0.7 for impact scales.
The data quality assessment involves determining the usefulness of the data gathered to evaluate risk. Most important, the data must be unbiased and accurate. You will want to examine elements such as the following when using this tool and technique:
The quality of the data used
The availability of data regarding the risks
How well the risk is understood
The reliability and integrity of the data
The accuracy of the data
Low-quality data will render the results from the Perform Qualitative Risk Analysis process almost useless. Spend the time to validate and verify the information you've collected about risks so that your prioritization and analysis is as accurate as it can be. If you find that the quality of the data is questionable, you guessed it—go back and get better data.
This tool and technique is used to determine the effects risk has on the project. You can examine not only the categories of risk determined during the Plan Risk Management process (and described in the RBS) but also the project phase and the WBS to determine the elements of the project that are affected by risk.
Using this tool you'll determine how soon the potential risk events might occur and quickly determine responses for those risk events that could occur soon. You should consider the risk triggers, the time to develop and implement a response, and the overall risk rating when determining how quickly responses are needed.
Because this process determines qualitative values, by its very nature you must rely on expert judgment to determine the probability, impact, and other information we've derived so far. The more knowledge and similar experience your experts have, the better your assessments will be. Interviews and facilitated workshops are two techniques you can use in conjunction with expert judgment to perform this process. As with the Identify Risks process, make certain to take into account any bias your experts have and to correct it when necessary.
The goal of the Perform Qualitative Risk Analysis process is to rank the risks and determine which ones need further analysis and, eventually, risk response plans. The output of this process is risk register updates. According to the PMBOK® Guide, you'll update the register with the following information:
Risk ranking (or priority) for the identified risks
Risks grouped by categories
Causes of risk
List of risks requiring near-term responses
List of risks that need additional analysis and response
Watch list of low-priority risks
Trends in qualitative risk analysis results
Each element becomes a new entry in the risk register. For example, risk ranking assigns the risk score or priority you determined using the probability and impact matrix to the list of identified risks previously recorded in the risk register. I discussed the categories and the list of risks requiring near-term responses earlier. Note these in the risk register.
You'll also note those risks that require further analysis (including using the Perform Quantitative Risk Analysis process), you'll create a list of risks that have low risk scores to review periodically, and you should note any trends in Perform Qualitative Risk Analysis that become evident as you perform this process.
The Perform Quantitative Risk Analysis process evaluates the impacts of risk prioritized during the Perform Qualitative Risk Analysis process and quantifies risk exposure for the project by assigning numeric probabilities to each risk and their impacts on project objectives. This quantitative approach is accomplished using techniques such as Monte Carlo simulation and decision tree analysis. To paraphrase the PMBOK® Guide, the purpose of this process is to perform the following:
Quantify the project's possible outcomes and probabilities.
Determine the probability of achieving the project objectives.
Identify risks that need the most attention by quantifying their contribution to overall project risk.
Identify realistic and achievable schedule, cost, or scope targets.
Determine the best project management decisions possible when outcomes are uncertain.
Perform Quantitative Risk Analysis—like Perform Qualitative Risk Analysis—examines each risk and its potential impact on the project objectives. You might choose to use both of these processes to assess all risks or only one of them, depending on the complexity of the project and the organizational policy regarding risk planning. The Perform Quantitative Risk Analysis process can follow either the Identify Risks process or the Perform Qualitative Risk Analysis process. If you do use this process, be certain to repeat it every time the Plan Risk Responses process is performed and as part of the Monitor and Control Risks process so that you can determine if overall project risk has decreased.
I've already covered many of the inputs to the Perform Quantitative Risk Analysis process in previous sections of this chapter. They are as follows:
Risk register
Risk management plan
Cost management plan
Schedule management plan
Organizational process assets
The elements of the organizational process assets you'll want to pay close attention to as an input to this process are the historical information from previous projects, risk databases, and risk specialists studies performed on similar projects.
The Perform Quantitative Risk Analysis process includes three tools and techniques: data gathering and representation techniques, Quantitative Risk Analysis and modeling techniques, and expert judgment.
The data gathering techniques include interviewing techniques and probability distributions.
This technique is like the interviewing technique discussed earlier in the section "Identifying Potential Risk." Project team members, stakeholders, and subject-matter experts are prime candidates for risk interviews. Ask them about their experiences on past projects and about working with the types of technology or processes you'll use during this project.
Note
For the exam, remember that interviewing is a tool and technique of the Perform Quantitative Risk Analysis process. Although you can use this technique in the Identify Risks process, remember that it's part of the data gathering and representation technique and not a named tool and technique itself.
When using this technique, you should first determine what methods of probability distribution (described next) you'll use to analyze your information. The technique you choose will dictate the type of information you need to gather. For example, you might use a three-point scale that assesses the low, high, and most likely risk scenarios or take it a step further and use standard deviations calculations.
Make certain you document how the interviewees decided upon the risk ranges, the criteria they used to place risks in certain categories, and the results of the interview. This will help you later in developing risk responses as well.
It's beyond the scope of this book to delve into probability distributions and calculations, so I'll point out a few aspects of them that you should remember for the exam.
Continuous probability distributions (particularly beta and triangular distributions) are commonly used in Perform Quantitative Risk Analysis. According to the PMBOK® Guide, continuous probability distributions include normal, lognormal, triangular, beta, and uniform distributions. Distributions are graphically displayed and represent both the probability and time or cost elements.
Triangular distributions use estimates based on the three-point estimate (the pessimistic, most likely, and optimistic values). This means that during your interviews, you'll gather these pieces of information from your experts. Then you'll use them to quantify risk for each WBS element.
Normal and lognormal distributions use mean and standard deviations to quantify risk, which also require gathering the optimistic, most likely, and pessimistic estimates.
Discrete distributions represent possible scenarios in a decision tree (we'll discuss this in the next section), outcomes of a test, results of a prototype, and other uncertain events.
There are four analysis and modeling techniques within the Quantitative Risk Analysis tool and technique you should know for the exam: sensitivity analysis, expected monetary value analysis, decision tree analysis, and modeling and simulation. Let's take a brief look at each of them.
Sensitivity analysis is a quantitative method of analyzing the potential impact of risk events on the project and determining which risk event (or events) has the greatest potential for impact by examining all the uncertain elements at their baseline values. One of the ways sensitivity analysis data is displayed is a tornado diagram. Figure 6.5 shows a sample tornado diagram.
You can see by the arrangement of horizontal bars (each representing a sensitivity variable) how the diagram gets its name. The idea is that each sensitivity bar displays the low and high value possible for the element the bar represents. It's beyond the scope of this book to explain how these values are determined. The questions you might encounter on the exam are focused on the context of this type of analysis. The variables with the greatest effect on the project appear at the top of the graph and decrease in impact as you progress down through the graph. This gives you a quick overview of how much the project can be affected by uncertainty in the various elements. It also allows you to see at a glance which risks might have the biggest impacts on the project and will require carefully crafted, detailed response plans. You can use tornado diagrams to determine sensitivity in cost, time, and quality objectives or for risks you've identified during this process. Sensitivity analysis can also be used to determine stakeholder risk tolerance levels.
Expected monetary value (EMV) analysis is a statistical technique that calculates the average, anticipated future impact of the decision. EMV is calculated by multiplying the probability of the risk by its impact for two or more potential outcomes (for example, a good outcome and a poor outcome) and then adding the results of the potential outcomes together. EMV is used in conjunction with the decision tree analysis technique, which is covered next. I'll give you an example of the EMV formula in the next section. Positive results generally mean the risks you're assessing pose opportunities to the project, while negative results generally indicate a threat to the project.
Unfortunately, this isn't a tree outside your office door that produces "yes" and "no" leaves that you can pick to help you make a decision. Decision trees are diagrams that show the sequence of interrelated decisions and the expected results of choosing one alternative over the other. Typically, more than one choice or option is available when you're faced with a decision or, in this case, potential outcomes from a risk event. The available choices are depicted in tree form starting at the left with the risk decision branching out to the right with possible outcomes. Decision trees are usually used for risk events associated with time or cost.
Figure 6.6 shows a sample decision tree using expected monetary value (EMV) as one of its inputs.
The expected monetary value of the decision is a result of the probability of the risk event multiplied by the impact for two or more potential outcomes and then summing their results. The squares in this figure represent decisions to be made, and the circles represent the points where risk events might occur.
The decision with an expected value of $7,000 is the correct decision to make because the resulting outcome has the greatest value.
Modeling and simulation techniques are often used for schedule risk analysis and cost analysis. For example, modeling allows you to translate the potential risks at specific points in the project into their impacts so you can determine how the project objectives are affected. Simulation techniques compute the project model using various inputs, such as cost or schedule duration, to determine a probability distribution for the variable chosen. (Cost risks typically use either a work breakdown structure or a cost breakdown structure as the input variable. Schedule risks always use the precedence diagramming method as the input variable. I'll cover schedule diagramming methods in Chapter 7.) If you used simulation techniques to determine project cost and use the cost of the project elements as the input variable, a probability distribution for the total cost of the project would be produced after running the simulation numerous times. Modeling and simulation techniques examine the identified risks and their potential impacts to the project objectives from the perspective of the whole project.
Monte Carlo analysis is an example of a simulation technique. Monte Carlo analysis is replicated many times, typically using cost or schedule variables. Every time the analysis is performed, the values for the variable are changed using a probability distribution for each variable. Monte Carlo analysis can also be used during the Schedule Development process.
I've talked about this tool and technique before. Experts can come from inside or outside the organization and should have experience that's applicable to your project. For example, if your project involves manufacturing a new product or part, you might want to consider experts such as engineers or statisticians. If you're dealing with sensitive data in an information technology project, consider bringing in a security expert.
The output of the Perform Quantitative Risk Analysis process is—I'll bet you can guess—risk register updates. As with the Perform Qualitative Risk Analysis process, you'll record the following new elements in the risk register:
- Probabilistic analysis of the project
Probabilistic analysis of the project is the forecasted results of the project schedule and costs as determined by the outcomes of risk analysis. These results include projected completion dates and costs, along with a confidence level associated with each. According to the PMBOK® Guide, this output is often expressed as a cumulative distribution, and you'll use these results along with stakeholder risk tolerances to quantify the time and cost contingency reserves. (I'll talk about contingency reserves in the next section, "Developing a Risk Response Plan.")
Confidence levels can also be used to describe the level of confidence placed on the outcome of the forecasted results. For example, suppose the projected schedule completion date is July 12 and the confidence level is .85. This says you believe the project will finish on or before July 12 and that you have an 85 percent level of confidence that this date is accurate.
- Probability of achieving the cost and time objectives
Using the tools and techniques of Perform Quantitative Risk Analysis allows you to assign a probability of achieving the cost and time objectives of the project. This output documents those probabilities and as such requires a thorough understanding of the current project objectives and knowledge of the risks.
- Prioritized list of quantified risks
The prioritized list in this process is similar to the list produced during the Perform Qualitative Risk Analysis process. The list of risks includes those that present the greatest risk or threat to the project and their impacts. It also lists those risks that present the greatest opportunities to the project. This list should also indicate which risks are most likely to impact the critical path and those that have the largest cost contingency.
- Trends in Perform Quantitative Risk Analysis results
Trends in Perform Quantitative Risk Analysis will likely appear as you repeat the risk analysis processes. This information is useful as you progress, making those risks with the greatest threat to the project more evident, which gives you the opportunity to perform further analysis or go on to develop risk response plans.
The Plan Risk Responses process is the last process covered in this chapter. (I hear you cheering out there!) Plan Risk Responses is a process of deciding what actions to take to reduce threats and take advantage of the opportunities discovered during the risk analysis processes. This process also includes assigning departments or individual staff members the responsibility of carrying out the risk response plans you'll outline in this process. These folks are known as risk owners.
Note
The more effective your risk response plans are, the better your chances for a successful project. Well-developed and well-written risk response plans will likely decrease overall project risk.
Generally, you'll want to develop risk response plans for those risks with a combination of high probability of occurrence and significant impact to the project, those ranked high (or red) on the probability/impact matrix, or those ranked high as a result of Perform Quantitative Risk Analysis. Developing risk response plans for risks of low severity or insignificant impact is not an efficient or good use of the project team's time. Spend your time planning responses that are appropriate given the impact the risk itself poses (or the opportunity the risk presents), and don't spend more time, money, or energy to produce a response than the risk event itself would produce if it occurred.
The inputs you'll use to assist you in this process are the risk register and the risk management plan. Several strategies are used in this process to reduce or control risk. It's important that you choose the right strategy for each risk so that the risk and its impacts are dealt with effectively. After deciding on which strategy to use, you'll develop an action plan to put this strategy into play should the risk event occur. You might also choose to designate a secondary or backup strategy.
The Plan Risk Responses process consists of four tools and techniques, and each one of them involves a strategy. The tools and techniques are as follows:
Strategies for negative risks or threats
Strategies for positive risks or opportunities
Contingent response strategy
Expert judgment
You'll take a look at the first three next.
Four strategies exist to deal with negative risks or threats to the project objectives. They are avoid, transfer, mitigate, and accept.
To avoid a risk means you'll evade it altogether, eliminate the cause of the risk event, or change the project plan to protect the project objectives from the risk event. Let's say you're going to take a car trip from your home to a point 800 miles away. You know—because your friends who just took the same trip told you—that there is a long stretch of construction on one of the highways you're planning on using. To avoid the risk of delay, you plan the trip around the construction work and use another highway for that stretch of driving. In this way, you change your plans, avoid the risk of getting held up in construction traffic, and arrive at your destination on time.
With risk avoidance, you essentially eradicate the risk by eliminating its cause. Here's another example: Suppose your project was kicked off without adequate scope definition and requirements gathering. You run a high probability of experiencing scope creep—ever-changing requirements—as the project progresses, thus impacting the project schedule. You can avoid this risk by adequately documenting the project scope and requirements during the Planning processes and taking steps to monitor and control changes to scope so it doesn't get out of hand.
Risks that occur early in the project might easily be avoided by improving communications, refining requirements, assigning additional resources to project activities, refining the project scope to avoid risk events, and so on.
The idea behind a risk transfer is to transfer the risk and the consequences of that risk to a third party. The risk hasn't gone away, but the responsibility for the management of that risk now rests with another party. Most companies aren't willing to take on someone else's risk without a little cash thrown in for good measure. This strategy will impact the project budget and should be included in the cost estimate exercises if you know you're going to use it.
Transfer of risk can occur in many forms but is most effective when dealing with financial risks. Insurance is one form of risk transfer. You are probably familiar with how insurance works. Car insurance is a good example. You purchase car insurance so that if you come upon an obstacle in the road and there is no way to avoid hitting it, the cost to repair the damage to the car is paid by the insurance company...OK, minus the deductible and all the calculations for the age of the car, the mileage, the color and make of the car, the weather conditions the day you were driving—but I digress.
Another method of risk transfer is contracting. Contracting transfers specific risks to the vendor, depending on the work required by the contract. The vendor accepts the responsibility for the cost of failure. Again, this doesn't come without a price. Contractors charge for their services, and depending on the type of contract you negotiate, the cost might be quite high. For example, in a fixed-price contract, which I'll talk more about in Chapter 7, the vendor (or seller) increases the cost of the contract to compensate for the level of risk they're accepting. A cost reimbursable contract, however, leaves the majority of the risk with you, the buyer. This type of contract might reduce costs if there are project changes midway through the project.
Keep in mind that contracting isn't a cure-all. You might just be swapping one risk for another. For example, say you hire a driver to go with you on your road trip, and that person's job is to do all the driving. If the driver becomes ill or in some way can't fulfill their obligation, you aren't going to get to your destination on time. You've placed the risks associated with the trip on the contract driver; however, you've taken on a risk of delay because of nonperformance, which means you've just swapped one risk for another. You'll have to weigh your options in cases like this and determine which side of the risk coin your organization can more readily accept.
Other forms of transference include warranties, guarantees, and performance bonds.
When you mitigate a risk, you attempt to reduce the probability of a risk event and its impacts to an acceptable level. This strategy is a lot like defensive driving. You see an obstacle in the road ahead, survey your options, and take the necessary steps to avoid the obstacle and proceed safely on your journey. Seeing the obstacle ahead (identifying risk) allows you to reduce the threat by planning ways around it or planning ways to reduce its impact if the risk does occur (mitigation strategies).
According to the PMBOK® Guide, the purpose of mitigation is to reduce the probability that a risk will occur and reduce the impact of the risk to a level where you can accept the risk and its outcomes. It's easier to take actions early on that will reduce the probability of a risk or its consequences than it is to fix the damage once it has occurred. Some examples of risk mitigation include performing more tests, using less complicated processes, creating prototypes, and choosing more reliable vendors.
The acceptance strategy is used when you aren't able to eliminate all the threats on the project. Acceptance of a risk event is a strategy that can be used for risks that pose either threats or opportunities to the project. Passive acceptance is a strategy that means you won't make any plans to try to avoid or mitigate the risk. You're willing to accept the consequences of the risk should it occur. Acceptance might also mean the project team was unable to come up with an adequate response strategy and must accept the risk and its consequences. Active acceptance might include developing contingency reserves to deal with risks should they occur. (You'll look at contingency reserves in the next section.)
Let's revisit the road trip example. You could plan the trip using the original route and just accept the risk of running into construction. If you get to that point and you're delayed, you'll just accept it. This is passive acceptance. You could also go ahead and make plans to take an alternate route but not enact those plans until you actually reach the construction and know for certain that it is going to impede your progress. This is active acceptance and might involve developing a contingency plan.
Four strategies exist to deal with opportunities or positive risks that might present themselves on the project: exploit, share, enhance and accept. We already covered accept, so we'll look at the remaining strategies next.
When you exploit a risk event, you're looking for opportunities for positive impacts. This is the strategy of choice when you've identified positive risks that you want to make certain will occur on the project. Examples of exploiting a risk include reducing the amount of time to complete the project by bringing on more qualified resources or by providing even better quality than originally planned.
The share strategy is similar to transferring because you'll assign the risk to a third-party owner who is best able to bring about the opportunity the risk event presents. For example, perhaps what your organization does best is investing. However, it isn't so good at marketing. Forming a joint venture with a marketing firm to capitalize on a positive risk will make the most of the opportunities.
The last tool and technique of the Plan Risk Responses process is called the contingent response strategy, better known as contingency planning. Contingency planning involves planning alternatives to deal with the risks should they occur. This is different from mitigation planning in that mitigation looks to reduce the probability of the risk and its impact, whereas contingency planning doesn't necessarily attempt to reduce the probability of a risk event or its impacts. Contingency planning says the risk might very well occur, and you better have plans in place to deal with it when it does.
Contingency comes into play when the risk event occurs. This implies you need to plan for your contingencies well in advance of the threat occurring. After the risks have been identified and quantified, contingency plans should be developed and kept at the ready.
Contingency allowances or reserves are a common contingency response. Contingency reserves include project funds that are held in reserve to offset any unavoidable threats to project scope, schedule, cost, or quality. It also includes reserving time and resources to account for risks. You should consider stakeholder risk tolerances when determining the amount of contingency reserves.
Fallback plans should be developed for risks with high impact or for risks with identified strategies that might not be the most effective at dealing with the risk.
In practice, you'll find that identifying, prioritizing, quantifying, and developing responses for potential threats might happen simultaneously. In any case, you don't want to be taken by surprise, and that's the point of the risk processes. If you know about potential risks early, you can often mitigate them or prepare appropriate response plans or contingency plans to deal with them.
As you've no doubt concluded, the purpose of the Plan Risk Responses process is to develop risk responses for those risks with the highest threat to or best opportunity for the project objectives. The Plan Risk Responses process has four outputs: risk register updates, risk-related contract decisions, project management plan updates, and project document updates.
Note
Remember that you might need to revisit other Planning processes after performing Plan Risk Responses to modify project plans as a result of risk responses.
Again, the risk register is updated at the end of this process with the information you've discovered during this process. The response plans are recorded in the risk register. You'll recall that the risk register lists the risk in order of priority (those with the highest potential for threat or opportunity first), so it makes sense that the response plans you have for these risks will be more detailed than the remaining lists. Some risks might not require response plans at all, but you should put them on a watch list and monitor them throughout the project.
Let's take a look at what the risk register should contain at this point. According to the PMBOK® Guide, after Identify Risks, Perform Qualitative Risk Analysis, and Perform Quantitative Risk Analysis are preformed, the following elements should appear in the risk register:
Prioritized list of identified risks, including their descriptions, what WBS element they impact (or area of the project), categories (RBS), root causes, and how the risk impacts the project objectives
Risk ranking
Risk owners and their responsibility
Outputs from the Perform Qualitative Analysis
Agreed-upon response strategies
Actions needed to implement response plans
Cost and schedule activities needed to implement risk responses
Contingency plans
Fallback plans
Contingency reserves
The only elements in the preceding list I haven't talked about so far are residual and secondary risks. A residual risk is a leftover risk, so to speak. After you've implemented a risk response strategy—say mitigation, for example—some minor risk might still remain. The contingency reserve is set up to handle situations like this.
Secondary risks are risks that come about as a result of implementing a risk response. The example given previously where you transferred risk by hiring a driver to take you to your destination but the person became ill along the way is an example of a secondary risk. The driver's illness delayed your arrival time, which is a risk directly caused by hiring the driver or implementing a risk response. When planning for risk, identify and plan responses for secondary risks.
If you're planning on using strategies such as transference or sharing, for example, you might need to purchase services or items from third parties. You can prepare the contracts for those services now and discuss them with the appropriate parties.
Risks exist on all projects, and risk planning is an important part of the project Planning processes. Just the act of identifying risks and planning responses can decrease their impact if they occur. Don't take the "What I don't know won't hurt me" approach to risk planning. This is definitely a case where not knowing something can be devastating. Risks that are easily identified and have planned responses aren't likely to kill projects or your career. Risks that you should have known about but ignored could end up costing the organization thousands or millions of dollars, causing schedule delays, causing loss of competitive advantage, or ultimately killing the project. There could be a personal cost as well, because cost and schedule overruns due to poor planning on your part are not easily explained.
As we've discussed throughout the book, the management plans created that document how the schedule, budget, quality, procurement, and human resources will be defined, managed, and controlled on the project become subsidiary plans to the project management plan. Any and all of these management plans may require updates after you perform the risk processes. In addition, the WBS, the schedule baseline, and cost performance baseline may require updates as well.
Other project documents, such as technical documentation and the assumptions documented in project scope statement, could need an update after performing these processes as well.
Risk management and all the processes it involves is not a process I recommend you skip on any size of project. This is where the Boy Scouts of America motto, "Be Prepared" is wise advice. If you haven't examined what could be lurking around the corner on your project and come up with a plan to deal with it, then you can be assured you're in for some surprises. Then again, if you like living on the edge, never knowing what might occur next, you'll probably find yourself back on the job-hunting scene sooner than you planned (oh, wait, you didn't plan because you're living on the edge).
In all seriousness, as with most of the Planning processes I've discussed so far, risk management should be scaled to match the complexity and size of your project. If you're working on a small project with a handful of team members and a short timeline, it doesn't make sense to spend a lot of time on risk planning. However, it does warrant spending some time identifying project risk, determining impact and probability, and documenting a plan to deal with the risk.
My two favorite Identify Risks techniques are brainstorming and the Nominal Group Technique. Both techniques help you quickly get to the risks with the greatest probability and impact because, more than likely, these are the first risks that come to mind. Identify Risks can also help the project team find alternative ways of completing the work of the project. Further digging and the ideas generated from initial identification might reveal opportunities or alternatives you wouldn't have thought about during the regular Planning processes.
After you've identified the risks with the greatest impact to the project, document response plans that are appropriate for the risk. Small projects might have only one or two risks that need a response plan. The plans might consist of only a sentence or two, depending on the size of the project. I would question a project where no risks require a response plan. If it seems too good to be true, it probably is.
The avoid, transfer, and mitigate strategies are the most often used strategies to deal with risk, along with contingency planning. Of these, mitigation and contingency planning are probably the most common. Mitigation generally recognizes that the risk will likely occur and attempts to reduce the impact.
I have used brainstorming and the Nominal Group Technique to strategize response plans for risks on small projects. When you're working on a small project, you can typically identify, quantify, and create response plans for risks at one meeting.
Identifying positive risk, in my experience, is fairly rare. Typically, when my teams perform Identify Risks, it's to determine what can go wrong and how bad the impact will be if it does. The two most important concepts from this chapter that you should apply to your next project are that you and your team should identify risks and create response plans to deal with the most significant ones.
Congratulations! You've completed another fun-filled, action-packed chapter, and all of it on a single topic—risk. Risk is inherent in all projects, and risks pose both threats and opportunities to the project. Understanding the risks facing the project better equips you to determine the appropriate strategies to deal with those risks and helps you determine the response plans for the risks (and the level of effort you should put into preparing those plans).
The Plan Risk Management process determines how you will plan for risks on your project. Its only output is the risk management plan, which details how you'll define, monitor, and control risks throughout the project. The risk management plan is a subsidiary of the project management plan.
The Identify Risks process seeks to identify and document the project risks using information-gathering techniques like brainstorming, the Nominal Group technique the Delphi technique, interviewing, and root cause identification. This list of risks gets recorded in the risk register, the only output of this process.
Perform Qualitative Risk Analysis and Perform Quantitative Risk Analysis involve evaluating risks and assigning probability and impact values to the risks. Many tools and techniques are used during these processes, including risk probability and impact, probability and impact matrix, interviewing, probability distributions, expert judgment, sensitivity analysis, decision tree analysis, and simulation.
A probability and impact matrix uses the probability multiplied by the impact value to determine the risk score. The threshold of risk based on high, medium, and low tolerances is determined by comparing the risk score based on the probability level to the probability and impact matrix.
Monte Carlo simulation is a technique used to quantify schedule or cost risks. Decision trees graphically display decisions and their various choices and outcomes and is typically used in combination with earned monetary value.
The Plan Risk Responses process is the last Planning process and culminates with an update to the risk register documenting the risk response plans. The risk response plans detail the strategies you'll use to respond to risk and assign individuals to manage each risk response. Risk response strategies for negative risks include avoidance, mitigation, and transference. Risk strategies for positive risks include exploit, share, and enhance. Acceptance is a strategy for both negative and positive risks.
Contingency planning involves planning alternatives to deal with risk events should they occur. Contingency reserves are set aside to deal with risks associated with cost and time according to the stakeholder tolerance levels.
- Be able to define the purpose of the risk management plan
The risk management plan describes how you will define, monitor, and control risks throughout the project. It details how risk management processes (including Identify Risks, Perform Qualitative Risk Analysis, Perform Quantitative Risk Analysis, Plan Risk Responses, and Monitor and Control Risks) will be implemented, monitored, and controlled throughout the life of the project. It describes how you will manage risks but does not attempt to define responses to individual risks. The risk management plan is a subsidiary of the project management plan, and it's the only output of the Plan Risk Management process.
- Be able to name the purpose of Identify Risks
The purpose of the Identify Risks process is to identify all risks that might impact the project, document them, and identify their characteristics.
- Be able to define the purpose of Perform Qualitative Risk Analysis
Perform Qualitative Risk Analysis determines the impact the identified risks will have on the project and the probability they'll occur, and it puts the risks in priority order according to their effects on the project objectives.
- Be able to define the purpose of Perform Quantitative Risk Analysis
Perform Quantitative Risk Analysis evaluates the impacts of risk prioritized during the Perform Qualitative Risk Analysis process and quantifies risk exposure for the project by assigning numeric probabilities to each risk and their impacts on project objectives.
- Be able to define the purpose of the Plan Risk Responses process
Plan Risk Responses is the process where risk response plans are developed using strategies such as avoid, transfer, mitigate, accept, exploit, share, enhance, develop contingent response strategies, and apply expert judgment. The risk response plan describes the actions to take should the identified risks occur. It should include all the identified risks, a description of the risks, how they'll impact the project objectives, and the people assigned to manage the risk responses.
- Be able to define the risk register and some of its primary elements
The risk register is an output of the Identify Risks process, and updates to the risk register occur as an output of every risk process that follows this one. By the end of the Plan Risk Responses process, the risk register contains these primary elements: identified list of risks, risk owners, risk triggers, risk strategies, contingency plans, and contingency reserves.
Life is a risky business, but with proper planning, your project doesn't have to be. Using processes I've discussed in this chapter, you'll be prepared for the foreseeable and the not so foreseeable. Understand them well, and know each process by the name used in the PMBOK® Guide:
Perform Qualitative Risk Analysis | Plan Risk Management |
Perform Quantitative Risk Analysis | Plan Risk Responses |
Identify Risks |
Before you take the exam, also be certain you are familiar with the following terms:
acceptance | Monte Carlo analysis |
avoid | Nominal Group Technique |
brainstorming | ordinal scale |
cardinal scale | passive acceptance |
cause-and-effect diagrams | probability |
contingency planning | probability and impact matrix |
contingency reserves | residual risk |
decision trees | risk breakdown structure (RBS) |
Delphi technique | risk categories |
Enhance | risk management plan |
expected monetary value (EMV) | risk register |
exploit | risk tolerance |
force majeure | secondary risks |
impact | sensitivity analysis |
impact scale | share |
influence diagramming | tornado diagram |
interviews | transfer |
mitigate | triggers |
You are a project manager for Fountain of Youth Spring Water bottlers. Your project involves installing a new accounting system, and you're performing the risk-planning processes. You have identified several problems along with the causes of those problems. Which of the following diagrams will you use to show the problem and its causes and effects?
Decision tree diagram
Fishbone diagram
Benchmark diagram
Simulation tree diagram
Assessing the probability and consequences of identified risks to the project objectives, assigning a risk score to each risk, and creating a list of prioritized risks describes which of the following processes?
Perform Quantitative Risk Analysis
Identify Risks
Perform Qualitative Risk Analysis
Plan Risk Management
Each of the following statements is true regarding the risk management plan except for which one?
The risk management plan is an output of the Plan Risk Management process.
The risk management plan includes a description of the responses to risks and triggers.
The risk management plan includes thresholds, scoring and interpretation methods, responsible parties, and budgets.
The risk management plan is an input to all the remaining risk-planning processes.
You are using the interviewing technique of the Perform Quantitative Risk Analysis process. You intend to use normal and lognormal distributions. All of the following statements are true regarding this question except which one?
Interviewing techniques are used to quantify the probability and impact of the risks on project objectives.
Normal and lognormal distributions use mean and standard deviation to quantify risks.
Distributions graphically display the impacts of risk to the project objectives.
Triangular distributions rely on optimistic, pessimistic, and most likely estimates to quantify risks.
The information-gathering techniques used in the Identify Risks process include all of the following except ___________________.
toot cause analysis
the Delphi technique
brainstorming
checklist analysis
Which of the following processes assesses the likelihood of risk occurrences and their consequences using a numerical rating?
Perform Qualitative Risk Analysis
Identify Risks
Perform Quantitative Risk Analysis
Plan Risk Responses
You are the project manager for a new website for the local zoo. You need to perform the Perform Qualitative Risk Analysis process. When you've completed this process, you'll produce all of the following as part of the risk register update output except which one?
Priority list of risks
Watch list of low-priority risks
Probability of achieving time and cost estimates
Risks grouped by categories
You've identified a risk event on your current project that could save $100,000 in project costs if it occurs. Which of the following is true based on this statement? (Choose the best answer.)
This is a risk event that should be accepted because the rewards outweigh the threat to the project.
This risk event is an opportunity to the project and should be exploited.
This risk event should be mitigated to take advantage of the savings.
This a risk event that should be avoided to take full advantage of the potential savings.
You've identified a risk event on your current project that could save $500,000 in project costs if it occurs. Your organization is considering hiring a consulting firm to help establish proper project management techniques in order to assure it realizes these savings. Which of the following is true based on this statement? (Choose the best answer.)
This is a risk event that should be accepted because the rewards outweigh the threat to the project.
This risk event is an opportunity to the project and should be exploited.
This risk event should be mitigated to take advantage of the savings.
This a risk event that should be shared to take full advantage of the potential savings.
Your hardware vendor left you a voicemail saying that a snowstorm in the Midwest might prevent your equipment from arriving on time. She wanted to give you a heads-up and asked that you return the call. Which of the following statements is true? (Choose the best answer.)
This is a trigger.
This is a contingency plan.
This is a residual risk.
This is a secondary risk.
You are constructing a probability and impact matrix for your project. Which of the following statements is true?
The probability and impact matrix multiplies the risk's probability by the cost of the impact to determine an expected value of the risk event.
The probability and impact matrix multiplies the risk's probability—which fall from 0.0 to 1.0—and the risk's impact for each potential outcome and then adds the result of the potential outcomes together to determine a risk score.
The probability and impact matrix are predetermined thresholds that use the risk's probability multiplied by the impact of the risk event to determine an overall risk score.
The probability and impact matrix multiplies the risk's probability by the risk impact—which both fall from 0.0 to 1.0—to determine a risk score.
Your stakeholders have asked for an analysis of the cost risk. All of the following are true except for which one?
Monte Carlo analysis is the preferred method to use to determine the cost risk.
Monte Carlo analysis is a modeling technique that computes project costs one time.
A traditional work breakdown structure can be used as an input variable for the cost analysis.
Monte Carlo usually expresses its results as probability distributions of possible costs.
Your hardware vendor left you a voicemail saying that a snowstorm in the Midwest will prevent your equipment from arriving on time. You identified a risk response strategy for this risk and have arranged for a local company to lease you the needed equipment until yours arrives. This is an example of which risk response strategy?
Transfer
Acceptance
Mitigate
Avoid
All of the following are elements of the enterprise environmental factors input of the Identify Risks process that you should evaluate except for which one?
Assumptions analysis
Industry studies
Benchmarking
Risk attitudes
You work for a large manufacturing plant. You are working on a new project to release an overseas product line. This is the company's first experience in the overseas market, and it wants to make a big splash with the introduction of this product. The stakeholders are a bit nervous about the project and historically proceed cautiously and take a considerable amount of time to examine information before making a final decision. The project entails producing your product in a concentrated formula and packaging it in smaller containers than the U.S. product uses. A new machine is needed in order to mix the ingredients into a concentrated formula. After speaking with one of your stakeholders, you discover this will be the first machine your organization has purchased from your new supplier. Which of the following statements is true given the information in this question?
The question describes risk tolerance levels of the stakeholders, which should be considered when performing the Plan Risk Management process.
This question describes the interviewing tool and technique used during the Identify Risks process.
This question describes risk triggers that are derived using interviewing techniques and recorded in the risk register during the Perform Qualitative Risk Analysis process.
This question describes a risk that requires a response strategy from the positive risk category.
Your project team has identified several potential risks on your current project that could have a significant impact if they occurred. The team examined the impact of the risks by keeping all the uncertain elements at their baseline values. What type of diagram will the team use to display this information?
Fishbone diagram
Tornado diagram
Influence diagram
Process flowchart
Your project team is in the process of identifying project risks on your current project. The team has the option to use all of the following tools and techniques to diagram some of these potential risks except for which one?
Ishikawa diagram
Decision tree diagram
Process flowchart
Influence diagram
All of the following statements are true regarding the RBS except for which one?
The RBS is contained in the risk management plan.
It describes risk categories, which are a systematic way to identify risks and provide a foundation for understanding for everyone involved on the project.
The lowest level of the RBS can be used as a checklist, which is a tool and technique of the Identify Risks process.
The RBS is similar to the WBS in that the lowest levels of both are easily assigned to a responsible party or owner.
Your team has identified the risks on the project and determined their risk score. The team is in the midst of determining what strategies to put in place should the risks occur. After some discussion, the team members have determined that the risk of losing their network administrator is a risk they'll just deal with if and when it occurs. Although they think it's a possibility and the impact would be significant, they've decided to simply deal with it after the fact. Which of the following is true regarding this question?
This is a negative response strategy.
This is a positive response strategy.
This is a response strategy for either positive or negative risk known as contingency planning.
This is a response strategy for either positive or negative risks known as passive acceptance.
All of the following are true regarding the Perform Qualitative Risk Analysis process except which one?
Probability and impact and expert interviews are used to help correct biases that occur in the data you've gathered during this process.
The probability and impact matrix is used during this process to assign red, yellow, and green conditions to risks.
Perform Qualitative Risk Analysis is an easy method of determining risk probability and impact that usually takes a good deal of time to perform.
Risk urgency assessment is a tool and technique of this process used to determine which risks need near-term response plans.
B. The cause-and-effect flowcharts—also called fishbone diagrams or Ishikawa diagrams—show the relationship between the causes and effects of problems.
C. The purpose of Perform Qualitative Risk Analysis is to determine what impact the identified risk events will have on the project and the probability they'll occur. It also puts risks in priority order according to their effects on the project objectives and assigns a risk score for the project.
B. The risk management plan details how risk management processes will be implemented, monitored, and controlled throughout the life of the project. The risk management plan does not include responses to risks or triggers. Responses to risks are documented in the risk register as part of the Plan Risk Responses process.
C. Distributions graphically display the probability of risk to the project objectives as well as the time or cost elements.
D. The information-gathering techniques in the Identify Risks process are brainstorming, the Delphi technique, interviewing, and root cause analysis.
C. Perform Quantitative Risk Analysis analyzes the probability of risks and their consequences using a numerical rating. Perform Qualitative Risk Analysis might use numeric ratings but can use a high-medium-low scale as well.
C. Probability of achieving time and cost estimates is an update that is produced from the Perform Quantitative Risk Analysis process.
B. This risk event has the potential to save money on project costs, so it's an opportunity, and the appropriate strategy to use in this case is the exploit strategy.
D. This risk event has the potential to save money on project costs. Sharing involves using a third party to help assure that the opportunity take place.
A. The best answer is A. Triggers are warning signs of an impending risk event.
C. The probability and impact matrix multiplies the probability and impact to determine a risk score. Using this score and a predetermined matrix, you determine if the scores is a high, medium, or low designation.
B. Monte Carlo analysis is a simulation technique that computes project costs many times in an iterative fashion.
C. Mitigation attempts to reduce the impact of a risk event should it occur. Making plans to arrange for the leased equipment reduces the consequences of the risk.
A. Assumptions analysis is a tool and technique of the Identify Risks process.
A. This question describes risk tolerance levels of the stakeholders. Risk triggers are recorded in the risk register during the Plan Risk Responses process. The risk of buying a machine from a new supplier would pose a threat to the project, not an opportunity. Interviewing might have been used, but this question wasn't describing the Identify Risks process.
B. The question describes sensitivity analysis, which is a tool and technique of the Perform Quantitative Risk Analysis process. Tornado diagrams are often used to display sensitivity analysis data.
B. Decision tree diagrams are used during the Perform Quantitative Risk Analysis process. All the other options are diagramming techniques used in the Identify Risks process.
D. The RBS describes risk categories, and the lowest level can be used as a checklist to help identify risks. Risk owners are not assigned from the RBS but typically are assigned as soon as the risk is identified.
D. This is a response strategy known as passive acceptance because the team has decided to take no action and make no plans for the risk. This is a strategy that can be used for either positive or negative risks.
C. Perform Qualitative Risk Analysis is a fast and easy method of determining probability and impact.