Chapter 11

Introducing Project Risk Management

CERTIFICATION OBJECTIVES

11.01   Planning for Risk Management

11.02   Identifying Risks

11.03   Using Qualitative Risk Analysis

11.04   Preparing for Quantitative Risk Analysis

11.05   Planning for Risk Responses

11.06   Implementing Risk Responses

11.07   Monitoring Risks

  Two-Minute Drill

Q&A     Self Test

Risk is everywhere. It’s inherent in the activities we choose—from driving a car to parachuting. Within a project, risks are unplanned events or conditions that can have positive or negative effects on a project’s success. Not all risks are bad, but almost all are seen as a threat. Even launching a project represents risk, because the project could succeed or fail—there’s uncertainty in the endeavor.

The risks that activities bring are an exchange for the benefits we get from accepting the risks. If a person chooses to jump out of a perfectly good airplane for the thrill of the fall, the exhilaration of the parachute opening, and the view of Earth rushing up, there is still a risk that the chute may not open—a risk that thrill-seekers are willing to accept.

Project managers, to some extent, are like thrill-seekers. Parachutists complete training, pack their chutes, check and double-check their equipment, and make certain there’s an emergency chute for those “just-in-case” scenarios. Project managers—good project managers—take a similar approach.

Risks in a project, should they come to fruition, can mean total project failure, increased costs, and extended project duration, among other things. Risk often has a negative connotation, but as it does for the parachutist, the acceptance of the risk can also offer a reward. For the parachutist, the risk is certain death—but the reward is the thrill of the activity. For project managers, risk can mean failure, but the reward can mean a time or cost savings as well as other benefits. After a risk event happens, it’s known as an issue. This chapter focuses on managing risks before they become issues.

Risk management is the process by which the project manager and project team identify project risks, analyze and rank them, and determine what actions, if any, need to be taken to avert these threats. Associated with this process are the costs, schedule, and quality concerns of the project brought about by the solutions to those risks. In addition, the reactions to risks are analyzed for any secondary risks that the solutions may have created.

In this chapter, we’ll discuss risk management planning, risk identification and analysis, response planning and implementation, and monitoring the identified risks. For the PMP exam, you’ll need to have a firm grasp of these concepts. You’ll be taking a real risk if you don’t know them well.

Building a Strong Risk Understanding

Risks in project management are either threats, which are negative risk events, or opportunities, which are positive risk events. Negative risk events are easy to see: loss of data, potential for injury, late resource delivery from a vendor. Positive risk events are sometimes cloudier to see, but they do exist. Consider investing in a faster piece of equipment, hiring a vendor to do a portion of the project work, or saving costs by paying in advance for a service the project needs. Positive risks are opportunities to save time, money, or effort, or to increase productivity. Some risks, positive or negative, are negligible and are documented and accepted, while other risk events need to be quantified, planned for, and closely monitored throughout the project.

There are two levels of risks in a project to consider:

   Individual project risks The risk events that can hinder or help the project reach its objectives

   Overall project risk The combination of all risk events that will reveal the project’s risk exposure and determine just how risky the project is for the organization

Generally, the higher the project priority, the more willing the organization is to spend time or money to address risk events. You’ll also consider business risks and pure risks in a project. Business risks can have an upside and a downside, such as investing in that new piece of equipment. Pure risks have only a downside, such as someone getting injured on the job site because they took a shortcut in the work process. Of course, we want to address negative risks at all costs because we don’t want people to be injured in the project.

Reviewing Project Risk Considerations

Stakeholder tolerance for risk is one of the first things you’ll need to know when you start a project. Risk tolerance, sometimes called the risk appetite, refers to the stakeholders’ willingness to take on risk events. The risk tolerance describes how much risk is acceptable in relation to the cost of addressing the risk event. Some projects and organizations have a high tolerance for risk—they readily take on risks, but their tolerance is in relation to the perceived reward the risk will bring them. It’s just like investing in the stock market—you could earn money or lose money. Do you buy all safe and solid stocks? Or do you invest in only startup companies and penny stocks? Or, more likely, is there a distribution of low-risk and high-risk investments? From a project portfolio management perspective, a distribution of risk in projects is a safer bet than one or the other.

Within the project, you’ll consider both event-based risks and non–event-based risks. Event-based risks are the risks project managers most often consider—events that will help or hinder the project objectives. Non–event-based risks are risks that are more nebulous and uncertain. There are two types of non–event-based risks:

   Variability risks Uncertainty surrounding a project activity or decision. Fluctuations in productivity, number or errors and defects, or even the weather affecting the project are all examples of variability risks. You can’t really predict with certainty productivity, errors, or weather, so these risks vary within the project.

   Ambiguity risks Uncertainty about what the future holds. These risks are impossible to predict accurately: certainty of a new technical solution, future laws or regulations, or even complexity in the project approach.

Another risk factor to consider is the project resilience. You won’t be able to identify some risks until they happen; these are called the unknown-unknowns. Project resilience is the project’s ability to weather these risks through resilience in the form of

   Budget and schedule contingency

   Flexible project processes to identify and address risks as they are discovered

   Strong change management policies and procedures

   Empowered project team that’s trusted to take actions to complete the project work

   Ongoing risk identification activities throughout the project

   Input from stakeholders to address emergent risks in the scope or project strategy

Integrated risk management is part of the organization’s approach to risk. It’s the distribution of risk events and how the risks are managed. Some risks may be assigned to the project manager to manage, and some risks may need to be escalated to management to address and manage. The integrated nature of risk management is beyond the boundaries of project management; the risk should be given to the party who’s most appropriate to manage the risk event for the organization, not just the project or even the program.

For agile projects, uncertainty is part of the approach. Because of the nature of uncertainty and the expectation of change in an agile project, there are iteration reviews, knowledge sharing, and risk management involved at each iteration. The project team, the product manager, and the project manager all work together at the beginning of an iteration to address potential risks and at the end of the iteration to review what did, or didn’t, work in the iteration. While the iteration is in motion, the project team and project manager work to monitor and address risks as they may be pending or have happened. The team is empowered to address the risk events to achieve the project’s objectives in the current iteration.

Tailoring Risk Management in Projects

Like all knowledge areas, you can also tailor risk management to fit your organization and processes. Risk management should always be adjusted to fit the project you’re managing—there is no blanket approach to risk management that will fit every project. For risk management in your projects you’ll have to consider the following:

   Size of the project Larger projects generally require a more formal risk management approach than smaller, low-priority projects.

   Complexity of the project Simple is always better when it comes to project management, but that’s not always feasible. A complex project, based on the technology involved, the endeavor’s work, and external dependencies, can include many uncertainties that have to be addressed in risk management.

   Importance of the project A high-profile project that the organization considers important for opportunities, investment, reputation, and other considerations will warrant a well-thought-out project management risk approach.

   Development of the project A waterfall or predictive project calls for risk planning upfront, as opposed to an agile project, where risks are addressed at the start of each iteration. Both project types call for risk management, but the approach is different with each type.

CERTIFICATION OBJECTIVE 11.01

Planning for Risk Management

Risk management planning is about making decisions. The project manager, the project team, and other key stakeholders are involved to determine the risk management processes. These processes are related to the scope of the project, the priority of the project within the performing organization, and the impact of the project deliverables. In other words, a simple, low-impact project won’t have the same level of risk planning as a high-priority, complex project. It’s important to complete risk management planning to manage, plan for, analyze, and react to identified risks successfully.

Examining Stakeholder Tolerance

Depending on the project, the conditions, and the potential for loss or reward, stakeholders will have differing tolerances for risk. Stakeholders’ risk tolerance may be known at the launch of the project through written policy statements or by their actions during the project. Risk tolerance describes the amount of risk exposure an organization is willing to tolerate in a project. A large project in a construction company, for example, might have a low tolerance for risk, even though the nature of the work involves many risks. The low tolerance and high risk exposure would generally mean the company would look to alleviate the high risks as much as possible—such as safety approaches and the like. Risk appetite is similar, but it describes the amount of risk an organization will allow in hopes of the reward the risk will bring. Risk appetite describes the general attitude toward risk—how hungry a company is to accept risk in relation to the reward. An investment company, for example, may have a larger risk appetite than a government agency.

Consider a project to install new medical equipment in a hospital. There’s little room for acceptance of errors because life and death are on the line. No shortcuts or quick fixes are allowed. Now consider a project to create a community garden. Not only are life and death not on the line in the garden project, but the acceptance of risk is different as well. The nature of the project and the organization determines the type of risks and the approach to manage the risk events.

A person’s willingness to accept risk is known as the utility function. The time and money costs required to eliminate the chance of failure is in proportion to the stakeholders’ tolerance of risk on the project. The cost of assuring there are no threats must be balanced with the confidence that the project can be completed without extraordinary costs. Figure 11-1 demonstrates the utility function.

FIGURE 11-1 The higher the project priority, the lower the risk tolerance.

Relying on Risk Management Policies

Organizations often have a predefined approach to risk management. The policies can define the activities to initiate, plan, and respond to risk. The project manager must map the project risk management to these policies to conform to the organization’s requirements. Within the confines of the risk management policy, the project manager must identify any component that can hinder the success of the project. Risk management policies are considered part of the organizational process assets.

Creating the Risk Management Plan

Through planning meetings, the risk management plan is created. Risk management plan templates, performing organization policies, and the risk tolerance level of the stakeholders aid in the creation of the risk management plan. The following stakeholders should be included:

   The project manager

   Project team leaders

   Key stakeholders

   Personnel specific to risk management

   Any other persons of authority involved or who have input required for the risk management processes

The goals of the meeting include defining the following:

   The project’s risk management activities

   The costs of risk elements

   Risk schedule activities

   The assignment of risk responsibilities

   The reliance on templates for risk categories

   Definitions for the level of risk

   The relevant risk probability and impact matrix definitions for the project type

The risk management meetings are iterative processes that guide the identification, ranking, and responses to the identified risks. Risk management meetings will occur throughout the project duration to assess risk, risk responses, and the overall status of risks within the project.

Examining the Risk Management Plan

The risk management plan does not detail the planned responses to individual risks within the project—this is the purpose of the risk response plan. The risk management plan is responsible for determining the risk strategy and methodology; specifically, the plan addresses these factors:

   How risks will be identified

   How quantitative analysis will be completed

   How qualitative analysis will be completed

   How the resources and funds needed for risk management will be managed

   How the risk management activities will become part of the project schedule

   How the identified risks will be categorized

   How stakeholders’ risk appetite may be adjusted based on the project conditions

   How the risk will be documented and reported

   How risk response planning will happen

   How risks will be monitored

   How risks will be tracked throughout the project

   How ongoing risk management activities will happen throughout the project life cycle

Methodology

