risk management - elearning.esi-intl.comelearning.esi-intl.com/blendedlearning/ilt/ctl_v3... ·...

Risk Management

Risk ManagementPMC:CTL:EN:000 ver. 3.2

© 2016 StrategyExecutionMarch 2016All rights reserved.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of TwentyEighty Strategy Execution.

TwentyEighty Strategy Execution grants federal government users "Restricted Rights" (as the term is defined in FAR 52.227-14 and DFARS 252.227-7013). Use, reproduction, or disclosure of these materials is subject to the restrictions set forth in the MOBIS, FSS, or contract under which the materials were provided.

All material from A Guide to the Project Management Body of Knowledge (PMBOK® Guide) is reprinted with permission of the Project Management Institute, Four Campus Boulevard, Newtown Square, Pennsylvania 19073-3299, USA, a worldwide organization of advancing the state-of-the-art in project management. Phone: (610) 356-4600, Fax: (610) 356-4647.

PMI® did not participate in the development of this publication and has not reviewed the content for accuracy. PMI® does not endorse or otherwise sponsor this publication and makes no warranty, guarantee, or representation, expressed or implied, as to its accuracy or content. PMI® does not have any financial interest in this publication and has not contributed any financial resources.

The names of all companies and characters used in these materials are purely fictional. Any resemblance to any existing or no longer existing company, or living or dead person is not intended, and is purely coincidental.

PMI, PMBOK, and PMP are registered marks of the Project Management Institute, Inc.

TwentyEighty Strategy ExecutionArlington, VA USA

Module 1Foundations of Risk

Module Introduction

Module OverviewThis module introduces the fundamentals of risk in a project.

Introduction to Risk

Risk OverviewAny study of risk and risk management should begin with the fundamentals: those basic terms and concepts that underlie all the more detailed methods and activities that project managers and their organizations apply and undertake. Some of these terms and concepts are related to the project itself, because it is the project manager who is ultimately responsible for risk management in his or her project. Others relate strictly to the discipline of risk management. In any event, risk is something that is a part of every project and has to be continuously evaluated and dealt with throughout the project life cycle.

Whether you are encountering some of these terms for the first time or whether you are an accomplished project manager, you have undoubtedly experienced the realities of risk events in a project. In fact, a project manager is in simple terms a risk manager. Every project contains some level of risk. If it did not, it would not be worth pursuing. As a result, project managers have to live with the reality of risk. Their challenge is managing it.

Key Risk DefinitionsRisk is an uncertain event or condition that, if it occurs, has a positive or negative effect on a project objective. Notice that in the definition, we clearly stated that there is either a positive or negative effect on the project. “Risk” is one of those words that immediately conjures up the image of something bad. But it is important to remember that risk can also provide positive benefits as well as negative ones. We will discuss this in more detail later.

Risk management is the systematic process of identifying, analyzing, and responding to project risk. We want to maximize the probability and the impact of any positive risk factors and minimize the probability and impact of those that might negatively affect the project.

Module 1: Foundations of Risk

©2016 StrategyExecution PMC:CTL:EN:000 ver. 3.2 1

Some organizations establish a “risk office” or assign a person to be the risk manager. This generally is a mistake. The project manager is ultimately responsible for risk, and taking the risk function out of the project or establishing it as a separate function from the project may cause the project manager to be less careful about risk events because someone else is responsible for them. Besides, a person or group outside the project knows less about the project requirements (and consequently its risks) than the project manager and the project team do.

So as a project manager, assume you are responsible for the risks in your project because, frankly, you are.

Risk Characteristics and Exposure

Three Defining ElementsA project risk has three defining elements:

It is a definable event.There is a probability the event will occur.There is a consequence to the project if the event occurs.

The event is what could happen, both good and bad, to the project. Remember that risk by itself is a neutral word; it could be something devastating that might happen, or it could be an opportunity to improve the organization’s capability or profit. Regardless, the risk event is what could happen to the project.

It is very important to determine when a risk event might occur. If the event is likely to occur early in the project life cycle, then it must be addressed immediately. Potentially long-term risk events, that is, events that probably will occur later in the project life cycle, must be planned for but don’t have to be addressed immediately (other than for contingency planning).

The frequency of an event also is important to determine. A risk event, even a low risk event, can be disrupting and even disastrous to a project if it is likely to occur over and over. So if you can determine the likelihood that an event will keep occurring, it can help you plan for the eventuality and perhaps even eliminate the risk completely.

The probability of the risk is simply the chances the event will occur. Clearly, there may be a potential event, but if the chances of it occurring are slim to none, then it is not really a risk at all as a practical matter. As we will see later, it is important to consider this aspect of risk and, if possible, assign an actual percentage probability to the occurrence of risk events. Assigning a probability figure enables one to use additional planning tools in preparing against the risk’s impact.

The consequence of the occurrence of any risk event is measured in terms of its impact on the project. The project can have an identified risk event with a high probability of its happening; but


2 PMC:CTL:EN:000 ver. 3.2 ©2016 StrategyExecution

if the impact (even if it does happen) is low, then the risk can be ignored or at least tolerated.

With these elements described, the amount of risk exposure to the project and to the organization can be determined.

Risk ExposureRisk exposure is another way to describe the impact of a risk event occurring. Risk exposure is determined by multiplying the probability times the impact. Stated another way, most project managers equate risk exposure with expected value. (Expected value is a common measure used in risk and quality assessments, but it will be reviewed in a later module.) This is one instance in which the senior management is not particularly interested in the gain from a risk event; when he or she asks, “What is our risk exposure?” the interest is in determining what the cost to the project or organization could be.

One of the challenges the project manager and the project team face is defining risk. Even though we provided a definition of risk and described its elements, the reality is that everyone views risk differently. For example, if one asks, “What is the risk?” he or she may be asking for a description of the risk event.

Another person might ask, “What is the risk?” and be referring to the impact of the risk or the risk exposure to the organization. Thus, it is imperative that the project manager be well versed in risk management and particularly adept at determining exactly what the person wants to know. More importantly, the project manager must be able to describe exactly what the person wants to know within his or her frame of reference. The latter can be greatly aided by understanding the different types of risks.

Characteristics of Risk Events

Risk Events OverviewRecognizing risk characteristics aids in planning responses to them. One or more of several characteristics are inherent in every risk event. Risk events are—

SituationalTime-basedInterdependentMagnitude-dependentValue-based



SituationalBecause risks can occur from actions by team members, stakeholders (internal or external to the project), or just from the normal project activities, risk inevitably must be handled on a case-by-case basis. In short, risks are predictable only within limited parameters, and so the ongoing use of sound project management tools and techniques that are tried, documented, and available to team members is crucial.

Time-BasedRisk is a phenomenon that is time-based; it is always in the future. In fact, one can think of risk as a problem or opportunity that has not yet arisen. Time also has a way of affecting the perception of risk. If there is a lot of time remaining in a project, or if a long period of time has passed without any significant risk event occurring, then risk anxiety lessens. If there is less time available to accomplish a task or project, then risk anxiety heightens.

In the former case—having more time available—risk actually does lessen. The more time we have, the more we understand about the project requirements, how well the technical solution is working, and whether the proper personnel are on the project, and the more efficient the management processes, including risk management, are working.

InterdependentOne of the many problems in dealing with risks is that they are interdependent; any risk event may affect or even create others. This characteristic has two important ramifications. First, it means that every risk must be frequently assessed to ensure that there are no interdependencies or, if there are, that they are known and understood. Second, if the domino effect of interdependent risks is large enough, the immediate perception is that the project is too difficult. In the second case, a “too risky” project is one that loses stakeholder and team member support very rapidly.

Magnitude-DependentLow-risk events usually involve only a few people or relatively low costs. In other words, the risk is low enough that its effect on the project can be ignored. However, as the magnitude of the risk increases, it can impact many people, organizations, and costs. The fact that the risk impact is potentially greater is not necessarily bad; remember that risk has both a loss and gain component. For example, if the customer increases the scope of the project, the change might add increased risk to the organization because the new requirement(s) may involve work outside the organization’s expertise. However, the increased scope may mean larger profits if the organization can increase its skill base by either teaming with another company, hiring the requisite experience and skills needed, or negotiating a delay in providing the additional scope requirements until the skill sets are trained.

Again, if the perception of risk is that it is too big to be handled, then the project manager will lose stakeholder and team support. Arguably, the bigger problem is that risks can become so



big and affect so many people or groups of people that the cost of involvement in the project outweighs its potential payoff.

Value-BasedRisk means different things to different people. The banking industry, for example, is very conservative. Bankers do not lend money to people who have poor credit ratings. On the other hand, venture capitalists have no problem lending money for very risky ventures, provided the payoff is large. So risk management in each organization will take on a different complexion depending on the organization’s industry, its business goals, its culture, and how well it is equipped and trained to handle risks.

STIM-VIt is important to remember these risk characteristics because they affect how we plan our risk responses, which is discussed in more detail later in this text. One way to remember them is with the mnemonic, STIM-V, which stands for (S)ituational, (T)ime-based, (I)nterdependent, (M)agnitude-based, and (V)alue-based.

Risk Management and the Project

Risk Management Is Integrated with the Project Planning ProcessRisk management has to be performed throughout the project life cycle, and the identification of potential risk events is begun during the earliest project planning stages.

There are several steps in the risk planning process, and each one is discussed separately in detail in this text. But it is important to remember that the risk management process cannot be performed piecemeal; it must be done as a total process with every step reevaluated every time risk is assessed during the project. Generally, the steps of the risk process are—

IdentifyAnalyzePlan alternativesManage and control

These are the major steps, which will be expanded and discussed in depth in the next chapter when we introduce the Strategy Execution risk model. The reasons for introducing these steps here are twofold: to lead into how one can begin identifying risks during project planning; and, to accentuate the fact that there are specific steps to the risk management process that cannot be overlooked. This concept will become clearer during the following discussion.

At the beginning of a project, the earliest that you will have some sense of its risks is during the assessment of the requirements. The customer almost always makes some statements as to



when the product or service is needed. That statement potentially defines a risk. For example, if the customer states that the product must be operational by no later than a particular date, that may create a risk because it may not be possible to deliver by that date without extraordinary efforts such as working overtime, hiring new resources, teaming with another company, or engaging consultants. There also will be other statements in the requirements that indicate risks. For example, the customer may place restrictions on the budget and product reliability or maintenance requirements.

The next opportunity to identify risk is in the development of the WBS. The WBS is, in the opinion of most project managers, the best place to identify risks because after the tasks are identified, the attendant risks almost identify themselves. For example, if a required task is one that your organization has little or no expertise to deliver, then clearly it is a risk; or, even if your organization has the expertise, the resources may not be available when they are needed.

Another opportunity for identifying risk is while doing budget and schedule estimates. Obviously, when tasks are planned and the cost and time to do them are considered, there may or may not be an impact to the project. Again, it is a matter of pure resource availability and, during this assessment period, the skill sets that are needed and available.

Thus, every aspect of the planning process offers opportunities to identify risk. In addition, every project manager or team action or consideration should be weighed against other project considerations because every time a decision is made relative to one task, it invariably impacts other tasks.

By the time the cost, schedule, and scope baselines are defined and agreed upon, most of the risks in the project should be identified and assessed as to whether they represent real risks, response strategies should be developed, and an overall risk plan should be written.

Risk Management Is a Full Project Life-Cycle ResponsibilityThe best project managers are those who constantly evaluate and test their plans, and revise them on a regular basis. That is not to imply that the project’s baseline changes every few days; it does not. But planning by definition involves estimating, which does require reevaluating and refining. Every time any plan or any portion of a plan is updated, the risk management plan must be reevaluated and updated too. Thorough risk management is integral to the success of the project. Without it, the project may be doomed to failure before it ever begins.

But the news is not all dismal. As the project progresses, risk decreases. It decreases simply because we learn more about the project and its risks as time passes. Also, risk events that were predicted at the beginning of the project either may actually not occur; and if they do occur, our response strategies are put into place, and we know how well the project responded.

However, risk only decreases in the sense that the probability of a risk event happening decreases. The impact of a risk event, if it should happen, increases as the end of the project gets closer. This is true because by the time the project is in its final phases, the investment of time and money in the project is at its highest.



Responsibilities in Risk Management

Project Manager and Team Member Responsibility in Risk ManagementWe mentioned earlier that the project manager has ultimate responsibility for risk management in his or her project. We also mentioned that it is not wise to assign a separate person or group to be responsible for risk because the tendency is to assume someone is taking care of the risk problems when, in fact, he or she may not be. That does not mean that the project manager can’t assign task leaders or other team members to be responsible for watching the potential risks that have been identified in their tasks and for implanting the risk response strategy to cope with a risk should it happen.

The project manager is responsible for initiating and leading the risk management process. This is done by integrating the risk management plan into the project plan, and then ensuring that every team member is familiar with the identified potential risks, when they are likely to occur during the project life cycle, the task(s) they are likely to affect, and the approved response strategy to mitigate each risk.

The project team members are responsible for performing the risk management process by watching for risk triggers (that is, indicators that a risk event could occur), actually implementing the appropriate risk response strategy, and most importantly, reporting the status of the risk to the project manager. A closely coordinated risk management plan and a defined and documented risk management process will help ensure a smoothly run and successful project.

