Assessing Risk

Overview

Each of us takes risks everyday. For most of us, reasonable risks don't prevent us from doing our daily tasks and routines. The same is true for our projects. But you must identify the risks and analyze their potential impacts and the possibility that the risk will happen during the course of your project in order to know how to handle the risk should it occur.

The goal of this chapter is to show you how to create the risk management plan. This plan consists of risks you've identified that could impact the project, an analysis of the risks and their impacts, planned responses for the risks should they occur, and a determination of how risk management processes will be implemented and monitored throughout the project.

One thing is certain—risk does exist on your project, and it poses either a potential threat or a potential opportunity. It's your job to document the risks and determine which ones need response plans.

In this chapter you will learn:

• Identifying risks
• Planning for risks
• Using risk-analysis techniques
• Responding to risk
• Contingency planning
• Creating the risk management plan

Identifying Risks

A risk is the possibility of a problem occurring on the project, thereby threatening the project's outcome in some way. However, not all risks are bad, and not all risks have negative impacts. Some risks are actually opportunities in disguise. For example, agreeing to take on and complete a new project is a risk. Since one of the definitions of a project is creating a unique product or service, the project itself is a risk that's taken on to exploit an opportunity.

risk

An event that poses a potential threat or potential opportunity.

It doesn't matter whether the risk is a threat or an opportunity; if you don't take the time to identify it, you won't know that either exists. Failing to document risks and develop plans for those with the greatest probability for impact can cause your project to fail.

So why should you identify risks, and how do they cause projects to fail if you don't plan for them? Risk can cause rework, which means that you have to go back and repeat some activities you've already completed. Rework almost always means that there will be schedule delays or additional costs or both. If you've completed one of the deliverables of the project only to have a risk event wreak havoc with the results, you'll have to perform additional steps to correct the impact of the event, or perhaps you'll even need to scrap the work that's been done and start over. None of that will come without a cost. You'll likely need to retain resources longer than you had planned, which could jeopardize other projects as well as cost you more money. If all your resources are internal to the organization, you will still incur additional costs. The extra time they are spending on your project prevents them from doing work on other projects, thereby increasing the cost. Additional supplies and materials, extended lease times for equipment you're using on the project, and the replacement of resources that were scrapped all cost money as well.

Remember that your goal as the project manager is to complete the project to the satisfaction of the stakeholders. In order to do that, you'll need to know what obstacles can spring up along the way to prevent you from completing the deliverables on time and on budget. It isn't possible to know every risk in advance, but the more risks you identify and plan for, the less impact they'll have on the project outcomes. When you plan for risk events, the consequences of those risk events are reduced or perhaps avoided altogether. Take the time in the planning stage to identify risks and come up with action plans even for those risks you cannot avoid or reduce. You'll save yourself precious time figuring out what to do when they do occur if you've planned ahead of time.

Risk management is an activity that occurs throughout the life of the project. It begins in the Planning process and continues until the Closing process is completed. Good risk management practices helps you bring your project to a successful ending because you'll have plans in place to deal with potential threats before they occur and you'll have identified potential opportunities that may bring your organization more business, an increase in efficiency, or new ways of performing the work of the project. The advantages of practicing good risk management include:

• It helps you to identify potential project showstoppers early in the process and develop plans and strategies to reduce or avoid their impacts.
• It helps you to identify potential opportunities and exploiting them (maybe even creating whole new projects out of the opportunities that come about through the risk management process).
• It enables you to reduce rework and keep the project budget on track.
• It allows you to be proactive instead of reactive, which increases your credibility and reputation among the stakeholders.
• It increases the likelihood of project success.

Project risk is greatest at the beginning of the project because the potential for unsuccessful outcomes or incomplete projects is most likely to occur at the beginning of the project or in the early phases. At this point, so many aspects of the project are yet to be completed and thus have unknown outcomes. This risk decreases as the project nears completion. Careful attention to risk events during the Planning, Executing, and Controlling processes helps assure project success. Let's take a look at some of the risks all projects have in common.

Types of Project Risks

All projects have risk, and several risks are common to all projects no matter how easy or complicated the project appears.

Most risks fall into three categories: known risks, known risks with uncertain outcomes, and unknown risks. Obviously, there isn't much to say about the unknown risks category. By nature of the fact that they're unknown, you can't identify them up front or create specific plans in the event they'll occur. You can plan for them in nonspecific ways, however. We'll talk more about those plans in a later section.

