001

Table of Contents
 
About the Author
Title Page
Copyright Page
Dedication
Foreword
Acknowledgments
Introduction
Who Should Read This Book?
The Spotlight Series
 
CHAPTER 1 - What Is Risk Management?
 
Defining Risk
Purpose of Risk Management
A Practical Risk Management Approach
Communication Is the Key
Case Study
 
CHAPTER 2 - Identifying and Documenting Risks
 
Identifying Risks
Common Risks
Where to Look
How to Look for Risk
Documenting Project Risk
Case Study
 
CHAPTER 3 - Why Projects Fail—More Risks and How You Can Prevent Them
 
The PMINO Syndrome
Absentee Sponsor
Disengaged Teams
Case Study
 
CHAPTER 4 - Preventing Scope and Schedule Risks
 
Scope Risk
Schedule Risks
Change Management
Case Study
 
CHAPTER 5 - Analyzing and Prioritizing Risks
 
Qualitative Risk Analysis
Quantitative Risk Analysis
The Analysis Method of Choice
Listing and Ranking Project Risk
Case Study
 
CHAPTER 6 - Defining Risk Response Plans
 
Risk Response Planning
Risk Response Techniques
Developing Risk Response Plans
Planning for the Unknown
Case Study
 
CHAPTER 7 - Implementing and Monitoring Risk Response Plans
 
Monitoring and Control
Implementing Response Plans
Risk Audits
Case Study
APPENDIX A - Nine Knowledge Areas Refresher
APPENDIX B - Risk Management Templates
Glossary
Index

About the Author
Kim Heldman is the Chief Information Officer for the Colorado Department of Natural Resources. She has more than 14 years of project management experience in the information technology field. She has managed small, medium, and large projects over the course of her career and shares her breadth of experience and knowledge in her books through examples, stories, and tips.
Kim Heldman is the author of several other project management books, including PMP Final Exam Review, Project Management JumpStart, and the top-selling PMP: Project Management Professional Study Guide, all from Sybex. You can learn more about Kim at her website: www.KimHeldman.com.

001

For BB, the biggest risk I ever took.
Kimmie

Foreword
The Project Manager’s Spotlight Series is written for those of you who are engaged in projects at the day-to-day level of business. You’re working on projects such as server consolidation, piloting new products in the marketplace, or opening a new branch or storefront. These day-to-day projects keep businesses moving forward, carving out market share, meeting strategic goals, and improving the firm’s bottom line. These projects, while vitally important to the companies you work for, are not necessarily multi-million dollar, multi-year projects that require meticulous disciplines and precise methodologies.
The Project Manager’s Spotlight Series shows you the how-to’s of project management on a practical level. These books help you apply solid principles of project management without the rigor. You’ll find tools, tips, and techniques to help you use Project Management Institute-based practices in your small- to medium-sized projects; these are tips you can read over the weekend and be ready and able to apply on Monday morning.
 
—Kim Heldman

Acknowledgments
There are so many people to thank for their help with this project, I’m not sure where to begin. I think I’ll start with Heather O’Connor, the acquisitions editor for this book and the first person I shared the Spotlight Series idea with. She took the idea and ran with it and was instrumental in getting this series off the ground. She also was very gracious and helpful with her comments on both the series idea and this manuscript. Thank you, Heather. This series wouldn’t have been possible without your belief in it and your hard work to bring it to reality.
Thank you, as always, to Neil Edde, Publisher. Way back when, he took a chance on me and got me started on this crazy notion that I could write a book. I never would have believed it without the encouragement and support from Neil and his staff. He also went to bat for this series and again, thanks Neil, for the opportunity to write this book, launch this series, and work with your incredible, dedicated staff.
Jeff Kellum took over as developmental editor when Heather went on leave. Jeff has been great to work with and has had many helpful suggestions along the way. He said he enjoyed reading this book which was a great encouragement to me. Thank you, Jeff, for your help and support.
Thank you to Chance Reichel, who worked as the technical editor for this book. He did a great job of pointing out information and tips that would make the text stronger. I really appreciate his help.
It’s amazing how many folks are involved in creating a book. Without each of them and their expertise, the final product wouldn’t be what you’re seeing here. Sometimes I think the writing is the easy part and these folks have the difficult part—making suggestions and corrections and asking me what I was thinking in rough parts of the manuscript. Thank you to each of you for your expertise and suggestions. Leslie Light, production editor, has been terrific at keeping us all on schedule. Kim Wimpsett, copyeditor, asked a lot of those “what are you thinking” questions, only she was very professional about it and every time those questions helped me improve the text. Thank you as well to the behind-the-scenes crew at Sybex: Maureen Forys and the compositors at Happenstance Type-O-Rama, the proofreaders, and always, the indexer, Ted Laux.
Last but never least, thank you to my husband, BB, for your love, encouragement, and support. Thanks for believing in me and for the many dinners you served me in front of the computer screen while I was writing away.