Knowing that the project manager is responsible for project risk management may not provide a sense of comfort, but considering how a good risk management program can benefit the project and organization, every project manager should strive to be an accomplished risk manager.

Benefits of Risk ManagementThere are several benefits of risk management. They include—



Minimizing management by crisis: When a risk event occurs, there is always a reactive response to it if the risk was not anticipated.Minimizing surprises and problems: As you will soon discover, identifying and planning for risk is the best way to avoid being surprised by it.Gaining competitive advantage: Any well-developed, documented, and implemented risk process reduces schedule and cost impacts of risk events, thus improving the organization’s advantage in the marketplace.Decreasing overall project variances: One major problem in project management is maintaining project progress within tight variances from the plan. Risk management is one of the principal ways of reducing these variances. If the risk is expected and a response is rapidly implemented, then the project’s planned track is more likely to be maintained.Increasing the probability of success: Keeping the project on its planned schedule and budget enhances the probability that the project can be completed successfully.Increasing profitability: Poor risk planning invariably leads to rework, scheduling problems, and cost overruns; good risk planning eliminates many of these problems and contributes directly to the bottom line.

Types of Risk

Are There Different Types of Risk?Actually, there are many different types of risk. Remember that we spoke of opportunity for gain and the possibility of loss when risk is considered. In a very real sense, that notion defines the types of risks that are confronted in a project. Basically, at least for all practical purposes, there are four types of risk that project managers and their teams need to be aware of. They are—

Business riskPure or insurable riskKnown riskUnknown risk

Business RiskBusiness risk is the normal risk of doing business and carries with it the potential for both loss and gain. For example, suppose the customer for a project decides to change the scope. The change may involve a negative risk, that is, loss, because it might require expertise that your organization does not possess. On the other hand, it might involve considerable gain because it could mean significantly more profit if you can accomplish the scope change efficiently. Business risk is the kind of risk an organization should not only embrace, but pursue. It is the type of risk we can manage.



Pure or Insurable RiskPure or insurable risk is the risk that is associated only with loss and has no opportunity for gain. This includes threats such as fire or hurricane. The organization needs to avoid or at least greatly reduce the direct impact of this form of risk by passing it on to another party. This can be accomplished by purchasing insurance or by teaming with another party that has the expertise to do the job.

Generally, we think of this kind of risk in terms of catastrophic events, such as fire, but the fact is, this kind of risk occurs when an organization attempts to do a job without having the requisite skill sets or expertise. Those are the cases where the solution is simply to team with a company that has the skill and expertise to accomplish the task(s) in question.

Known RiskKnown risk includes those risks one should naturally be aware of (such as scheduling problems because of limited or committed resources) that must be identified and watched. Known risks are usually manageable, because we know they exist and we know what has to be done to avoid or deal with them. It is almost always possible to develop a strategy that will deal with this type of risk. For example, if the known risk is that the schedule could be impacted because of a shortage of resources at a particular time, then the decision could be made to either hire additional resources, team with another company, outsource the work, or negotiate with the customer to delay work on that particular portion of the project.

Unknown RiskUnknown risk is not so easy to deal with. By its very definition, it includes risks that we cannot anticipate or plan for, except perhaps by adding money to the management reserve fund.

An unknown risk is, for example, a tornado that strikes in an area not usually susceptible to such weather phenomenon. The disease AIDS was an unknown risk before it hit millions of people.

Having reviewed the different types of risk, it is important to consider some of the characteristics of risk events themselves.

Factors Affecting Risk Perceptions

Risk Perceptions OverviewOrganizations and individuals have perceptions of risk that influence their approach to them. There are many reasons why project teams and organizations in general do not do a good job managing risk. Understanding these reasons and factors affecting the perception of risk is one key to improving the risk management process for your organization and your project.



The factors that most affect the perceptions of risk are—Lack of controlLack of informationTimeRisk preference

Lack of ControlMuch of project risk is not within the control of the project team. It is risk that is created by outside influences such as weather phenomena, environmental or other regulations, or even actions from other project and organizational activities. Perhaps the most common risks occur when one project’s schedule depends upon the schedule of resources within other projects. If a key task requires, for example, tests by an overworked, small, specialized test group within the organization, the risk of that task and the project’s schedule being affected has a high probability.

Notice that one of the exacerbating factors with the lack of control problem is that these risks tend to be unknowns. This is not always so, as the lack of testing capabilities example shows; but it very often is.

Lack of InformationLack of information is the norm, particularly in the early stages of risk identification. Generally, the lack of information is caused by incomplete or poorly stated requirements, unfamiliarity with the customer or the customer’s needs, or lack of experience or skills with the likely technical solution. The single biggest obstacle in obtaining adequate information is time. Given enough time, we could collect all the relevant data needed to identify and plan for nearly every risk, but most projects must meet either a customer’s operational schedule or time to market imperative.

TimeIn addition to the impact of time on how much information is or is not available, time has other important implications as well, some perceptual and some real.

The farther the potential risk event is into the future, the greater the degree is of uncertainty about the risk impact, should the event occur. On the other hand, the perception often is out of sight and out of mind. We tend to become complacent about the risk, and unless a conscientious effort is made to continue assessing it, the risk event’s occurrence may come as a surprise and turn out worse than expected.

There is one good thing about time when it is used properly in the sense of risk planning. Given adequate time, the project manager and his or her team can change their approach or plan contingency approaches to minimize the negative effects and maximize the opportunities that the risk event holds.



Module Summary

SummaryThere are three defining components of risk:

The event itself (What can happen, good or bad, to the project?)The probability of occurrence (How likely is it that the event will occur?)The impact of the event (What is the effect on the project if the event does occur?)

Risk can have either a negative or positive component if it is business risk. This is the kind of risk every project and organization should be pursuing, with the aim of reducing the former and maximizing the latter.Risk that has only a potential for loss is called pure or insurable risk. This kind of risk should be avoided or passed to a third party either by purchasing insurance, by teaming with another company, hiring additional personnel, or by renegotiating the delivery schedule.Risk events are inherently situational, interdependent, magnitude-dependent, value-based, and time-based.Risk management is the process of identifying, analyzing, and responding to the risks in a project.



Module 2Identifying Risks

Module Introduction

Module OverviewThis module discusses the first two steps of the Risk Management Model.

Planning for Risk Management and Identifying Risks

OverviewTo manage risks effectively, the project manager must obtain thoughtful input on project risks from the project team. To do this, the project manager must be able to convince the project team of the importance and benefits of risk management based on his or her own understanding. The project manager should be able to describe the basic eight-step Strategy Execution Risk Management Model and the activities that it includes, identify risks using a variety of tools and techniques, and develop a risk listing for a project.

Risk Management and Project ManagementWhat is the relationship between risk management and project management? Project management involves planning, organizing, directing, and controlling company resources to provide a product or service on schedule, within budget, and in accordance with the customer’s stated requirements. Risk management is that part of project management that deals with the processes of identifying, quantifying, responding to, and controlling the risks inherent in a project.

In other words, there is a fundamental difference between risk management and project management. Project management is the process that gets us to an objective; risk management is an enabler to that process. Risk management considers issues that could possibly affect that process as it unfolds; project management looks at the process itself. Risk management looks at how we can avoid problems; project management looks at how we get beyond problems. It is a fundamental, very simple difference. When it comes to risk management, we are looking at the reality of day-to-day life and how we can have an impact on those things that might stop us from getting to our objective. Project management is the effort to work toward and actually reach that objective.

Module 2: Identifying Risks


Risk ContextRisks, like beauty, are in the eye of the beholder. We all look at risks differently. Be prepared that not everyone will agree with the risks identified and the value of the impact or probability they may have on the project. This is fine. One person who has a high level of attitude, tolerance, and threshold would probably enjoy skydiving, while another person who has a low level of attitude, tolerance, and threshold would probably see going to the local grocers as a bit of a risk.

The same goes for identifying risks as well as all the steps in risk management. You need a little bit of both ends of the spectrum. Someone with a higher threshold for risks will inadvertently dismiss some of the risks because they just do not see them (they are not wired that way); they will usually be able to see the really big, unique risks. This matched with someone more risk averse is good. Working alone, the risk averse may become overwhelmed with seeing everything as a risk.

Risk Management Process

Risk Management Process OverviewLike all project management processes, risk management involves the application of tools and techniques to certain inputs to achieve certain outputs. Inputs include such factors as the people involved and their expectations. However, particular attention should be paid to the triple constraints of time, cost, and scope (or schedule, budget, and quality). If you lack experience in risk management, these constraints offer good places to start looking for input, because all projects will have risks associated with schedule, budget, and quality. The desired outputs resulting from the use of various tools and techniques include a list of prioritized risks, a risk response plan, and a list of risk indicators that, with proper monitoring, will provide early indications of risks that come to pass.

The Risk Management ModelThere are many risk management models. They are fundamentally similar. Strategy Execution’s is an eight-step model based on practical experience and best practices that go beyond the information in any one standard. The model will serve the structure for the remainder of this text. They are listed in order below. The first two steps are addressed in this chapter.

Risk management planningIdentifyAnalyzePrioritizePlanExecute



EvaluateDocument

Step 1: Risk Management PlanningRisk management planning is the first step of an eight-step process. It must be completed so that risk planning and analysis do not become afterthoughts to project planning. It is important to set aside time and processes to plan for project risk. This is done by conducting a team meeting specifically to address risk issues. The agenda for the meeting should include reviewing lessons learned from previous, similar projects and reviewing all the project documents (statements of work, contracts, specifications, resource availability charts, and so on) to ensure that the team is aware of all potential risk sources. It should conclude with an agreement on the process that will be followed and the tools and techniques that will be used in planning for the risks associated with the project in question.

Documenting and communicating are two activities throughout the eight-step model that are ongoing and crucial to risk management planning.

Step 2: Identify RisksIdentifying risks is the second step in risk management, and it is absolutely crucial. Risk identification is considered a key step in the process. It is arguably the most important step for several reasons. First, it is one of the initial functions that the project manager must perform. Second, when the project manager and project team do not identify risks, they cannot take steps to mitigate them. Finally, simply identifying the risks begins to reduce risk from the start.

Risk identification continues to be important throughout the duration of the project. Although the initial project planning phase is the first time to identify risk, it is not the only time to do so. Risks should be identified continuously throughout the life of the project. In addition, the initial list of risks may be used until the project is completed. This means that each risk event must be stated specifically and clearly for the risk management process to operate effectively, because the project team members must be able to understand exactly what was meant when they refer at a later date to the original risk management plan.

Risk Identification

Risk Identification GuidelinesCertain guidelines should be followed in describing risk events to ensure that they are specific and fully defined. The effectiveness of the risk management process relates directly to how well each risk event is defined. If a risk event is not stated specifically, how can a project manager develop a good risk response? How will the organization be able to use lessons learned effectively in the future? Guidelines for risk identification include the following:



The risk description should state the event that may happen, when it is likely to occur, and what its impact will be. For example, on a prison construction project the supplier of difficult-to-find alarm glass windows might go out of business before completing fabrication, thereby causing delays to accomplish reprocurement with another supplier.Use the WBS as a good tool for risk identification. This will help ensure coverage of all significant risks and facilitate analysis of their potential effects on the project’s cost and schedule.In identifying risks, be thorough but don’t be absurd. It’s easy to start brainstorming risks based on every WBS activity only to develop a ridiculously long list of trifling risks. Risk identification should stick to those items with a reasonable likelihood of occurring and a reasonably significant impact on the project if they did occur.The risk identification process should be completed by the team in a group effort and not by individuals.

Risk Identification Tools and TechniquesSpecific tools and techniques can be used to help the project team identify risks. They include the following:

Delphi techniqueBrainstormingNominal group techniqueCrawford slip methodAffinity diagramAnalogy processChecklists, questionnaires, and templates

These are all proven tools and techniques, and each has different nuances in exposing risk and allowing the project team to find risk. The project manager should be careful to select the most appropriate tool for each situation.

Analogy ProcessThe analogy process is a simple one. You first identify the type of information you need. In the case of risk identification, this would be the risks that might be encountered on your project. You then look for similar projects. It is important, however, to realize that although there will be similar projects, the trick is to recognize which components of those projects are truly analogous to the project in question. After you have mastered that, it is easy to identify the risks that carry over from one project to another and to address them in the current context.

Checklists, Questionnaires, and TemplatesChecklists, questionnaires, and templates are additional tools that can be used for risk identification. Like the analogy process, they are based on the idea that no new project represents a completely new set of risks. People and companies often compile lists of risks that



occurred on previous projects and then create checklists, questionnaires, and templates from those lists.

Industry organizations and associations also produce such information. The Software Engineering Institute (SEI) has produced a checklist called the SEI Risk Taxonomy and made it available to the general public. The Software Program Managers Network (SPMN) has done the same with its list.

Whether they are developed internally by the project’s sponsoring organization or obtained from other sources, these tools are used by project teams as lists of potential project risks. The project team examines the risks and decides which, if any, pertain to their project. These instruments bear an interesting relationship to the concept of known and unknown risks. To improve project management and risk management over time, project teams should record unknown risks on a checklist, questionnaire, or other tool when they occur. In this way, lists of known risks are generated from previously unknown risks.