Known risks are events that you or the project team knows have the potential to occur, and they have predictable outcomes. For example, let's say you've been asked to head up your company's annual all-employee meeting. Your company employs 500 people, and all employees plus one guest of their choice are invited to attend the meeting. The owner of your company is a generous person and believes in sharing the wealth because, after all, the employees helped her get to where she is today. The meeting is going to be held at a famous resort in the mountains near your city, and each employee and their guest are encouraged to stay at the resort for one evening (at the company's expense). The meeting itself will consist of a formal dinner and an awards ceremony. Every employee in the company will receive something. You've been sworn to secrecy regarding the awards and will have to handle these arrangements yourself with no help from the project team.

Known risks with predictable outcomes are fairly easy to spot. An example of a known risk for this project would be the weather—the meeting is being held in November, which means there's a potential for a snowstorm that will prevent folks from getting to the resort.

An example of a known risk with an uncertain result in this case is the number of attendees. Even though you're limiting the employees to one guest each, there's the potential that some may bring more than one guest or that employees say they will attend with a guest but won't show up. Now let's take this one step further and find out how to identify specific risks for your project.

Common Project Risks Where Are They Hiding?

Risks can come from internal or external sources. Internal risks come about due to the nature of the project itself, organizational issues, employee or resource problems, and so on. External sources of risk include political issues, legal concerns, environmental issues, and social issues.

One of the first places to start identifying risks is with the project itself, looking at internal, known risks. Some of the planning processes you've already completed can help you with this task. The project constraints, WBS, task list, and critical success factors can help you uncover risks regarding the project itself.

Business risks are another area to consider when identifying risks. These include marketing concerns, timing of the product release, and public perception.

This section examines some of the common risks you may encounter on your projects. I'll conclude this section with a checklist that you can use as a template for identifying your project risks.

Constraint-Related Risks

Project constraints limit the project team in some way, and you usually know about them at the start of the project. Risks, on the other hand, are generally unknown at the beginning of the project. However, looking closer at the constraints can help you identify project risks. Remember that the triple constraints of time, resources, and quality generally have the biggest risk impact on the project. Risks are usually lurking in each of these areas. If time is your primary constraint, risks associated with this constraint could include loss of key personnel, lack of training opportunities in time for critical project activities, vendor delays, equipment failure, and so on. Each of these potential risks has an impact on the project schedule. So the project schedule, or time, is not only a constraint, it's also a key area for us to examine in the risk-identification process.

We can examine resource and quality constraints in the same way. Remember that resources include money, such as the project budget or funding, as well as people. You should consider breaking this constraint into two parts—project budget and project personnel.

For risk-identification purposes, it really doesn't matter which of the constraints is the primary constraint because each of them have associated risks. Exploring time, resources, and quality will almost always turn up risks on the project. Taking a closer look at each of the constraints is a good way to kick off the risk-identification process.

Identifying Risks in the WBS and Task List

Other great tools you can use to help in the risk-identification process are the WBS and task list. You can see how these planning tools begin to build on themselves and why it's important to document all the project plans. Not only can you use this information as a reference on future projects, you can use it now in the risk-identification process to help you identify potential threats and opportunities. (Here's a hint, you'll use all these documents again in the Executing and Controlling phases of the project.)

Using the WBS, examine the deliverables and the work package levels for risks. One of the deliverables for our employee meeting project is setting up the speaking area of the meeting room with a laptop, projector, and microphone. Some of the risks associated with this deliverable are equipment malfunction, lack of power, and delayed delivery of equipment.

Use the task list in the same manner. Examine each task from the perspective of what can go wrong. Add those risks, or things that could go wrong, to your risk-identification list. We'll talk more about the list shortly.

Critical Success Factors

We talked about critical success factors in Chapter 4, "Defining the Project Goals." They are usually deliverables or milestones that absolutely must be completed, and completed correctly, to consider the project a success. Again, look over your critical success factors to see what risks you can uncover that might be associated with them.

In Chapter 4, I gave you a list of some of the things I consider critical success factors for all projects. Let's look at a few of them again in light of the risks that could be associated with them.

Understanding of and consensus regarding the project goals by key stakeholders, project team, management team, and project manager Risk: If understanding and consensus are not reached, the project will not produce the results expected by the stakeholders, and therefore the project will be unsuccessful. This could result in the loss of business for your company or contractual issues that require legal intervention. Your own job or personal reputation could suffer as a result.

Well-defined scope statement Risk: Poorly defined scope will result in misdirection for the project team, leading to missed deadlines, continual scope changes, rework, inaccurate results, and/or increased costs.