The methodology is concerned with how the risk management processes will take place. The methodology asks the following questions:

   What tools are available to use for risk management?

   What approaches are acceptable within the performing organization?

   What data sources can be accessed and used for risk management?

   Which approach is best for the project type and the phase of the project, and which is most appropriate given the conditions of the project?

   How much flexibility is available for the project given the conditions, the time frame, and the project budget?

Roles and Responsibilities

The roles and responsibilities identify the groups and individuals who will participate in the leadership and support of each of the risk management activities within the project plan. In some instances, risk management teams outside of the project team may have a more realistic, unbiased approach to the risk identification, impact, and overall risk management needs than the actual project team.

Budgeting

Based on the size, impact, and priority of the project, a budget may need to be established for the project’s risk management activities. A project with high priority and no budget allotment for risk management activities may face uncertain times ahead. A realistic dollar amount is needed for risk management activities if the project is to be successful.

Scheduling

The risk management process needs a schedule to determine how often and when risk management activities should occur throughout the project. If risk management happens too late in the project, the project could be delayed because of the time needed to identify, assess, and respond to the risks. A realistic schedule should be developed early in the project to accommodate risks, risk analysis, and risk reaction.

Risk Analysis Scoring

Prior to beginning quantitative and qualitative analysis, the project manager and the project team must have a clearly defined scoring system and an interpretation of it. Altering the scoring process during risk analysis—or from analysis to analysis—can skew the seriousness of a risk, its impact, and the effect of the risk on the project. The project manager and the project team must have clearly defined scores that will be applied to the analysis to ensure consistency throughout the project.

Risk Categories

Based on the nature of the work, there should be identified categories of risks within the project. Figure 11-2 shows one approach to identifying risk categories by using a risk breakdown structure (RBS). Throughout the project, the risk categories should be revisited to update and reflect the current status of the project. If a previous, similar project’s risk management plan is available, the project team may elect to use this plan as a template and tailor the risk categories to the specific project.

FIGURE 11-2 A risk breakdown structure categorizes project risks.

Creating Risk Categories

Risk categories should be identified before risk identification begins, and they should include common risks that are typical in the industry in which the project is occurring. Risk categories help organize, rank, and isolate risks within the project. Risks can be categorized according to these four areas:

   Technical risks Technical risks are associated with new, unproven, or complex technologies being used on the project. Changes to the technology during the project implementation can also be a risk. Quality risks are the levels set for expectations of impractical quality and performance. Changes to industry standards during the project can also be lumped into this category of risks. Performance risks can be tied to how solutions perform, such as hardware, software, or vendors. Be careful, because risks in established technologies are not common and often overlooked.

   Management risks These risks deal with faults in the management of the project: the unsuccessful allocation of time, resources, and scheduling; unacceptable work results (low-quality work); and lousy project management. This category can also address any risks within the program, portfolio, operations, organization, resourcing, and communications.

   Commercial risks When working with vendors, new risks are introduced to the project specific to the contractual relationship. Risk categories can include the contract terms, internal procurement procedures, suppliers, subcontracts, client and customer stability, and any partnerships or joint ventures.

   External risks These risks are outside of the project but directly affect it: legal issues, labor issues, a shift in project priorities, and weather. Force majeure risks can be scary and usually call for disaster recovery rather than project management. These are risks caused by earthquakes, tornados, floods, civil unrest, and other disasters. External risks can also include exchange rates, facilities, competition, and pending regulations.

Using a Risk Management Plan Template

The performing organization may rely on templates for the risk management plan. The template can guide the project manager and the project team through the planning processes, the risk identification, and the values that may trigger additional planning. Hopefully, the organization allows the template to be modified or appended based on the nature of the project. Because most projects resemble other historical projects, an existing template may need only minor changes to be adapted to the current project.

A risk management plan may grant the project manager decision-making abilities on risks below a certain threshold. Risks above a preset threshold may need to be escalated to a risk management board or a project steering committee for a determination of their cost and impact on the project’s success.

CERTIFICATION OBJECTIVE 11.02

Identifying Risks

After completing the risk management plan, you’ll need to get to work identifying risks that can hinder the project’s success. Risk identification is the process of identifying the risks and then documenting how their presence can affect the project. Risk identification is an iterative process and can be completed by the project manager, the project team, a risk management team, and even SMEs. In some instances, stakeholders and even people outside of the project can complete additional waves of risk identification. Risk identification addresses both individual risks and the overall project risks.

Preparing for Risk Identification

The risk management plan, a subsidiary plan to the overall project management plan, is one of the key inputs to the risk identification process. It describes how the risks will be identified, the requirements for risk analysis, and the overall management of the risk response process. The risk management plan does not include the actual responses to the risks, but rather the approach to the management of the process. In addition to the risk management plan are several other inputs to the risk identification process. The following risk management plan components are referenced here:

   The roles and responsibilities for risk management activities

   The budget for risk management activities

   The schedule for risk management activities

   Categories of risk

Other subsidiary plans from the project management plan can also be utilized in risk identification:

   Requirements management plan Identify objectives that are prone to risks

   Schedule management plan Review parts of the schedule that are risk laden

   Cost management plan Address any cost ambiguity activities or cost uncertainties

   Resource management plan Identify resources, physical or human, that have ambiguity or assumptions made

   Quality management plan Address assumptions about quality that could introduce risk

   Scope baseline Review the qualifications for acceptance for the deliverables and use the WBS as a guide for the risk breakdown structure

   Schedule baseline Review milestones and due dates that may be susceptible to risk events or introduce risk into the project

   Cost baseline Review the cost thresholds, limits, range of variances, and other aspects of costs that may introduce risk to the project success

Project documents are also reviewed as an input to risk identification throughout the project. You’ll need to review all the following for assumptions and potential risks:

   Assumption log

   Cost estimates

   Duration estimates

   Issue log

   Lessons learned register

   Requirements

   Resource requirements

   Stakeholder register

Identifying the Project Risks

Armed with the inputs to risk identification, the project manager, the project team, and experts are prepared to begin identifying risks. Risk identification should be a methodical, planned approach. Should risk identification move in several different directions at once, some risks may be overlooked. A systematic, scientific approach is best.

Reviewing Project Documents

One of the first steps the project team can take is to review the project documentation. The project plan, scope, and other project files should be reviewed. Constraints and assumptions should be reviewed, considered, and analyzed for risks. This structured review takes a broad look at the project plan, the scope, and the activities defined within the project.

Testing the Assumptions

All projects have assumptions. Assumption analysis is the process of examining assumptions to see what risks may stem from false assumptions. Examining assumptions is about finding their validity. For example, consider a project to install a new piece of software on every computer within an organization. The project team has assumed that all the computers within the organization meet the minimum requirements to install the software. If this assumption were wrong, cost increases and schedule delays would occur.

This examination also requires a review of assumptions across the whole project for consistency. For example, consider a project with an assumption that a senior employee will be needed throughout the entire project; the cost estimate, however, has been billed at the rate of a junior employee. All assumptions and their conditions should be recorded in the assumptions log. You’ll update this log based on the accuracy of the assumptions and the outcome of assumptions testing.

False assumptions can ruin a project. They can wreck schedule, cost, and even the quality of a project deliverable. For this reason, assumptions are treated as risks and must be tested and weighed to truncate the possibility of an assumption turning against the project. Assumptions are weighed using two factors:

   Assumption stability How reliable is the information that led to this assumption?

   Assumption consequence What is the effect on the project if this assumption is false?

The answers to these two questions will help the project team deliver the project with more confidence. Should an assumption prove to be false, the weight of the assumption consequence may be low to high—depending on the nature of the assumption.

Brainstorming the Project

Brainstorming is likely the most common approach to risk identification. It’s usually completed by the entire project team to identify the risks within the project. The risks are identified in broad terms and posted, and then the risks’ characteristics are detailed. The identified risks are categorized and will later pass through qualitative and quantitative risk analyses.

A multidisciplinary team, hosted by a project facilitator, can also complete brainstorming. This approach can include subject matter experts, project team members, customers, and other stakeholders who contribute to the risk identification process.

Using Checklists

Checklists can serve as a good reminder of what to review for risk events, specific steps to follow, and project points to be considered for risk events. A checklist can evolve over time and is part of organizational process assets. A project manager can rely on a checklist for prompts during risk identification meetings, where the checklist could provide a series of questions, confirmations, or reminders. However, the checklist can’t, and won’t, cover every feasible risk event, so it’s important not to treat the checklist as a comprehensive list that addresses every possible risk in the project.

The Delphi Technique is an anonymous method used to query experts about foreseeable risks within a project, phase, or component of a project. The results of the survey are analyzed by a third party, organized, and then circulated to the experts. There can be several rounds of anonymous discussion with the Delphi Technique—without fear of backlash or offending other participants in the process. The Delphi Technique’s goal is to gain consensus on risks within the project. The anonymous nature of the process ensures that no one expert’s advice overtly influences the opinion of another participant. The Delphi Technique can also take out the fear of retribution some people may have about showing a risk that could make a colleague or supervisor look bad in front of other team members.

Identifying Risks Through Interviews

Interviewing subject matter experts and project stakeholders is an excellent approach to identifying risks on the current project based on the interviewees’ experience. The people responsible for risk identifications understand the overall purpose of the project and the project’s work breakdown structure (WBS), and they likely have made the same assumptions as the interviewee.

The interviewee, through questions and discussion, shares his insight on what risks he perceives within the project. The goal of the process is to learn from the expert what risks may be hidden within the project, what risks this person has encountered on similar work, and what insight he has into the project work. Part of the interview process is also to examine, even challenge, the assumptions the stakeholders may have as part of the project.

Analyzing SWOT

SWOT stands for strengths, weaknesses, opportunities, and threats. SWOT analysis is the process of examining the project from the perspective of each characteristic. For example, a technology project may identify SWOT as follows:

   Strengths The technology to be installed in the project has been installed by other large companies in our industry.

   Weaknesses We have never installed this technology before.

   Opportunities The new technology will allow us to reduce our cycle time for time-to-market on new products. Opportunities are things, conditions, or events that allow an organization to differentiate itself from competitors and improve its standing in the marketplace.

   Threats The time to complete the training and simulation may overlap with product updates, new versions, and external changes to our technology portfolio.

You can use SWOT analysis as you prepare to pass your PMP exam. Review your end-of-chapter exam scores to see which chapters contain information you’re strong or weak in and which chapters represent your opportunities and threats.

Utilizing Diagramming Techniques

The project team can utilize several diagramming techniques to identify risks:

   Ishikawa These cause-and-effect diagrams, as shown, are also called fishbone diagrams. They are great for the root-cause analysis of factors that are causing risks within the project. The goal is to identify and treat the root of the problem, not the symptom.

   Flowcharts System or process flowcharts show the relationship between components and how the overall process works. These are useful for identifying risks between system components.

   Influence diagrams An influence diagram, shown next, charts out a decision problem. It identifies all the elements, variables, decisions, and objectives—and how each factor may influence another.