Delphi TechniqueThe Delphi technique is a more involved form of the expert interview technique. It is named for the Greek oracle located at the foot of Mt. Parnassus whose most famous prediction was that Oedipus would kill his father and marry his mother. Not knowing that he lived with foster parents, Oedipus tried to avoid these two awful risks, but ironically precipitated them by fleeing to the city where his real parents lived. Hopefully, the use of the Delphi technique by project managers will lead to less dramatic and more successful results!

The RAND Corporation developed the Delphi technique in 1948 as a way of obtaining the input of several experts on specific issues. The technique proceeds according to the following steps:

Step 1. The coordinator formulates the problem and distributes it to experts in the field. This is the hardest step. If you phrase the question improperly, different experts can interpret it differently and undermine chances for the success of the Delphi technique. When applying this technique, devote a lot of time to Step 1. In the risk identification process, the basic problem is to determine the reasonably significant project risks, how likely each is to occur, and what kind of effects each will have on the project.Step 2. The experts review the problem and send their written position statements to the coordinator.Step 3. The coordinator then sends out the position papers without attributing them to their authors. Each expert knows only his or her position, but this step gives each an opportunity to compare it to the other experts’ positions.Step 4. The experts can then reconsider their positions and submit changes as appropriate.

The cycle of reviewing and resubmitting positions can be repeated several times as needed. Sometimes experts are very reluctant to change their opinions. Ultimately, in a risk identification exercise, the list of risks is finalized on a Risk Listing form.



Advantages of the Delphi TechniqueThe Delphi technique can be advantageous when soliciting input from individuals who are geographically dispersed. In these circumstances, travel time and cost make frequent group meetings infeasible, so using a group information gathering technique with limited personal interaction works well. Because the parties providing input do not interact directly, this technique can be useful for addressing issues that are politically sensitive or seeking input from diverse (or adverse) individuals. The Delphi technique also works well when the problem being addressed requires some attention to detail, does not lend itself to precise analytical techniques, or can take some time to be resolved. Conversely, if you need quick answers based on interpersonal group input, the Delphi technique is not for you.

The Modified Delphi TechniqueThere are numerous situations where the Delphi technique can be too costly or too time consuming to allow for it to play out properly. This is where a modification to the approach has become more common than the original technique itself. The modifications take out the constraints of anonymity and allow for the reviewers to not necessarily be experts; it also provides for the coordinator (a central person) to be an equal part of the proceedings.

In short, the modified Delphi approach is a more practical way to get the needed information without the rigor (or the time) needed for the original model. This other approach allows companies to do it on their own and provides for quicker resolution/solution of the multiple cycles. It, however, will be more biased than the original technique. The central person needs to be a good facilitator to draw out all of the information in the meetings—to allow the “silent” members an opportunity to contribute.

The steps of the modified technique are very similar to the original:Step 1. The facilitator prepares materials and coordinates reviewers. Since all reviewers meet in Step 5, it is less imperative to “get the questions exactly right.” Do try to remove ambiguity, but know that you will get an opportunity again to tell them what you really want.Step 2. Reviewers attend kickoff meeting to discuss the objective, due date, expectations, and so on. Provide common ground; let the reviewers ask clarifying questions, and then let them go.Step 3. Reviewers review materials and offer modifications or alternatives to the facilitator and/or bring them to the final meeting.Step 4. The facilitator reviews and analyzes all of the submissions and develops a clean document that contains the consensus of the reviewers. Any issues that do not have consensus are annotated and become the focus of the working meeting. NOTE: This step may not happen if the expectation is to do all work in an extended working meeting.Step 5. All reviewers attend the working session to come to consensus on issues with the new solution. The goal of this meeting is to answer all questions and resolve all issues.Step 6. The facilitator takes all data and compiles the information into the final solution/documentation.



Brainstorming ProcessBrainstorming begins with the “auction stage.” Each member of the group is asked to provide input in the form of project risks. Members are encouraged to use each other’s ideas to generate new ones, and all ideas are written on a list. Start evaluating the ideas only after the brainstorming is complete. This is the big challenge for the moderator. When identifying all the risks in a given project or process, there may be people who consider some risks as silly. None are to be evaluated as they are being recorded at this point, and the person leading the session should ensure that everyone has a chance to identify all the risks they can think of.

When the group has run out of ideas, they proceed to the “evaluation stage.” The group reviews each risk on the list and discusses the merits of each idea. The results of this evaluation are then summed up as the “group’s results” and placed on a Risk Listing form. Both stages of brainstorming rely on group dynamics and depend on the group process for valuing the creative merit of all ideas.

One advantage of brainstorming is that it affords everybody an opportunity to participate, promoting feelings of belonging and acceptance among team members. Another is that it allows for feeding off another’s ideas: one team member offers a good idea; another catches part of it and thinks of another idea. That is synergy.

Brainstorming can have disadvantages too, though. It can sometimes lead to groupthink, so the critical issue in brainstorming is to afford everyone an opportunity to speak to the question of what risks a project might face. Unfortunately, the process can intimidate less assertive participants. Many times, one team member may offer seemingly endless ideas while another is quiet, reluctant to participate, and difficult to draw into the process. This is a pitfall of brainstorming. Vocal people in the group tend to “win” in the sense that they tend to get their opinions voiced and documented on the flip chart or wherever information is recorded. It is amazing how a brainstorming session can be dominated by a few individuals. This is known as “false synergy.”

Nominal Group Technique (NGT)The nominal group technique is similar to brainstorming and the Delphi technique in that it derives extra information by asking others for their insights. It uses groups that are physically together as in brainstorming; but, much like the Delphi technique, it involves a lot of individual thought and written input. A relatively small group of 5 to 7 people is the ideal size, and a group of 12 is considered the maximum size for a productive exercise. The technique proceeds according to the following steps:

Step 1. A question or issue is posed by the group facilitator. In a risk identification exercise, the question might be: “What risks are associated with this project?”Step 2. All members of the group consider the question and silently write all their answers on a sheet of paper. No talking is allowed.Step 3. After participants have finished writing all their answers to the question, the facilitator asks each person in turn to read one answer from his or her list. The responses are recorded on a flip chart or other visual aid so all group members can see them. This



step is repeated until all the responses of each group member have been posted. As in Step 2, no talking is allowed.Step 4. The facilitator then leads a discussion of each idea by asking for any questions, clarifications, or explanations that the group members may have. Each idea is given equal consideration. There is no evaluation of the ideas at this time, just questioning, explanation, and clarification.Step 5. The facilitator then asks each group member to make a list of the ideas that he or she thinks are especially important. This may be limited to a certain number, such as the five most important ideas, in order to facilitate the process. This is another silent process.Step 6. The facilitator tabulates the results for the entire list to narrow it down to the most important ideas, which may be limited to a certain number. Differences of opinion can be clarified and explained at this time, and the previous step and this one can be repeated if necessary to arrive at a clearer consensus based on consistent understanding among the group members.Step 7. The facilitator asks each group member to rate the ideas in order of priority. This could be done numerically (for example, ranking a list of five items with scores of one through five from the least to the most important) or descriptively (for example, ranking a list of 10 items as having high, medium, or low importance). Every idea is ranked by each of the team members in another silent process. The facilitator then develops cumulative scores for the ideas remaining in order to prioritize them. This step may involve clarification, explanation, and repetition like the preceding one. The end result is that the facilitator finalizes a prioritized list of risks on a Risk Listing form.

The name of the nominal group technique explains its underlying rationale. The group is a group in name only, for the most part, because it requires individual work and prohibits group discussion during most steps in the process. This is a direct reaction to the problems associated with brainstorming. Nominal group technique is a good way to elicit input from people who are shy or unwilling to speak up in those situations. This is because it treats everybody equally by giving all ideas equal consideration, and because it focuses on the ideas rather than the people offering them. Nominal group technique also helps eliminate groupthink and jumping on the bandwagon. Its drawback is that it can lose opportunities for synergy, because it emphasizes the individual instead of the group.

Crawford Slip MethodAlthough we would probably use adhesive note pads of any color nowadays, this method was originally known as the Crawford blue slip, because the participants actually used blue slips of paper to write down their own ideas. They used blue paper for two reasons. First, blue signified “blue sky” or more creative thinking. Second, blue paper was more expensive and thus showed the importance of the ideas and the people offering them.

If you have ever read the same book or seen the same movie twice and experienced new insights the second time around, then you can understand the premise underlying the Crawford slip method. The process is very simple and follows these steps:

Step 1. The facilitator establishes a question for the group to consider, for example, “What risks are associated with this project?”



Step 2. Each group member is given several slips of paper and writes one answer to the question on one piece of paper. The facilitator gives them a full minute to write their responses.

As soon as the group members have finished Step 2, the facilitator asks the same question again and has them write new answers, repeating the same 2 steps 10 times so that each person provides 10 different answers.

Crawford was smart. Each time the process is repeated, the question is more fully investigated and analyzed. By the time the group members give their tenth set of ideas on any topic, they are dredging the bottom. They are down to silly ideas and goofy stuff, but they have also provided the best information they had to offer. The facilitator has everything the group could offer in a format that is easy to work with.

SWOT AnalysisStrengths-weaknesses-opportunities-threats (SWOT) analysis is another important technique in generating a comprehensive risk listing, which can be used during Initiation and Planning, as well as during risk reassessment in risk monitoring and control. Analysis is used to determine where to apply special efforts to achieve desired outcomes.

SWOT analysis "entails listing strengths and how to best take advantage of them; weaknesses and how to minimize their impacts; opportunities presented by the project and how to best take advantage of them; and threats and how to deal with them."1

SWOT analysis is most effective if done after initial risk lists have been developed to ensure a comprehensive view of project risks. Because most people tend to focus on threats to a project, SWOT analysis can also be an important tool in identifying potential opportunities on which the project team may be able to capitalize.

During SWOT analysis, a facilitator poses the following questions to individuals and groups:What are the strengths of the organization?What are the weaknesses of the organization?What opportunities might the project present?What threats could endanger the project?

The responses are generally compiled into a chart allowing for analysis and cross-referencing.

PrototypingProtoyping is an effective tool to identify risks associated with unknowns and uncertainty of requirements. It is used when planning and defining requirements. A prototype is a mock-up or simulation of a possible product or a portion of the product developed by the project team to evaluate its design. The goal of prototyping is to make the product real enough that potential users can visualize the product and identify any components that they might otherwise miss.

1 Ward, J. LeRoy. Dictionary of Project Management Terms. 3rd ed. Arlington, Va.: ESI International, 2008, p. 422.



Prototyping is most appropriate when trying to define more precisely the technical requirements of a high-risk project or deliverable. For example, prototyping may be useful when—

The product has not existed before and is difficult to visualizeThe users of the product have no experience with the kind of product or proposed technologyThe users have been doing their work for some time and are stuck in the way they do itThe users are having trouble articulating their needsThe business analysts are having trouble understanding what is requiredThe feasibility of a requirement is in doubt

Analysis of the prototype can help identify risks associated with the product design through the discovery of unknowns. It can also help to resolve uncertainty and assist in making “unknowns” become “knowns.” Other risk identification tools, such as brainstorming, can be very helpful in generating ideas about risks that have been revealed through prototyping.

Affinity DiagrammingAffinity diagramming is an excellent tool for organizing and categorizing large ideas or concepts that use group dynamics to great advantage. It allows project teams to gather new information and sort it in new ways. It is a great tool for finding risk symptoms and for finding huge categories of risk that might not otherwise be discovered. The development of an affinity diagram proceeds as follows:

Step 1. Write all the ideas to be organized on slips of paper, one to a slip. In the risk identification process, each slip of paper would contain a single risk event description. Based on this first step, it is easy to see that affinity diagramming can be used as a natural follow-on to brainstorming, the nominal group technique, or the Crawford slip processes.Step 2. Spread all the slips randomly (with no organization whatsoever) on a large table so that they are easily seen and moved about.Step 3. Have each member of the team help group ideas by placing slips next to other slips with related ideas. All members must work simultaneously but without communicating. Each member may move only one piece or a few pieces at a time. At no time may a single participant completely reorganize all the information. Encourage the participants to react quickly to what they see and not to agonize over decisions.Step 4. Stop the grouping process when no team member wants to make any more moves or after about 15 to 20 minutes. If there is an obvious conflict because two members keep moving a particular slip or group of slips back and forth, duplicate those slips and put them in both groups.Step 5. Have the participants discuss and determine appropriate headings for the groups that have been created, either by using existing slips that will serve well as headings or by creating new ones through group discussion.Step 6. Reduce the results to a formal diagram.

You now have a risk listing that is well organized by categories of risk that were logically determined by the team based on the individual risk events they previously identified. It will not



only help you to organize your risk management planning, it may also reveal major categories of risk that have been overlooked and need further attention. This method of categorization is preferable to putting up the headings first because that approach tends to create “in the box” thinking and stifle creativity. It also helps ensure team buy-in and understanding because each person contributes and no single person dominates the outcome.

Risk Events and Risk Event Lists

Specificity of Risk Event StatementsEach risk event must be specifically described. The risk event should be stated as—

Something that may or may not happenOccurring at a particular point in timeCausing a particular impact to the project

For example, “If software programmers are not available, the test will not be able to be conducted, with the result that the schedule will be delayed.” It is extremely important that statements of risk events be complete and definitive, because how they are understood will affect everything in the process that follows. Each risk event statement is analogous to a scope statement. As such, a poor risk event statement will have the same effect on risk management that a poor scope statement has on project management. These rules and recommendations apply to both threats and opportunities.