Well-defined project plan Risk: The risks here are similar to what was outlined above in the scope statement risk, including rework, incorrect results, poor quality, increased cost, and missed deadlines.

The use of established project management practices Risk: Not using a standard project management process could result in a lack of communication and organization regarding the project activities, ultimately resulting in an unsuccessful project.

The theme is consistent regarding these critical success factors—if you don't take the time to adequately plan your project activities and communicate well with the project team and stakeholders, your entire project is likely in jeopardy. Planning is an important step in any established project management methodology. I can't emphasize enough the importance of planning, so don't skip these processes.

Business Risks

Depending on the type of project you're working on, business risks may not have as much probability of occurring as risks associated with the triple constraints or critical success factors, but you should be aware of them and identify them because their impacts pack a big punch. If you're caught by surprise and don't have a plan to respond to any of these risks that may affect your project, it could spell disaster. Let's look at some of the most common business risks.

Marketability If your project is the launch of a new product, marketability is a business risk. One concern regarding marketability is the question, Will customers really pay for this product? This project may build a product or service that everyone inside the company thinks is the next greatest blockbuster hit, but if customers don't perceive the product to have the same value as the company does, they won't buy it.

Timing Timing of the project is another business-related risk. For instance, maybe your project created the perfect holiday bakeware for home chefs, but due to schedule delays, the product didn't hit the retail shelves until January. Or, maybe your project was creating a documentary of the world's greatest ice cream parlors only to have the FDA issue a ban on all ice cream production for health reasons (heaven forbid!). Be aware of timing issues or impacts to timing issues like these as they could also cause an otherwise successful project to fall flat.

Management issues Management risks are related to business risks. Management issues that may pose risks to your project include changes in corporate strategic direction, reorganization of the business units, layoffs and cutbacks, and budget restrictions (after budgets have been approved for your project). If you're aware of these issues lurking behind the scenes, you should take them into consideration and evaluate the impacts they could have on the project.

Vendor delays Vendor delays and contract issues are another type of business risk. If you're relying on a vendor to deliver critical components or equipment at specific times during the project, you should note the failure to deliver these items on time as a risk. Contract issues can also delay project schedules or impact the project budget. If the vendor does not live up to the terms of the contract, you'll either need to take action to force them to comply or find another vendor. Either way, it will likely cause schedule delays and impact the project budget.

External Project Risks

External project risks include things that are outside the control of the project team and the organization itself. Political issues, legal issues, environmental issues, and social issues are a few examples. Don't overlook obvious things such as the weather, earthquakes, fires, sunspots, alien invasions, and so on.

Technical concerns can also be an external project risk. If you're relying on new technology for a project you're working on, but the release of the new technology is delayed, your project will also be delayed—unless you have alternatives to deal with this risk event. The opposite of this situation can occur as well. Aging technology can be a risk to the project if you're relying on specific technology for your project, but that technology is outdated by the time you're ready to launch the product of the project. Your product may not have a long shelf life as a result or, more likely, it will be canceled before completion.

Other Risks

There are a couple of other issues to think about when identifying risk. One risk that you should be aware of is the complexity of the project itself. Ask the team or project sponsor whether the project team has ever taken on a project of this magnitude before. If the answer is no, then you should document this as a risk and be aware that the project team may require additional training or you may need consulting services to assist the project team, and so on.

Also examine your own skills and ability as a project manager. Are you prepared to take on a project of this size? Have you had sufficient experience with other similar projects to lead this project to a successful conclusion?

Along these same lines, be sure to examine the skills and abilities of the project team members. If the project involves writing a new software program in a language that project team members are not familiar with, document this as a risk. Keep in mind that senior or experienced team members can help identify and mitigate risks more easily than junior team members with less experience.

Identification Techniques

The process of identifying risks is something the project manager should do together with the project team, the stakeholders, the project sponsor, and so on. In this section, we'll look at a few techniques you can use to get the team's creative thinking processes going to uncover as many risks as possible.

The first attempt at risk identification is more easily accomplished with a small group consisting of key project team members and key stakeholders. Using some of the techniques outlined below, document the risks the team comes up with during this initial meeting in a spreadsheet or other word-processing document. List each risk, assign it a number for tracking purposes, and identify its impacts or characteristics.

After you've compiled an initial list, hold another meeting (or set of meetings depending on the size of the project), expanding the number of participants to include more of the project team members and stakeholders. Again, use some of the techniques outlined later in this section to identify more risks with this bigger group, and add those to the risk list.