Using Prompt Lists

If you’re doing the same types of projects over and over, such as IT projects or construction projects, you might use a prompt list to help the project team better identify project risks. Prompt lists are risk categories that were identified in the risk management plan. For example, your prompt list might ask, “What type of risks are lurking in hardware for this project?” or “Are there any new materials that could have risks we should consider?” The prompt list prompt risk identification participants to think about individual risks based on the prompts you include.

Overall project risks subscribe to one of three common types of prompt lists:

   VUCA volatility, uncertainty, complexity, and ambiguity

   TECOP technical, environmental, commercial, operational, and political

   PESTLE political, economic, social, technological, legal, and environmental

Creating a Risk Register

The risk register is a project document that contains all the information related to the risk management activities. It’s updated as risk management activities are conducted to reflect the status, progress, and nature of the project risks. The risk register includes the following:

   Risks Of course, the most obvious output of risk identification is the risk that has been successfully identified. Recall that a risk is an uncertain event or condition that could potentially have a positive or negative effect on the project’s success.

   Potential responses During the initial risk identification process, there may be solutions and responses to identified risks. This is fine as long as the responses are documented in the register. Along with the risk responses, the identification of risk triggers may occur. Triggers are warning signs or symptoms that a risk has occurred or is about to occur. For example, should a vendor fail to complete her portion of the project as scheduled, the project completion may be delayed.

   Potential risk owners If you’ve identified a person or role on the project team or in the organization who will own the risk, you’ll include that information in the risk register. The ownership of the risk will be confirmed in the qualitative risk analysis process.

   Possible additional data Risk identification may include additional information, such as risk category, current risk status, root cause(s) of an identified risk, risk triggers, WBS references, risk timing, and deadlines.

Creating a Risk Report

Another output of risk identification is a risk report. The risk report explains the overall project risks and provides summaries about the individual project risks. You’ll update the risk report through the project as more information becomes available through analysis and experience in the project. The report will be updated with risk responses and the response outcomes, and any additional details as a result of monitoring risks in the project. Your risk report, depending on what’s required in the organization, may include sources of overall project risk exposure, trends among the individual risks, number of threats and opportunities, and other related information.

CERTIFICATION OBJECTIVE 11.03

Using Qualitative Risk Analysis

Qualitative risk analysis “qualifies” the risks that have been identified in the project. Specifically, qualitative risk analysis examines and prioritizes the risks based on their probability of their occurrence and the impact on the project if they did occur. Qualitative risk analysis is a broad approach to ranking risks by priority, which then guides the risk reaction process. The facilitator of the qualitative risk analysis process, whether an expert or the project manager, must be aware of perception and bias of how and why risks are rated by the participants.

The end result of qualitative risk analysis (once risks have been identified and prioritized) can lead to more in-depth quantitative risk analysis, or it can move directly into risk response planning. Qualitative is subjective, because it’s really a fast human judgment based on experience, a gut feeling, or a best guess about the risk’s impact and probability.

Preparing for Qualitative Risk Analysis

The risk management plan is the key input to qualitative risk analysis. The plan will dictate the process, the methodologies to be used, and the scoring model for identified risks. In addition to the risk management plan, the identified risks from the risk register, obviously, will be needed to perform an analysis. These are the risks that will be scored and ranked based on their probability and impact.

The status of the project will also affect the process of qualitative risk analysis. Early in the project, there may be several risks that have not yet surfaced. Later in the project, new risks may become evident and need to pass through qualitative analysis. The status of the project is linked to the available time needed to analyze and study the risks. More time may be available early in the project, while a looming deadline near the project’s end may create a sense of urgency to find solutions for the newly identified risks.

The project type also has some bearing on the process. As in the following illustration, a project that has never been done before, such as the installation of a new technology, has more uncertainty than a project that has been undertaken repeatedly within an organization. Recurring projects have historical information that you can rely on, while first-time projects have limited resources upon which to build a risk hypothesis.

All risks are based upon some belief, proof, and data. The accuracy and source of the data must be evaluated to determine the level of confidence in the identified risks. A hunch that an element is a risk is not as reliable as measured statistics, historical information, or expert knowledge that an element is a risk. The data precision needed is in proportion to the reality of the risk.

Prior to the risk analysis, a predetermined scale of probability and impact must be in place. A project manager can elect to use a number of scales, but generally they should be in alignment with the risk management plan. If the performing organization has a risk management model, the scale identified by the performing organization should be used. (I’ll discuss the scale values in the next section.)

The assumptions used in the project must be revisited, so you’ll also rely on the assumptions log. Throughout the project, assumptions are accrued in the assumption log, which was initially generated as part of building the project charter. These assumptions will be evaluated as risks to the project’s success if they prove false. Finally, the project’s stakeholder register serves as an input, too, because certain stakeholders may be identified as risk owners.

Completing Qualitative Analysis

Not all risks are worth responding to, but some demand attention. Qualitative analysis is a subjective approach to organizing and prioritizing risks. The risk data quality assessment helps to determine the reliability of the data about the identified risks and their rankings. Using good, reliable, proven data along with a methodical and logical approach, the identified risks can be rated according to probability and potential impact.

The project manager needs to determine the quality of the data used to understand the accuracy and reliability of the risk scoring; low-quality data is little more than opinion and not a good foundation for qualitative risk analysis. One of the toughest parts of qualitative risk analysis is the biased, subjective nature of the process. A project manager and the project team must question the reliability and reality of the data that led to the ranking of the risks. For example, Susan may have great confidence in herself when it comes to working with new, unproven technologies. Based on this opinion, she petitions for the risk probability of the work to be a very low score.

However, because she has no experience with the technology because of its newness, the probability of the risk of failure is actually very high. The biased opinion that Susan can complete the work with zero defects and problems is slightly skewed, because she has never worked with the technology before. Obviously, a low-ranked score on a risk that should be ranked high can have detrimental effects on the project’s success.

Data precision ranking takes into consideration the biased nature of the ranking, the accuracy of the data submitted, and the reliability of the biased ranking submitted to examine the risk scores. Data precision ranking is concerned with the following:

   The level of understanding of the project risk

   The available data and information about the identified risk

   The quality of the data and information about the identified risk

   The reliability of the data about the identified risk

The outcome of the ranking determines four certain things:

   It identifies the risks that require additional analysis through quantitative risk analysis.

   It identifies the risks that may proceed directly to risk response planning.

   It identifies risks that are not critical, project-stopping risks, but that still must be documented.

   It prioritizes risks.

Qualitative risk analysis also takes a cursory look at and documentation of the following:

   Urgency of the risk How long before the risk may happen in the project?

   Proximity How long before the risk will affect a project objective?

   Dormancy How long after the risk has occurred before its impact is noticed?

   Manageability How easily can the risk be managed?

   Controllability How easily can the outcome of the risk event be controlled?

   Detectability How easily can the evidence of a risk’s occurrence be detected?

   Connectivity How connected is a risk to other risks within the project?

   Strategic impact What size of impact will the risk event have on the organization’s strategic goals?

   Propinquity What is the risk perception by key stakeholders?

Applying Probability and Impact

The project risks are rated according to their probability and impact. Risk probability is the likelihood that a risk event may happen, while risk impact is the consequence that the result of the event will have on the project objectives. Each risk is measured based on its likelihood and its impact. Two approaches exist to ranking risks:

   Cardinal scales Identify the probability and impact on a numeric value from 0.01 (very low) to 1.00 (certain).

   Ordinal scales Identify and rank the risks with common terms, such as very high to very unlikely, or using an RAG (red, amber, green) rating to signify the risk score.

Creating a Probability-Impact Matrix

Each identified risk is fed into a probability-impact matrix, as shown in Figure 11-3. The matrix maps out the risk, its probability, and its possible impact. The risks with higher probability and impact are a more serious threat to the project objectives than the risks with lower impact and consequences. The risks that are threats to the project require quantitative analysis to determine the root of the risks, the methods to monitor the risks, and effective risk management. We’ll discuss quantitative risk management later in this chapter.

FIGURE 11-3 A probability-impact matrix measures the identified risks within the project.

The project is best served when the probability scale and the impact scale are predefined prior to qualitative analysis, as was done when creating the risk management plan. For example, the probability scale rates the likelihood of an individual risk happening and can be on a cardinal scale (0.1, 0.3, 0.5, 0.7, 0.9) or on an ordinal scale (low, medium, high). The scale, however, should be defined and agreed upon in the risk management plan. The impact scale, which measures the severity of the risk on the project’s objectives, can also be on an ordinal or a cardinal scale.

The value of identifying and assigning the scales to use prior to the process of qualitative analysis enables all risks to be ranked by the system and allows for future identified risks to be measured and ranked by the same system. A shift in risk rating methodologies midproject can cause disagreements regarding the method for handling the project risks.

A probability-impact matrix multiplies the value for the risk probability by the risk impact for a total risk score. The risk’s scores can be cardinal, as shown in Figure 11-4, and then preset values can qualify the risk for a risk response. For example, an identified risk in a project is the possibility that the vendor may be late in delivering the hardware. The probability is rated at 0.9, but the impact of the risk on the project is rated at 0.1. The risk score is calculated by multiplying the probability times the impact—in this case, resulting in a score of 0.09.

FIGURE 11-4 The results of a probability-impact matrix create a risk score.

The scores within the probability-impact matrix can be referenced against the performing organization’s policies for risk reaction. Based on the risk score, the performing organization can place the risk in differing categories to guide risk reaction. There are three common categories based on risk score:

   Red condition These high risk scores are high in impact and probability.

   Amber condition (aka yellow condition) These risks are somewhat high in impact and probability.

   Green condition These risks are generally fairly low in impact, probability, or both.

Your organization may not use a classification of risks based on red, amber, and green—called RAG rating. Your project risks should map to the methodology your organization uses to identify and classify project risks. If there is no classification of risks, take the initiative and create one for your project. Be certain to document your classification for historical information and include this information in your lessons learned documentation.

Building a Hierarchical Chart

It’s tempting, and often convenient, to rate risks based only on probability and impact. However, you can rate risks based on several factors, such urgency, proximity, and impact, to create a more robust chart. By scoring any number of factors, you can create histograms, pie charts, or bubble charts. In a bubble chart, shown next, you’ll plot out the factors from low to high and add the variable of the size of the bubble to show the bubble impact value. The larger the bubble, the larger the impact of the risk. Where the bubbles land in the chart, based on the factors selected, will help determine which risks need additional analysis, aren’t acceptable, or have low factors and might be acceptable in the project.

Examining the Results of Qualitative Risk Analysis