Common Problems with Risk Event ListsThere are three problems that often occur in developing a risk event list:

Risk event descriptions are too vague.The list of risk events is not sufficiently thorough.The risk events identified lack a consistent level of detail.

Categories Help Ensure Thorough Risk Event ListsThe risk event list must be as thorough and comprehensive as reasonably possible. If the team identifying risks becomes too focused on a particular type of risk, they may fail to include important threats or opportunities on the risk event list and fail to plan for them. The use of categories will help ensure thoroughness and the avoidance of critical omissions. Examples of categories might include such subjects as legal risks, technical risks, procurement risks, environmental risks, personnel risks, health risks, and so on.

There are other ways to categorize risks, such as external versus internal. External risks are those that are beyond any team control; internal risks are those that are somewhat within team control, such as financial, schedule, legal, and technical risks. External risks can be further



categorized into “unpredictable” versus “predictable but uncertain.” Unpredictable risks would include such categories as natural disasters, public opinion, and government regulations. Predictable but uncertain risks would include threats and opportunities, such as changes in inflation or interest rates.

Risk List Level of DetailMany times the risk list will contain a mixture of very small risks and broad, sweeping risks. For example, a risk list could include either of the following:

Power test failures during rework of power supply could delay milestone #2.Use of new technology could increase cost and affect schedule throughout the project.

The use of such varying degrees of detail in describing risk events can distort risk process results. If a person were to analyze and prioritize these two risk events, the second risk event would always show more impact probability, because the risk associated with new technology is so broad. It would likewise be ranked first in any prioritization scheme. This is because the risk associated with new technology is stated at too high a level.

The risk associated with new technology should not be totally eliminated from the risk listing. It needs to be broken down, restated at a more particular level of detail, and linked to specific work packages that it may affect. For example, “The use of new technology could delay completion of the design task.”

Module Summary

SummaryRisk management is a full project life-cycle activity.Risk management is composed of eight major processes: risk management planning, identifying, analyzing, prioritizing, response planning, executing, evaluating, and documenting.Risk identification should involve group techniques.Group techniques should be used based on their specific characteristics, advantages, and disadvantages to maximize the effectiveness of risk identification for the project in question.



Module 3Analysis Fundamentals

Module Introduction

Module OverviewThis module discusses how to place a value on the probability of a risk event occurring.

Establishing Risk Measurement Parameters

Introduction to Risk QuantificationPerhaps the most difficult aspect of analyzing and planning for risk is not risk identification, but determining how to place some value, numerical or otherwise, on the probability that the risk event will occur. Without a way to quantify this aspect of risk, it is impossible to analyze the impact of risks on the project and to prioritize risks for an appropriate degree of management attention.

Risk analysis is most effective when a numerical probability of risk occurrence can be determined. Although it is not always possible to do that, the project manager should understand the fundamental concepts of probability theory to better estimate the chances of a risk occurring, and to determine additive and multiplicative risk properties when they are interrelated. The project manager should also understand the differences among quantitative, qualitative, and narrative approaches to measuring risks, and the advantages and disadvantages of each.

Presenting Risk Information

How Risk Information Is PresentedRisk information is typically presented in one of three forms, or a combination of the three:

QualitativeQuantitative

Module 3: Analysis Fundamentals


Descriptive

QualitativeQualitative risk information makes use of terms such as “high,” “medium,” or “low” to describe the probability or impact of the occurrence of risk events. Unless the person providing the information is an exceptional writer, this form of presenting risk information is generally better than the narrative form for explaining the severity of a risk impact.

But even the qualitative form has its limitations. Describing a risk event as having a medium probability of occurrence provides a sense of how likely the risk is to occur, but leaves a wide range of possibilities to consider. In addition, high, medium, and low are very subjective terms; a high risk for one person may be a medium risk for another. Even with the qualitative form of presentation, it is more helpful if the qualitative scale can be defined more quantitatively. For example, defining low risks as those falling between 0 and 20 percent probability of occurrence clarifies what is meant by “low risk.” However, it still is better to use a specifically quantified number than a range, whenever possible.

QuantitativeIn a quantitative analysis, numbers are used to assess probabilities and impact. This is useful for two important reasons. First, assigning a number to the risk’s probability affords the opportunity to use more tools to assess the risk. Second, quantifying the risk’s probability provides some objectivity to the assessment of risk. Like it or not, we have to realize that there will always be a certain amount of subjectivity in assigning risk probabilities to a risk event, but there are powerful tools that can help us mitigate risk if we can first quantify them.

DescriptiveDescriptive risk information, in some respects, is very useful because it offers an easy way to provide a lot of information about a risk event. For example, a person can provide a complete description of the potential risk event, the source of the risk, and what might be done about precluding it or controlling it if it occurs. The major disadvantage of this form of presenting risk information is that it provides no way to measure the risk’s probability or its impact to the project or organization.

Handling Probability and ImpactRisks can be presented using various formats. One of the most commonly used formats is the following grid. This grid is particularly useful when only qualitative data using high, medium, and low rankings are available.

Looking at the grid, it is easy to see that risks falling in the low-probability and low-impact (L/L) quadrant may be ignored or assigned a lower priority, while those falling in the high-probability and high-impact (H/H) quadrant must be dealt with proactively. The two quadrants, high-probability and low-impact (H/L), and low-probability and high-impact (L/H), depending on where they fall within the grid, likewise may be ignored or assigned a lower priority. If a risk has a high



probability of occurring but minimal impact, then we are likely to accept the risk and deal with it when and if it happens. Likewise, if there is a low probability of a risk event occurring, we are likely to accept the risk even if there is a very high impact.

An example of an L/H risk event is flying. If a commercial airliner crashes, the impact is catastrophic, but the probability of such an occurrence is so low that most of us never even consider the risks of flying. An example of a common H/H risk arises when a company has one or more projects requiring expertise not available within its personnel ranks. This H/H risk becomes a low risk or no risk at all when the company outsources one of the projects, hires additional personnel, or teams with another company to perform the work in question.

Examples of Qualitative and Quantitative RisksWhenever risks are rated, the level of risk acceptance has to be considered. Organizational culture will have developed a level of risk tolerance that will cause each person to see a particular risk in a very different light. A low risk for one person may be a high risk for another, so delineating between levels of risk becomes very difficult, particularly when a qualitative analysis is done.

The following graphic can be used to define the high, medium, and low categories of risk event probability and impact for most organizations in most instances.



Rank Probability Impact

High Risk event is very likely to occur.

Risk event has high probability of occurrence.

If risk event occurs, a significant impact to cost, schedule, quality, or customer satisfaction will occur.

Medium Risk event is likely to occur.

Risk event has medium probability of occurrence.

If risk event occurs, a moderate impact to cost, schedule, quality, or customer satisfaction will occur.

Low Risk event is unlikely to occur.

Risk event has low probability of occurrence.

If risk event occurs, a small impact to cost, schedule, quality, or customer satisfaction will occur.

A quantitative risk presentation is one that has numbers associated with it. For example, if we can say that an event has a 15 percent probability of occurring and that its impact would be a cost to the project of $10,000, then we have quantitatively defined the risk. As with the qualitative analysis, it is difficult to assign accurately a probability to a risk event; it is a matter of experience, expert opinion, lessons learned, and so on. The better the historical data, the more accurate the probability and impact assessments.

Given the particularly difficult task of assigning accurate qualitative risk ratings, can these presentation models be combined in a way that mitigates the subjective nature of the rating? The answer is, “Yes, they can.” Qualitative ratings can be broken down so that within one level there are two or more levels. For example, high might have additional levels of very high, medium high, and low high. Then numerical probability ranges can be assigned to aid in determining a reasonable probability number for each risk event. The graphic below demonstrates how this is done.



Probability Analysis and Rules of Probability

Probability AnalysisProbability analysis determines how likely a risk event is to occur. Although the sources of probability assessment data were briefly mentioned previously in this chapter, they are worth reviewing.

Generally speaking, a large portion of the data used for risk analysis comes from experience. This does not necessarily mean the data are bad, but care when using the data is crucial. The project manager should always evaluate the source of the data and how “biased” the data source is. Bias in this case is a function of whether the source or person providing the data is open to accepting some risk or is averse to any risk. His or her assessment may be colored by how tolerant he or she is to the risk. Once again, knowing what the organizational culture can tolerate relative to risk and especially to risk impact is extremely important.

When the experience is based upon historical data (that is, lessons learned), and especially when lessons learned are documented, the data source tends to be less biased because there are actual examples of risk events and how they were handled. Historical data also can take some of the subjectivity out of probability and impact assessments.

Theoretical distributions are another source of probability data that can be used to good advantage. Many standards are developed from surveys or other data taken over the years about processes, methods, and actual project or manufacturing events. The resulting probability formulas are more accurate than just basing the risk estimate on an “educated guess.”

One of the most accurate methods for determining probabilities can be a simulation. For example, Monte Carlo analysis is a well-known simulation that examines many data points or “what if” scenarios to determine the most likely outcome. Whatever the method used, an understanding of basic probability principles is necessary for understanding risk analysis.

Approaches to Predicting ProbabilityThe probability that a particular event will occur can be predicted by using one of three methods: classical probability, relative frequency, and subjective probability.

Classical probability is a form of deductive logic that states that the likelihood of an event occurring (P) equals the ratio of the number of possible outcomes yielding that event divided by the number of all possible outcomes. Logically, the number of all possible outcomes equals the number of outcomes where the event in question (A) occurs plus the number of outcomes where it does not occur (B). A classic example is the probability of getting heads when flipping a coin. Mathematically, this concept can be expressed as follows:



P(A) = A/(A + B)

P(heads) = (1 head)/(1 head + 1 tail)

P(heads) = 1/2 = 50%

This approach works well with simple situations where each outcome can be identified and is equally likely to occur. But what if the coin is known or even suspected to be biased? Or what if the question is something complex such as how likely a finely calibrated engine part is to fail within one year? In these cases, relative frequency offers a better approach.

Relative frequency uses inductive logic to draw conclusions about probability based on empirical results of samplings of actual events. For example, if 1,000 engine parts were sampled and 100 failed, the relative frequency of failure for that sample would be 100/1,000. Applying inductive logic, the probability of failure for all engine parts would be predicted to equal the relative frequency and be deemed 10 percent.

In the case of a biased coin, the results might be that heads occurred 6 times in a sample of 10 coin flips. This would be evidence of a bias toward heads, but sample size is important, because the larger the sample, the more reliable the use of relative frequency. A relative frequency of 60 out of 100 coin flips would be stronger evidence of a 60 percent probability of heads, and 600 out of 1,000 would be stronger still. Conversely, when different outcomes really are equally likely (that is, the coin is unbiased), the larger the sample, the closer the relative frequency will come to the classical probability prediction. In that case, one might see 6 heads out of the first 10 flips, then 56 out of the first 100, then 520 out of the first 1,000, and so on, until the relative frequency closely approaches 50 percent.

What can be done to predict probability when the situation is too complex for application of the classical approach and not susceptible to sampling? This is when subjective probability must be used. Subjective probability is not based on deductive logic, inductive logic, or empirical observation of test samples. It is purely an application of individual intuition. For example, suppose the probability of prime interest rates rising above six percent must be predicted because of the effects such an increase would have on a project. This event is far too complex for use of the classical approach, and there is no way to conduct valid test sampling. The only way to assign probability is based on conclusions reached intuitively by individuals, and that is the subjective approach.

Rules for Dealing with ProbabilityThere are some basic rules or principles for dealing with probabilities, including these key concepts:

Mutually exclusive eventsNonexclusive eventsIndependent eventsDependent events



Probability representationThese concepts are most easily explained by examples. Suppose you have a stack of index cards numbered 1 through 10 and a coin with the usual sides of heads and tails. Then consider the following cases.

Mutually ExclusiveMutually exclusive events are those that can never happen at the same time. If one occurs, the other cannot. If you draw 1 card from the 10 cards, you may draw an odd or even number, but if you draw odd, you cannot draw even, and vice versa. Drawing an odd card and drawing an even card are therefore mutually exclusive events. So are getting heads and getting tails when you flip the coin.

Nonexclusive EventsNonexclusive events may or may not happen at the same time, such as drawing an even card and a card less than five. Drawing a two or a four would mean doing both. Drawing a seven or nine would mean doing neither. Any other draw would mean doing one or the other.

Independent EventsIndependent events are nonexclusive events where the outcome of one event cannot be affected by the outcome of another event. If you draw a card, you may get any number from 1 through 10, and if you flip the coin, you may get heads or tails. These are independent events. Suppose you are trying to both draw the number 5 from the cards and get heads from the coin flip. The probability of both occurring is calculated as follows:

P(A and B) = P(A) x P(B), or

P(5 and heads) = 1/10 x ½ = 5%

The probability of either drawing the number 5 or getting heads from the coin flip is calculated as follows:

P(A or B) = P(A) + P(B), or

P(5 or heads) = 1/10 + ½ = 60%

This formula is slightly more complex for nonexclusive events, which may happen at the same time. An example would be determining the probability of drawing, on a single draw, either an even-numbered card or a card less than five. The additional complexity in the formula is necessary to avoid double-counting the two numbers (two and four) that satisfy both conditions. The probability is calculated as follows:

P(A or B) = P(A) + P(B) – P(A and B)