Some of the participants you should consider including in your risk-identification meetings are listed below. The project manager should always attend these meetings.

• Project team members
• Project sponsor
• Stakeholders
• Technical experts
• People who have experience on previous projects of similar size and scope
• Customers or end users
• Vendors (when appropriate)

Historical Information

One of the first places you should look for risks is past projects. Here's where those project notebooks you've been putting together and past project documentation come in handy. If you're working on a project that's similar in nature, scope, and complexity to past projects, you can review the previous project as a starting point for documenting risks in this project.

Brainstorming

You are probably already familiar with this technique. Brainstorming is a process in which the project team members, subject-matter experts, stakeholders, and anyone else who might have information or knowledge about this project meet in a single location and name the risks they see for the project.

brainstorming

A method of discovering risk events, alternatives, requirements, or other project information with a group of people who have knowledge of the project, product, or processes used during the project. This process is intended to produce freeform ideas, and no restrictions are placed on the participants.

A facilitator documents the items on a list or a white board, while the participants keep calling out the risks as they occur to them. The dynamics at work here are interesting. The old saying that two heads are better than one applies to brainstorming. Each of the participants will come to the meeting thinking about the risks that may impact their particular function or area. When you bring all these folks together, one group of stakeholders or functional managers will hear the risks the other groups are naming, which will bring to light new risks they might not have thought about if they were doing this individually.

The rules for brainstorming are simple. The group should not look down on anyone's ideas; in other words, no one is allowed to pass judgment. List all the risks identified, using one or two words whenever possible. Try to manage the group so that only one person is speaking at a time, but I'll warn you, once they start rolling with the ideas, it will be hard to keep them from speaking over one another. Keep the enthusiasm going, but do try to maintain order at the same time. Don't assume that one of the risks someone mentions is the same as a risk that was identified earlier.

Delphi Technique

The Delphi technique uses a questionnaire method to identify potential risks. The questionnaire asks participants about risks associated with the project, the business process, the product of the project, and asks the readers to rank their answers in regards to the potential impacts of the risks. In this technique, people do not have to be located in the same room and, in fact, they don't even have to know each other.

Delphi technique

A method of discovering risk events, alternatives, requirements, or other project information using a questionnaire format. This process uses a facilitator to solicit ideas, and participants are not collocated.

If you're acting as the facilitator, you can assemble your participants via e-mail or an Internet or intranet site. Experts from inside and outside the company are asked to identify potential risks for the project using a questionnaire that the facilitator wrote up ahead of time. The participants complete the questionnaire and send it back to you, the facilitator. You will then compile all the responses and organize them in some logical manner—by content or risk type, for example. After you've compiled the responses, you send this list back to each of the Delphi members and ask them for further input, additions, and comments. The participants send their comments and additions back to you, and then you compile a final list.

The Delphi technique removes bias from the process. Since the team members completing the questionnaire are not meeting together as a group, one member is not unduly influenced by others, and each one is free to state what they're really thinking.

Nominal Group Technique

The Nominal Group technique is similar to brainstorming, but it's more like brain-storming by secret ballot.

Nominal Group technique

A method of discovering risk events, alternatives, requirements, or other project information. This process uses a facilitator to solicit ideas in writing from the participants.

This technique requires all the participants to be in the same room together. Everyone is given a marker and a pad of sticky notes. You, the facilitator, then ask everyone to write one risk, and only one risk, on a note. You might consider starting out each round by telling the group to think of the most important risk or the risk with the greatest impact to the project and write that risk on a note.

You then collect the notes, post them on a white board or flip chart, and ask the group to think of the risk with the next-greatest impact to the project and write it down. Continue asking them to write down risks in this manner until they can't think of anymore.

After all the risks have been identified and posted on the board, ask the group to rank them and prioritize them. They should perform this first ranking and prioritization in writing, and each of them should submit their rankings to the facilitator. You then assemble and prioritize the risks in order according to the consensus of the written rankings. At this point, you can ask for input or clarification from the group. When you've finished, you'll have a complete list of risks in their order of importance or impact.

The rules for the Nominal Group technique are also simple. Only one risk can be written per note. Once the notes are posted and all the participants can see them, risks should not be duplicated in subsequent rounds. And the participants should not pass judgment on the risks submitted by others. Keep the group size to a manageable number when using these techniques, or you might end up stalling the process.

Interviewing