Introduction
Project Manager’s Spotlight on Risk Management was written for those of you who want to know more about project risk and how to take advantage of the opportunities risk presents or about how to reduce or eliminate the impact it has on your project.
This book explores risks and risk management from a practical, hands-on approach. It will equip you with questions to ask, tools and techniques to implement, checklists to use, and templates to apply to your projects immediately.
This book has a lot of examples of the types of risks that can plague your project. Reading this book will help you identify risks on projects that you may not have thought of before. It will walk you through how to identify those risks and what to do about them should they occur.
Reading this book will give you a solid foundation in risk management practices. From here, you can build on this knowledge by taking project management classes, reading other books in this series or on this topic, and networking with others in your organization. This book is based on the project management guidelines recommended by the Project Management Institute (PMI), and many of the terms, concepts, and processes you’ll read about in this book are based on the PMI publication A Guide to the Project Management Body of Knowledge (PMBOK Guide). This book assumes you have some hands-on project management experience and some familiarity with project management terms and processes as described in A Guide to the PMBOK. For those of you who need a refresher, Appendix A describes the nine Knowledge Areas found in A Guide to the PMBOK and the five project management processes.

Who Should Read This Book?

If you’re serious about increasing your chances for an on-time, on-budget project, you should read this book. Risk management is a process that should be required for all projects, no matter how big or how small. Sometimes simply having an understanding of what’s lurking around the corner is enough to reduce the threat of a schedule delay or a budget overrun. This book will walk you through the steps of identifying risks, prioritizing them, deciding which risks require a response plan to deal with them should they occur, monitoring the project for new risks, and evaluating the overall risk strategy so your next project benefits from what you learned about this project.
Those of you who are experienced at project management will find this book beneficial because you can combine what you know from practice with the additional tips and processes outlined here, making your risk management strategy more effective than ever. Those of you who don’t have a lot of hands on experience in project management will benefit from this book as well. I’ll step you through exactly what you should do to discover risks and how to deal with them.

The Spotlight Series

The Spotlight Series is designed to give you practical, real-life information on specific project management topics such as risk, project planning, and change management. Many times, the theory of these processes makes sense when you’re reading about them, but when it’s time to implement, you’re left scratching your head wondering exactly how to go about it. The books in this series are intended to help you put project processes and methodologies into place on your next project without any guesswork. The authors of this series have worked hard to anticipate the kinds of questions project managers might ask and to explain their topics in a step-by-step approach so you can put what you’re reading into practice.
If you find that the topic of project management interests you, I strongly recommend you consider becoming a certified Project Management Professional (PMP) through the PMI. This is the de facto standard in project management methodologies. You’ll find many organizations now require a PMP certification for project management jobs. For more information on this topic and to help prepare you for this exam, read my PMP Project Management Professional Study Guide from Sybex.