Qualitative risk analysis happens throughout the project. As new risks become evident and identified, the project manager should route the risks through the qualitative risk analysis process. The end results of qualitative risk analysis include the following:

   Assumption log Assumptions can be updated and new assumptions are added to log.

   Issue log Any new issues discovered are added to the log, and issues that have changed are updated to reflect their new status.

   Risk register New risks that have been identified are added to the register, while existing risks will have their attributes updated to reflect the qualitative risk analysis findings.

   Risk report The risk report is updated with any changes to the summary on the individual risks and the overall risk ranking of the project. This enables the project manager, management, customers, and other interested stakeholders to comprehend the risk, the nature of the risk, and the condition between the risk score and the likelihood of success for a project. The risk score can be compared to other projects to determine project selection, the placement of talent in a project, prioritization, the creation of a benefit/cost ratio, or even the cancellation of a project because it is deemed too risky.

   Risk categories Within the risk register, categories of risks should be created. The idea is that not only will related risks be lumped together, but there may also be some trend identification and root-cause analysis of identified risks. Having risks categorized should also make it easier to create risk responses.

   Near-term risks Qualitative analysis should also help the project team identify which risks require immediate or near-term risk responses. Risks that are likely to happen later in the project can be acknowledged, enabling imminent risks to be managed first. Urgent risks can go right to quantitative analysis and risk response planning.

   Low-priority risk watch list Let’s face it: not all risks need additional analysis. However, these low-priority risks should be identified and assigned to a watch list for periodic monitoring.

   Trends in qualitative analysis As the project progresses and risk analysis is repeated, trends in the ranking and analysis of the risk may become apparent. These trends can enable the project manager and other risk experts to respond to the root cause, predict trends to eliminate, or respond to the risks within the project.

CERTIFICATION OBJECTIVE 11.04

Preparing for Quantitative Risk Analysis

Quantitative risk analysis attempts to assess the probability and impact of the identified risks numerically. It also creates an overall risk score for the project. This method is more in-depth than qualitative risk analysis and relies on several different tools to accomplish its goal. You don’t have to do quantitative analysis on every project and certainly not for every identified risk. You’ll only do quantitative analysis on projects that demand the process, usually high-profile projects, and on risk events that are deemed significant through qualitative risk analysis.

Qualitative risk analysis typically precedes quantitative analysis. All or a portion of the identified risks in qualitative risk analysis can be examined in the quantitative analysis. The performing organization may have policies on the risk scores in qualitative analysis that require the risks to advance to quantitative analysis. Schedule and budget constraints may also be factors in the determination of which risks should pass through quantitative analysis. Quantitative analysis is a more time-consuming process and is, therefore, also more expensive. Following are the goals of quantitative risk analysis:

   To ascertain the likelihood of reaching project success

   To ascertain the likelihood of reaching a project objective

   To determine the risk exposure for the project

   To determine the likely amount of the contingency reserve needed for the project

   To determine the risks with the largest impact on the project

   To determine realistic schedule, cost, and scope targets

Considering the Inputs for Quantitative Analysis

Based on the time and budget allotments for quantitative analysis, as defined in the risk management plan, the project manager can move into quantitative analysis. The project manager should rely on the following 16 inputs to quantitative risk analysis:

   Risk management plan The risk management plan identifies the risk management methodology, the allotted budget for risk analysis, the schedule, and the risk scoring mechanics—among other attributes.

   Scope baseline You’ll utilize the scope baseline to see what’s being affected in scope by the identified risk events.

   Schedule baseline Risks don’t affect just the scope; they can also affect the project’s schedule.

   Costs baseline Risks can also affect the costs of the project, so the cost baseline also serves as an input to quantitative risk analysis.

   Assumptions log Assumptions are uncertain and their uncertainty can serve as an input to quantitative risk analysis. Constraints are also examined in this process.

   Basis of estimates How the cost and activity duration estimates were modeled and formulated are subject to quantitative risk analysis.

   Cost estimates Cost estimates are examined because there may be a range of variance in the cost estimates that could introduce risks to the project.

   Cost forecasts Through earned value management, you may have created an estimate to complete, estimate at completion, budget at completion, and a to-complete performance index that have introduced risks into the project, or they may be at risk of being false assumptions about the costs to complete the project work.

   Duration estimates Duration estimates, and their supporting detail, may be subject to risk, because there’s uncertainty in predicting how long an activity will take to complete. You don’t know how long something will truly take to do, usually, until you do the activity.

   Milestone list The target dates for achieving milestones can pass through quantitative risk analysis because there may be a level of uncertainty for reaching the target dates.

   Resource requirements Resources, human and physical, may have variations for their performance, availability, and completion of the project work.

   Risk register The risks that have been identified and promoted to quantitative analysis are needed. The project team will also need their ranking and risk categories—all of which are documented in the risk register.

   Risk report The current individual risks and the overall project risks are defined.

   Schedule forecasts The predicted timeline of the project can introduce risks and may need to pass through quantitative risk analysis to determine a level of confidence of actually achieving the project schedule as planned and predicted.

   Enterprise environmental factors The organization may require the project manager to utilize risk databases from similar projects within the organization or from industry sources. The enterprise environmental factors may also include reports, checklists, and business cases from similar projects within your industry.

   Organizational process assets Historical information is one of the best inputs for risk analysis, as it is proven information for the project. An examination of the project risks from past experiences can help the project team complete quantitative risk analysis activities.

Interviewing Stakeholders and Experts

Interviews with stakeholders and SMEs can be among the first tasks involved in quantifying the identified risks. These interviews can focus on worst-case, best-case, and most-likely scenarios if the goal of the quantitative analysis is to create a triangular distribution; most quantitative analysis, however, uses continuous probability distributions. Figure 11-5 shows five sample distributions: normal, lognormal, beta, triangular, and uniform.

FIGURE 11-5 Risk distributions illustrate the likelihood and impact of an event within a project.

Continuous probability distribution is an examination of the probability of all possibilities within a given range. For each variable, the probability of a risk event and the corresponding consequence for the event may vary. In other words, depending on whether the risk event occurs and how it happens, a reaction to the event may also occur. Here are the distributions of the probabilities and impacts, sometimes called “representations of uncertainty”:

   Uniform

   Normal

   Triangular

   Beta

   Lognormal

Applying Sensitivity Analysis

Sensitivity analysis examines each project risk on its own merit. It is an analysis process to determine which risks could affect the project the most. All other risks in the project are set at a baseline value. The individual risk is then examined to see how it may affect the success of the project. The goal of sensitivity analysis is to determine which individual risks have the greatest impact on the project’s success and then escalate the risk management processes on these risk events. Sensitivity analysis is often associated with a tornado diagram.

Finding the Expected Monetary Value

The expected monetary value of a project or event is based on the probability of outcomes that are uncertain. For example, one risk may cost the project an additional $10,000 if it occurs, but there’s only a 20 percent chance of the event occurring. In the simplest form, the expected monetary value of this individual risk is thus $2000. Project managers can also find the expected monetary value of a decision by creating a decision tree.

See the video “Risk Reserve.”

Using a Decision Tree

A decision tree is a method used to determine which of two or more decisions is the best to make. For example, it can be used to determine buy-versus-build scenarios, lease-or-purchase equations, or whether to use in-house resources rather than outsourcing project work. The decision tree model examines the cost and benefits of each decision’s outcomes and weighs the probability of success for each of the decisions.

The purpose of the decision tree is to make a decision, calculate the value of that decision, or determine which decision costs the least. Follow Figure 11-6 through the various steps of the decision tree process.

FIGURE 11-6 Decision trees analyze the probability of events and calculate decision values.

Completing a Decision Tree

Let’s look at a scenario. As the project manager of the new GFB Project, you have to decide whether to create a new web application in-house or send the project out to a developer. The developer you would use if you were to outsource the work quotes the project cost at $175,000. Based on previous work with this company, you are 85 percent certain they will finish the work on time.

Your in-house development team quotes the cost of the work as $165,000. Again, based on previous experience with your in-house developers, you are 75 percent certain they can complete the work on time. Now let’s apply what you know to a decision tree:

   Buy or build is simply the decision name.

   The cost of the decision if you buy the work outside of your company is $175,000. If you build the software in-house, the cost of the decision is $165,000.

   Based on your probability of completion by a given date, you apply the 85 percent certainty to the “strong” finish for the buy branch of the tree. Because you’re 85 percent certain, you’re also 15 percent uncertain; this value is assigned to the “weak” value on the buy branch. You complete the same process for the build branch of the tree.

   The value of the decision is the percentage of strong and weak applied to each branch of the tree.

   The best decision is based solely on the largest value of all possible decisions identified in the decision tree.

Using a Project Simulation

Project simulations enable the project team to play “what-if” games without affecting any areas of production. The Monte Carlo analysis technique, discussed in earlier chapters, is the most common simulation. Monte Carlo, typically completed using a software program, completely simulates a project with values for all possible variables to predict the most likely model. Monte Carlo simulations can create a probability distribution, called an S-curve, to show the likelihood of a desired outcome, or loss, in the project.

Examining the Results of Quantitative Risk Analysis

Quantitative risk analysis is completed throughout the project as risks are identified and passed through qualitative analysis, as project conditions change, or on a preset schedule. The result of quantitative risk analysis should be reflected in the risk report and should include the following:

   Overall project risk exposure The overall project risk exposure is documented in the project’s chances of success, which indicates how likely the project is to reach its key objectives. The degree of inherent remaining variability in the project is assessed. This means how much risk the project is carrying based on how the variations of possible project outcomes.

   Probabilistic analysis The risks within the project enable the project manager or other experts to predict the likelihood of the project’s success. The project may be altered by the response to certain risks; this response can increase cost and push back the project’s completion date. The results of quantitative analysis can be shown through tornado diagrams and S-curves to plot out the project’s risks. The analysis also can identify the major risk events, contingency reserve needed, and which risks have the most uncertainty and most probability of happening.

   Prioritized list of individual project risks The risk events are prioritized by their likelihood of occurring and the impact on the project if the risk events do occur.

   Trends in quantitative analysis As the project moves toward completion, quantitative risk analysis may be repeated. In each round of analysis, trends in the identified risks may become visible. The trends in the risk can help the project team eliminate the root causes of the risk, reduce their probability, or address their impact.

   Recommended risk responses Risk response planning is covered in detail in the next section, but the risk report may also include the recommended risk responses. These recommendations will serve as an input to planning the risk responses formally.

CERTIFICATION OBJECTIVE 11.05

Planning for Risk Responses

Risk response planning is all about options and actions. It focuses on how to decrease the possibility of risks adversely affecting the project’s objectives and how to increase the likelihood of positive risks that can aid the project. Risk response planning assigns responsibilities to people and groups close to the risk event. Risks will increase or decrease based on the effectiveness of risk response planning.

The responses to identified risks must be in balance with the risks themselves. The cost and time invested in reducing a risk’s impact and probability must be compared with the expected gains. In other words, a million-dollar solution for a hundred-dollar problem is unacceptable. The people or individuals who are assigned to the risk must have the authority to react to the project risk as planned. In most cases, several risk responses may be viable for the risk—the best choice for the identified risk must be documented, agreed upon, and then followed through should the risk occur.