An interview is a question-and-answer session held with key stakeholders, team members, functional managers, subject-matter experts, and others who have an interest in the project or who have previous experience on projects similar to yours. These folks can tell you what risks are likely to occur on the project based on their experiences with similar projects.

Ask them about risks they've experienced on previous projects or what they think may happen on this project. Ask them about their industry expertise or specialized knowledge regarding the product of the project and its outcomes. Show them the WBS, the task list, and the list of constraints and assumptions to help them think of risks that might occur on this project.

Checklist of Common Project Risks

As we saw earlier, the most common project risks are those risks associated with the triple constraints: time, resources, and quality. If you focus on these three areas, you'll probably discover a great many of the risks that could affect your project. In a later section, we'll discuss how to determine and weigh the impacts of these risks.

Table 7.1 is a checklist of risks that you can use to help you begin to identify risks for your projects. I've listed the risks we talked about in the preceding sections in the first column and added a few new ones. You can add new risks to this list that consistently apply to the types of projects you work on. The next column on the checklist is an area for you to briefly note the impact of the risk or to note its characteristics. The last column is a check-off area where you can indicate that you've examined this risk category and documented the risks associated with it. This checklist is intended to be a guideline to start you thinking about risks and their impacts. The risks and impacts you list for your projects should be more specific than what this example shows. When identifying risks for your project, it's important to be specific. For example, simply listing "weather" in your list may not be specific enough. In our annual conference project, snow is much more difficult to deal with than rain and requires different planning. Keep this in mind when identifying your risks.

Checklists, like the one in Table 7.1, can be developed based on historical information or on the previous experience of the project team members. If you work on projects on a consistent basis that are similar in nature and scope, construct a checklist like the one in Table 7.1 to help you identify risks on future projects. Don't use checklists as your only form of risk identification, however, as every project is different and you might miss an important risk. Combine the use of checklists with some of the other techniques outlined here to find all the risks for your project.

Risk is something that good project managers plan for ahead of time and monitor throughout the course of the project. All project risks should be identified and documented. This checklist is a way to get your thought processes charged up to start identifying risks on your project. You should also check with your organization or industry associations for checklists. Many industries have checklists that are very specific and will help offset inexperience in the risk identification process or help make certain you've identified all the risks for complex projects.

As with all the other project documents so far, you'll file your list of risks and risk response plans in the project notebook, but you don't want to file them there and then forget about them. As you get closer to the risk event, you'll want to reevaluate the risk and the plans for that risk and make any adjustments needed based on new information you have at the time. So, keep your risk list handy or make a mental note to yourself to check the list periodically.

Once you've identified and documented the risks and their potential impact, you're ready to perform some risk analysis and rank and prioritize the risks. You'll want to know which risks carry the greatest threat so that you can then develop response plans for those risks. First, let's take a look at some analysis techniques.

Risk Analysis Techniques

The potential for serious risk can bring about a couple of reactions—we avoid the risk altogether, we take steps to minimize the risk, or we make plans to deal with the risk event in case it occurs. The potential that a risk will happen during the course of your project depends on the nature of the risk. If your project involves constructing a highway overpass in North Carolina, the probability of an earthquake is very low, so you wouldn't even bother coming up with a plan to deal with this risk event. However, the probability of a hurricane is very high, so you may want to take this into consideration as a project risk.

Risk analysis takes into consideration the probability that the risk will occur and its impact if it does. The end result of this process is a prioritized list of risks that you can use to determine which risks need response plans.

One of the easiest ways to rank the risks is using the Nominal Group technique that we talked about in the last section. After identifying the risks, ask the group to rank them in their order of importance. This technique will work for very small projects, but I recommend going a step further for all other projects and examining probability and impact.

Risk Probability and Impact

Probability can be assigned using a simple high-medium-low scale that ranks the probability for each risk. For instance, our fictitious annual employee meeting project is scheduled to occur in November. There's a high probability of snow in November, which could prevent employees from getting to the event or getting there on time. So, you would assign this risk event a high probability.

probability

The likelihood that an event will occur.

Examine the remaining risks on the risk list and assign a probability for each. Table 7.2 shows an example of a risk probability chart. The risk number is used to track the risk throughout the project and to tie it to a response plan a little later in this process.

Risk number 1 has a high probability rank, which means that this risk should have a risk response plan developed to avoid the risk or reduce its impact if it occurs. Risks number 2 and number 4 probably need risk response plans as well. You may want to combine the probability score with an impact score to help you further determine the need for risk response plans for these two. We'll cover impact scores shortly. Risk number 3 doesn't need any further attention, but it should remain on the risk list.