CHAPTER 1
What Is Risk Management?
Can you name the ultimate project management four-letter word? You guessed it: R-I-S-K. This word is uttered either in complete confidence or under the breath as something the project manager wished he or she knew something more about.
Risk management is an integral part of project management. I’ll start this chapter with a discussion of the basics of risk management, including the definition of risk, the purposes of risk management, the processes involved with risk management, and principles of risk management.
At the conclusion of this chapter, I’ll introduce a case study that you can follow throughout the book. The project manager in the case study will handle issues in her project that I’ve discussed during the chapter. Don’t be caught off guard if there are a few surprises along the way. After all, that’s how most projects work.
Are you ready to dive in?

Defining Risk

Most of us tend to think of risk in terms of negative consequences. It’s true that risks are potential events that pose threats to the project. But they’re also potential opportunities. That’s the side of the equation we often forget.
For instance, did you know you’re taking a risk by reading this book? You’re investing a few hours of your time reading about the topic of risk and risk management—and for that I thank you—but it’s time that you can’t regain once you expend it. You will (I hope) get to the end of this book and realize you learned a lot more about risk than what you knew before you started. In that case, you’ve taken on a risk and benefited from it. The risk (the threat of a loss of time that you can’t regain) will thus end in opportunity because you’ll have achieved something at the conclusion of the activity that you didn’t have in the beginning.
NOTE
Risks are like exercise: no pain, no gain. Accomplishment is rarely possible without taking risks.
Likewise, you take other risks in your daily routine of which you probably aren’t consciously aware. Perhaps you cross a busy intersection on the way from the bus stop to your office. You wait for the walk sign, look both ways before stepping out onto the curb, and proceed to the other side. But let’s say you’re late for a meeting with the big boss. You can stand on the corner and wait for the walk light, making you even later for the meeting, or you can cross against the light once the traffic has cleared. You weigh the consequences of both actions and decide to walk against traffic.
Chances are you probably didn’t consciously perform a complete analysis of all the risks and their consequences involved in these two scenarios before reaching a decision. You likely made a snap judgment in both cases. In the first example, you picked up this book and thought you’d learn something by reading it, so you purchased a copy. In the second, you weighed the probability of getting hit by a car against the likelihood of getting yelled at by the big boss for being late. Even though the consequences of getting hit by a car have significantly more impact, you decided that being yelled at was a more likely outcome and chose to avoid this risk by taking on the other.
Organizations and individuals make decisions regarding project risks every day. They might use a formally recognized, documented process or go with the “fly-by-the-seat-of-your-pants” approach. I hope after reading this book you won’t exercise snap judgment about project risks anymore but will instead develop a sound methodology for identifying, analyzing, prioritizing, and planning for risks.

Project Risk

All projects begin with goals. The point of the project is to meet and satisfy the goals the stakeholders agreed on when the project was undertaken. Risk is what prevents you from meeting those goals. (What? Your stakeholders didn’t agree on the goals? We’ll talk more about that in Chapter 4, “Preventing Scope and Schedule Risks.”)
NOTE
This may come as a surprise to all you eternal optimists out there, but all projects have risks. Unfortunately, covering your eyes and saying “you can’t see me” doesn’t make them go away.
As I stated earlier, most organizations, and most individuals, really, think about risks in terms of harm or danger. What’s at stake, how much could we lose, and how bad will it hurt? are the initial questions that surface when we think about risk. I don’t mean to be a downer—but I’ll spend the majority of this book discussing risks from the perspective of the threats they pose to the project (and their consequences), because after all, unidentified and unplanned for risks are project killers. Chances are you’ve experienced a failed project or two as a result of unidentified or unplanned risks. As you progress through the book, I’ll discuss techniques that lower or eliminate the consequences of risk and thus give your projects a head start to success.

Organizations and Project Risk

