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 weatherthe 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 RisksWhere 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 factorsif 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 delayedunless 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 mannerby 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.