Probability can also be expressed as a value. The classic example is the coin flip. There is a 50 percent probability that you'll get heads and a 50 percent probability that you'll get tails on the flip. The probability that the event will occur plus the probability that the event will not occur always equals 100 percent, or 1.0.

For example, if there is a 60 percent probability of snow on the evening of the event, there is a 40 percent chance it will not snow, and the total of both probabilities equals 1.0. The closer the probability of the event occurring is to 1.0, the higher the risk.

Assigning Risk Impacts

Impact values can be assigned to risk in the same way that the probability scores are assigned. You can use a high-medium-low value to indicate the impact the risk event has on the project if it should occur. For example, the snow risk event has a high probability of occurring, and the impact is also high should this event occur. Any risk event with a combination of high probability and high impact should have a risk response plan developed to deal with the risk should it occur.

You can also develop predefined measurements that will qualify the risk event and tell you what value to place on the impacts of the risk event. For example, you can rate the impact using a high-medium-low scale like the one shown next. Depending on where the risk impact falls on the scale, it's assigned a value from .05 to .80. The ranks and values are as follows:

The snow event is assigned a rank of high, which means the impact's value or weight is .60. You'll want to assign a value to the probability of the risk event and to the impact of the risk event so that an overall risk score can be determined. The overall risk score, which we'll calculate next, will determine what type of risk response should be developed for the risk.

Probability Impact Matrix

Now we'll put this altogether in a probability impact matrix. The idea here is to multiply the probability score by the impact value to come up with an overall risk score. The higher the overall risk score, the higher the risk to the project. Table 7.3 shows an example of a probability impact matrix.

The risk management policies your organization has in place (or that you establish) may dictate that all risks with overall risk scores greater than or equal to .30 need risk response plans. This means that both the snow risk event and the banquet hall risk event need risk response plans. The risk response plans are documented in the risk management plan that we'll discuss later in this chapter.

How to Assign the Ratings

Assessing the probability and risk impact and assigning values to each are accomplished using some of the same techniques you used to identify the risks. You can consult subject-matter experts, use interviewing techniques, or use the Delphi or Nominal Group technique to determine probability and impact values. Once you have the values, you can calculate the overall risk score as we did in the previous section. The risk score then tells you what you should do about the risk.

Your organization may have policies already established regarding how to rank risks and what actions need to be taken to plan for the risk events depending on their scores. Some organizations have specialized teams who are devoted to risk analysis and risk management. But if your organization does not have any predetermined policies regarding risk management, you should spend some time developing them yourself by working with a few key team members, subject-matter experts, and stakeholders to determine the criteria for risk responses based on the risk scores.

Risk Tolerance

Risk tolerance is the comfort level you have for particular risk events. For instance, driving to work every morning carries some level of risk. Your car may not function properly, you could have a fender bender at the corner stoplight, or road crews could have set up a detour on your regular route that adds significant drive time to your commute. None of these risks keep you from coming into work, however. The benefits of going to work and generating revenue for the company, gaining satisfaction from a job well done, and earning a pay-check for yourself outweigh the risks of driving to work. That means you're willing to take the risk of driving to work to get the benefits.

risk tolerance

The amount of risk a person or organization is willing to tolerate in exchange for the perceived or actual benefits of partaking in the activity.

Organizations, like individuals, also have risk-tolerance levels. Some are more risk averse (that is, they avoid risk at all costs) than others. Stakeholders also have risk-tolerance levels you should consider when planning for risks. One organization may think nothing of taking on a project that has a high likelihood of failure because of the information they'll gain in the process, while another organization wouldn't even allow the project to make it to the project selection committee's attention.

Be certain you're aware of the risk-tolerance levels of your organization and key stakeholders when you're the one responsible for developing the risk management policies.

Planning for Risks

Planning for project risks is an activity that you should undertake for all projects. The better prepared you are going into the Executing phase of the project, the more likely you'll be able to respond to risk events with a cool, level head. In Chapter 2," Developing Project Management Skills and Expertise," we talked about operating in fire-fighting mode. When you're in fire-fighting mode, the object is to put the fire out—fast. That usually means that you deal with things in the quickest, easiest way you can just to put the fire out. And putting the fire out doesn't necessarily solve the problem in the long run. Planning for risks by identifying them, analyzing their impact, and preparing response plans where appropriate will help you avoid risks altogether in some cases and minimize their impact in others.