Executive managers are responsible for making decisions that benefit the corporation, the shareholders, the constituents, and the others they represent. Whether it is a for-profit company, a governmental organization, a not-for-profit organization, an education-focused business, and so on, the executives at the top have one goal in mind—maximize benefits to the organization and to their shareholders (all the while making themselves look good for future promotional purposes, but that’s another book). To do that, the company must minimize bad risks while maximizing the opportunities that good risks may present. This is where you come in.
For executives to make good decisions, they need information. Risk identification and analysis is a part of the vital information they’ll use when determining a go or no-go decision regarding the project. And you are the one responsible for reporting on the risks and their potential impacts to the executives to assist them in their decision-making process.
Risk management, unfortunately, is probably one of the most often skipped project management knowledge areas on small-to-medium-sized projects. Many project managers I know take the attitude that they’ll deal with the risks when and if they occur rather than take the time to identify and plan for them before beginning the work of the project.
On a small project, even just an hour or two of time spent on risk management can mean the difference between project success and project failure. The information you learn doing simple risk analysis could prove invaluable to your organization. I can’t guarantee you project success, but I can guarantee you a much higher potential for project failure if you don’t practice basic risk management techniques and inform your executives of the potential for bad juju before it hits.
Applying the risk management processes you’ll learn about in this book will help you manage successful projects that improve your organization’s performance, profits, efficiency, and market share; provide better market presence; and meet the organization’s goals.
The Spotlight Series is geared toward those of you who manage small-to-medium-sized projects. You and I are the ones out there keeping the everyday business functions forging ahead with the small-to-medium-sized projects such as consolidating servers, launching websites, conducting space planning, implementing new purchasing procedures, and so on.
You may be asking, “What does small mean?” Well, the answer is relative. A small project with minimal impact to one organization could be huge with devastating impacts to another. For example, your $50,000 project in an organization that generates $500 million a year in revenues is relatively harmless to the bottom line if the project should fail. Conversely, the failure of a $50,000 project to a small business owner could send her into bankruptcy. A small business owner likely couldn’t afford the impact of even one risk consequence whereas the large organization could easily invest twice the original amount of the project without batting an eye. Therefore, the risk to the organization is relative as well. (Don’t fool yourself, though; you’ll have to report to someone about why the original $50,000 wasn’t enough. The risk in this case rests with you. Did you plan the project appropriately? Did you estimate activities and budget accurately? And did you identify and plan safe, client-approved strategies for managing risks that could have caused the need for more project funds?)
Remember that your success with small projects will win you larger and larger project assignments. One way to assure you get those juicy assignments is not skipping the risk management processes.
Your company takes on risk with every project the executive team approves. They supply resources, time, money, and sometimes even stake their reputations on projects. Those same resources could be applied to other projects. But the decision makers weigh the possible outcomes of your project over another and decide to run with the project you’re assigned. When projects are approved, the benefit, or perceived opportunity, outweighs the perceived threat of not completing the project. When the opposite is true, the project never sees the light of day.
NOTE
Most organizations (and individuals) will take risks when the risk benefits outweigh the consequences of an undesirable outcome.
You may be scratching your head right now wondering why the co-worker downwind from you got his project approved while yours was nixed for no apparent reason. Many things can come into play in decisions such as this, including power plays (someone somewhere doesn’t like someone else who may benefit from the project), the executive in charge doesn’t like the project, favoritism, and other similar office politics. More apparent reasons might play a part as well, such as the project isn’t in keeping with the company’s mission, no money exists for the project, enough resources aren’t available to apply to the project, the risks outweigh the benefits, and so on. I’m certain you can come up with as many reasons as I can.
As you explore risks and consequences and their impact on the organization through the course of this book, keep in mind that executives sometimes seem to defy logical reason when making decisions. They choose projects that have risks with potentially devastating consequences to the organization while brushing off other projects that to us seem like a no-brainer. So when you’re wondering about why your project wasn’t approved—my advice is don’t. Move on to your next assignment and apply solid project management and risk management techniques to help assure its success.

Purpose of Risk Management