P(even or <5) = P(even) + P(<5) – P(even and <5)



P(even or <5) = 5/10 + 4/10 – 2/10 = 7/10 = 70%

Dependent EventsDependent events are events where the outcome of one event is affected by the outcome of another event. If you are trying to draw even cards, and draw 1 card from the set of 10 and keep it separate from the rest, then draw another card, the odds of drawing an even card the second time will be affected by which card you drew the first time. These are therefore dependent events. The probability (P) of picking two even cards, where event A occurs first and both events stand for drawing an even card, is calculated as follows:

P(A and B) = P(A) x P(B, after A occurs), or

P(even and even) = 5/10 x 4/9 = 22%

Ratios have been used to represent event probabilities for ease of understanding in the examples above. However, normal practice in risk analysis is to express probabilities as decimals between 0 and 1 or as percentages from 0 to 100 percent.

Addition, Summation, and Multiplication RulesRisk analysis often involves mutually exclusive events because the question being evaluated is the probability of a risk event happening or not happening. Two particularly important rules to keep in mind for mutually exclusive and independent risk events are the addition rule and the summation rule. These formulas are set forth below. On the surface, these rules look the same, but they are slightly different concepts.

The addition rule says that the probability of either one outcome or another outcome occurring is equal to the sum of the probabilities of the outcomes occurring individually, which can be written as—

P(A or B) = P(A) + P(B)

The summation rule states that the sum of the probabilities of occurrence for all possible outcomes from a single event must be equal to 1.0 (that is, 100 percent). Statedmathematically—

Σ(P1 + P2 + P3 … Pn) = 1.0

For events that are not mutually exclusive, one very important rule is the multiplication rule. It states that the probability of both one outcome and another outcome occurring is equal to the product of the probabilities of the outcomes occurring individually.

P(A and B) = P(A) x P(B)



Comparing Risk Approaches

Comparing Risk Presentation ApproachesEach of the three risk presentation formats has its own advantages and disadvantages, but when they are used together, a description of the risk event, its likelihood of occurrence, and its impact can be clearly documented and communicated. The table below summarizes the characteristics of the approaches:

Qualitative Quantitative Descriptive

Fast and easy to administer and understandDifficult to enforce uniformly across organization and projectsRequires definitions, rules, standards, and processes

Preferred methodology, often mandated by managementMore time consuming; requires estimationMisleading in that numbers may give appearance of precision and specificity, unless the precision of the estimate is givenDifficult if team resists deriving the numbersEasier to forecastAble to use trendsSubstantially more valuable in developing risk response strategies and reserves

Difficult to quantifyUsually based on experience

Module Summary

SummaryThree formats are commonly used for presenting risk information. They are narrative, qualitative, and quantitative.



Because each of these formats has certain advantages and disadvantages, neither by itself is usually sufficient. The best approach is to use some combination of the three.In the case of mutually exclusive events or independent events, the probability of either one event or the other happening is the sum of their probabilities of occurring individually.In the case of events that are not mutually exclusive, the probability of both one event and the other event happening is the product of their probabilities of occurring individually.The sum of the probabilities for every possible outcome for a given event must equal 1.0 (that is, 100 percent).



Module 4Analyzing and Prioritizing Risk

Module Introduction

Module OverviewThis module discusses the next steps in the risk management process, analyzing and prioritizing risks.

Next Steps in Risk Management

Analyzing and Prioritizing Risk IntroductionAfter leading the project team through the identification of risks, the project manager must lead them in analyzing and prioritizing the identified risks using a variety of techniques. Examples of these techniques include decision trees, which can be used to evaluate relative levels of probability and risk, and financial measures, which can be used to quantify risk. By performing risk analysis, the project team accomplishes several risk management objectives. These include determining the values of the variables involved, identifying various consequences of the occurrence of risk events, estimating the magnitude of the risks identified, and reducing the possibility of surprise, which can never be eliminated altogether. Taken together, these efforts are aimed at the overall objective of preparing a thorough value analysis of the risks entailed by a project.

Step 3: Analyze Risks

OverviewRisk analysis is the third step in the risk management process and follows risk identification. It involves systematically estimating the probability of occurrence and magnitude of impact for each risk event that was identified in Step 2 (risk identification). The objective of this step is to reduce the uncertainty that always accompanies risks.

Risk analysis is a process itself within the larger risk management process. Its primary input is

Module 4: Analyzing and Prioritizing Risk


the risk event listing generated by the risk identification process. Using a qualitative or quantitative approach, or a combination of both, various tools are used to assess both the probability of the occurrence and the likely impact of each risk event. The end product is a fully analyzed risk event listing.

Risk Analysis GuidelinesCertain guidelines should be kept in mind while performing risk analysis. It is important to cover all the risk events listed at the end of risk identification. This effort can be extensive, but distributing risk analysis tasks among team members will break down the workload into manageable pieces and speed up the process. Assignments should be made based on the technical skills involved to ensure that the most knowledgeable people are analyzing each risk. Wherever possible, each risk should be evaluated both quantitatively and qualitatively. In doing so, it is wise to assess the best-case, worst-case, and most likely scenarios to understand the whole range of possibilities. This is especially true for risk events with high uncertainty.

The primary thing to avoid during risk analysis is trying to prioritize the risks at the same time. People have a natural tendency to want to prioritize risks as they analyze them. This is a bad practice because if project team members prioritize as they analyze, they may lose focus and never perform the sort of rigorous analysis that is necessary to validate the prioritization of risks.

Impact Analysis

Impact Analysis OverviewThere are two basic impact categories for any risk, because a risk may affect either the project cost or the project schedule. Schedule impacts can often have cost impacts, especially when a project incurs additional costs as a corrective action to keep the project on schedule. Cost impacts may affect scheduling in cases where work must be delayed to address cost issues.

There are several sources of data for impact analysis. Historical data based on similar situations that actually occurred on previous projects can be considered. Estimates and subjective judgments are common data sources that should not be confused. They differ in that subjective judgments are opinions based on intuition, without the substantiation of an analytical process such as estimating. Finally, simulations can be used in more complex scenarios. Regardless of what approach is used, those performing the analysis are basically undertaking an estimating process.

Project Cost ImpactsThe project team must analyze all identified risks to determine the impact of each on project cost. In doing so, they must consider the effects of the risk on cost factors such as level of effort, labor rates, labor hours required, materials required, and tools and equipment. Cost impact assessment must be done for both opportunities and threats.



Project Schedule ImpactsSimilarly, all listed risks need to be analyzed to determine their impact on the project schedule. Factors such as resource shortages, extended task durations, and the effects of the risk on parallel and dependent activities must all be evaluated. Any impact on the schedule needs to be checked against the network diagram to assess the impact on other activities.

To be meaningful, all these effects should be considered against the project schedule. Although an impact assessment may determine that the outcome may be a five-week delay to a procurement task, the only way to understand the effect on the project end date is to examine the network diagram and critical path. The delay may be on a chain of activities with 10 weeks of float, which means that the impact on the overall schedule is nil. As with cost impact analysis, it is important to analyze the effect of both opportunities and threats on the project schedule.

Project Scope ImpactsScope must also be analyzed for possible impact with factors such as—

Increased requirementsReduced or increased work effortProject qualityProduct reliabilityProduct safety

For example, a reduction in work effort could be a high risk during contract negotiations. As before, scope assessment must be done for both opportunities and threats.

Tools and Techniques for Risk Analysis

Proven Tools and TechniquesFortunately, certain proven tools and techniques are available to help in risk analysis. They include the following:

Expert judgmentFinancial measurementsExpected valueDecision treesStatistical sumsComputer simulation

Each of these tools will be discussed more fully in this chapter, but two require some immediate clarification. The term statistical sum refers to a process that combines statistical distributions into a single overall distribution, the most notable example being Program Evaluation and



Review Technique (PERT). The term computer simulation refers to the process of constructing a computer model of the project to simulate execution and analyze possible outcomes, the most notable example being the Monte Carlo simulation.

Expert Judgment in Risk AnalysisAn expert’s judgment can be used to help analyze risks much like an expert interview can be used to help identify them. The source of expertise may be outside consultants or team members assigned to the project. Because they are performing the work, team members often will have a better understanding of the impact the risk will have on the project.

Expert judgment is most often used when no precise analytical techniques are available. Although expert judgment is subjective, it can be helpful in cases when objective information is not available. The Delphi technique also can be used as a tool for gathering expert opinions about risk impacts. The process would be the same as the one used in risk identification, except that the experts would provide estimates of probability or impacts.

Financial Measurements in Risk AnalysisMany financial measurements or techniques are available to help analyze risks, particularly business risks. The importance of financial considerations when determining risk impact and probability is difficult to overstate. If the financial risk is too high, the project may not even get off the ground. An organization normally decides to undertake a particular project based on certain expected business results as determined by a general business financial measurement, for example, a certain level of return on investment (ROI). Life-cycle costing (LCC) is another financial measurement tool that is more focused on project management. The project manager should be able to use such measures in quantifying the financial impact that risks may have on the project.

Impact Analysis—Life-Cycle Costing (LCC)Where project risks have a lasting effect, the project manager should examine them in relation to the entire life cycle of the project deliverables, not just the duration of the project. The project life cycle will go through closeout, but the project deliverables may be implemented, operated, maintained, and enhanced for a much longer period of time.

For example, assume a project manager is thinking about reducing the amount of testing for a new software program to reduce a project’s cost and scheduled duration. This may look like a good way to meet original cost and schedule targets if project managers limit their perspective to the project only. However, there may be significant savings or benefits later, such as reduced repair and maintenance costs, if the testing is performed during the project life cycle. Immediate cost savings should be examined against later benefits or cost savings by using the life-cycle concept.



Expected ValueExpected value (EV) is a means of mathematically combining assessments of risk event probability and impact. The expected value (EV—not to be confused with earned value, which uses the same abbreviation in other contexts) can be defined by the following formula:

EV = (probability of occurrence) x (amount at stake)

An example of the formula applied would be the case of a risk event that has a 20 percent likelihood of occurring and would cost $100,000 if it did:

EV = 20% x $100,000 = $20,000

Expected value is also referred to as exposure in the case of threats and as leverage in the case of opportunities.

NOTE: Be cautious with the term "EV." It can be used to describe expected value, as used here, or earned value when measuring and calculating earned value management data. It is relatively obvious, but be vigilant.

Assessing Expected ValueAt the project level, overall expected value (that is, cost) can be assessed in several ways:

Baseline (the estimated cost of the project with no risks accounted for)Best case (the estimated cost of the project if all risk opportunities occur and no risk threats occur, that is, all good things happen and no bad things happen)Worst case (the estimated cost of the project if all risk threats occur and no risk opportunities occur, that is, all bad things happen and no good things happen)Expected value (the sum of the baseline and all risk events’ expected values, both threats and opportunities)

The final actual cost of the project will probably fall between best case and worst case. Expanding on the preceding example, suppose the following:

A project with a $1 million baseline estimateA threat Risk A worth $200,000 and having a 10 percent probabilityA threat Risk B worth $50,000 and having a 20 percent probabilityAn opportunity Risk C worth $100,000 and having a 5 percent probabilityAn opportunity Risk D worth $200,000 and having a 50 percent probability

Because we are addressing project cost, the expected values for the threat risks will be positive values, and the expected values for the opportunity risks will be negative values. The expected values for the four risks would be as follows:

A = 10% x $200,000 = $20,000 EVB = 20% x $50,000 = $10,000 EVC = 5% x $100,000 = ($5,000 EV)



D = 50% x $200,000 = ($100,000 EV)At the project level, overall expected cost can be assessed as follows:

Baseline = $1,000,000Best case = $1,000,000 – $100,000 – $200,000 = $700,000Worst case = $1,000,000 + $200,000 + $50,000 = $1,250,000Expected value = $1,000,000 + $20,000 + $10,000 – $5,000 – $100,000 = $925,000

Decision TreeA decision tree is a diagram that can be used to depict a series of alternative decisions, events, or outcomes. It is most useful where numerous possible alternatives can occur. It is referred to as a decision tree because it is a convenient way of depicting the consequences of different choices that must be made at different points over a period of time. The diagram therefore often begins with a decision to be made. However, in performing risk analysis, project managers often use decision trees to understand possible outcomes and not to make decisions. Therefore, the decision tree actually may begin with a risk event and depict the consequences that flow from it.

Consider the following example of a “make-or-buy” decision regarding a particular project component:



For this particular component, there is a 30 percent risk that the customer will require some rework that will not justify an increase in contract price. The component can be fabricated in-house for an estimated baseline cost of $80,000, but rework would have a cost impact of $40,000. In the alternative, the work can be fabricated by a subcontractor who would contractually assume the responsibility for performing any necessary rework for a contract price of $100,000.



Decision Tree Diagramming ConventionsAs the example illustrates, decision trees are normally constructed according to the following conventions:

Represent decisions by boxes (decision nodes).Represent outcomes or events by circles.Enter the primary decision on the left side of the tree and work through the possibilities from left to right.Represent all possible scenarios by paths.Assign probabilities to all path segments leading from events.Determine the expected value for each segment (the sum of the probabilities from each node must equal 100 percent).Add expected values from right to left along all path segments leading to a decision node to determine the most advantageous path.

As you can see from the example, decision trees are most powerful when used in conjunction with expected values. Depending on one’s risk tolerance, the information provided by a decision tree can be seen from multiple perspectives. For example, the total expected values for each of the four outcomes in the example are as follows:

Make and rework = $12,000 + $80,000 = $92,000Make and no rework = $0 + $80,000 = $80,000Buy and rework = $0 + $100,000 = $100,000Buy and no rework = $0 + $100,000 = $100,000

However, the best- and worst-case scenarios are quite different:Best case for making = $0 + $80,000 = $80,000Worst case for making = $40,000 + $80,000 = $120,000Best case for buying = $0 + $100,000 = $100,000Worst case for buying = $0 + $100,000 = $100,000

An organization that bases all its project risk management decisions on thorough risk analysis and expected values would decide to make the component despite the $40,000 risk of rework, because expected risk impacts of rework would be much lower on average than the cost of hiring subcontractors. In this case, the expected value of making the component and reworking it would be $92,000. An organization that is extremely risk intolerant and places a high value on certainty of results would probably decide to buy for $100,000 and forego the likely savings of $20,000 that might come with a decision to make the component.

Statistical Sums in Risk AnalysisStatistical sums can be used to calculate a range of total project durations and costs from estimated ranges for individual work items. This makes them powerful tools for understanding the likelihood of completing the entire project for a certain cost and within a certain amount of time.



For example, if all the estimated ranges of work durations of all the project activities are statistically summed, they can be used to generate a normal distribution curve of possible overall project durations. You may then calculate that curve’s standard deviation. A normal distribution has half of its values above its mean and half below. It also has 68 percent of its values within 1 standard deviation of the mean, 34 percent above and 34 percent below. This means that the project manager can predict that there is an 84 percent probability that the project will finish on or before the duration that is 1 standard deviation greater than the mean. This is because 50 percent of all outcomes are below the mean and half of the 68 percent of outcomes within 1 standard deviation of the mean (that is, 34 percent of the total outcomes) are above the mean.

PERTStatistical sums can be used for both project costs and project durations. One of the best-known and most significant statistical sums that can be used in risk analysis is the beta distribution using the Program Evaluation and Review Technique (PERT).

PERT is a network scheduling technique that is similar to critical path method (CPM) scheduling. However, CPM is based on activities with fixed durations, whereas PERT is based on variable activity durations. In PERT, each activity is assigned three durations:

O = Optimistic timeML = Most likely timeP = Pessimistic time

From these, a fourth duration called the expected time is calculated using the following formula:

(O + 4ML + P)/6

The statistical model upon which PERT is based is known as the beta distribution. The beta distribution looks and behaves like the normal distribution when ML is exactly centered between O and P. When ML is closer to either O or P, the beta distribution for the specific activity becomes skewed, and this is the usual situation. Nevertheless, when all activities for a project are beta distributed and statistically summed, the result approaches the normal distribution and can be used to estimate probabilities for overall project completion times.

Monte Carlo Simulation in Risk AnalysisMonte Carlo simulation is a computer analysis of the project using the network schedule diagram and probability distributions for activities to determine all possible project outcomes and their probabilities. It requires the use of special software but has some significant advantages over summation techniques, such as PERT. First, it can be used to evaluate possible project outcomes for both costs as well as durations. Second, in evaluating durations, it accounts for “path convergence” and is the only tool available that does so. Path convergence is a scheduling phenomenon that increases the probability of delaying the start of an activity as the number of parallel predecessor activity paths increases. Finally, unlike PERT, Monte Carlo does not require the assumption that all task distributions be beta distributions.



The Monte Carlo ProcessTo run a Monte Carlo simulation, the project manager must begin by establishing probability distributions for the duration and cost for each project activity, using whatever assistance is necessary. The project manager may specify any type of probability distribution desired for an activity’s duration or cost. All the information that has been gathered is loaded into the software. The software then runs multiple, randomly chosen simulations based on the activities and their probability distributions, and plots the outcomes as a range of potential overall project results.

Standard estimating techniques and some of the methods used for risk identification can be used as potential sources of information for input into the simulation. These, of course, include the project manager’s and project team’s previous experiences. The Delphi method, expert judgments, and actual data on previous projects can also be useful.

Overall Risk Rankings

OverviewAfter the probabilities and impacts of each risk event have been evaluated, the project manager may find that not all risk events can be evaluated in the same way. Some may have been evaluated quantitatively, some qualitatively, and some only in narrative format. Before the risk events can be prioritized, an overall risk rating that accounts for both risk probability and risk impact, and allows comparison of all risk events, must be determined and applied to each one.

Two-Step ApproachThe project manager must decide what this risk rating system will look like and how it will work. One simple two-step approach would be: (1) to equate certain probability percentages and cost impacts with corresponding categories of high, medium, and low, and (2) to further simplify the risk ratings by combining the two components of risk into unified numerical ratings.

Because there would be three rating levels for both probability and impact, there could be as many as nine numerical ratings using this approach, depending on the relative value assigned to the different combinations of probability and impact to the organization.

For example, would a high-impact/moderate-probability risk or a high-probability/moderate-impact risk be of greater concern? The answer depends on the individual and the organization. Organizations that can withstand a high-impact risk may readily accept the first scenario but be cautious about high-probability events. Organizations that cannot handle a high-impact risk may be more concerned about the first scenario. Regardless of the organization’s values and how they influence the scale of overall risk ratings, the project manager should be able to generate a risk listing that is suitable for the project team to use in the risk prioritization process.



Step 4: Prioritize Risks

OverviewThe risk prioritization process is an effort to rank risks that have been identified and analyzed in order of importance. It is a way of narrowing the focus of risk management and managing by exception. In the overall risk management process, it is the step that occurs after risk analysis has been completed. The risk response plan should not be developed at this time. After the risks are ranked and prioritized, a response plan can be developed.

Objective of Prioritizing RisksThe objective of risk prioritization is to let the project team determine which risks will be planned for in advance and which will not, based on the fact that there never will be enough time and resources to respond to all the risks associated with the project. When a prioritized list is created, there is a point when the team can see that the risks are better handled through workarounds than through strategies that have been carefully planned up front. At the same time, prioritizing risks gives you a sense of the level of risk tolerance in the project team and in the organization.

The project manager must not forget that ranking and prioritizing must be done with both opportunities and threats. This point highlights another way to characterize the main objective of prioritization. It is done to decide which threats to avoid or mitigate, and which opportunities to pursue or enhance.

Risk Prioritization Process and Tools

OverviewThe risk prioritization process is based on input that comes from the risk analysis process in the form of a list of analyzed risks and a prioritization structure. Proven tools and techniques to help prioritize risks include quantitative and qualitative assessments, expected value analysis, filtering, and comparative risk ranking. The final output should be two lists of prioritized risk events, one for threats and one for opportunities.

Each risk should be ranked quantitatively (that is, 1 through n), if possible, because quantitatively ranking provides more tangible information. Otherwise, a qualitative ranking system may be used (first all high risks, second all medium risks, and so on). These two approaches were discussed previously in Module 3. Risks should be prioritized by the whole team to consider all useful input and try to reach consensus.



Expected value (abbreviated as “EV” and also known as “exposure” for threats and “leverage” for opportunities) was addressed in detail previously in this module. It is a technique that naturally lends itself to relative risk ranking and prioritization. For example, a $50,000 risk impact with a 50 percent probability might be given higher priority than a $100,000 risk impact with a 10 percent probability, because the respective EVs are $25,000 and $10,000.

Filtering and comparative risk ranking (CRR) are two more approaches to prioritization. Although they are two separate techniques, Strategy Execution recommends using them together. The filtering process does not really prioritize. It is a question and answer technique that removes risk events that are currently less important from immediate consideration. CRR actually ranks or prioritizes risk events. Naturally, the information developed is only as good as the people involved, so people who understand the risks being analyzed and the organization’s risk tolerance characteristics must participate.

FilteringFiltering is using a series of questions to set aside risks that will not be immediate priorities. This is an example of a very simple three-question filtering process:

For each risk, ask whether the probability of the risk exceeds 25 percent. If it does not, remove it from the priority listing.For each remaining risk, ask whether the cost impact of the risk exceeds $10,000. If it does not, remove it from the priority listing.For each remaining risk, ask whether the risk is expected to occur within the next three months. If it is not, remove it from the priority listing.

The remaining risks make up your active priority risk listing. To use filtering effectively, you must know your or your organization’s priorities. That allows you to establish the filters that will focus risk management on the right risks. Some organizations put higher priorities on other issues than the sequence presented here. It is perfectly reasonable to use different questions and use them in whatever order best reflects project and organizational priorities.

Note that you never discard a risk event just because it does not satisfy one of the filtering questions. The answer to the question for a filtered risk event could change at a later date, so instead of removing such risk events from your risk listing, you temporarily exclude them from further consideration in the risk management process at the step of risk prioritization. You can only safely discard a risk event from your listing when you are absolutely sure that the risk event can no longer be an issue. You must therefore revisit the filtering process on a regular basis during the course of the project.

Comparative Risk RankingComparative risk ranking is a technique that asks a group of people one comparative question about each risk event on a risk event listing compared to each other risk event. It is based on the fact that any priority listing assumes that the items being listed have more or less importance relative to each other. Using a very simple example, this technique works as follows:

Assume you have five risk events to prioritize.



Assume you have three people ranking the risk events.The comparative question for each possible pair of risk events is: “Which risk deserves higher priority?”For each pair, each person must answer the question by choosing one risk event or the other. The possible breakdowns of answers for any pair of risk events include 3–0, 2–1, 1–2, and 0–3. For any given pair, each risk event may be chosen one, two, or three times; these choices are assigned as points to each risk event whenever it is chosen over another.After all pairs are evaluated this way, the points for each risk event from all its pairings are summed. The higher the number of points a risk event has, then the higher its priority is deemed to be.

CRR is best used for ranking risks that have similar levels of impact. When it is difficult to decide which high-probability, high-impact risk is worse among a grouping, CRR can help find an answer. Because it is the only tool that compares each risk event to every other risk event, it is an unusually powerful tool, and the results of which deserve great credence.

Prioritized Risk

Final OutputThe final output of risk prioritization should be two ranked and fully analyzed lists of risk events, one for threats and one for opportunities. Ideally, all risk events would be presented using uniform quantitative formats for probability, impact, overall rating, and priority. That is often impossible in the real world. Some risk events may be expressed quantitatively, some qualitatively, and some even in narrative format. It is rare that all project risk events will be completely quantifiable or that none will be quantifiable.

Module Summary

SummaryThe product of the probability and impact of a risk event determines its expected value.Risks may be analyzed using narrative, qualitative, or quantitative approaches.You must prioritize risks because there is never enough time or money to respond to all risks.Financial measurements can be used to assess business risks.PERT analysis can be used to assess schedule and cost risk.Monte Carlo simulations can be used to assess risk for large, complex projects.



Module 5Planning Responses to Risk

Module Introduction

Module OverviewThis module discusses the fifth step in the risk management process, risk response planning.

Risk Response

OverviewThe project manager must lead the team in planning effective risk response strategies to counter those risks that have been identified, analyzed, and prioritized thus far in the project. This requires the evaluation of risk response options and documentation of the response strategies to be used. In performing this function, the project manager should be aware of the types of risk response strategies available and choose appropriately based on the nature of the risks involved.

Step 5: Plan Responses to RisksRisk response planning is basically about answering the question, “What should we do about this particular risk if it happens?” In this step in the risk management process, the project manager uses information previously collected about project risks to develop specific strategies for handling them. This step must be performed for both threats and opportunities, and the responses that are developed should be incorporated into the project risk plan and the overall project plan.

Module 5: Planning Responses to Risk


Risk Response Planning Process

IntroductionThe risk response planning process is a process within the overall risk management process. It begins with two key pieces of input, the prioritized risk listing and the project plan.

The process should include the planning of several strategies, followed by the selection of the best strategy—including ways to handle both threats and opportunities. This part of the process can be considered an attempt to answer questions such as the following:

Can this threat be accepted?Can this opportunity be ignored?Can this threat be avoided or minimized?Can this opportunity be maximized?Can this threat be transferred to another party?

Because risks often do not operate in isolation, a response strategy for one risk may affect others by exacerbating them or by making them more tolerable. A risk response strategy also may create an entirely new risk. Therefore, after making preliminary decisions about response strategies, the project manager should conduct an assessment of the effects of implementing those strategies on other project risks. If alternative strategies can be used, they should be substituted into the plan. Evaluation of each strategy against the other should continue until the optimum set of strategies is chosen. That set of strategies should then be incorporated into the risk management plan and the project plan.

Regardless of which options are ultimately chosen for incorporation into the plan, documentation of all response options available should be maintained. If the primary response fails, the project team can then examine the documentation, reassess its options, and substitute a back-up risk response if that proves practical.

Response Strategy ContextThe project manager must be cognizant of the overall context within which risk response strategies are developed. Recall that the project plan is one of the two primary inputs to the risk response planning process. This is because the whole purpose of risk management is to increase the chances for a successful project outcome. Risk response strategies must therefore be consistent with and assist in achieving overall project objectives. The existence of a combination of risks is an important context because a single strategy could sufficiently mitigate several risks. The ability of the project team to assimilate the strategy is another essential context, since the team must be ready, willing, and able to execute the strategy in order for it to be effective. Finally, the strategies adopted must account for any project constraints. If there are