Project risk is higher during the Initiation and Planning processes than later in the project. More factors are unknown at the beginning of the project, and the work of the project hasn't begun. As the work of the project is completed, project risk lessens. However, it's important to keep in mind that the potential impact of unidentified risk is much greater as the project progresses because time and money have been expended on the project. That's why it's important to identify risks and develop plans to deal with them early on in the project.

Risks are often ignored and the risk-identification and analysis process is often skipped because of a lack of understanding of the risk management process. Risks aren't something to fear. Risks should be identified and documented and their impacts examined to determine opportunities that may spring from the risk events or to develop risk response plans. Sometimes the process of risk identification itself will minimize risk impacts and allow you to come up with plans to avoid the risk altogether.

Risk response plans involve detailed actions of how the organization will deal with the risk should it occur. They include descriptions of the risk events and where or when in the project the risk events could occur. They should also include a description of the causes of risk and how the risks impact the project objectives or deliverables.

In our example project, we identified the possibility of a snowstorm on the day of the employee meeting as a risk that needs a risk response plan. The plan should include what's described in the previous paragraph, and it should also include the alternatives available to deal with the risk event. Perhaps you can avoid the risk altogether by holding the meeting at a hotel in town instead of the mountain resort; the company could consider hiring drivers with four-wheel-drive vehicles to transport people to the event; and so on. There are some specific responses you should consider when writing your risk response plan that we'll cover in the next section.

Responding to Risks

The amount of effort you'll put into the development of risk response plans depends on the nature of the risk. Some risks require extensive plans, some may need only to be noted and accounted for in an overall plan, and others need only to be listed on the risk list.

Risk response planning is a matter of deciding what steps to take should the risk event occur. It also includes assigning individuals (or departments) the responsibility of carrying out the risk response plan if the risk event occurs. Be sure to note the individuals or department that's responsible for enacting the response plan in the plan documentation.

As we discussed in the previous sections, the organization's risk management policies contain the guidelines you should follow for determining which risks need response plans. Generally speaking, those risks with a high probability of occurring that also have a medium-to-high impact should have a plan.

There are several recognized strategies you can use to reduce or control risks: accepting, avoiding, transferring, and mitigating. It's important to use the right strategy for each risk so that each risk impact is dealt with adequately and in the most efficient way possible. It's not a bad idea to designate a secondary strategy for the highest impact risks. We'll look at each of the strategies in more depth below.

Accepting

This first strategy is straightforward. Accepting the risk means that you won't make any plans to deal with the impacts of the risk event, and if it occurs, you'll let nature take its course. If we used this strategy when dealing with the snow risk event, for example, we would leave all the existing arrangements in place, we wouldn't investigate alternative locations for the event, and we would do nothing if snow occurred on the evening of the event.

Avoiding

Risk avoidance involves taking steps to avoid the impact of the risk event or eliminating the cause of the risk altogether. This is different than the acceptance strategy because plans are developed to avoid the risk or its impact whereas the acceptance strategy does nothing.

Back to the snow example. The avoidance strategy for this risk event would be moving the employee meeting to a location in town so that the effects of bad weather are eliminated. Since it doesn't snow in the month of November in the city, the impact of the snow event is eliminated. This assures that all the employees will be able to attend the meeting.

Transferring

Risk transference doesn't eliminate the risk or its impacts—it transfers the responsibility for the management of the risk event to a third party. The classic example of risk transference is insurance. Your own car insurance policy is a perfect example. The insurance company takes on the risk of paying for damages caused by an accident in exchange for money. Keep this in mind because risk transference almost always involves the exchange of money. You'll want to account for transference costs in the project estimates and the project budget.

Contracting is another form of risk transference. The vendor takes on the responsibility for the work as outlined in the contract and accepts the responsibility for the cost of failure. They're going to charge you for the work they perform and will build in a margin for the amount of risk they think they're taking on. Obviously this impacts the project budget, so you'll want to take contract costs into consideration when determining project estimates.

Keep in mind that contracting as a risk strategy doesn't always mean that you won't experience the impact of the risk. One way to transfer the impact of the snow risk event is to contract with a shuttle service to transport employees from the office to the meeting location should it snow. However, if all the drivers go on strike the morning of your event, the four-wheel-drive vehicles won't show up at the designated time to take everyone to the meeting. You've simply traded one risk for another. Closely weigh your options in cases like this to determine which risk your organization is more likely to accept. And, make certain the party you're transferring the risk to is able to assume the risk.

Mitigating