The good news is risk isn’t the enemy. The bad news is the consequences of ignoring risk can be. What you don’t know can hurt you when it comes to risk. The goal of risk management is identifying potential risks, analyzing risks to determine those that have the greatest probability of occurring, identifying the risks that have the greatest impact on the project if they should occur, and defining plans that help mitigate or lessen the risk’s impact or avoid the risks while making the most of opportunity.
Project management means applying skills, knowledge, and established project management tools and techniques to your projects to produce the best results possible while meeting stakeholder expectations.
Risk management means applying skills, knowledge, and risk management tools and techniques to your projects to reduce threats to an acceptable level while maximizing opportunities.
More specifically, risk management concerns these five areas:
• Identifying and documenting risks
• Analyzing and prioritizing risks
• Performing risk planning
• Monitoring risk plans and applying controls
• Performing risk audits and reviews
I’ll describe each of these processes in further detail in their own chapters, so in this section I’ll stick with a high-level definition for each. These processes are highly interactive, and to understand how they all work together, you’ll first look at the purpose for each.
Identifying and documenting risks This one is fairly straightforward. The first step of your risk management approach is identifying and writing down all the potential risks that exist on your project. It doesn’t stop there, however. Identifying risks occurs throughout the life of the project. Every life-cycle phase brings its own challenges and opportunities, which means more opportunity for project risk.
 
Analyzing and prioritizing risks These processes are a little more complicated. Now that you know what the risks are, you’ll apply tools and techniques to determine which ones have the greatest potential for harm (and for good) to the project. The analyzing and prioritizing process determines which risks require plans.
 
Performing risk planning Risk planning concerns developing strategies that document how you’ll deal with the risks if they occur. Not all risks require response plans. You may choose to live with the consequences of a risk event if it occurs.
 
Monitoring risk plans and applying controls This process involves evaluating the risk response plans you’ve put into action and implementing any corrections needed to make certain the plan is effective and the risks are handled appropriately and timely.
 
Performing risk audits and reviews This process is different from the previous one because it’s performed after the project is completed. Monitoring risks occurs throughout the life of the project. Performing a risk audit is a lot like documenting lessons learned. You’ll document information as the project progresses, but the risk audit analysis is performed at the end of the project.

Iterative Process

You can see from the discussion in the previous section how the risk management processes interact. Once the project manager (or project team) identifies a risk, she analyzes it to determine its potential impact on the project. Then she develops a plan that outlines how to deal with the impacts of the risk should they occur, and monitors, tracks, and perhaps changes the plan as a result of new information. This means she may identify new risks, requiring more plans, and so on.
Risk management, just like project management, is an iterative process, and effective communication is at its core. Without communication and constructive information exchange between key stakeholders, project team members, management, the project sponsor, and so on, risk management wouldn’t work well. The same is true for the project management processes.
The following illustration shows the iterative nature of risk management and the interaction between its processes.
002
Risk management is tightly integrated with the project management processes and, like project management itself, is not a one-time process. To illustrate this point, the next illustration shows the project life-cycle processes (in italics in the graphic) plotted with the risk management processes to demonstrate how closely linked they are. (Appendix A contains a refresher on the project management life-cycle processes if you need a review.)
003

Probability and Impact

I’ve already touched on two topics that need a little further explanation before you proceed—probability and impact. You’ll spend a great deal of time with these subjects in Chapter 5, “Analyzing and Prioritizing Risks,” but for now some explanations are in order.
Probability is simply the likelihood that a risk event will occur. Let’s say you’re busy planning the annual St. Patrick’s Day parade. The weather forecasters say today has a 20 percent chance of rain. Therefore, the probability it will rain on your parade is 20 percent.
Risk impact is the result of the probability of the risk event occurring plus the consequences of the risk event. Impact, in laymen’s terms, tells you how bad or how good the realized risk is going to hurt.
Back to the rain example. Perhaps your organization has invested $75,000 in a float scheduled to appear in the parade’s third position. This is a prime spot because folks watching the parade are still energized and watching the events closely. This means the advertising panel on the side of the float with your organization’s name in huge letters is going to get a lot of visibility. This translates, you hope, into more business. However, if it rains, the impact to the organization is the $75,000 (at a minimum) invested in the float. The potential loss of business is also an impact of this risk event and could be added to the $75,000 to determine a total financial impact. So how bad will it hurt if it rains? The cost is $75,000 plus the loss of business and other time or resources expended preparing the float, assuming a total washout.