constraints prohibiting the implementation of certain strategies, those strategies must not be selected.

Risk Response Strategies for Threats

Four Types of Risk Response StrategiesIn responding to threats (negative risks), there are four types of threat response strategies that may be used:

AcceptMitigateTransferAvoid

AcceptSometimes a project manager must accept a risk because there simply are no strategies available to deal with it. At other times, a project manager may decide to accept a particular risk because that is the most sensible approach. This should happen if analysis of all possible avoid, transfer, and mitigate strategies reveals that their costs will be higher than the amount of risk that can be tolerated. In either case, the project manager and the organization must be able to tolerate the consequences of the accepted risk should it occur.

There is, however, more than one way to accept a risk. Passive acceptance means that nothing will be done to prepare for the risk in advance; instead, it will be dealt with if and when it occurs. Active acceptance means that the risk is accepted for the time being, but a contingency plan is developed for implementation later in case the risk occurs. This can be done using some amount of money or resources in reserve to be drawn on if the risk occurs.

MitigateThreat mitigation means either reducing the probability of the threat’s occurrence or minimizing its impact if it does occur. In other words, it is an attempt to reduce risk exposure that is too high to be acceptable. This is so because risk exposure is the product of probability and impact.

The probability of a threat event’s occurrence can be reduced by using similar techniques to those used to avoid threats, for example, adopting simpler approaches or adding resources. The difference is that the chances of the threat’s occurrence are merely reduced, not eliminated altogether.

The impact of a threat’s occurrence can be reduced through the use of safety measures. Good examples of this approach can be taken from projects that conclude with the cutover to a major



new software program. The threat of system failure and loss of data during cutover can be mitigated by backing up the legacy system and running both systems in parallel until the stability of the new system has been fully confirmed.

TransferThreat transfer does not eliminate the threat. Instead, it shifts the threat and responsibility for responding to it to another party. Transference almost invariably involves some sort of legal or contractual relationship. The most obvious is liability insurance, for example, shifting the risk of property damage to an insurance company. Buyers in all industries risk purchasing deliverables that fail after sellers have completed their work on the project and been fully paid; the buyers transfer that risk back to the sellers through warranties and guarantees, and sellers transfer some of it back issuing strictly limited warranties and guarantees. Owners of large construction projects invariably transfer the threat of contractor default by requiring the contractor to provide surety bonds for performance and payment of subcontractors. Even simple contract terms that seemingly have nothing to do with risk can be used to transfer enormous threats. Price terms are good examples, where cost-plus contracts place the risk of cost overruns entirely on the buyer and fixed-price contracts place it entirely on the seller.

In adopting a threat transfer strategy, you should always remember that transference is not likely to be free. The party that the threat is transferred to will invariably want something in return, and that will usually mean some form of payment. Often the end result is that the risk-intolerant buyer rids itself of the possibility of facing an extremely damaging worst-case scenario while the seller accepts the threat transfer for a fee based on risk exposure (expected value) plus some reasonable return. The seller can do this because its risks actually occur according to expected probabilities over the course of many contracts.

AvoidAvoid is the most direct threat response strategy. It means eliminating a threat, or at least eliminating the possibility of it having any impact on the project. How can you avoid a threat? You will not always be able to, but depending on the nature of the threat, it can be done. For example, the chances of a resource shortage on an earthen dam construction project may be eliminated altogether through the purchase of additional heavy equipment. Substituting a simpler, time-tested component may eliminate the possibility of delays to a systems integration project because of incorporation of a highly complex and previously untried product. In general, any significant threat should be avoided if the avoidance approach is relatively simple and has no other adverse effects.



Risk Response Strategies for Opportunities

OverviewLike threats, opportunities also can be addressed using various response strategies. The basic approaches include the following:

AcceptEnhanceExploitShare

Strategies for dealing with opportunities are conceptual opposites of corresponding strategies for dealing with threats.

AcceptAccepting an opportunity, corresponds to accepting a threat. You simply decide to actively or passively accept the responsibility to deal with the event if and when it arises.

EnhanceEnhancing an opportunity means trying to increase its expected value. It is the opposite of threat mitigation because you try to increase rather than decrease either the probability or the impact of the opportunity, or both.

ExploitExploiting an opportunity is the opposite of avoiding a threat, since you try to ensure that the risk does occur instead of ensuring that it does not.

ShareSharing an opportunity uses the same logic as transferring a threat. You share the opportunity with another party that takes the responsibility for making the opportunity occur. Then you both can share in the wealth.

Risk Response DevelopmentAfter you have reviewed each risk identified and assigned a strategy to minimize the threats and maximize the opportunities, now you need to develop the response plan. What will you do to achieve the goal with that risk? What will you do if that risk event actually happens? What is



your alternative plan? Who on your team will be responsible for ensuring that the right actions are taken?

Planning your response to a risk is more than just saying, “I choose to mitigate that risk.” Is it better to accept or maybe transfer? What actions are required to ensure that the risk is truly mitigated or transferred? This is just like a mini-planning session, but for just that circumstance where that risk is about to happen. Let’s look at an example to help explain what is needed in the risk response plan.

You are working on a project to create a new parking lot next to a large, old historic building. You review the risk register and determine that the city government zoning restrictions may force the cancellation of your parking lot, and the preservationists will try to make your parking lot hidden or in the same ‘style’ as the historic building. According to your contract, if the businesses double their revenue the first year of the parking lot being open, your company will be rewarded with a percentage of that revenue. So with the parking lot visible from the main road, the business within the historic building might generate even more revenue. Your possible response strategies for these threats include—

ZoningMitigate: Talk with the local residents and government officialsTransfer: Transfer the ownership of the parking lot to a larger company (like a holding company or shell company)Accept

Active: Read the laws and rework the project to ensure it fitsPassive: Wait for the government representative to stop up at your door

Avoid: Move the parking lotPreservationists

Mitigate: Create environmentally safe lots with special hazardous waste drainage system or hire a PR firm to counter the preservationists' messageAvoid: Move the parking lot

BusinessEnhance: Hire a PR firm to market the new lotExploit: Install signage indicating the parking lot availabilityAccept: Hope they do well

At this point, you need to determine through the use of expected value calculations or decision trees which response strategy is best for you.

Then you need to make a plan, sometimes locally referred to as a contingency plan, to have at the ready to respond. This plan, complete with its cost estimate and time requirements, should be addressed in the project schedule and budget as well.



Schedule Risk Response Planning

OverviewSchedule risk response planning also must include an evaluation of the project’s network schedule. In fact, the project manager cannot properly understand schedule risk exposures without the aid of a network schedule. That is one of the main reasons why network scheduling techniques are strongly preferred for project schedules.

Scheduling ImpactsIn the case of scheduling impacts, the harm that a particular threat risk might cause to the project is significantly influenced by the presence of float in the network schedule. For example, suppose that there is a 50 percent risk of a 90-day delay in procuring a particular project component. There appears to be a worst-case impact of a 90-day delay and a risk exposure (or expected value) of a 45-day delay, but if that particular procurement activity has 180 days of float, there is actually no impact or risk exposure at all, and the risk can be ignored.

Thus, schedule risk exposure only arises when the risk of delay approaches or exceeds the amount of float available to the activity at risk. When that situation occurs, the project manager should be concerned and should consider whether the threat is acceptable or requires some risk response planning. If it does, measures to avoid, transfer, or mitigate the risk should be evaluated against the network schedule until the optimum plan is determined.

Response Analysis Matrix

OverviewRisks and responses can interact in strange ways. Project managers need to analyze this interaction. The easiest way to do this is to create a matrix of risks and risk responses with the risks listed by row in priority order from top to bottom, and the response strategies listed across the columns. An example of a simple matrix is provided here for a shopping center developer’s project.



Responses: Risks Builder’s Risk Insurance

Payment and Performance

Bonds

Reduce Contract

Time

Perform Additional

Soil Borings

Fire or natural disaster +

Prime contractor default +

Liens from unpaid subcontractors

+

Unexpected subsurface site conditions

+

Open after holiday season +

Claims by contractor for additional time and money

+ -

Using the MatrixFor each combination of a risk and a risk response, the matrix is marked with a plus (+) or minus (-) sign to indicate a positive or negative effect on risk exposure. As the sample matrix shows, one response strategy may actually solve more than one risk problem. Requiring performance and payment bonds addresses the risks of contractor default and nonpayment of subcontractors, and providing additional soil borings minimizes the chances of encountering unexpected subsurface conditions and reduces the likelihood of contractor claims.

On the other hand, the response to one risk may exacerbate another, as in the case of shortening the contract time. Although this strategy is designed to maximize chances of completing the project in time for the holiday shopping season, it also increases the probability of contractor claims by making the schedule more difficult to meet. And of course, one risk may be affected in different ways by two different strategies as the risk of claims is by providing additional soil borings and by shortening the contract time.

The key point to recognize is that risks and responses can interact in unexpected ways, so the relationships of all risks and response strategies must be considered together at the conclusion of response planning. The risk response matrix is a useful tool for studying this interaction. The final step in using it is to decide which strategies will be implemented and which will not. The plus and minus signs for those that remain a part of the risk response plan can be circled on the matrix to indicate that decision.



Reserves

OverviewAlthough there are two types of reserves used in project budgets, the distinction between the two is not always clear. In the federal sector, the two types are generally well-defined and consistently used; in the private sector, however, organizations often do not delineate between the two, nor do they use them consistently. Nevertheless, it is important to understand the two types, how they are typically apportioned, and what the project manager should know regarding how his or her organization defines and uses reserves.

Contingency Reserves—Normally, the amount of money (but can be other resources including time) set aside for those risks that can be identified and are likely to occur. These reserves are typically a part of the cost performance baseline and final budget. Most organizations authorize their use to the project manager.

Management Reserves—An amount of money that senior management sets aside for unknown circumstances. The amount in this pot of money varies from organization to organization but usually is calculated on some percent of the overall project cost based on historical data from similar projects. For instance, an organization may have experienced enough unknown risk occurrences that it knows to expect a 15 percent increase over planned costs. The senior management controls the management reserves, which are not usually accessible to the project manager. To access these reserves, the project manager would, therefore, have to make a case to senior management for using the money and then obtaining the authority and funds. (It is worth noting in passing that federal sector customers usually do not approve management reserves in the negotiated project contract because they view this as “gold plating.” Actually, it also is difficult to get approval for contingency reserves in a federal sector contract unless there are clearly definable potential risk events. In the private sector, however, both types of reserves are very common.)

To complicate the subject of reserves even more, private sector organizations often don’t delineate between contingency and management reserves. Rather, they opt just to set aside funds (or other resources) and simply refer to them as “reserves.” Whether the project manager or senior management controls this category is determined by the organization.

Factors in Determining ReservesMany factors need to be assessed to determine reserve amounts. The earlier the risk occurs in the project life cycle, the higher the need for reserves, because additional unknowns may occur. The type of contract is significant to a seller’s project manager because fixed-price contracts require more reserves than cost-plus contracts. The corporation’s risk tolerance level also will affect the reserve level. If a company has a high tolerance for risk, it may not want much reserve, because it is willing to run the risk. If a company has low tolerance for risk, it may opt for a solid reserve. Risk exposure is an obvious factor influencing the size of the reserves. If the



risk exposure is high, set aside a comparable reserve. If there is not much risk exposure, a reserve is not as important.

Risk Reserves BudgetingThere are two key points to consider in budgeting reserves. First, the determination of reserves is essentially an estimating process. Second, reserves should be broken into smaller units in the WBS, using the same process that was used for actual work tasks. This is essential to accurate reserves estimating.

The total project budget is composed of the total of the project performance budget and the reserves budget. When risk response planning is completed, tasks included in the plan or WBS to mitigate risk events should be included in the project performance budget. They should still be tracked as costs related to risk management for lessons learned purposes.

Contingency Reserves for Actively Accepted RisksWhen the project manager has contingency plans for actively accepted risks, the costs associated with executing the contingency plans must be accounted for in contingency reserves. This is done by calculating the total or net amount of the cost impact after the contingency plan was executed and the cost of executing the contingency plan. For example, assume the following situation:

A risk event with an impact of $30,000 and a 50 percent probabilityA contingency plan that will cost $5,000 to execute and reduce the impact of the risk event to $10,000

In that case, the original and contingency plan risk exposures (expected values) can be calculated as follows:

Original EV = 50% x $30,000 = $15,000Contingency plan EV = 50% x ($5,000 + $10,000) = $7,500

By performing this sort of analysis for all actively accepted risks and summing all the risk exposures, the amount of money needed for the contingency reserve allowance can be determined.

Contingency Reserves for Passively Accepted RisksContingency reserves are established to allow for estimating inaccuracies associated with passively accepted risks. There are no industry standards, but many organizations have their own. The objective is to put enough into reserves to cover overall systematic estimating errors. Based on Strategy Execution client experience, the percentage of contingency reserves is typically 5 to 20 percent of the total project budget.

The problem being addressed is that a project manager may have a lengthy list of passively accepted risks. Some of these risks will occur and some will not. The risks that occur will have an impact, and the project manager must determine how much should be put into reserves to account for this situation. Since not all of the risk events will occur, some average or weighted



average amount should be set aside based on historical data if it is available. A general rule of thumb is to add an additional 10 percent that can be used to account for these risks.