Preparing for Risk Response

To prepare successfully for risk response, the project manager, project team, and appropriate stakeholders rely on just two inputs: the risk management plan and the risk register. The inputs for planning the risk responses include the following:

   Project management plan Resource management plan, risk management plan, and cost baseline

   Project documents Lessons learned register, schedule, team assignments, resource calendars, risk register, risk report, and stakeholder register

   Enterprise environmental factors Risk appetite and risk thresholds of the key stakeholders

   Organizational process assets Templates for the risk management plan, risk register, risk report, any historical databases, and lessons learned from similar projects

Creating Risk Responses

The project team can employ several tools and techniques to respond to risks. Each risk should be evaluated to determine which category of risk response is most appropriate. When a category of risk response has been selected, the response must then be developed, refined, documented, and readied for use, if needed. In addition, secondary responses may be selected for each risk. The purpose of risk response planning is to bring the overall risk of the project down to an acceptable level, while leveraging any positive risks. In addition, risk response planning must address any risks that have unacceptably high scores.

Expert judgment, interviews, and facilitation techniques are three of the nine tools and techniques used for creating risk responses. These three tools deal with discussing the risk responses, getting stakeholders involved in the planning, and ensuring that the best decisions for the risk responses are made. These are the other six tools and techniques:

   Strategies for threats

   Strategies for opportunities

   Contingent response strategies

   Strategies for overall project risk

   Data analysis

   Decision-making

I’ll discuss each of these in detail in this section.

Escalating the Risk Event

Not all risks should be managed at the project level. Some risks that are outside of the boundary of the project should be escalated when the project team, project sponsor, or project manager believes the risk management would exceed the authority the project manager has over the risk event. In these instances, the risk is escalated to management, a program manager, or the portfolio manager in the organization. The escalated threat should be communicated to the new owner of the risk event to explain why it’s beyond the project boundaries, and the new owner must also agree to accept the risk as part of her responsibility. Like negative risk events, threats and opportunities can be escalated.

Avoiding the Negative Risk and Threats

Avoidance is simply avoiding the risk. This can be accomplished in many different ways and generally happens early in the project, when any change will result in fewer consequences than it would later in the project plan. Here are some examples of avoidance:

   Changing the project plan to eliminate the risk

   Clarifying project requirements to avoid discrepancies

   Hiring additional project team members who have experience with the technology involved in the project

   Using a proven methodology rather than a new approach

Transferring the Negative Risk

Transference is the process of transferring the risk (and the ownership of the risk) to a third party. The risk doesn’t disappear; it’s just someone else’s problem. Transference of a risk usually costs a premium for the third party to own and manage that risk. Here are common examples of risk transference:

   Insurance

   Performance bonds

   Warrantees

   Guarantees

   Fixed-price contracts

Mitigating the Negative Risk

Mitigating risks is an effort to reduce the probability and/or impact of an identified risk in the project. Mitigation occurs before the risk event happens. The cost and time to reduce or eliminate the risk is more cost effective than repairing the damage caused by the risk. The risk event may still happen, but hopefully the cost and impact will be low.

Mitigation plans can be created so that they are implemented should an identified risk cross a given threshold. For example, a manufacturing project may have a mitigation plan to reduce the number of units created per hour should the equipment’s temperature exceed a given threshold. The reduction is the number of units per hour that implementing the plan may cost the project in time. In addition, the cost of extra labor to run the equipment longer because the machine is now operating at a slower pace may be attributed to the project. However, should the equipment fail, the project would have to replace the equipment and could be delayed for weeks while awaiting repairs.

Here are some examples of mitigation:

   Adding activities to the project to reduce the risk probability or impact

   Simplifying the processes within the project

   Completing more tests on the project work before implementation

   Developing prototypes, simulations, and limited releases

Managing the Positive Risks and Opportunities

Although most risks have a negative connotation, not all risks are bad. There are instances when a risk may create an opportunity that can help the project, other projects, or the organization. The type of risk and the organization’s willingness to accept the risks will dictate the appropriate response.

Exploiting the Positive Risk or Opportunity

When an organization wants to ensure that a positive risk definitely happens, it can exploit the risk. Exploiting a risk means that the project team works to ensure a 100 percent probability of the risk event. Positive risk exploitation can be realized by adding the most-qualified resources to an activity, using a faster piece of equipment, or employing another method to make the likelihood of a positive risk event definite.

Sharing the Positive Risk

The idea of sharing a positive risk really means sharing a mutually beneficial opportunity between two organizations or projects, or creating a risk-sharing partnership. When a project team can share the positive risk, ownership of the risk is given to the organization that can best capture the benefits from the identified risk. Teaming agreements and joint ventures are examples of sharing a positive risk.

Enhancing a Positive Risk

This risk response seeks to modify the size of the identified opportunity. The goal is to strengthen the cause of the opportunity to ensure that the risk event does happen. Enhancing a project risk looks for solutions, triggers, or other drivers to ensure that the risk does come to fruition so that the rewards of the risk can be realized by the performing organization. Crashing a project to receive an award, for example, is an example of enhancing a positive risk.

Escalate a Positive Risk

When a risk, even a positive risk, is outside of the project manager’s authority or outside the scope of the project, the risk is escalated. Once an opportunity is escalated, it’s no longer monitored by the project manager or team; it’s owned by some other entity in the organization, and the project manager and team return to focus on the project scope.

Accepting a Risk

Risk acceptance is the process of accepting a risk because no other action is feasible, or the risk is deemed to be of small probability, impact, or both, and a formal response is not warranted. Passive acceptance requires no action; the project team deals with the risk when it happens. Active acceptance entails developing a contingency plan should the risk occur. Acceptance may be used for both positive and negative risks.

Creating a Project Contingency Response

A contingency response is a predefined set of actions the project team will take should certain events occur. Contingency plans are sometimes called worst-case scenario plans or fallback plans. Events that trigger the contingency plan should be tracked. A fallback plan is a reaction to a risk that has occurred when the primary response proves to be inadequate. Most risk acceptance policies rely on a contingency allowance for the project. A project contingency allowance is the amount of money the project will likely need in the contingency reserve based on the impact, probability, and expected monetary value of a risk event.

For example, Risk A has a 25 percent chance of happening and has a cost impact of –$20,000. The probability of 25 percent times the impact of –$20,000 equates to a –$5000 expected monetary value (Ex$V). Another risk, Risk B, has a 45 percent chance of happening and has a positive benefit value of $3000. The Ex$V for Risk B is positive, $1350. If these were the only risks in the project, an ideal contingency reserve would be $3650. This is calculated by adding the positive and negative risk values to predict the amount by which the project is likely to be underfunded if the risks happen. Table 11-1 shows several risks and their Ex$Vs.

TABLE 11-1 Contingency Reserve Calculations

Examining the Results of Risk Response Planning

The major output of risk response planning is the risk register updates, though change requests, project management plan updates, and project documents might also be outputs depending on the risk responses created. These risk responses are documented in the risk register and guide the reaction to each identified risk. They include the following:

   A description of the risk, what area of the project it may affect, the causes of the risk, and its impact on project objectives

   Risk response strategies

   Contingency plans and fallback plans

   The identities of the risk owners and their assigned responsibilities

   The outputs of qualitative and quantitative analyses

   Risk strategies and the specific actions necessary to implement those strategies

   Symptoms and warning signs, sometimes called triggers, of each risk event

   A description of the response to each risk, such as avoidance, transference, mitigation, or acceptance

   The actions necessary to implement the responses

   The budget and schedule for risk responses

   The contingency and fallback plans

   Change requests

Working with Residual Risks

The risk response plan also acknowledges any residual risks that may remain after planning, avoidance, transfer, or mitigation. Residual risks are typically minor and have been acknowledged and accepted. Management may elect to add both contingency costs and schedule to account for the residual risks within the project.

Accounting for Secondary Risks

Secondary risks stem from risk responses. For example, the response of transference may call for a third party to manage an identified risk. As you can see in the following illustration, a secondary risk caused by the solution is the failure of the third party to complete their assignment as scheduled. Secondary risks must be identified, analyzed, and planned for, just as any another identified risk.

Creating Contracts for Risk Response

When multiple entities are involved in a project, contractual agreements may be necessary to identify the responsible parties for identified risks. The contract may be needed for insurance purposes, customer acceptance, or the acknowledgement of responsibilities between the entities completing the project. Transference is an example of contractual agreements to transfer the responsibility for risks within a project.

Justifying Risk Reduction

To reduce risk, additional time or monies are typically needed. The process and logic behind the strategies to reduce a risk should be evaluated to determine whether the solution is worth the tradeoffs. For example, a risk may be eliminated by adding $7500 to a project’s budget. However, the likelihood of the risk occurring is relatively low. Should the risk happen, it would cost, at a minimum, $8000 to correct, and the project would be delayed by at least two weeks. The cost of preventing the risk versus the cost of responding to it must be weighed and justified. If the risk is not eliminated with the $7500 cost and the project moves forward as planned, it has, theoretically, saved $15,500 because the risk did not happen and the response to the risk did not need to happen. However, if the risk does happen, the project will lose at least $8000 and will be delayed at least two weeks. The cost inherent in the project delay may be more expensive than the solution to the risk. The judgment of solving the risk to reduce the likelihood of delaying the project may be wiser than ignoring the risk, hoping the risk won’t happen, and saving the costs incurred. In other words, sometimes it’s better to purchase a solution than to gamble that the risk won’t happen.

Updating the Project Plan

The risk reactions, contingency plans, and fallback plans should all be documented and incorporated into the project plan—for example, updating the schedule, budget, and WBS to accommodate additional time, money, and activities for risk responses. The responses to the risks may change the original implementation of the project and should be updated to reflect the project plan and intent of the project team, management, and other stakeholders. A failure to update the project plan and the risk register may cause risk reactions to be missed and may skew performance measurements. The following specific project management plan components may need a change request to be updated:

   Schedule management plan

   Cost management plan

   Resource management plan

   Procurement management plan

   Scope, schedule, and cost baselines

CERTIFICATION OBJECTIVE 11.06

Implementing Risk Responses

Once the risk responses have been identified, documented, and agreed upon, the project manager will also need to make certain that the responses are carried out as planned. It’s too easy to assume that the risk owners will attend to the risk responses—that assumption is a risk. Implementing risk responses creates the mechanisms to ensure that the response has been taken.

Preparing to Implement Risk Responses

To complete this process you’ll need three inputs:

   Risk management plan The roles and responsibilities of the risk management plan are needed to make certain the right people are carrying out the right responses. You’ll also need the risk management plan to identify and communicate the risk thresholds, which will signal when the risk response is needed.

   Project documents The lessons learned register, risk register, and risk report are inputs to this process.

   Organizational process assets Historical information from similar projects can help the project manager and the project team implement the risk responses.