Propensity for Risk

The propensity for project risk depends on the project’s life-cycle phase. Risks are most likely to occur during the Initiating phase and least likely to occur during the Closing phase. Don’t let this fool you though: risks can occur at any time during the course of the project. Intuitively, it makes a lot of sense that risks have a greater chance of occurring earlier in the project. The beginning of the project has lots of uncertainty. Cost-benefit analyses are being performed, resources are being identified but may not be available, market forces may cause a shift in focus, and so on. Many events can happen early on that increase project risk (including the risk of the project getting killed for a host of reasons), so the probability for risk is greatest in the early phases. As you approach the closing phase, the majority of the project work is completed, so the probability of risk events occurring decreases. Chances are a few risks will occur along the way, but I know you have great plans in place to handle them.
You can see the relationship of risks and their probability across the project life-cycle processes in the following graphic.
004
The opposite can be said for risk impact. At the beginning of the project, the impact of a risk event is less than it is later in the project life cycle—with the exception of the risk of your project being killed altogether.
Let’s say the project is proceeding as planned for this example. Not a lot of energy or resource is usually expended in the Initiating phase of a project, so if a risk event occurs, the consequences it produces aren’t likely devastating. For example, perhaps you’re working on a software upgrade project. During the planning phase you discover that the software you’re considering purchasing requires an upgrade of the operating system that lives on the servers and an upgrade of software on every desktop in your organization. Fortunately for you, you made this discovery during the planning phase. At this point, you can plan for an increase in the budget based on this new information, or the CIO can decide to kill the project and forgo installing the new software altogether with little organizational resource spent or lost.
The consequences or impact of this risk at this phase are minimal because the only resources usually expended at this point are human resources spent on planning, gathering information, and talking with stakeholders.
Now using the same example, imagine you’ve purchased the software and are in the later phases of the project. You’ve completed all the preliminary work and are ready to load the new software. Gulp. It isn’t until now, somewhere in the Executing and Controlling phase, that you discover you also need to upgrade the server and desktops. The consequences of this occurring at this stage of the project are much higher. You’ve already put out the money for the software purchase, you’ve also spent company resources performing all the tasks of the project, and now you can’t proceed without the operating system upgrade. The risk is much higher at this point in the project. The software you’ve purchased is useless without the other upgrades, and requesting additional funds at this point in the project may not fly (or be possible, depending on budget constraints). But, hey, the big boss can always use the paycheck of the project manager who allowed this risk event to occur to purchase the desktop and server upgrades once the project manager is gone.
The point is, the further you progress in the project life cycle, the less likely it is the risk event will occur, but the greater the impact to the project if the risk event does occur. The following graphic shows the inverse relationship of probability and impact as the project progresses through the life-cycle processes.
005

A Practical Risk Management Approach