Management ReservesThe quantification of management reserves is usually based on an organization-wide planning standard set by management. This standard usually is a percentage that has been derived from historical data and variances. Based on Strategy Execution client experience, the percentage of management reserves typically is two to five percent of the overall project budget.

Module Summary

SummaryRisk responses must be developed for each significant risk.There are four basic threat responses: accept, mitigate, transfer, and avoid.There are four basic opportunity responses: accept, enhance, exploit, and share.One risk response strategy may affect another risk response strategy.Reserves should be used to mitigate both cost and scheduling risks.Risk response strategies should be integrated into the risk management plan and the project plan.



Module 6Executing, Evaluating, and Documenting Risks

Module Introduction

Module OverviewThis module discusses the final step in the risk management process, monitoring and control.

The Final Risk Management Steps

IntroductionAfter completing risk response planning and the steps in the risk management process that precede it, the project manager must be able to lead the project team through effective execution, evaluation, and documentation of risk responses while the project work is actually accomplished and the risks that occur are actually addressed. Working with the project team members, the project manager must implement clear lines of responsibility for risk responses.

For those cases where risks are planned for, the team must evaluate the effectiveness of existing risk strategies and deploy updated strategies when necessary. For cases where workarounds are relied on instead of planned risk strategies, the team must also assess the viability of any unplanned risk responses.

Risk Monitoring and Control

OverviewThe process involved with monitoring and controlling risks during the project implementation phase is the process of implementing risk response plans, tracking identified risks, monitoring residual risks, identifying new risks, and evaluating risk process throughout the project. This process must be integrated with the overall project planning, execution, and control processes, relate to the accomplishment of project objectives, and be performed continually during the project. It essentially involves the three steps of the risk management process—executing,

Module 6: Executing, Evaluating, and Documenting Risks


evaluating, and documenting the risk management plan—all of which are performed continually and simultaneously during the course of the project.

Risk Response ControlCertain common terms are used in connection with risk response control in general. Risk events that materialize in a project are “problems.” This is true for both known risk events that are anticipated and identified on the project’s risk listing and unknown risk events. In other words, when project managers and others discuss problems that have occurred on a project, they are really referring to risks that have materialized. A windfall is the opportunity equivalent of a problem. In other words, it is a realized opportunity rather than a realized threat, and may be known or unknown. A workaround is a response to a problem that has not been planned for. Corrective action is the execution of a response to a problem, whether planned or unplanned.

The risk management plan is the basis for risk response control. It tells project managers what actions they will take to help control risk, how they will control risk, who will take action, how the plan will work, and when the plan will be initiated. Risk response control is based on a feedback cycle of executing responses to problems and windfalls, reassessing the risks that have occurred and the effectiveness of the responses to those risks, and updating risk response plans accordingly. Risk response plans will cause the project team to execute planned responses, and the results will cause them to see how effective the responses are compared to the plan and to respond further if necessary. These actions are integrally related to project execution and control processes.

Meanwhile, deviations and variances from the overall project plan will affect the project risk management plan. As project performance unfolds, the project manager should regularly reassess risks and the project’s risk management plan and update it in light of what has happened so far on the project. Project managers should continue going through that process until execution is complete.

As problems materialize, certain choices must be made. If the problem was not planned for, the project manager may decide to accept its impact or develop a workaround on the spot that is designed to avoid, transfer, or mitigate the problem. If the problem was planned for, the project manager may execute the planned corrective action, and do no more if the results are acceptable or implement additional workarounds if they are not. The project manager also may execute contingency plans. Meanwhile, the project manager should be regularly reassessing risks and identifying new ones.

Risk Response Control GuidelinesIn order for risk response control to work, the project manager must adopt the following practices:

Closely monitor project progressPromptly execute risk responses when problems or windfalls occurThoroughly evaluate the effectiveness of risk responsesImplement further responses when necessary



Regularly monitor and follow up on the status of project risksThe risk management plan is a critical component of the project plan because the only way to perform all these functions effectively is to perform them as part of the overall project management plan and process.

Step 6: Execute Risk Strategy

OverviewThe sixth step in the risk management process is executing the risk strategy. Just as the project manager must follow through and execute the project plan, he or she must do the same with the risk management plan. Because the risks arise out of the project, there is no way to implement a risk plan without implementing the project plan at the same time. At the most basic level, the execution step in the risk management process means carrying out risk response strategies. Note that not all risk strategies require implementation. Many (particularly acceptance) require action only when the risks become actual events. Meanwhile, as the project progresses, risk evolves and the project team must be kept up-to-date. This can be done by the project manager in a variety of ways, including through meetings, e-mail, or managing by walking around.

Early Warning SystemsOne key to successful execution of a risk management plan is catching problems before it is too late to respond to them effectively. Establishing early warning systems that identify risk triggers and provide notice that a problem may need to be addressed can do this. These triggers can be specifically associated with particular risks or more general feedback mechanisms about the status of the project.

A specific trigger event is a situation that alerts someone that a particular risk event has occurred or is about to occur. For example, the risk of depleting a battery power back-up system during a data-conversion process may use a power outage of more than 30 minutes as the risk trigger and the start-up of an emergency generator as the risk response. More general feedback from basic project status reports can also serve as triggers for responses to a variety of risks. Examples include such project performance measures as earned value, cost variance, delays in the project completion date, or disappearance of float time. Negative variances in any of these measures may serve as warnings of problems with subcontractor performance, customer cooperation, or the original project estimates.

You should monitor risks exactly as you would monitor project status. This means that risk review should be included as a regular agenda item for project status meetings. Such a review should involve discussions of the following topics:

Progress made to date in executing the risk management planAny threats or opportunities that have passed without becoming problems or windfallsAny new problems or windfalls observed or anticipated



Any actions required in terms of updating or implementing risk response plans

Responsibility for Risk Response ControlSomeone must be responsible for each aspect of risk response control. The project manager needs to assign responsibility for risk response control just as carefully as he or she would any other important task. This is extremely important, but it is not particularly difficult. Simple tools such as responsibility matrices or action item lists can be used to make clear who is responsible for what. Responsibility for particular risks and for execution of their response strategies also can be documented on the project’s risk listing. The important thing is that the method used must identify specific individuals for specific responsibilities.

Step 7: Evaluate Results

OverviewOn a regular basis throughout the project, the project manager should evaluate the effectiveness of risk responses and the risk management plan. It is important to determine whether a risk response strategy proved to be either effective or ineffective so that others can be informed of the results and decide whether to use it in the future. Opportunities to revise the risk management plan that might not be seen without such ongoing evaluation also may arise during the project.

Risk EvaluationThe input for risk evaluation starts with the risk management and project plans. It also includes cost and schedule data and information about any technical or scope issues that have arisen. All this information is evaluated, along with corrective actions that have been taken and their results, in order to determine the effectiveness of the risk management process to date.

This determination is made by periodic reassessment of risks throughout the execution process. This reassessment may raise a variety of questions, such as the following:

Are the identified risks still the same? (New risks may have arisen; others may have passed.)Are the probabilities of the identified risks still the same? Are their expected impacts still the same? (Either of these components of risk exposure may have changed for any risk as a result of what has already transpired on the project.)Were the consequences of the response strategies the same as envisioned? (In other words, how well did the response strategies work?)Given the answers to those questions, should planned risk responses stay the same or be revised? (Depending on the timeliness of the reassessment, it may not be too late to try a different course of action.)



All risks and responses, including risks that were filtered out, must be regularly evaluated in this manner throughout the project life cycle. The net result is that the project manager is trying to determine if any additional actions are required.

Evaluating Risk ResponsesThe evaluation process for risk responses and corrective actions should be specifically related to the nature of the risk responses that were selected. Questions to be answered include the following:

Have avoided risks truly been eliminated?Have mitigated risks been sufficiently contained? (The intent of a mitigation response is not to eliminate the threat entirely, but just enough to be tolerated.)Have transferred risks been fully shifted to other parties? (Sometimes they have a way of coming back to haunt the party transferring the risk, especially if the risk transfer is based on onerous contract provisions that shift risks to a party that is not well positioned to manage them.)Can accepted risks that have materialized really be tolerated? (Their impacts may be worse than expected.)Have contingency plan results been satisfactory?Have workaround results been effective?Has the possibility of the risk event’s occurrence expired?Is any further action required?

Risk Reassessment—Updated Risk IdentificationIn addition to evaluating corrective actions, project managers must continually reassess the risk management plan, starting with risk identification. This means validating risks already being tracked and identifying any new risks that have arisen. Common sources of new risks include—

Cost or schedule variancesChanges in requirementsPersonnel or stakeholder changesOrganizational and environmental changesChanges in resources and their utilization

The output of this step is an updated list of risk events, and the list should address both threats and opportunities.

Risk Reassessment—Updated Risk AnalysisThe next step in risk reassessment is reanalyzing risks. This starts with determining whether the probability of each risk occurring is the same and whether the impact of each risk is the same. For example, suppose the following:



The project uses a work force of several trades in five different unions.When the project was launched, all five union agreements were due for negotiations within the next six months, and threats of strikes were common.Each union would honor any other’s picket line.The original project risk listing identified a project shutdown caused by a strike as a risk with a 60 percent probability and an impact of 30 days on the project schedule.The original mitigation strategy was to accelerate the work by paying considerable overtime to trades working on critical activities, because that would be less expensive than the risk exposure associated with delaying completion of the project.

Now, further suppose that three months into the project, four of the five agreements have been successfully renegotiated with remarkably few problems and that rumors of a strike have ceased. Clearly, the risk of a strike requires reanalysis. The project team might now reassess the risk exposure as having a 10 percent probability and an impact of 20 days. Depending on how the product of those two factors compares to the cost of the mitigation strategy, acceleration of the project through use of overtime might be reduced or eliminated altogether. The latter choice would mean accepting the reduced risk exposure.

Risk Reassessment—Updated Risk PrioritizationAfter reanalyzing the updated risk list, the project manager must reprioritize the entire list, since priorities can change. This is true because tolerances for particular risks and risk tolerances in general may change over time, even during the duration of the project. Project stakeholders or sponsors may change, and a new sponsor of a project might want one risk given priority over another risk, changing the order of priority. In addition, entirely new risks may have been identified during the risk reassessment process.

When to Perform Risk ReassessmentGenerally speaking, you should reassess risk at regular intervals. The intervals should vary based on the nature of the project. If you are running a major project that spans 10 years, you do not want daily reviews. If your project spans four weeks, a weekly review may not be enough.

Regardless of the overall project duration, you should reassess risk whenever major changes occur. Project managers must never forget that changes occur on projects. Things go right, and things go wrong. Things move ahead of schedule, and things fall behind. As changes occur, risks must be reassessed. Similarly, if some major decision must be made, it is time to reassess risk. This means that before major decisions are made, planning for the associated risks should be completed.



Step 8: Document Risk Management Results

OverviewDocumentation is the one remaining step in the risk management process. Although many people think documentation is a waste of time, it is important for a variety of reasons. Documentation provides a written account that risk management occurred and can be used to prove that risk management was integrated into the management of the project if that should become necessary. Naturally, a written record is preferable to an oral record or “institutional memory,” either of which can often be unreliable and biased. Documentation also provides information on how risk management was approached and the rationale for actions taken. This documentation can be vital to a later understanding or explanation of the course of action that was taken. Without such a record, the project manager might be hard pressed to explain his or her actions to upper management.

Keeping thorough documentation also ensures that the organization will have historical data available for use in managing future projects and helps produce valuable lessons learned records. It provides information on what worked, what did not, and why or why not.

Risk DocumentationRisk documentation should include all the input and output of the risk management process, such as the original risk listing, risk analyses, the original prioritized risk listing, and the risk response plan. It should likewise include any updates or revisions to these items that were generated during the evaluation and reassessment of risks in the project execution phase.

Because risk documentation spans the duration of the project, it needs to be maintained on an ongoing basis. Organizations that document projects successfully document them in a consistent way. Some organizations encourage project managers to read the documentation of other project managers. They do so by ensuring that project managers are rewarded on their ability not to repeat the mistakes of others. This incentive is made part of their performance package.

Final Steps During Project CloseoutEverything covered so far has been going on continually during the project life cycle. However, the project eventually will come to an end. At that point, the final project documentation, including a final risk assessment and lessons learned, should be prepared by the project manager.

In the final risk assessment, the project manager prepares an overall assessment of how the project concluded from a risk management perspective. The assessment should cover issues such as the effects of risks and response strategies on the project’s cost, schedule, and



performance; whether the customer was satisfied with how risks were managed; the extent to which risk management objectives were achieved; and identification of any organizational recognition or rewards associated with risk management.

Whether it is incorporated in the final risk assessment or prepared separately, the project manager should prepare documentation of risk management lessons learned when the project nears its end. The purpose is to reduce threats and increase opportunities for future projects by documenting the experience with risks on the project being completed. The lessons learned also can include improvements and updates to standard forms and processes such as WBS templates, network schedules, estimating, procurement, and contracts.

Module Summary

SummaryThe project team must perform each risk response and contingency plan during the project life cycle.If unknown risks occur during the project, workarounds should be used to control variances.Risk reassessment should be continually performed throughout the project life cycle.The project team should fully document the performance and results of the risk management plan on an ongoing basis throughout the project life cycle.



risk management - elearning.esi-intl.comelearning.esi-intl.com/blendedlearning/ilt/ctl_v3... ·...

Documents