Reviewing the Tools and Techniquesfor Implementing Risk Responses

You should be familiar with three tools and techniques for implementing risk responses:

   Expert judgment Expert judgment, a common tool and technique, is also used in implementing risk responses. Experts can help to implement the risk response or even modify the risk response based on conditions within the project.

   Interpersonal and team skills The project manager may need to influence the risk owner to act on the risk that needs the response. The risk owner could be outside of the project team, so influencing is the interpersonal skill that’s needed: influence that person to act to keep the project moving.

   Project Management Information System The PMIS can help to ensure that the risk response activities are integrated into the schedule, resource planning, and cost of the project.

Examining the Results of Implementing Risk Responses

There are just two results of implementing risk responses:

   Change requests As you might expect, change requests could be generated because the risk response may cause a change to the project’s cost or schedule baseline. The change request must be documented and must flow through the integrated change control process.

   Project document updates Lots of project documents could be updated because of the risk response. Documents that might need updating include the issue log, lessons learned register, project team assignments, risk register, and the risk report.

CERTIFICATION OBJECTIVE 11.07

Monitoring Risks

Risks must be actively monitored, and new risks must be responded to as they are discovered. Risk monitoring is the process of monitoring identified risks for signs that they may be occurring, addressing identified risks with the agreed-upon responses, looking for new risks that may creep into the project, and then following the outcomes of the risk responses to track their effectiveness. Risk monitoring also is concerned with the documentation of the success or failure of risk response plans and keeping records of metrics that signal risks are occurring, fading, or disappearing from the project.

Risk monitoring is an active process that requires participation from the project manager, the project team, key stakeholders, and, in particular, risk owners within the project. As the project progresses, risk conditions may change and require new responses, additional planning, or the implementation of a contingency plan.

There are several goals to risk monitoring:

   To confirm that risk responses are implemented as planned

   To determine whether risk responses are effective or whether new responses are needed

   To determine the validity of the project assumptions

   To determine whether risk exposure has changed, evolved, or declined due to trends in the project progression

   To monitor risk triggers

   To confirm that policies and procedures happen as planned

   To monitor the project for new risks

   To confirm the continued validity of the risk management approach

   To determine whether the project contingency reserves (cost and schedule) are adequate

Preparing for Risk Monitoring

Risk monitoring is an active process. The project team and the project manager must rely on several inputs to monitor and address risks effectively:

   The risk management plan Defines the organization’s approach to risk management. It is not the strategy for specific risks within a project, but the overall strategy for risk analysis and planning.

   Project documents The central repository for all project risk information, the risk register, is the primary document you’ll need. The risk register includes the identified risks, the potential responses, the root causes of risks, and any identified categories of risk. You may also reference the lessons learned register, the issue log, and the risk report.

   Work performance data and work performance reports The results of project work can inform the project manager and the project team of new and pending risks. In addition, project team members may create reports to monitor or document risks. Project performance focuses on the balance of the project schedule, costs, and scope. Should the performance of time, cost, or scope suffer, new risks are likely to enter the project.

Completing Risk Monitoring

Risk monitoring happens throughout the project—it is not a solitary activity that is completed once and never revisited. The project manager and the project team must actively monitor risks, respond with the agreed-upon actions, and scan the horizon for risks that have not been addressed. Risk monitoring is a recurring activity that requires input from all project participants. Several tools are available for implementing risk monitoring, and they are discussed in the following sections.

Completing Risk Response Audits

A risk response audit examines the planned risk response, how well the planned actions work, and the effectiveness of the risk owner in implementing the risk response. The project manager is responsible to ensure that audits happen throughout the project to measure the effectiveness of mitigating, transferring, and avoiding risks. The risk response audit should measure the effectiveness of the decision and its impact on schedule and cost.

Completing Periodic Risk Reviews

Project risk should be on the agenda at every project team meeting. The periodic risk review is a risk reassessment scheduled regularly throughout the project to ascertain the level of foreseeable risks and the success of risk responses in the project to date, and to review pending risks. Based on circumstances within the project, risk rankings and prioritization may fluctuate. Changes to the project scope, team, or conditions may require qualitative and quantitative analyses.

Using Earned Value Analysis

Earned value analysis measures project performance. When project performance is waning, the project is likely missing targeted costs and schedule goals. The results of earned value analysis can signal that risks are happening within the project or that new risks may be developing.

For example, a schedule performance index (SPI) of 0.93 means the project is off schedule by 7 percent. A risk based on this value could mean that the project team is having difficulty completing the project work as planned. Additional work will continue to be late, the project will finish late, and quality may suffer as the team attempts to rush to complete assigned tasks.

Measuring Technical Performance

Throughout the project, the project team’s technical competence with the technology being used in the project should increase. The level of technical achievement should be in proportion to the expected level of technical performance within the project. If the project team is not performing at a level of expected technical expertise, the project may suffer additional risks resulting from the discrepancy. Technical performance can be measured by the successful completion of activities throughout the project or project phases.

Completing Additional Risk Planning

Most likely, new risks will become evident during the project implementation. The project team, project manager, and key stakeholders who discover the risks should communicate them. The risks must then be acknowledged, documented, analyzed, and planned for. The project team must be encouraged to communicate the discovery of new risks.

Often, project team members don’t want to share discovered risks with the project manager because the presence of a risk can be seen as bad news. The project manager must stress to the project team members that identified risks should be communicated so that the risks can be planned for through escalation, avoidance, mitigation, transference, or even acceptance.

When a risk event occurs and the project manager uses a portion of the risk reserve, it’s necessary to examine the balance of the contingency reserve in relation to the risks still in the project. In other words, you’ll want to see how much the risk event has cost the project and determine whether enough funds remain in the contingency reserve to cover the remaining risk events should any of these events happen. Reserve analysis is a necessary practice throughout the project.

Examining the Results of Risk Monitoring

Risk monitoring helps the project become more successful. It measures the planned responses to risks and creates reactions to unplanned risks. The outputs of risk monitoring also aim to help the project reach its objectives. The process has several outputs:

   Work performance information What happens in the project because of monitoring risks and risk responses will create work performance information. This information affects what needs to be communicated and what actions the project manager and team may take next, and it helps with project decisions.

   Change requests Risk monitoring may cause the project’s cost or schedule baseline to need to be updated. The update of a baseline will need a change request that follows the integrated change control process. Project management plan updates could also be an output of this process, and these updates will also require a change request. Corrective actions are taken to bring the project back into compliance with the project plan. Preventive actions are taken to bring the project back into alignment with the project management plan.

   Project document updates As the project moves along and the project manager and the project team complete the risk assessments, audits, and risk reviews, they’ll need to record their findings in the risk register, risk report, or both. This update may include the reevaluation of the risk’s impact, probability, and expected monetary value. For those risks that have passed in the project, the risk register should record what happened with the risk event and its impact on the project. The project’s assumption log, issue log, lessons learned register, risk register, and risk report can all be updated because of this process.

   Organizational process assets updates The risks from the current project can help other project managers in the future. Therefore, the project manager must work to ensure that the current risks, their anticipated impact, and their actual impact are recorded. The current risk matrix, for example, can become a risk template for other projects in the future. This is true for just about any risk document—from risk responses, to the risk breakdown structure, lessons learned, and checklists.

   Project management plan updates All component plans are potentially updated as some risk responses will require change requests that require that the project management plan to be updated. As risks occur, the responses to those risks should be documented and updated in the risk response plan. Should risk rankings change during the project, the change in ranking, the logic behind the change, and the results of the risk rank change should be documented in the individual risk response plans. For the risks that do not occur, the risks should be documented and considered closed in the risk response plan. Issue and assumption logs as well as the lessons learned may also need to be updated.

CERTIFICATION SUMMARY

PMP candidates must have a firm grasp on how to plan for, monitor, and respond to projects’ risks. To handle risks effectively, the project manager needs to begin with risk management planning. A large, complex project will likely have more risks than a smaller project. In any situation, however, risks must be identified and planned for. The performing organization will often have risk management policies that dictate how the risk planning sessions are to be performed and what level of risks call for additional planning.

Some stakeholders—and organizations—will be more tolerant than others of accepting risks.

Qualitative risk analysis qualifies identified risks and creates a prioritization of each. Every risk is considered for its impact and likelihood of occurring. Once the risks have passed through qualitative risk analysis, quantitative risk analysis can be done if appropriate for the project. Quantitative risk analysis assesses the probability and impact of the risks, and it determines a risk score based on further analysis, discussion, expert judgment, simulations, and interviews with stakeholders.

Risk responses are created and risk owners are assigned. Thresholds and triggers are identified for the risks, and these are then monitored throughout the project. Risk responses are then implemented. Risk monitoring tracks the risk response effectiveness and the conditions of the risk events, and periodically reviews the status of risks, including the low-level risk watch list, to see if the probability and/or impact of the risks have changed.

KEY TERMS

If you’re serious about passing the PMP exam, memorize the following terms and their definitions. For maximum value, create your own flashcards based on these definitions and review them daily. You can find additional information on these terms in the project glossary.

acceptance   A response to a risk event, generally made when the probability of the event and/or its impact is small. No proactive action is taken on the risk. It is used when escalation, mitigation, transference, and avoidance are not selected.

ambiguity risks   These risks are impossible to predict accurately: certainty of a new technical solution, future laws or regulations, or even complexity in the project approach.

avoidance   One response to a risk event. The risk is avoided by removing the risk from the project.

brainstorming   The most common approach to risk identification; it is performed by a project team to identify the risks within the project. A multidisciplinary team, hostedby a project facilitator, can also perform brainstorming.

bubble chart   A hierarchical chart that uses three parameters for mapping the axes of the risks and the magnitude of the third parameter. The larger the bubble the more significant parameter.

cause-and-effect diagrams   Used for root-cause analysis of what factors are creating the risks within the project. The goal is to identify and treat the root of the problem, not the symptom.

commercial risks   When working with vendors, new risks are introduced to the project specific to the contractual relationship. Risk categories can include the contract terms, internal procurement procedures, suppliers, subcontracts, client and customer stability, and any partnerships or joint ventures.

contingency reserve   A time or dollar amount allotted as a response to risk events that may occur within a project.

decision tree analysis   A type of analysis that determines which of two decisions is the best. The decision tree assists in calculating the value of the decision and determining which decision costs the least.

Delphi Technique   A method to survey experts anonymously on foreseeable risks within the project, phase, or component of the project. The results of the survey are analyzed and organized, and then circulated to the experts. There can be several rounds of anonymous discussions when using the Delphi Technique. The goal is to gain consensus on project risks, and the anonymous nature of the process ensures that no one expert’s advice overtly influences the opinions of other participants.

enhance   To enhance a risk is to attempt to modify its probability and/or its impacts to realize the most gains from it. Enhance applies only to positive risks (opportunities).