In practical terms, a solid risk management methodology allows you to manage your project proactively. By that I mean you’re in control and prepared for most anything that can happen on the project. On the other hand, reacting to events as they occur without any forethought regarding their probability of occurring (or what kind of trouble they could cause) is nothing more than crisis management.
A risk management approach starts first with the determination that you’ll create and implement a risk management plan and not let problems run amok and get the upper hand. Identifying, analyzing, prioritizing, and then planning for the management of risks and monitoring the plans is a much better approach than allowing problems to change the outcome of your project because they weren’t planned for ahead of time.
Earlier I talked about the five purposes for risk management. These are actually action items, or steps, you’ll perform throughout the course of the project to actively engage in risk management. The Project Management Institute’s (PMI) A Guide to the Project Management Body of Knowledge—herein referred to as A Guide to the PMBOK—categorizes its Risk Management Knowledge Area into six processes. They are: Risk Management Planning, Risk Identification, Qualitative Risk Analysis, Quantitative Risk Analysis, Risk Response Planning, and Risk Monitoring and Control. Let’s do a quick review of each of these processes next. As you’ve probably guessed, I’ll be covering each of these areas more thoroughly as you progress through the book.
Risk Management Planning The purpose of the Risk Management Planning process is to create a risk management plan. Don’t confuse this plan with the “what” of risk planning. The risk management plan is the “how” you’ll go about dealing with risks on your project. It describes how you define, monitor, and control risks throughout the project. It also describes how each of the remaining processes in this knowledge area are implemented, monitored, and controlled throughout the life of the project. I’ll discuss the risk management plan in more detail in the Risk Management Plan section later in this chapter.
 
Risk Identification The Risk Identification process involves identifying and documenting all the risks that could impact the project. This includes reviewing project documents, categorizing risks, reviewing checklists, using techniques such as brainstorming to identify risks, and ultimately producing a list of project risks. I’ll discuss Risk Identification in detail in Chapter 2, “Identifying and Documenting Risks.”
 
Qualitative Risk Analysis The purpose of the Qualitative Risk Analysis process is to determine the consequences the risks you identified in the Risk Identification process may have on the project objectives. It involves determining the probability that the risks will occur and ranking risks according to their effect on the project objectives. I’ll discuss Qualitative Risk Analysis techniques in Chapter 5.
 
Quantitative Risk Analysis The Quantitative Risk Analysis process evaluates the impacts of risk and quantifies the overall risk exposure of the project by assigning numeric probabilities to each risk and their impacts on the project objectives. The primary output of this process is a prioritized list of quantified project risks. I’ll cover Quantitative Risk Analysis techniques in Chapter 5.
 
Risk Response Planning Risk Response Planning involves deciding what actions to take to reduce threats while maximizing opportunities discovered during the performance of the risk processes. This process includes assigning staff members as risk owners. The risk owners are responsible for carrying out the risk response plans outlined during this process when the risk event occurs (or is about to occur). To read more about Risk Response Planning, see Chapter 6, “Defining Risk Response Plans.”
 
Risk Monitoring and Control The purpose of the Risk Monitoring and Control process is to respond to risks as they occur, track and monitor identified risks, evaluate risk response plans for effectiveness, identify new risks, and ensure proper risk management procedures are being followed as defined in the risk management plan. I’ll discuss Risk Monitoring and Control further in Chapter 7, “Implementing and Monitoring Risk Response Plans.”
Table 1.1 ties A Guide to the PMBOK’s Risk Management Knowledge Area processes to the previous risk management action steps and the frequency or timing of each. Remember that while the risk management processes are broken out individually, many times you’ll combine one or more of these processes into one step.
TABLE 1.1: Risk Management Processes and Purposes
PROCESS ACTION STEP TIMING
Risk Management PlanningCreate risk management plan detailing how risks are managed for this project.Once during Planning phase.
Risk IdentificationIdentify and document risks.Ongoing throughout all phases of the project.
Qualitative Risk AnalysisAnalyze and prioritize risks.When new risks are identified.
Quantitative Risk AnalysisAnalyze and prioritize risks.When new risks are identified.
Risk Response PlanningCreate response plans and strategies for those risks with highest probability and impact.When new risks are identified.
Risk Monitoring and ControlMonitor the effectiveness of the response plans.Monitor response plans at project status meetings. Identify new risks and reevaluate throughout all project phases.
Risk Monitoring and ControlPerform risk audit and reviews to determine effectiveness of overall risk management plan.Once during the Closing phase.
Now that I’ve covered the bases and we’re all using the same risk process terminology, let’s look closer at risks.

Risks versus Problems

Risks aren’t problems. The problem is that the word problems