The last technique involves risk mitigation. This strategy attempts to reduce the impact of the risk event by reducing the probability of the risk occurrence or reducing the impact of the risk event to an acceptable level. If it's important to hold your employee meeting at the resort location and changing locations isn't an option, you could consider moving the meeting to a later date when there is no chance of snow in the resort area to mitigate the impact of the risk. You could also reduce the impact of the risk by requiring all employees to be at the meeting location two hours prior to the start of the meeting, which gives everyone time to deal with bad weather conditions should they occur and still get the meeting started on time.

Contingency Planning

Have you ever worked on a project where one of the project team members was so critical to the project that if they left the company the project would fail? More than likely, you or one of your managers took steps to protect the project and the organization should this occur. For example, you may have required this employee to document their knowledge and train one or two others so that the other employees understood and knew what the critical employee knew. This is an example of contingency planning.

contingency planning

A process of planning for known risks to help ensure project success if a risk event occurs.

Contingency planning is similar to risk avoidance and mitigation in that you outline alternatives to deal with the risk events should they occur. Contingency plans can be developed for individual risks or for groups of risks. In our annual employee meeting project, we defined some risks that have a medium probability and low impact. These risks may not need detailed plans of their own, but they can be incorporated into a contingency plan that briefly details each of these risks and the strategies to deal with their impacts.

Contingency planning should occur after you've identified the risks and performed risk analysis to determine the extent of their impacts. These plans should be filed in the project notebook and available at all times for reference when a risk event occurs.

Most project managers also account for contingencies in the project budget. Contingency allowances or reserves are built into the budget and the funds set aside for the specific purpose of dealing with risks as they occur. These funds are typically for the risk events you've identified with medium or low impacts and probabilities. Risk plans and strategies that were developed for individual risks should also be accounted for in the project budget.

Residual and Secondary Risks

There are two types of risks that may occur on the project that the contingency plan should take into consideration. They are residual risks and secondary risks.

Residual risks are the leftover impacts or minor risks that remain after the primary risk event has occurred and responses have been implemented. If you've used the mitigation risk strategy when defining your risk response plan, the impacts of the risk event are reduced but some minor leftover effects may still occur. The contingency reserves are set up for situations like this.

Secondary risk is risk that occurs as the result of implementing a risk response plan. The example given earlier of hiring four-wheel-drive vehicles to transport employees to the meeting but then the drivers declaring a strike the morning of the employee meeting is an example of a secondary risk.

Risk Management Plan

The primary goal of the risk management process is to identify risks, document their impacts, and develop plans to reduce their impacts or take advantage of the opportunities presented. All of this information is collected and documented in the risk management plan.

Listed below is a recap of the steps you'll take to assemble the risk management plan. The risk management plan encompasses all of the elements of risk identification, analysis, and response planning that we've talked about in this chapter. You can use this as a checklist or reminder of how to complete the risks management process for your next project.

1. Identify the risks.
2. Analyze risks to determine the probability of the event occurring.
3. Analyze risks to determine the impact on the project if a risk event occurs.
4. Calculate an overall risk score and determine which risk events need detailed response plans.
5. Create detailed response plans and assign resources to carry out the plan in the event a risk occurs.
6. Create a contingency plan.
7. Document everything in the risk management plan section of the project notebook or on the project's intranet site.

The risk management plan should make up one section of your project notebook. You may want to consider creating a spreadsheet or a chart, similar to the one shown next in Table 7.4. This directory lists the risk by number and name, indicates whether a plan exists for the risk, shows where the risk plan can be found (references a page number in the notebook or a website), and tells who the responsible party is for carrying out the risk response. Use the following chart as a template for your risk directory, and make this one of the first pages of the risk management section.

As the project manager, it's your responsibility to make certain that risk events are monitored throughout the life of the project and that the risk response plans are carried out when necessary. Always be on the lookout for risk events ready to occur. One way to do that is to pay attention to risk triggers. Risk triggers warn you that the risk event is getting ready to happen. If dark gray, snow-laden clouds start gathering over the mountains the morning of the meeting, it's likely that the snow is going to fly. This risk trigger signals you that the risk event is about to occur.

risk triggers

Symptoms that signal that a risk event is about to occur.

Risks exist on all projects. Don't skip the risk management process because not taking the time to identify and document the risks could end up killing the project, not to mention your reputation as a project manager.

Terms to Know

• brainstorming
• contingency planning
• Delphi technique
• Nominal Group technique
• probability
• risk
• risk tolerance
• risk triggers

Review Questions

Answers