escalate risk response   Some risks that are outside of the boundary of the project should be escalated when the project team, project sponsor, or project manager believes the risk management would exceed the authority the project manager has over the risk event.

exploit   The organization wants to ensure that the identified risk does happen to realize the positive impact associated with the risk event.

individual project risks   An individual risk that hinders or helps realize the project objectives.

influence diagram   A diagram that charts out a decision problem. It identifies all of the elements, variables, decisions, and objectives—and how each factor may influence another.

mitigation   A process of reducing the probability or impact of a risk.

overall project risk   A combination of all risk events that will reveal the project’s risk exposure and determine just how risky the project is for the organization.

PESTLE   Analysis of overall project risks by determining political, economic, social, technological, legal, and environmental uncertainty.

qualitative risk analysis   An examination and prioritization of the risks based on their probability of occurring and the impact on the project if they do occur. Qualitative risk analysis guides the risk reaction process.

quantitative risk analysis   A numerical assessment of the probability and impact of the identified risks. Quantitative risk analysis also creates an overall risk score for the project.

residual risks   Risks that are left over after mitigation, transference, and avoidance. These are generally accepted risks. Management may elect to add contingency costs and time to account for the residual risks within the project.

risk   An uncertain event that can have a positive or negative influence on the project’s success.

risk categories   These help organize, rank, and identify risks within the project.

risk management plan   A subsidiary project management plan for determining how risks will be identified, how quantitative and qualitative analyses will be completed, how risk response planning will happen, how risks will be monitored, and how ongoing risk management activities will occur throughout the project life cycle.

risk owners   The individuals or groups responsible for a risk response.

risk register   Documentation of all risk events and their conditions, impact, probability, and overall risk score.

risk report   A document that explains the overall project risks and provides a summary about the individual project risks. You’ll update the risk report through the project as more information becomes available through analysis and experience in the project.

scales of probability and impact   Used in a risk matrix in both qualitative risk analysis and quantitative risk analysis to score each risk’s probability and impact.

secondary risks   Risks that stem from risk responses. For example, the response of transference may call for hiring a third party to manage an identified risk. A secondary risk caused by the solution is the failure of the third party to complete its assignment as scheduled. Secondary risks must be identified, analyzed, and planned for, just like any other identified risk.

sensitivity analysis   Examines each project’s risk on its own merit to assess the impact on the project. All other risks in the project are set at a baseline value.

share   Sharing is nice. When sharing, the risk ownership is transferred to the organization that can most capitalize on the risk opportunity.

simulation   Allows the project team to do “what-if” analysis without affecting any areas of production.

system or process flowcharts   Show the relationship between components and how the overall process works. They are useful for identifying risks between system components.

TECOP   Analysis of overall project risks by determining technical, environmental, commercial, operational, and political uncertainty.

transference   A response to risks in which the responsibility and ownership of the risk are transferred to another party (for example, through insurance).

triggers   Warning signs or symptoms that a risk has occurred or is about to occur (for example, a vendor failing to complete their portion of the project as scheduled).

utility function   A person’s willingness to accept risk. The higher the utility function, the more likely the person or organization is willing to accept risk.

variability risks   Uncertainty surrounding a project activity or decision. Fluctuations in productivity, number or errors and defects, or even the weather affecting the project are all examples of variability risks.

VUCA   Analysis of overall project risks by determining volatility, uncertainty, complexity, and ambiguity.

workarounds   Unplanned responses to risks that were not identified or expected.

TWO-MINUTE DRILL

Planning for Risk Management

   Risk management planning involves determining how the risk management activities within the project will take place. It is not the response or identification of risks, but the determination of how to manage project risks.

   Risk management planning is accomplished through planning meetings with the project team, management, customers, and other key stakeholders.

   A utility function, also called risk tolerance, is a stakeholder’s willingness to accept or tolerate risks.

   Risks are uncertain events that can affect a project’s objectives for good or bad.

   Risks can be placed into four different categories: technical, management, commercial, and external risks.

   The risk management plan defines the process to identify, analyze, respond to, and monitor all project risk events.

Identifying Risks

   Project records from published information and previous projects can serve as input to risk identification.

   Assumptions are things that are believed to be true but that haven’t been proven to be true. Assumptions can become risks based on the assumption stability and consequence if the assumption is false.

   Triggers are warning signs that a risk is about to happen or has happened.

Using Qualitative Risk Analysis

   Qualitative risk analysis is a high-level, fast analysis of the identified project risks.

   Risks are evaluated for their impact and likelihood.

   Risks can be ranked in an ordinal fashion by using indicators such as very low, low, moderate, high, and very high.

   Risks can also be analyzed using a cardinal ranking system of numeric values that are assigned to each risk based on its impact and probability.

   An overall project risk ranking can be used to compare the current projects with other projects in the organization.

   Risks that have a high score from qualitative analysis can be moved into quantitative analysis for further study.

Preparing for Quantitative Risk Analysis

   Risks are assigned an expected monetary value—for example, there is a 50 percent likelihood that the risk will occur, causing a $10,000 cost.

   Quantitative analysis is an in-depth study of the risk’s probability and impact.

   Risks and their impacts, status, responses, and updates are all recorded in the risk register.

Planning for Risk Responses

   Risk response planning focuses on reducing threats and increasing opportunities as a result of risks.

   Risk tolerance or appetite, documented in risk management planning, describes the acceptable level of risk within a company.

   Risk owners are the individuals or groups that are responsible for a risk response and that should participate in the risk response planning.

   Enhancing a positive risk requires that the organization take steps to increase the probability and/or impact of the risk.

Implementing Risk Responses

   Risk avoidance changes the project plan to avoid the risk (as well as conditions that promote the risk).

   Risk transference moves the risk consequence to a third party. The risk doesn’t go away, but the responsibility for it is shifted. However, the performing organization still retains the ultimate accountability and results of the risk event.

   Risk mitigation involves actions designed to reduce the likelihood of a risk occurring, the impact of a risk on the project objectives, or both.

   Risk acceptance acknowledges that the risk exists but deems it unworthy of a more in-depth response, or a more in-depth response isn’t available for the risk.

   Residual risks remain after avoidance, transference, mitigation, and acceptance.

   Secondary risks are new risks that arise from a risk response.

   To exploit a positive risk requires that an organization implement measures to ensure that the risk happens.

   Sharing a risk assigns ownership of the positive risk to an organization that is most likely to utilize the positive risks for the benefit of the project.

Monitoring Risks

   Identified risks must be tracked, monitored for warning signs, and documented. The responses to the risks are monitored and documented as successful or less successful than expected.

   Risk response audits measure the success of the responses and the effectiveness of the cost, scope, and quality values gained or lost by the risk responses.

   Earned value analysis can measure project performance, but it can also predict and signal pending risks within the project.

   As unexpected risks arise, the project team may elect to use workarounds to diminish the impact and probability of those risks. Workarounds, however, should be documented and incorporated into the project plan and risk response plan as they occur.

SELF TEST

1.   Beth is the project manager for her company, and Marty, her supervisor, is concerned with the possibility of Beth accepting one of the project risks. Beth explains that this risk should be accepted within the project. When is it appropriate to accept a project risk?

A.   It is never appropriate to accept a project risk.

B.   All risks must be mitigated or transferred.

C.   It is appropriate to accept a risk if the project team has never completed this type of project work before.

D.   It is appropriate to accept a risk if the risk is in balance with the reward.

2.   Frances is the project manager of the LKJ Project. Which of the following techniques will she use to create the risk management plan?

A.   Risk tolerance

B.   Status meetings

C.   Planning meetings

D.   Variance meetings

3.   You are the project manager of the HQQ Project, and part of your requirement in this role is to create a risk management plan. Which of the following is not part of a risk management plan?

A.   Roles and responsibilities

B.   Methodology

C.   Technical assessment board compliance

D.   Risk categories

4.   You are the project manager of the GHK Project. You and the manufacturer have agreed to substitute the type of plastic used in the product to a slightly thicker grade should there be more than a 7 percent error in production. The thicker plastic will cost more and require a production slowdown, but the errors should diminish. This is an example of which of the following?

A.   Threshold

B.   Tracking

C.   Budgeting

D.   JIT manufacturing

5.   Hans is a project manager for his organization, and he’s working with his sponsor to identify the organization’s risk tolerance. Understanding the risk tolerance and any associated enterprise environmental factors will help Hans and the project team plan for risk responses. An organization’s risk tolerance is also known as what?

A.   The utility function

B.   Herzberg’s Theory of Motivation

C.   Risk acceptance

D.   The risk–reward ratio

6.   As a project manager, you must understand the components of an identified risk, a risk response, a risk trigger, risk thresholds, and issues. A risk trigger is also called which of the following?

A.   A warning sign

B.   A delay

C.   A cost increase

D.   An incremental advancement of risk

7.   The customers of the project have requested additions to the project scope. The project manager brings notice that additional risk planning will need to be added to the project schedule. Why?

A.   The risk planning should always take the same amount of time as the activities required by the scope change.

B.   Risk planning should always occur whenever the scope is adjusted.

C.   Risk planning should occur only at the project manager’s discretion.

D.   The project manager is incorrect. Risk planning does not need to happen at every change in the project.

8.   You are the project manager of your organization, and you’re working with your project team and the project stakeholders to identify the risks within the project. Some of the risks have not yet happened, and some of the risks are already issues. You tell the project team that all risks must be documented in the risk register, but they are not familiar with this document. Which one of the following best describes the risk register?

A.   It documents the individual risks.

B.   It’s a document that contains the initial risk identification entries.

C.   It’s a system that tracks all negative risks within a project.

D.   It’s part of the project’s PMIS for integrated change control.

9.   An understanding of the different types of risk events can help the project manager work better with the enterprise environmental factors and the organizational process assets that affect the risk management in a project. Based on this information, a _______________ include(s) fire, theft, or injury, and offer(s) no chance for gain.

A.   Business risks

B.   Pure risks

C.   Risk acceptance

D.   Life risks

10.   Complete this sentence: A project risk is a(n) _______________ occurrence that can affect the project for good or bad.

A.   Known

B.   Dangerous

C.   Uncertain

D.   Known-unknown

11.   Risk identification is an iterative process in the project and requires participation from the project manager, the project team, and other key stakeholders. Because of the nature of risk, when should risk identification happen?

A.   As early as possible in the initiation process

B.   As early as possible in the planning process

C.   Throughout the product management life cycle

D.   Throughout the project life cycle

12.   You are the project manager of the KLJH Project. This project will last two years and has 30 stakeholders. How often should risk identification take place?

A.   Once at the beginning of the project

B.   Throughout the execution processes

C.   Throughout the project

D.   Once per project phase

13.   You are the project manager of the HNN Project and you’re working with the project stakeholders, including the project team and the project sponsor, to identify risks within the project. You have identified an opportunity that the organization could take advantage of as an additional revenue stream. As the project manager, what’s the best risk response to choose for this risk?

A.   Exploit

B.   Enhance

C.   Escalate

D.   Share

14.   You are the project manager for a project that will create a new and improved web site for your company. Currently, your company has more than 8 million users around the globe. You would like to poll experts within your organization with a simple, anonymous form asking about any foreseeable risks in the design, structure, and intent of the web site. With the collected information, subsequent anonymous polls will be submitted to the group of experts. This is an example of _______________.

A.   Risk identification

B.   A trigger

C.   An anonymous trigger

D.   The Delphi Technique

15.   As a PMP candidate, you must be familiar with the different approaches to risk identification. One approach is called SWOT. Which of the following describes SWOT?

A.   An analysis of strengths, weakness, options, and timing

B.   An analysis of strengths, weakness, opportunities, and threats

C.   An elite project team that comes in and fixes project risks and threats

D.   Ratings of 1 to 100

16.   You are the project manager of the GLI Project for your organization. Your project sponsor has asked that you use an approach to measure the probability and impact of the risk events and then to rank the events accordingly. Which risk analysis provides the project manager with a risk ranking?

A.   Quantifiable

B.   Qualitative

C.   The utility function

D.   SWOT analysis

17.   A table of risks, their probability, their impact, and a number representing the overall risk score is called a _______________.

A.   Risk table

B.   Probability and impact matrix

C.   Quantitative matrix

A.   Qualitative matrix

18.   You are presented with the following table:

What is the EMV for Risk Event 3?

A.   $135

B.   –$300

C.   $45

D.   –$135

19.   You are presented with the following table:

Based on the preceding numbers, what is the amount needed for the contingency fund?

A.   Unknown with this information

B.   $249,000

C.   $117,150

D.   $15,750

20.   The water sanitation project manager has determined that the risks associated with handling certain chemicals are too high. He has decided to allow someone else to complete this portion of the project, so he has outsourced the handling and installation of the chemicals and filter equipment to an experienced contractor. This is an example of which of the following?

A.   Avoidance

B.   Acceptance

C.   Mitigation

D.   Transference

21.   A project manager and the project team are actively monitoring the pressure gauge on a piece of equipment. Sarah, the engineer, recommends a series of steps to be implemented should the pressure rise above 80 percent. The 80 percent mark represents what?

A.   An upper control limit

B.   The threshold

C.   Mitigation

D.   A workaround

22.   You are presented with the following table:

What would Risk 6 be based on the following information: Marty is 60 percent certain that he can get the facility needed for $45,000, which is $7000 less than what was planned for?

A.   .60, 45,000, 27,000

B.   .60, 52,000, 31,200

C.   .60, 7000, 4200

D.   .60, –7000, –4200

23.   What can a project manager use to determine whether it is better to make or buy a product?

A.   A decision tree analysis

B.   A fishbone model

C.   An Ishikawa diagram

D.   An ROI analysis

24.   Which of the following can determine multiple scenarios, given various risks and the probability of their impact?

A.   Decision trees

B.   Monte Carlo simulations

C.   Pareto charts

D.   Gantt charts

25.   Gary is a project manager for his organization and he’s evaluating the risks within his project. Some of the risk events have a high impact, while other risk events have a low probability. In this project, many risks have high-risk impact scores but an overall low-risk score. How is this possible?

A.   The risk scores are graded on a bell curve.

B.   The probability of each risk is low.

C.   The impact of each risk is not accounted for until it comes to fruition.

D.   The risks are rated high, medium, or low.

SELF TEST ANSWERS

1.   Beth is the project manager for her company, and Marty, her supervisor, is concerned with the possibility of Beth accepting one of the project risks. Beth explains that this risk should be accepted within the project. When is it appropriate to accept a project risk?

A.   It is never appropriate to accept a project risk.

B.   All risks must be mitigated or transferred.

C.   It is appropriate to accept a risk if the project team has never completed this type of project work before.

D.   It is appropriate to accept a risk if the risk is in balance with the reward.

2.   Frances is the project manager of the LKJ Project. Which of the following techniques will she use to create the risk management plan?

A.   Risk tolerance

B.   Status meetings

C.   Planning meetings

D.   Variance meetings

3.   You are the project manager of the HQQ Project, and part of your requirement in this role is to create a risk management plan. Which of the following is not part of a risk management plan?

A.   Roles and responsibilities

B.   Methodology

C.   Technical assessment board compliance

D.   Risk categories

4.   You are the project manager of the GHK Project. You and the manufacturer have agreed to substitute the type of plastic used in the product to a slightly thicker grade should there be more than a 7 percent error in production. The thicker plastic will cost more and require a production slowdown, but the errors should diminish. This is an example of which of the following?

A.   Threshold

B.   Tracking

C.   Budgeting

D.   JIT manufacturing

5.   Hans is a project manager for his organization, and he’s working with his sponsor to identify the organization’s risk tolerance. Understanding the risk tolerance and any associated enterprise environmental factors will help Hans and the project team plan for risk responses. An organization’s risk tolerance is also known as what?

A.   The utility function

B.   Herzberg’s Theory of Motivation

C.   Risk acceptance

D.   The risk–reward ratio

6.   As a project manager, you must understand the components of an identified risk, a risk response, a risk trigger, risk thresholds, and issues. A risk trigger is also called which of the following?

A.   A warning sign

B.   A delay

C.   A cost increase

D.   An incremental advancement of risk

7.   The customers of the project have requested additions to the project scope. The project manager brings notice that additional risk planning will need to be added to the project schedule. Why?

A.   The risk planning should always take the same amount of time as the activities required by the scope change.

B.   Risk planning should always occur whenever the scope is adjusted.

C.   Risk planning should occur only at the project manager’s discretion.

D.   The project manager is incorrect. Risk planning does not need to happen at every change in the project.

8.   You are the project manager of your organization, and you’re working with your project team and the project stakeholders to identify the risks within the project. Some of the risks have not yet happened, and some of the risks are already issues. You tell the project team that all risks must be documented in the risk register, but they are not familiar with this document. Which one of the following best describes the risk register?

A.   It documents the individual risks.

B.   It’s a document that contains the initial risk identification entries.

C.   It’s a system that tracks all negative risks within a project.

D.   It’s part of the project’s PMIS for integrated change control.

9.   An understanding of the different types of risk events can help the project manager work better with the enterprise environmental factors and the organizational process assets that affect the risk management in a project. Based on this information, a _______________ include(s) fire, theft, or injury and offer(s) no chance for gain.

A.   Business risks

B.   Pure risks

C.   Risk acceptance

D.   Life risks

10.   Complete this sentence: A project risk is a(n) _______________ occurrence that can affect the project for good or bad.

A.   Known

B.   Dangerous

C.   Uncertain

D.   Known-unknown

11.   Risk identification is an iterative process in the project and it requires participation from the project manager, the project team, and other key stakeholders. Because of the nature of risk, when should risk identification happen?

A.   As early as possible in the initiation process

B.   As early as possible in the planning process

C.   Throughout the product management life cycle

D.   Throughout the project life cycle

12.   You are the project manager of the KLJH Project. This project will last two years and has 30 stakeholders. How often should risk identification take place?

A.   Once at the beginning of the project

B.   Throughout the execution processes

C.   Throughout the project

D.   Once per project phase

13.   You are the project manager of the HNN Project and you’re working with the project stakeholders, including the project team and the project sponsor, to identify risks within the project. You have identified an opportunity that the organization could take advantage of as an additional revenue stream. As the project manager, what’s the best risk response to choose for this risk?

A.   Exploit

B.   Enhance

C.   Escalate

D.   Share

14.   You are the project manager for a project that will create a new and improved web site for your company. Currently, your company has more than 8 million users around the globe. You would like to poll experts within your organization with a simple, anonymous form asking about any foreseeable risks in the design, structure, and intent of the web site. With the collected information, subsequent anonymous polls will be submitted to the group of experts. This is an example of _______________.

A.   Risk identification

B.   A trigger

C.   An anonymous trigger

D.   The Delphi Technique

15.   As a PMP candidate, you must be familiar with the different approaches to risk identification. One approach is called SWOT. Which of the following describes SWOT?

A.   An analysis of strengths, weakness, options, and timing

B.   An analysis of strengths, weakness, opportunities, and threats

C.   An elite project team that comes in and fixes project risks and threats

D.   Ratings of 1 to 100

16.   You are the project manager of the GLI Project for your organization. Your project sponsor has asked that you use an approach to measure the probability and impact of the risk events and then to rank the events accordingly. Which risk analysis provides the project manager with a risk ranking?

A.   Quantifiable

B.   Qualitative

C.   The utility function

D.   SWOT analysis

17.   A table of risks, their probability, their impact, and a number representing the overall risk score is called a _______________.

A.   Risk table

B.   Probability and impact matrix

C.   Quantitative matrix

D.   Qualitative matrix

18.   You are presented with the following table:

What is the Ex$V for Risk Event 3?

A.   $135

B.   –$300

C.   $45

C.   –$135

19.   You are presented with the following table:

Based on the preceding numbers, what is the amount needed for the contingency fund?

A.   Unknown with this information

B.   $249,000

C.   $117,150

D.   $15,750

20.   The water sanitation project manager has determined that the risks associated with handling certain chemicals are too high. He has decided to allow someone else to complete this portion of the project, so he has outsourced the handling and installation of the chemicals and filter equipment to an experienced contractor. This is an example of which of the following?

A.   Avoidance

B.   Acceptance

C.   Mitigation

D.   Transference

21.   A project manager and the project team are actively monitoring the pressure gauge on a piece of equipment. Sarah, the engineer, recommends a series of steps to be implemented should the pressure rise above 80 percent. The 80 percent mark represents what?

A.   An upper control limit

B.   The threshold

C.   Mitigation

D.   A workaround

22.   You are presented with the following table:

What would Risk 6 be based on the following
information: Marty is 60 percent certain that he can get the facility needed for $45,000, which is $7000 less than what was planned for?

A.   .60, $45,000, $27,000

B.   .60, $52,000, $31,200

C.   .60, $7000, $4200

D.   .60, –$7000, –$4200

23.   What can a project manager use to determine whether it is better to make or buy a product?

A.   A decision tree analysis

B.   A fishbone model

C.   An Ishikawa diagram

D.   An ROI analysis

24.   Which of the following can determine multiple scenarios, given various risks and the probability of their impact?

A.   Decision trees

B.   Monte Carlo simulations

C.   Pareto charts

D.   Gantt charts

25.   Gary is a project manager for his organization and he’s evaluating the risks within his project. Some of the risk events have a high impact, while other risk events have a low probability. In this project, many risks have high-risk impact scores but an overall low-risk score. How is this possible?

A.   The risk scores are graded on a bell curve.

B.   The probability of each risk is low.

C.   The impact of each risk is not accounted for until it comes to fruition.

D.   The risks are rated high, medium, or low.