Risk Management Professional PMI RMP® Certification Guide Carl Pritchard ChidoLib 4zbqb2

About This eBook
ePUB is an open, industry-standard format for eBooks. However, support of ePUB and its many
features varies across reading devices and applications. Use your device or app settings to
customize the presentation to your liking. Settings that you can customize often include font, font
size, single or double column, landscape or portrait mode, and figures that you can click or tap to
enlarge. For additional information about the settings and features on your reading device or app,
visit the device manufacturer’s Web site.
Many titles include programming code or configuration examples. To optimize the presentation
of these elements, view the eBook in single-column, landscape mode and adjust the font size to
the smallest setting. In addition to presenting code and configurations in the reflowable text
format, we have included images of the code that mimic the presentation found in the print book;
therefore, where the reflowable format may compromise the presentation of the code listing, you
will see a “Click here to view code image” link. Click the link to view the print-fidelity code
image. To return to the previous page viewed, click the Back button on your device or app.
Risk Management Professional (PMI-RMP)® Cert
Guide
Carl Pritchard
Risk Management Professional (PMI-RMP)® Cert Guide
Copyright © 2023 by Pearson Education, Inc.
All rights reserved. No part of this book shall be reproduced, stored in a retrieval system, or
transmitted by any means, electronic, mechanical, photocopying, recording, or otherwise,
without written permission from the publisher. No patent liability is assumed with respect to the
use of the information contained herein. Although every precaution has been taken in the
preparation of this book, the publisher and author assume no responsibility for errors or
omissions. Nor is any liability assumed for damages resulting from the use of the information
contained herein.
ISBN-13: 978-0-13-810847-2
ISBN-10: 0-13-810847-1
Library of Congress Control Number: 2023930987
ScoutAutomatedPrintCode
Trademarks
All terms mentioned in this book that are known to be trademarks or service marks have been
appropriately capitalized. Pearson IT Certification cannot attest to the accuracy of this
information. Use of a term in this book should not be regarded as affecting the validity of any
trademark or service mark.
Cover credit: Andrii Yalanskyi/Shutterstock
Warning and Disclaimer
Every effort has been made to make this book as complete and as accurate as possible, but no
warranty or fitness is implied. The information provided is on an “as is” basis. The author and
the publisher shall have neither liability nor responsibility to any person or entity with respect to
any loss or damages arising from the information contained in this book.
Special Sales
For information about buying this title in bulk quantities, or for special sales opportunities
(which may include electronic versions; custom cover designs; and content particular to your
business, training goals, marketing focus, or branding interests), please contact our corporate
sales department at corpsales@pearsoned.com or (800) 382-3419.
For government sales inquiries, please contact governmentsales@pearsoned.com.
For questions about sales outside the U.S., please contact intlcs@pearson.com.
Vice President, IT Professional
Mark Taub
Product Line Manager
Brett Bartow
Executive Editor
Laura Norman
Development Editor
Christopher A. Cleveland
Managing Editor
Sandra Schroeder
Senior Project Editor

Tonya Simpson
Copy Editor
Barbara Hacha
Indexer
Timothy Wright
Proofreader
Jen Hinchliffe
Technical Editor
Susan Parente
Publishing Coordinator
Cindy Teeters
Cover Designer
Chuti Prasertsith
Project Manager
Jayaprakash P (JP)
Compositor
codeMantra
Pearson’s Commitment to Diversity, Equity, and Inclusion
Pearson is dedicated to creating bias-free content that reflects the diversity of all learners. We
embrace the many dimensions of diversity, including but not limited to race, ethnicity, gender,
socioeconomic status, ability, age, sexual orientation, and religious or political beliefs.
Education is a powerful force for equity and change in our world. It has the potential to deliver
opportunities that improve lives and enable economic mobility. As we work with authors to
create content for every product and service, we acknowledge our responsibility to demonstrate
inclusivity and incorporate diverse scholarship so that everyone can achieve their potential
through learning. As the world’s leading learning company, we have a duty to help drive change
and live up to our purpose to help more people create a better life for themselves and to create a
better world.
Our ambition is to purposefully contribute to a world where
Everyone has an equitable and lifelong opportunity to succeed through learning

Our educational products and services are inclusive and represent the rich diversity of learners
Our educational content accurately reflects the histories and experiences of the learners we
serve
Our educational content prompts deeper discussions with learners and motivates them to
expand their own learning (and worldview)
While we work hard to present unbiased content, we want to hear from you about any concerns
or needs with this Pearson product so that we can investigate and address them.
Please contact us with concerns about any potential bias at https://www.pearson.com/report-

bias.html.
Contents at a Glance
Introduction
PART I Strategic Risk and Risk Planning
CHAPTER 1 The Risk Structure
CHAPTER 2 Risk Environment and Culture
CHAPTER 3 Tolerance, Thresholds, and Triggers
CHAPTER 4 Strategic Risk
CHAPTER 5 The Risk Management Plan (RMP)
CHAPTER 6 Connecting Others in Risk
PART II Risk Identification
CHAPTER 7 Practical, Team-Based Risk Identification
CHAPTER 8 Constraints and Assumptions
CHAPTER 9 Applying Triggers and Thresholds
CHAPTER 10 The Risk Register
PART III Risk Analytics
CHAPTER 11 Risk Qualification
CHAPTER 12 Risk Quantification
CHAPTER 13 Risk Complexity, Assessment, and Analysis
PART IV Risk Management and Resolution
CHAPTER 14 Response Planning
CHAPTER 15 Response Implementation
PART V Tracking and Closing Out Risks
CHAPTER 16 Data Collection
CHAPTER 17 The Leftovers and the Latecomers
CHAPTER 18 Sharing Risk Information
PART VI Final Preparation
CHAPTER 19 Final Preparation
APPENDIX A Answers to the “Do I Know This Already?” Quizzes and Review Questions
APPENDIX B Risk Management Professional (PMI-RMP)® Cert Guide Exam Updates
Glossary of Key Terms
Index
ONLINE ELEMENTS
APPENDIX C Study Planner
Table of Contents
Introduction
Part I: Strategic Risk and Risk Planning
Chapter 1 The Risk Structure
“Do I Know This Already?” Quiz
Foundation Topics
Risk Documentation Capture
Industry Benchmarks
Project Plans
Lessons Learned
Customer Agreements
Project Assumptions
The Project Charter
Risk Roles and Responsibilities
Risk Manager
Risk Owner
Risk Team
Project Roles
Risk Responsibilities
The Risk Archive
Risk Repository
Risk Register
Exam Preparation Tasks
Review All the Key Topics
Key Terms You Should Know
Review Questions
Chapter 2 Risk Environment and Culture
Foundation Topics
Risk Attitude, Appetite, and Maturity
Tolerance
Threshold
Appetite
Attitude
Risk Maturity
Risk Assumptions
Constraint-Driven Risks
Stakeholders and Risk Culture
Salience Model
Stakeholder Tolerances
Risk Owners
Stakeholder Risk Planning
Program Stakeholders
Portfolio Stakeholders
Data Processing
Organizational Infrastructure
Communication
Facilities, Equipment, and Hardware
Capacity
Review Questions
Chapter 3 Tolerance, Thresholds, and Triggers
Foundation Topics
Risk Absorption
Organizational and Project Risk Tolerance
Organizational Risk Tolerance
Project Risk Tolerance
Thresholds
Triggers
Recognizing and Resolving Cultural Discord
Review Questions
Chapter 4 Strategic Risk
Foundation Topics
Risk Process Alignment
Risk Management Planning
Risk Identification
Risk Analysis
Qualitative Analysis
Quantitative Analysis
Risk Response Development
Risk Response Implementation and Control
Risk Process Tools
Risk Sources and Their Roles
Risk Alliances
Review Questions
Chapter 5 The Risk Management Plan (RMP)
Foundation Topics
The Three R’s: RAM, RACI, and RBS
Responsibility Assignment Matrix (RAM)
RACI (Responsible Accountable Consult Inform) Chart
The Risk Breakdown Structure
Risk Responsibility and Accountability
Risk Responsibility in the Risk Management Plan
Risk Accountability in the Risk Management Plan
Risk Communication Documentation
The Author
The Timing
The Recipients
Communications Modes
Risk Education and Training
Review Questions
Chapter 6 Connecting Others in Risk
Foundation Topics
Stakeholders and Their Roles
Strategic Risk and the Stakeholders
Team Engagement in Appetites, Attitudes, and Priorities
Forming
Storming
Norming
Performing
Adjourning
Team-Driven Data-Gathering Techniques
Brainstorming
Nominal Group Technique
Focus Groups
Interviews
The Delphi Technique
Meetings
Rules of Engagement
Tolerance Rules
Trigger Rules
Escalation Rules
Reporting Rules
Information–Sharing Rules
Risk Education Beyond the Strategic
Review Questions
Part II: Risk Identification
Chapter 7 Practical, Team-Based Risk Identification
Foundation Topics
Identification Approaches
Mind Mapping
Affinity Diagram
Root Cause Analysis
Checklist Analysis
Assumptions Analysis
SWOT Analysis
Expert Judgment
The Risk Questions
Preliminary Data Analysis
The Risk Register
Review Questions
Chapter 8 Constraints and Assumptions
Foundation Topics
Constraints as Risk Drivers
Known-Knowns
Unknown-Knowns
Unknown-Unknowns
Known-Unknowns
Pure Versus Business or Speculative Risk
Changes in Constraints
Assumptions as Identified Risks
The Open Assumptions and Constraints Discussion
Assumptions, Constraints, Tolerances, and Thresholds
Review Questions
Chapter 9 Applying Triggers and Thresholds
Foundation Topics
Compliance and the Implications of Tolerance
Tolerance- and Threshold-Driven Triggers
Visible Triggers
Physical Triggers
Stakeholder-Driven Triggers
Review Questions
Chapter 10 The Risk Register
Foundation Topics
Register Functionality
Register Categories
Risk ID
Risk Event
Probability
Impact
Urgency
Propinquity
Proximity
Dormancy
Manageability and Controllability
Connectivity
Detectability (FMEA)
Strategic Impact
Overall Risk
Priority
Risk Owner
Area(s) Impacted
Escalation
Response Strategy Type
Response Strategy Narrative Description
Implementation Schedule
Implementation Review
Retirement Criteria
Follow-up
Outcome
Archival Location
Risk Classification
Review Questions
Part III: Risk Analytics
Chapter 11 Risk Qualification
Foundation Topics
Risk Sorting
Taxonomic Review
Risk Management Plan Application
Risk Ranking
Group Risk Ranking
Individual Risk Ranking
Fist to Five
Dot Voting
Roman Voting
Consensus
Stakeholder-Based Ranking Support
Review Questions
Chapter 12 Risk Quantification
Foundation Topics
Performance Data and Its Implications
Waterfall Performance Data
Budget at Completion
Planned Value
Earned Value
Actual Costs
Schedule Variance and Schedule Performance Index
Cost Variance and Cost Performance Index
Estimate at Completion
To-Complete Performance Index
Agile Performance Data
Sprint Completion
User Stories Completion
Story Point Completion
General Versus Detailed Quantitative Analysis
General Analysis
Detailed Analysis
Sensitivity Analysis Tools
Monte Carlo Sensitivity Analysis
Tornado Diagram
Network Diagram Sensitivity Analysis (Critical Path)
Ishikawa Diagram Analysis (Root Cause)
Decision Tree Analysis
Relative Risk Weight and Priority
Review Questions
Chapter 13 Risk Complexity, Assessment, and Analysis
Foundation Topics
Risk Complexity
Root Cause Analysis (Ishikawa)
SWOT Analysis
Tree Diagrams
Fault Trees
Decision Trees
Risk Interconnectedness
Risk at the Organizational Level
Threat Versus Opportunity
Review Questions
Part IV: Risk Management and Resolution
Chapter 14 Response Planning
Foundation Topics
Opportunity Versus Threat Strategies
Opportunity Strategies
Passive Acceptance
Active Acceptance
Exploitation
Enhancement
Sharing
Escalation
Threat Strategies
Avoidance
Mitigation
Transfer
Escalation
Action Plans and Risk Owners
Action Plans
Agile Action Plans
Predictive Action Plans
Risk Owners
Resolution Metrics and Communication
Resolution Metrics and Evaluation
Workarounds
Response Communication
Organizational Impacts
Tolerances
Policy
Compliance
Objectives
Review Questions
Chapter 15 Response Implementation
Foundation Topics
Response Plans Versus Contingencies
Stakeholder Response Reactions
Nature of the Response
Personal/Professional Implementation Involvement
Personal/Professional Tolerances
Residual Risk and Its Implications
Secondary Risk and Its Implications
Review Questions
Part V: Tracking and Closing Out Risks
Chapter 16 Data Collection
Foundation Topics
Gathering Information
Data Sources
Degrees of Accuracy
Ranking Approach Efficacy
High-Probability Risk Realization
High-Impact Risk Realization
Resilience
Anti-fragility
Overall Risk and Project Influence
Contrasting Project and Organizational Risk
Project Risks in an Organizational Context
Organizational Risk Taking in a Project Context
Organizational Aspects as Risk Sources/Drivers
Rewards in Risk–Reward
Rewards to Offset Risks
Review Questions
Chapter 17 The Leftovers and the Latecomers
Foundation Topics
Residuals and Deductibles
Deployed and Undeployed Responses
Intended and Unintended Outcomes
Residual Project and Organizational Risk
Residual Financial Risk
Residual Quality Risk
Residual Reputational Risk
Response-Generated Risks
Risk Environment and Response-Generated Risk
Specific Responses That Generate Risk
Firm-Fixed Price Contracts
Fixed-Price Economic Adjustment (FPEA) Contracts
Fixed-Price Incentive Fee (FPI or FPIF) Contracts
Cost-Plus Incentive Fee (CPIF) Contracts
Cost-Plus Award Fee (CPAF) Contracts
Cost-Plus Fixed Fee (CPFF) Contracts
Time and Materials (T&M) Contracts
Cost-Plus Percentage of Cost (CPPC) Contracts
Contract Type Summary
Late Risk Reporting
Risk Register Updates
Workaround Reporting
Review Questions
Chapter 18 Sharing Risk Information
Foundation Topics
Risk Reporting
Qualitative Data Gathering and Reporting: Predictive
Qualitative Data Gathering and Reporting: Adaptive
Quantitative Data Gathering and Reporting: Predictive
Quantitative Data Gathering and Reporting: Adaptive
Related Document Updates
Management Plan Updates
Lessons Learned Updates
Change Log Updates
Project-wide Risk Updates
How Has the Project Gone?
What Risks Remain?
What’s the Likelihood of Success?
Organization-wide Risk Updates
Organizational Impact Risks
Personnel/Stakeholders Risk Updates
Deliverables Organizational Risks (Quality)
System Life Cycle Risk Updates
Unanticipated Overuse
Environmental/Technical/Organizational Change
Updated Risks to the Project Management Culture
Cultural “Get Away with It” Risk Updates
Misapplication Risk Updates
Tolerance Updates
Review Questions
Part VI: Final Preparation
Chapter 19 Final Preparation
Suggested Plan for Final Review and Study
Summary
Appendix A Answers to the “Do I Know This Already?” Quizzes and Review Questions
Appendix B PMI-RMP (Risk Management Professional) Cert Guide Exam Updates
Index
ONLINE ELEMENTS
Appendix C Study Planner
About the Author
Carl Pritchard, PMI-RMP®, PMP® is a thought leader in the risk management community,
where he has been involved for 30 years. He has written eight books and led training around the
globe for the Project Management Institute, as well as for private clients.
In 2019, PMI® global awarded him the Eric Jenett Project Management Excellence Award,
citing him as the “Best of the Best” in project management. Considered the “fun guy” of project
risk management, Carl is a sought-after speaker and has presented keynote addresses for major
conferences and corporate all-hands meetings.
Carl is honored by his long-term relationships with PMI® chapters in upstate New York,
Baltimore, Pittsburgh, and the greater Washington, DC area. He resides in the mountains of
western Maryland with his wife, Nancy. Additional information about Carl’s current activities
can be found at carlpritchard.com, and you can follow Carl on Twitter @rmpprep.
Dedication
I would like to dedicate this book to my lovely wife, Nancy, and my two amazing sons, Adam and
James, who are always there and always a source of encouragement, supporting me through the
development of this book.
—Carl
Acknowledgments
It takes a lot of amazing people to publish a book. Special thanks go to Chris Cleveland, Laura
Norman, and all the others at Pearson (and beyond) who helped make this book a reality. We
appreciate everything you do! I thank my technical editor and fellow risk expert, Susan Parente,
for her professionalism and encouragement throughout the process. Most of all, I thank my
lovely wife, Nancy, without whom I couldn’t have made it through.
About the Technical Reviewer
Professor Susan Parente is a principal consultant at S3 Technologies, LLC, the project

management certificate program coordinator, and an instructor at the University of Virginia. She
is also a project engineer, speaker, author, and mentor who leads large complex IT software
implementation projects and the establishment of Enterprise PMOs. She has 25+ years of
experience leading software and business development projects in the private and public sectors,
supporting small to large organizations in many sectors. She trains and mentors project managers
in the areas of traditional and Agile project management and risk management. Mrs. Parente has
co-authored books in her areas of expertise, risk management and agile project management:
Global Hot Spots: How Project and Enterprise Risk Management Practices Drive Business
Results Around the World and recently, Hybrid Project Management: Using Agile with
Traditional PM Methodologies to Succeed on Modern Projects.”
We Want to Hear from You!
As the reader of this book, you are our most important critic and commentator. We value your
opinion and want to know what we’re doing right, what we could do better, what areas you’d
like to see us publish in, and any other words of wisdom you’re willing to pass our way.
We welcome your comments. You can email or write to let us know what you did or didn’t like
about this book—as well as what we can do to make our books better.
Please note that we cannot help you with technical problems related to the topic of this book.
When you write, please be sure to include this book’s title and author as well as your name and
email address. We will carefully review your comments and share them with the author and
editors who worked on the book.
Email: community@informit.com
Reader Services
Register your copy of Risk Management Professional (PMI-RMP)® Cert Guide at

www.pearsonitcertification.com for convenient access to downloads, updates, and corrections as
they become available. To start the registration process, go to
www.pearsonitcertification.com/register and log in or create an account*. Enter the product
ISBN 9780138108472 and click Submit. When the process is complete, you will find any
available bonus content under Registered Products.
*Be sure to check the box that you would like to hear from us to receive exclusive discounts on
future editions of this product.
Introduction
Welcome to the Risk Management Professional (PMI-RMP)® Cert Guide. The PMI-RMP® is the
premier certification for project managers with a risk orientation or risk managers working
extensively on projects. It is industry neutral, but Agile areas of the exam do lend themselves to
those in the information technology community. The exam serves as a means to show a clear
grasp of risk management practice in a project management context. As organizations seek to
mature in project management, risk management becomes a logical next step in ensuring that
projects are completed without putting individuals and organizations in danger. Risk
management’s positive orientation opportunity is also a focus for true professionals seeking to
optimize individual and organizational performance and outcomes. I wrote this book to be
something you can study from for the exam and keep on your bookshelf for later use as a risk
resource.
There are a host of risk practices out there. Some focus on insurance risk. Others take aim at
financial risk. Still others hone in on risks to the environment. Project risk and project
management risk is an arena unto itself. Although it ties to these other kinds of risks, the focus is
on achieving project outcomes successfully.
To prepare for the exam, it’s important to recognize that there will often be multiple true answers
on the examination, but PMI® will be expecting you to select the best answer, rather than just the
true answer. I’ve tried to highlight the best answers throughout this book. Some of the questions
on your real exam will be only a sentence or two. Others will be lengthy narratives that are
challenging to follow. Your best strategy to deal with the more bloated questions is to read the
last sentence or two, and then select the best answer. Upon doing so, return to the top of the
question and read the narrative. In many instances, you’ll find the narrative was there for
distraction, rather than information.
In the answers, you’ll occasionally encounter terms you have never seen before. Although they
may be legitimate, remember that PMI®’s questions authors sometimes make up answers to fill
in the space for distraction. They are sometimes not terms of art in risk management. They’re
simply fiction.
And when you’re taking the exam, if you hit a question that is completely, utterly, unintelligible
or unfamiliar, consider a probabilistic approach to the question. It is statistically more likely that
the longest answer is the right answer in such situations. This should not be your default setting
for the exam, but when you are truly desperate, it’s a way to leverage probabilities in your favor.
This book alone will not make you a great risk manager. It will teach you the processes and
lexicon of risk essential to pass the PMI-RMP® exam, when coupled with your professional
experience and other available data sources. Good luck as you prepare to take the PMI-RMP®
exam. As you read through this book, you will be taking advantage of the experiences of others,
enhancing the opportunities associated with passing the exam.
Goals and Methods
The number one goal of this book is to help you pass the PMI-RMP® Certification Exam. To that
effect, I have filled this book and practice exams with more than 600 questions/answers and
explanations in total, including four practice exams. All exams are located in Pearson Test Prep
practice test software in a custom test environment. These tests are geared to check your
knowledge and ready you for the real exam.
To aid you in mastering and understanding the PMI-RMP® objectives, this book uses the
following methods:
Opening topics list: This defines the topics to be covered in the chapter.
Foundation topics: The heart of the chapter. This includes in-depth descriptions, tables, and
figures that are geared to build your knowledge so that you can pass the exam. Each chapter
covers at least one full task from one of the five domains from the PMI-RMP® exam outline.
Key topics: The Key Topic icons indicate important paragraphs, figures, tables, and lists of
information that you should know for the exam. They are interspersed throughout the chapter
and are listed in table format at the end of the chapter.
Key terms: Key terms without definitions are listed at the end of each chapter. See whether
you can define them, and then check your work against the complete key term definitions in
the glossary.
Review questions: These quizzes, and answers with explanations, are meant to gauge your
knowledge of the subjects. If an answer to a question doesn’t come readily to you, be sure to
review that portion of the chapter. The review questions are also available online.
Practice exams: The practice exams are included in the Pearson Test Prep practice test
software. These test your knowledge and skills in a realistic testing environment. Take these
after you have read through the entire book. Master one, and then move on to the next. Take
any available bonus exams last.
Who Should Read This Book?
This book is for anyone who wants to advance a career in project management, and more
specifically, project risk management. Readers of this book can range from persons who have
been project managers for years who are now ready to take the next step in building up the risk
aspect of their career, to those who are just entering project management but want to be a
specialist in risk before becoming a generalist as a project manager.
This book is also designed for people who see risk management as the future. As more and more
organizations identify their risk practices as inadequate, individuals who can prove themselves to
be true specialists in the field of risk command a premium. Because the book is focused on
Project Management Institute practices, it ties in with the other PMI® certifications, particularly
the Project Management Professional® certification.
The prerequisites for the exam may sound daunting. They’re not as challenging as they appear on
the surface. Candidates with a secondary diploma (high school diploma or associate degree) need
to be able to illustrate 36 months of risk management–oriented experience over the past five
years. Those with a four-year degree or more need to be able to defend 24 months’ experience.
Note that most project management experience is risk management experience. In fact, many
types of professional experience outside project management would qualify. The key is that the
experience incorporates risk awareness, process, and rigor. It’s possible to be a project manager
without being a risk manager, and conversely, it’s possible to be a risk manager without being a
project manager. PMI® would prefer the latter over the former.
This book affords you insight into the terminology and processes of risk management. The best
candidates for the exam are those who have experience in applying the terminology and
processes with rigor. The focus of this book is to highlight those aspects of risk management that
are predominant on the exam, and how those aspects should be integrated into project
management in the day-to-day.
PMI-RMP® Exam Topics
If you haven’t downloaded the PMI Risk Management Professional (PMI-RMP)® Examination
Content Outline and Specifications, do it now from the PMI website:
https://www.pmi.org/certifications/risk-management-rmp. Review it and make sure you are
familiar with every item that is listed. Use the information found in this document to aid in your
studies while you use this book.
The following two tables are excerpts from the Examination Content Outline and Specifications
document. Table I-1 lists the PMI-RMP® domains and each domain’s percentage of the exam.
Table I-1 PMI-RMP® Exam Domains
Domain % of Exam
Risk Strategy and Planning 22%
Risk Identification 23%
Risk Analysis 23%
Risk Response 13%

Monitor and Close Risks 19%
The PMI-RMP® domains are then further broken down into individual tasks with some enablers,
which are illustrative examples of the work associated with the task.
Table I-2 lists the PMI-RMP® domains and tasks and their related chapters in this book. It does
not list the enablers for each task. Please refer to the PMI Risk Management Professional (PMI-
RMP)® Examination Content Outline and Specifications for full details.
Table I-2 PMI-RMP® Exam Domains, Tasks, and Chapter Mapping
Domain I: Risk Strategy and Planning
Task Chapter(s)
1 Perform a preliminary document analysis 1
2 Assess project environment for threats and opportunities 2
3 Confirm risk threshold based on risk appetites 3
4 Establish risk management strategy 4
5 Document the risk management plan 5
6 Plan and lead risk management activities with stakeholders 6
Domain II: Risk Identification
Task Chapter(s)
1 Conduct risk identification exercises 7
2 Examine assumption and constraint analyses 8
3 Document risk triggers and thresholds based on context/environment 9
4 Develop risk register 10
Domain III: Risk Analysis
Task Chapter(s)
1 Perform qualitative analysis 11
2 Perform quantitative analysis 12
3 Identify threats and opportunities 13
Domain IV: Risk Response
Task Chapter(s)
1 Plan risk response 14
2 Implement risk response 15
Domain V: Monitor and Close Risks
Task Chapter(s)
1 Gather and analyze performance data 16

2 Monitor residual and secondary risks 17
3 Provide information required to update relevant project documents 18
4 Monitor project risk levels 18
Companion Website
Register this book to get access to the Pearson Test Prep practice test software and other study
materials plus additional bonus content. Check this site regularly for new and updated postings
written by the author that provide further insight into the more troublesome topics on the exam.
Be sure to check the box that you would like to hear from us to receive updates and exclusive
discounts on future editions of this product or related products.
To access this companion website, follow these steps:
Go to www.pearsonitcertification.com/register and log in or create a new account.
On your Account page, tap or click the Registered Products tab, and then tap or click the
Register Another Product link.
Enter this book’s ISBN (9780138108472).
Answer the challenge question as proof of book ownership.
Tap or click the Access Bonus Content link for this book to go to the page where your
downloadable content is available.
Please note that many of our companion content files can be very large, especially image and
video files.
If you are unable to locate the files for this title by following the preceding steps, please visit
http://www.pearsonitcertification.com/contact and select the “Site Problems/Comments” option.
Our customer service representatives will assist you.
Pearson Test Prep Practice Test Software
As noted previously, this book comes complete with the Pearson Test Prep practice test software
containing four full exams. These practice tests are available to you either online or as an offline
Windows application. To access the practice exams that were developed with this book, please
see the instructions in the card inserted in the sleeve in the back of the book. This card includes a
unique access code that enables you to activate your exams in the Pearson Test Prep software.
Note
The cardboard sleeve in the back of this book includes a piece of paper. The paper
lists the activation code for the practice exams associated with this book. Do not
lose the activation code. On the opposite side of the paper from the activation
code is a unique, one-time-use coupon code for the purchase of the Premium
Edition eBook and Practice Test.
Accessing the Pearson Test Prep Software Online
The online version of this software can be used on any device with a browser and connectivity to
the Internet, including desktop machines, tablets, and smartphones. To start using your practice
exams online, follow these steps:
Go to www.PearsonTestPrep.com and select Pearson IT Certification as your product group.
Enter your email/password for your account. If you do not have an account on
PearsonITCertification.com or CiscoPress.com, you will need to establish one by going to
PearsonITCertification.com/join.
On the My Products tab, tap or click the Activate New Product button.
Enter this book’s activation code and click Activate.
The product will now be listed on your My Products tab. Tap or click the Exams button to
launch the exam settings screen and start your exam.
Accessing the Pearson Test Prep Software Offline
If you want to study offline, you can download and install the Windows version of the Pearson
Test Prep software. There is a download link for this software on the book’s companion website,
or you can enter this link in your browser:
http://www.pearsonitcertification.com/content/downloads/pcpt/engine.zip
To access the book’s companion website and the software, follow these steps:
Register your book by going to http://www.pearsonitcertification.com/register and entering the

ISBN: 9780138108472.
Respond to the challenge questions.
Go to your account page and select the Registered Products tab.
Click the Access Bonus Content link under the product listing.
Click the Install Pearson Test Prep Desktop Version link under the Practice Exams section of
the page to download the software.
After the software finishes downloading, unzip all the files on your computer.
Double-click the application file to start the installation, and follow the onscreen instructions to
complete the registration.
When the installation is complete, launch the application and click the Activate Exam button on
the My Products tab.
Click the Activate a Product button in the Activate Product Wizard.
Enter the unique access code found on the card in the sleeve in the back of your book and click
the Activate button.
Click Next and then the Finish button to download the exam data to your application.
You can now start using the practice exams by selecting the product and clicking the Open
Exam button to open the exam settings screen.
Note that the offline and online versions will synch together, so saved exams and grade results
recorded on one version will be available to you on the other as well.
Customizing Your Exams
When you are in the exam settings screen, you can choose to take exams in one of three modes:
Study Mode
Practice Exam Mode
Flash Card Mode
Study Mode enables you to fully customize your exams and review answers as you are taking the
exam. This is typically the mode you would use first to assess your knowledge and identify
information gaps. Practice Exam Mode locks certain customization options because it is
presenting a realistic exam experience. Use this mode when you are preparing to test your exam
readiness. Flash Card Mode strips out the answers and presents you with only the question stem.
This mode is great for late-stage preparation when you really want to challenge yourself to
provide answers without the benefit of seeing multiple-choice options. This mode will not
provide the detailed score reports that the other two modes will, so it should not be used if you
are trying to identify knowledge gaps.
In addition to these three modes, you will be able to select the source of your questions. You can
choose to take exams that cover all the chapters, or you can narrow your selection to a single
chapter or the chapters that make up specific parts in the book. All chapters are selected by
default. If you want to narrow your focus to individual chapters, deselect all the chapters, then
select only those on which you want to focus in the Objectives area.
You can also select the exam banks on which to focus. Each exam bank comes complete with a
full exam of questions that cover topics in every chapter. The exam printed in the book is
available to you as well as two additional exams of unique questions. You can have the test
engine serve up exams from all banks or just from one individual bank by selecting the desired
banks in the exam bank area.
There are several other customizations you can make to your exam from the exam settings
screen, such as the time of the exam, the number of questions served up, whether to randomize
questions and answers, whether to show the number of correct answers for multiple-answer
questions, or whether to serve up only specific types of questions. You can also create custom
test banks by selecting only questions that you have marked or questions on which you have
added notes.
Updating Your Exams
If you are using the online version of the Pearson Test Prep software, you should always have
access to the latest version of the software as well as the exam data. If you are using the
Windows desktop version, every time you launch the software, it will check to see whether there
are any updates to your exam data and automatically download any changes that were made
since the last time you used the software. This requires that you are connected to the Internet at
the time you launch the software.
Sometimes, due to many factors, the exam data may not fully download when you activate your
exam. If you find that figures or exhibits are missing, you may need to manually update your
exams.
To update a particular exam you have already activated and downloaded, select the Tools tab and
click the Update Products button. Again, this is an issue only with the desktop Windows
application.
If you want to check for updates to the Pearson Test Prep exam engine software, Windows
desktop version, select the Tools tab and click the Update Application button. This will ensure
you are running the latest version of the software engine.
Premium Edition eBook and Practice Tests
This book also includes an exclusive offer for 80 percent off the Premium Edition eBook and
Practice Tests edition of this title. Please see the coupon code included with the cardboard sleeve
for information on how to purchase the Premium Edition.
Part I
Strategic Risk and Risk Planning

Chapter 1
The Risk Structure
This chapter covers the following topics:

The Risk Archive
Every project and every organization has structure and infrastructure. Documents, processes, and
other intellectual property serve to facilitate work efforts, project management efforts, and risk
management efforts. The expectation is that the risk manager will fully leverage these structures
to render a more in-depth understanding of the risks in their work and how those risks ultimately
will be addressed. If these do not already exist, the risk manager must research what’s available
in the public domain and create the structures for the current project’s (and future projects’) risk
reviews.
This book focuses on the role of risk management in a project context, but the same principles
apply at the larger program and portfolio levels. Although projects work toward a single, discrete
objective, many of the risks that exist in projects also exist systemically. Project managers and
risk managers alike must leverage the structures for risk management in all environments. An
effective risk manager has at their disposal sources for this information and freely shares those
sources with their peers in the organization’s project community.
After the data sources are gathered, it then becomes the responsibility of the risk manager to
either conduct a thorough analysis of the documents or to identify an individual to conduct that
analysis.
Even before the project is underway, the risk manager should know and create the document
inventory required to make the risk management process effective.
This chapter addresses the following objectives from the PMP RMP® Exam Content Outline:
Domain Task # Exam Objective
Risk Strategy and Planning Task 1 Perform a preliminary document analysis
The “Do I Know This Already?” quiz allows you to assess whether you should read this entire
chapter thoroughly or jump to the “Exam Preparation Tasks” section. If you are in doubt about
your answers to these questions or your own assessment of your knowledge of the topics, read
the entire chapter. Table 1-1 lists the major headings in this chapter and their corresponding “Do
I Know This Already?” quiz questions. You can find the answers in Appendix A, “Answers to
the ‘Do I Know This Already?’ Quizzes and Review Questions.”
Table 1-1 “Do I Know This Already?” Section-to-Question Mapping
Foundation Topics Section Questions
Risk Roles and Responsibilities 2, 4, 6
The Risk Archive 1, 3, 5
Caution
The goal of self-assessment is to gauge your mastery of the topics in this chapter.
If you do not know the answer to a question or are only partially sure of the
answer, you should mark that question as wrong for purposes of the self-
assessment. Giving yourself credit for an answer you correctly guess skews your
self-assessment results and might provide you with a false sense of security.
The project is barely underway, with a signed project charter and little else. At this point in the
project, what should you, as a risk manager, have already done?
1. Identified most of the project’s major risks and shared them with upper management
2. Created an inventory of all the major risk documents that will be established for the project
3. Notified relevant team members that they will be responsible for managing the risks within
the confines of the project team
4. Evaluated the risks to determine which are the most significant
The project manager has decided to take on the challenges of conducting documentation
analysis. The project manager now has ______.
1. all the information necessary to discover all risks on the project

2. all the information necessary to discover risk sources for the project
3. a responsibility to share that information with relevant stakeholders
4. most of the information necessary to build a risk register
To do project risk identification well, certain documents become essential. What should those
documents include?
1. Historical data, industry benchmarks, lessons learned from past projects, customer
agreements, and the organization’s mission and vision statement
2. Historical data, industry benchmarks, lessons learned from past projects, and customer
agreements
3. Industry benchmarks, lessons learned from past projects, customer agreements, and the
organization’s mission and vision statement
4. Industry benchmarks, lessons learned from past projects, and customer agreements
Preliminary risk analysis through documentation analysis can be done by a variety of project
participants. Those participants may include any or all of the following, except which?
1. The project manager

2. The risk manager
3. The business analyst
4. The customer
Because of the unique nature of projects, each project can generate novel risks. Because of this,
are there situations where the risk/project manager should not take lessons learned from past
projects into account?
1. Yes, because there are some situations in which no true analogies exist.
2. No, because it’s a part of the risk process and should be done accordingly.
3. No, despite the fact that the project is different, some aspects will be analogous.
4. Yes, because not every process step is required on every project.
You have identified candidates to serve as risk owners for your project. What must these
individuals do?
1. Manage their aspects of the project, ensuring risk is considered

2. Track their risks to ensure the risks don’t come to pass
3. Develop the risk responses for the risks to which they are assigned
4. Track their risks and the responses to ensure that the risks are managed as planned
Foundation Topics
One overarching responsibility for any risk process is the capture and review of project
documentation. Every review of project documentation should be conducted through the lens of
risk identification and response. To do this properly, a critical first step is to identify the
available documentation set. Documentation about any aspect of the project can ultimately serve
in this role. From instructional guidance to contracts, each document can be reviewed with the
simple question: Based on what’s said here, what are the risks? Documents that might be
captured include some very obvious selections:
Industry benchmarks
Project plans
Lessons learned from past projects
Risk registers from past projects
Customer agreements
Project assumptions
The project charter
Project risk managers are responsible for identifying the available data set. Given that most
projects have a broad body of stakeholders, stakeholder-owned and stakeholder-developed
documentation also needs to be taken into account.
Industry Benchmarks
For every industry, the benchmarks will be different, but the nature of a benchmark remains the
same. It is a normative value that expresses what “customary” looks like. Finding or establishing
benchmarks takes time and effort, which can be done by the project manager, the risk manager,
or any competent team member. In terms of utility, a benchmark is only as valuable as how
much it aligns with the project in question. Finding the risks for materials delivery might best be
benchmarked with an organization that requires the same practice. If the organization seeking a
benchmark looks at another organization with the same efforts, great. If the organization seeking
a benchmark looks at the U.S. Postal Service, Federal Express, or UPS, they likely will not find
good risk benchmarks. Although those organizations are critical to materials delivery, they do
not have the same concerns as the shipper.
Project Plans
When it comes to project plans, it’s important to distinguish between project plans and project
management plans. Project plans detail how and when work will be conducted, at what cost.
Project management plans detail the processes that will be used to manage the endeavor, but not
the actual work to be performed. The list that follows should help to distinguish the two:
Project plans: In gathering project plan data, the information should be accessed at the
highest and lowest levels. At a high level, the project charter will generally dictate the nature
of the project and its ultimate objective. This document should be incorporated in the data set
for any risk analysis.
At a micro level, the information should be gleaned from the work packages (discrete
deliverables for the project in a waterfall management environment) or the user stories
(deliverables as described by their owner and the rationale for incorporating those
deliverables in an Agile environment). This level of specificity proves valuable in identifying
many of the smaller (but no less crucial) risks.
Project management plans: Project management plan data will include the managerial
processes used to dictate how the project will function in terms of a host of different areas. It
might incorporate the integration management plan, the scope management plan, the cost
management plan, the procurement management plan, the benefits realization plan, the
time/schedule management plan, and a host of others. The key term here is “management
plan,” because the emphasis rests on how the effort will be managed. In gathering this data,
the questions are not as project-specific as they would be for project plan data. Instead, the
questions are all about how management functions will be performed and the risks associated
with that type of performance.
Lessons Learned
There are no projects where lessons learned have no value. Every risk effort is rooted on
experience (good or bad). Every organization has its own approach to lessons learned, but an
effective risk manager must know both how to access the data set and how (and when) to update
it. Lessons learned should be broadly available to not only management but also the team and
other responsible stakeholders. As information is gathered, all responsible parties should know
its location, and each lesson learned should be associated with an active member of the
organization for in-depth analysis and reference. As information is gathered, all responsible
parties should know its location, and each lesson learned should be associated with an active
member of the organization for in-depth analysis and reference. These information sets are
frequently updated as project objectives change and as risks evolve throughout the project life
cycle.
Customer Agreements
Although contracts are the most common vehicle for customer agreements, these agreements can
take many forms. They can be verbal or written (and the former has far more inherent risk than
the latter due to potential misinterpretations). They can be internal or external. Elements within
customer agreements that should be gathered include both the requirements for the project, as
well as the terms and conditions (Ts&Cs) for deployment of the project. Whereas requirements
can highlight one set of risks, the terms and conditions underscore the contractual environment in
which the project will be executed.
In the PMI® world, project managers and risk managers have full access to any contractual
documentation for the project.
Project Assumptions
Assumptions are what the project team believes to be true in planning a project. Even the
simplest of assumptions (e.g., the weather will be decent 80% of the time) can draw attention to
inherent project risks. The assumptions log becomes one of the key documents to be developed
and gathered early in the project. It also needs to be updated throughout the project life cycle.
Any assumption that proves valid minimizes the overall project risk. Any assumption proven
invalid exacerbates the risk on a project. Chapter 2, “Risk Environment and Culture,” discusses
assumptions in greater depth.
The Project Charter
The project charter is the authorizing document of any project. A signed project charter is
essential to project success. The charter becomes the document that sanctions the project and
identifies the ultimate goals to be achieved. The key elements of any risk-effective charter will
include the following:
The project objective: A risk-sensitive project objective statement will incorporate all the
elements of SMART goals: Specific, Measurable, Agreed-upon, Realistic, and Time-limited.
The most challenging aspect of a SMART objective is the measurable aspect. Trying to find
metrics that can be validated for a project is a core component of knowing the goals (hence,
knowing what impediments there may be in achieving those goals).
Note
You will not be expected to know acronyms on the exam with very few
exceptions. Because the exam is international, the abbreviations don’t work the
same way in every language. As a result, PMI® avoids their use and spells out
the detail on such elements.
An environmental assessment: A sentence in the project charter should define the project
climate. Things like location, team dispersion, and timing pressures could be incorporated in
such a statement.
A signature: Ideally, the signature is attained in pen and ink. Although electronic signatures
are acceptable, the penned signature carries more weight. It represents a commitment on the
part of the project sponsor, who, ideally, authored the charter. If the sponsor doesn’t write the
charter, the sponsor remains accountable for its outcome. The project sponsor who signs the
charter is ideally a project champion, well-versed in the project’s outcomes, and in tune with
the project team responsible for implementation.
All the data gathering, as well as risk process implementation, is done by people. A variety of
risk roles could exist on a project and might be established based on experience, organizational
structure, or risks under consideration. Because of the wide range of expertise on a project team,
not all of the most important risk work falls to the most veteran team members. In many cases,
team members who have only recently joined an organization might have a much more in-depth
understanding of fresh technologies.
The risk roles on a project can include the following:
Risk manager
Risk owner
Risk team
The project roles that have a direct influence on risk might include any project team members
with direct influence on the project itself. These can include the following:
Finance
Legal
Development
Vendors
Any germane department serving the project
Risk Manager
The risk manager, as the name implies, is responsible for managing the risks and the risk
process. Much of this work is delegated, but it is up to the risk manager to ensure that all the
processes are covered. At a programmatic level, the risk manager is also responsible for either
identifying or working with the parties responsible for program risk governance.
If the risk manager is not seen as the key decision maker for all things risk oriented, the manager
must have a close relationship with those decision makers.
Although the risk manager could be the project manager, the risk manager might be a distinct
and separate role, particularly in situations where the project manager is overwhelmed by the
scale or scope of the project.
Risk Owner
The risk owner is perhaps the single most important role within a project from a risk perspective.
The risk owner is the person responsible for tracking risks and ensuring that risk strategies are in
place and implemented. From the point at which a risk owner is identified for any risk event, the
owner becomes accountable for all the remaining steps in the risk process. This doesn’t mean
that the risk owner develops all risk resolutions, but it does mean that the implementation of
those resolutions falls on this individual’s shoulders.
Although the risk owner might occasionally be the project manager, the risk owner is normally a
distinct and separate role.
Risk Team
The risk team might be synonymous with the project team, or it might be more expansive. The
risk team includes all the individuals who either own risks (risk owners) or individuals who are
participants in any step of the risk process. Risk is best identified, strategized, and managed as a
team because of the variety of perspectives that need to be brought to bear in any risk
environment.
Project Roles
The variety of project roles needs to be brought to bear throughout the risk process. Each
department or division has a different risk perspective. The legal department, for example, might
focus on contractual and compliance-oriented risks. Accountants might be most concerned with
risks to profit or costs. Vendors might have competitive concerns. Technical staff is tuned in to
technical risks.
By simply raising the question of “What are the risks…?” for each department, division, or
project role, a risk manager can explore a much broader assemblage of risks from differing
viewpoints.
Risk Responsibilities
Responsibilities for risk management vary depending upon the echelons within an organization.
At an enterprise level, the enterprise risk management system should incorporate a process for
assigning high- and low-level risk responsibilities at the program and project levels.
Responsibilities support the strategic objectives and mission of the organization as a whole at the
enterprise level.
At the program level, the responsibilities tie (somewhat obviously) to the risks to the program.
At the project level, the responsibilities are to manage risks within the tolerances of the
organization, the program, and the project, and to identify as many risks as possible. For those
risks deemed “high priority,” the project-level responsibilities include risk management at the
micro level, with responses, tracking, and lessons learned. Again, lessons learned are considered
a key obligation in managing the risk process.
The Risk Archive
A number of documents are commonplace in the risk archive. Those documents (as with the
responsibilities) vary based on the organizational echelon under consideration. Archival
documents become the risk history for an organization. The Project Management Institute’s®
perspective on risk indicates that they subscribe to the theory of philosopher George Santayana,
who said, “Those who cannot remember the past are condemned to repeat it.”
The two most significant documents in the risk archive are the risk repository (organizational and
multiproject) and the risk register (project specific).
Risk Repository
The risk repository is a collection of risk registers from past projects, organized to allow for
comparison of similar projects, similar customers, similar environments, and similar risks. The
repository is considered a knowledge management document, capturing the history of the
organization, its risks, and its responses.
Risk Register
The risk register element of the risk archive will be heavily tested on the exam, so a
comprehensive understanding of what should and could be incorporated in a risk register is
essential to your success.
For each component of the risk register, it’s important to understand why that information is
captured and what level of detail is appropriate. Typically, a risk register is captured in a
spreadsheet or database program and can include a wide range of information, as illustrated in
Tables 1-2, 1-3, and 1-4.
Table 1-2 Risk Register (Section 1)
Risk Probability Impact Overall Priority Risk Area

Event Risk Owner Impacted
As defined As defined Probability Ranked Name and Department

in the Risk in the Risk times order Contact or project
Management Management Impact Information component
Plan (RMP) Plan (RMP), or work
with package/user
narrative story
Area Escalation Response Response Implementation Implementation

Impacted Strategy Strategy Schedule Review
Narrative
Department Name and Avoidance, Strategy Strategy Timing Date

or project Contact Acceptance described
component Information (active/passive),
or work Mitigation,
package/user Transfer, or
story Escalation
Retirement Criteria Follow- Outcome Archive

up
Narrative of when/how the risk might Date Result of Date and

be retired action/inaction location
Each of the elements outlined in the preceding tables serves a specific purpose in terms of both
risk management and knowledge management. Some will be described in more depth later in the
book, but a clear understanding of the register is a PMI-RMP’s obligation:
Risk Event: The thing that might happen to the betterment or detriment of the project,
described in the context of a future phenomenon that has not yet occurred. The statement, “A
team member may come down with COVID” is a risk statement in that it identifies a future
that does not currently exist. The statement, “A team member is out with COVID, which will
cost us time and expense” is an issue rather than a risk event. It is a statement of things that
currently exist, rather than a future state.
Probability: The likelihood of a risk event coming to pass. The probability can be expressed
either qualitatively or quantitatively. In either case, the approach to expressing probability
should be well described in the risk management plan (RMP).
Impact: The amount at stake associated with a risk event coming to pass, as well as the
nature of the impact to one or more project or organizational objectives. Again, this can be a
quantitative or qualitative expression, but it should be accompanied with a description of the
impact. For example, High - Losing Jean to COVID mid-project would cost at least a month
on the schedule. This provides clarity on both the nature of the impact as well as the relative
level of the impact as expressed in the RMP.
Overall Risk: This is the confluence of probability and impact and is sometimes a simple
multiplication factor of the two values. In other cases, because of the lack of quantifiability,
this could be a relative statement that takes both values into account but reflects the
qualitative understanding of the risk management and/or project manager and/or risk owner.
This is addressed in depth in Chapter 11, “Risk Qualification,” and Chapter 12, “Risk
Quantification.”
Priority: Either presented as an ordinal value or as a member of a certain class of risk,
priority ranking determines which risks should be dealt with first.
Risk Owner: This is an individual responsible for checking on a given risk and for
developing and implementing the appropriate response. Whereas a project might have many
risk owners, a specific risk has only one.
Area Impacted: This can have a host of different meanings, because “area” could refer to
project elements (e.g., WBS codes, user stories), organizational departments, or any other
designation. The definition of terms should be incorporated in the RMP.
Escalation: This is the name of the party (higher in the organizational hierarchy) to whom the
risk should be addressed if it exceeds thresholds and/or tolerances. Escalation is applied when
there is insufficient authority or resources to manage the risk.
Response Strategy: Addressed in depth in Chapter 14, “Response Planning,” the response
strategy is one of the primary responses acknowledged by the Project Management Institute.
Response Strategy Narrative: This is a description of the action to be taken (or not taken) as
a result of the response strategy.
Implementation Schedule: This is not the implementation schedule for the activities
involved, but instead the implementation schedule for applying the risk response.
Implementation Review: This can either be a fixed date or a description of the project
conditions that will lead to a review of the implementation of the risk response.
Retirement Criteria: This is a brief narrative explaining if or when the risk event in question
may be retired. The default setting here is “at project completion,” although there could be
other criteria that either eliminate the risk or render it as no longer a concern.
Follow-up: This is the specific date when the risk owner is obligated to check on the status of
the risk and its response(s). If not date specific, this can be completed with a relative timing
(e.g., quarterly, semi-annually).
Outcome: For many risks, this box would be completed with a notation that the risk never
came to pass. For those that do convert to become issues, this would address the efficacy of
the strategy/response.
Archive: As discussed earlier in this chapter, archiving project documents is a key aspect of
lessons learned and knowledge management. In the risk register, this would be an annotation
on the virtual or physical “home” for information on this risk. As with most activity for
individual risks, archival responsibilities for individual risk events fall to the risk owner.
Most risk registers do not go to the extreme of incorporating all these elements. Each
organization has its own informational priorities. However, each column serves a useful function
in terms of supporting risk histories and ultimately developing healthy risk repositories.
One key to doing well on the exams is to perform repetitive spaced review sessions. Review this
chapter’s material using either the tools in the book or interactive tools for the same material
found on the book’s companion website. Refer to Appendix C, “Study Planner,” online for more
details. Table 1-5 outlines the key review elements and where you can find them. To better track
your study progress, record when you completed these activities in the second column.
Table 1-5 Chapter Review Tracking
Review Element Review Date(s) Resource Used
Review Key Topics Book, Website
Review Key Terms Book, Website
Answer “Do I Know This Already?” Quiz Book

Questions
Review Practice Questions Book, Website
Rewrite/Document Chapter Headings Book
Review the most important topics in this chapter, noted with the Key Topic icon in the margin of
the page. Table 1-6 lists the key topics and the page numbers on which each is found.
Table 1-6 Key Topics for Chapter 1
Key Topic Element Description Page Number

Section Risk Documentation Capture 6
Section Risk Manager 9
Section Risk Owner 10
Section Risk Team 10
Section Risk Repository 11
Section Risk Register 11
Define the following key terms from this chapter and check your answers in the glossary:
industry benchmarks
project plans
lessons learned
risk registers
customer agreements
project assumptions
project charter
project management plans
risk manager
risk owner
risk repository
retirement criterion/criteria
Review Questions
Your only key vendor (Acme) went out of business three years ago. Your risk repository still
includes the risk statement that Acme may go out of business, causing supply chain delays. What
does this risk statement represent?
1. A lesson learned
2. An action item for the risk manager
3. An action item for the risk owner
4. A risk that should be retired
5. An assumption
You are reviewing extensive documentation regarding the risks in your project, including their
probabilities and impacts. You are likely reviewing which document?
1. The issues log

2. The risk log
3. The risk repository
4. The risk breakdown structure
5. The risk register
A risk archive will likely include what documentation?
1. The risk register, the risk breakdown structure, and the risk repository
2. The risk register, to examine current project risks, and the risk repository, to examine past and
current projects and their risks
3. The risk register, to examine past and current projects and their risks, and the risk repository,
to examine the current project and its risks
4. The risk breakdown structure, to identify risks according to their sources
5. The collection of all project documents that may influence project risk
Management wants to ensure that everyone understands the nature of the project’s goals and
your interpretations of what may impede progress toward those goals. This can be achieved
through the project charter. Who signs off on the project charter?

2. The project sponsor
3. The project manager and the team
4. The project sponsor and the team
5. The customer
Bobbie Martini was just assigned as the risk owner for the risk that a team member may be
struck by a train in the project’s implementation. Their primary job is to do what?
1. Communicate the status of the team and the train.

2. Track the shifting nature of the risk, apply any responses, and report on progress.
3. Notify management if the trains stop running.
4. Notify the project manager if the team member is in direct peril.
5. Document the death of the team member in the risk register.
Chapter 2
Risk Environment and Culture

Risk Assumptions
The PMI-RMP® exam recognizes the critical relationship between organizational, physical and
social environments, and risk. Just as one organization might have management that rigorously
investigates and responds to risk, another might be oblivious to the risks or their impacts. The
Project Management Institute has made this topic a foundational element of setting down risk
strategies.
To identify risks and evaluate their relative impact on projects, the risk manager needs to know
the nature of the project, the environment in which that project will evolve, and the constraints
and/or impediments to implementing any risk approach. That manager also has a responsibility
to identify those who know the risk environment well and who can make a difference in
supporting or rejecting the risk strategies.
From the overall cultural norms for risk (as expressed through appetite and attitude) to the
individual stakeholders and their risk awareness, PMI® expects the project manager to take an
active role in ensuring that the appropriate risks are identified and that their relative levels of
impact and probability are well-expressed in the Risk Management Plan. These are discussed in
depth in Chapter 3, “Tolerance, Thresholds, and Triggers.”
Above all, the exam takes a success perspective, making the recognition of project objectives, as
well as risk objectives, a notion that must be addressed through formal practice.
®
The PMI-RMP® exam focuses on the need to have the organizational process assets, enterprise
environmental factors, and strategic approaches in place to manage risk effectively. Note that the
emphasis is not on eliminating risks, but on managing them. An effective risk management
environment will ensure that risks that might occur will do so within the tolerances of the project
and its supporting organization.
This chapter examines these environmental considerations. It also drives to the project manager’s
(or risk manager’s) roles in executing the best practices to assess the project environment for the
risks that environment may create or eliminate.
Throughout the risk process, these environmental considerations might evolve. It is incumbent
on the effective risk manager to document and communicate any such evolution to the relevant
stakeholders.
This chapter addresses the following objectives from the PMI-RMP® Exam Content Outline:
Domain Task Exam Objective

#
Risk Strategy and Task Assess project environment for threats and
Planning 2 opportunities
The “Do I Know This Already?” quiz enables you to assess whether you should read this entire
Risk Attitude, Appetite, and Maturity 1, 2, 4, 6
Risk Assumptions 7
Constraint-Driven Risks 7
Stakeholders and Risk Culture 5
Organizational Infrastructure 3
Caution
You are attempting to ascertain the degree to which the organization is willing to take risks. As
you review the information in the risk management plan, you discover that risks that would drive
the project more than 15 percent over budget would be considered “showstoppers.” Risks of that
nature help you understand what about the organization?
1. Risk appetite
2. Risk tolerance
3. Risk attitude
4. Risk approach
One of your team members just discovered that the project accounting system incorporates
purchasing cards that open the organization up to potential fraud. The last time fraud was raised
as a subject, an entire team was fired and personnel were tainted by the experience. What should
you advise your team member to do?
1. Document the problem and include it in the lessons learned.

2. Immediately elevate the risk to you and senior management.
3. Remain silent unless the risk converts to an issue.
4. Document the problem.
Traditionally, your organization has planned every aspect of projects down to the most minute
detail. Planning is an organizational hallmark. However, your newest project is completely
innovative. It’s work you have never done and that is totally unfamiliar turf. You have no
established protocols for doing the work, and your team members know that the only way they’ll
get through it is with constant communication. Given the project type and the organization’s
history, what is the best approach for this particular project?
1. Waterfall
2. Hybrid
3. Agile
4. Kanban
You have decided to conduct a SWOT analysis to better understand your project environment
from a risk perspective. What does this mean you’ll examine?
1. The strengths and weaknesses of the project and the opportunities and threats of the
organization
2. The strengths, weaknesses, opportunities, and threats of the project
3. The strengths, weaknesses, opportunities, and threats of the organization
4. The strengths and weaknesses of the organization and the opportunities and threats of the
project
You realize that, ultimately, your responsibility is to deliver the project outcomes to the
satisfaction of your customer. To ensure that you can accomplish that goal, you’ve studied the
business case for the project over and over. It suggests that the project can achieve a 17 percent
return on investment over the first two years. The more you read the business case, the more
confused you become. You realize that you need the insight of the people who understand the
thinking behind the business case. You want to get a look at the benefits realization plan and the
supporting documentation behind it. Your best bet for finding that information is a visit to
whom?
1. Business analyst
2. Accountant
3. Risk officer
4. Boss/manager
Your organization has a history of success. Although it seems they could never do the same
project twice, they seem to have a knack for making customers happy. Team members integrate
well with each other, even if they’ve never worked together before. Projects are done on time, on
budget, and according to specifications. None of the information that leads to this success is
documented, because the organization fears losing the “secret sauce” that makes the company
special. In terms of cultural risk management maturity, what can this organization be considered?
1. Fully evolved, as evidenced by their consistent success

2. Mature to the point of having repeatable success
3. Mature to the point of having team members who can enable the success
4. Immature
Your project is to deliver decorations for the New Year’s Eve gala at the most prestigious estate
in Idaho. If they are not delivered by December 31 at noon, there’s no time to install them. Local
weather forecasters say there’s no snow in the forecast for at least three days on either side of the
event. You’re operating your project based on their expertise. For this project, which of the
following statements is true?
1. December 31 at noon is an assumption, the lack of snow is a constraint.
2. December 31 at noon is a constraint, the lack of snow is an assumption.
3. December 31 at noon is an assumption, as is the lack of snow.
4. December 31 at noon is a constraint, as is the lack of snow.
Foundation Topics
Every organization, individual, and culture has limits. There are “rules of the road,” which are
both explicit and tacit. Explicit rules are those that are clearly documented and which express, in
no uncertain terms, risk approaches and risks that are wholly acceptable or wholly unacceptable.
Tacit knowledge is information that, although just as important as explicit knowledge, is not
openly expressed or quantifiable through the use of limits or process steps. Both sets of
knowledge, explicit and tacit, provide the risk manager with an understanding of how far they
may go before a risk becomes unacceptable or before a risk may convert to an issue.
These limits set a foundation for risk attitude, appetite, tolerances, thresholds, and maturity.
Before discussing the nature of the different terms, it’s important to understand that they all can
apply at the individual, divisional, organizational, cultural, or geographically regional level.
Although certain risk tolerances might apply for one organization, another might not consider
them at all. For the certification exam, the baseline assumption should be that the terms are being
used in a project context, unless otherwise specified within the question.
Tolerance
The formal definition of a tolerance, per PMI®, is the quantified acceptability of variation for a
requirement. Tolerances can be financial in nature, such as a “plus or minus” range for project
costs. They can also apply to the schedule, with the same sense of acceptable ranges. From a
quality perspective, tolerances are quantified in ideal situations, but can also represent
“showstoppers” that would cause the organization to immediately take action.
Tolerances are preordained and are listed as critical components of the risk management plan,
ensuring that there is a common understanding about the limits on risks that are tolerable to a
project or its sponsoring organization.
In common parlance, a tolerance for a driver would be the ditch on either side of the road. When
a tolerance is hit, the project temporarily (or permanently) stops, forcing reconsideration as to
whether further progress is warranted.
Threshold
A threshold is a point at which variability from requirements causes a change in behaviors.

Established by virtue of the tolerance, the threshold represents a commonly understood condition
where project direction may shift or where certain actions are taken. This is often the point at
which different echelons of management are notified about current risk conditions.
Thresholds can also apply at the lower end of the spectrum. Some thresholds are established to
avoid creating concern regarding small-scale or nominal risks. Although the risk of losing
$10,000,000 would (in most projects) cross a threshold, a risk of losing $10 would likely not.
The lower-end thresholds become important when trying to avoid a glut of risk, where too many
risks are identified and tracked.
Appetite
Thresholds and tolerances reflect organizational, project, and individual risk appetites. The easy
way to remember risk appetite is to remember that it represents what an organization can
“stomach.” If a risk might cause some harm to the objectives, but not enough to change
behaviors, such risk fits squarely within the risk appetite of the entity in question. Any thorough
stakeholder assessment must ultimately take risk appetites into question. Project managers need
to consider the appetites of the following:
Customer
Management
Team members
Vendors
Organizations
Governing boards
Governments
Public
While a project’s progress might be seen as organizationally acceptable, a public outcry (a sign
of risk exceeding appetites) can be enough to shut down an effort entirely. Thus, there is no
single appetite for a project. There are hosts of different appetites that all need to be taken into
account.
Risk–reward considerations play heavily into risk appetites. Just as many players have no interest
in paying for a lottery ticket when the jackpot is relatively small, the higher the value of the
reward eventually creates a greater appetite for many players. Sales of Lotto tickets, for example,
grow exponentially when jackpots exceed the half-billion-dollar mark.
Attitude
Attitude is a close relative to appetite. As with appetite, each stakeholder might have a different
risk attitude, which is often outwardly expressed through witnessed behaviors. Those behaviors
are sometimes mercurial, shifting in different market contexts, legal environments, and political
settings.
Attitudes apply not only to the organizational posture toward specific risks, but also toward the
risk responses. When helmet laws were first applied for motorcyclists in many states in the U.S.,
some bikers felt the requirements were overkill. A skilled rider, they would argue, had no need to
wear a helmet and should be able to opt out of the requirement. Emergency room staffers, by
contrast, who dealt with the outcomes of risk realized in these situations, were among the chief
proponents of such regulation. The risk response of enforcing helmet laws had strong backing in
the medical community.
Risk Maturity
Many organizations have not explored their own maturity in risk management practice. Maturity
begins with consistency in practice, tied directly to documentation and enforcement. Any
organization without rigorous documentation of their risks and risk practices can be deemed
“immature.”
Maturity can evolve in a variety of areas, but no matter the risk considerations, consistency of
practice and documentation are the hallmarks of a more mature risk organization.
Some of the aspects of maturity include:
Escalation paths
Risk methodology
Risk tools
Risk techniques
Reporting formats
Reporting protocols
For any or all of these, the important consideration is that they are clearly documented and
scalable within the organization, no matter the project scope. Without consistency in these
practices, an organization might not be considered “mature.” The more of these aspects that are
applied consistently and supported by thorough documentation, the more mature the organization
is.
In some measure, the maturity of the organization is sometimes reflected in Strength, Weakness,
Opportunity, Threat (SWOT) analyses. These tools enable an analysis of the strengths and
weaknesses of an organization or external influences. They also provide the opportunities and
threats of the project at hand.
Risk Assumptions
In all aspects of risk planning, risk identification, and response development, assumptions come
into play. Assumptions are what we (as an individual or organization) believe to be true for
planning purposes. Given the fact that risk is a future phenomenon, assumptions play a vital role
in our ability to assess the project environment. If we believe, for example, that a project will
likely be conducted in Mexico, hosts of assumptions are taken into account. The weather will be
warm. The primary language will be Mexican Spanish. The electrical grid will be sufficient for
all but the most extraordinary of needs.
If any of those assumptions prove invalid, hosts of risks are generated. Mexican Spanish, for
example, is not the same as European Spanish or Guatemalan Spanish. A language barrier
limiting access to training and tutoring can prove to be a meaningful source of risk for any
project. Thus, risk assumptions need to be captured, and also shared across the project team and
the project organization. In assessing the potential impact of assumptions, three questions need to
be asked:
Could the assumption be invalid?

If it’s not valid, would it directly affect the project outcomes?
Should it be converted to a risk statement?
If the first two questions merit a “yes” response, and the impact is sufficiently meaningful to
have a direct impact on the objectives of the project, a risk statement should be generated. This
will be discussed further in Chapter 7, “Practical, Team-Based Risk Identification,” and Chapter
8, “Constraints and Assumptions,” but for now, the basic statement will be If <<assumption>>
proves false, <<impact>> may happen.
On the exam, be acutely aware that PMI®’s expectation is that management, team members, and
customers will all openly and freely share their respective assumptions and the rationale behind
them. The project stakeholders will inherently have differing assumption sets, but those sets need
to be logged and communicated to all project parties.
Just as we must document assumptions to ensure a comprehensive overview of the risk

environment, we must also document, capture, and report on all project constraints. Unlike
assumptions (which represent beliefs), constraints represent the hard-and-fast rules of the
project. The project must not exceed $24,000,000 in overall costs (including time and materials).
The project must be completed by September 4 of this year. The system generated by the project
must be able to support at least 5,600 end users. These are all constraint statements. They are the
absolutes of a project. And they extend far beyond time, cost, and quality. Constraints come from
many sources, including constraints that are not directly dictated by the project customer.
Examples of constraint-generating sources comprise (in part):
Government regulation
Cultural norms
Ethics practices
Physical limitations (e.g., size, weight)
Failure to identify a constraint early in the project is a common project risk. A missed regulation,
for example, can lead to extensive rework and scrap if it impacts the project’s operability.
Constraints impact how we manage projects and what we consider to be the crucial elements for
getting the job done.
Constraints can be internal or external. Internal constraints are often self-imposed, where we or
our management make a determination that there is one specific approach that must be used.
External constraints come from outside organizations, such as the government. Constraints are
not weighted, because they are simple yes/no evaluations. A project either exists within its
constraints or it does not. And a project that does not exist within those constraints is non-
compliant. Theoretically (and for the exam), non-compliant projects cannot be implemented.
Every risk management plan must take stakeholder management and stakeholder engagement
into account. Stakeholders are those individuals who are positively or negatively influenced by or
have a positive or negative influence on the project. The stakeholder register not only identifies
the individuals (preferably by name), but also captures a wealth of other information with direct
impact on their risk attitudes and appetites, as illustrated in Table 2-2.
Table 2-2 Stakeholder Register
Stakeholder Contact Title Role on the Key Engagement

Name Information Project Expectations Level
(Current
and
Desired)
Don Diehl 301-606- VP Vendor We’ll use Supportive

6519 (cell) representative their product (c)
throughout. Supportive
(d)
Mary 301-482- End Beta tester The system Supportive

Holliday 4519 user will work (c)
right the first Leading (d)
time.
Juanita 301-662- System Integrator The system Neutral (c)

Wynn 7877 Admin with other will be based Supportive
systems on existing (d)
platforms.
A comprehensive stakeholder register affords the risk manager the ability to understand the
thought processes of virtually anyone engaged in the project. In the register in Table 2-2, for
example, the fact that Don anticipates his product will be used throughout the project may create
a risk in that he could take the project organization for granted. Or, it could go in the other
direction, leading to a higher level of service and performance.
This register can also draw information from a salience model or from a stakeholder engagement
matrix.
Salience Model
A salience model takes into account two facets of stakeholders to determine which stakeholders
are the more significant participants in the process. A classic salience model would incorporate
Power and Interest as two dimensions, as in Figure 2-1.
Figure 2-1 Stakeholder Salience Model Framework
The stakeholder register and salience models should not be confused with a stakeholder
engagement matrix. The stakeholder engagement matrix is a tool to track the stakeholder levels
of commitment. PMI® breaks those levels down as follows (these represent either current or
desired stakeholder levels of engagement):
Unaware: Unaware individuals are those who do not know about the project. As such, their
risk awareness is also extremely low. In the classification of current state versus desired state,
“unaware” is the only class that cannot migrate downward. Someone who is in any of the
other states cannot be rendered unaware (save through a serious bout of amnesia).
Resistant: Resistant individuals are those who are aware of the project and oppose its
outcome, approach, or implementation. An analysis of these individuals will inherently
identify some risks. They pose risk by themselves, often by virtue of their willingness to share
their rationale for resistance openly with other stakeholders.
Neutral: Neutral individuals are those who want the project neither to succeed nor fail. Their
level of disinterest can be either a blessing or a curse, depending upon their organizational
position or their levels of expertise in the subject matter of the project.
Supportive: Supportive individuals are those who support project success. They want to see
the project succeed, and if called upon, will take action to serve that success. They are not the
project spokespeople or the cheerleaders of the team. They are the people who create
opportunities for success through their willingness to engage in the project as required.
Leading: Leading individuals are those who not only support project success, but also cheer
that success on in public settings. Leaders assume the attitude that their job is to openly
promote the project at every opportunity and to identify ways to render it more successful.
Stakeholder Tolerances
As discussed earlier with appetites and attitudes, stakeholder appetites and attitudes need to be
taken into account to establish the risk environment. A single risk-averse stakeholder in the high-
high quadrant of the salience model could change the tenor of the project manager’s willingness
to take certain risks. A risk-prone stakeholder in that same quadrant would likely expect risks to
be taken, even with the possibility of loss.
To establish stakeholder tolerance, stakeholders should be interviewed with test questions and
sample scenarios. Such questions provide more clarity on the amorphous nature of risk in a
multiparticipant environment. The questions could include the following:
What specific actions or behaviors would cause you to call for the project to be terminated?
If the project were to run overbudget by $X, would that be a situation where management
should review the effort for termination?
If the project were to be late in delivery by X days, would that be a situation where
management should review the effort for termination?
If the project deliverable came under fire for X, Y, Z, would that be a situation where
management should review the effort for termination?
Note that all the questions identify termination points for the project. Tolerances are dictated by
the points beyond which a project will not proceed. If stakeholders do not understand the
questions, examples should be provided.
What specific actions or behaviors would cause you to call for the project to be terminated?
For example, if the project came under fire from an animal rights organization for the use of
test animals during its creation….
If the project were to run overbudget by $X, would that be a situation where management
should review the effort for termination? For example, if the project ran over budget by 10%
at any given milestone….
If the project were to be late in delivery by X days, would that be a situation where
management should review the effort for termination? For example, if the project were to
miss a deadline or milestone by more than two weeks….
If the project deliverable came under fire for X, Y, Z, would that be a situation where
management should review the effort for termination? For example, if the project deliverable
came under fire for cultural appropriation….
Stakeholder tolerances (limits established by the stakeholders, rather than the project or
organization) need to be evaluated with consideration for the stakeholder salience model and the
engagement matrix. Stakeholders in the high-power/high-interest quadrant merit more serious
consideration than those in the low power quadrants. Those in the low power quadrants need to
be tracked, nonetheless. These individuals can sometimes migrate to a higher power level
through aggressive behaviors, rendering their tolerances more meaningful than in a preliminary
assessment.
Risk Owners
Stakeholders might also be engaged by being enlisted as risk owners. Risk owners are those who
track risks and are often called upon to implement (or monitor implementation of) risk strategies.
Risk owners should be individuals who have a clear understanding of the breadth of the risk
events or source they own. That breadth should include the following:
Nature and description of the risk event, its probability, and impact
The influence of the risk on stakeholders and on the project itself
The acceptability of the risk, as well as the tolerances associated with it
The suggested and adopted risk responses
The current status of the suggested and adopted risk responses
The timing for review or retirement of the risk
Risk owners need to have both the responsibility and authority to report on and act on the risks to
which they’re assigned. In the ideal situation, the risk owner is someone with a stake in the
outcome of the risk event. The project manager is responsible to ensure the owners act with
urgency as appropriate.
Stakeholder Risk Planning
Just as risk owners are responsible for individual risks, all stakeholders have a vested interest in
identifying and planning for risk events and their sources. Risk sources are a major consideration
on the exam, because those sources serve as helpmates in identifying risk, as well as in risk
categorization. When risks are categorized, it is done by the risk sources. Examples of such
categorization include the Risk Breakdown Structure (Hillson) and PESTLE analysis. PESTLE
risk sources are believed to exist on virtually every project:
Political
Economic
Social
Technological
Legal
Environmental
Stakeholders should be asked not just “What are the risks?” but should be asked about the risks
on a project categorically: “What are the political risks?,” “What are the social risks?,” and so
forth. Risk categories provide structure to ensure that the greatest body of risks is identified.
Stakeholders should be engaged. They should be active participants in the process. No matter
their role, each individual brings a different set of experiences to bear. Our role is to ensure that
those experiences are drawn upon as discussed in Chapter 7, using facilitation tools and
techniques such as focus groups, brainstorming, mind mapping, and others. The facilitator for
such efforts should be skilled in their application and well-informed on the stakeholders with
whom they’ll work.
Stakeholders exist at the project level, where work toward a discrete objective is being done.
They also exist at the program level, where multiple projects are in place, focused on a common
element, such as a common customer, common platform, or common department. Still other
stakeholders are at the portfolio level, which is generally a high level of governance over all the
projects past and present.
Program Stakeholders
Very few stakeholders are single-interest participants in the process. For many stakeholders, they
have interests that extend beyond a single project into an entire program. Whereas projects have
a defined beginning and end, programs do not. That changes the stakeholder’s risk posture.
When stakeholders have a programmatic perspective, their interest may extend for years and
years, as the projects within the program come and go. They take into account the long view of
the program, which generally drives an assessment beyond a single organization or deliverable.
Portfolio Stakeholders
Portfolio stakeholders, like program stakeholders, have a much broader understanding of the
risks in the environment. They take the entire organization into account, as well as the variety of
projects, programs, and work. With this wide-ranging outlook, they take not only project risk
into consideration, but also management and organizational risks. The classic role for portfolio
stakeholders is that of business analysts. They develop business realization plans and strategies
that address the project, and consider the impact of that business realization in programmatic and
organizational (portfolio) contexts.
Data Processing
As the stakeholder risk information is gathered, the records are archived. Archives should be
retained for as long as is legally required, and no longer. Beyond that point in time, they should
be either reevaluated or destroyed. The role of an effective risk manager in this environment is to
ensure that data processes are in place and that they are adhered to zealously. There is no single
data storage and retrieval approach for risk information, but there is a common understanding as
to the artifacts that will be generated. The two most significant artifacts are the risk register (with
detail on the current project’s risks) and the risk repository (a library of project risks and details
from past projects). Both are discussed in greater depth in Chapter 7.
All risks exist in an organizational climate. That climate is established, in large part, by the
infrastructure supporting the organization and by the deployment of tools and techniques at the
project manager’s disposal. Infrastructure in a risk context is largely focused on the sources of
risks, including communications, facilities, equipment, hardware, and capacity. These can either
be enablers of the risk management process or can prove to be impediments to its
implementation.
Communication
The single most significant (and pervasive) element of infrastructure is communication. The
tools and techniques for risk communication serve as the means to ensure that all stakeholders
are aware of, and participants in, the risk process. The organizational infrastructure for risk
communication involves any of the existing tools and processes for information exchange. This
may include email, memoranda, meetings, focus groups, or any facilitation settings.
Facilities, Equipment, and Hardware
As the COVID experience taught, the organizational facilities for communication are not
exclusively physical. Virtual facilities such as Zoom and Skype become just as important to
information sharing as any physical facility or meeting room. Without well-established facilities,
risk communication could fail dramatically.
Capacity
Most risk information sharing is somewhat intimate. Large group settings are not the norm for
gathering risk information. Still, an organization’s capacity to gather and share information can
be a risk source. Capacity can come in the form of seating capacity in a conference room to the
storage capabilities of an organizational intranet.
For all of these aspects, broad capability generally implies a better capacity to conduct
knowledge transfer within and outside an organization—a vital aspect of a well-managed risk
process.
The other key consideration here is the nature of the project organization. Waterfall (predictive)
approaches minimize risk in situations where many of the conventional variables are well
known. Agile (adaptive) approaches ameliorate risk when there are many new and unknown
conditions. Hybrid models apply when both considerations (knowns and unknowns) are in play.
The selection or determination of the project organization happens early in the project and is
often tied directly to both the culture of the organization and the nature of the work to be
performed.

Answer DIKTA Questions Book
the page. Table 2-4 lists a reference of these key topics and the page numbers on which each is
found.

Key Topic Description Page
Elements
Section Tolerance 23
Section Risk Assumptions 26
Section Salience Model 29
Paragraph Framework for tracking current and desired state of stakeholders, 29

and list their perspectives, and their level of influence
Section Stakeholder Risk Planning 32
tolerance
threshold
appetite
attitude
maturity
assumptions
constraints
stakeholder register
salience model
stakeholder engagement matrix
risk owner
PESTLE
Review Questions
The organization has declared that your project will not exceed $2,000,000, no matter what.
They will not spend a dime beyond that point. Team member Ahmed has identified a risk that
would push project costs well beyond the $2 million mark. He keeps telling you that you don’t
need to worry, because it probably won’t happen, and if it does, you’ll figure it out then. His
reassurances reflect what aspect of his risk perspective?
1. Risk attitude
2. Risk appetite
3. Risk tolerance
4. Risk threshold
5. Risk culture
Your organization seems documentation happy. They record action items in every risk meeting
and they follow through on what’s been documented. The archives are maintained by a skilled
librarian, and there are regular retrospectives to review and share lessons learned. In considering
organizational maturity, you would likely state that your organization is in what level of
maturity?
1. There is no indication of any maturity here.

2. The maturity is low, because you shouldn’t have to record actions at every meeting.
3. The maturity is high, because most of the team members are senior within the organization.
4. The maturity is high, because information is being retained and shared.
5. The maturity is in development, because processes are evolving.
Your project was to be conducted in Youngstown, Ohio, but is instead going to be developed by
the team in Kuala Lumpur, Malaysia. You selected vendors in the greater Youngstown area and
now have to contact them to see if they can handle the work on the other side of the world. When
you selected your vendors, you did so based on what?
1. Assumptions
2. Constraints
3. Assumptions and constraints
4. The vendors’ assumptions
5. The vendors’ constraints
You have a project sponsor who has been a true champion for your project. She has shown up for
team meetings, promoted the project with her peers and superiors, and keeps close watch to see if
there’s anything she can do to help. In a traditional Power/Interest salience model, she is likely in
which quadrant?
1. High Power-High Interest

2. High Power-Low Interest
3. Low Power-High Interest
4. Low Power-Low Interest
5. Can’t be determined without more information
You didn’t think it was possible, but you found a corner of the world where the best Internet
speeds are measured in Mb, rather than Gb. These slow speeds are compounded by the fact that
the power grid is dicey at best. Not only that, your building tends to be about a foot underwater
during much of the monsoon season. These are failings of who or what?
1. Management, because they should have known that these shortcomings exist
2. The customer who chose this location
3. Organizational infrastructure, because this appears systemic at this location
4. Stakeholder tolerances, for putting up with this
5. Project tolerances, for allowing this within “acceptable” limits
Your 17-year-old child just drove your car into a ditch. As a risk expert, you explain to them that
they have reached what?
1. A threshold
2. A tolerance
3. The limits of their risk appetite
4. The limits of their risk attitude
5. The end of your rope
Chapter 3
Tolerance, Thresholds, and Triggers
This chapter covers the following subjects:
Risk Absorption
Aligning Tolerances and Thresholds
Triggers
Recognizing Cultural Discord
Much of the insight in this chapter covers information that will ultimately be documented in the
Risk Management Plan (RMP). With a broad body of stakeholders to consider for any project,
it’s important to align the risk cultures so that all parties react appropriately as a risk is
considered and if or when it converts to become an issue.
The PMI-RMP® Exam anticipates that the risk manager (or project manager) will gather this
information and render it as project specific.
The manager is also responsible for reviewing any changes to these conditions over time, as
tolerances might shift with the vagaries of changing environments.
This chapter addresses the following objective from the PMI-RMP® Exam Content Outline:
Risk Strategy and Planning Task 3 Confirm risk thresholds based on risk appetites
Risk Absorption 1
Organizational and Project Risk Tolerance 2–5
Recognizing and Resolving Cultural Discord 6
Caution
You work for the Acme Corporation, and as you launch into your next project, your manager has
instructed you to determine the level of risk absorption for the organization. What does your
manager want to know?
1. How much risk the organization can handle

2. How much risk you believe your project can handle
3. How far is “too far” when it comes to individual project risks
4. Which risk approaches are tolerable to the organization
Which of the following best describes a project risk tolerance?
1. The point approaching a threshold at which an organization will modify its behaviors
2. The range of acceptability for risk
3. The identifying signal or condition that causes a change in organizational behavior
4. The point at which risks are escalated to senior management for review or action
As trains approach a railroad crossing, about 3,000 feet before they reach the crossing, the bells
ring, lights flash, and barrier arms lower. As a driver, you are expected to stop before you reach
the crossing to preclude an accident. In risk parlance, what type of situation is this?
1. The bells and lights are triggers, and the 3,000 feet is a tolerance.
2. The bells and lights are triggers, and the 3,000 feet is a threshold.
3. The bells and lights are tolerances, and the 3,000 feet is a trigger.
4. The bells and lights are thresholds, and the 3,000 feet is a tolerance.
Two team members argue constantly about the organization’s level of risk aversion. Jean
contends that the organization is overly risk averse, while Martine believes the organization is
overly risk prone. Who thinks the organization is taking too many risks?
1. Jean, believing the organization willingly takes on risk after thoughtful evaluation
2. Martine, believing the organization too often rejects risk after thoughtful evaluation
3. Jean, believing the organization too often rejects risk after thoughtful evaluation
4. Martine, believing the organization willingly takes on risk after thoughtful evaluation
Your organization is a multi-billion-dollar enterprise. With clients around the globe, you develop
projects ranging from several hundred thousand dollars to projects in the hundreds of millions.
You are the project manager and risk manager for a $900,000 USD effort. Management sees this
as an opportunity for you to prove yourself as a risk manager. To do the job well, you tell your
boss that you’ll let her know any time a risk is identified that could cost the organization an
additional $100,000 USD or more. She says you need to lower that number and suggests she
would like to be notified anytime a risk is identified that could cost the organization an additional
$50,000 USD or more. What does that $50,000 represent?
1. The degree of risk absorption the organization can withstand

2. The degree of risk absorption the project can withstand
3. The risk tolerance the project manager can accept
4. The risk trigger for the project team
Your client believes that anthropogenic climate change is a serious reality that must be dealt with
on every project. You have some team members who don’t share the client’s concern. Every
time you host a risk review, the client evaluates the risks through the prism of this political hot-
button issue. Team members roll their eyes and sigh audibly whenever the subject is raised. As
the project manager for this effort, what should you do?
1. Preface each review with an explanation of how conflicts will be managed during the meeting
and identify normative behaviors for everyone in the room.
2. Identify off-limits topics for the meeting, emphasizing that they don’t contribute to the
broader understanding of the risks at hand.
3. Allow the discussion to continue freely for a fixed amount of time, and then explain how the
topic will be revisited at a later date.
4. Grant each party equal time to express their views, and terminate the discussion thereafter.
Foundation Topics
Risk Absorption
Risk absorption is about what individuals, projects, cultures, and organizations can withstand. A
young, healthy, able-bodied human might be able to cope with the impact of a car accident,
whereas a centenarian with health issues might not. Organizationally, some risks can be absorbed
solely by the project organization, whereas others might be shared across projects or across
different organizations.
Individuals make decisions involving risk absorption on a regular basis. Every auto insurance
policy with a deductible is representative of such thinking, as displayed in Table 3-2.
Table 3-2 Comparative Insurance Policies
Policy A Policy B Policy C
Comprehensive Insurance Not offered Offered with a Offered with a

(for non-driving coverage) $250 USD $500 USD
deductible deductible
Collision and Liability Covered up Covered up to Covered up to

Coverage to $500,000 $20,000,000
$1,000,000
Collision and Liability $400 $100 $1,000

Deductible
In selecting a policy, the insured is determining their level of risk absorption. Many people opt to
not get comprehensive insurance because the price is too high, and (more importantly) they feel
that they can manage the risks involved independently. Still others want a low deductible
because they have had past experiences where they have leveraged the comprehensive policy,
and they see a value greater than the deductible in their purchase.
The risk-averse (risk-avoiding) individuals might opt for Policy C for collision coverage,
because they are willing to absorb virtually no significant risk. Those who purchase Policy B
(and are thus more risk prone) might not envision a situation where they would have to cover
anything more than $500,000, so they are willing to absorb all risk above and beyond the half-
million-dollar mark.
On the other side of the transaction, insurance companies make their assessments for risk
absorption based on driver age, accident history, and vehicle. A 40-year-old with a perfect
driving record driving a 10-year-old Toyota Corolla will likely be a cause for an insurance
company to absorb the risk with the driver’s policy. An octogenarian with an average of one
accident a year driving a brand-new Maserati will cause the insurance company to seriously
evaluate how much risk they are willing to absorb.
In the insurance example, absorption is shared. The driver absorbs some risk. The insurance
company absorbs some risk. And with insurance, actuaries make the determination on how much
absorption is acceptable. And the risk sharing of who pays for what reflects the relative degrees
of absorption.
Risk absorption is not exclusively about money. It can relate to almost any aspect of the project.
For an environmental risk, a company might be willing to accept certain types of pollutants in
certain measures. For technical risks, bugs in a software package (particularly a beta version)
might be something the developer is willing to absorb. The legal department might identify some
language in a contract that allows for various interpretations, but because the client requires it,
they might be willing to absorb the risk associated with the ambiguity.
The etymology of tolerance is from the root word “tolerate,” which is rooted in the Latin for
what an individual or organization will bear. There are distinct differences between
organizational tolerance and project tolerance, and that distinction is borne out on the exam. In
both cases, the tolerance represents a hypothetical wall between what can be withstood and what
cannot.
Organizational Risk Tolerance
Although a project manager does not set the organizational risk tolerance, that tolerance must be
on radar. It represents the cultural norms of the organization for what will or what will not be
endured. When organizations make enterprisewide decisions, those decisions take organizational
tolerances into account.
A good example of organizational risk tolerance transpired in 1986, when the Earth Island
Institute entered legal battles regarding the percentage of dolphins allowed in tuna fishing. Tens
of thousands of dolphins were dying annually due to certain fishing practices. The Earth Island
Institute began a public awareness campaign spotlighting the practices and creating a distinction
between “dolphin-safe” and “dolphin-deadly” tuna. As public awareness grew, canned tuna
companies were compelled to acknowledge and accept only dolphin-safe tuna. Companies such
as Star-Kist, Bumblebee, and Chicken of the Sea established organizational tolerances as a result
(http://www.eurocbc.org/page322.html).
Their decision impacted everyone in their supply chain. It determined where tuna could be
purchased. It determined viable and nonviable tuna sources. If asked, all related vendors would
have to be able to indicate that their fishing practices were dolphin safe.
This is the nature of organizational risk tolerance. It impacts work at all levels. It establishes
absolute limits and codes of behavior. It alerts all parties to what activities, spending, delays, or
behaviors will not be accepted. It is absolute and far reaching.
Project Risk Tolerance
Project managers and risk managers should set the project risk tolerance, which bears many
similarities to organizational risk tolerance. It represents the cultural norms of the project for
what will or will not be endured. As project decisions are made, those decisions are made in the
context of the project risk tolerance.
The traditional tolerances on any project are established for time, cost, and quality. For each of
these primary project constraints, the question is asked: How far is too far?
For the schedule, the tolerance might be a statement regarding delays or fixed delivery dates
(e.g., The widget must be delivered by July 22, or the contract will be null and void).
For cost, the tolerance is expressed as a limit as well (e.g., The total project cost may not exceed
$2.8 million USD. At that point, termination protocols will be followed for the effort).
For quality, the tolerance limits can relate to virtually any aspect of project performance.
In all cases, the tolerances represent walls that cannot be pierced. Again, as with organizational
tolerance, they represent points beyond which a project will not go.
This information is developed by the risk manager and the project manager and is openly shared
with the project team, as well as critical stakeholders.
These tolerances should be a direct reflection of organizational and project stakeholder risk
appetites. As organizational leadership or project ownership shifts, the appetites might be
different, prompting a reassessment of tolerances. As the tolerances are shared openly with the
relevant parties, those parties should be involved in any adoption or review.
Thresholds
Thresholds are a direct function of tolerances. If a tolerance is a point beyond which an

organization or project will not go, then thresholds represent the degree of variability that’s
accepted prior to reaching that point. It’s also a point at which involved parties are expected to
change behaviors.
A railroad might deem that it will not tolerate any deaths at railroad crossings. The thresholds
associated with such a situation might be hit when a train is a half mile away. Any person
crossing the tracks when a train is that close is likely crossing a threshold.
Most drivers can’t spot a locomotive 2,500 feet down the tracks. That doesn’t change the nature
of the threshold. It’s what the rail company has determined is a reasonable safety threshold. The
2,500-foot mark illustrates what the railroad deems is a degree of variability that should prompt a
shift in behavior.
Triggers
To alert project stakeholders that a threshold is being breached, triggers might need to be
identified. For the rail example, the trigger can come in a variety of forms, some more effective
than others. On a rural road with very light vehicular and rail traffic, a simple white “Railroad
Crossing” sign may be the indicator that trains might be coming, and drivers should be on a
higher level of alert. In more urban environments, the simple white sign might be supplanted
with red flashing lights and barrier gates. These triggers turn on only when the train is a specified
distance away, indicating the threat is imminent. Both, however, are considered triggers because
they indicate that a threshold has been hit.
Some individuals have difficulty discerning the distinction between thresholds and triggers. A
threshold is a theoretical range that is determined as being of concern related to the potential
impact or influence of a risk event. A trigger, by contrast, is a physical or visible manifestation
that a threshold has been breached, and a tolerance is at hand.
Recognizing and Resolving Cultural Discord
Risk management approaches can be very personal. One person’s threat is another’s opportunity.
As a result, there is inherent discord. Team members who are risk averse have a very small risk
appetite and may not be willing to accept any meaningful risks on the project. Team members
who are risk prone (also considered as risk willing and risk seeking) see projects as an
opportunity to strike out on new work with new approaches and opportunities. The project
manager and/or risk manager take on the role of mediator when such friction asserts itself.
While the ultimate goal might be to achieve conflict resolution, there are also situations where
conflict management without resolution becomes optimal.
The different approaches to conflict management include:
Problem solving (Confrontation): Considered the ideal approach to conflict resolution

because it resolves conflict through creative solutions generated by all parties involved. Risk
managers applying confrontation will look at risk appetites as problems to be solved and
challenges to be overcome through innovation. This is considered the ideal win-win solution
to conflict because everyone gets a positive outcome as their risk appetites are considered.
Collaboration: A close cousin to confrontation, but the difference is that innovation is not as
highly prized. By working together, all parties heed the needs of other parties, seeking to
identify areas of agreement.
Compromise: Compromise on risk appetites suggests that all parties will get some of what
they want, but not all. All parties in a compromise conflict resolution will get part of their
perspective respected, but not all. This is a win-some/lose-some scenario.
Forcing: Forcing is the least desirable conflict resolution strategy and indicates a situation
where one party’s risk appetite will be used to evaluate all risk situations. It is normally
reserved for situations involving legal or ethical obligations. This is the win-lose scenario.
Withdrawal (also known as avoidance): Applied by simply avoiding the subject altogether.
Inevitably, there are situations where people with different risk perspectives (risk prone versus
risk averse) cannot agree, and continuing the conversation at a given point in time can lead to
hostility. While hiding from the conflict will never resolve it, putting the risk appetite
conversation on hold can afford time for cooler attitudes to prevail.
Smoothing (also known as accommodation): Affords the parties involved an opportunity to
see where and how they have commonalities with those with different risk perspectives.
Having a discussion about a sporting event or the weather are two examples of smoothing.
Neither likely has anything to do with the individual’s risk appetites, but they do grant all the
parties a chance to see the other as sharing some common values.
Whereas confrontation, collaboration, compromise, and forcing resolve risk conflicts,

withdrawal and smoothing actually manage the conflicts without bringing them to resolution.
The conflict management (with resolution) comes from improving the two sides’ abilities to
move back toward resolution.
When examining discord from a whole-team perspective, one critical document is the team
charter. When considering risk as a project team, the project manager and/or risk manager needs
to minimize conflict through consistent behaviors. As with any project team, efforts to normalize
conduct become important. This can be established through a team charter.
This document has nothing to do with the project charter. The team charter is a document that
captures the behavioral norms for the team. It documents everything from team language to
meeting conduct. It serves as a guidepost for what is “normal” and what’s not. The team charter
is developed by the team, normally as one of the earliest acts in the project. Such guidance
should be in place and rigidly followed from the first days. Rather than responding to situations
ad hoc, project managers can refer to the team charter to dictate how team members will interact
and share responsibility for project risks and risk management.
found.
Key Topic
Description Page
Elements
Section Risk Absorption 43
Section Organizational and Project Risk Tolerance 44
Section Project Risk Tolerance 45
Section Thresholds 45
Section Triggers 46
List The four approaches to conflict resolution and the two additional 46
approaches to conflict management
Paragraph The application of the team charter to establish team norms 47
risk absorption
organizational tolerance
project tolerance
thresholds
triggers
problem-solving (confrontation)
collaboration
compromise
forcing
withdrawal (avoidance)
smoothing (accommodation)
team charter
Review Questions
Two of your team members, Serena and Yvonne, are on opposite ends of the spectrum. Serena
believes in the motto of Take Chances and Make Mistakes, whereas Yvonne is much more in the
camp of Get It Right the First Time. Up until now, it hasn’t caused many problems, but in the last
two meetings, the two have almost come to blows. Serena believes the organization should try an
innovative technical solution that could speed the project up or could shut the project down
altogether. Yvonne wants to stick with a tried, true, slow solution. You want them to derive a
solution they both approve. From a conflict management perspective, the best approach would be
what?
1. Forcing
2. Confrontation
3. Compromise
4. Withdrawal
5. Smoothing
As you drive down the road, you worry about the steep cliff beyond the berm. It looks perilous.
You try not to focus on it, but it’s there and unnerving. You continue down the road and feel the
vibration of a set of rumble strips under your tires. The rumble strips are designed to serve in
what risk capacity?
1. Project tolerance
2. Threshold
3. Trigger
4. Alarm
5. Organizational tolerance
Your organization is conducting work in an abandoned salt mine in Romania. The project is
heavily insured, even though the probability of cave-ins is minimal. The billion-dollar insurance
policy for the project has a $1,000,000 deductible. The million dollars represents what?
1. The amount of risk your organization believes it can absorb

2. The amount of risk your organization can tolerate
3. The amount of risk your organization will manage until changing behaviors
4. The risk aversion of your organization
5. The risk readiness of your organization
Yours is a small project in a multi-billion-dollar enterprise. The organization last year suffered a
malware attack that cost it $4.5 million. Your project is worth less than half-a-million dollars.
Last year’s attack put the organization on high alert for phishing scams and denial-of-service
attacks. Any team member not reporting such computer incidents became subject to termination
for cause. You warn your team members that Internet safety is not optional. It’s mandatory. You
are advising them regarding what aspect of risk?
1. Organizational tolerance
2. Project tolerance
3. Organizational triggers
4. Project triggers
5. Personal responsibility
Your team members have a reputation for being somewhat gruff in their encounters with
customers and others in the “outside world.” The team members don’t feel a need for social
niceties in their day-to-day work encounters. As one team member put it, We have plenty of dirt
under our fingernails because we’re the ones who do the work. While you acknowledge that
socialization is not their strong suit, you need them to understand that the “outside world” is
what pays the bills. One team member in particular, Ivan, is your greatest challenge in this
regard. To ensure that the entire team, including Ivan, is appropriately tactful, the best approach
is to take what action?
1. Terminate Ivan.
2. Have one-on-one conversations with each team member, expressing your concern.
3. Announce your concern at the beginning of every team meeting.
4. Build the behaviors you want them to exhibit into the team charter.
5. Have your management come in and explain how important polish and tact are in a customer
setting.
Chapter 4
Strategic Risk

Risk Process Tools
Risk Alliances
The PMI-RMP® exam seeks to ensure that project managers and risk managers take a large-view
perspective on risk management. As such, risk management takes on an advocacy role for the
organization’s mission and vision. Risk management should support that vision, and each
element of the vision becomes a benchmark for whether tolerances have been properly set, and
whether risk responses are appropriate.
For every aspect of risk management, from the macro to the micro view, the question should be
asked: Does this support our strategy? Although most strategic considerations are at the
organizational level, projects have strategies as well. Like the organizational strategy, the project
strategy should serve as a guidepost for risk tolerance and response.
Strategy comes into play when defining and implementing risk processes, as well as in the tools
selection to support those processes. Risk sources can, in some cases, be defined or modified
based on strategic considerations. By aligning the processes with the strategies, project managers
can build relationships with other stakeholders who must also work from a strategic viewpoint.
This all focuses on the need to already have strategic approaches in place to manage risk
effectively. The assumption is that organizations will not have to backtrack to generate strategy.
The strategy will be well established at the enterprise level and will be documented and ready for
application at the project level.
This chapter examines the relationship between strategy and risk. It also drives to the project
manager’s (or risk manager’s) roles in executing the best practices to assess the project strategy
for the risks those strategies may create or eliminate.
Throughout the risk process of identification, analysis, response, and implementation, these
strategic considerations may evolve. It is incumbent on the effective risk manager to document
and communicate any such evolution to the relevant stakeholders.

#
Risk Strategy and Task Establish Risk Management Strategy in the

Planning 4 Introduction
Risk Process Alignment 1, 2
Risk Process Tools 3, 4

Risk Sources and Their Roles 5, 6
Risk Alliances 7, 8
Caution
Part of your organization’s vision statement says the organization will be “Among the Top Ten
Best Companies to Work for as Reported by Worker Magazine.” Many team members have
never seen the vision statement or know what it contains. As the project and risk manager for this
effort, how can you best align your risk approach and process to that aspect of the vision?
1. Communicate the vision statement to the team as you engage in the risk process.
2. Create risk responses that engage more team members.
3. Involve as many stakeholders as possible in the risk identification process.
4. Document clear links between the vision statement and the risk approach in the risk
management plan, ensuring high visibility of the connections.
Your enterprise has a rather risk-averse posture, unwilling to take any risks that jeopardize the
corporate image. They strongly believe that image drives every other aspect of the business. As
the risk manager, you are responsible for maintaining that perspective. In selecting risk tools,
what should you look for?
1. Those that do the best job of quantifying critical risks in priority order
2. Those that can account for qualitative, as well as quantitative perspectives
3. Those that are familiar to most members of the team and stakeholders
4. Tools that take into account organizational history
Your project office does a great job of generating forms, templates, and documentation support.
This is true not only for project management in general, but also for risk management
specifically. You’re very grateful for this behavior. Why?
1. It will save you both time and effort in that you will not have to create the documentation
frameworks yourself.
2. Your team members and stakeholders will be looking at documents in forms and formats they
have seen before.
3. You will be able to compare and contrast information from other projects, including those in
the archive.
4. Because it takes a lot of time to fill out the forms.
You are selecting tools to deploy in your risk processes. As you go through this effort, your
primary consideration should be what?
1. The tools’ capacity to provide answers you want

2. The tools’ ease of use for anyone on the project team
3. The tools’ availability across the organization
4. The tools’ alignment with the organization and culture, as well as their ability to produce
outcomes of value
Your organization relies heavily on the risk breakdown structure (RBS) to ensure consistency in
risk identification and evaluation. What’s the breakdown organization for the RBS?
1. Risk sources.
2. It is project-dependent, based on a shared understanding of what matters most to the
organization.
3. It is organizationally dependent, based on a shared understanding of what matters most to the
organization.
4. The human resource organization chart.
Which of the following statements is true about risk sources?
1. They are consistent across all projects.

2. The best risk sources are those that everyone concurs about.
3. Risk sources are inherently binary.
4. All risks have at least one source.
Every time you say the word “risk,” one of your team members (Bob) winces. The more you talk
with Bob about it, the more you come to realize that it’s not the risks that cause him worry. He’s
primarily worried about formatting the risk reports and putting documentation in the wrong
place. As the project leader, what’s your best approach for dealing with Bob’s concern?
1. Tell him that everyone has to deal with the same concerns, so he’ll be fine.
2. Give him templates from other projects that are already completed, so he has sample
formatting.
3. Walk him through the process one more time.
4. Volunteer to either format his reports or check his formatting.
You’ve been invited to speak at a departmental “all-hands” meeting. Your boss asked you to
speak about the strategic perspective you’re taking on your project for risk management. The
enterprise strategy is not something you really embrace. What are you responsible for doing at
this meeting?
1. Reiterate corporate policy

2. Lead others to adopt the enterprise strategy
3. Lead others to adopt your perspective on the enterprise strategy
4. Lead others to adopt your project risk management strategy
Foundation Topics

Process dominates in risk management. Risk management becomes more authoritative and
powerful when risk processes are aligned with organizational strategy and vice versa. At the
simplest level, the risk processes, as outlined by PMI®, include risk management planning, risk
identification, risk analysis (qualitative and quantitative), response development, response
implementation, and response control. For each of these, there should be a direct alignment with
how the organization does business and what is deemed acceptable and what is not.
Risk Management Planning
This is perhaps the single dominant process step tied to process alignment between the project
and the enterprise. The risk management plan (RMP) is the document that captures the risk
approach to be applied throughout the project, as well as the risk language and cultural norms.
The RMP explains how all the other process steps will be carried out. Terms like “high risk” are
defined here, as are any qualitative values to be used for probability and/or impact. It clarifies the
roles and responsibilities of all the stakeholders in each step of the process and establishes the
relative timing for any risk reviews or audits.
Risk Identification
This step in the risk process is frequently misunderstood. High-quality risk identification
involves identifying not only the event that might happen to influence project objectives, but also
the impact of that event (e.g., We may lose Alfonse from the project team, causing rework on the
crucial web development component). Without an impact statement, the risk manager is left with
a question of “so what?” when it comes to why a particular future phenomenon should be
included in the risk register. As most enterprise strategies emphasize their personnel, process
alignment with risk identification should feature the broadest number of stakeholders possible.
Risk Analysis
Risk analysis examines the probability and impact of risks and the cumulative effect thereof.
This is perhaps the single dominant process step tied to process alignment between the project
and the enterprise. The risk management plan (RMP) is the document that captures the risk
approach to be applied and how analyses (both qualitative and quantitative) will be conducted.
Qualitative Analysis
Organizational strategy is strongly reflected in qualitative analyses. This is where project

managers set the definitions for high, medium, and low for probability and impact. The impact
terms reflect both strategy and tolerance. For impact, a high impact can be expressed by
providing examples or commonly understood statements. A high impact might be expressed as a
“showstopper” in an organization where project termination is acknowledged as the worst kind
of failure. In an organization without such an attitude, a high-impact risk might generate a
completely different impression. With qualitative analysis for probability, there is a greater
opportunity for enterprisewide consistency. Rather than numbers, qualitative probability is
expressed as a likelihood in context. An example that might be captured in a RMP might appear
as it does in Table 4-2.
Table 4-2 Probability Definitions for an RMP
Probability Description
High More likely than not
Medium/Moderate Between High and Low
Low Have only seen it happen here once or twice
Remote Never happened here, but hypothetically, it could
Again, as with impact, these might vary from project to project, although the variability is less
pronounced in probability because those descriptions may apply to more than a single project.
For both probability and impact, the terms can be converted into numeric values, such as a
High=3, Medium=2, and Low=1 scale. This is discussed later in Chapter 11, “Risk
Qualification.”
Quantitative Analysis
Quantitative analysis processes are also established in the RMP. This includes the tools (to be
described later in this chapter) and the data-gathering approaches. Quantitative analysis differs
from qualitative in that the data sets developed for quantitative analysis are numeric, driven by
actual project values (e.g., time, cost), rather than numerically assigned (as is the case in some
qualitative analyses). The numbers-driven approach is more objective, but it is also more time-
consuming. Given that quantitative reviews produce ranges of numbers reflecting cost, schedule,
and other values, the RMP should dictate the acceptable numeric ranges (thresholds) and the
points beyond what an organization can accept (tolerances).
Risk Response Development
After risks are analyzed for their relative impact and likelihood, those that have the greatest
potential influence on the project will be evaluated for risk responses. Chapter 14, “Response
Planning,” discusses these responses in greater depth. From a strategic perspective, these
responses should mirror organizational and project tolerance by either bringing risks within (or
below) the thresholds or by acknowledging their existence and taking no action proactively.
The choice is made strategically by evaluating tolerances, examining responses, and ensuring the
responses serve enterprise and project risk strategies.
Risk Response Implementation and Control
After the response is determined, the risk owner’s role becomes all important. The risk owner is
responsible for safeguarding the implementation of the response and tracking its efficacy.
Discussed in depth in Chapter 15, “Response Implementation,” this is also the point at which risk
responses are reevaluated to determine whether they generate new risks that otherwise would not
have been encountered. The risk owner needs to capture whether “the cure is worse than the
disease.”
The risk management planning, risk identification, and risk analysis processes described in the
preceding sections are iterative. Risk processes are never a one-time, one-size-fits-all
arrangement. They need to be revisited to reflect the current project climate and the enterprise
environment.
Risk Process Tools
Tools exist for each step in the process. These risk process tools are discussed in depth with each
process chapter in this text. The tools can be found in the related chapter as outlined in Table 4-3.
Table 4-3 Process Step Locations
Process Step Location of detailed information
Risk Planning Chapter 5
Risk Identification Chapters 7, 8, 9, 10
Risk Analysis Chapters 11, 12, 13
Risk Response Development Chapter 14
Risk Response Implementation and Control Chapter 15

In looking at tools from a strategic perspective, tools need to be a good organizational fit. Tools
that involve extensive team interaction, for example, will likely not work well in an enterprise
that values information compartmentalization and data security. For exam questions that ask
about the propriety of tools in a specific setting, accept any answers that resonate with how you
would apply the tools in a common workplace setting. Tools should be aligned with their proper
processes. Tools should mirror the culture. Tools should be applied within the organizational
tolerances.
Tools need to be deployed consistently. Whether the tool is a software package or a simple
Microsoft Excel template, it should have the same look and feel across the enterprise. This
encourages cross-project evaluations of risk. It also affirms that project managers will know what
to expect in terms of risk reporting from one project to the next. For risk process tools,
consistency is paramount, because consistency ensures that similar data sets are available for
review and comparison from one project to the next.
All risk has at least one source. A risk source is the driver of the risk. It is a condition that allows
certain risks to evolve. On a vacation, for example, the family might want to take a flight to
Hawaii. If there’s only one flight and it leaves at 10:00 a.m., the schedule becomes a source of
risk. Schedule pressures are, indeed, often sources of risks. By booking a backup flight for the
following day, we can mitigate the one risk. By choosing an airline with hourly flights to Hawaii,
we might eliminate the schedule risks altogether. That will minimize not only the “We’re late”
risk, but also the risks of mechanical delays, overbooked flights, and a host of other risks, all
with schedule as their source. By addressing risk at the source (schedule), risk managers have the
opportunity to ameliorate a variety of concerns.
Because there are a variety of risk sources, they can serve as categorization tools for risks
identified, or as a means to generate more expansive lists of risks. Rather than simply asking,
What are the risks…?, a set of risk categories allows for repetition of the question, source by
source. What are the schedule risks? What are the risks associated with politics?
This has led to the development of two tools associated with risk sources. One is PESTLE,
which is a standard set of classifications (sources) for risk:
Political
Economic
Social
Technological
Legal
Environmental
The PESTLE model serves as a jumping-off point for risk management. By having default
categories or sources, it’s easier to augment the list with other enterprise-specific, project-
specific, or culturally specific categories. Other similar prompt lists can also be used to begin an
in-depth discussion of risk sources and categories.
One tool heavily tested on the exam is the risk breakdown structure (RBS). The RBS is a
breakdown of risks for a project, sorted by risk sources. PMI’s default categories for an RBS are
Technical, Management, Commercial, and External. Each of these is further broken down into
subcategories until virtually all project risks can be assigned to one or more categories.
Using an RBS consistently across an enterprise ensures that the most common organizational
sources (and thus, many of the strategic sources) of risk are considered in every project.
Risk Alliances
Risk management presents an opportunity to lead. As with many aspects of project management
in the current culture, risk management conducted well is conducted under the banner of servant
leadership. This means that the leader takes on efforts that might otherwise be seen as
burdensome to enable others to do the “real” work associated with risk management. Although
this might fall under the umbrella of paperwork, such efforts do a great deal to support the notion
that team members participating in the risk processes are adding value to the project as a whole.
The effective risk manager is someone who not only manages risks but knows how to coach and
mentor team members to support the processes.
In the process of doing so, risk alliances are built.
Alliances evolve when there is a risk culture in place. Cultures evolve when risk terms and
terminology are used consistently. Cultures evolve when tools are consistently applied. Cultures
evolve when risk strategies are clear and well understood.
Alliances also evolve when the project manager and/or risk manager take ownership of the whole
of risk management. They become cheerleaders for the process and potential outcomes. Project
managers who see risk as one more administrative burden or as a depressing aspect of project
management miss the chance to build alliances via the risk management practice.

found.
Section Risk Process Alignment 57
Section Risk Process Tools 59
Section Risk Sources and Their Roles 60
Section Risk Alliances 61

risk process
risk management plan (RMP)
risk identification
qualitative analysis
quantitative analysis
risk process tools
risk source
PESTLE
servant leadership
risk alliance
Review Questions
Management has told you that they want to encourage everyone to become more involved in the
risk management process. Your best opportunity to make this happen is to do what?
1. Provide rigid instructions on how to apply the risk management process.

2. Support the risk owners by taking on the more administrative tasks they have to perform.
3. Go to every stakeholder and explain the risk management process.
4. Get the project team to include risk management processes in the team charter.
5. Get the customer involved in the risk management process.
In sequence, the risk management process is which of the following?
1. Identify, analyze, manage, develop responses, and implement responses.

2. Analyze, identify, manage, develop responses, and implement responses.
3. Manage, identify, analyze, develop responses, and implement responses.
4. Manage, analyze, identify, develop responses, and implement responses.
5. A project-dependent approach to clarifying which risks the managers truly need to worry
about.
From a risk management perspective, PESTLE represents what?
1. The sources of risk to allow for risk categorization

2. The risks on the project, sorted by their generic names
3. A heavy tool with a rounded end, used for crushing and grinding substances
4. The risk process steps by their more generic names
5. The foundation for a risk breakdown structure
One element you might find in a risk management plan would be which of the following?
1. A project-specific risk
2. An organizationally specific risk
3. A risk category
4. The definition of high probability
5. The outcome of a particular risk response
Which of the following steps in the process involves the development of plans to deal with the
probability and/or impact of individual risks, which may involve doing nothing?
1. Risk management planning

2. Risk identification
3. Risk analysis
4. Risk response development
5. Risk response implementation
The risk breakdown structure is a breakdown of risks. By what categorization are they broken
down?
1. It depends on the RBS

2. Risk owners
3. Risk responses
4. Project divisions
5. Risk sources
Chapter 5
The Risk Management Plan (RMP)

As any project begins, the risk management plan (RMP) should begin at the same time. The
RMP is one of the first documents that a project or risk manager generates, and it covers a wealth
of information about how the project should be managed from a risk perspective. A common
misunderstanding about the RMP is that the document lists all the project risks. It does not. It
should not list any of them, except for reference purposes. Its role in the process is to affirm how
risk will be managed and what the risk norms of the enterprise are.
As discussed in Chapter 4, “Strategic Risk,” the RMP echoes organizational risk strategy and is
approved by the project sponsor. It documents enterprise and stakeholder tolerances, as well as
their associated thresholds (and in some cases, triggers). The RMP serves primarily from the
macro view of the project, although some micro issues might also be addressed. For example, the
structure of risk statements and how risks will be tracked and reported will be incorporated in the
RMP (whereas the actual, individual risk statements will not).
In many organizations, there is a standard template for their RMPs, often owned by the project
management office (PMO). Although each RMP will be unique to the project, the layout of that
document should be consistent with other RMPs for other projects. Informational elements that
need to be included reflect organizational culture and strategy. If the organization is sufficiently
risk-mature, there could be an enterprise risk management office, which would ultimately own
the risk management plan template.
This chapter examines the structure and elements of a risk management plan. It also addresses
the project manager’s (or risk manager’s) roles in developing the document.
During the life of the project, some of these considerations may evolve. It is incumbent on the
effective risk manager to document and communicate any such evolution to the relevant
stakeholders.
Risk Strategy and Planning Task 5 Document the Risk Management Plan
The Three R’s: RAM, RACI, and RBS 1, 2
Risk Responsibility and Accountability 1, 2
Risk Communication Documentation 3, 4, 5

Risk Education and Training 6, 7
Caution
Stakeholders play a significant role in all steps of the risk process, whether they are employees of
the organization or not. How will your risk management plan ensure that engagement happens?
1. Assign specific roles to specific individuals to make sure they understand their participation
and their deliverables.
2. Assign specific risks to specific individuals to make sure they understand their participation
and their deliverables.
3. Spell out the risk processes that involve both inside and outside parties and encourage them to
select processes germane to their roles.
4. Spell out the risks that involve both inside and outside parties and encourage them to select
processes germane to their roles.
5. Create a RACI chart for the internal personnel and a RAM for all stakeholders, and distribute
them widely.
What’s wrong with the RACI chart displayed in the table that follows?
Process Responsible Accountable Consult Inform
Data Capture Chris Miguel Carl Janine

Archiving Chris, Janine Laura Carl Miko
Lexicon Maintenance Chris, Carl Laura, Carl Miko Janine
RMP Review and Update Chris Martin Miko Evelyn
1. Chris cannot be responsible for more than one process.

2. Accountability can be assigned to only one person per process.
3. Carl cannot be both responsible and accountable for the same process.
4. Laura cannot be accountable for more than one process.
5. Miko cannot have both consulting and informing roles.
The risk management plan integrates with the rest of the project plans. How?
1. The risk management plan leverages information from the other management plans to create a
master list of process areas and their risks.
2. As multiple stakeholders are involved in developing the RMP, natural integration occurs
through their experiences with different aspects of the project.
3. The risk management plan is one of a number of management plans that combine to form the
project management plan.
4. All the other plans draw on the risk management plan to inform their processes.
5. The risk management plan is overarching and thus integrates naturally with the other
management plans.
You always conduct a SWOT analysis to better understand your project environment from a risk
perspective. This process will manifest itself in the risk management plan. How?
1. The details of the strengths, weaknesses of the project and the opportunities and threats of the
organization will be spelled out in the RMP.
2. The strengths, weaknesses, opportunities, and threats of the project will be spelled out in the
RMP.
3. The strengths, weaknesses, opportunities, and threats of the organization will be spelled out in
the RMP.
4. The format for the SWOT and the appropriate application thereof will be spelled out in the
RMP.
5. The strengths and weaknesses of the organization and the opportunities and threats of the
project will be spelled out in the RMP.
Several paragraphs in your risk management plan explain the risk sources that will be used for
your risk breakdown structure. These are sources that are used consistently across the enterprise
to build out RBSs. As you evaluate them, you come to the realization that _____.
1. This is an important inclusion because the RMP is about the structure of risk processes and
how they’re done.
2. This is an important inclusion because the RMP needs to incorporate detail on risk sources.
3. This is an important inclusion because the RMP needs to incorporate them to fill out the RBS.
4. This is wrong because the RMP needs to be project specific, rather than reflecting the rest of
the enterprise.
5. This is wrong because the RMP needs to address specific risks.
For your project, who’s responsible for ensuring that proper risk management training is
conducted for the proper stakeholders?
1. The project/risk manager is responsible and accountable on all projects.

2. The project management office (PMO) is responsible and accountable across projects.
3. The project management office (PMO) with guidance from the project/risk manager is
responsible for ensuring that proper risk management training is conducted for the proper
stakeholders.
4. The project/risk manager, with guidance from the project management office (PMO), is
responsible for ensuring that proper risk management training is conducted for the proper
stakeholders.
5. Human Resources.
When it comes to the risk management plan (RMP), you wonder whether some of the
descriptions of tolerances and triggers might upset some team members. You fear that the
lexicon incorporated in the document might become a point of contention, thanks to the
ambiguity of some of the terms. Your best solution to this problem would be to do which of the
following?
1. Rewrite the lexicon in plain language.

2. Have the team rewrite the lexicon in plain language.
3. Leave the lexicon consistent with the rest of the organization and know that the stakeholders
will figure it out over time.
4. Rewrite the lexicon in plain language, knowing that the stakeholders will then be able to
figure it out.
5. Leave the lexicon consistent with the rest of the organization and host training sessions that
incorporate the terms generously.
Foundation Topics
The risk management plan is rooted in the notion of providing management guidance. It is less
about what work is being performed and more about how processes are ultimately going to be
managed. Roles and responsibilities for these processes need to be clearly delineated. The clearer
the understanding of what roles need to be filled, the easier it will be to minimize bias within the
process. Bias often asserts itself when roles are established ad hoc and when consistency doesn’t
exist across RMP approaches.
Consistency is much easier to achieve when the same documents exist within an enterprise to
identify the roles essential to carrying out risk management planning. Key among those
documents are
The responsibility assignment matrix
The responsibility/accountability/consultation/information grid
The risk breakdown structure
Responsibility Assignment Matrix (RAM)
The responsibility assignment matrix (RAM) in risk management is a simple list of the risk
processes to be implemented and the roles (or individuals) responsible for carrying them out.
Ideally, to make the RAM function more effectively, the responsibilities are assigned by role,
rather than individual names. Although individuals will fill those roles, the use of the role affords
the project the ability to absorb team member loss or organizational shifts more readily.
One of the major advantages of the RAM is its simplicity. It doesn’t require extensive education
to understand or interpret what the chart means. Table 5-2 provides an example of a simple
RAM.
Table 5-2 Risk Management Plan Responsibility Assignment Matrix
Process Martine Executive Project Product

Sponsor Manager Owner
Data Capture X
Archiving X
Lexicon X
Maintenance
Escalation X
Protocol
To apply the RAM, one needs to go no further than to identify the process and look for the “X.”
Note that the only named individual in the sample chart is Martine. If something should happen
to Martine, this document will have to be updated. For the other processes, if there are
organizational shifts, the roles become all important, rather than named individuals. When an
individual is critical to the process, the individual should be named.
For a risk manager, this document facilitates the assignment of process owners, making it easier
to track down responsible parties and get their help in serving those process steps.
RACI (Responsible Accountable Consult Inform) Chart
The RACI chart in risk management is an expansion of the traditional (simpler) RAM. For most
managers, the RACI is better known by its acronym than the words the acronym represents. In an
exam where most of the acronyms have been abolished, RACI remains. The major difference
between a RAM and a RACI is that the RACI has additional information regarding the other
participants in any risk process. In addition to responsibility (as found in a RAM), this chart also
identifies three other factors. The four factors found in a RACI each have a distinct meaning:
Responsibility: The role or person who will actually perform the process step
Accountability: The role or person who will be held liable for the success or failure of the
process step
Consult: The role or person who might be able to provide supplemental information about the
nuances of implementing the process step
Inform: The role or person who should be apprised of the progress or status of the process
step
As with the RAM, it doesn’t require extensive education to understand or interpret what the chart
means. Table 5-3 provides an example of a simple RACI chart.
Table 5-3 Risk Management Plan RACI Chart
Process Martine Executive Project Product

Sponsor Manager Owner
Data Capture R C A I
Archiving C I R, A I
Lexicon R, A C, I I
Maintenance
Escalation R, A C, I
Protocol
To apply the RACI, it’s important to understand that no process step can have more than one
accountable individual. Although there might be several roles working on a process, and even
more who need to be informed, only one person or role can ultimately be accountable for the
work.
The Risk Breakdown Structure
The name of the risk breakdown structure (RBS) is most appropriate when discussing it in the
context of the risk management plan. That’s because it’s a structure. It’s a framework into which
risks will ultimately be incorporated. It is not the risks themselves, but instead is the
decomposition of the source of risks as they are identified or about to be identified.
The sources of risks for an RBS may be generic (like the prompt list PESTLE) or enterprise
specific. They can go down several levels through decomposition. The risk management plan
documents this structure, because it might be applied and reapplied multiple times throughout the
life of a project.
In its lowest levels, the RBS can highlight some of the most pervasive risks faced by an
organization, and the set of sources at those low levels can ultimately become the foundation for
risk process checklists.
If the organization seeks to maintain consistency, ownership of the RBS might rest with the
project management office, at least at the higher levels of the structure. At the more detailed
levels, more project-specific risk sources might surface. Table 5-4 provides an example of a
simple RBS.
Table 5-4 Risk Management Plan Risk Breakdown Structure
Risk Breakdown Risk Breakdown Risk Breakdown

Structure Level 0 Structure Level 1 Structure Level 2
All Project Risk Sources Politics National political

movements
Community political
movements
Internal enterprise politics
Economics Market growth
Inflation
Taxation/tariffs
Social Media narratives
Social media presence
Community perceptions
Technological New tech
Obsolescence
Technological acceptance
Legal Lobbying
Lawsuits
Liability
Environmental Earth-based
Regional environment
The distinction between these two terms was discussed earlier in this chapter. But they merit an
extended discussion because it’s easy to misinterpret a question about responsibility as being
about accountability, and vice versa. As project managers, we need to know that our stakeholders
are also aware of the distinction, because, in many cases, they are the parties whom we try to
hold accountable for carrying out the risk processes.
Risk Responsibility in the Risk Management Plan
The term “risk responsibility” should be pervasive in the RMP. In using it, the project manager
is defining the level of effort required to carry out a particular process. The person who will take
on that effort should have some clarity on what their work is going to entail. Writing up a
responsibility assignment for building the risk lexicon may involve more responsibility than
some might consider. Take a look at the responsibilities associated with this process in Table 5-
5.
Table 5-5 Risk Management Plan Responsibility Description
Process Task Responsibilities
Lexicon Attend project meetings and capture risk commentary.

Development Document terms used and definitions thereof.
Validate new terms with project office or project manager.
Share information with project stakeholders.
Share information with project office for enterprise lexicon.
Lexicon Review entire lexicon on a timely basis (e.g., quarterly,

Maintenance semiannually).
Update terms only as appropriate.
Document updates and definitions thereof.
Share information with project stakeholders.
Share information with project office for enterprise lexicon.
Again, as with most aspects of the risk management plan, it’s easy to see how this information
could be applied in multiple projects and that it provides clarity and minimizes misunderstanding
about the nature of being responsible for a given subset of risk management.
Risk Accountability in the Risk Management Plan
The term risk accountability will be far less pervasive than “responsibility” in the RMP.
Accountability is defined as being held liable for the implementation and/or outcomes of a risk
approach. Someone who is accountable can be held to blame if anything goes wrong, and, on the
other hand, is the individual who should ultimately receive the credit when the risk process
functions as designed.
In many instances, the person who is accountable is also the person responsible for a given risk
or risk approach.
If the project was to create a documentary, the documentarian who developed the concept, the
approach, and the idea is likely the accountable individual. The editors, sound/audio staff, and
production personnel are responsible for realization of the idea. For a simple YouTube
documentary, all the roles can potentially fall to a single person.
Risk management is effective only when the information derived from it is shared liberally
across an enterprise. The documentation that supports risk management is extensive, including
charts already shared in this text, such as the responsibility assignment matrix, the RACI chart,
the risk breakdown structure, and the organizational risk lexicon. Each of these documents
provides a layer of depth that others do not. Each document highlights a different aspect of the
risk process, encouraging a deeper understanding of the risks, their sources, and their nature.
The single most significant document related to identifying and managing individual risks is the
risk register, discussed in depth in Chapter 7, “Practical, Team-Based Risk Identification.”
Although the approach to completing a risk register is discussed there, the framework for what it
should include is incorporated in the risk management plan. As a component of the risk archive,
the framework was examined in some depth in Chapter 1, “The Risk Structure.”
The key to any communication is clarity. The risk manager is responsible for clarifying terms,
phrases, and frameworks that are intended to convey the risk message.
For every piece of risk communication, there are critical elements. They include
The author
The timing for the original communication and any reviews/updates
The recipients
The communications modes
There are also distinctions in the nature of the content of the communication. PMI® makes that
distinction in the forms of data, information, and reports.
Data are raw facts, with no processing whatsoever. As such, it is the least biased of the
content areas. When the term is used, it suggests that no analysis has taken place and no
interpretation has transpired.
Information is data that has been processed in some way, shape, or form. Categories might
have been created or data affinities (natural groupings) might be applied. Although the bias in
information is limited, the simple act of sorting can be done under the umbrella of a particular
perspective. As such, information is more interpretive and can afford greater depth.
Reports represent information in a formalized package. Reports create a frame around the
information and can readily be skewed to afford the information a specific perspective. This is
where bias is most significant in communications.
The Author
All communications have a degree of bias. As soon as data are processed into information, the
processor’s bias comes into play. If that author catalogs all information according to risk sources
(as in the risk breakdown structure), then there’s a bias to examine risk sources. If the author
catalogs all information according to geographical region, a geographical bias can exist. The
author thus becomes the arbiter of bias, even when such bias is unintended.
The author is important to the process because this individual also serves as a kind of personal
archive. Many are the instances where risk information seekers will turn to the original authors
of the risks or the responses to determine assumptions and intent.
For many aspects of the risk process, a single bit of data could have multiple authors. When
that’s the case, all authors should be given credit for their role in the process. The varied
assumptions and intent may reflect that a single risk is actually multiple risks drawn from a
single data point.
The Timing
Communications timing can refer to when the information was originally documented or when
the information needs to be refreshed or reviewed. By way of example, the book Bartlett’s
Familiar Quotations was originally published in 1855. Since then, there have been 17
subsequent editions. The 14th edition, published in 1968, has eight quotes from the Reverend Dr.
Martin Luther King, Jr. In the next edition, the count goes to 12 quotes. The quotes were not
newer. They reflect the timing of the information capture and Dr. King’s perceived importance.
Timing matters. Post-9/11 risk lists will not look the same as any captured in the twentieth
century. Post-COVID risk lists will incorporate risks not seriously considered in the 2010s. The
timing of risk information becomes very important.
By acknowledging the shifting tides of information, and documenting when those tides might
shift again, the risk manager has a much richer data set with which to work.
The Recipients
In a sender–receiver communications model, there are filters on both ends of the model. The
sender filters information through language, gesture, and tone. The receiver does likewise. If the
recipients and their filters are not considered during information gathering or information
dissemination, the true intent of the messaging could be lost. If one identifies a driving risk as
“The bonnet might come loose, flying off at high speeds,” a failure to acknowledge the recipients
and their culture can lead to broad miscommunication. In the States, for example, that risk might
be seen as the loss of a woman’s hat. In the UK, it would be a reference to the hood over an
engine. The recipients are a vital element of the communication, and their geography, social
status, and culture will all play into an understanding of the message at hand.
Communications Modes
The clearest communications occur face to face. Per communications theorist Albert Mehrabian,
that’s the setting where it’s possible to get 100% of the communication across. Take away any
aspect of the communication, and some of the messaging will be lost. Mehrabian argues that
only 7% of the likeability of any communication is conveyed by the words alone. A phrase such
as, “Sure, I believe that,” can be said in serious or sarcastic tone. But as written, it’s impossible
to discern intent. Thus, risk information sharing is most clear when we have the opportunity to
go beyond the simple written word.
Mehrabian continues that another 38% of the likeability of messaging is conveyed through vocal
inflection and tone. A telephone call may not be the ideal means of sharing risk information, but
it’s definitely a major improvement over an email.
As for face to face? That’s the remaining 55%. This is a major consideration associated directly
with those in the Agile environment (which PMI is heavily invested in). A cornerstone of Agile
management practices is an event called a daily Scrum. The daily Scrum is a brief, heavily
structured meeting held each morning with all team members physically present. The meeting is
short. Each team member is asked the same three questions at every meeting:
What did you do yesterday?

What will you be doing today?
What’s standing in your way?
This structured data-gathering is crucial not only to Agile management but to risk management
within Agile. The third question regarding potential impediments is a clear risk question. In
many cases, this is a future-looking question, rather than a question about present states. As such,
that means the question will often capture risks identified since the previous day.
Although PMI does not expect you to be able to identify Mehrabian or his theories, they do
anticipate you will embrace the thinking behind his theories. You are also expected to know the
three questions of Agile management Scrum meetings and which of the three most closely aligns
with risk management practice.
For any questions in this area, understanding Mehrabian’s theories should suffice in coming up
with answers. Recognizing that pure words are limited in their ability to share insights is
important. Seeing body language and other paralinguals provides the richest communications
experience.
One other aspect of communications matters here. Because of the fluid nature of risk
management, consistency in documentation practice is vital. The forms and formats discussed
earlier in this chapter grant the project manager latitude to focus on the risk practice rather than
the library sciences.
The risk management plan will be used as a foundation for much of the risk education and
training for the project team. It also serves as the guide, detailing the nature of the education and
training and the desired outcomes. Risk training (like all project management training) should be
outcome based. The idea is for every training experience to create new behaviors and to support
the tools that enable those behaviors. There should be measures or metrics to evaluate how well
the new behaviors have been trained.
The risk education methods are delineated in the risk management plan so that all stakeholders
understand how knowledge will be transferred. Such methods may include classroom and virtual,
on-the-job training or theoretical, and real-time or scheduled.
As discussed in Chapter 2, “Risk Environment and Culture,” most knowledge transfer will
involve explicit knowledge (knowledge that can be expressed in a step-by-step fashion to be
applied consistently). Tacit knowledge transfer (knowledge transfer driven by a personal
understanding) is much harder to generate consistently and through traditional training methods.
Different stakeholders will require different levels of risk education, based on their level of
understanding and their degree of involvement in the project. The risk management plan should
clarify which stakeholders will receive which training. For the most part, it’s a function of their
level of project involvement. Consider the training requirements of the different echelons or
stakeholder groups within a project:
Senior management: Risk training for senior management involves sharing information
regarding escalation protocols. It also involves affirming that the identified organizational
tolerances, thresholds, and triggers represent management’s interests. Although management
might be interested in some of the task-level risks, that’s not where their time will be invested.
Instead, the focus is on risks that might require some level of management intervention or that
might draw excessive management attention. (Concepts like “excessive” management
attention are also addressed here, ensuring a common understanding of such adjectives).
Team members/Task performers: For team members and task performers, risk education
and training focuses on information sharing and common understanding of terms. Terms from
the risk lexicon (such as high, medium, and low risk) are clarified for these individuals so that
they can carry on the risk conversation in team meetings and with their peers. The education
also apprises these people as to the relative levels and priorities of risk, as well as how to
share risk information when it comes to their attention. They learn that risk statements are not
just one- or two-word risk areas (e.g., weather, resources), but instead are stated as full
sentences indicating the nature of the risk and the impact it might cause should it come to
pass. Whereas senior management risk training might be a one-time experience, team member
risk training is ongoing. The frequency and duration of that training will be expressed in the
RMP, as well.
Vendors: First and foremost, vendors need to know that they have a role in a project’s risk
management. Because they understand their deliverables better than anyone else, they have a
clearer understanding of any risks associated with those deliverables. The training is not an
opportunity for them to abrogate responsibility for their risks, but it is an opportunity for them
to see the relative scale of the risks their deliverables create within the context of the project.
Another value of the training is for vendors to better understand how risks affect other
stakeholders with whom they’ll be working.
Customer stakeholders: Customers actually have the best project risk information at their
disposal. Because most of them own the project outcomes, they understand the challenges and
the opportunities associated with working in their environment. The educational setting opens
the door to define and refine which parties own which aspects of the relationship. It also
ensures a common language across the various parties.
Other/peripheral stakeholders: As with the customer, much of the education for other
stakeholders will center around the language of risk on the project. It will also hinge on the
risk priorities, tolerances, and thresholds. Some peripheral stakeholders (local civic activists,
for example) might need to know that they are responsible for identifying their own tolerances
and for expressing those tolerances to the project owners. The art of such information sharing
can be one of the many goals of a risk education experience.
For all the potential training participants, the goals are largely the same. They need to be taught
to understand the process of risk information sharing. They need to be educated on the forms and
formats for sharing that data. They need to learn the risk language. And they need to know their
role and the value of that role in the process as a whole.
the page. Table 5-7 lists the key topics and the page numbers on which each is found.
Key Description Page

Topic Number
Element
List Three essential tools to apply in managing project risk 72
Section Responsibility Assignment Matrix (RAM) 72
Section RACI (Responsible Accountable Consult Inform) Chart 73
Section The Risk Breakdown Structure 74
Section Risk Responsibility in the Risk Management Plan 75
Section Risk Communication Documentation 77
List When working with risk information and communication, it’s 77

important to distinguish among data, information, and reports
Section Risk Education and Training 80
responsibility assignment matrix (RAM)
RACI chart
risk breakdown structure (RBS)
risk responsibility
risk accountability
risk register
data
information
reports
daily Scrum
explicit knowledge
tacit knowledge
Review Questions
Your project is being conducted using an Agile methodology. Specifically, you’re applying the
Scrum method. Some of the best risk information in this environment will come from what
source?
1. The customer, who understands the most about their environment

2. The team members, during regular weekly meetings and updates
3. You, with project oversight
4. The team members, during brief daily meetings
5. Your management, during weekly meetings and updates
In a RACI chart, two of your team members are marked as “A.”
1. That means there are two parties who will be accountable.

2. That means there are two parties who will be advised on the state of the project.
3. That means there are two team members sharing responsibility for the risk and/or its response.
4. That means two team members will consult on the risk and/or its response.
5. That means someone made a mistake, because you can have only one person accountable for
a risk and/or its response.
A risk breakdown structure (RBS) is a breakdown of what information?

1. It’s a breakdown of risk responses, according to their owners.
2. It’s a breakdown of risks, according to their sources.
3. It’s a breakdown of risk processes, according to their owners.
4. It’s a breakdown of risks, according to the work with which they’re associated.
5. The name is technically a misnomer because it really doesn’t break down anything.
Which of the following statements regarding data, information, and reports is true?
1. Data, information, and reports are three names for the same thing.
2. Data have the most inherent bias, whereas reports have the least.
3. Reports have the most inherent bias, whereas data has the least.
4. Data are filtered.
5. Information is unfiltered.
You and your project team want to have the best possible risk communication. This will likely
happen using which of the following communications modes?
1. Face-to-face meetings
2. Virtual meetings
3. Teleconferences
4. Email
5. Risk registers
Which is the most important risk question in a Scrum setting?
1. What are you doing today?

2. What’s going wrong on your tasks?
3. What did you do yesterday?
4. Who is managing your risk?
5. What’s standing in your way?
Chapter 6
Connecting Others in Risk

Rules of Engagement
Risk is a team sport. All good risk practice involves multiple stakeholders with a variety of
perspectives. The more perspectives that an organization has on risk, the more it is truly risk
capable. The reasoning here is not that we need more participants in the process. Instead, it’s that
enterprises fare better when they have multiple viewpoints to bring to bear on the questions of
“What are the risks?” and “What should we do about the risks that seem most significant?”
To get answers to those questions, project managers need to draw in as many stakeholders as
reasonable through as many processes as reasonable.
This chapter examines the roles of teams in the risk process and the project manager’s
responsibility to identify and exploit those roles.

#
Risk Strategy and Task Plan and Lead Risk Management Activities with
Planning 6 Stakeholders

Stakeholders and Their Roles 1, 2
Team Engagement in Appetites, Attitudes, and Priorities 3
Rules of Engagement 4, 6
Risk Education Beyond the Strategic 5
Caution
Your new team has been together for only a week, and yet you are impressed by the way in
which they work together. They don’t seem to shy away from sharing risk information, and they
genuinely seem to enjoy each other’s company at all of your risk meetings. Per Tuckman’s
Ladder of Group Development, your team is at which stage?
1. Forming
2. Storming
3. Norming
4. Performing
5. Adjourning
In a customer–supplier relationship where you are the supplier, who has the best information on
risks within the project environment?
1. The project sponsor

2. The customer
4. The individual team members
5. The end user
Marlene seems to be willing to take on any challenge and deal with any daring, risky activity on
the project. She tries to get others to go along, even when they point out that the organization
would not approve. She flirts with health and safety regulations, blaming them for slowing her
down. If everyone would follow her lead, she points out, the entire project could be done in half
the time, and because the project is running late, her advice has appeal. How should you handle
Marlene’s situation?
1. Let her take the lead on much of your risk implementation, because she will expedite the
project.
2. In a one-on-one meeting with Marlene, point out the need for total compliance on the project,
even if it means making the project even later.
3. In a regular group risk meeting, point out the need for total compliance on the project, even if
it means making the project even later.
4. Have Marlene identify those aspects of the project that are causing delays and investigate
ways to circumvent compliance.
5. Kill the project.
You have regular risk meetings with the team, but most of them are virtual. You use a variety of
technologies and platforms, all with the approval of your network administrator. A new team
member, Ace, just joined the group, but because of their remote location has trouble with any
communication that requires something besides a smartphone. Because of this new limitation,
what should you do?
1. Get a new platform that will enable smartphone use.

2. Improve the technology capability on the new team member’s end.
3. Move all your team members to smartphones for the meetings.
4. Ensure one of the existing platforms you’ll be using is smartphone compliant and still meets
the other requirements of the environment.
5. Move to all in-person meetings.
Your enterprise ran an advertising campaign a few years ago with big posters proclaiming:
DON’T RISK IT! Each had an image representing some pretty horrific episodes where personnel
were either killed or seriously injured. At a meeting recently, you were sharing a safety message
and said, “And let’s all remember those three little words the company won’t let us forget!”
Everyone in the room, in unison, shouted back “Don’t Risk It!” You’re stunned. You thought
you were the only one so affected by the campaign. It made a powerful impression on you. It
makes what important point about risk education?
1. Consistent, repetitive messaging can often ingrain messages (if not behaviors) in members of
an organization.
2. Powerful, even gruesome, images drive messages home.
3. Company support for the risk message is the key to getting a message across.
4. Narrow risk messaging gets a singular message across well.
5. Broad risk messaging gets a singular message across well.
You have advised your risk team that they will adhere to the same basic protocols for meetings,
behavior, and professional conduct as the project team. What is the best document for all of you
to reference?
1. The project charter

2. The Project Management Office (PMO) guidance
3. The Enterprise Office guidance
4. The team charter
5. The human resources staff guidance
Foundation Topics
Risk is pervasive. It manifests itself at the strategic, portfolio, program, and project levels.
Although there might be some crossover, each of those levels is rich in stakeholders. These are
individuals who are either positively or negatively influenced by or have a positive or negative
influence on the work being performed. Although organizational team members and customers
are the most obvious stakeholders, the other players are legion.
Just as there are a host of different stakeholders and stakeholder types, they can be sorted into an
almost infinite number of categories. Using salience models, as discussed in Chapter 4,
“Strategic Risk,” project managers and risk managers can evaluate the relative influence of these
people. Stakeholders have roles in each step in the risk process:
Risk management planning: Here, beyond any specific role in developing the RMP,
stakeholders review the key elements of the plan itself. They evaluate the risk lexicon, the
thresholds, the tolerances, and the processes to ensure that they are capable of carrying them out.
If the stakeholders don’t have an active performance role here, they may review just to ensure
that the deliverables from the RMP processes will be useful or meaningful.
Risk identification: This is perhaps the most important role for stakeholders, in that each person
has a unique perspective on what risks may manifest themselves in the life of the project.
Personal experience plays heavily here, because stakeholders’ past sufferings or joys can draw
out risks that would otherwise not be readily seen by others. How the risk statements are
formatted should be established in Step 1, and then implemented here.
Risk qualification: As with risk identification, individual perspectives come into play here.
What one person perceives as a high-impact, moderate-probability risk could be seen as a low-
probability, low-impact risk by someone else. Although this should be dealt with in the risk
management plan (through the risk lexicon), individual perception still plays a role. As different
stakeholders offer different opinions, it becomes important to validate the assumptions that drive
them to their conclusions and to document those assumptions.
Risk quantification: Perhaps the most important stakeholders at this stage of the process are
those with a mathematical or statistical bent. Stakeholders with no quantitative background can
be overwhelmed by the statistical leanings of risk quantification. The language alone can be
overpowering. Add to that the surprisingly interpretive nature of the math outputs, and risk
quantification can become a hunting ground for stakeholders who get the “deer-in-the-
headlights” look when it comes to the risk numbers. The stakeholders who understand and can
share statistical information well are invaluable at this stage of the risk process. It should be
noted that in some projects, quantification is not conducted at all.
Risk response development: As a creative endeavor, response development creates an

opportunity to cultivate new ideas and new approaches to mitigate, accept, transfer, or escalate
risks. As with risk identification, response development flourishes with more stakeholder
involvement. More stakeholders? More approaches to respond.
Risk response implementation: Response implementation again relies on a broad range of

different stakeholders to succeed. Here, however, they should be clearly identified risk owners,
with narrow and specific responsibilities mapped out in the responsibility assignment matrix
(RAM), discussed in Chapter 5, “The Risk Management Plan (RMP).”
Monitor and control risks: The more watchful eyes on a risk or set of risks, the higher the
probability that any variations in probability or impact will be readily identified. Stakeholders
represent those sets of watchful eyes and play an important role in alerting the risk and/or project
managers to those variations.
Strategic Risk and the Stakeholders
Beyond the process itself, stakeholders also have roles in influencing which risks the
organization can or should be concerned about. Stakeholders who have lived along riverfronts
can see flood possibilities with every significant rainfall. Those who survived the Mount Saint
Helens disaster perceive risks associated with volcanic activity. Those who have suffered
nonpayment by customers might see their accounts receivable as a pervasive problem.
Stakeholders bring such personal biases with them to the risk table. Their responsibility, and the
responsibility of the risk/project manager, is to make sure that these large-scale overarching risk
areas are addressed but not overemphasized.
Project managers will have, theoretically, conducted a team engagement evaluation prior to
diving deeply into the risk processes. They will have determined who is (as discussed in Chapter
4) unaware, resistant, neutral, supportive, or leading. With that information in hand, risk
managers have a first step in team engagement already completed.
Nonetheless, risk managers need to understand where the team is in terms of group development.
Tuckman’s Model of Group Development (also known as Tuckman’s Ladder of Group
Development) is critical to understanding the natures of team behaviors as a project progresses.
The model features five primary (progressive) levels:
1. Forming
2. Storming
3. Norming
4. Performing
5. Adjourning
Forming
The forming stage occurs early as a group is identified as a team. It’s a time when team members
assume everyone is working in everyone else’s best interest and where all team members look to
paint their peers in the best possible light. Forming happens with every team when it first gets
together. Roles and responsibilities are assigned here, but not always embraced.
Storming
The storming stage is where team members assert their authority within certain aspects of the
project. Although they might not have the authority, they might assert it nonetheless. This can
lead to team conflict because multiple stakeholders may determine that they merit the same role.
Because team member conflict might escalate during storming, risk might also escalate as team
members fail to agree on their respective responsibilities.
Norming
The norming stage occurs when team members have determined and accepted their positions
within the group, and when they are able to function effectively within their roles. In a risk
setting, norming means that they have accepted the attitudes and appetites of their peers and have
an understanding of the risk absorption that different team members can handle. Conflict is
limited because team members are focused on their own perceptions of the risks and on the risk
responses for which they are responsible.
Performing
The performing stage happens as team members are willing to give and receive constructive
input in a helpful spirit. When it comes to the risk team, performing drives a clearer shared
understanding of the risks, the levels of acceptance, and the tolerances of other team members.
Performing opens the door for a shared understanding of risk and risk responses. Risk owners get
their greatest support during this stage of group development.
Adjourning
This is the only stage in Tuckman’s Ladder that involves grief or sadness. It is the point at which
the team is formally breaking up, and as such, in a risk team, this also should be a stage where
large volumes of information are captured and archived.
Team-Driven Data-Gathering Techniques
In all of these “rungs” on Tuckman’s Ladder, the project manager has an opportunity to gather
risk information from the team. Any team-driven data-gathering techniques can be applied, but
the most common for risk are
Brainstorming
Nominal group technique
Focus groups
Interviews
The Delphi technique
Meetings
Others will be discussed in Chapter 7, “Practical, Team-Based Risk Identification.”
Brainstorming
Brainstorming is a group meeting where the free flow of ideas is encouraged. It is ideal in team
settings where team members are open to the ideas of others and where team members can hold
back on any temptation to critique ideas as they are shared. Effective risk managers are aware of
the basic rules of a brainstorm:
No idea is a bad idea. All ideas are welcome.

Ideas are not criticized or evaluated until the brainstorm is complete.
Everyone has the opportunity, but not the obligation, to participate.
The brainstorm continues until all participants have shared all their ideas, no matter how long
it takes.
The brainstorm tends to reward the outspoken members of the team. Their ideas proliferate,
whereas the more reticent team members tend to have a lower level of engagement.
Although more commonly know by its abbreviation, NGT, nominal group technique will be on
the exam as its full name. Because the exam is international, abbreviations are largely avoided.
The nominal group technique is sometimes referred to as brainstorming on paper. Each
participant in the group is given a sheet of paper and a pen and proceeds to document their
master list of the response to the question at hand. That question might be What are the risks on
this project? or What approach makes the most sense to managing the most risks? Participants
get to write their responses for a prescribed amount of time.
The lists are then turned over to a facilitator who documents them for group consideration and
prioritization. NGT tends to work effectively in teams that have more individuals who are
reluctant to share in a group setting. It also creates a documentary trail through the process. The
major downside of the approach is that there are limited opportunities to discuss and evaluate the
outputs from the team members.
Focus Groups
Focus groups are small-group settings where individuals with an understanding of the question
at hand are brought together for a discussion on that question. This group can be representative
of the various factions within an organization or of the variety of stakeholders who will deal with
the project outcomes. The discussion is moderated to keep the focus group on task to deal with
the questions or concerns at hand. Because of its small-group nature, attendees in a focus group
are selected to be the voice of their respective stakeholder group. The downside of a focus group
is that certain representatives might be accidentally omitted from the group, limiting their voice
regarding risk on the project.
Interviews
A classic information-gathering technique, interviews provide a powerful means to gather large

volumes of information from individuals, rather than groups. Although this might not be seen as
a team development tool, interviews ensure that every interviewee has a voice in the risk
discussion. Interviews should be conducted in a nonthreatening setting, primarily with just the
interviewer and interviewee. Questions should be open-ended, rather than closed-ended. Open-
ended questions are those where the interviewee can expand on an idea. Closed-ended questions
are those with discrete yes/no answers. The former obviously offers a richer data set with which
to work.
The Delphi Technique
The Delphi technique has been heavily tested on both the Project Management Professional®
(PMP®) exam and the PMI-RMP® exam since their inception. The Delphi technique is a process
designed to both gather information and eliminate personal bias from risk discussions.
The Delphi technique is conducted by establishing the premise for the discussion and submitting
that premise to at least three anonymous experts in the field. Their identities are anonymous to
preclude bias based on professional recognition. The question is framed and delivered to each of
the experts, requesting their response. The responses are then collated, and the question is
reframed, coupled with the responses from all the experts in the process. This allows the other
experts to see the inputs of their peers without knowing who those peers are.
The second round is then reviewed and submitted to the facilitator, who collects the inputs and
again replies and reframes the question, sending all the data from the current version to all the
participants, who are given a last opportunity to add new ideas or to critique the ideas from the
earlier rounds.
The key to understanding the Delphi technique is that there are at least three experts and at least
three rounds of participation.
Meetings
Meetings are a key enabler of all the risk processes. The foundation of good meetings is that they
all have an agenda, are held only with the members present who need to be there, and that they
are time limited. All those qualities lead to better meetings, whether they are face-to-face or
virtual.
Face-to-Face Meetings
Face-to-face meetings afford the richest information exchange in that the words, the tone, and the
body language (paralinguals) all come into play. In building risk teams, these meetings allow for
a greater depth of understanding because they allow participants to put a face to a name. These
meetings engage all the senses and rely very little on technology. As such, technological
roadblocks are eliminated. Every facet of each team member’s personality and data sharing is
exposed, minimizing misunderstandings.
Virtual Meetings
Although virtual meetings (using Zoom®, Skype®, GoTo®, Webex®, or other technology) allow
meetings to be held at a distance, there are significant limitations. Meeting attendees must be
technologically capable, with a quality microphone and camera. Many such meetings are held
without cameras, limiting the level of interaction. Because the remote attendees are in a variety
of locations, they can sometimes be distracted by local activity at their site. In most face-to-face
meetings, a cat on a keyboard is not a very common sight. As a risk manager hosting such a
meeting, the ground rules established in the team charter become all the more important. And
issues such as varied time zones and local language/dialect also evolve.
Reconciling Meeting Conflict
A key responsibility of the risk manager or meeting facilitator is to ensure that nonproductive
conflict is kept to a minimum. This is best accomplished through the meeting ground rules. Even
with that guidance, there will still be occasions where unanticipated meeting conflicts arise.
Although conflicts are best resolved through open discussion, there are occasions where the
conflict prompts the team to stray from the original risk intent of the meeting. If that becomes the
case, the facilitator or manager must have already identified how such situations will be
managed. In many instances, a “parking lot” is established as a temporary repository for off-
agenda items that need further discussion at a later time. There should be a clear understanding
as to how and when parking lot items will be addressed. This kind of information would be
included in the team charter, as discussed in Chapter 3, “Tolerance, Thresholds, and Triggers.”
As with other conflicts, the ideal outcome involves problem solving—coming to a mutual
meeting of the minds on a creative solution to the conflict.
Rules of Engagement
While the ground rules represent a cornerstone in team engagement, the risk team needs to know
any other rules of engagement that they may have to follow. Specifically, these rules can apply to
the following:
Tolerances
Triggers
Escalation
Reporting
Information sharing
Tolerance Rules
Tolerances are the absolutes of risk management. They ultimately represent points beyond which
a project will not go. Oddly enough, even when tolerances are clearly identified, some team
members (because of their voracious risk appetites), will push beyond those boundaries. Thus, as
with speed limits in a car, team members need to be able to distinguish between thresholds and
tolerances and the implications of violating either.
Some drivers believe that the speed limits on certain roads are more of a suggestion than a rule.
They believe there’s a cushion of five to ten miles an hour between a legal violation and
detention by local authorities. If the speed limit is 55 miles per hour, the question becomes
“What’s the tolerance?”
For those who believe in the absolute rule of law, the answer is 55 mph. For some in a local
jurisdiction, they might believe they can proceed at up to 64 mph without being pulled over.
Even then, if they are pulled over by the authorities, their right to drive will likely continue
unimpeded. A driver in Nevada in a 65 mph zone was pulled over by the authorities for driving
125 mph. His Corvette was impounded, and he was charged with reckless driving and jailed. He
had clearly exceeded a tolerance.
In the Commonwealth of Virginia, the violation for exceeding the speed limit by 20 miles an
hour is not a speeding violation. It’s reckless driving. That limit is a clear tolerance with clear
repercussions. Virginia has clear tolerance rules.
In projects, such rules might be influenced by the cost of the project, the pressure of the deadline,
or the stringency of the quality requirements. The tolerance rules might be documented internally
in a project’s organization, or through the contract in a buyer–seller arrangement. The rules
might be as simple as citing any material breach (a breach of contract that renders the
deliverables unusable or significantly less usable) as beyond the contract tolerance. The
implications are that the contract could be rendered void.
Trigger Rules
Triggers are the physical and visible manifestations that a tolerance is nigh. As mentioned in
Chapter 3, they are the bells and lights and gates at the railroad crossing. As with tolerance rules,
the trigger rules should have clear dictates as to the repercussions of a failure to comply. The
difference here is that the trigger rules must be less punishing than the tolerance rules. The
challenge is that a violation of trigger rules can lead (very quickly) to a violation of tolerance
rules.
With the railroad example, there are situations every year where cars go around the crossing
gates to beat a slow-moving train. These are individuals violating trigger rules. In 2018, 99
drivers died in the United States when they went around the crossing gates. Had they beaten the
train, they likely would have only gotten a moving violation for their driving. That’s the
repercussion of violating a trigger rule. For those 99 people, however, the situation went from
noncompliance with a trigger rule to noncompliance with a tolerance rule, costing them their
lives.
In any case, trigger rules again emphasize the implications of noncompliance and need to be
clearly communicated to the team.
Escalation Rules
When do you tell management there might be a problem developing? When do you tell the
customer their deliverables are at risk? Those questions go to the heart of escalation rules. Done
ad hoc, such escalation policies are useless. Every team member in the perfect risk team will
know precisely when they need to report a shift in the probability or impact of a given risk event.
The guidance for escalating a risk to different management echelons should be a component of
the risk management plan. Those rules need to be in place to preclude individual team members
from making those decisions based on personal preference or bias. The escalation rules need to
incorporate the following:
Which risks go to which management levels

When risks go to the next management level
A clear understanding that when risks are escalated, they now belong to the higher
management level and are no longer under the team’s control
The last bullet is important. Per the Project Management Institute®, after a risk has been
escalated, the only time the original project team or risk team will actively participate in
managing that risk is if such action is directly requested by management. Otherwise, the
assumption is that management will take over the risk.
Reporting Rules
All risk reporting is done to a clear set of protocols. Those protocols are not violated, because
they cover virtually every possible contingency. Reporting rules establish when reports are
developed, who authors them, who contributes to them, and where/how they are archived. In
many instances, these rules will be put in place through a project management office,
maintaining alignment with other organizational reporting practice. This information is
ultimately memorialized for the project in the risk management plan.
Information–Sharing Rules
Intellectual property is, in many enterprises, the currency they have available to “spend” when
purveying their wares. Thus, rules for information sharing become vital in ensuring that team
members do not squander some of the organization’s most valuable assets. These rules captured
in the communications management plan dictate who can receive information and what
information can be shared with which individuals.
By way of example, the United States government has information sharing rules when it comes
to formal government documentation. Unclassified documentation has virtually no sensitivity
and can readily be shared with the public. “Confidential” information is information that could
have a direct impact on national security if released. “Secret” information is information where
that impact would be more serious. “Top Secret” applies to information where grave danger to
national security could occur when released.
Those classifications represent information sharing rules. To work in an environment where Top
Secret information can be disclosed, stakeholders must go through a clearance process and
follow the clearance rules for document and information management.
In business, it’s similar, in that stakeholders need to understand what information they can share
freely and what information represents meaningful intellectual property.
The greatest opportunity to engage stakeholders in the risk process is through training and
education. Whether the training is experiential or rote, education creates an opportunity to get all
the personnel to look at risk from similar perspectives and to understand how the enterprise
wants to manage its risk.
Oddly enough, this is not like strategic risk education, where the organization seeks to educate
on acceptable risk absorption and on management attitudes and appetites. This is mechanic’s
training. This is education on the risk principles and processes, as well as the other
considerations discussed earlier in this chapter.
This education might include guidance on how to properly complete a risk register or assign a
risk owner. It might explain why, how, when, and where risk information is archived, and the
nature of those archives.
Note
Information is archived for as long as is legally required, and no longer. When

documentation and history are no longer legal requirements, that documentation is
deleted or destroyed.
The education is also designed to empower the team. Empowerment stems from team members
sharing a clear understanding of the boundaries of their authority. During the educational
process, team members discover how far they are permitted to go in terms of implementing risk
responses and acting on risks.
One key to doing well on the exam is to perform repetitive spaced review sessions. Review this
found.

Topic Number
Element
Section Stakeholders and Their Roles 91
Paragraph In developing a project team, Tuckman’s Model of Group 93

Development should be considered. The level (or “rung” on
Tuckman’s Ladder) determines how teams will interact and how
supportive stakeholders will be of one another.
Section Brainstorming 94
Section The Delphi Technique 96
Section Meetings 96
Tuckman’s Model of Group Development
brainstorming
nominal group technique (NGT)
focus group
Delphi technique
meetings
Review Questions
You’re trying to achieve a consensus of experts, but know that they don’t get along well. In
working through this process with your risk team, what’s the best approach for gathering data
from these people?
1. Focus groups
2. Brainstorming
3. Meetings
4. The Delphi technique
5. The nominal group technique
Your team members are cooperative and able to get tasks done in a reasonable amount of time.
Each one has a clear understanding of their place in the team and works strictly on their
responsibility. They don’t jump over to others to lend a hand, but instead work on their tasks
alone. Where is this team in terms of Tuckman’s Model of Group Development?
1. Forming
2. Conforming
3. Storming
4. Norming
5. Performing
You are going to use brainstorming to gather risk data. What can you expect? (Pick two)
1. Team members will provide detailed analysis of their ideas as well as the ideas of their peers.
2. Team members will share ideas openly and freely until every last idea is exhausted.
3. Data gathered will be documented and then shared with the team as a whole.
4. The process will move quickly, drawing out a prioritized list of responses.
5. The process may take longer than anticipated, and some team members may dominate the
information sharing.
One of your team members identifies a major, previously undisclosed risk in the middle of your
latest meeting. The room is a hive of activity as the discussion intensifies. The team seems
energized by the discussion and you are anxious to learn more about the implications of the risk.
To deal with this new concern, what should you do?
1. Table the discussion until a future meeting when it can be put on the agenda and scheduled
into the discussion.
2. Remove items from the existing agenda to make room for the discussion.
3. Extend the existing agenda to make room for the discussion.
4. Let the discussion continue.
5. Ask the team what they would prefer to do.
Your organization is ardent about the use of nondisclosure agreements, particularly as they apply
to corporate policy. Everyone working on every project is required to sign such an agreement
and stick to it. In the middle of a risk meeting, your customer asks if you have thought about the
risks associated with travel on your project and the potential to lose team members because they
will be away from home for months at a time. Internal corporate policy in your organization
limits monthly travel in an effort to achieve work–life balance. There are specific rules in place
for you and your fellow employees.
1. Tell the customer that the concern has been addressed, but say nothing else.
2. Explain the corporate policy to the customer.
3. Provide the customer with a written copy of the policy.
4. Speak in hypotheticals, explaining that organizations facing such concerns have historically
had policies in place to limit monthly travel.
5. Say nothing.
The escalation rules for your organization are clear. Anytime a project exceeds planned spending
during a fiscal year by 3 percent or more, the causes must be identified, and the risk of continued
overspending must be escalated to the chief financial officer. It’s the first month of the new fiscal
year. Last fiscal year, your project was underbudget by 7 percent. But it’s been a tough month.
You are currently overbudget by 3.5 percent, but you have eleven months in which to recover.
What should you do?
1. Contact the chief financial officer and let her manage the overspending situation.
2. Give it another month to see if you continue to overspend.
3. Document the overspending and your rationale for expecting it to improve.
4. Wait to take action until the overspending breaks above 3.9 percent.
5. Contact the chief financial officer and tell her you believe you can manage the overspending
situation.
Part II
Risk Identification
Chapter 7
Practical, Team-Based Risk Identification
The Risk Register
Risk identification involves creating risk statements that are clear, readily understood, and in a
consistent format. Identifying risk is a form of clairvoyance, because risks are future phenomena
that have not yet occurred. The more perspectives that can be brought to bear on identifying risk,
the better. Customers see the risks of their environment. Vendors know the risks associated with
their products or services. Team members know the risks engendered by having them (the team
members) on the team (as well as the risks associated with completing the project work).
A basic understanding of risk statements is required to identify risks well. They can take a
variety of forms and formats, but after the form is determined, it must be enforced with rigor.
The classic approaches to risk statements include
IF/THEN
EVENT might happen, causing IMPACT
By generating risk statements in a consistent format, risks are more readily identified. A risk is
never a one-word answer. “Schedule” is not a risk. It is a risk category. It is a risk source. The
same applies to “Resources” or “Weather.” Those who allow one-word answers during risk
identification do themselves and their organizations a disservice.
Team members need to understand not only the format, but the nature of risk. Risk is a future
phenomenon that has not yet occurred. “I might hit a deer with my car, causing significant
damage to the vehicle.” That’s a risk statement that captures the nature of risk as being in the
future. After a risk is realized, it converts from being a future state of being to becoming an
issue. Issues management is separate and distinct from risk management.
Team members also need to be aware that risk comes from both negative and positive
perspectives. Risk is both threat and opportunity. Just as bad things might happen, good things
might happen as well. Both perspectives need to be brought into consideration.
This chapter examines the tools of risk identification, how the data gathered by those tools are
applied, and the classic archival practice of using a risk register.
Risk Identification Task 1 Conduct Risk Identification Exercises
Identification Approaches 2, 6
Preliminary Data Analysis 3, 5

The Risk Register 1, 4
Caution
Your supervisor is a data-driven manager. She loves data. The more, the better. She has taken a
heightened interest in your work in risk management and wants to know about your project risks.
What is the best tool to provide that information?

3. The work breakdown structure
4. The risk report
5. The risk response report
You are hosting a risk identification meeting with your project team and customer
representatives. You want to be careful not to share too much negative information about the
project, but you do want active participation by everyone present. Which of the following
techniques will likely serve you best in this setting?
1. Brainstorming
2. The nominal group technique
3. Focus groups
4. SWOT analysis
5. Variance analysis
Marlene managed the last project similar to yours. She recorded all her team meetings and had
them transcribed. In the process, she generated gigabytes of documentation. If you print it all out,
there will be thousands and thousands of pages. It’s early in your project. What should you do
with Marlene’s meeting records?
1. Contact Marlene and ask her what’s important.

2. Review her information to explore whether there are risks identified that would apply to your
efforts, even though such a review might take days.
3. Ignore them, since each project is, by its nature, unique.
4. Read only the important components of her meeting records.
5. Delete them.
You are developing the format for the risk register for your project. Which of the following is not
a column that should be included?
1. Risk Owner
2. Retirement/Review Date
3. Risk Response
4. Issue
5. Risk Source
Your enterprise has a fleet of vehicles, each on loan to an individual employee. In your project
alone, there are 21 cars and vans to track. Fortunately, the organization has Big Sibling software
to track every inch of movement by the vehicles. You have begun a study on the routes that are
most common for your project team, and have identified that they consistently cross railroad
tracks, drive through heavily wooded areas, and get caught in traffic on the Beltway. Such a
review on your part has what impact on the team’s risk efforts?
1. The telemetry data might provide insight not only on the nature of the risks but the relative
probability of risk events occurring.
2. The team might become upset about being tracked every time they’re in their vehicles.
3. The data might lead to inconclusive results, rendering it useless.
4. You might identify issues with team driving behaviors.
5. Team members might be more cautious upon realizing they’re being tracked.
You are trying to extract a list of risks from your team members through interviews. In the
course of the interviews, you have noticed that the participants continually answer simply “yes”
or “no.” You were hoping to get some in-depth insights by spending time one-on-one with your
team. What are you likely doing wrong?
1. You should have used brainstorming to achieve your goals.

2. You are likely asking open-ended questions.
3. You should have opted for the Delphi technique instead.
4. You are likely asking closed-ended questions.
5. You selected the wrong team members.
Foundation Topics
As you enter the basic practice of risk identification, it’s important to remember that the
objective of the practice is to identify as many risks as practicable. No risk manager will ever
identify all project risks. And in risk identification, the team does not yet know which risks are
worthy of deeper consideration. That will happen later in the process in risk qualification and
quantification. The challenge in risk identification is to state as many risks as the team can, in a
consistent format.
After a basic format for risk statements is established, there are myriad ways in which to reduce
responses to “What are the risks on this project?” There are different tools. Among them, this
book has already addressed (in Chapter 6, “Connecting Others in Risk”) brainstorming, nominal
group technique, the Delphi technique, focus groups, interviews, and meetings. There are still
quite a few other approaches to consider. They include
Mind mapping
Affinity diagrams
Root cause analysis
Checklist analysis
Assumptions analysis
SWOT analysis
Expert judgment
There are also different ways to ask the basic risk question. The two most common alternatives
to the generic “What are the risks on this project?” question are as follows:
What are the risks driven by these categories and/or sources?

What are the risks driven by this individual perspective or bias?
Mind Mapping
Mind mapping is basically brainstorming with graphics. As ideas are shared freely in a group
setting, each idea is posted to a common board or screen, visible to all participants. If an idea is
based in part on something that has already been brought out, a line is drawn from the new idea
to the original source idea. The major advantage of mind mapping is that participants understand
where ideas are drawn from and how they evolved. I might have a car accident, causing serious
injury can evolve into I might hit a deer, causing a car accident, which could evolve into My
insurance rates might increase, making them unaffordable, as shown in Figure 7-1.
Figure 7-1 Mind Map
In a mind map, it’s easy to track the origins of ideas, which can make risk identification (and the
identification of risk sources) easier.
Affinity Diagram
The affinity diagram tool is largely based on brainstorming techniques, but with a twist. Risks
are catalogued on paper or sticky notes as the ideas are generated. Each slip of paper represents a
single risk event (properly formatted, of course). The initial ideation continues (as with a
brainstorm) until all ideas are exhausted. Then, the affinity diagram is created. Using the slips of
paper, each is placed, one at a time, on a common board or screen. After slip #1 is placed,
someone else takes one of their slips and places it on the common board or screen. Anytime the
risk described on a slip of paper is in the same general group as a previous slip, those slips are
placed adjacent to each other. As more and more slips of paper are posted, natural groupings
form. Ultimately, the board is filled with risks that have affinities with others, looking something
like Figure 7-2.
Figure 7-2 Affinity Diagram
Because each idea is added to the board by a different person (on a rotating basis), no single
perspective becomes dominant.
Root Cause Analysis
With root cause analysis, another diagram is applied. It is sometimes referred to as an Ishikawa
diagram but is more commonly known as a cause-and-effect, or fishbone, diagram. The impact
of the risk events drives this particular type of analysis. If management is most concerned with
cost overruns, the primary impact under consideration would be just that. Another Ishikawa
diagram might have “Missed Deadline” as its primary impact. A single effect becomes the focal
point. From there, the “fishbones” are developed. Classically, a fishbone diagram had four
primary causal areas: Human, Method, Materials, and Machine. Over time, different
organizations had adapted their own causes for the fishbones, generally drawn from their
organizational experience with risk. These categories can also represent risk sources, drawn from
a risk breakdown structure or a standard (like PESTLE).
The questions asked in an Ishikawa analysis are simple and basic on the diagram. Were the
diagram based on the original four primary causes (as shown in Figure 7-3), the question set
would be the following:
What are the human reasons that might drive a missed deadline?
What are the process reasons that might drive a missed deadline?
What are the materials reasons that might drive a missed deadline?
What are the machine reasons that might drive a missed deadline?
Figure 7-3 Ishikawa Diagram
After the first question, the follow-on questions are simple. If the human reason for a missed
deadline was We might not have enough staff, the follow-on question is Why?
The process then moves into what are called The Five Whys. Why? Why? Why? Why? Why?
The questions in the list that follows and Figure 7-4 illustrate how this applies:
We might not have enough staff because we don’t pay well. Why?
We don’t pay well because our company isn’t that profitable. Why?
We’re selling something the public doesn’t want. Why?
We’ve been doing it this way for 150 years. Why?
We believe it worked in the twentieth century; it should work now.
Figure 7-4 Partially Completed Cause-and-Effect Diagram
By going through the five whys on each branch of the fishbone diagram, themes develop. When
themes recur across the diagram on different “fishbones,” these might not just be causes of risk.
They have the potential to be root causes. Root causes are those that either are repeated on the
fishbones or those at the furthest end of the diagram (like the 150-year sales history) that are
most significant issues that drive to the effect in a cause-and-effect diagram.
Checklist Analysis
Checklists reflect history. Every checklist reflects either a positive or negative experience where
an action or activity has worked to the benefit or detriment of a project. Just as a vacation
packing checklist’s inclusion of “toothpaste” might serve to remind someone of the time they
had to buy a tube of toothpaste from the hotel gift shop for $10, the checklist items serve as
reminders of what needs to be included (or omitted) in future efforts. Checklists might identify
threats and/or opportunities as a result.
Checklists should not be seen as sacrosanct or as all-encompassing. They should, however, be

analyzed to ensure that the concepts they cover are considered, because someone deemed the
included items as risks or risk sources at some point in the past.
Assumptions Analysis
Assumptions are what we believe to be true for planning purposes. Assumptions analysis is the
effort to identify the belief system and the implications thereof. Assumptions are rife in project
management. Managers make assumptions about the weather, the physical environment,
infrastructure, personnel, and dozens of other considerations. The first aspect of an assumptions
analysis is to review the assumptions and ensure they are properly documented.
After that step is complete, the next challenge is to convert assumptions into risk statements. If
the assumption was, We’ll have at least two weeks of dry weather, the risk statement might be, If
we don’t have two weeks of dry weather, then the concrete pouring phase will have to be
postponed. The key is that assumptions analysis can lead to a variety of different impacts. Unlike
cause-and-effect diagrams, where myriad causes are identified for a single impact, assumptions
analysis drives from a single cause to a variety of impacts.
SWOT Analysis
Strengths, weaknesses, opportunities, and threats (SWOT) is one of the few abbreviations that
still lingers on the exam. The focus on SWOT analysis is that the strengths and weaknesses are
external to the project. That does not mean that the strengths and weaknesses are external to the
organization, just that the project is not the driver of those strengths and weaknesses. In Figure 7-
5 and Figure 7-6, the SWOT is formatted in a traditional approach, with the external concerns
across the top of the diagram and the project-specific concerns across the bottom.
Figure 7-5 SWOT Format
Figure 7-6 SWOT Example

In the SWOT example in Figure 7-6, the company is a concrete firm that has been doing business
since the late twentieth century. The latest project is a last-minute, client-centric project where
the client needs the work done as soon as possible.
The lower-right quadrant represents traditional threat risks, whereas the lower left represents
traditional opportunities. Opportunities are considered as positive risks in evaluating the risk
environment.
SWOT is considered a “big picture” perspective on risk, rather than a detailed analysis.
Expert Judgment
As the name implies, the application of expert judgment requires that the organization have
experts. These can be experts in the project field, in particular aspects of the project (e.g.,
technology), or experts in risk management. No matter the type of expert, it’s important to ensure
that their expertise is directly germane to the project at hand and the risks at hand. Expert
judgment inherently incorporates a degree of bias, and the experts can be either internal or
external. They can include team members, consultants, subject matter experts, professional
association representatives, or a representative from the project office. Because every expert
comes to the table with their own set of experiences and beliefs, some bias is inevitable.
The Risk Questions
For all the ideation techniques, the basic question is: What are the risks?
However, that question can be asked any of dozens of different ways. Working in tandem with
the risk breakdown structure, the same question can be rephrased with sources of risk. For
example, it could be asked as What are the [SOURCE] risks? With that modest change, and by
narrowing the category for the risks, team members and those participating in the risk
identification process can often draw out even more risks. If the original generic risk question
didn’t bring out enough answers, the follow-on of a litany of sources might. For example:
What are the schedule risks?

What are the cost risks?
What are the compliance risks?
What are the political risks?
What are the environmental risks?
What are the societal risks?
By enveloping risks within categories, some supplemental risks might be brought out that
otherwise might have been missed.
If the risk questions are preordained by the organization, the project office, the risk office, or
other source, they can collectively be referred to as “prompt lists.” As the name implies, a
prompt list is designed to prompt users to consider the specific areas within the list (as in the
preceding list).
The risk question can also be rephrased from different organizational or project perspectives. In
such a scenario, participants can don different “hats” and take on the roles of others in the sphere
of project influence. For example:
If you were the chief financial officer, what would you see as the risks?
If you were the customer, what would you see as the risks?
If you were a worker in the field, what would you see as the risks?
By framing the risks in different perspectives, again, some supplemental risks may be educed
that otherwise could be overlooked.
During risk identification, possibilities arise. Sometimes (particularly when using tools such as
affinity diagrams), relationships among risks might surface. Such relationships can represent risk
sources or can manifest themselves as common causes or risks with common impacts.
The project/risk team needs to be attuned to watching for such commonality, because it
contributes to the context of the data being collected.
In addition, early in the process, it’s possible to generate solutions. Although this is considered
premature (as some of the risks identified might not be important enough to warrant response),
the project manager and the team are expected to capture the information in case it might have
utility at a later date.
The Risk Register
The single most important output of risk identification is the risk register. As discussed in
Chapter 1, “The Risk Structure,” the risk register is considered the cornerstone of the risk
archive. During risk identification, the register is populated with data. This data is shared across
the project team openly and freely.
Historical risk registers (from past projects) are considered critical organizational process assets,
in that they represent the collective knowledge related to risk from a specific project. The risks,
contact information, and outcomes can prove invaluable in terms of building a new list of risks
and interpreting the risks at hand.
The current risk register serves as a prompt list for risk data to be gathered. As discussed in
Chapter 1, the data set can include the following:
Risk event
Risk ID
Probability
Impact
Overall risk
Priority
Risk owner
Area(s) impacted
Escalation
Response strategy type
Response strategy narrative description
Implementation schedule
Implementation review
Retirement criteria
Follow-up
Outcome
Archival location
Clearly, at the early stages of a project, such information will not all be readily available. As
such, the risk register is completed to the degree to which information is available. For some
risks, some of that information might never become available or even be sought. If the risks
prove too inconsequential, they can be retained in the risk register with an incomplete data set.
Also, the risk register can play a role in risk identification by spurring the identification of
additional risks. For example, the implementation schedule for a risk response that hits during a
particular busy season might flag a new risk that hadn’t been previously considered. If the “area
impacted” all seems to fall under the purview of one individual or department, that could create a
new risk for that individual or department to become overwhelmed.
It is noteworthy that the risk register (or updates thereto) is an input and output to every process
in risk management after risk identification.
found.

Section Identification Approaches 111
Section Root Cause Analysis 113
Section SWOT Analysis 116
Section The Risk Register 119
mind mapping
affinity diagram
root cause analysis
checklists
assumptions analysis
SWOT analysis
risk register
Review Questions
Your project team is very visually oriented and seems to understand concerns better when they
can see where they’re coming from. You were planning to brainstorm a long list of risks, but
realize that a large list might serve only to minimize discussion, rather than support it. You want
to use the right tool to work with your team’s propensities. Which tool will likely serve you best?
1. SWOT analysis
2. Ishikawa diagramming
4. Mind mapping
5. Affinity diagramming
Your boss has asked you to get to the “heart” of your project risks. She believes there are a
handful of key risk sources that require her focus and yours. She doesn’t just want a laundry list
of causes. She wants the root causes. What’s the best tool to achieve her goal with your team?
1. Mind mapping
2. SWOT analysis
3. Affinity diagramming
4. Ishikawa diagramming
5. Performance reviews
Which of the following statements about checklist analysis are true? (Pick two)
1. Checklists cover the full spectrum of risks for projects across an organization.
2. Checklists reflect history.
3. Checklists are generated for each project individually, because each project is unique.
4. The checklists are reviewed by each team member, every time.
5. The checklists are normally not specific to each risk manager, being archived and shared
through the project management office.
You announce to your team that they are going to identify risks for the project. What is their
objective?
1. Identify as many risks as practical.

2. Identify all the risks.
3. Identify the major risks.
4. Identify the risks that will actually impact the project.
5. Identify risks specific to this project.
You and your team just spent hours building a long list of risks. During the course of the
discussion, one of your team members points out, “90 percent of these risks could be mitigated if
we just had a customer representative at our disposal.” What should you do with this shard of
insight?
1. Ignore it, as it’s too early in the process for responses.

2. Catalogue the response with the risks for which it’s appropriate.
3. Provide the customer with a written explanation of the need.
4. Identify team members who have a good relationship with the customer and ask them to find
out how the idea might be received on the customer’s side.
5. Document it in the risk register for the risk that spurred the comment.
The customer, Jean, has expressed a near-phobic reaction to the possibility that wildlife may
infest the supplies that are being left in the outdoors. Jean knows that all the supplies are
wrapped in heavy-duty plastic and sprayed with animal repellents. In all your years managing
similar projects, you’ve never seen this as a problem. Still, you want Jean to feel the concern is
being addressed at its core. You believe you can resolve this by pointing out the root causes of
the problem and the fact that those causes are few and far between. What’s the best tool to apply?
1. A SWOT analysis
2. An Ishikawa analysis, using the five whys
3. A cause-and-effect analysis, applying interviewing techniques
4. A fishbone diagram, applying the “what-if?” technique
5. A nominal group technique ideation session
Chapter 8
Constraints and Assumptions

The distinction between constraints and assumptions is significant in risk management.

Constraints are limiting factors that define the boundaries of a project (and in some ways, the
boundaries of a project’s risks). Assumptions are factors that are believed to be true for planning
purposes. A schedule deadline is a constraint. Believing a client will not accept any component
of a deliverable after the deadline is an assumption. It becomes a constraint only when the client
tells you that it’s a fact, rather than a belief.
Both constraints and assumptions are risk drivers. Constraints drive risks by virtue of their
limiting qualities. Assumptions drive risks by virtue of representing aspects of the unknown.
The two are inextricably wed. Assumptions, as they are validated, become constraints or become
known risks. Constraints, even when clearly spelled out, are burdened by different perceptions of
their meaning—different assumptions.
Project managers must openly share information on assumptions and constraints for all team
members to ensure a consistent understanding of the environment. The risk personnel on the
project should also be able to distinguish the nature of this information in the risk context of
known-knowns, unknown-knowns, unknown-unknowns and known-unknowns.
This chapter examines the nature of constraints and assumptions, their relationship, and the need
for stakeholder understanding of both.
Risk Identification Task 2 Examine Assumption and Constraint Analyses
Constraints as Risk Drivers 2, 3
Assumptions as Identified Risks 1, 6
The Open Assumptions and Constraints Discussion 4, 5
Caution
You are concerned about the technical complexity of the project and the rare skill set required to
get the work done. One of your team members, in an effort to reassure you, points out that
Lawanda is on your team, and she knows the technology better than anyone. Team members
have not yet been assigned to the project, but everyone expects to see Lawanda on the effort.
Which of the following statements is true?
1. That Lawanda will be on your team is an assumption

2. That Lawanda will be on your team is a constraint
3. That you need Lawanda on your team is a constraint
4. That you need Lawanda on your team is both an assumption and a constraint
5. That Lawanda will be on your team is both an assumption and a constraint
The project includes a vast array of deliverables to celebrate Samhain (October 31–November 1).
It marks the end of the harvest season and is normally celebrated with decorations including corn
stalks and pumpkins. Part of your deliverable package is 12,000 bright orange pumpkins, each
weighing at least three pounds. The contract says that they must be at the client site no later than
noon on October 30. Your trucking company just called to tell you that it looks like the truck
won’t get to the site until 12:45 p.m. on the 30th. Which of the following statements is true?
1. The noon deadline is an assumption and should be validated.

2. The noon deadline is a constraint, and this violation represents a contract breach.
3. The noon deadline is a constraint, and this violation represents a material breach.
4. The noon deadline is an assumption, and this violation is immaterial.
5. The noon deadline is a target and requires further analysis.
Management has told you that your project will have to be conducted out of the Youngstown,
Ohio, office. You’ve never really liked managing remotely, and you realize there are perils
associated with working in a city with which you’re not familiar. The sheer volume of unknowns
of working in Northeast Ohio makes you shudder. You would much rather run the project out of
the Scranton facility, but management says it’s Youngstown or nothing. You now realize that
working out of the Ohio facility represents what?
1. An assumption that you’ll have to assume is valid
2. A constraint that might drive other risks
3. An unknown-unknown, which might surprise everyone on the team
4. A known-known, which everyone on the team will have to live with
5. A minimal risk, as management wouldn’t select it otherwise
At mid-project, the unthinkable happens. The power grid grows weak, running all your servers
and other equipment on low voltage. There are no systems to alert you to the semi-failure, and as
a result, your entire server farm short circuits at once. No one recognized this as a possibility,
because the power company told no one about brownouts or other outages. When you talk to
your technical personnel, they tell you they’ve never heard of something like this. In classifying
this risk from its inception, it should be considered as what?
1. A known-known
2. A known-unknown
3. An unknown-known
4. An unknown-unknown
5. An assumption
You have been named as the project manager and risk manager for a new endeavor to build a
methane collection and power facility. It’s never been done. You’re excited about the prospects,
but realize things will go wrong between the chartering of the project and its completion. You
have no idea what things will go wrong specifically, but with all the variables in this new effort,
you are certain something will fall afoul of your plans. That “something” represents what
classification of risk?
1. A known-known
2. A known-unknown
3. An unknown-known
4. An unknown-unknown
5. An assumption
Kristi, one of your team members, just revealed that she’s three months’ pregnant and her
anticipated delivery date is around the time your project is to be transitioned to the customer.
Kristi is the absolute best of the best in terms of customer relationships and has already built a
solid rapport with the customer. Up until now, you lived under the misconception that Kristi
would be the guiding force for the transition. You just added a new risk to the risk register. It
reads: Kristi might go into labor during the transition, forcing the handoff to be managed by
someone else. In this situation, what just happened?
1. A risk just converted to an issue.

2. An assumption just converted to an issue.
3. An assumption just converted to a constraint.
4. An assumption just converted to a risk.
5. You selected the wrong team members.
Foundation Topics
You have to start the meeting at noon Pacific Time. The project budget is $1,000,000 and not a
penny more. The deliverables for the project must be wrapped in holiday gift wrap and presented
to the customer with a song. Those are all constraints. They are “must-do” conditions that are
placed on projects to create the parameters and boundaries of how the project will be conducted.
Constraints can relate to the classic triple constraint of time, cost, and requirements, or to
virtually any aspect of the project. Anytime a project charter, contract, or memorandum of
understanding uses the words “shall” or “must,” that’s a clear indicator of a constraint being
imposed on a project.
Team members need to be aware of the constraints on a project, because those constraints
represent the parameters for risks, as well. By clearly establishing the project environment, you
also begin to establish the nature of which risks fall into which categories. The classic four
categories of risks are
Known-knowns
Known-unknowns
Unknown-knowns
Unknown-unknowns
These become significant, particularly when it comes to the consumption of project reserves. For
known-knowns and unknown-knowns, recovery (in terms of time and cost) will be funded
through contingency reserves. For the others, recovery should be covered through management
reserves. The sections that follow look at these risk categories in more detail.
Known-Knowns
There are risks that almost everyone is aware of. When driving, you may be in an accident.
When paddling a kayak, you could overturn and drown. When working in the outdoors, you
might be bitten by an insect. For most people, these are known-known risks. The first “known”
comes from awareness. You know that these things could happen, and you are conscious of
them. If they come to pass in the course of a project, it’s not a surprise.
The second “known” comes from a relative understanding of the probability and impact. Those
values vary from project to project, but for most of these knowns, there’s a general
understanding of how often they might occur and how badly they might impact project
objectives (or in the case of opportunities, how beneficial they could be to our project
objectives).
The known-known risks, when they come to pass, are funded through contingency reserves.
Contingency reserves can be work package by work package, user story by user story, or can be
across the entire project. It is specifically set aside for risks that are a function of the project work
and that would be expected in the project environment. Contingency reserve is managed by the
project manager or risk manager, coordinating with finance and accounting to access the funds
and apply them appropriately.
Unknown-Knowns
There are risks that almost everyone should be aware of. The only reason team members are not
aware of them is that they haven’t been considered in a while, or they haven’t happened in a
while, or someone simply forgot that they existed. These are the unknown-knowns. When these
risks are realized, the general reaction is, “We should have thought of that!” or “I can’t believe
we forgot that one.” In discussing accidents, for example, you might anticipate that you could be
hit by another car or a deer. But if you’re driving in Maine or Alaska, you need to add being hit
by a moose into that equation. And if you don’t, but get struck by a moose, it’s not because that
type of incident is unknown entirely. It’s one you should have known, considering the
environment.
The unknown-knowns, much like the known-knowns, are funded through the contingency
reserve. In this case, it is specifically set aside for risks that are a function of the project work and
which should be expected in the project environment.
Unknown-Unknowns
9/11. A meteorite strike. Sudden pandemic. Supervolcano eruption. For most risk managers,
these are unknown-unknowns. For the risk personnel dealing with these risks, there is virtually
no visibility on these risks prior to their occurrence. And the level of impact and probability is
equally unknown. Although project managers have to deal with the aftermath of such risks, these
are not things that we plan for. In a thorough risk identification effort, these are largely ignored,
because the list of potential unknown-unknowns is infinite. There’s always one more risk. Plus,
because they fall into that category, there’s very little historical information to inform decisions
about how to manage these risks.
For the COVID-19 outbreak in the early 2020s, the most recent meaningful historic reference
was almost a century past. Technology eclipsed many of the effects and approaches from the
1918 Spanish Flu epidemic.
Because these are not project-driven risks, and because they are the proverbial “bolts from the
blue,” these are not funded through contingency reserve. They are instead funded through
management reserve on the project. The management reserve, as the name implies, is under the
purview of management, and it is up to them to determine if, how, and when any funds from that
reserve will be applied.
Known-Unknowns
Known-unknowns is the newest addition to the list of general risk categories. It is the category
of risk where the project manager knows that risks are pending in a project environment, but the
nature of those risks is undetermined. When a child is born, parents are aware that there will be
risks in the infant’s future. How those risks will manifest themselves is unknown. When you
purchase a new car, you know there are risks in the vehicle’s future, but you cannot predict what
specific risks you will see realized.
This category of risk is almost free-floating. The risks might prove to be project-centric. The
risks might also come from an external source, having nothing to do with the project itself. As
such, known-unknowns are not consistently funded from either category of reserve. They are
funded on a case-by-case basis as they either move into a better understood category or are
realized.
Pure Versus Business or Speculative Risk
Although they are not specifically wed to any of the categories just covered, it’s important to
note the distinction between pure risk and business (also known as speculative) risk. Pure risk
applies to any of the risks with only a threat downside. There’s no intent to gain associated with
pure risk. Instead, it’s risk that when realized does harm to the project and/or organizational
objectives.
This is in contrast to business risk, which is the classic risk–reward scenario. In business risk,
there is both the chance for gain and loss. Business risks are taken with the intent of gain, and
thus normally fall into the known-known category. To achieve gains, there is normally intent to
do so.
Changes in Constraints
Anytime there are changes in constraints, the risks need to be revisited to determine if the
probabilities and impacts of the risks remain the same in the new constraint environment. If a
contract is renegotiated, a date shifts, or the nature of a deliverable is altered, new risks evolve.
The same can be said of any changes to the project charter or any of the management plans
associated with the effort.
In a classic example, a subcontractor on a software project for a government agency received a

request from an onsite customer. The request was simple. Add one character to a 14-character
field to allow for future expansion. The subcontractor agreed because the level of effort required
to make the change was minimal. The subcontractor had not considered the risks of changing the
field. The ripple effect from that constraint change caused two years of rework and modification
because of the integrated nature of the software.
You assume that the navigational software in your vehicle has current maps. You assume that the
customer’s product owner will be the same person for the next two or three sprints. You assume
that when you finish the documentation for the project, as requested, you’ll get paid.
But what if your assumptions are wrong?
Part of our role as risk managers is to encourage team members to challenge assumptions.
Because each team member has a different history, each team member has a different belief
system associated with their assumptions. For everything from management support, to team
member behavior, to customer conduct, each person has an assumption set, and part of our role is
to identify that assumption set and make it public within the team.
Assumptions are captured in an assumptions log. As a key artifact in assumptions analysis, this
log of beliefs is important because each one can readily be converted to one or more risks. The
conversion process is easy:
Document the assumption: The navigational software in your vehicle has current maps.
Convert it to a negative: The navigational software in the vehicle might not have current
maps, causing…
Define the impact: The navigational software in the vehicle might not have current maps,
causing us to take a longer route to get to the client site and being late for meetings.
For any assumption, one or more risks can be generated by simply stating the assumption as a
negative. The lack of current maps, for example, could also lead to a team member missing an
engagement, or to team member frustration, causing them to quit. The list of impacts can be
sizeable.
Every assumption bears with it at least one risk event to consider.
Getting team members to openly discuss constraints and assumptions can sometimes be
challenging. Some individuals will mistake assumptions for constraints, whereas others identify
constraints where there are no hard and fast metrics. Of the following three statements, one
embodies an assumption, and the other two are constraints:
The project must be done by October 5.
The project must be achieved within a $2,000,000 budget.
The project must follow management’s strategic objectives.
Some might believe that all three are constraints because the word “must” appears in all three
statements. In fact, the last statement is sufficiently ambiguous that any interpretation of it
represents an assumption. Even if the organization’s strategic objectives are well documented,
one team member’s interpretation of those objectives could vary widely from another team
member’s.
Although “must” and “shall” are good starting places for objectives, team members need to
understand that a clear constraint is unambiguous and metrically driven.
After team members understand the distinctions between assumptions (belief systems) and
constraints (clearly documented, metrically driven limitations), the team is enabled to have the
open assumptions and constraints discussion.
Assumptions, Constraints, Tolerances, and Thresholds
The assumptions and constraints often drive or stem from project risk tolerance, and vice versa.
A €2,000,000 project in some organizations might lead to a belief system that any final budget
number within 10 percent of that value is good performance. Often that’s an assumption.
However, a clearly stated tolerance of no more than €2,000,000 is a constraint. Because of the
confusion between assumptions and constraints, one team might panic when project spending
hits €1,900,000, whereas another team might believe there’s still plenty of breathing room before
the real ceiling is hit.
An open discussion on these concerns can take a variety of forms, but the expectation is that the
risk conversation happens regularly, on a timely basis. In agile environments, this discussion can
readily be had with the three questions of an agile daily scrum meeting, particularly the third
question:
What’s standing in your way?
This is a perfect opportunity to identify not only the risks that lie ahead, but also the assumptions
or constraints that drive those risks.
Because those meetings are held on a daily basis, with all team members present, there’s a
regular, ritual opportunity to reinforce the assumptions and constraints for the project.
In more traditional project management, the assumptions and constraints conversation can
leverage approaches from the construction and utility industries. There, “safety messages” are
shared at the beginning of every team meeting. Just as readily, a “risk message” would be
appropriate in such a setting.

found.
Key Topic Page

Description
Element Number
Section Constraints as Risk Drivers 129
Section Pure Versus Business or Speculative Risk 131
Section Assumptions as Identified Risks 132
Section The Open Assumptions and Constraints Discussion 133
Section Assumptions, Constraints, Tolerances, and 133

Thresholds

known-knowns
unknown-knowns
unknown-unknowns
known-unknowns
assumptions analysis
constraints
Review Questions
You are a subcontractor with a team of 20 painters on a building renovation project in downtown
Portland, Maine. During the project, a ship from Bath Iron Works on a test run goes rogue and
plows into Portland Harbor, destroying dozens of pleasure craft and demolishing an entire wing
of the building where you’re working. In the city’s 400-year history, that’s never happened. The
type of risk that just manifested was what?
1. A known-known risk that will be managed through management reserves

2. An unknown-known risk that will be managed through management reserves
3. An unknown-known risk that will be managed through contingency reserves
4. An unknown-unknown risk that will be managed through management reserves
5. An unknown-unknown risk that will be managed through contingency reserves
You have been assigned to shut down the last major mainframe system still operating on what
many consider “antique” software. It’s been running fine for decades. Still, the organization
wants to integrate more of the information from that system into its more modern systems. It
works fine now. The newer systems work fine now. Still, you know that something during the
life of the project can go horribly wrong. You just don’t know what. This is a classic example of
what type of risk?
1. Known-known
2. Unknown-known
3. Unknown-unknown
4. Known-unknown
5. Performance risk
Which team members need to share their assumptions about the project?
1. Internal team members

2. External team members
3. All team members and stakeholders
4. Critical stakeholders
5. Vendors
1. All risks are driven by assumptions of one type or another.

2. Tolerances often determine constraints.
3. Constraints often determine tolerances.
4. Assumptions determine constraints.
5. Assumptions determine tolerances.
You have a project with an $8,000,000 CDN budget. Management has told you that the project
will be sent for review for termination if, at any time, the budget projections exceed $8,300,000
CDN. Management wants to be notified if the budget projections, not considering contingency,
exceed $7,900,000 CDN. Which of the following statements is true?
1. $8,000,000 is the tolerance and $8,300,000 is the threshold.

2. $7,900,000 is the threshold and $8,300,000 is the tolerance.
When reviewing the terms and conditions of the contract, you realize that one of the conditions is
that all 10 of the personnel on the project have a government clearance for Top Secret
information, with a full polygraph. Only a handful of your staffers have gone through the
clearance process. Only two of them have taken the polygraph. It’s written in the terms and
conditions section of the contract, not the requirements. As such, what should you do?
1. Recognize that eight more staffers will have to be cleared, with a polygraph, because it’s a
project assumption.
2. Recognize that eight more staffers will have to be cleared, with a polygraph, because it’s a
project constraint.
3. Suggest to the customer that you can get the staffers cleared after the project is underway,
because it’s an assumption.
4. Document the assumption that because it’s in the terms and conditions of the contract and not
the requirements, it’s optional.
5. Document the constraint that because it’s in the terms and conditions of the contract and not
the requirements, it’s optional.
Chapter 9
Applying Triggers and Thresholds

The trigger is a longstanding standard of risk management. It’s a warning sign. It’s a visible or
physical manifestation that a threshold has been (or is about to be) breached and that a risk that
might drive us to a tolerance is imminent. The warning signs of risk management can tie to every
type of risk, from compliance to safety to cost and schedule.
Triggers shift based on project context. They shift based on the environment. But no matter the
nature of the triggers, they must be broadly communicated. They can be communicated as a
matter of training or by their existence alone.
The application of triggers can decrease or increase both the probability and impact of a risk.
Knowledge that rumble strips are at the side of the road can minimize the probability of running
off the road. But that same knowledge may create a false sense of security, leading to increased,
rather than decreased, risk. As such, team members should be encouraged to alert the project
manager, risk manager, or their management when the trigger (or the threshold that’s driving the
trigger) needs to be reconsidered or challenged.
This chapter examines the nature of triggers and thresholds, their relationship, and the need for
stakeholder understanding of both.

#
Risk Task Document Risk Triggers and Thresholds Based on

Identification 3 Context/Environment
Compliance and the Implications of Tolerance 1, 2
Tolerance- and Threshold-Driven Triggers 3–5
Stakeholder-Driven Triggers 6
Caution
You are conducting the project per Government Policy #482-4519. Both your management and
the customer have made you acutely aware that any deviation from the mandates of that policy
will lead to immediate project termination. Which of the following statements is true?
1. This is a compliance risk with a binary (yes/no) outcome.

2. This is a compliance risk where the thresholds represent minor deviations, and the tolerance is
for major deviation.
3. This is a tolerance risk with a binary (yes/no) outcome.
4. This is a tolerance risk where the thresholds represent minor deviations, and the tolerance is
for major deviation.
5. This is a government risk where the thresholds represent minor deviations, and the tolerance
is for major deviation.
You routinely talk about compliance during your regular project meetings. One of your team
members comes up to you after the meeting and asks what compliance is all about. They want to
know who drives the compliance. You’ll need to explain it, but keep it simple. Which of the
following most effectively answers the question of who drives the compliance?
1. Compliance is driven by a variety of entities. There’s government compliance, regulatory

compliance, industry compliance, and organizational compliance, to name a few.
2. Compliance is driven by the project outcome.
3. Compliance is a function of the project requirements. If requirements are not met, the project
is noncompliant.
4. Compliance is driven by the triple constraint of time, cost, and requirements. Any failure to
meet any of those three constraints represents noncompliance.
5. Compliance is driven by government and industrial regulation.
You are pouring pink chocolate pandas for a special Valentine’s Day promotion. The molten
chocolate has a history of trapping air bubbles, causing poor panda performance. The bubbles
that permeate your pink pandas have attracted the attention of your primary customer. They’ve
warned you that if they find any of your confections with more than ten visible surface bubbles,
they’ll terminate the contract for cause. It’s your most important client. Which of the following
makes the most sense from a risk perspective?
1. Tell team members that ten bubbles is the new threshold for taking action to stop a shipment.
2. Tell team members that seven bubbles is the new threshold for taking action to inspect all
pink pandas.
3. Tell team members that ten bubbles is the new tolerance for taking action.
4. Tell team members that seven bubbles is the new tolerance for taking action.
5. Stop trying to sell pandas as a new Valentine’s Day symbol.
As you drive through the mountains, you note that the engine temperature in your vehicle is
climbing steadily. It’s gone from cold (designated by a green zone and the numbers 1, 2, and 3)
toward hot and continues to go higher. It’s almost in the red danger zone (designated by the
numbers 9 and 10). As you cross the 8,000-foot elevation, the needle creeps into the red zone.
The car seems to be running just fine. For now. You check the owner’s manual, which stipulates
Anytime a vehicle enters the red zone, park it immediately until the engine cools to at least
number 6 on the thermometer. A reading of 9 or 10 for more than a few minutes may cause
permanent out-of-warranty damage to your engine. What’s the trigger in this scenario?
1. 9 or 10 on the thermometer
2. A value approaching 9 or 10 on the thermometer
3. Any value above 3 on the thermometer
4. Any value above 6 on the thermometer
5. A blown engine
You read the instruction book for the smoke detector in the corporate kitchenette. A beep every
45 seconds indicates a low battery. A series of rapid beeps indicates carbon monoxide. A solid,
steady beep indicates the presence of smoke or fire. Your company, to maintain compliance with
government regulations, must have functioning smoke and CO detectors. Which of the following
statements is true?
1. A beep every 45 seconds indicates that the tolerance for battery life has been exceeded.
2. A beep every 45 seconds indicates the threshold for battery life has been exceeded.
3. A solid, steady beep is a trigger for low battery life.
4. A solid, steady beep is a trigger for potential carbon monoxide exposure.
5. A solid steady beep indicates that compliance is in jeopardy.
Kristi, one of your team members, is troubled by exposure to carcinogens. The contract with
Kristi’s organization says nothing about carcinogens, and the project is not one that traditionally
invokes any type of health clauses. Nonetheless, she’s noticed that there are landscaping timbers
all around the outside perimeter of the facility, and they smell like creosote, a known carcinogen.
You post signs every 10 feet along the perimeter reading Warning: Carcinogens Present. Stay
Clear of Landscaping Timbers. This seems to placate Kristi. The signs represent what?
1. A trigger driven by the environment

2. A trigger driven by the project
3. A trigger driven by compliance
4. A trigger driven by a stakeholder
5. A tolerance driven by the environment
Foundation Topics
Conventionally, compliance is binary. An organization, project, individual, or climate is either in

compliance or not. However, it’s possible to continue to function in some compliance
environments, because the compliance might or might not drive tolerance. If a failure to comply
forces projects to stop or exceeds an acceptable level, that’s when a tolerance has been met. If a
failure to comply creates additional work or generates new challenges, although it might be
painful, tolerance might not have been achieved.
This does not mean compliance is not always important. Compliance, when dictated for a
project, must ultimately be achieved. The challenge is knowing the degree to which it either has
been or will be achieved.
For some matters of compliance, there are degrees. Speeding on the highway is a compliance
concern. If the posted speed limit is 55 mph, anyone driving above 55 is no longer in
compliance. For most drivers, driving at 56 mph would easily be considered tolerable. A state
highway patrolman was once quoted as saying, “Eight is great. Nine, you’re mine.” This
indicates that for this officer, 63 mph is out of compliance, but he’s willing to tolerate the
behavior. Sixty-four mph was his tolerance.
Each driver is allowed a certain number of “points” against their license. If the driver has a full
set of 15 points and has never been pulled over for an infraction, for example, they might be
willing to tolerate 65 or even 70 mph on the highway. They can “afford” the loss of two or three
points for a speeding infraction. By the same token, after a year of bad driving behavior, if
they’re down to their last two points, the tolerance and threshold will shift dramatically. A single
driving mistake could cause them to lose their license.
Similarly, during the life of a project, the conditions shift. A single risk realized might cause
concern, but not push the project anywhere near its tolerances. If a dozen risks are realized, the
risk context changes, potentially shifting the thresholds as well as the tolerances.
The basic rules of compliance in project risk are as follows:
The project will comply with all mandatory regulations.

Out-of-compliance projects are not complete.
Compliance conditions may shift during the life of the project.
As risks are realized, the consequences of the risks can shift the perception of compliance.

Some triggers are driven by tolerances and thresholds. When there are points beyond which an
organization or individual will not go, those are tolerances. If the contract dictates that the project
will be terminated for violation of a nondisclosure agreement, such a violation becomes a
tolerance. Sharing any information related to the project or client becomes the point at which all
work will stop. Leading up to that tolerance are thresholds. These are the points at which the
project team and stakeholders change behavior to avoid hitting the tolerance.
Because a threshold is a point at which the stakeholders are expected to change behavior, the
thresholds must be tied to triggers, which are the warning that the threshold has been (or is about
to be) breached. These signs can be visible or physical.
Visible Triggers
Classic visible triggers are legion along the side of the highway. “Deer Crossing” or “Hidden
Driveway” serve as reminders that there are dangers ahead, and they would lead to exceeding a
tolerance without the proper level of attention. For something like a nondisclosure agreement, a
sign posted in the conference room might warn “Loose Lips Sink Contracts” as a reminder that a
conference setting is one where the threshold is likely to be crossed.
Visible triggers can be constant, such as a sign, or might hit only when the actual risk is
imminent. A flashing light on a railroad crossing sign might activate only when a train is nearing
the intersection. A dashboard “check engine” light blinks on only when there’s an anomaly that
could potentially damage the engine of an automobile. Obviously, the latter examples are more
effective than simple signs, but they also are more expensive and require a degree of
maintenance.
Some visible triggers are reinforced not by their creation, but through education. When you see a
shiny section of road on a cold winter’s day, it could be an indicator of treacherous black ice.
There’s no sign or warning, but if you were instructed well on how to handle winter weather, you
recognize the sheen as a visible trigger.
Physical Triggers
Physical triggers are those that touch the remaining four senses. Although a driver might not see
the indentations in the pavement that make up rumble strips, the feeling of those strips
reverberating under a car’s tires is unmistakable. The car is now precariously close to the berm or
the ditch. It is crossing a threshold, and the physical trigger alerts the driver.
Similarly, the warning track in baseball is designed to get an outfielder to change behavior before
hitting the wall. When the field shifts from green sod to brown sand or dirt, a player can feel the
change under their cleats, creating a situation where the player will either slow down or prepare
to jump, lessening the impact of the risk of hitting the wall.
Standing at the edge of the Grand Canyon, about 12 people a year fall to their death. Many of
these people are focused on taking selfies while standing at the very precipice of the canyon. At
the South Rim, there are many locations where there are no fences to preclude this behavior.
Although there are warning signs (triggers), there are no physical barriers to prevent fatalities in
some locations.
Because acrophobia (fear of heights) is one of the most common phobias

(https://my.clevelandclinic.org/health/diseases/21956-acrophobia-fear-of-heights), many people
will not willingly go anywhere near the edge of the canyon. If each person designed the trigger
based on their own willingness to take risk, they would be setting up stakeholder-driven triggers
based on their personal risk appetites.
Author’s Note
On a recent visit to the Grand Canyon, one member of a couple disembarking
from a tour bus was heard to say, “I can’t believe they park the bus this close to
the rim. I feel like they should have a barrier stopping you from going past the
front bumper.” A young man in the same tour group immediately walked to the
precipice of the canyon, saying, “As long as my feet aren’t over the edge, we’re
good!”
Stakeholder-driven triggers are those established by different parties in the project environment,
and their enforcement may hinge on the importance of the stakeholder. If a project sponsor wants
alarm bells to sound whenever the project is running more than a week late, those alarm bells are
stakeholder driven. Because they’re coming from the project sponsor (a stakeholder with clout),
the project manager will likely establish the alarm system and ensure its enforcement. By
contrast, if one team member is worried about customer relations and believes that customer calls
indicate customer dissatisfaction, the team member’s desire to have everyone report on every
customer call may be seen as overkill. That stakeholder-driven trigger (the phone call) might be
hypersensitive, and something the project manager or risk manager is not willing to pursue.

found.
Section Compliance and the Implications of Tolerance 143
Section Tolerance- and Threshold-Driven Triggers 144
Section Stakeholder-Driven Triggers 145
compliance
tolerance
threshold
trigger
stakeholder-driven trigger
Review Questions
You are leading a team of eight consultants on a project for the National Security Agency (NSA),
a highly secretive government agency in the United States. In the course of this work, you and
your team are required to maintain a Top Secret clearance. One of your best team members has a
rather lengthy criminal record, but has done their best to live on the straight and narrow for the
past five years. Still, they’re unable to pass through the clearance process. From a compliance
perspective, what should you do?
1. Keep the team member away from the project, consulting them only offline when you need
their expertise.
2. Explain to the client that compliance in this particular area is not important if they really want
the best possible outcome.
3. Keep the team member on the project team, because the government should not be able to
dictate personnel matters.
4. Ensure the team member is not on the project or anywhere near it.
5. Kill the project.
The project budget is €4,000,000, but management has acknowledged they won’t shut you down
until the projected costs on the project exceed €4,400,000. The accounting department has said
they’ll let you know when the projections hit €3,500,000. Which of the following is the
tolerance?
1. €400,000
2. €3,500,000
3. €4,000,000
4. €4,400,000
5. €7,500,000
Your significant other has told you that, without exception, you need to be home for dinner at
least three nights a week. Your job often takes you on the road. You have come to the realization
that you have a two-week travel experience coming up next month. Which of the following is
about to happen?
1. A tolerance-driven threshold is about to be breached.

2. A stakeholder-driven threshold is about to be breached.
3. A tolerance-driven trigger is about to be breached.
4. A stakeholder-driven trigger is about to be activated.
5. A visible trigger is being deployed.
1. Automatic crossing gates at railroad tracks are physical triggers.

2. Flashing dashboard lights are physical triggers.
3. A beeping smoke detector is a visible trigger.
4. The odor added to natural gas is a visible trigger.
5. Visible and physical triggers are the same thing.
Chapter 10
The Risk Register
Register Categories
Risk Classification
No single document in risk management is more important than the risk register. It is the log of
all the risks and the qualities of each risk. Although different organizations may have different
versions of the risk register, ideally the register should be consistent within a given organization.
The risk register is progressively elaborated, evolving over time as more information becomes
available.
The longer a project goes on, the more risks are added to the register. The longer a project goes
on, the more information is included to support those risks.
A risk register should be made available to all stakeholders so that there is a common
understanding of the risks and the information supporting them. Granted that some risks may
affect particular sensibilities, unless there is a proprietary reason for withholding risk
information, the assumption is that the risk register will be widely available.
Although the information might vary from one risk register to the next, common attributes are
included in the register. They include the risk event, the probability, the impact (amount at
stake), the priority, and the response. For each of those attributes, the risk register includes a
statement on the form or format. Any definitions supporting the attributes should be found in the
risk management plan, which is the project home for the risk lexicon or language.
This chapter reviews each column of a fully fleshed-out risk register and the implications of the
information within those columns.
®
Risk Identification Task 4 Develop Risk Register
the entire chapter. Table 10-1 lists the major headings in this chapter and their corresponding
“Do I Know This Already?” quiz questions. You can find the answers in Appendix A, “Answers
to the ‘Do I Know This Already?’ Quizzes and Review Questions.”
Register Functionality 1, 2
Register Categories 3, 4, 6
Risk Classification 5
Caution
You are coaching your team on the proper use and application of the risk register. Your customer
is very nervous about anything that might go wrong on the project. They have talked to your
project sponsor so much that she is worried about things going wrong as well. Given their
concerns, when it comes to sharing the gritty details incorporated in your risk register, what
should you do?
1. Share the information in the risk register freely and openly, because they ultimately need this
information.
2. Share the information on a need-to-know basis, with the project sponsor determining degrees
of need for the critical stakeholders.
3. Share the information on a need-to-know basis, with the project manager determining degrees
of need for the critical stakeholders.
4. Share the information on a need-to-know basis, with the project manager and the team
determining degrees of need for the critical stakeholders.
5. Lock down the risk register file with password protection, allowing access only to the project
manager and the team.
You are just beginning to build a risk register with your team. As you determine which columns
will be included, you know that you’ll be populating them soon. After the columns are
determined, what information comes next in building a risk register?
1. Column definitions are included in the risk register.

2. Column definitions are included in the risk management plan.
3. Terms and language are included in the risk register.
4. Terms and language are included in the risk management plan.
5. Risk events are added to the risk register.
Your risk register has a column for “risk owner.” Who is this person?
1. The person who discovered the risk
2. The person who will track the risk and any responses
3. The person who most directly causes the risk event
4. The person who overcomes the risk
Your risk register has a column for “Outcome.” What is the purpose of this column?
1. To identify the most impactful potential outcome for the risk event in question
2. To catalog whether the risk event actually came to pass, or if the risk response was effective
in implementation
3. To explain why management should be concerned about this particular risk
4. To express the cost and schedule impacts of the risk event if it comes to pass
5. To flag risk events that never came to pass
One of your team members had an extended conversation with the customer about the progress
to-date on the project. In the course of the discussion, the customer revealed that there’s a new
five-year contract that will be put out to bid in a matter of weeks, and companies that are already
engaged have the best chances of winning. The work is exactly what your company does well,
and you think this could be a true prospect for building the business. In a risk discussion, what
does this represent?
1. A threat risk if the company has a serious chance of losing the work to another vendor
2. An opportunity risk if the company has a serious chance of winning the work
3. A tolerance, if the company doesn’t have the bandwidth to service the work
4. A trigger, because the warning signs for trouble ahead are clearly spelled out
5. A probability, because there’s a likelihood the threat will be realized
Your new risk register from the project management office has some columns that haven’t been
used much before in your organization. The risk attributes that have been incorporated are alien
to you, so you start researching what they mean and why you might need them. You’re
accustomed to seeing “probability” and “impact.” You are not accustomed to seeing “proximity”
and “propinquity.” In your research, you find these have very specific meanings, and the degrees
for these attributes (High, Medium, Low) need to be defined. You have some work to do. What
does that work entail?
1. Defining high, medium, and low degrees for probability and physical nearness in the risk
management plan
2. Defining high, medium, and low degrees for probability and physical nearness in the risk
register
3. Defining high, medium, and low degrees for what management cares about and physical
nearness in the risk register
4. Defining high, medium, and low degrees for what management cares about and physical
nearness in the risk management plan
5. Finding more risks based on propinquity and proximity
Foundation Topics
The risk register is a go-to document for archiving, tracking, and cataloguing individual risk
events. Whereas the risk management plan serves the important role of ensuring that every risk
term is well-defined and expressed in an organizational context, the risk register ensures that
every individual risk is remembered and put in its appropriate place (either priority or physical
location). Because new risks evolve on a regular basis, the risk register is built through
progressive elaboration. It does not remain constant, although its categories should be relatively
unchanged during the life of a project.
The categories largely determine the level of effort and the value of the risk register. A simple
risk register with just probability, impact, and priority for each risk event will require a minimal
level of effort. A more thorough risk register with a long list of columns becomes more of an
archival challenge.
The register columns should be established early in the project, because the first risks should be
identified from the project’s outset. Key stakeholders should have input on the columns, because
they may have informational needs related to risk that others do not. Although the schedule may
be one department’s greatest risk concern, management interest (propinquity) may be the
attribute that worries another segment of the organization.
Because the risk events are the first element catalogued in the register, the framework for
expressing them needs to be consistent. Such is the case with most of the information in most of
the columns. A template or format should be clear to affirm when the information is captured
well. Later in this chapter, basic explanations of each column will be provided.
The register needs to be archived in a location accessible to project stakeholders, but the degree
of security required may limit editing to the project manager and the risk owner. The protocol for
accessing and amending the document should be clearly delineated to all stakeholders and
captured in the risk management plan.
The register updates need to occur per a basic set of rules:
When change is planned

When change occurs
At regular intervals
Planned changes (often generated by change orders) are easy to identify as they are well
communicated across the project team. Changes that occur are more challenging to identify,
because the changes may be subtle, but their impact on the risks of a project may not. A
hurricane warning along the gulf coast of Florida may not be seen as a project risk, because only
a few remote members of the team might live there. But considering the dramatic change that
may occur as a result of losing those team members, even for a one-week evacuation, may have a
far more lasting impact than initially thought. The risk register would need to be reviewed.
As for the regular interval, the timing should be delineated in the risk management plan. The
frequency of such reviews is unique to each project, but a review should occur at least at the
mid-point of the project, even on a smaller effort.
Register Categories
The categories that are reviewed in a thorough risk register are potentially legion. As mentioned
earlier in Chapter 7, “Practical, Team-Based Risk Identification,” those categories can include a
laundry list of attributes to consider. The list can potentially include (but is not limited to):
Risk ID
Risk event
Probability
Impact
Urgency
Propinquity
Proximity
Dormancy
Manageability and controllability
Connectivity
Strategic impact
Overall risk
Priority
Risk owner
Area(s) impacted
Escalation
Response strategy type
Response strategy narrative description
Implementation schedule
Implementation review
Retirement criteria
Follow-up
Outcome
Archival location
The sections that follow review each of these categories, explain their purpose, and provide
examples that might be included in the register. This list is by no means all-inclusive, but covers
most of the more common elements in a risk register.
Risk ID
This is a numeric or alphanumeric identifier to ensure that the risk can be tracked through the life
of the project.
Risk Event
This is a narrative description of the event that may occur and the impact it may cause. All risk
events are future phenomena that have not yet occurred. A clear risk event statement for
someone driving across Australia might be, I might hit a kangaroo with my car, causing damage
to the vehicle. The impact becomes important, because it will shift the probability and impact
evaluations later in risk register development. Statements for the Risk Event column should be
consistently formatted. Some risk managers prefer IF/THEN statements. If I hit a kangaroo with
my car, then my vehicle will be damaged. Others prefer a statement that captures the event and
the impact, as with the first example.
Probability
Probability is the likelihood of the risk event (as described in the preceding paragraph)
occurring. Later in the book (Chapter 11, “Risk Qualification,” and Chapter 12, “Risk
Quantification”), we’ll examine the nature of how probability can be expressed. In simple terms,
it can be expressed qualitatively (High, Medium, Low, Remote) or quantitatively (basic
numbers). The decision on when to apply which approach should be detailed in the risk
management plan. Also, the definitions of terms like high, medium, and low should be captured
in the risk lexicon, also in the risk management plan. Although kangaroo accidents make up 90
percent of all animal accidents in Australia, the odds of hitting one vary widely depending upon
the route being taken. If the driver has a propensity for ignoring the Kangaroo Crossing signs, the
likelihood might be moderate. If the driver stays in the city limits and drives defensively, the
probability might be low.
Impact
Impact is the amount at stake associated with the risk event. Again, later in the book (Chapters
11 and 12), we’ll examine the nature of how impact can be expressed. In simple terms, it can be
expressed qualitatively (High, Medium, Low) or quantitatively (basic numbers). The decision on
when to apply which approach should be detailed in the risk management plan. Also, the
definitions of terms like high, medium, and low should be captured in the risk lexicon, also in the
risk management plan. Most drivers would consider vehicle damage to be a moderate impact. If
the risk event statement were changed to, If I hit a kangaroo with my car, I could die, the impact
level would certainly shift. Most analysts would agree that death is a high impact.
Urgency
Urgency refers to how soon a risk could potentially befall the project. If I’m in Australia and not
planning any long-distance driving in the next two months, the urgency of the risk is minimal. If
I am leaving tomorrow along a kangaroo-infested route, the risk becomes more urgent. Yet
again, the definitions (and the terminology) for urgency levels are catalogued in the risk
management plan. And again, they will vary from project to project. On a two-month project, a
single risk that slows the schedule by two days would be a major concern, with high urgency. On
a ten-year project, a single risk that would slow the schedule by two days wouldn’t be considered
urgent at all.
Propinquity
The propinquity category is one of the most difficult that the Project Management Institute has
opted to include in its list of considerations. Propinquity normally refers to personal attractions
(to other people). But for the sake of the risk discussion, it refers to attractions to risks. Some
Australians care deeply about the fate of the kangaroo. If you have a team filled with those
animal lovers, the propinquity of the car accident risk is very high. They care. If you have a team
that really doesn’t have any passion for the rest of the animal kingdom, their propinquity in the
car accident risk is going to be low. This is another opportunity to evaluate the relative interest
and impact of the stakeholders on the situation.
Proximity
Proximity refers to physical nearness. How close is the risk? Many of those reviewing this
manual have never been to Australia and have no intent to drive while there. In fact, for many of
you, the discussion on hitting a kangaroo with your vehicle is a nonrisk. The reason is because of
the vast physical distances between you and the nearest big marsupial. When the weather
forecasters call for a hurricane in Florida, Floridians have high proximity. But those who live in
Kansas might feel only empathy, not fear. The closer (physically) a risk is to you and your
project team, the higher its proximity. As with all the other categories, the definitions of high,
medium, and low proximity are documented in the risk management plan.
Dormancy
Consider the 13- and 17-year locusts. They are a marvelous example of dormancy. They lie
invisible, deep under the ground, for over a decade. Were there no entomologists tracking their
cycles, their return would be a complete surprise. But there are entomologists. Dormancy in risk
refers to the nature of a risk event to lie inactive and undetected until it converts to an issue. If
the risk is completely inactive and undetectable until it’s an issue, then it is “high” dormancy. If
there are subtle warnings that it’s about to eventuate, it might be moderately dormant. Again, the
definitions for levels of dormancy are captured in the risk management plan.
Manageability and Controllability

The Project Management Institute has, for years, separated these two attributes, although it’s
difficult to see the distinction. Manageability and controllability refer to the nature of how
readily a risk event can be mastered through the application of management principles. This
normally applies to risks for which the risk response will be mitigation; however, it can also
address the risks that are actively accepted, with management dealing with the issues (risks
realized) rather than the risks themselves.
Connectivity
For want of a nail, the shoe was lost. For the want of a shoe, the horse was lost. For the want of
a horse, the rider was lost. For the want of the rider the message was lost. For the want of the
message, the battle was lost. Versions of this poem on risk connectivity stretch back to the mid-
1200s. Connectivity is the propensity for a risk event to cascade and have impact on other risk
events. The more a given risk event is integrated with multiple activities or multiple agencies or
multiple staffers, the greater the likelihood that connectivity will come into play.
Chapter 11 discusses failure mode effect analysis (FMEA) in more detail; however, a
cornerstone of any good FMEA will incorporate the degree of detectability. This ties tangentially
to dormancy, but is different in a number of ways. For one, it means that the column defines the
degree to which a looming risk event, its triggers, thresholds, and tolerances can be seen with
time to act prior to realization. This is the only category where a “high” status is considered a
good thing. A highly detectable risk would be one where there is ample time to act when the
triggers are seen. The earlier examples of railroad crossing gates as triggers would render the risk
of being hit by an oncoming train as “highly detectable.” By contrast, driving down a dark, unlit,
sparsely populated area in Australia would make the risk of hitting a kangaroo “low” in terms of
detectability, because it would be practically invisible until it was upon you. In the risk
management plan, there will be a strong explanation that low detectability is a bad situation,
whereas high detectability is the most desirable.
Strategic Impact
In this category, it’s possible to use either a High-Medium-Low schema or a narrative to express
the nature of the strategic impact. As with the others, the definitions for high, medium, and low
would be detailed in the risk management plan. The narrative might go into some depth as to the
nature of the risk event and how it might affect organizational or project strategy. For example:
If a flood submerges the server room in the basement, the potential loss of those servers could
seriously damage the corporate promise of 24/7 “uptime” for all computing connected to the
customer.
If “uptime” is a critical element of the organizational strategy, this statement serves to connect
the risk directly to that strategy. Strategic impact narratives should be clear on what aspect of the
strategy could be directly involved with the risk event.
Overall Risk
If a risk manager takes all the categories identified previously from Probability to Strategic
Impact and finds a way to integrate them into a single scoring system, it’s possible to have a
quantitative value for each risk event. Although the information in all those columns might be
important, it’s also equally important to recognize that not all the columns will apply to all risk
events. Thus, the most common way to score risk events is with the simple use of probability
times impact. Chapter 11 covers the value of having a “high-high,” “high-moderate” scoring
approach in greater detail. Beyond that simple scoring method, the most common way to
calculate overall risk is found in FMEA. It still multiplies the probability and impact scores, but
also rolls in the detectability score. This generates a risk priority number (RPN), which can be
used in ranking in the next column.
Priority
The only difference between the “overall risk” column and the priority column is that this
column is used to rank-order the risk events (identifying them from most significant to least).
Those with the highest priority will ultimately get the greatest attention.
Risk Owner
The risk owner is the individual responsible and accountable for tracking risk events, reporting
any changes, and ensuring the responses are applied as prescribed. Although the project manager
often takes on this role (which is not the ideal), the risk owner should be someone who has the
time and energy to devote to the risk event and to ensure that the responses are properly
understood and implemented. For each risk event, there should be a single owner. But each
owner may own multiple risk events. The key is to ensure that the owners have the ability to
track and share information about the risk events to which they’re assigned.
Area(s) Impacted
The nature of the “areas” should be defined in the risk management plan. These can be
organizational departments, resource groups, geographies, or any other natural project area.
Within these areas, there should be identifiable lead staff to whom risk information will be
reported.
Escalation
The escalation column answers the question, Who gets information about this risk and when? A
sample statement in the column might read:
The Chief Financial Officer. If the risk event may cause an increase in cost of $12,000 or
more, the CFO should be notified face-to-face.
Note the components of that statement. It’s still keeping risk in a future state. It provides a
specific boundary. It also identifies the communications modes to be used to escalate the risk.
This column can serve two purposes. One is to identify who gets the information and when. The
other purpose is to identify who will own the risk if “Escalate” is selected as the response
strategy.
Response Strategy Type
Chapter 14, “Response Planning,” and Chapter 15, “Response Implementation,” discuss the
nature of the different response strategies in depth, but there are very specific strategies with
very specific names. Again, the nature of those names and descriptions of their application would
be included in the risk management plan. In an electronic version of the risk register, this column
would likely be a drop-down menu with the following responses for threats:
None
Passive Acceptance
Active Acceptance
Mitigation (Probability)
Mitigation (Impact)
Mitigation (Probability and Impact)
Avoidance
Transfer
Escalation
In an electronic version of the risk register, this drop-down menu would also include the
following responses for opportunities:
Passive Acceptance
Active Acceptance
Enhancement (Probability)
Enhancement (Impact)
Enhancement (Probability and Impact)
Sharing
Exploitation
Escalation
These are the standardized risk responses, per PMI®.

Note that there is no narrative at this point. It’s simply a look at the nature of the risk response
from a categorical perspective.
Response Strategy Narrative Description
This is a text field where the project manager or risk owner documents the nature of how the risk
response from the prior column will be achieved. For example, if the strategy selected was
“Passive Acceptance,” the narrative would be a brief No action required. For the risk of striking
a kangaroo with one’s vehicle, if the strategy was “Mitigation (Impact),” the narrative might be,
Have “roo bars” installed on the front bumper to absorb more of the impact. The narrative
description lets all parties know precisely how the response strategy will be implemented.
Implementation Schedule
Some responses require immediate action. Others activate only when a trigger prompts action.
Still others require action at a later date. The implementation schedule is important to any
stakeholder (but particularly the risk owner) if they are tracking the risk and monitoring the
response.
Implementation Review
When a response strategy is implemented, it might succeed (in whole or part) or fail. An
implementation review examines the success of the response strategy. This applies to all
strategies, even passive acceptance (where the interested parties simply wait and watch). This
review examines the response, its implementation, and the degree of success. In the case of the
vehicle with roo bars, the implementation review narrative might read as follows:
Strategy implemented at a cost of $1300 AUD. Kangaroo struck three days later. Front end of
vehicle intact. Windshield replacement required.
This is where the information about the relative success of the risk strategy is captured and
preserved for future risk managers and lessons learned.
Retirement Criteria
There comes a time when every risk needs to be reexamined to determine whether the risk event
remains a threat (or opportunity) at all. If the opportunity was a billion-dollar lotto win, and
someone else hit the jackpot, the massive opportunity is no more. It would be time to retire the
risk, rendering it as a closed risk. If the Australian driver moved to the Arctic Circle, the threat of
striking a kangaroo could be retired, again rendering it as a closed risk. In both cases, the risk no
longer has the same level of significance. Because each risk is project specific and each risk is
determined in part by its environment, the retirement criteria may shift even when the same risk
is identified for different projects.
Follow-up
Two critical questions can be answered with the follow-up column. The first is “when?” The
second is “how?” This provides critical guidance to the risk owner, who otherwise is forced to
develop a personal understanding as to the reasonability of taking action at a given time. A
follow-up statement in this column of the risk register might read:
Quarterly—Conduct a visual inspection of the vehicle
The risk owner and any stakeholders directly impacted by this risk would benefit from the
follow-up.
Outcome
The outcome could, in some cases, be a reiteration of the implementation review. The outcome is
an implementation review after the risk is realized, and the long-term implications of the risk are
well understood. Outcome is important, in that an implementation review generally looks at how
treatment of the risk is going. Outcomes look at how treatment of the risk went.
Archival Location
As the name implies, this is an address (physical or virtual) where the risk archives and
information related to the risk event are stored. For the risk owner, this is important in that that
individual is responsible for submitting information to the archives, as well as reading the
information retained in the archives. For other stakeholders, this is important for them to know
where and how to access the data that has been gathered regarding the specific risk event.
Risk Classification
As discussed earlier in this chapter, risks fall into two primary classes: threat and opportunity.
The simple key is to understand that threats are those things that may happen to the detriment of
the project or organizational objectives. Opportunities are those things that might happen to the
betterment of the project or organizational objectives. They represent the yin and yang of risk
management.
In project risk management, an important aspect of risk classification is recognizing that the
different classes of risk can be exacerbated by system interaction and connectivity. The more
interaction with more systems, the greater the potential degree of both threat and opportunity.
It’s also important to recognize that risk classification can apply on a projectwide level. Most
projects are generated with the intent of achieving new opportunities. New sales, new
technologies, and new capabilities are all driven by projects and all represent opportunities. On
the opposite side, some projects carry with them little more than new threats. Projects designed
to retire older (well-functioning) systems, comply with new, daunting government mandates, or
resolve objections may pose little more than threats and offer little or nothing in the way of new
opportunities.
In this way, it becomes important to know project origins and who is responsible for initiating
them. If a project comes from an edict at a local level, it may have a lower overall risk profile. If
a project comes from the executive suite and has a C-level individual as its champion, the levels
of both threat and opportunity increase. It’s also vital to recognize whether a project was initiated
internally or externally to the organization. Depending upon the organizational culture, either
internal or external inception can enhance the opportunity or threat.
details. Table 10-2 outlines the key review elements and where you can find them. To better
track your study progress, record when you completed these activities in the second column.
found.
Section Register Functionality 155
Section Register Categories 156
Section Detectability (FMEA) 160
Section Risk Classification 164
probability
impact
urgency
propinquity
proximity
dormancy
manageability and controllability

connectivity
failure mode effect analysis (FMEA)
detectability
strategic impact
overall risk
priority
risk owner
escalation
response strategy
Review Questions
Your organization doesn’t have a long history with risk management. As such, you are a pioneer
in building one of the enterprise’s first risk registers. Management asks why you’re bothering
with all that administrative paperwork. What should you tell them?
1. It protects the project team in case someone comes along later saying they hadn’t done their
homework.
2. The risk register creates a “line in the sand” to preclude any really big threats from occurring.
3. The risk register is a document for management to keep an eye on project risk conditions.
4. The risk register is a document for all stakeholders to keep an eye on project risk conditions.
5. The risk register is proof that the team is risk aware.
The summer has been unseasonably hot and dry, and the project is being conducted in southern
California. Wildfires are a perennial threat. Your project facility is a 150-year-old wood structure
on the edge of a massive stand of old growth forest. One of the identified risk events is
If there is a major wildfire, the project facility might be burned to the ground, stopping work.
Any work stoppage is beyond the organization’s tolerance. As you look across the risk register,
you can expect to learn (or be reminded) that the risk has which attributes?
1. High probability, Low proximity

2. Low probability, High proximity
3. Low probability, Low proximity
4. High probability, High proximity
5. High probability, Low impact
The summer has been unseasonably hot and dry in southern California. The project is being
conducted in Central Ohio. Wildfires in California are a perennial threat. Your project facility is
a 150-year-old wood structure on the edge of a massive stand of old growth forest near
Wapakoneta, Ohio. One of the identified risk events is
If there is a major wildfire, the project facility might be burned to the ground, stopping work.
Any work stoppage is beyond the organization’s tolerance. As you look across the risk register,
you can expect to learn (or be reminded) that the risk has which attributes?
1. High probability, Low proximity

2. Low probability, High proximity
3. Low probability, Low proximity
4. High probability, High proximity
5. High probability, Low impact
You have identified Bruce as the risk owner for the risk event Einstein may leave the
organization, leaving the project without a subject matter expert. Which of the following best
describes Bruce’s job?
1. He’s responsible if Einstein leaves.

2. He’s responsible for watching for any signs that Einstein may leave and to implement any risk
responses as prescribed.
3. He’s responsible for watching for any signs that Einstein may leave and to implement any risk
responses if the risk is realized.
4. He’s responsible if Einstein leaves and to implement any risk responses as prescribed.
5. He’s responsible to implement any risk responses as prescribed.
Which of the following statements is true? (Select two)
1. Proximity refers to physical nearness.

2. Propinquity and proximity both refer to physical nearness.
3. Connectivity refers to technological integration.
4. Urgency addresses the question of how soon a risk might be realized or the last point at which
a strategy may still be effective.
5. Probability refers to the severity of a risk event.
When are risks retired?
1. When they have happened once.

2. When the project manager declares them complete.
3. When they no longer pose a threat or opportunity to the project outcomes.
4. When the risk owner determines that they have been on the risk register long enough to no
longer be undetectable.
5. It’s a misnomer. Risks are never truly “retired.”
Where are risk registers archived?
1. In the project management plan

2. In the risk management plan
3. In an organizational repository with broad stakeholder access
4. In an organizational repository with limited stakeholder access
5. In an organizational repository with access only by the project team and other specific
identified stakeholders
Part III
Risk Analytics
Chapter 11
Risk Qualification
Risk Sorting
Taxonomic Review
Risk Ranking
Many people look at risk as an endeavor with nothing but numbers. Nothing could be further
from the truth. Because actuarial information is not readily available on many risks,
organizations and individuals resort to risk qualification as the best available practice for
establishing the relative importance of individual risk events and for the project as a whole. The
classic “High-Medium-Low” schema is one approach to qualifying risks, and it is sometimes
translated into stoplight charts with red, yellow, and green indicators.
Risk qualification is a quick and effective way in which to evaluate risks only when there are
clear, objective definitions of terms. One individual’s perception of a high risk might be wildly
different from another’s. Objective terms and terminology come into play because of the inherent
problem with individual bias driven by individual experience.
Although the actual rankings and assessments of risks could change radically during the life of a
project, the definitions of terms should not. The same evaluation criteria used to determine a
high-impact risk at the beginning of a project should be the same as the evaluation criteria used
at the end. Those criteria are documented and accessible in the risk management plan.
That information should be made available to all stakeholders so there is a common

understanding of the levels of concern associated with the risk events. This affords stakeholders
the ability to understand why particular risks might be actively addressed while others are
passively accepted.
Ultimately, it’s possible to rank order the risk events without directly applying quantitative
practices, although the quantitative analysis (see Chapter 12, “Risk Quantification”) provides a
deeper understanding of whether particular investments associated with responses might or
might not be appropriate. Conventionally, risk qualification is conducted before risk
quantification.
This chapter reviews the process of sorting the risk events, ascribing levels of impact and
probability to their outcomes, generating priorities, and setting up risk matrices to display and
track the events.
Risk Analysis Task 1 Perform Qualitative Analysis
chapter thoroughly or jump to the “Exam Preparation Tasks: section. If you are in doubt about

Risk Sorting 1, 2
Taxonomic Review 3
Risk Management Plan Application 4, 5
Risk Ranking 6
Stakeholder-Based Ranking Support 7
Caution
You have decided to sort your project risks using PESTLE and believe this will give you a good
at-a-glance categorization of risks throughout the project. In terms of capturing the risk events
that fall under the different categories, you want to ensure that you (and your team) understand
the subcategories as well. What’s the most effective tool for achieving this goal?

2. The work breakdown structure
4. The risk management plan
5. The sorting hat
Your project management office is a strong believer in the PESTLE model. That includes
political, economic, social, technology, legal, and environmental risks. If you have sorted your
risks according to the model, which aspect of PESTLE is considered the most important?
1. It depends upon the organization, the project, and the persons conducting the evaluation.
2. Political
3. All of them
4. Environmental
5. Legal
You want to augment your identified list of risks, ensuring you’ve included risks that are
systemic in your organization. In the course of doing so, you refer to your internal risk
taxonomy. What will this practice enable you to do?
1. Assess risks within existing preordained categories germane to your enterprise.

2. Identify risks within existing preordained categories germane to your enterprise.
3. Quantify risks within existing preordained categories germane to your enterprise.
4. Assign the appropriate risk owners to risks within existing preordained categories germane to
your enterprise.
5. Evaluate the risks according to the approach prescribed in the risk management plan.
Your risk management plan includes the lexicon for high, medium, and low for probability. You
don’t agree with the definition of “low,” which is Saw it happen here once. You know of some
risks that are so significant that if they happen, the project (and perhaps the entire organization)
will collapse. You believe the term needs to be changed. Given your concern, what should you
do?
1. You should petition the project management office to change the definitions.
2. You are confusing probability and impact and should stick to whatever the organization
traditionally uses.
3. You should change the definition, because it’s your project’s risk management plan.
4. You should consult the risk owner, because they may have a different perspective.
5. You should flag risk events with low probability for further evaluation.
Your risk management plan notes that the tolerance for schedule is January first of next year.
Because of some weather-related delays, you are going to be extremely close to that line. On
December 15, you come to the realization that even if you work in superhuman fashion through
the holidays, the best you can hope for is to deliver the project January 2. When you notify
management, they tell you, “A tolerance is a tolerance!” What does that mean?
1. They will not be happy about the outcome of the project.

2. They believe the project should be escalated for review for termination.
3. You should go ahead with the project, recognizing that this could be the end of your career.
4. You need to put triggers in place to let you know if you’re right.
5. The thresholds were inappropriately set.
You want to be able to manage as many important risks as possible. But you fear your
interpretation of what’s important might differ from the opinions of the rest of the management
team. You want to, as the old nautical phrase goes, “Cover your aft.” What will you do to reflect
the relative levels of probability and impact to highlight which risks should be at the top of the
list?
1. Define the risks in extreme detail, ensuring that everyone has a common understanding of the
nature of the risk events.
2. Create a risk taxonomy to evaluate the different categories of risk and their relative
importance.
3. List those risks that you believe are the most important in the risk management plan.
4. Apply a risk matrix.
5. Gain the agreement and concurrence of the risk owner to support you in your efforts.
You are working with an Agile team to develop groundbreaking software. A few programmers
on the team know precisely what they’re doing and where the project is going. They are also the
first to confess that if the code isn’t written perfectly, the software could crash in dramatic
fashion. You are entrusting these people with your professional life. Even so, you want to make
sure they alert you when new risks to the software package evolve. What do you need to do to
prevent them from darkening your doorstep every time they find a new bug?
1. Have them report on all their problems at the daily scrum.
2. Tell them to fill you in on everything they did the previous day at the daily scrum.
3. Tell them to let you know what they will be doing today during the daily scrum.
4. Educate them on the risk matrix and the related terminology in the risk management plan.
5. Switch to a predictive model for building the software to minimize the risks.
Foundation Topics
Risk Sorting
In the process of developing the risk management plan, the project manager or the team might
have developed organization-appropriate categories. These are akin to the PESTLE model
mentioned earlier in Chapter 7, “Practical, Team-Based Risk Identification.” If the categories are
not preordained by the project office, they might be (and often are) project specific. A tool for
developing such categories is the affinity diagram. Although the affinity diagram (also discussed
in Chapter 7) is considered a tool for risk identification, it can also facilitate the development of
natural categories appropriate to the project.
The sorting process is important on a variety of levels. It allows the team to augment the list of
risks. Serving as a prompt list for risk, it can remind team members of risk areas that they might
have otherwise overlooked. Instead of simply asking, “What are the risks?” they can sort the
risks as they go by asking, “What are the political risks?” and “What are the environmental
risks?” and so on. Sorting also affords the ability to generate categorical responses to risk.
Although each risk will ultimately be examined individually, categories can provide blanket
solutions to risks. If the risk category is Schedule, there might be an overarching solution that
solves many schedule concerns. Extending the schedule by several months might open the door
to resolving (or at least managing) a whole host of risks.
Taxonomic Review
Risk taxonomies are carefully reviewed and studied risk categories. This is not a radically
different approach from a general risk sort, save that the taxonomy is generally owned by the
organization and is consistently applied across all projects. It’s a forced review ensuring
categorical consistency. Taxonomic reviews create a sense of consistency for an organization
with a specific risk orientation. If economic risks are a primary concern, a taxonomy built with
an extensive economic “branch” will serve those interests.
Taxonomies are laid out in either a hierarchical (family tree) format or in simple tabular outlines.
They apply the same principles as a risk breakdown structure, in that each category is divided
into subcategories to build out a comprehensive interpretation of the risk events on the project.
Taxonomies also support prompt lists, which are checklists of questions regarding the project
risk environment. Buried deep in an economic branch, the risk identified might relate to currency
exchange rates and the potential impact on supply chain costs. Are international conditions such
that the euro may fall below parity with the U.S. dollar? Every “yes” answer to such questions
generates at least one risk event. In this example, there are a host of risks (both threat and
opportunity) that can be derived.
In no other part of the risk management process does the risk management plan play such a
major role. Because the risk management plan describes how qualification is conducted, it serves
as a guide for establishing the language and the ranking strategies for risk. Terms such as “high,”
“moderate,” and “low” are defined in the risk management plan (RMP), as well as the
interactions between probability and impact, and how those interactions should be interpreted.
By way of example, the RMP will break down the qualitative means by which probability is
evaluated. It might look something like this:
High: Happens on more than half of similar projects.

Moderate: Saw it happen more than once within our organization.
Low: Saw it happen here once.
Remote: Has never happened, but it could.
Note that there are no numbers applied as yet; however, it would be easy enough to assign simple
numeric values for later analyses:
High: 3
Moderate: 2
Low: 1
Remote: .1
On probability, it’s possible to have organizational consistency, because it isn’t project specific.
Probability can apply across different projects and still have the same values.
Impact, by contrast, is project specific. Each project will have its own impact values, although
those values still can be qualitative in nature:
High: Catastrophic or total failure

Medium: Project outcome functional, but at or near tolerance
Low: Project outcome functional
These are simple examples of what might be applied in a 3×3 matrix. In a larger matrix (e.g.,
5×5), the definitions will inherently change. Note that the impact scale relies again on the RMP
information regarding project tolerances. Because of this, a single impact scale might be used for
time, cost, and/or requirements.
Again, like probability, some organizations like to apply values to the impact scale for a numeric
analysis of a qualitative condition. The scoring is different from probability in that each level of
impact is considered a full order of magnitude higher than the one before it. This example is for a
3×3 matrix, and again, the values would change in a 5×5 matrix.
High: 8
Medium: 4
Low: 2
Blending the scales is conventionally done in the tic-tac-toe format of a PxI matrix. This is
sometimes referred to as the risk matrix, and is shown in one format in Figure 11-1.
Figure 11-1 Probability-Impact Matrix (PxI Matrix)
The color coding speaks volumes regarding which risks should be considered the highest
priorities. Those in the “red zone” are clearly the risks that are highest in impact and have the
greatest probability of occurrence.
Anytime a single square in the tic-tac-toe chart (particularly the “red” quadrants) is
overpopulated, it could be a signal that another layer of evaluation needs to be applied. This
could be the high-medium-low from any of the other risk attributes, from proximity to urgency.
Urgency is the most common filter applied when a quadrant is supersaturated with risk events.
Urgency goes to the notion of how soon the risk event might occur or the last point at which the
risk event can effectively be managed.
The other common filter is detectability. For projects where the failure mode effects analysis
(FMEA) is being applied, this third dynamic is used consistently. The risk management plan will
explain scoring for the FMEA, because high detectability is a positive condition, whereas low
detectability (or invisibility) generates a higher level of risk.
When moving into three dimensions of risk, the graphic approach of a 3×3 box becomes more
difficult to apply, so most project examples will resort back to a simple spreadsheet, which is a
common tool in FMEA.
The risk management plan will dictate what information will be incorporated into the FMEA.
Like the risk register, the data set here can become expansive, incorporating multiple effects
from a single failure condition, as well as multiple levels of severity. Table 11-2 demonstrates
the simplest version of an FMEA.
Table 11-2 FMEA Table
Work Failure Failure Severity Cause/Probability Probability

Element Mode Mode (S) (P)
Outcome
Area of Conditions Nature of Score Conditions altering Score per

work where it the per likelihood RMP
impacted may occur outcome RMP
Document Documents No 6 Team members 7

as-built not effective may dislike the
condition properly as-built admin tasks
captured records
Note that on a sliding scale, a detectability score of 10 would mean that the risk event would be
completely invisible. A score of 1 would mean that it was always totally visible with no
additional effort. Ultimately, this helps generate the risk priority number (RPN), which is
severity times probability times detectability.
All the terminology for qualitative analysis, be it a basic PxI matrix (probability-impact) or a
more complex FMEA, will be catalogued in the risk management plan.
The risk management plan also spells out the timing of any risk qualification efforts. Timing
includes both the frequency of a qualitative review and the situations in which a review must be
conducted. As with so many other things in risk management, the general rule for reiteration is to
conduct it as follows:

When change occurs
The regular interval for a qualitative review is, at a minimum, halfway through the project. If a
project is planned for over a year, the review dictated by the RMP would likely be quarterly. For
a multiyear project, that could be as infrequent as semiannually.
Risk Ranking
Risks can be ranked in groups or as individual events.
Group Risk Ranking
When populating the PxI matrix, the obvious first choice for a highly ranked group of risk would
be the high-highs (high probability, high impact). Those in the upper-right corner of the matrix
are the obvious first choice of risks to be addressed.
The next in line would be the medium-highs (moderate probability, high impact). Some might
contend that the high-medium (high probability, moderate impact) risks should be equal, but
they’re not. Impact is a far more important attribute than likelihood. If the scores from the PxI
matrix are applied, a high-high has a score of 3 x 8 or 24. A medium-high has a score of 2x8 or
16. By contrast, a high-medium has a score of 3 x 4 or 12. This becomes important when a
project has only moderate risks, and the project team is working to ascertain those risks that are
worthy of attention and those risks they should deal with first. In the PxI matrix, the group might
not be just a single box. As in the display from Figure 11-1, a project team might see the highest
risks as any in the red area. Thus, there can be a relatively long list of risks that are considered
the most important for the project team or risk team to consider.
Group rankings have the advantage of being easily interpreted and understood. Explaining the
process for determining which risks are the most significant is easy.
Individual Risk Ranking
In some cases, however, it becomes important to determine which are the individual risk events
that pose the greatest threat or might generate the highest opportunity. In such instances, the
group risk ranking could be done first, followed by individual risk ranking. A variety of different
tools are available to establish the risk rank. In a qualitative environment, most of them involve
voting among team members. Some of the tools common to Agile management can be applied in
these cases:
Fist to five
Dot voting
Roman voting
Consensus
And from more conventional (waterfall) project management, an extension of the nominal group
technique (NGT) could serve for a qualitative rank as well.
Fist to Five
Whether in a live face-to-face meeting or in a virtual setting, the key with fist to five is to score
risks based on personal opinions of those present. After establishing the meaning of the scores
(Fist = Not worth worrying about; Five = A catastrophic risk that should be a top priority), team
members are presented with risk events, one at a time. With hand signals representing 0 to 5,
everyone in the meeting votes, as shown in Figure 11-2. The scores are added together, and the
team moves on to the next risk.
Figure 11-2 Fist to Five Technique
When the process is complete for all the risks under review, the scores are evaluated and a rank
order is established.
Dot Voting
In the dot voting process, each participant is given a preordained number of adhesive “dots” and
told that the dots represent the degree of concern associated with the individual risk events. The
individual risk events are listed on a screen or whiteboard. If each team member is given 20 dots,
for example, the team member might apply one dot each to 20 risks, or might apply 20 dots to a
single risk event (or anything in between). Team members then apply their dots at will, and when
all the dots are expended, the dot score for each individual risk is calculated and a rank order is
established.
Roman Voting
Roman voting is simply a binary decision-making event (with the option to abstain). In Roman
voting, each risk event is described, and all participants provide either a thumbs up or thumbs
down (as to whether the risk should be a priority) as shown in Figure 11-3. A thumbs up is a +1,
whereas a thumbs down is a –1. Participants may also choose to abstain on a particular risk,
which adds 0 to the score.
Figure 11-3 Roman Voting
When the voting is complete, scores for each risk are added and the rank order is established.
Consensus
Attempts to achieve consensus can sometimes generate risks on their own. Nonetheless, it is a
familiar process where team members meet and attempt to determine through healthy discussion
which risks are the most critical—which risks need to be addressed first. This is difficult for rank
ordering individual risks, because the nuances of understanding from one risk to the next shift
from team member to team member.

Nominal group technique (NGT) is associated more with Waterfall project management
(traditional, predictive project management) than with Agile. As discussed earlier in Chapter 7,
“Practical, Team-Based Risk Identification,” NGT is largely brainstorming on paper. The
difference here is that many NGT sessions are augmented by each team member getting a copy
of all the risks identified by the participants. Each team member then conducts a personal rank
order of the risk events, providing a personal perspective on which are the greatest concerns for
the enterprise. The facilitator can then, after the session, collect the scores for each individual
risk and tabulate a ranking from most concerning to least.
The ranking processes can work well if everyone understands the goal of qualitative analysis.
That goal is to create a sufficiently detailed ordinal rank for each risk to allow for reporting and
response. To succeed, stakeholders need to be well-versed in the approaches, the language, and
the tools applied to accomplish the goal.
This is most readily achieved by allowing the team members access to the risk management plan.
If they share a common language with the project team (or risk team), they can have a clearer
understanding of how and why risks are being approached in a particular way.
By simply sharing the risk categories and sources of risk, stakeholders gain a greater sense of
which risks are of the greatest concern to the project organization, and to which risks they should
be more attentive.
It’s not just a matter of sharing the lists with the stakeholders. Stakeholders need to know why
the sources are the sources and why the risks that are under consideration are of concern. To
share this information, it comes down to risk processes. The process for categorization (be it
history, affinity diagramming, classic models (e.g., PESTLE), or some other approach) affords
stakeholders clarity on whether the risk categories are truly project specific or whether they
represent a systemic approach to risk management.
found.
Key
Page
Topic Description
Number
Element
Section Risk Sorting 176
Section Taxonomic Review 176
Section Risk Management Plan Application 177
Paragraph The PxI (probability-impact) matrix is a classic risk qualification 178

tool. Through the use of a simple 3×3 or 5×5 chart, coupled with
colors to highlight the greatest concerns, the matrix allows
stakeholders to plot risks consistent with the qualitative terms
outlined in the risk management plan. The red zone most often
includes high-probability, high-impact and medium-probability,
high-impact risks, whereas the high-probability, medium-impact
risks are relegated to the yellow zone.
Table 11- FMEA Table 180

2
Section Risk Ranking 181
Section Stakeholder-Based Ranking Support 184
PxI matrix
risk matrix
failure mode effects analysis (FMEA)
fist to five
dot voting
Roman voting
consensus
nominal group technique (NGT)
Review Questions
You realize that only a small component of your project budget can be used specifically to
address risk strategies. You want to address the risks that are the most pressing but your
organization insists that you address the risks that are the least visible. As a result, you decide to
accommodate the organization by applying which prioritization approach?
1. Fist to five
2. Dot voting
3. Roman voting
4. Failure mode effect analysis
5. The PxI matrix
Your risk breakdown structure is now accompanied by a series of questions. The questions are
associated with each “branch” of the structure, trying to define the relative levels of risk
associated with the particular source in question. One of the questions is, Have you asked local
government authorities if there are any zoning considerations associated with the project and its
impact? What does this question address?
1. It’s a question about the economic considerations, built into the risk taxonomy.
2. It’s a question about the environmental impact, built into a risk breakdown structure.
3. It’s a question about the political considerations, built into a risk taxonomy.
4. It’s a question about the social considerations, built into a risk breakdown structure.
5. It’s a question about the social considerations, built into a risk taxonomy.
In your PxI matrix, you have plotted 34 risks. Some, particularly the low-lows, will never see the
light of day. You know that the 12 high-highs are crucial and will be scrutinized by management.
If you are able to manage the 12 high-highs well, which risks will you address next?
1. The high-medium risks

2. The medium-high risks
3. The most urgent risks
4. The medium-medium risks
5. None; you have done the important work
Laura was reviewing the risk management plan for the project and found a reference to schedule
tolerances.
Delays on critical path activities are unacceptable and are outside organizational tolerance.
She has two activities that are three days behind schedule, but still have a month before they’re
actually due. What action should she take?
1. Notify the project manager and risk manager immediately, because this could shut down the
project.
2. Work diligently to recover the lost time, knowing she’ll likely be able to recover.
3. Work diligently to recover the lost time, notifying her project manager and risk manager if
she realizes her efforts are in vain.
4. Ask for an extension.
5. Resign her position.
Which of the following statements are true? (Choose two)

1. A project team can use the fist-to-five technique to establish risk priority.
2. A project team can use a PxI matrix to generate a rank order of risks.
3. The risk register defines terms like high probability and low impact.
4. Roman voting allows team members to generate gradient preferences in terms of their
understanding of which risks are highest.
5. Dot voting allows team members to generate gradient preferences in terms of their
understanding of which risks are highest.
Your team has finally achieved consensus on the risk ranking. What does that mean?
1. The team unanimously agrees the rank order of risks is perfect.

2. The team may be split on the rank order of risks, but part of the group prevailed.
3. The rank order of risks is complete, and the team will accept the outcome.
4. The approach to the rank ordering of risks was done properly.
5. Consensus is never achieved in risk ranking. They don’t understand the term.
Your stakeholders want to be involved in the risk process, particularly the ordering of risk
priorities. You want to inform them of their role. What is that role?
1. Stakeholders review the priorities after the team has established them.
2. Stakeholders participate in determining the risk ranking.
3. The risk ranking is done by management.
4. The risk ranking is done by the project manager.
5. The risk ranking is done pursuant to a process, and they may or may not be involved.
Chapter 12
Risk Quantification

Many people look at risk as an endeavor with nothing but numbers. For those with that
perspective, this is the area of risk management that they find the most appealing. When data are
available, risk analysis using numerical manipulation provides an aura of certainty in a practice
that is anything but certain.
Risk quantification differs from qualification in that although qualitative risk analysis may use
numbers, those qualitative values are subjective (such as the 1-2-3 scoring systems). In
quantitative analysis, the numbers are objective, as with dollars, hours, or defect rates.
One of the major challenges with risk quantification is the amount of time and effort associated
with data gathering and data review. But when the data and the time are available, the outcomes
of risk quantification are often considered unassailable.
Even so, data shift over time. Values increase and decrease based on the environment, and
probabilities shift with the passing days. A quantitative analysis that was perfectly valid a few
weeks ago may have no merit today.
Also, quantification comes into play on a variety of levels. Some organizations want projectwide
analyses, whereas others expect monetary and time values at the individual risk event level. The
effective risk manager must be capable of dealing with both.
This chapter reviews the process of analyzing risk using numeric values, both for probability and
impact. It looks at that process both from the project and risk event perspectives.
Risk Analysis Task 2 Perform Quantitative Analysis
Performance Data and Its Implications 1, 2
General Versus Detailed Quantitative Analysis 3, 4
Sensitivity Analysis Tools 5, 6, 7
Relative Risk Weight and Priority 8
Caution
Your project is using the earned value technique to evaluate performance. To date, your Cost
Performance Index is 84%, and the Schedule Performance Index is 111%. In sharing this
information with management from a risk perspective, what can you tell them?
1. The project runs a high risk of being overbudget but a low risk of coming in late.
2. The project runs a low risk of being overbudget and a low risk of coming in late.
3. The project runs a low risk of being overbudget and a high risk of coming in late.
4. The project runs a high risk of being overbudget and a high risk of coming in late.
5. You really can’t provide any insights on the current status of the project.
You are working on an Agile Scrum project, and you have produced three minimum viable
products over the last six sprints. You are applying story points to all your user stories and
mapping progress in a burndown chart. Your team is completing about 21 story points per sprint,
against a planned completion rate of 19 story points per sprint. What does this indicate regarding
your schedule and cost risks?
1. Your velocity is increasing and should continue on that path. This means that although you
can’t speak to project cost, there’s a low risk of coming in late.
2. Your velocity is decreasing and should continue on that path. This means that although you
can’t speak to project cost, there’s a low risk of coming in late.
3. You have no project velocity, and you will likely run late on delivery.
4. Your velocity is increasing and should continue on that path. This means that there are low
risks of both cost and schedule overruns.
5. Your velocity is decreasing and should continue on that path. This means that there are low
risks of both cost and schedule overruns.
You want to identify the anticipated cost associated with a particular risk event, and to do so, you
have ascertained the probability and impact of that event. To evaluate that information, you can
build a numerical context applying which tool?
1. Monte Carlo
2. Expected monetary value
3. The PxI matrix
4. The risk matrix
5. The venture evaluation review technique (VERT)
You have a project where you have constructed both venture evaluation review technique
(VERT) and graphic evaluation review technique (GERT) charts. It was a major undertaking to
put them together. Why would you do this?
1. To generate a sense of which activities in the network pose the greatest risks.
2. To get a projectwide view of the likelihood of certain schedule outcomes based on
probabilistic branching.
3. To get an activity-by-activity view of the likelihood of certain schedule outcomes based on
absolute branching.
4. To get a projectwide view of the likelihood of certain schedule outcomes based on absolute
branching.
5. To get an activity-by-activity view of the likelihood of certain schedule outcomes based on
probabilistic branching.
You brought in a Monte Carlo expert to evaluate the potential project outcomes. She established
all the basic information necessary to create an effective Monte Carlo analysis and ran 1,000
simulations. Did she run enough simulations, and what information did she have to have going
into the analysis?
1. She ran enough simulations, and all she needed were task durations and costs.
2. She ran enough simulations, and she needed the range of possible task durations and costs, as
well as the potential distributions of those ranges.
3. We don’t know if she ran enough simulations because we don’t know how big the project
was, and all she needed were task durations and costs.
was, but she needed the range of possible task durations and costs, as well as the distributions
for those ranges.
was, and all she needed were task durations and costs.
In examining the probability distribution function provided in the following figure, what is the
likelihood that the project will be complete by March 27?
1. 9.1%
2. Less than that of the mean completion date
3. Less than 50%
4. 90%
5. Higher than the likelihood of completion by April 1
You are working with Monte Carlo analysis to determine the likelihood of completion associated
with your project and its target dates. Based on the task information box provided in the
following figure, which of the following statements about “Task 7 – Normal” are true?
1. It will be complete in 7 days.

2. It’s a normal distribution with a median of 7 days.
3. It is being evaluated in the Monte Carlo using a Beta (or BetaPERT) distribution.
4. It will be completed in a range between five and nine days.
5. It’s a triangular distribution.
You are working on a project where your supervisor consistently tells you that quality, cost, and
time are all crucial to the project’s success. You’ve identified three major risks. One will have a
dramatic impact on quality. The next will have a major impact on time. The third will have a
huge impact on cost. You have a significant concern, because you only have enough staff and
funding to manage one of the three. You believe you should manage the one that has the greatest
relative weight.
Although expected monetary value seems a logical approach, you realize that it doesn’t address
all three of the aspects that your supervisor has determined are the crucial attributes. What should
you do?
1. Use expected monetary value, because it’s the only logical way to assess relative weight.
2. Set your own values for time, cost, and quality, and use them to determine the most crucial.
3. Ask your supervisor how they would like to have them weighted.
4. Refer to the risk management plan to determine how the weighting should be conducted.
5. Apply a triangular distribution to make the determination.
Foundation Topics
Projects should produce a wealth of performance information, and the data generated should
provide signs as to the risks on the horizon or those threats already realized (issues). In many
instances, however, project managers fail to look at the data as their proverbial “canary in the
mine,” and miss the early signs that a project is either underperforming or is about to
underperform.
The data come in a variety of different forms and formats, and the key is to recognize which data
sets are among the most predictive in the quantitative sphere.
The most notable difference in the data sets comes from the type of project model being applied
—waterfall (traditional) or Agile.
Waterfall Performance Data
The classic waterfall performance data are earned value metrics. Each metric has its own
implications in terms of quantifying risk. The primary data points in the earned value technique
include the following:
Budget at completion (BAC)

Planned value (PV)
Earned value (EV)
Actual costs
Schedule variance (SV) and schedule performance indices (SPI)
Cost variance (CV) and cost performance indices (CPI)
Estimates at completion (EAC)
To-complete performance indices (TCPI)
For each, there are the implications of the numbers themselves, as well as the implications of the
numbers when considered in light of other data and trends, as well as project timing. As a
general rule, predictive metrics in earned value begin to have integrity only after 20% or more of
the project’s earned value is accomplished. The sections that follow describe these primary data
points in more detail.
Budget at Completion
The budget at completion (BAC) is, as it sounds, the total budget assigned to a project. This
budget is normally derived from the aggregate costs of the work packages for the project.
Examined over time, the costs create a performance measurement baseline, which at the end of
the project is the budget at completion. From a risk perspective, it’s the benchmark that should
be achieved in terms of overall project spending. It includes contingent reserves and should (in
the ideal) be relatively consistent throughout the life of the project. It’s insight that will
ultimately send signals for the risk management plan developers to establish the threshold and
tolerance for cost. The BAC is set early in the project and is adjusted only when alterations are
made through the formal change management process.
Planned Value
The planned value (PV) is a timing value. It’s how much money was to have been spent as of a
given point in time in a project. From a risk perspective, planned value is a number of great
concern to finance and accounting personnel. When projected over time, it represents the timing
(or burn rate) on how much money will be spent as of particular points in time. Planned value
should be explained to project team members in that they may see distinct advantages to moving
work ahead on the schedule, but may not realize the risk of alienating finance personnel by
overspending against the planned burn rate of money. Planned value represents a snapshot of an
amount of total spending planned by a given point in time. And when the project is at or past its
scheduled completion date, the planned value should equal the budget at completion.
Earned Value
Earned value (EV), as the name implies, is the cornerstone of the earned value technique. It
represents the original planned spending for the work performed. That distinction is critical
because the moment work is done, it earns “credit” under an earned value system. If we are
earning value more rapidly than anticipated, that condition is normally considered good news. If
we are earning value, but it’s costing more than anticipated, that’s seen as bad news. In all earned
value quantification, the earned value will be an element of consideration. If a work package is
expected to cost $3,000, when it’s done, it will have an earned value of $3,000. If it’s only
halfway complete, its earned value will be $1,500 (one-half of $3,000). Earned value represents a
snapshot of an amount of total work performed by a given point in time. When the project is
complete, the earned value should equal the budget at completion.
Actual Costs
The actual costs are among the most difficult values to track in a performance management
system. Many organizations can track actual materials costs, but labor costs are much more
challenging to keep track of. An inability to track actuals can severely inhibit the ability of the
project or risk manager to actively evaluate progress or consumption. Such an inability can be an
early warning sign that the organization will be less than capable in terms of being able to
evaluate the efficacy of cost control practices. It might also indicate that triggers will be
overlooked.
Schedule Variance and Schedule Performance Index
The formulae for the schedule variance (SV) and schedule performance index (SPI) metrics are
quite simple:
SV = EV – PV
SPI = EV/PV
Note that earned value comes first in earned value performance metrics. For these values, the
simple mantra of “Negative is bad, and positive is good” is sufficient for evaluation purposes.
Seeing negative or subpar numbers here should be considered an early warning that project
schedule performance is slipping and could be an indicator of future slippage as well. It’s
noteworthy that when a project is complete and past its scheduled completion date, these
indicators actually tell the tale that schedule risk is moot. Any project that is complete and past
its scheduled completion date will have a schedule variance of 0 and a schedule performance
index of 1.0.
Cost Variance and Cost Performance Index
Much like SV and SPI, the formulae for the cost variance (CV) and cost performance index
(CPI) metrics are not daunting:
CV = EV – AC
CPI = EV/AC
Again, earned value comes first in these earned value performance metrics. The same mantra of
“Negative is bad, and positive is good” applies here, as well. Seeing negative or subpar numbers
here should be considered an early warning that project cost performance is slipping and could
be an indicator of future slippage as well. Although the schedule metrics eventually become
moot, the cost metrics survive the end of the project and remain as a lingering performance
reminder.
Estimate at Completion
Estimates are fluid. In light of that fluidity, the estimate at completion (EAC) value can be used
as an early warning sign that a project will be modestly (or wildly) overbudget. One of the most
concerning aspects of the EAC is that it can be calculated in a variety of ways, leading to
different conclusions about the degree of risk the project might still face. The three primary
approaches yield different outputs. Those approaches include one that indicates that past
performance is indicative of future results.
EAC = BAC/CPI
In a project with a $4,000,000 budget, an earned value of $1,000,000, and actual costs of
$1,250,000, this approach would suggest that the final project costs will be $5,000,000. That’s
$4,000,000/($1,000,000/$1,250,000) or $4,000,000/.8 which drives to a $5,000,000 estimate at
completion. A number that high would imply the project is overspending and will continue to
overspend at the current rate.
The second common approach is one where it is determined that past performance was
anomalous. There were extenuating circumstances that drove us to our current spending, but the
remaining spend on the project will be per the original plan. In a project where a hurricane
caused overspending late in the hurricane season, the project team is likely not expecting the
hurricanes to continue. Formulaically, that looks a lot different:
EAC = BAC – EV+AC
It’s the work remaining plus the actual costs to date. Using the same scenario, it’s $4,000,000 –
$1,000,000 + $1,250,000. That changes the estimate at completion to $4,250,000, which is
radically different from the previous scenario. All that changed were the assumptions and the
mathematical approach. From a risk perspective, this can either be seen as more honest or as a
means to hide the behaviors that led to earlier cost overruns.
The third approach is far less common but takes into account both cost and schedule
performance metrics. It assumes that delays or aggressive schedule performance will have a
direct impact on cost performance, and whatever trends are in place will continue and will be
exacerbated moving forward:
EAC = ((BAC – EV) / (CPI * SPI)) + AC
Applying the same values as before (and assuming a planned value of $4,100,000), the numbers
look quite different: (($4,000,000 – $1,000,000)/(.8 * .975)) + $1,250,000, which equals
($3,000,000 / .78) + $1,250,000 or a final value of $3,846,000 + $1,250,000, or roughly
$5,100,000. Note that any of these numbers can send risk signals that might or might not provide
additional value.
To-Complete Performance Index
From a risk management perspective, the to-complete performance index (TCPI) might be the
most valuable of the earned value performance metrics. The TCPI answers the question of
whether the project might be salvageable given performance to date and the amounts of time and
money remaining. In plain English, the formula is simply
Work remaining/Money remaining

In earned value terminology, that would be expressed as
TCPI = (BAC – EV) / (BAC – AC)
For the example thus far, there is $3,000,000 worth of work yet to be completed. There is
$2,750,000 remaining in the budget. So that $3,000,000/$2,750,000 or 1.091. Historically on this
project, the cost performance has been 80%. Moving forward, the project has to achieve 109%
performance to bring it in on budget. The probability is that will not be achievable. This
performance metric provides a sense of the degree to which project performance must shift in
order to recover.
Agile Performance Data
Although earned value data is the standard of predictive project management, those data are not
readily available in the Agile environment. More commonly in Agile, metrics are determined by
the completion of user stories, story points, or sprints.
Sprint Completion
Sprint completion is one of the broader metrics in Agile, because sprints basically mark the
passage of time. Because each sprint should, hypothetically, produce a deliverable of value, and
because the team remains intact, sprint completion should indicate a degree of project progress.
Whether user stories are completed as planned is not germane to sprint completion. It is simply a
measure of whether the time elapsed with work (and daily reviews) conducted. This ties to risk
in our ability to see that the work was conducted and the team held their daily scrums as planned.
Also, because the end of each sprint is highlighted by a retrospective (lessons learned and
product outcome review), sprint completion serves as important performance data, with a
growing repository of retrospective information available.
User Stories Completion

Although still a broad metric, user story completion is more performance oriented than sprint
completion. User stories come in a variety of sizes, with some representing significant levels of
effort and others representing relatively simple accomplishment. Each story represents some
degree of accomplishment, and because of the framing of user stories, the fact that they are
complete represents some degree of risk minimized.
User stories are written as:
[Persona] needs [Outcome] because [Rationale]
For example, this would translate into:
Field team members need personal protective equipment because they face physical perils
while validating the site.
The performance information associated with user story completion is a degree in risk reduced,
because a number of things happen each time a user story is finished:
1. A user’s need is met.

2. A deliverable is successfully produced.
3. A threat condition is eliminated or minimized.
This performance information is normally displayed in a burndown chart (as shown in Figure
12-1), which can provide an at-a-glance perspective on performance trends.
Figure 12-1 Burndown Chart
Assuming that the solid line represents planned performance, and the dashed line represents real
accomplishment, as of the end of Sprint #4, there are some clear risk indicators:
Based on current trends, user stories are not being accomplished as quickly as planned.
Velocity on the first four sprints is lower than anticipated.
Unless trends shift rapidly, the project will likely be late.
If there are specific causes that are driving the delays, they should be explored.
Story Point Completion
Not all burndown charts evaluate user story completion. Some evaluate the finer element of story
points. Each user story has, at a minimum, one story point. That story point represents the level
of difficulty or challenge associated with the work to be done to produce the user story outcome.
A user story with a single story point would be the easiest to accomplish. A user story with ten
story points would be seen as at least ten times as challenging. The interpretation of the
burndown chart would largely be the same as it would be for user story completion.
The Agile environment does not lend itself to the highly quantitative analysis of practices such as
earned value management. Because story points are most often subjective values, the burndown
chart using these values has the distinction of being labeled a quantitative tool in a qualitative
environment. Story point completion provides an opportunity to examine the risk of not
accomplishing work in a timely fashion or if there are opportunities generated by a higher
velocity and a potential early end date.
Quantitative analysis can be done at the whole-project level or task by task. On a whole-project
perspective, the concept is to generate information about the likely outcomes for the project as a
whole. On the detailed level, the idea is to generate the cost and time information about
individual elements of work (user stories or work packages). Each has its own applications and
merits.
General Analysis
The single most significant tool for general quantitative analysis is Monte Carlo. Monte Carlo
simulations take into account a variety of different data points regarding outcomes and simulate
how any given scenario may turn out. The simulations rely on range estimates for each work
element in a project, and then simulate how one version might ultimately turn out. The process is
then repeated hundreds or thousands of times. The simulations are then plotted on a graph as a
probability distribution function (PDF), as shown in Figure 12-2.
Figure 12-2 Probability Distribution Function for a 1,000-Simulation Monte Carlo
In this example, only a few iterations of the simulation came in on or before March 17. This is
indicated by the dark black line that begins its significant ascent about March 19. That black line
that ascends from left to right highlights the quantitative likelihood of achieving the project
completion by the dates in question. The percentage of simulations that are represented by the
line are on the right of the graphic. By March 25, there’s a 50-50 chance the project will meet
that as a target completion date. By March 27 or 28, completion is a virtual certainty.
The percentages on the left side are related to the number of simulations that the Monte Carlo
generated for each date under analysis. March 25 (the tallest bar), came in as the completion date
on more than 1/5 of the simulations conducted. On March 27, 9.1% of the simulations were
complete. Although only one or two simulations were complete on April 3, by that time the
probability of whole-project completion hits 100%. No simulations were calculated that
exceeded that point.
A note about Monte Carlo simulation calculations: There are two largely applied approaches for
Monte Carlo tools to generate random samples. The classic Monte Carlo uses computing power
to select the random output for each individual work package each time. The Latin Hypercube
approach is not entirely random, thus technically making it not a Monte Carlo analysis. Latin
Hypercube ensures that at least one variable changes in each simulation, eliminating the truly
“random” element of a Monte Carlo. There are no two identical simulations in a model
deploying Latin Hypercube. Although this distinction might seem minor, the Latin Hypercube
can achieve a credible output with fewer simulations than a traditional Monte Carlo. Risk
managers might apply the Latin Hypercube to speed up the analysis or to overcome a situation
where the mode of the probability density function is extreme.
A far less common (and far less labor-intensive) approach for general whole-project analysis is
the program evaluation review technique (PERT), which can be applied at both the project level
and at the detailed work element level.
At the whole-project level, PERT provides a very quick accounting for the best- and worst-case
cost or schedule scenarios, using a technique that accounts for the best and worst cases, with a
heavy emphasis on the most likely outcome. The math is simple:
Optimistic+(4 MostLikely)+Pessimistic
Optimistic+(4 MostLikely)+Pessimistic
PERT Mean = 6
By way of example, a project with a best case duration of 140 days, a most likely duration of 150
days, and a worst case of 220 days would play out as
140+600+220
6
The PERT analysis provides a project mean duration of 160 days, which is known as the PERT
mean (or BetaPERT mean).
Because PERT uses a consistent set of practices to establish the mean, this simple approach can
be used to apply normal distribution traits to what is basically a triangular distribution. The
triangular distribution is represented by the three data points of PERT. In a normal distribution
(the classic bell curve), the analyst can use standard deviations to determine the likelihood of
given outcomes.
PERT standard deviation is calculated as:
−Optimistic
PERT SD = Pessimistic6
The PERT standard deviation for the sample scenario is
220−140
6
Or 13.333.
Using the sample scenario, the bell curve center would be the PERT mean, as shown in a normal
distribution in Figure 12-3.
Figure 12-3 Normal Distribution
Going out one standard deviation represents 68% of the possible outcomes for this project. The
68% is not calculated. It’s a “given” in statistics. By adding and subtracting one standard
deviation from the mean of 160, the bell curve indicates the 68% likelihood of the outcome as
shown in Figure 12-4.
Figure 12-4 Normal Distribution with One Standard Deviation Highlighted
This indicates that there is a 68% chance of completing the project between Day 146.7 and Day
173.3. The 68% value is a given of statistics. Anytime you identify a single standard deviation in
any normal distribution, the range created by adding one standard deviation and subtracting one
standard deviation from the mean represents 68% of the possible outcomes.
A second standard deviation represents 95% of the possible outcomes for the project. By going
out one more standard deviation, 95.5% of the outcomes can be displayed, as shown in Figure
12-5.
Figure 12-5 Normal Distribution with Two Standard Deviations Highlighted
This indicates there is a 95.5% chance of completing the project between Day 133.3 and Day
186.6.
A third standard deviation represents 99.7% of the possible outcomes for the project. By going
out one more standard deviation, 99.7% of the outcomes can be displayed, as shown in Figure
12-6.
Figure 12-6 Normal Distribution with Three Standard Deviations Highlighted
This indicates there is a 99.7% chance of completing the project between Day 100 and Day 200.
PERT analysis at the project level provides rough ranges of duration (or cost).
There are two other approaches related to, but not as simple as, PERT. They are the venture
evaluation review technique (VERT) and the graphic evaluation review technique (GERT). Both
are supported by precedence diagrams, but for these, the probabilities are not rooted in a normal
distribution. For the PMI-RMP®, you need to know only that they are probabilistic network
diagrams with branching.
Detailed Analysis
Detailed quantitative analyses can examine the potential cost or schedule impacts of individual
risk events. The most common convention for detailed quantitative analysis is expected
monetary value (EMV). Expected monetary value incorporates the two elements of probability
and impact, and through multiplication, generates a target value. As with qualitative analysis, it’s
simply probability times impact (PxI).
For detailed analysis, the impact of the risk is normally calculated using the worst-case realistic
scenario. In a situation where a large, old-growth tree is beginning to lean toward a residence, the
cost impact would be evaluated based on the cost of repairs to the residence, not to the cost of a
lawsuit from a visiting relative who happens to be injured in the fall. While the latter is plausible,
it’s not a realistic scenario for evaluation. If an arborist determines there’s a 10% chance of the
tree falling in the next year, and the cost of repairs would be $100,000, the EMV for the risk
event would be 10% of $100,000. $10,000 is not a cost that will ever be incurred. But it is a
reasonable amount to apply in mitigation, transfer, or other risk response.
With risk as both opportunity and threat, a scenario that takes multiple risks into account in a
detailed analysis may be considered from both perspectives. If the project is the purchase of a
home for $500,000, there might be a threat of a flooded basement. There might be an opportunity
of discovered riches in the wall. If the home is valued at $500,000, the analysis should take both
the opportunity and threat into account:
VALUE = $500,000
Flood Threat = $40,000 in repairs. Probability 20%. Expected Monetary Value = $40,000 * .2
= –$8,000
Riches Opportunity = $50,000 in lucre. Probability 5% EMV = $50,000 * .05 = +$2,500
The total value of the home is decreased by $8,000 for the EMV of the flood. The total value of
the home is increased by $2,500 for the EMV of the riches.
The EMV of the home is $500,000 minus $8,000 plus $2,500. That’s $494,500.
It’s important to understand that EMV can be assessed both for value and cost.
By way of example, the same project from a cost, rather than value, perspective goes the other
way:
COST = $500,000
Flood Threat = $40,000 in repairs. Probability 20%. Expected Monetary Value $40,000 * .20
= +$8,000
Riches Opportunity = $50,000 in lucre. Probability 5% EMV = $50,000 * .05 = $2,500
The total cost of the home is increased by $8,000 for the EMV of the flood. The total cost of the
home is decreased by $2,500 for the EMV of the riches.
The EMV of the home is $500,000 plus $8,000 minus $2,500. That’s $505,500.
That distinction is noteworthy because some managers prefer to express risk in terms of the
value of the project, whereas others are cost focused.
The most powerful sensitivity analysis tool has already been discussed, but not in this context.
Sensitivity analysis applies to the ability of the risk manager to examine the impact of single
changes in the larger context of the entire risk environment. The most powerful (and accurate) of
these tools is the Monte Carlo analysis. Others include network diagrams, Ishikawa diagrams,
and decision trees.
Monte Carlo Sensitivity Analysis

What if? That is the classic question of sensitivity analysis, and it is rooted most deeply in Monte
Carlo reviews. Monte Carlo works from range estimates for all the work elements within a
project, and as such, mirrors the impact each of those elements has on the project. Suppose,
however, that a single work element changes. Originally, it was to be staffed by one of the best
and brightest team members, who believed it could be accomplished within a narrow range of
cost and time. Enter management, telling the project manager that the best and brightest will not
be available but instead will be replaced with a newcomer who has little background on the work
element in question. The range estimate for the newcomer’s tasks will expand. The distribution
of possible outcomes for that same work element will be lower and wider. A new Monte Carlo
analysis of the project as a whole can be conducted, and the probability distribution function will
change, possibly dramatically.
Tornado Diagram
In some instances, the output of a Monte Carlo analysis (in addition to the probability density
function) is a tornado diagram. As shown in Figure 12-7, the tornado chart highlights the
activities that have the highest level of sensitivity. These top-of-the-tornado activities are the
activities that are driving longer durations in this project example.
Figure 12-7 Tornado Diagram

In this scenario, finding ways to minimize the variability of tasks 8 and 4 would have the greatest
influence on the schedule outcomes.
Network Diagram Sensitivity Analysis (Critical Path)
Although not providing multiple simulations, a critical path network diagram affords risk
managers to examine the relative impact of a shift in duration for any given activity. For a simple
network like the one in Figure 12-8, critical path analysis is achieved by simply adding together
the durations for each path through the network and determining which is the longest. In this
scenario (assuming that each work element’s duration is identified in the center of the node), the
longest path is 18 days (Path 8-7-3).
Figure 12-8 Precedence Diagram
However, the 8-6-3 path of 17 days is only one day away from being critical. Because it’s a path
that is the closest to being critical without being critical, it’s called a near-critical path. In a
quantitative analysis of the schedule, the critical path gets the most attention. The near-critical
path gets the second-most level of attention. Any remaining analysis will be invested in other
subcritical (e.g., non-critical) paths.
For a complex network, this type of analysis is addressed effectively by most Monte Carlo tools,
as well.
Ishikawa Diagram Analysis (Root Cause)
Ishikawa diagrams go by a variety of names, as discussed in Chapter 7, “Practical, Team-Based

Risk Identification.” In terms of quantitative analysis, the key application of the cause-and-effect
diagram is sheer volume. Working across the branches to evaluate the causes of the causes of the
causes of the causes of the major impact, a quantitative analyst will look at the repetition of
particular causes on multiple branches. If a given term shows up on five branches and another
shows up on four branches, quantitatively, the five-branch risk cause “wins” because it has more
sources.
Decision Tree Analysis
Decision trees employ expected monetary value to determine the weight of the branches.
Decision trees are the graphic display of singular choices and the risk impacts and probabilities.
Figure 12-9 illustrates the choice between two airlines based on their fees, and the $500 cost of a
two-hour or more delay. The first branch highlights the choice, which makes Airline P appear to
be the better choice:
Figure 12-9 Basic Decision Tree
If the early/late impact of a two-hour delay is $1,000, that will occur after the event transpires.
Airline C has a 90% on-time rating, whereas Airline P has a 60% on-time rating. That would
now be displayed on the outer branches of the decision tree, as illustrated in Figure 12-10.
Figure 12-10 Decision Tree with Event Probabilities and Costs

For each branch, the expected monetary value (EMV) of the outcome can now be displayed to
the right, as shown in Figure 12-11. The $540 EMV is derived as a 90% chance of a pure $600
outcome, the $60 EMV is derived from 10% of the $600 outcome, and the $100 EMV is 10% of
the $1000 late arrival cost. The sum of the EMVs is $700. The $240 EMV is derived as a 60%
chance of a pure $400 outcome, whereas the $160 EMV is derived from 40% of the $400
outcome. The $400 EMV is 40% of the $1,000 late arrival cost. The sum of the EMVs is $800.
Figure 12-11 Decision Tree with Probabilities and Costs and Expected Monetary Values
In the original choice, Airline P was the less expensive choice. When considering EMV, Airline
C is now less expensive than Airline P by a full $100. The decision tree analysis is a means to
display this information that is visually informational and appealing.

When quantitative values are readily available, setting risk weight and priority is simple. More
expensive risks are a higher weight and priority. Risk events that directly impact the end date of
the project are higher weight and priority. About the only major challenge with using
quantitative values for weight and priority is the question of which is more important—time or
cost? That answer should be addressed in the risk management plan with all the other definitions
in the risk lexicon for the project. Whatever definitions appear in the RMP, they need to include
information on how the metrics will be collected, reviewed, and applied, and how the metrics for
one attribute (such as time) will be assessed against other attributes (such as cost and quality).

found.

Topic Number
Element
Section Waterfall Performance Data 197
Section Agile Performance Data 201
Section General Analysis 204
Paragraph The program evaluation review technique (PERT) uses a simple 205
weighted average that can readily convert a triangular
distribution (Best Case, Worst Case, Most Likely) to be
interpreted as a normal distribution.
Section Detailed Analysis 209
Section Sensitivity Analysis Tools 210

performance measurement baseline
planned value (PV)
earned value (EV)
actual cost
schedule variance (SV)
schedule performance index (SPI)
cost variance (CV)
cost performance index (CPI)
estimate at completion (EAC)
burndown
Monte Carlo
program evaluation review technique (PERT)
expected monetary value (EMV)
sensitivity analysis
decision tree analysis
Review Questions
You are on a predictive project where management wants to know if there are moments when the
project runs the risk of running overbudget. They stress that they want to see specific hard data
metrics that illustrate the degree of the risk based on performance to date. You should
recommend which approach?

2. Burndown charts
4. An earned value management system
5. PERT
Your Agile meetings have been going well, and at the end of the project sprints you have been
capturing the completion of user stories and have been reflecting on the completion of those user
stories in contrast to the planned levels of accomplishment. Management wants to be able to see
the risk trends based on that information. You should recommend which approach?

2. Burndown charts
4. An earned value management system
5. PERT
You are reporting to management on the following figure. What can you tell them?
1. If you are given until March 27, there’s a 90% probability the project will be completed on
that day.
2. If you are given until March 27, there’s a 90% probability the project will be completed by
that day.
3. If you are given until March 27, there’s a 9.1% probability the project will be completed by
that day.
4. There is a high probability the project will be accomplished by March 20.
5. There is a low probability the project will be accomplished by April 2.
You are applying expected monetary value for some of your more significant risk events. One of
the risks you have identified is that you may encounter a power outage of more than 24 hours,
incurring costs of $500 for food replacement and alternative heat. The odds of such an outage are
about 5% at any given point in time. What is the EMV for this event?
1. $500 in additional value

2. $2500
3. $25 in additional value
4. $500 in additional cost
5. $25 in additional cost
Which two of the following statements are true?
1. A near-critical path is any path that is less than critical.

2. A subcritical path is any path that is less than critical.
3. A near-critical path is the path closest to being critical without being critical.
4. A subcritical path is any path close to being critical without being critical.
5. The critical path is the path with the least schedule sensitivity.
In the illustrated decision tree, what’s the expected monetary value of our choosing Airline P?
1. $400
2. $800
3. $1200
4. $1400
5. Can’t be determined without more information
You have just replaced three of your most skilled workers on the project with three total
newcomers who have never worked with the technology before. In examining the probability
distribution function and its overall “look,” what would you expect to have changed?
1. Nothing.
2. The apparent curve of the function would be more centered toward the mean.
3. The apparent curve of the function would be less centered toward the mean.
4. The number of iterations would increase in this analysis.
5. The number of iterations would decrease in this analysis.
Chapter 13
Risk Complexity, Assessment, and Analysis
Risk Complexity
In all the analyses discussed to date, risk impact is king. Risk impact is the degree to which a
given risk event will do damage (or help) the project objectives. Conventionally, the impact is
expressed in financial terms or in terms of timing. But impact can address everything from public
acceptance to long-term organizational strategy.
Impact also can be directly affected by human understanding. It is often difficult to express
impact for the unknown-unknown risks, because information on such risks is impossible to come
by. For example, during the COVID-19 pandemic, the impact to human health was complex, but
understandable. The impact to traditional education was completely outside most analysts’
understanding early in the pandemic.
That also points to other aspects of impact, including compliance concerns and the
interconnectedness of risk. For almost every risk event, positive or negative, there are cascading
events that need to be taken into account.
This chapter reviews the variety of impact considerations in any risk analysis.
This chapter addresses the following objectives from the PMP-RMP® Exam Content Outline:

Risk Analysis Task 3 Identify threats and opportunities
Risk Complexity 1, 2
Risk Interconnectedness 3, 4
Risk at the Organizational Level 5, 6, 7
Threat Versus Opportunity 8
Caution
You are working on an Agile project that has never been attempted before. Everything about the
project is new. The team hired for this effort has never worked for your organization and has
never worked together. The requirements are unclear and the technical uncertainty is high. Per
the PMI® Agile Practice Guide, what can this project be considered?
1. In chaos and fundamentally risky

2. Complex and will respond well to adaptive approaches
3. In chaos, and will respond well to adaptive approaches
4. Complex and fundamentally risky
5. You really can’t provide any insights on the current status of the project.
You are working in a predictive project management environment. Even so, the project has
tendrils that reach well beyond your organization, and there are six vendors you will be dealing
with on a regular basis. The project is being performed across three geographies, with team
members speaking four languages. To manage this high level of complexity, what should you
do?
1. Gather risk information and data as early as possible from as many sources as possible.
2. Identify a subproject manager to facilitate efforts in the other geographies.
3. Meet regularly with the vendors.
4. Minimize the project velocity.
5. Learn all four languages.
You just learned that two of your best team members are about to resign. If they go at the same
time, you’ll need to hire replacements in the near term. Although your organization often finds
great talent, it normally takes a lot of time, and multiple hires are very uncommon. In talking
with Human Resources, they inform you that you’ll want to move fast because a hiring freeze is
coming at the end of the year. That freeze could last for months. If you put too much strain on
the existing team, some of them might also decide to resign. What should you do?
1. Talk the two team members out of resigning.

2. Recognize the situation as high complexity and begin looking for the root causes of these
cascading risks.
3. Determine the highest priority risk from this high complexity environment.
4. Defer to Human Resources for all these concerns.
5. Build a decision tree to determine the lowest-cost alternative.
You had the honor of working with Robert Ballard in his search for the HMS Titanic. In that
time, you learned that the binoculars that should have been in the crow’s nest to warn of icebergs
were locked in a cabinet below decks. The key to the cabinet was still back in Ireland. It was left
there because the Titanic crew was replaced by a crew from the Olympic (Titanic’s sister ship).
The original Titanic team member who had the key only discovered the key after he got home
(and lost a few weeks’ work). He didn’t perceive his possession of the key as a major
consideration. The fact that the key on that desk could have stopped one of history’s great
tragedies is a classic example of what?
1. The need for a risk register to cover all risks, great and small.
2. The interconnectedness of risks that independently might not seem important, but when they
cascade they take on higher significance.
3. The complexity of risk, particularly when there are a lot of independent events.
4. The need to reduce risk at all levels of an endeavor.
5. The need for an activity-by-activity view of the impact of certain risk events.
You are not a big believer in the “Save the Cockroach” campaign. You believe they will do a
great job of saving themselves. But there’s a new insect activist group that your organization is
supporting with fervor. When management announces a “Roach Buffet” in the office kitchenette,
you believe some of your team members might resign from the project. You fear, however, that
if you bring it up to management, they might take umbrage and treat your project team unfairly.
What should you do?
1. Affirm the corporate view, and eat with the roaches.

2. Affirm the corporate view, and offer team members the means to work on the project without
countering management’s objectives.
3. Explain the problems associated with the corporate view to your management, and ask them
for alternatives.
4. Explain the problems associated with the corporate view to your team, and ask them for
alternatives.
5. Bring pesticides.
You build homes. As such, you and your team must follow the local building codes wherever a
construction project is underway. Those local codes dictate that the construction on your latest
project must be done using Acme Concrete for all foundation work. You have never used Acme
products because your corporate motto includes the phrase “ANYONE but ACME.” You have to
come to a resolution. Where do you start?
1. You have the procurement staff contact Acme to order the concrete.
2. You contact management to explain that you have to use Acme.
3. You order concrete from your regular vendor because the vendor wasn’t specified in the
contract.
4. You contact management to determine whether strategic or regulatory compliance is more
important.
5. You contact the client to determine whether strategic or regulatory compliance is more
important.
Your organization has an outstanding project management office. It has powerful oversight and
is largely considered a directive PMO. Your C-level managers are totally supportive. They
believe projects are the backbone of the organization. Team members are hired into your
organization only when they have a project management credential like the PMP® or the
CAPM®. Who is considered accountable and responsible for project governance, including risk
governance?
1. C-level management
3. The project manager and the team
4. The project management office
5. It is project specific
When it comes to the potential impacts of risks to project objectives, you have been told to be
comprehensive in your assessment. This means that your impact analysis should take a variety of
attributes and project objectives into account.
Your understanding of comprehensive should include which of the following?
1. Scope, cost, and schedule

2. Scope, cost, schedule, resources, and quality
3. Cost, schedule, resources, quality, and stakeholders
4. Scope, cost, schedule, resources, quality, and stakeholders
5. Scope, cost, schedule, quality, and stakeholders
Foundation Topics
Risk Complexity
Risk management is considered a cornerstone of handling project complexity. Complexity is

defined as the quality of being complicated. Risk management is essentially designed to
uncomplicate, to the degree possible, project conditions. To achieve that, the degrees of
complexity must first be examined. Those analyses are traditionally conducted using root cause
analysis, SWOT analysis, and tree diagrams (such as fault trees and decision trees).
Root Cause Analysis (Ishikawa)
Discussed at length in Chapter 7, “Practical, Team-Based Risk Identification,” the Ishikawa

diagram bears fruit in any risk complexity analysis. That’s because it works not only from the
perspective of a single cause, but from the perspective of the five whys. The five whys drive to
the cause of the cause of the cause of the cause of the cause. By asking why certain risks would
surface on a project, and subsequently asking why the conditions of that answer might be met,
complexity bubbles to the surface.
A well-developed Ishikawa diagram provides a relative sense of the degrees of complexity, in

that the more times the “why” question is answered, the more potential causes that may have to
be managed. With an Ishikawa diagram, the interpretation of complexity comes down to sheer
volume. That can be volume in terms of the number of causes, but can also be the volume of root
causes. If the risks on the project have multiple roots, they are likely intertwined. That
interconnectedness is discussed later in this chapter.
SWOT Analysis
Strengths, weaknesses, opportunities, and threats (SWOT) analysis takes both the internal and
external risk influences into account. As examined in Chapter 7, the focus on SWOT analysis is
that the strengths and weaknesses are external to the project, while the opportunities and threats
are internal to the project. The interplay between these two environments alone can generate a
degree of risk complexity. But the more the interactions between the internal and external are
considered, the more the project manager might understand that different stakeholders have roles
in controlling the degree of complexity.
Some analysts examine the influences based on the contrasts between the opportunities and the
weaknesses, as well as the threats and the strengths. This leads to the following questions:
Do the project’s opportunities overcome some of the weaknesses?

Are the project’s threats overcome by some of the strengths?
The four-square SWOT matrix shown in Figure 13-1 also begs related questions that drive to
project risk complexity.
Figure 13-1 SWOT Analysis
Are the project strengths and opportunities sufficient to warrant the project investment?
Are the weaknesses and threats so deleterious that they cannot be overcome?
Are the weaknesses and threats more damaging than the opportunities and strengths that offset
them?
In answering these questions, the rationale behind the answers forces a look at the degree of risk
complexity.
Tree Diagrams
Two common types of tree diagrams point to risk complexity. They are fault trees and decision
trees. They address two related, but different, aspects of complexity. Fault trees address the
underlying conditions that must exist for a risk to manifest itself as an issue. Decision trees
examine the potential to assess the complexity involved in a string of events for a risk to be
realized.
Fault Trees
Fault trees highlight the underlying conditions that need to exist for a risk to be realized. They
come in a variety of different formats, each with its own meaning. Figure 13-2 is an example of
the “all conditions,” also known as an all-gate fault tree or an and-gate fault tree.
Figure 13-2 All Conditions Fault Tree
In this fault tree, there are four downward branches. That means all four conditions must be met
to generate the fault. To generate an electrical house fire, for example, the four conditions might
include
An overburdened circuit
Inadequate wiring
Live electric
Combustible material
Any one of those conditions is a problem. When all four are present, it’s a virtual guarantee there
will be a fire.
Fault trees can also address “or” conditions. In such a situation, any of a series of conditions
could lead to the risk outcome. The format of the any-condition fault tree is similar, but not
identical to the all-conditions fault tree (also known as an or-gate fault tree), as shown in Figure
13-3.
Figure 13-3 Any-Condition Fault Tree
The modest changes here highlight that not all conditions must be met, but any of the conditions
could lead to the fault or failure in question. For this example, a trucker might consider road
conditions that could lead to an accident. Again, here, four conditions are to be considered:
Dense fog
Icy roads
Excessively steep grades
High speeds
The key difference from the all-condition fault tree is that if any of these conditions are in place,
the risk might be realized. Although a combination of the environmental conditions would
radically increase the probability of an accident, any one of the conditions could be sufficient to
cause the risk to convert to an issue.
Between these two extremes in fault tree analysis are a host of possibilities, because some risks
require that more than one (but not all) conditions be met to ensure risk realization. A multiple
condition fault tree (also known as a multiple-gate fault tree) can address such a situation, as
shown in Figure 13-4.
Figure 13-4 Multiple Condition Fault Tree
In this example, three of the four conditions must be met to generate the risk event.
Decision Trees
Decision trees come into play in a complexity discussion when they have multiple branches.
Those supplemental branches might stem from the original risk event or from a series of risk
events and outcomes.
Although many decision trees highlight two possible outcomes from a single event, some will go
much further in terms of the range of possible outcomes.
For the example in Figure 13-5, there are four possible outcomes from a single risk event.
Figure 13-5 Decision Tree Event with Four Possible Outcomes
Note that the outcomes are mutually exclusive. Two conditions on the arrows cannot be realized
at the same time. This affects the probabilities that will be applied to the event, because it means
that the probabilities must sum to 100, as illustrated in Figure 13-6.
Figure 13-6 Decision Tree Event with Outcomes and Probabilities

Although informative, the multiple branches indicate that the risks are inherently more complex,
given the gradient outcomes that can occur.
The other way in which decision trees can illustrate complexity is when they highlight the
likelihood of a given string of events, as illustrated in Figure 13-7.
Figure 13-7 Decision Tree with Multiple Dependent Events
This scenario might illustrate an opportunity for the likelihood of winning a new car on a game
show. There’s a 50% chance that an entry postcard will be selected for tryouts in a particular
city. From there, participants are told that there’s a 10% chance that they will be selected during
the tryouts. From there, when they appear on the game show with two other contestants, there’s a
33% (rounded down here to 30%) chance they will crush their opponents. And if they do, there’s
an 80% chance that during the “bonus round” they will win the new car, valued at $60,000. Note
that the entire string of events must occur for the contestant to win the new car. To determine the
probability of that event being realized, it is a simple matter of multiplication. Expressed as
decimals, the math would be .50*.10*.30*.80. That works out to .012, or just over 1 percent. For
the $60,000 car, the expected monetary value based on this series of events is $720.
The reason the expected monetary value is so low on such a valuable car is a function of
complexity. For all those events to come to pass requires an involved string of outcomes.
The game show example also points to the notion of risk interconnectedness. This is brought out
in the risk register (as discussed in Chapter 10, “The Risk Register”) in the “Connectivity”
category. The classic poetic example regarding the want of a nail points precisely in this
direction:
For want of a nail, the shoe was lost. For the want of a shoe, the horse was lost. For the want
of a horse, the rider was lost. For the want of the rider the message was lost. For the want of
the message, the battle was lost.
The more modern version of this poem is the simple axiom that When it rains, it pours. It often
seems true that when a single risk is realized, a host of other risks reveal themselves. Everything
from a mistake in the baking processes to car trouble drives this point home. Risk impacts rarely
exist in a vacuum. With interconnectedness, it is important not only to look at the amount at
stake, but also to examine how, if a risk is realized, new risks and new impacts are generated.

This interconnectedness can manifest itself not just at the project level, but at the organizational
level as well. When a single project encounters failure modes, the organization may suffer from
the ripple effects. A project with a sudden budget problem might influence projects elsewhere in
the organization through policy changes, lack of funding, or reduction of resources. At the
organizational level, management decision-making can be affected by the implications of a
single project in trouble.
Solar farms are classic examples. Unbeknownst to many solar entrepreneurs, one of the classic
risks in solar power farms is the risk that components might catch fire. The probability is low,
but the impact is significant. A single fire (risk realized) might not draw management attention.
Two fires in two weeks might prompt a more significant review. Ten fires in ten weeks could
lead to a complete overhaul of organizational policy. The organizational level risks are those that
directly impact strategic goals and objectives.
In addressing organizational-level risks, it is important to know the organization’s tolerances for

risk, which should be incorporated into the risk management plan. Those tolerances might go
well beyond time and cost. Those tolerances often relate to government regulation and
compliance. When the Ford Motor Company suffered a major setback with the Ford Pinto model
line (cars exploding because of poorly placed gas tank necks), Ford management became
involved and changed the entire corporate attitude toward quality. When packages of Tylenol
were tampered with in 1982, management demanded a complete overhaul to product packaging.
The tolerances in both cases related to regulatory compliance as well as public perception.
At the organizational level, the influence of single risk events (or interconnected events) can
evolve into a much greater situation. In some cases, different stakeholders can have different
interpretations of what constitutes compliance. A team might believe that management wants
lower cost and higher profit. Management might believe that public image is everything.
Although these different objectives could be capable of living in harmony, they can also fly in
the face of one another. That’s why project managers and risk managers must review corporate
processes to affirm that objectives at all levels are aligned.
The game show example used earlier is a classic example of risk as opportunity. When the term
risk is applied, most people don’t think about selecting the winning horse at the track, picking the
winning lottery ticket, or driving home in a new car from a game show. Many go so far as to use
the terms threat and risk interchangeably. Nothing could be further from the truth. In terms of
eliciting and evaluating risks, stakeholders need to know that both sides of the risk
considerations need to be taken into account.
This is particularly important in educating stakeholders regarding risk. Those who don’t deal
with risk on a day-to-day basis are least likely to look at opportunity as risk. And because risk is
seen primarily as threat, many stakeholders don’t care to become engaged in that conversation.
To overcome this, risk managers need to create safe spaces to report risks and to catalog changes
to probability and impact. This is why widespread access to the risk register is so important.
Stakeholders need to know how to frame risk statements, identify probability and impact, and
express concerns with impunity. If someone believes that their risk input will be critiqued or
dismissed, the system can break down. Many of the tools identified in Chapter 7, “Practical,
Team-Based Risk Identification,” need to be reinforced with the duality of risk
(opportunity/threat). Group tools such as mind mapping, affinity diagramming, brainstorming,
and SWOT analysis can all reinforce both the positive and negative items worthy of
consideration.
The complex, interconnected nature of risk is inherent in all projects. The challenge is taking all
those aspects and weaving them together to create a holistic picture of the risks at the project,
program, and organizational levels.
found.

Element Number
Paragraph Risk complexity derives from the nature of projects as 226

complicated entities
Section Root Cause Analysis (Ishikawa) 226
Section Fault Trees 228
Section Decision Trees 229
Section Risk Interconnectedness 231
Section Risk at the Organizational Level 232
Section Threat Versus Opportunity 233
complexity
SWOT analysis
fault trees
all-gate fault tree
and-gate fault tree

or-gate fault tree
multiple-gate fault tree
interconnectedness
opportunity
threat
Review Questions
There is a chance that your project may drive the customer to move you into the “preferred
vendor” category, which would mean almost double the business. Although you don’t currently
have the capacity to handle that much work, you are confident that you can find the staff to make
it work. What is this an example of?
1. And-gate fault
2. Complexity
3. SWOT analysis
4. Risk
5. Opportunity
You have identified a risk that the first floor of your riverside complex could flood in a major
storm, causing extensive damage. For that to happen, the river would have to crest above nine
feet, the floodwalls surrounding the complex would have to fail, and the emergency pumps
would have to lose power. You want to alert management to your concerns. What graphic
display would be most effective at illustrating this concern?
1. Decision trees
2. Burndown charts
3. And-gate fault trees
4. Or-gate fault trees
5. SWOT
You have identified a risk that the first floor of your riverside complex could flood in a major
storm, causing extensive damage. For that to happen, the river would have to crest above nine
feet, the floodwalls surrounding the complex would have to fail, and the emergency pumps
would have to lose power. You want to alert management to your concerns. This type of scenario
highlights what aspect of risk management?
1. Risk complexity
2. Risk interconnectedness
3. Risk-reward
4. Weaknesses and threats
5. Probability and impact
You are integrating six systems on two platforms with teams across the globe speaking seven
languages. This type of scenario highlights what aspect of risk management?
1. Risk complexity
2. Risk interconnectedness
3. Risk-reward
4. Weaknesses and threats
5. Probability and impact
Which of the following two statements are true?
1. An or-gate fault tree requires that all criteria be met for a risk to be realized.
2. In a SWOT analysis, strengths and weaknesses are external to the project.
3. Threats and opportunities are both risks.
4. Decision trees highlight two outcomes per risk event.
5. In a decision tree with multiple outcomes for a single risk event, the multiple outcomes’
probabilities must sum to less than 100%.
Part IV
Risk Management and Resolution

Chapter 14
Response Planning

There is a key distinction in risk management. Risk management, as the name implies, is the
management of risk that might or might not lead to a successful resolution. In any case, the risk
will be managed. This is a significant distinction from risk resolution. Risk resolution involves
treatment action in which the risk is ultimately resolved. Resolution implies that the risk will no
longer have to be revisited. It has been solved, cured, or corrected. Although this might not make
the risk go away, it will ensure that supplemental corrective action is not required. This stems
from response planning, which is the development of risk responses to create the optimal
environment to deal with the risk.
Risk response planning is the opportunity to proactively explore options. Conveniently, those
options come pre-packaged in risk management, both for opportunities and threats. The
expectation is that risk managers will review the responses for all significant risks, and in most
cases, will determine that the risks should ultimately be accepted. Although that’s the single most
prevalent strategy (and in many ways, the default strategy), it should be a conscious decision to
adopt it.
Risk response planning also means planning to respond to risk on both the project and
organizational levels. And it means preparing the environment for the unplanned responses to
events, known as workarounds.
Risk resolutions are not the sole province of the project manager or risk manager. In many if not
most instances, risk resolution is the province of the risk owner for a particular risk event. That
risk owner takes on the burden of implementing the response, tracking the response’s impact,
and reporting back on its efficacy.
This chapter reviews the various risk resolution strategies (both positive and negative) and the
implications of their selection and application.
Risk Response Task 1 Plan risk response
Opportunity Versus Threat Strategies 1, 2
Action Plans and Risk Owners 3, 4
Resolution Metrics and Communication 5, 6

Organizational Impacts 7, 8
Caution
You are working on an Agile project that has never been attempted before. Because of the
project’s novelty, you realize that you might discover new approaches that have not previously
been deployed in your organization. There’s a chance these new approaches could become
organizational standards. You identify the risk that you could learn and capture new tactics,
causing a shift in organizational approach. To ensure that knowledge is captured, you hire a
project librarian to catalog all the actions your team takes. Your ultimate hope is that the catalog
will lead to better Agile approaches in the future. This risk strategy is known as what?
1. Enhancement
2. Mitigation
3. Exploitation
4. Sharing
5. Transfer
You identified the threat that one of your team members, Malissa, might leave the organization,
taking with her valuable knowledge about your operating practices. The impact would be that
your practices would fall into the hands of your competition. You know Malissa as one of the
most ethical and forthright people you have ever worked with and realize your worries are likely
without merit. You decide to keep the potential threat to yourself. Which risk strategy are you
deploying?
1. Passive acceptance
2. Active acceptance
3. Mitigation
4. Avoidance
5. None
You named Roberto as the risk owner for a key threat to your project. The threat was
documented as, “If the vendor goes bankrupt, it might take months to find a new, validated
vendor.” Your response is to conduct a thorough review of the vendor’s credit scores, Dun &
Bradstreet ratings, and customer rankings. Roberto’s role as the risk owner is to do what?
1. Talk to the vendor about how the review is going.

2. Ensure the review is conducted, the outcomes are logged, and any ongoing concerns are
reported back to you.
3. Personally conduct the review, making sure that all the information from the review is logged
and any ongoing concerns are reported back to you.
4. Defer to vendor management for all these concerns.
5. Catalog the outcomes.
One of the threat strategies that your organization supports relates to poorly tracked meetings.
The threat is that meeting minutes might not be effectively kept, causing a loss of organizational
memory. Your strategy is to hire a court reporter for meetings that involve the client. They will
capture, word for word, everything said in the meeting and turn it over in a document file for
your use and consumption. Roberta is the risk owner for this particular threat. Which of the
following would you expect?
1. She will personally take on the role of “court reporter.”

2. She will make sure the court reporter is hired and follows her instructions.
3. She will report on the availability of court reporters and the lead time required to hire one.
4. She will use an audio recorder to back up every meeting.
5. She will report on the availability of court reporters, hire one, and use an audio recorder to
back up every meeting.
You are the risk owner for the threat that The customer will change their mind on the
requirements, causing extensive rework at mid-project. The estimated impact of such a risk is a
delay of eight weeks. The likelihood is 50%. You debate the strategy with management. The
strategy, Send the contract back through Legal, is designed to minimize the probability. If Legal
renegotiates, it drops the likelihood down to about 10%. Your concern is that the strategy itself
could easily delay the project by as much as four weeks. What do you recommend?
1. Apply the renegotiation strategy, based on the lower probability.

2. Recommend against the strategy, because the expected value of the improvement is not
enough to offset the time consumed.
3. Tell management it is a “wash,” given that the lost time for the strategy is equivalent to the
expected value of the threat.
4. Apply the renegotiation strategy, based on the lower impact.
5. Apply the renegotiation strategy, based on the lower probability and impact.
You build software using an Agile methodology. One risk you face is a loss of urgency as more
and more user stories pile up in the backlog. Your project velocity is consistent with original
projections, but the number of user stories has actually grown since the project started three
sprints ago. Management noticed. They want to know what you’re doing to resolve the problem.
You need to highlight the consistency in your velocity and the growing number of user stories.
The best way to highlight this would be to show management what informational elements?
1. The burndown chart and the sprint backlog

2. The Kanban chart and the sprint backlog
3. The Kanban chart and the project backlog
4. The burndown chart and the project backlog
5. The work breakdown structure and the critical path
Your organization has a bad history when it comes to overseas projects. The latest project, in
Slobbovia, is not going well. You have invited the client in for a discussion on the natural
disasters that seem to be plaguing the project, and point to the risk that if any more occur, all the
deadlines will be missed, and costs will increase dramatically. Your Slobbovian counterpart
suggests sacrificing a puppy into Mount Slob, an active volcano near the project site. They
contend that such a sacrifice will appease the gods and stop the natural disasters. They’re rather
insistent about it. Given that your organization is based in the UK, and such practices are
forbidden both nationally and in corporate policy, you balk at the suggestion. They insist that it’s
their puppy and their choice to make, but for it to work, the risk manager must do the sacrifice.
What do you do?
1. Agree and throw the puppy into the caldera.

2. Refuse, citing British law.
3. Refuse, citing humane treatment of animals.
4. Refuse, citing corporate policy.
5. Ignore the risk entirely, because the impacts will be covered by force majeure.
There’s a national scare related to the pesticide DeadStuff. Although your organization doesn’t
actively use it, it’s been found in crops from one end of the country to the other. Your project is
to introduce a new cereal just as the DeadStuff scandal story breaks. You recommend that
management avoid the risk entirely, and they agree. What does that mean to the organization?
1. The project will continue as if nothing has happened, and the organization will endure any
consequences.
2. The project will continue, with strict quality controls to ensure your product is safe.
3. The project will continue, and because it was never implemented, there are no real losses.
4. The project will be canceled, incurring whatever losses may result.
5. The project will be canceled, and because it was never implemented, there are no real losses.
Foundation Topics
There are a host of different responses (strategies) that can be applied to any risk. In fact, by
identifying different strategies, different options often present themselves. PMI®’s language for
these strategies is separate and distinct when it comes to opportunities and threats, as highlighted
in Table 14-2.
Table 14-2 Threat and Opportunity Strategies
Opportunity Strategies Threat Strategies
Acceptance (Passive) Acceptance (Passive)
Acceptance (Active) Acceptance (Active)
Exploitation Avoidance
Enhancement Mitigation
Sharing Transfer
Escalation Escalation
The only strategies that cross over between opportunity and threat are acceptance and escalation.
Even so, the approaches based on the nature of the risk event are different. Strategies, at their
root, are designed to address the probability and impact of risks, even when the strategies suggest
inaction.
Opportunity strategies are considered whenever a risk event is identified that could have a
positive influence on project or organizational objectives. The sections that follow explore these
opportunity strategies in more detail.
Passive Acceptance
As the name implies, acceptance is a strategy where the project team opts to take the good
fortune that might occur, if or when it occurs. Tracking is the only responsibility for the risk
owner. There are no special efforts to put forth to apply an acceptance strategy. If the good
fortune is realized, acceptance suggests that we will take that as it comes.
Active Acceptance
Akin to passive acceptance, active acceptance is the approach where no proactivity is involved in
terms of concrete action; however, specific responses are identified that will be implemented if
the risk is realized. These responses are designed to optimize the beneficial outcome.
Exploitation
Some opportunities are so significant or great that they cannot be ignored. In fact, the
opportunities can be so great that they must be seized. Exploitation is the strategy that ensures an
opportunity will be capable of being seized and will be seized. With exploitation, the risk event
moves from being a probabilistic event to being a sure thing. If the risk is that the client might
hire a new vendor to develop their technology, creating a new revenue stream, exploitation is the
means by which the organization ensures that they are that vendor, and no one else is even under
consideration. It could be argued that sole-source contracting is a prime example of exploitation
in action.
Enhancement
Enhancement comes in two forms—enhancing the probability and enhancing the impact. It’s a
strategy whereby the probability of a risk event is increased, but not to 100% certainty (which
would be exploitation). It’s also a strategy whereby the impact of the event is heightened. If the
risk is that the client might hire a new vendor to develop their technology, creating a new
revenue stream, the possibilities for enhancement are legion:
Enhance the probability: The risk team could enhance the likelihood of winning the work
by hiring thought leaders in the field.
Enhance the probability: The risk team could enhance the likelihood of winning the work
by spreading bad information about their competition.
Enhance the impact: The risk team could enhance the impact of winning the work by
developing cost reduction strategies before the work ever starts.
Enhance the impact: The risk team could enhance the impact of winning the work by
inserting incentive clauses in the contract.
With enhancement, multiple strategies can be deployed toward the same ends—increasing the
probability and/or amount at stake.
Sharing
Sharing is a situation where the opportunity is divided across multiple parties to increase the
probability or impact of success. News stories abound with tales of office teams getting together
to buy lotto tickets by the hundreds. When the pooled resources get together their tickets, the
probability of winning is increased. If they win, however, the impact is significantly reduced. In
2011, a group of seven New York state workers pooled their resources to buy a large number of
lotto tickets. Collectively, they won $319 million. The impact was dramatically reduced because
each of the pool participants got only $19 million (thanks to the cash payout and taxes). This is
the standard with sharing. Probability increases. Impact decreases.
Escalation
Some opportunities are so significant that a project manager and/or risk manager will not have
the capacity or authority to act on them. In such instances, escalation is the logical step. As the
name implies, escalation is a situation where the opportunity is surrendered to a higher level of
management (be it at the project, program, or portfolio level), allowing them to make the
determination whether the opportunity is worth pursuing. Individuals at these higher levels must
accept their new role as the owner and manager of that risk. After an opportunity has been
escalated, it is out of the project manager’s hands, and neither the project nor its participants will
receive the direct benefits of the opportunity. The upper manager who took over the opportunity
will ultimately earn the credit for the accomplishment.
Threat Strategies
Threat strategies are considered whenever a risk event is identified that might have a negative
influence on project or organizational objectives. The sections that follow explore these threat
strategies in more detail.
Acceptance
Acceptance and escalation are the only two approaches that span both opportunity and threat. As
the name implies, acceptance is a strategy where the project team opts to deal with the bad
fortune that could occur, if or when it occurs. The difference with threat acceptance is that it
comes in two forms—passive and active.
Passive Acceptance
Passive acceptance is a conscious lack of action. The threat is sufficiently remote or

inconsequential that no other formal strategy need be applied. Passive acceptance is the single
most common threat strategy. The risk owner’s response to anyone asking about such a risk
event would be, “We’ll deal with that if or when it comes.” The only other responsibility for the
risk owner would be to track. There are no special efforts to put forth to apply a passive
acceptance strategy. If the risk is realized, any funds required to resolve it would come from
contingency reserve if the risk event is within the project purview. If the risk event is completely
outside the project purview, the funds required to resolve it would come from management
reserves, dictated by individuals at a management level above the project manager.
Active Acceptance
Active acceptance is a conscious lack of preemptive action, coupled with a game plan if or when
the risk event is realized. Active acceptance differs from mitigation in that active acceptance
requires no proactivity. An active acceptance strategy will involve a contingent response. This
means that if (and only if) the threat is realized, specific actions will be taken to ameliorate the
pressures from the threat. This should not be confused with a mitigation strategy, where direct
action is taken prior to the risk being realized. A simple means to test whether a strategy is active
acceptance or mitigation is by evaluating cost or effort. If the cost or effort is incurred while the
threat has not yet been realized, the strategy is mitigation. If the cost or effort is incurred only
after the threat has converted to an issue, the approach is active acceptance.
In some instances, active acceptance will also warrant a supplemental response in case the initial
response is inadequate. If the strategy doesn’t work, the project manager or risk manager might
resort to a second contingent response, known as a fallback plan. A fallback plan is a contingent
response for a contingent response, developed before the risk is realized. If a threat is significant
enough to warrant more than one fallback plan, such supplemental strategies normally fall under
the umbrella of disaster recovery plans or continuity of operations plans.
Avoidance
Avoidance is the strategy to ensure that the risk cannot happen or cannot impact project
objectives. It resolves risk through the complete elimination of the threat event. If the threat is,
Marie might leave the organization, causing a knowledge gap on the project, an avoidance
strategy would be to take Marie off the project altogether. This ensures that there is no way for
the risk to be realized. It now has a probability of 0%. If it cannot happen, the risk has been
avoided.
Mitigation
Mitigation comes in three forms. The project manager can minimize the probability, minimize
the impact, or minimize both. Mitigation is an expensive form of risk response, because these
steps are taken prior to risk realization to achieve their goals.
Minimizing the Probability
As the name implies, minimizing the probability is a proactive step to reduce the likelihood of a
risk event’s occurrence. Minimizing the probability might do nothing to affect the impact. It
simply changes the chances that the impact will ever come to pass. Some newer vehicles have
warning devices to alert the driver that they are drifting out of their lane. This doesn’t inherently
change the impact of an accident, but it does minimize the chances that the accident will occur.
Minimizing the Impact
In those same cars, there are air bags. They are what has become an expensive feature in all
newer vehicles. They are also a clear mitigation strategy. Air bags do nothing to alter the
probability of a car accident. The likelihood of the accident is reliant on the skill of the driver and
the environment in which the car is driven. However, if there is an accident, the air bags can
deploy, saving the driver from striking the steering wheel or going through the windshield. They
serve only to minimize the impact, thus resolving the risk of an accident in a completely different
way than minimizing the probability.
Minimizing Both Probability and Impact
A more pedantic approach to risk resolution for the car accident example is simply to drive more
slowly. This lowers the probability of an accident by affording the driver sufficient time to
respond or react in a collision situation. It also lowers the impact, in that an accident at 50 miles
per hour is far less damaging than an accident at 70 miles per hour. Mitigation in this instance is
improved from both probability and impact perspectives.
Transfer
Risk transfer is shifting the threat in whole or in part to other parties. Insurance is a classic
example. The insurance company traditionally takes on the financial risks associated with a car
accident. These financial risks might result from vehicle damage or personal injury. In most
insurance policies, there are limits to the degree to which the insurance company will go in
protecting the policyholder. A policy might limit physical damage to $50,000 and personal injury
to $1,000,000. That’s the amount of accident risk (threat) that has been transferred to the insurer.
Transfer is complete only in the ideal. Most risk transfer involves the retention of some risk by
the risk-owning organization. In the car accident example, the vehicle owner will assume all risk
above and beyond $1,000,000 for personal injury. That same owner might also have to pay a
deductible before the insurer will make a payout. A vehicle policy with a $500 deductible means
that the insured is taking on a $500 risk at all times. That amount over $1,000,000 and that
deductible remain with the driver. Those values are residual risk. Residual risk is the risk that
remains after the resolution strategy has been applied. Even with insurance, drivers have residual
risk in the form of their deductibles.
Escalation
Some threats are so significant that a project manager and/or risk manager will not have the
capacity or authority to act on them. In such instances, escalation is the logical step. As the name
implies, escalation is a situation where the threat is surrendered to a higher level of management,
allowing them to make the determination whether the threat (and the project) is worth pursuing.
After a threat has been escalated, it is out of the project manager’s hands, and neither the project
nor its participants will be able to directly influence the implementation of the senior
management approach. The upper manager who took over the threat will ultimately bear the
brunt of the risk or earn the credit for the accomplishment of resolving it. Still, keeping the risk
on the risk register affords a history of the risk and how the project team responded.
To be effective, all these strategies must be documented and assigned to responsible parties. The
documentation comes in the form of action plans, which are converted into work. The
responsible parties are the risk owners, who are responsible for tracking the work, ensuring it is
progressing, and determining the ultimate efficacy of the approach.
Action Plans
Risk resolution plans need to be captured as work. In an Agile environment, such work would
traditionally be catalogued as a user story in a backlog. In a predictive project management
environment, such work would conventionally be converted to work packages in a work
breakdown structure. If the strategy is passive acceptance, no action is required, save for risk
tracking in the risk register. Otherwise, even strategies like avoidance require some action to
affirm that they are deployed as planned.
Agile Action Plans
User stories in Agile have a specific format. It is [Persona] needs [Outcome], because of
[Rationale]. An example for a risk resolution strategy might be, The client needs our
organization to have an umbrella liability policy because of their corporate risk tolerance. The
key deliverable here is the umbrella liability policy. That’s the outcome that must be achieved to
mark this user story as complete. For Agile, the individual responsible for carrying out the user
story gets the added advantage of understanding why the approach is being deployed, and at
whose behest.
Predictive Action Plans
In traditional waterfall project management, the work breakdown structure delineates the work to
be performed. It is deliverables based. Considering the prior example for user stories, a work
package for the same risk event would be umbrella liability policy. That’s the deliverable that
would be included in the work breakdown structure (WBS) to ensure that the work is being
carried out as planned.
Details of the nature of the policy and the coverage levels would be incorporated in a WBS
dictionary, detailing the nature of the protection created by the risk response.
In both examples, the key to action planning is to convert the response strategy to work. Action
plans ensure that risk responses become elements of work so that they can be both implemented
and tracked.
Risk Owners
Risk owners are the individuals who do the implementation and tracking. They may not be
responsible for performing the work, but they are responsible for making sure the work is carried
out. These individuals should not be confused with project managers (although project managers
often take on a risk ownership role). Risk owners are team members with sufficient bandwidth to
evaluate the responses to the risks they “own” and to make sure those responses are creating the
desired results.
The risk owners are not necessarily the individuals carrying out tasks impacted by the risk
events. But while their role is largely administrative, they have a hands-on responsibility to
ensure risk responses are carried out as planned.
Determining the success of risk responses can be challenging. In threat acceptance, for example,
success is purely achieved only when the event or its impact is not realized. Part of a risk
owner’s role is to determine what success looks like.
Resolution Metrics and Evaluation

Depending upon the strategy, success metrics may take on different looks and feels, as shown in
Table 14-3. Those strategies with an asterisk lend themselves to mathematical evaluation as well.
Table 14-3 Strategies and Resolution Metrics
Strategy Potential Resolution Evaluation
Opportunity
Passive No action taken. Risk event realized. As soon as the risk event occurs, the
acceptance opportunity associated with the event works to the benefit of the task or
project objectives.
Active No proactive action taken save to document the approach to be applied if

acceptance the opportunity ultimately is realized and becomes a benefit. When
opportunities are realized, the documented approach optimizes the
outcome.
*Enhancement Action taken. Risk event realized. Although the strategy might or might
of probability not have directly caused the risk to be realized, an increase in probability
can be cited as at least one of the causes of the opportunity.
*Enhancement Action taken. Risk event realized with greater than normal positive
of impact influence over the task or project objectives.
*Exploitation Action taken. Risk event realized. In this instance, the only metric is the
realization of the opportunity, which, hypothetically, must happen under
these conditions.
*Sharing Action taken. Partnering organization or entity identified and selected.

Probability of positive influence on project or task objectives increased.
Escalation Risk event passed along to higher organizational echelon. Outcome is no
longer under the purview of the project organization.
Threat
Passive No action taken. Risk event not realized or realized only to the degree
acceptance that it does not directly have a negative impact on task or project
objectives.
Active No action taken, save to establish a protocol for dealing with the risk
acceptance event if realized. Success is achieved when either the risk event is not
realized, or if realized, is kept within tolerances because of the protocol.
Risks that are actively accepted have a contingency plan.
Avoidance Action taken to ensure the risk cannot come to pass. Success is achieved
when the threat event does not come to pass.
*Mitigate Action taken. Risk event not realized. Although the strategy might or
probability might not have directly caused the risk not to be realized, a reduced
probability can be cited as at least one of the reasons it did not come to
pass.
*Mitigate Action taken. If the risk event is realized, it happens with a less-than-
impact normal negative influence over the task or project objectives.
*Transfer Action taken. Partnering organization or entity identified and selected.

Probability or impact of negative influence on project or task objectives
decreased.
Escalation Risk event passed along to higher organizational echelon. Outcome is no

longer under the purview of the project.
For those strategies with an asterisk, the metrics for resolution might be expressed quantitatively.
The math would be applied in three parts. The first is to establish the expected value of the risk
event if untreated:
Untreated Risk Event Cost/Time/Scope Impact * Probability of Occurrence
The second is to establish the expected value of the risk event with the treatment, in which the
formula is very similar:
Treated Risk Event Cost/Time/Scope Impact * Probability of Occurrence
The third is to determine the Delta between the two.
Untreated EMV minus Treated EMV
The solution provides a sense of what mathematical success looks like for the cost of the
strategy. If the risk is for a car accident causing $100,000 in injury, for example, and the
probability is .6 percent, the $500 deductible insurance math plays out as follows:
$100,000 * .006 = $600
Untreated, this risk has an expected value of $600.
Treated, the math plays out differently.
The $500 deductible will be paid only if the accident occurs, and the rest of the $100,000 risk is
transferred away.
$500 * .006 = $3
The difference between the $600 threat and the $3 treated threat is $597. That’s the amount that
the risk owner should be willing to pay for the insurance covering this particular threat (over a
fixed time period).
If the risk owner finds an insurance policy for under $597, success has been achieved in terms of
risk resolution metrics.
Workarounds
If none of the resolution strategies are applied, or a risk is unforeseen (and is realized), the last
risk strategy is a workaround. It’s an unplanned response to a negative risk event. Because it is
unplanned, unforeseen, and reactionary, metrics are virtually impossible to build into the project
proactively. Technically, workarounds are issues management, rather than risk management, but
PMI® still considers them a risk response.
Response Communication
When strategies are ready to be deployed, those approaches should be announced to as broad a
stakeholder base as plausible. Classic mitigation strategies (like air bags, seat belts, life vests) are
normally accompanied by messaging to alert potentially impacted parties of their use. When air
bags went from conventional air bags (deployment at the same pressure for all passengers) to
advanced air bags (deployment at adjusted pressures based on passenger weight), notices were
posted on vehicle visors to notify passengers and drivers of the change. Whereas an older,
conventional airbag might kill a 100-pound passenger, an advanced air bag will not. As strategies
are modified, affected parties need to know how their risk has shifted.
Communicating response strategies can be done through simple placards (as with the airbags),
signs, or other caveats and warnings at the site of the potential event (e.g., Warning: The
beverage you are about to enjoy may be extremely hot!). It can be done through regular meetings
(e.g., the traditional “safety message” provided at the beginning of virtually every construction
site or utility company meeting). Communicating the strategies should be conducted early and
often.
As effective risk managers, we intend to share this message with as many stakeholders as
appropriate, and as frequently as the situation warrants.
For the individuals implementing the risk resolution strategies, their roles must also be clearly
communicated. Use of a RACI (responsible, accountable, consulted, informed) chart (see Table
14-4) can be an effective way to share the approach.
Table 14-4 RACI Chart
Responsible Accountable Consulted Informed
Response 1 Ted Alice Carol
Response 2 Ted Bob Alice
Response 3 Bob Alice Carol Ted
Risk resolution needs to occur within the confines and constructs of the organizations in
question. Resolution needs to be in keeping with the tolerances and traditions of the
organizations. Those tolerances might take policy, compliance, and organizational objectives into
account. The traditions might consider the culture, attitudes, and sensibilities of the organization
as a whole, or of the key stakeholders in the project.
Tolerances
Tolerances (documented in the risk management plan) represent those points beyond which an
organization will not go. They might be related to the project objectives, corporate policy, or
compliance (on any number of fronts). Any selected strategy must be applied in the tolerance
context, with an understanding that those tolerances are sacrosanct.
Policy
Policy tolerances are those tolerances that define the organizational ethos. Ethics, organizational
behavior, and client relationships can fall into this category. As a strategy is selected, corporate
policy must be considered. Any strategy that would violate organizational policy is taboo. If a
strategy is rejected based on organizational policy, such rejection must be documented, along
with the rationale. When a risk response is in what might be considered a “gray area,” the policy
tolerance should be documented, coupled with the risk response, and communicated up the
organizational echelons for confirmation that the response is within tolerance.
Compliance
Compliance tolerances are those tolerances that are defined both inside and outside the
organization as to propriety. Most compliance tolerances are established by government entities,
although some might be dictated by the organization, by professional associations, and/or by
executive fiat. The tolerances here are easy to discern, because most are binary. The risk
resolution strategy either complies or it does not. If a risk response directly influences or is
directly influenced by government regulation, for example, the first question to ask is, Does this
comply with the regulation? Compliance tolerances often eliminate the “gray areas” because
there is evidence that they either are being met or not. As with any tolerance, a risk resolution
response that exceeds tolerances is unacceptable.
Objectives
Objective tolerances are those tolerances that define the limits on the goals of the organization or
the project. These are among the hardest to define because they are situational by project. They
also vary as time and corporate approaches change over time. The classic constraints of project
management (time, cost, and requirements) should have clearly delineated objective tolerances.
The project will be sent to management for review for termination if… is a statement defining
objective tolerance. The easiest of the objective tolerances to define are time and cost.
Surprisingly, most projects don’t have true objective tolerance. A good risk manager will suggest
values to their management for these two metrically driven objectives. These are the points
beyond which the project will not proceed.
Organizationally, objective tolerances go to the organization’s values. If the organization values

public image above all, any risk response that would potentially damage the public perspective
would be rejected. Any aspect of the organization’s values can apply here. And any risk response
that strays outside the boundaries of organizational objectives cannot be applied.

found.
Key Topic Page

Description
Element Number
Paragraphs There are distinct strategies that apply to opportunities that, 244
although similar to the strategies for threat events, represent
completely different approaches.
Section Opportunity Strategies 244
Section Threat Strategies 246
Section Action Plans 249
Section Risk Owners 250

Section Resolution Metrics and Evaluation 251
Section Workarounds 253
Paragraph As with all project work, work created by the risk resolution 253
strategies must be incorporated into the project plans. Taking it
a step further, for complex work, an effective communications
tool is the RACI chart, designed to explore the different roles
for those in the resolution strategy sphere.
Section Tolerances 254
acceptance (opportunity)
exploitation
enhancement (probability and/or impact)
sharing
escalation (opportunity)
passive acceptance (threat)
contingency reserve
management reserve
active acceptance (threat)

contingent response
fallback plan
avoidance
mitigation
transfer
escalation (threat)
workaround
RACI chart
tolerances
compliance
Review Questions
We will finish this project, no matter what! Your management has handed down the dictate that
the project must ultimately be completed. You also know that there are some risks that may
exceed organizational and project tolerances. Because the project must proceed, and the risks
would drive the project outside tolerance, the best strategy for those threats is what?
1. Acceptance
2. Enhancement
3. Transfer
4. Avoidance
5. Exploitation
There’s a chance that your project could lead to new work, but you and your team are not
counting on it. In fact, you have sufficient work that additional contracts would be nice, but
aren’t needed. If they happen, great. If not, it’s not a big deal. Your likely strategy for this
opportunity is what?
1. Passive acceptance
2. Active acceptance
3. Transfer
4. Enhancement
5. Escalation
You had no idea that your office complex was built on an old mine, and never conceived that the
entire building could slowly sink into an abyss. Nonetheless, the building has shifted, and the
west wing is uninhabitable. Your wing is likely next because the building is tipping that way.
Your best approach here is to take what resolution action?
1. Acceptance
2. Workaround
3. Mitigation
4. Transfer
5. Backfill
You have identified a brilliant set of threat strategies to resolve the risks that you and the team
have identified. Responsibility for addressing these strategies will be in whose hands?
1. The task or user story owner

2. The risk owner
4. The customer
5. The product owner or project owner
1. Projects may exceed organizational tolerances, but only in specific situations.

2. In a passive acceptance strategy, contingent responses will not be developed.
3. Risk resolution strategies that involve work become activities, work packages, and/or user
stories.
4. In a RACI chart, two individuals may be identified as “Accountable.”
5. After a threat is escalated, management will return it to the risk owner for resolution.
A meteor struck the building and is seriously slowing your ability to build a new server farm.
The costs associated with the repairs and rework are significant. Those funds will come from
where?
1. The project budget

2. Management reserve
3. Contingency reserve
4. Pad in the project budget
5. Finance
Your strategy to minimize the risk event The Customer might change their minds on the
requirements, forcing rework is working brilliantly, and you believe you have a new protocol to
manage this into the future. So far, the customer has not made a single change, and there don’t
appear to be any changes in the offing. Your next step should be to do what?
1. Ask the customer if they plan any changes or if the status quo is working for them.
2. Quietly wait, hoping the strategy continues to work.
3. Let the team and management know what the strategy is, and explain how well it is working.
4. Let the team and management know what the strategy is, and tell them not to jinx it.
5. Let the team know what the strategy is, and tell them not to communicate it outside the team.
Chapter 15
Response Implementation

All the planning in the world is rendered useless if the plans are not pursued. Implementation is
where the responses are put into action (or inaction, as the case may be). This is the perfect
confluence of risk management planning and project management planning. To be an effective
risk manager, an individual must be prepared to put project management practice in play. This
also ties to team motivation, highlighting their role in both resolving risks and receiving
acknowledgment for their efforts in that sphere.
Response implementation also provides senior or executive management with an understanding

that there is a game plan, even when that plan is to take no action. It involves the integration of
project management, risk management, and organizational management in affirming protocols
for implementing strategies, drawing down funds, and establishing change within the change
management process.
This also requires a high degree of emotional intelligence, being able to identify if, when, where,
or how stakeholders will react to responses as they are deployed.
Response implementation can establish the degrees of residual risks on a project or within an
organization. At the same time, it can also establish new, previously undiscovered, secondary
risks that would not exist without the risk resolution strategy’s implementation.
This chapter reviews the implications of response implementation at the pragmatic level and in
the context of the human response.
®
Risk Response Task 2 Implement risk response
Response Plans Versus Contingencies 1, 2
Stakeholder Response Reactions 3, 4
Residual Risk and Its Implications 5, 6
Secondary Risk and Its Implications 7, 8
Caution
You have created a project with a contingency budget to cover the entire project, as well as
contingencies on certain high-threat activities. You believe you are now prepared to handle
almost any risk that might come your way. What best defines the threats that you are shielding
the project and the organization against?
1. Risks that could reasonably be expected with a project of this nature

2. Unknown-unknowns
3. Known-unknowns
4. Risks outside the purview of the project manager
5. Risks that would be traditionally paid for by senior or executive management
Your risk register seems to be lacking in detail. For one of the threats, no detail exists on the
action to be taken. Under “Response,” it says only passive acceptance. There is no explanation as
to how the strategy will be carried out. To ensure that your risk register is complete, you should
add what information?
1. None
2. The nature of the passive acceptance approach and how it will be implemented
3. The plan for minimizing the probability and/or impact of the threat
4. How you and the team will ensure the risk never comes to pass
5. The approach for transferring the threat to another party
Your primary customer stakeholder, Angelica, is furious. She explains that she just got your
email regarding the plan to hire a subcontractor to manage a major portion of the work. Although
the contract doesn’t prohibit subcontractors, she explains that the site clearance process for a new
vendor could take weeks, and that delay is beyond her tolerances. What should you do?
1. Talk to the subcontractor about speeding their access to the site.
2. Find an approach that will not exceed her tolerances.
3. Continue as planned, because subcontracts are not prohibited by the contract.
4. Defer to Vendor Management for all these concerns.
5. Catalog the outcomes.
Your three primary stakeholders all seem to have a different interpretation of one of your key
threat strategies. Each time you send out a “clarifying” email, they seem to get more and more
confused. You’ll need their buy-in to the approach, and you need to ensure they can carry their
responsibilities related to the strategy. The best way to gain consensus and clarify their roles
would be to do what?
1. Maintain the email history and continue to send out clarifying emails.
2. Hold a live meeting with all responsible parties.
3. Change the response to the risk to something that everyone can more readily understand.
4. Host a conference call with all responsible parties.
5. Meet individually with each of the stakeholders to attempt to determine where the message is
disconnected, and take corrective action.
The project will last several years, and you have insurance on virtually all aspects of the project.
Your $1 billion umbrella policy is designed to cover virtually every conceivable threat and its
outcome. You worry because the project is only $140 million, and the deductible on the
insurance is $14,000,000. You clearly cannot afford a 10% impact to your project budget, but if a
disaster strikes, that’s exactly what will happen. In light of your tolerances, the massive
insurance policy, the deductible, and the overall project impact, what are the residual risks in this
scenario?
1. $1,000,000,000.
2. $14,000,000
3. $986,000,000
4. $140,000,000
5. The probability of the threat event that would take the project costs over $14,000,000
You are almost done with your project, and it has seemed blessed. None of the identified threat
events have occurred, and you have encountered a few of the opportunity events to solid
advantage. The contingency reserves are largely untouched, and some of the work has come in
early and under budget. The last few surviving threat events are low probability and have all
been passively accepted. Collectively, if they all come to pass, the costs would be within the
remaining contingency funds, and no last-minute dollar requests would have to be filed. What
can you now say about the residual risks?
1. There are none.

2. The residual risks have been eliminated, thanks to the contingency funds.
3. The residual risks have been mitigated, thanks to the contingency funds.
4. The residual risks are the sum total value of the surviving threat events, if realized.
5. The residual risks are completely manageable.
You are concerned about trucks from your customer’s organization backing into the natural gas
lines that supply your project. There’s clearly a chance for an explosion. Your customer assures
you that they hire nothing but the best professional truckers who know how to handle the
backing-up process. You suggest a strategy to install heavy concrete-and-metal bollards to shield
the exposed natural gas lines. Which of the following would be considered a secondary risk in
this situation?
1. The truckers might back into the natural gas lines.

2. The truckers might back into the bollards.
3. The truckers might never hit the bollards.
4. The truckers might need additional training.
5. The natural gas might explode on its own.
In the risk register, there was originally a risk identified that team members may suffer electrical
shock and injury while swapping out transformers. Your strategy to resolve this risk is to shut
down power for at least two hours before team members begin their work. It’s a brilliant
strategy, except that some residences have patients that require power to keep their life-saving
equipment running. Now, although your team members are safe, the patients are at risk. Which
of the following statements is true?
1. This is active threat acceptance, and the patients will need to be notified before the power is
shut down.
2. This is an avoidance strategy that creates residual risk.
3. This is an avoidance strategy that creates secondary risk.
4. This is a transfer strategy that creates residual risk.
5. This is a mitigation strategy that creates residual risk.
Foundation Topics
Contingencies are risk responses, but because of their blanket nature, they are often not
recognized as such. Response strategies (as discussed in Chapter 14, “Response Planning”) are
any conscious actions taken to proactively manage risks. For most opportunity and threat
strategies, the response plans involve new work. Installing safety devices, creating new
protocols, or generating alert systems all consume time and effort. The risk owner becomes
responsible for tracking not only the efficacy of the response, but also the cost and time
consumed in its implementation.
Risk response implementation is project management on a micro level. Not on a full-project or

large-project scale, objectives must still be identified, outcomes determined, stakeholders
defined, and impacts evaluated. The objective of a risk response is to bring the event to a level
within organizational tolerances. Even though that default description is consistent throughout a
project, the objectives for each individual response must be identified for that response. In
automotive air bag implementation, for example, the objective is to ensure that life lost is kept to
a minimum when the air bags deploy. In that situation, the objective would need to be clarified to
determine what “kept to a minimum” means. No one believes that air bags will prevent all
accident deaths, but there should be a clear metric for the threat strategy, determining success.
By contrast, contingencies (set aside for risks that occur within the scale and scope of the
project) are available at both the project and task level, and represent a pool of time and/or
money from which the project manager can draw to respond to risk events realized. The
challenge with contingency is that the project manager needs to make an early determination as
to how the funds may be accessed and for what purposes. Contingency reserves are set aside for
almost real-time access and should be used at the time the risk event is realized. They should not
be preserved until the end of the project, for use only when the project budget is completely
expended. Thus, when a project is 80% complete, and only 20% of the reserves have been
consumed, that’s a positive indicator. Conversely, when a project is 20% complete, and 80% of
the reserves have been consumed, early warning indicators should be going off.
Contingency funds might be used to manage overages created by the risks being realized or be
applied to fund contingent responses. Contingent responses are those planned reactive responses
generated when the risks are realized. Calling emergency services (e.g., 911) is a classic
contingent response. In some jurisdictions, direct costs are incurred for requesting emergency
assistance, and such costs would be covered through contingency funds, not the normal project
operating budget.
In some situations, there are contingent responses to the contingent responses. If the contingent
response is not adequate, another contingent response exists to deal with the aftermath. In such
situations, the second contingent response is referred to as a fallback plan. Fallback plans are
those plans that require inadequacy on the part of the original contingent response. The sequence
of events required to implement a fallback plan would be that the original risk event transpired,
the contingent response failed, and the fallback plan now must be applied. It is, in essence, a
contingent response to a contingent response. For the most dramatic of project failures, even
another layer of contingent responses may exist. These normally fall into the category of
disasters (and disaster recovery plans or continuity of operations plans [COOP]). Although the
implementation of such plans is rare, organizations have these in place to ensure that a single risk
event will not completely disable the enterprise.
Also, such plans should not be confused with workarounds, which are unplanned responses to
negative risk events that are realized (or about to be realized).
Anytime any project actions are taken (risk related or otherwise), stakeholders react. In risk
management, stakeholder responses often hinge on the nature of the response, their direct
involvement in its implementation, and on their personal tolerances and thresholds. The risk
manager and risk owner should be prepared for those reactions, in that they are predictable, at
least to some degree.
Nature of the Response
Chapter 14 reviewed each of the risk response types. Stakeholder responses to these responses
can be categorized and anticipated, as shown in Table 15-2.
Table 15-2 Strategies and General Reactions
Approach Stakeholder Reaction
Acceptance Reaction here is minimal, and it can be perceived as inaction.

Documenting the intentional use of this strategy is important to building an
understanding of the approach with stakeholders.
Exploitation Reaction here can be significant because it often involves a substantial

level of time and effort.
Enhancement Enhancement is seen as a traditional form of opportunity management and
is therefore readily accepted by most stakeholders, unless the enhancement
approach is highly unconventional.
Sharing The reaction here is largely a function of the degree(s) of trust with the
stakeholders involved and their willingness to adapt to a third party’s
involvement.
Escalation Reaction here is normally significant because it involves the stakeholders

adjusting to a new opportunity manager and giving up the relationship (for
this risk) with the existing risk owner and manager.
Threat Strategies
Acceptance Reaction here is minimal, and it can be perceived as inaction.

(Passive) Documenting the intentional use of this strategy is important to building an
understanding of the approach with stakeholders.
Acceptance Reaction here is minimal, and it can be perceived as inaction. Providing an

(Active) early alert that there are specific actions pending if the risk converts to an
issue is important.
Avoidance Reaction here is wholly dependent on the nature of the avoidance, because
this may mean dropping an entire approach or procedure associated with
the project. Because of the sweeping nature of avoidance, the reactions
here are sometimes visceral.
Mitigation Mitigation is seen as a traditional form of threat management and is

therefore readily accepted by most stakeholders, unless the mitigation
approach is highly unconventional.
Transfer The reaction here is largely a function of the degree(s) of trust with the
stakeholders involved and their willingness to adapt to a third party’s
involvement.
Escalation Reaction here is normally significant because it involves the stakeholders

adjusting to a new threat manager and giving up the relationship (for this
risk) with the existing risk owner and manager.
Personal/Professional Implementation Involvement
There is an old saying that in a ham and egg breakfast, the chicken is involved, but the pig is
committed. When it comes to risk resolution implementation, it is important to make the
distinction between involvement and commitment. Stakeholders will more readily rally around a
threat resolution approach if they believe they only have to be involved, rather than committed.
When it comes to opportunity resolution, the opposite is true. Stakeholders appreciate the
opportunity to leverage good news and to be seen as parties to making it happen.
In a RACI chart (described in Chapter 14), those stakeholders in the “Consult” and “Inform”
columns are largely seen as involved. Those who are responsible (doing the work) and
accountable (held answerable for the work) are committed.
The level of involvement or commitment is often in the hands of the stakeholders, rather than
predetermined by the project manager. That level can be driven by personal and professional
interests, as well as the level of challenge associated with the response strategy. Some
individuals prefer more challenging work, whereas others simply want to be able to mark work
as complete. Some stakeholders will commit to extensive support on work that interests them,
whereas others see work only as a necessary evil.
Personal/Professional Tolerances
The willingness to support or adopt some risk resolution approaches also ties to personal and
professional risk tolerance. Escalation is a classic example where this is applicable. Some
individuals believe that handing responsibilities off to senior management is akin to giving up.
Others believe that management needs to take a hands-on role in ameliorating the risks.
Tolerance is a very personal thing.
A classic example of this occurred when a training company received an offer from a Fortune 50
firm. The offer was to have the training company conduct all training for the firm, but in
exchange, all the training organization’s intellectual property would ultimately be owned by the
Fortune 50 enterprise. Many senior executives in the training company saw this as a bad bargain.
They believed that handing over all the intellectual property would result in the ultimate demise
of the training firm. They found the strategy well beyond their tolerances.
The individual responsible for the deal was totally comfortable with the transaction, believing it
was an amazing chance for a major opportunity. And in the five years of the contract, the
training firm would have more than enough time to build new intellectual capital and become an
even larger market force.
The deal was escalated to the company’s owner, who seized on the opportunity and agreed.
Several executives saw the move as defeatist and outside responsible corporate behavior. But
because the owner determined it was viable, the owner was the ultimate point of escalation.
(Note: The deal went through and succeeded, just as its sponsor had predicted.)
In selecting strategies, stakeholder tolerances become vital. If stakeholders cannot live with the
strategies, the risk manager and project manager need to know why. And if the stakeholders
cannot cope with the ultimate decisions, it might be a situation where mutually agreed-upon
separation becomes a consideration.

Residual risk is the risk that remains after any or all response approaches have been
implemented. If a threat strategy mitigates $20 million of value in a $25 million risk, there are $5
million in residual risk. That’s what the organization will still have to contend with if the risk is
realized. If the strategy for a physical ailment is surgery to reduce the pain, a physician may warn
that although the pain might go away, the underlying problem might not, leading to other health
concerns later in life. The underlying problem is residual.
Residual risk is at its most profound when acceptance is the response strategy, particularly
passive acceptance. Because passive acceptance is not proactive, the entire value of the threat
remains in play. A $10,000 risk that is passively accepted may ultimately cost the organization
the full face value of $10,000.
With most insurance policies (risk transfer), the residual risk is the deductible for which the
policyholder is responsible. For health insurance, the co-payment is also considered residual. In
these situations, some degree of risk rests in the hands of the policyholder, even though the larger
share of the threat now belongs to a third party.
Secondary risks are those risks generated by the risk response. In threat situations, these are
cases where the cure might be just as threatening as the disease. In opportunity situations, these
are cases where the good news of the potential opportunity (improved through an opportunity
strategy) might see the good news increased even further by the secondary risk (or might see the
good news wiped away by a secondary threat risk).
The National Institute of Standards and Technology published an article on the metallurgy of the
Titanic to determine whether the steel hull (and iron rivets holding it together) played any role in
the rapid sinking of the “unsinkable” ship (https://tinyurl.com/TitanicMetal). Although steel was
used to build the hull of the Titanic (a risk mitigation strategy to render the ship less likely to
sink), that same steel became very brittle when exposed to seawater at or below 32 degrees. Iron
rivets were used to mitigate the potential delays of using steel rivets (which take longer to
install). Although that minimized the impact of schedule risk, those iron rivets had a tendency to
pop at cold temperatures, and it’s believed that this caused the Titanic to sink more rapidly.
Secondary risk is any risk generated by a risk response that would not have otherwise existed. If
the risk response had not been applied, the new risk never would have been created.
An effective risk manager will look at all selected strategies to determine whether they have the
potential to create new risks. If new risks are created, the strategies need to be evaluated (in
terms of cost, time, and other implications) to determine whether the response creates more
problems than it’s worth.
For these newly discovered risks, the same processes of analysis, prioritization, and response
must be applied. During analysis, however, it is important to determine whether the originating
risk event must occur for the strategy to be applied (and the new risk generated). If the original
risk must occur, the probabilities become dependent. If there’s a 10 percent chance of the
original risk and a 20 percent chance that the new risk event will occur as a result, the overall
probability of incurring the secondary risk is only 2 percent (10%*20%). By contrast, if the
strategy creates secondary risk without requiring the first event to occur, the probabilities are
independent, and thus the likelihood of the secondary risk becomes much higher. If the
secondary risk is independent and has a 20 percent probability, there is a one in five chance it
will occur.
For example, if accidents happen on 10 percent of the projects, and when accidents happen, 20
percent result in hospitalization or death, that would mean there’s a 2 percent chance of
hospitalization or death during project execution. If the project manager can find a way to reduce
the probability of either the accident or the subsequent chance of dying, then the 2 percent would
be reduced even further.

found.

Section Response Plans Versus Contingencies 266
Section Stakeholder Response Reactions 267
Section Residual Risk and Its Implications 270
Section Secondary Risk and Its Implications 270
contingency
contingent/contingency reserve
contingent response
fallback plan
continuity of operations plan (COOP)
workaround
involvement
commitment
residual risk
secondary risk
Review Questions
Your project will incorporate quite a few risks that will be passively accepted. To effectively
deal with these risks, you will do what?
1. Develop approaches that involve minimizing the probability and/or impact.

2. Establish a management reserve account to handle challenges within the project as they arise.
3. Shift responsibility for some of these risks to responsible third parties.
4. Establish contingency reserves to handle challenges within the project as they arise.
5. Establish contingency reserves to handle challenges within the project when the project
budget runs out.
You establish a contingent response in case it snows by identifying 10 plowing companies to

clear the path for your team to get to work. You have no contracts, but you know they’ll come if
the money is right. You also realize that they might not be available. If it snows, and if the
snowplows aren’t available, you have a strategy to call in helicopters to get your team in to the
site. The helicopters are a last-resort strategy.
1. The helicopters are a contingent response.

2. The helicopters are a fallback plan.
3. The helicopters are a continuity of operations plan (COOP).
4. The helicopters are a disaster recovery plan.
5. The helicopters will never really come into play.
A series of cascading risks has struck your project and your organization. Staff has quit.
Buildings have burned. Financial losses have been staggering, and you’ve been asked to make
sure that the entire enterprise doesn’t fail. With everything going wrong at the same time, and the
potential for an organizationwide failure, what’s your best option?
1. Accept the risks.

2. Implement your contingent responses.
3. Conduct workarounds.
4. Implement the continuity of operations plan.
5. Backfill.
You are working in an Agile environment and have a great relationship with your customer.
Together you have been able to manage almost any threats that have come your way. A series of
new risk threat events have been identified, and you and your team have suggested a new set of
resolution strategies to deal with them. The strategies involve hiring outside vendors and
migrating to a waterfall approach for the next few deliverables. The customer is balking, and
they are upset. Could you have anticipated such an outcome?
1. No, it’s completely unexpected.

2. Yes, because the shift in approach represents significant change, and the new vendor adds a
new dynamic to the project team.
3. Yes, because the new vendor adds a new dynamic to the project team, although the shift in
methodology should not be an issue, given the nature of Agile and the ability to adapt.
4. Yes, because the shift in methodology means an entirely different type of customer
relationship, but the team should not be an issue, given the nature of Agile and the ability to
adapt.
5. Yes, although it should pass quickly, given the nature of Agile and the history of an ability to
adapt.
Which two of the following statements are true?
1. Residual risks are those risk events generated by response strategies.

2. Secondary risks are those risk events generated by response strategies.
3. Some residual risks are created when risk events are passively accepted.
4. Risks in an Agile project are more prevalent, given the changing nature of the backlog.
5. Risks are reduced by a waterfall approach, given the constant nature of the backlog.
The client is very upset that the software you are installing seems to be interacting poorly with
other related software systems. The system shuts down for about five seconds and then restores
itself, but you see a risk that the five-second gap may become worse. Customers never see the
software in action. They only get the data outputs from the software. Your team members,
however, have to write extensive reports every time the five-second glitch occurs, and realize if
the problem continues, they could lose the contract. Which of the following statements is true?
1. The parties in this situation are committed.

2. The customer is committed, and your team members are involved.
3. The parties in this situation are involved.
4. Your team members are committed, and your customer is involved.
5. No one in this situation is either committed or involved.
Your strategy to minimize the risk event The Customer may change their minds on the
requirements, forcing rework is working brilliantly. It is to actively accept the risk and have the
client consistently sign change documentation. If the customer fails to sign, which of the
following would be a fallback plan?
1. Ask the customer to please sign the change documentation.

2. Sign the change documentation for them.
3. Stop work on the project when the change documentation is unsigned.
4. Take no additional action.
5. Sell the customer relationship to another vendor.
Part V
Tracking and Closing Out Risks

Chapter 16
Data Collection
Monitoring and controlling risks involves data collection. Gathering information is all important
when it comes to determining the relative efficacy of the risk resolutions selected, and risk events
that have transpired (or passed). Risk information gathering needs to be consistent in terms of the
approach, the timing, and the nature of the data being collected. In addition, data collected for
other purposes (such as earned value performance data) needs to be evaluated for its influence on
the overall risk posture. Risk events, outcomes, and responses need to be evaluated for their
influence on the performance data, as well.
The question in these evaluations is not whether there is variance. There will be variance. The
question is one of whether that variance is within the tolerances of the stakeholders. These
variances occur at the user story, activity, and work package levels, as well as at the project level.
At the project level, the question is one of whether the variances are impacting the enterprise as a
whole.
This chapter reviews the implications of response implementation at the pragmatic level and in
the context of the human response. This chapter addresses the following objectives from the
PMI-RMP® Exam Content Outline:
Monitor and Close Risks Task 1 Gather and analyze performance data
Gathering Information 1, 2
Ranking Approach Efficacy 3–5
Contrasting Project and Organizational Risk 6–8
Caution
You are in the midst of preparing for the retrospective and want to ensure you have the right data
for your burndown charts. Which of the following best describes the nature of the data
gathering?
1. You will evaluate the number of user stories and story points completed, as well as
information from earlier burndown charts, to draw the current-versus-planned perspective on
project velocity.
2. You will evaluate the number of user stories and story points completed, as well as
information from earlier burndown charts, to highlight project cost and schedule variance.
3. You will evaluate the work packages completed, as well as information from earlier
burndown charts, to draw the current-versus-planned perspective on project progress.
4. You will evaluate the work packages completed, as well as information from earlier
burndown charts, to highlight project cost and schedule variance.
5. All team members will contribute their insights on project progress and accomplishment to
determine project progress.
You are trying to gather the data to determine whether your project is at risk of being overbudget
and/or late (or at risk of being underbudget and early). The CPI and SPI data from the last four
reports is beginning to show trends. The CPI from the last four reports was as follows: January
.92, March .90, May .89, July .88. The SPI from the last four reports was as follows: January .92,
March .94, May .97, July 1.0.
It’s September, and you need to put together your report. As you go to get September’s earned
value data, you can anticipate what?
1. The budget values will continue to get worse, while the schedule values will continue to
improve.
2. Past performance is not indicative of future results. You can’t really anticipate any outcome.
3. The budget values will continue to improve, while the schedule values will continue to get
worse.
4. Your schedule values will be almost a direct mirror reflection of the budget values. As the
budget goes up, the schedule will go down, and vice versa.
5. The data will prove meaningless.
You have consumed 18% of your contingency reserve and are 79% of the way done with the
project work. You have often thought that the end of the project will be the most difficult and
that your team needs to be at their absolute best to get the work done with minimal risk. One of
your team members just alerted you to the fact that the risk of the customer changing sites is
more likely to occur than anyone previously thought. That risk, if realized, would consume as
much as an additional 25 percent of your contingency reserves. Given the dramatic potential shift
in the ratio of work done to contingency consumed, what can you tell your management at your
next project review meeting?
1. There might be some significant drawdowns against contingency in the weeks ahead, and
you’re likely going to see that cause an overbudget condition.
2. There might be some significant drawdowns against contingency in the weeks ahead, but
overall, the project should be fine.
3. The project team will have to modify its approach on certain risks, including the potential for
the customer site change.
4. The project risk owner for the site change risk should be replaced for a failure to recognize the
risk was inevitable.
5. You continue to watch the accepted risks and will notify management if they are realized.
Your resolution strategies were converted into work to be performed, and you’ve now reached a
point where they were put in place, mostly to mitigate a variety of risks. One risk was transferred
to an insurance company, at a cost of $124,000 per year. The second year of the project is almost
complete, and you’ve made no claims against the policy. The risk is still at the same level in
terms of probability and impact, but you’re wondering if the money could be put to better use.
Assuming the other risk priorities have remained the same, what should you do?
1. Cancel the policy.

2. Retain the policy.
3. Phase out the policy with significantly higher deductibles and lower payout limits.
4. Consider a lower deductible and higher premium because the threat is now more probable.
5. Escalate to your management.
Project velocity is a key metric in your organization. Month after month, you see the project
velocity is increasing, and the impacts to your overall project schedule are dramatic. You
acknowledge there could be significant risk to the project outcome and want to let management
and the customer know. What should you tell them?
1. The threats on the project right now are significant, and as such they need to be aware of those
risks.
2. The opportunities on the project right now are significant, and as such they need to be aware
of those risks.
3. The project is moving more slowly than planned, and you’re working on workarounds.
4. The project is moving more quickly than planned, and you’re working on workarounds.
5. Nothing. This is yours to manage.
You are having challenges with one of your vendors, Initech. Their software does what it is
supposed to do, but only after you push back on the quality of their testing. Their testing
capabilities are not aligned with what they promised in the contract. Given that the software is a
very small component of your overall project deliverable, you’re thinking of firing them and
hiring someone else. The only problem is that they work on almost a dozen other projects led by
other departments and other project managers. A firing might not hurt you, but it could do
serious damage to the relationship between Initech and the remainder of your organization. What
should you do?
1. Express your concerns to Initech.

2. Express your concerns to the other project managers in your organization and determine
whether they would be all right with your response.
3. Express your concerns to your project sponsor.
4. Express your concerns to your contracts personnel.
5. Fire Initech.
You work for a multi-billion-dollar global enterprise with facilities on four continents. Your
project has a total value of $280,000 USD. It’s a high-risk effort with a significant chance of
failure. Management has told you simply to “do your best.” They’ve also mentioned that this
project has the attention of some of the most senior leaders in the organization. You realize that
you might fail and lose the entire corporate investment of more than a quarter-million dollars. In
light of your concerns about the project finances and the potential losses, what action should you
take?
1. Alert your boss to the concerns, document them, and forward the documentation to the senior
leaders in the organization.
2. Alert your boss to the concerns and follow your conventional risk management practices and
processes.
3. Follow your conventional risk management practices and processes.
4. Escalate the concerns to the senior leaders in the organization.
5. Stop the project now, before the company is in too deep.
You work for a small, family-owned business with facilities in three U.S. states. Your project has
a total value of $280,000 USD and is the largest single project the company has ever undertaken.
It’s a high-risk effort with a significant chance of failure. Management has told you that “failure
is not an option.” They’ve mentioned that this project has the attention of virtually everyone in
the executive echelons of the company. You realize that you may fail and lose the entire
corporate investment of more than a quarter-million dollars. In light of your concerns about the
project finances and the potential losses, what action should you take?
1. Alert your boss to the concerns, document them, and forward the documentation to the senior
leaders in the organization.
2. Alert your boss to the concerns and follow your conventional risk management practices and
processes.
3. Follow your conventional risk management practices and processes.
4. Escalate the concerns to the senior leaders in the organization.
5. Stop the project now, before the company is in too deep.
Foundation Topics
Information gathering occurs at a variety of levels throughout the life of a project. Notably, work
performance information and team performance information both need to be acknowledged as
critical considerations in what information must be gathered. Additionally, that information must
be assessed in the greater context of levels within the project. In Agile, is it the risk to a single
user story, or the sprint, or the project as a whole? In waterfall management, are the risks
germane at the work package level or across the entire project?
First and foremost, the basis for information gathering is knowing what form(s) and/or format(s)
the ultimate reporting will take. If the outputs are going to be displayed in burndown charts, the
required performance data will include user stories, story points, and rates of completion. If the
outputs are going to be generated as earned value, the performance data will include actual costs,
planned costs (by each work package), and accomplishment to date. To determine what data
must be gathered, the project and/or risk manager must know what outputs are appropriate to the
situation.
Beyond knowing what types of data need to be gathered, it’s also important to know the data
sources and the degrees of accuracy required. Some households track their spending by trusting
in monthly reports from the bank. Others reconcile spending down to the penny, using receipts as
their guide for how the money has been spent. In project management, the data sources and the
degrees of accuracy are important, because they may ultimately determine how much time and
effort is required to gather the information.
Data Sources
Where do data come from? That’s a very reasonable question that needs to be established as
early in the project as possible. During elections, for example, the argument could be made that
results are generated based on the vote tally. Some counties garner the votes through electronic
machines. Some gather votes based on paper ballots. Some use an amalgam of the two or leave
the choice in the hands of the voter. Almost invariably, those who support one approach argue
that the other has the potential to be tainted by fraud. The data source becomes all important.
In projects, the same kinds of contention can exist based on the nature of the data source and
based on how that source will ultimately be evaluated. In earned value, for example, the variety
of claiming techniques (means by which percent complete on work packages is tallied) leads to
the same potential arguments about fraud and deceit. Although traditional earned value would
say a $7,000 work package that is 60 percent complete has earned value of $4,200 ($7K*.6), the
50-50 rule for claiming value would give the work package owner only half-credit for their
efforts. Under the 50-50 rule, the value of the work done is $3,500. And that value wouldn’t
change until the work package is complete. Those who support the 50-50 claiming technique
argue that unscrupulous individuals cannot tweak their interpretation of percent complete,
rendering it less likely to suffer from misuse. Opponents of the 50-50 rule say that it skews the
analysis for the worse, leading to potential poor performance analysis.
Data sources matter. In financials, data from the current week may be far less trustworthy than
data that has been analyzed over the course of over a month. Reporting lag time may work in
favor of better data (or worse, depending upon an enterprise and its cost accounting practices).
Degrees of Accuracy
Most financial organizations are quick to acknowledge that real-time accounting data remains
subject to adjustment as the final tallies are gathered. This can also hinge on the levels of
precision required for specific data points. Someone willing to account for a project in $100
increments may find that the data-gathering goes rather quickly. Someone insisting on penny-
for-penny accounting in a project environment will discover such painstaking analysis takes
more time.
Long before beginning any data gathering, the project manager should determine the degree of
accuracy required for effective management. This will ultimately bleed over into the risk
management aspects of the project, because a project willing to tolerate information in one-
month increments will be managed differently than one driving for minute-by-minute
accounting.
An interesting term that is used in some organizations is called “wiggle room.” It’s the degree to
which room is given to account for the lack of a need in terms of high precision. A project with
precision measured in terms of months is probably willing to allow for a degree of wiggle room
measured in hours or days. No one will be concerned if a day is lost or gained at different
moments during the project life cycle.
Degrees of accuracy become critical in reporting whether risks are being realized as a project
progresses. If the impact of a risk is that the project will be late, a 10-minute delay will not
normally be considered a big deal.
In 1983, the San Diego Building Industry Association set a world record for home construction,
creating a stick-built home in under three hours. For them, accuracy was measured in minutes
because a 10-minute delay was considered crucial.
From a risk perspective, this plays into the decisions on tolerances and thresholds, but it also
determines the number of people who must be dedicated to tracking project information and the
frequency with which they must report.
Another aspect of data collection is the determination as to whether the “high-impact” risks
proved out to be high and whether the probability terminology and approach functioned as
intended. In trying to determine whether the ranking approach worked as planned, the proof is in
the outcomes, but only to a degree. High-probability risks that never come to pass are not poorly
planned. The fact that they were not realized only points to the fact that they never happened, and
little else. To determine whether the ranking approach worked, a few questions need to be taken
into account:
Were the high-probability risks realized?

Were the high-impact risks that were realized actually a high impact?
By managing the high-priority risks, was the project able to remain within the project’s and
organization’s risk tolerance?
High-Probability Risk Realization
The nature of statistical or probabilistic risk analysis suggests that most risks are, ultimately,
binary. They either transpire or they don’t. Although a single risk may impact the project to a
variety of degrees, the fact that it might happen is a yes/no consideration. It happens, or it
doesn’t.
Part of the thinking here goes back to a blend of qualitative and quantitative analysis. A high-
probability risk might be 51 percent. It might also be 99 percent. Unless extensive statistical
records are kept, some consistent value should be applied to high-probability risk. For the sake of
this discussion (but not for the exam), the term high probability will be equated to 60 percent. No
matter the value, the inverse then becomes true. If there’s a 60 percent probability the event will
occur, there’s a 40 percent chance it will not occur. When considering the body of risks in a
project, many of the high-probability events might occur. But some will not. This group will
generate some surprise in that they didn’t happen. During the course of the COVID-19
pandemic, some medical professionals, even though they were exposed on a daily basis, never
contracted the disease. When considering a single individual, that reality is not overly staggering.
However, when considering a group of individuals, it becomes progressively more surprising.
Assume (by way of example) that there was a 60 percent chance of any individual member of a
nursing home staff contracting COVID-19. The odds of one staffer not getting the disease were
40 percent.
The probabilities begin to shift radically when considering multiple staffers, because of
dependent probabilities.
The odds of two staff members not getting the disease are 40 percent times 40 percent, or 16
percent. That means for any random group of staff, there’s an 84 percent chance that if you pick
two of them, one will contract the disease.
The odds of three staff members not getting the disease are 40 percent times 40 percent times 40
percent, or 6.4 percent. Again, the inverse then becomes true. There’s a 93.6 percent (100%
minus 6.4%) chance that at least one of the trio will contract COVID.
With four staff members, the odds of none getting the disease are 2.56 percent. Five staffers? 1
percent. Six? Less than one-half of 1 percent.
When a single high-probability risk is not realized, there should not be surprise or any cry of foul
in the statistical analysis. When multiple high-probability, dependent, or independent risks are
not realized, there may be cause for investigation.
In any case, there are ample situations where the high-probability outcome is not realized. It’s
important to assure management and the team that although they were not realized, it does not
mean that the probabilities were not analyzed properly. It means only that the risk(s) did not
occur.
High-Impact Risk Realization
Gas lines explode. Customers go bankrupt. The system crashes. The organization reorganizes.
These kinds of dramatic events are the stuff of high-impact risks. But in some cases, even the
worst high-impact risks (short of those involving deaths) aren’t as bad as they were originally
believed to be. The customer goes bankrupt, but we are surprisingly high on the list of creditors
to be paid. The system crashes, but a major malware attack is avoided. The organization
reorganizes, and the new hierarchy works in the project’s favor. Part of evaluating the efficacy of
any risk ranking system is to determine whether the high-impact risks were truly high impact.
On the opportunity side, organizations sometimes see new projects as game changers. The reality
ultimately may not live up to the hyperbole.
As risks are realized, the impact assessments, both qualitative and quantitative, need to be
evaluated to determine whether the values were accurate, and whether those values were in any
way skewed by the nature of the environment or the project.
On the low-impact side, the project and risk managers need to determine whether those risks that
were considered to be a lesser impact actually were.
For both of these perspectives, some degree of personal bias comes into play. The interpretation
of high impact in many ways is driven by personal and corporate/organizational experience.
Take the example of a driver who has totaled four cars in his driving career, walking away from
each of the accidents. Most people would consider a ruined car as a high impact. The driver who
has survived multiple times might perceive it as a cost of doing business. Some organizations
value public image above all else, considering anything that taints their public image as a high
impact. In such instances, some organizations bounce back, either with resilience or anti-
fragility.
Resilience
Resilience is the concept that an individual, project, or organization can bounce back from
adversity. A high-impact risk is realized, and the organization recovers with the same level of
strength and capability as it had before the risk event transpired. In such instances, there is often
a cost associated with bouncing back, but there is also an understanding that the recovery
represents a significant layer of enterprise capability. The more resilient the organization, the
more hardened it is to manage and survive threat events.
Anti-fragility
Anti-fragility is a concept introduced by Nassim Taleb in his 2012 book, Anti-Fragile: Things
That Gain from Disorder. It is a notion beyond resilience, that some organizations can not only
bounce back from adversity, but can recover with a higher level of capability and new
understanding of how to manage their enterprise and their enterprise’s risks. In an anti-fragile
environment, organizations manage high-impact risks after the fact by having structures in place
that encourage new thinking and new approaches to strengthen the organization and create
higher capability levels.
For both resilient and anti-fragile environments, high-impact risks drive a lower level of concern,
in that the infrastructure is in place to manage them effectively if they are realized.
Overall Risk and Project Influence
Although most risk ranking is done within projects to examine individual risk events, the
effectiveness of risk approaches bears a great deal of fruit when considering overall project risk.
This concept was introduced in some measure in Chapter 12, “Risk Quantification.” No single
tool better evaluates overall risk than Monte Carlo analysis.
As discussed in that earlier chapter, Monte Carlo provides an overall assessment of the
probability of possible outcomes in terms of time and cost. In determining risk ranking efficacy,
Monte Carlo can serve double duty by not only establishing a baseline set of outcomes, but also
setting the stage to determine outcomes in dozens of “what-if” scenarios.
Consider the single risk event of Roberta might quit the team, being replaced by someone with
less expertise. Although the impact to a single work package might be quantifiable, without
Monte Carlo, it’s difficult to determine the overall threat to the project. With Monte Carlo,
however, it’s possible to get the large-scale view of how Roberta’s departure might influence the
project. Suppose that all the tasks to which Roberta is assigned have a relatively high confidence
level of +/– 10 percent, as shown in Figure 16-1.
Figure 16-1 Task with a +/– 10 Percent Confidence Level
If all of Roberta’s tasks have the same confidence level, their individual curves would influence
the overall project outcomes to some effect, but not dramatically.
Suppose Roberta is replaced with a less competent or confident employee, Ted. If Ted’s
confidence level is +/– 40 percent (as shown in Figure 16-2), his tasks would then affect the
project far more dramatically than Roberta’s did. Note the “days” range on the vertical axes.
Figure 16-2 Task with a +/– 40 Percent Confidence Level
Extrapolate this through the entire project for every one of Ted’s tasks, and the range of risk
associated with project timing becomes far more dramatic.
Setting up what-if scenarios provides the capability to see how individual risks impact a project
in its entirety. Monte Carlo analyses are the best tools for achieving that goal.
Just as a single task (or tasks with common traits) can influence an entire project, a single project
can influence an entire organization. Up until now, the assumption has been that project
managers and risk managers will function within an organization’s tolerances. The limits that an
organization sets on what is (and what is not) acceptable are vital boundaries for project
behavior. Still, there are two crucial perspectives to consider here. One is the obvious—how does
the project’s risk taking (and data gathering for those risks) potentially put the organization at
risk? The other is slightly less obvious—how does the organization’s risk taking (and data
gathering for those risks) potentially put the project at risk? Both are important.
Project Risks in an Organizational Context
As discussed earlier, projects must function within the boundaries of organizational tolerances.
For example, if the organization will not tolerate projects outside a specified set of compliance
boundaries, any risk that might drive the project outside those boundaries is wholly
unacceptable.
To serve this condition, project managers must know what the boundaries are. As project data
are collected, those boundaries become all important. Driving back to the earlier discussion in
this chapter on data sources and degrees of accuracy, the needs of the organization in those
regards should drive what information is collected and how the risk information is collected.
The United States has a health care privacy law known as the Health Insurance Portability and
Accountability Act (HIPAA). This law governs how health care information can be used, shared,
and applied. Any organization that falls under HIPAA constraints must follow the HIPAA rules
for compliance. HIPAA limits what information may be made readily available and the forms
and formats in which information may be revealed. If a project manager identifies a risk that
team members might fall ill during the project, the mitigation strategy might be to ask about team
members’ past medical histories. Although this could mitigate the specific risks, asking the
question would violate HIPAA compliance regarding personal information. The project might be
lower risk, but the data gathering would clearly cross organizational boundaries.
Organizational Risk Taking in a Project Context
At a far more macro level, the executive echelons in most organizations take risks on a regular
basis. Many are grounded in simple risk–reward considerations. The questions asked are
relatively simple:
What aspect of the organization is being put at risk?

What is the potential reward for doing so?
Is the reward significant enough to offset the risk and its relative probability of occurrence?
The question that is rarely asked is:
How might pursuit of this risk potentially influence the projects currently in play?
Organizational Aspects as Risk Sources/Drivers
Risk at the organizational level is not often limited to a single department or division. When
determining approaches for the entire organization, risks generated can widely encompass a
variety of different components of the organization. A decision to move to a specific type of
software platform stretches well beyond the information technologies (IT) department. Any
division or project that uses software within the organization will be influenced by this type of
strategic decision. In such a far-reaching organizational approach, the new software can become
a source of risk at a variety of levels:
Any software deployed to develop the project will have to function on the newer platform,
creating the risk that it might not.
Any end users familiar with the existing platform might not be capable on the new platform,
generating delays and rework.
Team members responsible for data entry could find themselves redoubling their efforts to
generate workable outputs.
The shift to a new platform might have shown high reward and low risk at the organizational
level, but at the project or departmental level, the shift becomes a major source of risk.
In any case, as a project is in process, the project manager and the risk owners become
responsible for analyzing data not only in a project context, but also in an organizational context.
In both of those contexts, it’s also important to realize that risks cut two ways. The
organization’s changes can become a source of risk at the project level, even when the two are
not directly related. The project’s risk realizations (as well as risks not yet realized) can
potentially generate concerns beyond the risk tolerance of the organization as a whole (while not
creating the same concerns at the project level).
Rewards in Risk–Reward
In a data collection effort, most evaluations of risk–reward tend to lean toward rewards as
monetary. Although financial considerations often drive projects, there are many projects where
the rewards are not sold as financial. Some organizations prize quality above all else. Others see
their organizational prowess as being lean or fast. In organizations where financial considerations
are not primary, it becomes important to determine the metrics that will be applied and evaluated.
Quality, for example, might be measured by the lack of customer complaints or by the number of
customer compliments. Quality might also be measured by defect rates. When organizations
determine rewards that are outside conventional boundaries, the ripple effect down to the project
level can be significant. As management guru Peter Drucker famously said, What gets measured
gets managed—even when it’s pointless to measure and manage it, and even if it harms the
purpose of the organization to do so.
In any case, the challenge is to ensure that the metrics selected at the organizational level are
mirrored at the project level. If project managers opt to catalog and evaluate different metrics to
serve common organizational metrics, such efforts might run counter to the desires of senior
management.
Rewards to Offset Risks
Ultimately, the rewards are perceived as potential offsets to project risks. But the question is
whether the reward is sufficient to truly offset the risk, not just within a project, but to the
organization as a whole. Although a risk might be financially recovered at the project level, if
public image is a primary organizational concern, the public image of a project misstep might be
seen as unacceptable at the organizational level, although the project would ultimately survive.
This goes to the old medical axiom that the operation was a success, but the patient died.
In most organizations, the key concern is the survival of the enterprise itself. Although projects
might generate new opportunities and open up new capabilities, if they don’t afford the
organization the ability to perpetuate itself, no level of alternate reward has sufficient value to
warrant moving forward.
Not quite as important, but by no means dismissible, is the impact of the risk and its rewards on
other projects in play at the same time. Projects can unintentionally have competing goals,
creating a situation where the success of one project leads to the damage (or demise) of another.
All these considerations need to be taken into account in terms of the risk exposure of the
project, the competing projects, and the organization as a whole.
found.

Element Number
Paragraphs All project risk monitoring and control hinges on data. 282
Section Data Sources 282

Section Degrees of Accuracy 283
Section High-Probability Risk Realization 284
Section High-Impact Risk Realization 285
Section Anti-fragility 286
Section Overall Risk and Project Influence 286
Paragraph For all these considerations, the evaluations should be 288

conducted both at the project and organizational levels.
data source
claiming techniques
accuracy
precision
dependent probability
resilience
anti-fragility
risk–reward
Review Questions
Your risk data are largely archived in the risk register, and at the end of the project, it will be sent
to the risk repository. Much of the data for your current project is coming from Ffodam, Inc., a
project partner that you’ve just learned is under federal investigation for falsifying reports and
projections. Which of the following statements is true about your primary data source?
1. The data source may be jeopardized, but the data might still be valid, so you should continue
to use it.
2. The data source doesn’t matter, but you should work to establish one that doesn’t have the
taint of a federal investigation.
3. The data source may be jeopardized, and you should schedule a meeting with Ffodam.
4. The data source may be jeopardized, and the data provided must be reviewed for accuracy.
5. The data source is compromised, and repairs to the data should be funded from contingency
reserves and management reserves.
You are tasked with providing 10,000 helium-filled balloons to release on New Year’s Eve at
11:59:59 p.m. The customer wants them to rain down on revelers at their annual “Ring in the
New” party. Your team members keep trying to ensure they have precisely 10,000 balloons, but
some pop. Others slowly deflate. They count and recount the balloons night and day, and keep
coming up with a number, but it’s not 10,000. Oddly enough, the last eight counts all identified
10,003 balloons. Even though you adjust for popping and deflation, each count identifies 10,003.
Given the last eight balloon counts, what can you report to the customer?
1. You have high precision and high accuracy on the count.

2. You have high precision and low accuracy on the count.
3. You have low precision and high accuracy on the count.
4. You have low precision and low accuracy on the count.
5. They’re in big trouble, because helium balloons won’t go down—they’ll go up!
You work building solar farms. One of the big risks is heliostat fires. The fires are caused by the
sun-directing mirrors on the farm. The probability of a single heliostat fire has been classified as
“high,” and the costs are in the millions of dollars. Your company pays hundreds of thousands of
dollars a year in insurance to transfer the risk of such fires. Despite the fact that these fires are
commonplace in the solar industry, your company has not had a single heliostat fire in three
years. The insurance premiums seem excessive, but upon investigation, you learn that your
insurance is about as cheap as it gets. You are coming up on insurance renewal season for your
big solar farm. Based on your recent experiences, what should you do?
1. Accept the risks and drop the insurance.

2. Recognize that high probability doesn’t connote certainty, and continue with the current
approach.
3. Conduct workarounds.
4. Recognize that the probability and impact have changed, and reconsider your approach.
5. Convert to geothermal.
Your organization has suffered issue after issue as risks are realized. The old axiom that “when it
rains, it pours,” is not lost on anyone who works there. Despite all the threats that have been
realized, each time your organization bounces back. It comes back just as strong, just as
effective, and just as efficient as before. You have always been impressed at the organization’s
capacity not to miss a beat in keeping outputs flowing. What term best describes your
organization?
1. Anti-fragile
2. Resilient
3. Risk averse
4. Risk prone
5. Lucky
Which of the following statements are true? (Choose two)
1. Individual project risk events are isolated to the work package driving them.
2. Overall project risk might be increased or decreased by individual project risk events.
3. The best tool for evaluating overall project risk is Monte Carlo analysis.
4. Overall project risk applies only in projects applying a predictive, rather than an adaptive,
model.
5. There are no individual project risk events in an Agile or adaptive project.
You are evaluating the risk–reward of your project. The current project assessments by your
business analyst show that the project will generate a return on investment (ROI) of 17 percent.
Coincidentally, that’s also the lowest acceptable ROI for clearance to proceed. If the project goes
well, it could mean future work with the same client for decades to come. If it goes poorly, even
in the slightest, the ROI could dip below 17 percent, rendering the project unacceptable. Your
employer is excited about the possibilities, with a vision to the future. You already have
questions about the business analysis, because you think the analyst may have massaged the
numbers to get the project cleared. You believe a major risk at the outset is that the requirements
may not be clearly spelled out, causing significant hidden costs and delays. You want to bring
this to your project sponsor’s attention. You should inform the sponsor that:
1. The project will likely not achieve its ROI and thus may not be worthwhile.
2. The project is being evaluated and validated based on a potentially false set of assumptions.
3. The project may bring a lot of future work, but likely won’t achieve 17 percent ROI.
4. The project’s “go” criteria should be reevaluated to account for both the ROI and the potential
future work if the project is to proceed.
5. It’s time to kill the project.
You identify a risk that Janelle may be the only operator who knows how to work a particular
piece of equipment, and if she’s injured, all work on that equipment may be delayed. In a
conference room presentation, you share that risk and notice that three of the other people in the
room become visibly agitated. When you ask if there’s a problem, they all say similar things—
she’s working on my project, too! You realize that the risk you identified for your project might
actually be a risk for other projects as well. What should you tell your peers?
1. Tell them that this is your risk, and if they see it as a problem, they should identify it in their
risk registers.
2. Tell them that this is your risk, but it will eventually be recorded in the risk repository.
3. Explain that this has moved beyond being an individual project risk and has a ripple effect
across the organization that should be jointly addressed.
4. Explain that this has moved from being an organizational risk to impacting your project
directly.
5. There’s a clear need to hire more staff with Janelle’s talents.
Chapter 17
The Leftovers and the Latecomers

Late-Risk Reporting
Monitoring and controlling risks is a basic process step in risk management. But it takes on a
different dimension when it comes to the risks that an organization accepts over time, and the
risks that have been generated by the project approach and by the risk approach.
Residual risks (the leftovers) were discussed in depth in Chapter 15, “Response
Implementation.” These are the risks that are to be absorbed by the producing organization by
virtue of inaction or by a conscious decision to accept a certain level of threat without full
coverage. Sometimes, the outcome of a risk event is that nothing happened. In such instances,
the owners of the residual risks only had to absorb the administrative burden of tracking the
threat. But tracking the residual risks is critical if an organization believes that the impact of the
threat might shift over time.
Secondary risks are those risks generated by the risk responses. Here, there’s the possibility that
the secondary risk might be either opportunity or threat. In monitoring and controlling these
risks, the project manager and the risk owner need to evaluate whether the probability or impact
of these risks is shifting with the implementation of the strategy. A dangerous intersection might
be mitigated with a four-way stop. If the secondary risk is traffic backups, the strategy for the
secondary risk might be to build a roundabout to keep traffic flowing. Forty years ago, such
roundabouts were rarely used for traffic mitigation, creating risk for those who didn’t know how
to navigate them. A generation of drivers later, the probability and impact of that secondary risk
has largely passed.
As with risks in general, residual and secondary risks need to be evaluated in an organizational
context. Also as with risks in general, the outcomes (success and failure) of risk responses
associated with these types of risk need to be communicated far and wide.
This chapter reviews the implications of monitoring and control of secondary and residual risk.
Monitor and Close Risks Task 2 Monitor residual and secondary risks
Residuals and Deductibles 1, 2
Response-Generated Risks 3–5
Late Risk Reporting 6–8

Caution
Your project has a liability insurance policy to cover any potential injuries incurred during the
life of the project. The policy was expensed directly to your project at a cost of $400,000 and
covers injuries up to $100,000,000. The deductible on the policy is $4,000 per incident. You
have just suffered your first claim against the policy, to the tune of $1,000,000. The insurance
company paid out after you covered the deductible. You’re now a little worried that there might
be a second incident. Assuming it would be roughly the same order of magnitude as the first
realized risk, your residual risk for that incident would be what?
1. $4,000
2. $396,000
3. $400,000
4. $996,000
5. $1,000,000
It’s been a tough project, and you have realized many of the threats that you feared the most.
You have mitigation strategies in place for the remaining risks and are working diligently to
ensure that your risk owners are doing their job of tracking and monitoring the implementation
of those strategies. You are satisfied that you have the right practices and people in place to keep
costs and schedules on target. Still, you are aware that if many more risks are realized, there’s a
distinct possibility that the organization will suffer some reputational damage, even if the project
is brought in on time, on budget, and to specification. Which of the following statements is true?
1. Even if the constraints of time, cost, and quality are met, there are still residual reputational
risks.
2. If the constraints of time, cost, and quality are met, there are no residual risks.
3. Because residual risks apply only to time and cost, the other risks are considered moot.
4. If you have been hit by multiple risk events on an ongoing basis, your residual risk is likely
rising dramatically.
5. Residual risks are the responsibility of the product owner, rather than the project manager and
team.
Your company makes flying cars. Despite the fact that they have all the latest technologies, you
are worried about some of the same concerns associated with traditional vehicles, such as
crashes. You face the threat that if there’s an accident, the driver of your vehicle could be killed.
You have mitigated that threat by installing air bags to protect the driver and their passenger.
During early testing, one of your staff, Melina, points out her big concern. Melina is 4’8” tall and
weighs about 90 pounds. She suggests that the air bags, when deployed, could kill her. “This
wouldn’t happen if you didn’t install air bags,” she points out. In your research, you find that
roughly 300 people have been killed by air bags since they first came into common use in 1990.
The chance of Melina being killed by an airbag represents what type of risk?
1. This is residual risk where the organization will retain the risk that some people may die as a
result of their air bags.
2. This is secondary risk where the organization created the risk with the risk response chosen.
3. This is ancillary risk associated with a rare experience, reported only in the hundreds with
millions or billions of miles traveled.
4. This is residual risk where the organization created the risk with the response chosen.
5. This is secondary risk where the organization will retain the risk that some people may die as
a result of their air bags.
You have a project where there’s a possibility that the facility you’re building might sink into a
type of moving soil called “marine clay,” rendering it uninhabitable. You have identified the risk
as The building might sink, rendering it uninhabitable. Your project has a total budget of
$1,500,000. Remediating the marine clay through removal and chemical treatment will cost more
than $250,000. It also creates the new risk that the chemical treatment could prove hazardous to
humans, causing the building to be uninhabitable anyhow. From a risk perspective, what does
this mean, and what action should you take?
1. It means that the impact of the primary and secondary risks is the same, so acceptance would
be the appropriate response.
2. It means that the impact of the primary and secondary risks is the same, so avoidance would
be the appropriate response.
3. It means that the expected value of the secondary risk is just as bad as for the primary risk, so
acceptance would be the appropriate response.
4. It means that the expected value of the secondary risk is just as bad as for the primary risk, so
avoidance would be the appropriate response.
5. It means that the project sponsor has chosen the wrong project and should suffer punitive
action for their choice.
Project velocity is a key metric in your organization. Month after month, you see the project
velocity is increasing, and the impacts to your overall project schedule are dramatic. You are
considering a risk response to encourage this type of behavior in the future. The biggest
secondary risk is that your approach might create the false impression that every project that
comes in early will reward team members with similar rewards. Those expectations would be
sorely misplaced, given that your organization doesn’t tend to hand out rewards lightly. In
making a final decision on how to deal with this secondary risk, what should you do?
1. Tell the team members that you were thinking about giving them rewards, but had second
thoughts, but you want them to know how much you appreciate their efforts. There will be no
reward.
2. Recognize that according to Herzberg’s theories of motivation and hygiene, the rewards need
to be tied directly to the behavior, or they risk becoming hygiene factors. You grant the
rewards with ample caveats about team expectations.
3. Tell the team members that you are giving them rewards based on schedule improvement.
4. Work to institutionalize the policy that early projects get rewarded.
5. Accept it. People will never punish you for doing good things.
Your risk strategy was to actively accept the risk that there could be a fire in the building during
the course of the project. As if on cue, the building went up in flames three days after the project
began. The fire department’s efforts were outstanding, and you had a backup site identified just
in case the threat converted to an issue. Because the project was barely underway, the experience
is largely considered a hiccup. It’s a minor impact with nominal rework involved. Since the
event, however, you’ve realized that you probably should have resorted to cloud storage for the
project information, because if the project was further along, the outcome could have been
disastrous. In filing reports with management, what should you tell them?
1. The response strategy was insufficient.

2. Acceptance should never be applied to risks with significant impacts.
3. The risk response was successful.
4. The risk response succeeded but should not be adopted for future risks of a similar nature.
5. The risk response succeeded, but needs to be clarified.
You knew it was too good to be true. Everything on the project was going extremely well, when
suddenly it wasn’t. A major pandemic hit. Team members quit. Interpretation of requirements
proved to be a bone of contention with the customer. Many of the risks that hadn’t happened
through the life of the project were suddenly realized in a single month. Up until now, you have
told management that the risk responses that you and your team were deploying were working
like a finely oiled machine. Now, just four months away from the end of the effort, everything
seems to be going wrong. These are both things that were on your “top list” of risks, as well as
things you hadn’t even considered as concerns. For now, however, your responses seem to be
working, both the planned and unplanned responses. Most of your planned responses involved
mitigation. In your next risk report, what should you record for posterity?
1. The project responses worked well, and there was no need for workarounds.
2. The project responses worked well, and here are the details on the workarounds deployed.
3. The project responses failed, and as such, there was no need for workarounds.
4. The project responses failed, and here are the details on the workarounds deployed.
5. Workarounds should be the primary approach to dealing with project risk.
Your project is almost complete. Early in the project, however, you identified risks that the
customer might not sign off, delaying payment. You mitigated the risk by repeatedly getting
signatures at every interval through the life of the project. The customer has expressed nothing
but delight on the latter days of the project and has assured you that they’re eager to do work
with your organization in the future. As a result of what you’ve done, you remain confident that
the risk you identified at the beginning will no longer be a threat. What should you do about that
risk?
1. Keep it in the risk register as “retired” or “expired.”

2. Keep it in the risk register until the last payment is made.
3. Keep it in the risk register, increasing the probability as the project gets closer to the end.
4. Keep it in the risk register, lowering the impact as the project gets closer to the end.
5. Remove it from the risk register.
Foundation Topics
As a project draws to a close, risk does not go away. It remains pervasive until the project is
finally transitioned to the customer and the project books are closed out. Although certain
specific risks might be closed through avoidance or by their total elimination, in all, both threats
and opportunities linger at the end of a project. From the threat perspective, the twilight of a
project becomes the time when documentation and evaluation of risk responses becomes vital.
Risks, whether realized or not, need to become part of the project archive. In particular,
responses need to be assessed to determine three vital considerations:
Were they deployed? (And if so, how?)

Did they work as intended?
Is there residual risk both for the rest of the project’s life and for the performing organization
on an ongoing basis?
In a late-project review of risk information, the viability of responses needs to carry over for
other project managers on other projects for reuse and reapplication.
Deployed and Undeployed Responses
Reflecting back on Chapter 14, “Response Planning,” a variety of responses exist that could have
been chosen to deal with project risks. Responses that mitigate or enhance impact (both threat
and opportunity) and those that actively accept threats often are not put into serious play until the
risk event is realized. Such deployed responses might have the desired outcome—they
minimized the pain of threats or increased the joy associated with opportunity. During
deployment, the nuances of how they achieved those goals should be captured. Some of the tacit
knowledge needs to be transferred at the end of the project, including key personnel required to
make the strategy successful and communications events supporting implementation.
This information can be captured in the risk register or in post-project risk reporting; however,
the key is to clarify which strategies were put into action and their results. It’s also vital to note
when a strategy wasn’t deployed (because the risk was never realized), but the retrospective on
the strategy is that it would have (or wouldn’t have) worked, had the risk transpired. The absence
of a risk event does not indicate the failure or success of the strategy. It simply indicates that the
strategy was never put to the test.
Intended and Unintended Outcomes
The term unintended consequences was meant for risk responses. If you have an allergy attack
and take a medication as a workaround, you don’t expect that you’ll be allergic to the allergy
medication. Such a rare situation can happen and land the unfortunate victim in the hospital for
anaphylaxis. Risk responses, good and bad, can have both intended and unintended outcomes.
For intended outcomes, the rules are simple. Declare victory, capture the details, and move on.
Sometimes risk responses work in the ways in which they are intended. Seatbelts work. Air bags
save lives. Individuals who fall out of watercraft can be saved by their flotation devices. In many
cases, such successes are the result of precise rules-following by those who suffered the risk.
When some risk responses fail, it can be because of missed steps or because the response was not
adequate to the task.
Chapter 9, “Applying Triggers and Thresholds,” discussed the example of the dangers of the
Grand Canyon. The vistas need not be as dramatic as the canyon to present some of the same
dangers. At the Palisades Center Mall in West Nyack, New York, they identified the risk that
patrons might get too close to the edge of the upper floors and tumble to their death. As a
mitigation strategy, they installed 3.5-foot-high railings to prevent patrons from falling. The
intended consequence? Stop people from falling to their death. The strategy, however, has
proven somewhat ineffective, because more than a half-dozen people have died falling from the
upper floors of the mall since 2005. Some victims’ families contend the railings should be
higher. But it’s also possible that the railings provided a false sense of security—an unintended
consequence.
For unintended consequences, the documentation and research need to be all the more thorough.
It’s one thing for a response strategy to fail. It’s another entirely to suffer unforeseen secondary
risks-turned-issues. For such situations, the project and risk teams are responsible to determine
why the risks were unforeseen, and why those secondary risks were realized. It might be that the
strategy was ineffective. It could also be a one-off situation where no reasonable manager could
have seen it coming. In either instance, future managers need the insights and reflections of those
who lived the experience.
Residual Project and Organizational Risk
Just as it’s important to document the outcomes and their impacts, it’s also critical to capture the
nature and amounts of residual risk. The residual risks might last only until the project is
complete, or might last well beyond the project’s life through the impact to the organization.
They are most noticeable as financial risks, but can be just as impactful, if not more so, as risks
to quality or reputation.
Residual Financial Risk
The residual financial risks that terminate with the end of the project are those that can be
accounted for purely within the project budget. Although they could have caused overspending,
they are documented with the final project accounting and are put to rest as the project records
are archived.
When the spending is well outside the project’s parameters and influences the annual (or other
periodic) organizational spending plans, such residual risk can have a far more lasting influence.
Such residual risks will require more extensive documentation to support why the organization
continued to put money into this particular effort.
Residual Quality Risk
In many ways, residual quality risks are far more damaging than financial risks (particularly
because they can have long-term financial implications). Again, if the risks are confined to the
project (and its products), the impacts of risks unaddressed or left over in the project might
influence a small customer segment.
But if the risks and their leftover quality failings extend beyond the project, such residual risks
can lead to the perception that the organization is in ways quality deficient.
The 1970s episode with the Ford Pinto is a classic example where the residual quality risks of a
new model line took its toll on the organization itself. When the Ford Motor Company
discovered that the Pinto’s gas tank placement created a propensity for explosions, the company
chose to accept the risk rather than deploy two safety strategies that would have added about $10
to the cost of each vehicle. The risk was that the car would explode in a crash, causing deaths.
Although Ford did its own internal calculations in terms of dollars and cents, the real residual
risk was in terms of the perception of quality. Today, more than 50 years after the introduction of
the Pinto, it continues to be held up as an icon of poor quality. Ford continues to pay a price for a
half-century-old risk unaddressed.
Residual Reputational Risk
Tied directly to quality is reputation. Risk responses leave reputations in their wake. Chapter 13,
“Risk Complexity, Assessment, and Analysis,” briefly addressed the Tylenol tampering attack.
In 1982, seven Chicago-area residents were murdered by an attacker (as of this writing still
unknown) who tainted bottles of Tylenol with cyanide, leading to their poisoning deaths. Many
officials and members of the media called for Johnson & Johnson to pull Tylenol from the
market. Instead, Tylenol leadership determined that their response would be to create tamper-
proof and tamper-resistant packaging and medication to preclude such situations in the future. If
their strategy worked, they needn’t worry about future attacks.
The strategy worked.
The residual risk from that strategy was that others would make J&J a target for future
tampering. The residual risks were also that the public would not come back to J&J for
analgesics.
Because of the firm stance of management, those risks were never realized. In fact, the residual
risks in the tampering scandals proved to be opportunities. Johnson and Johnson proved
themselves to be anti-fragile in this situation.
This kind of outcome needs to be documented in detail. It was. The J&J response has become an
industry (and public relations) standard. Transparency is crucial when dealing with residual
reputational risk.
Secondary risks are driven not by the project, but by the strategies meant to deal with risk on the
project. Because of this dependent relationship, many response-generated risks don’t occur until
late in the project life cycle. By this time in a project’s life, documentation is often seen as an
unnecessary administrative burden. Nothing could be further from the truth. Documenting
response-generated risks becomes all the more crucial, because this is when they appear.
Because secondary risks are more probable later in the life cycle, team members who have been
with the project from the beginning will not need to be educated in the project environment or
the rationale behind responses to these risks. Newcomers to the project, however, will need that
education. It’s challenging to understand why these risks were allowed to evolve without a clear
understanding of the risk environment and the specific responses that create new risks.
Risk Environment and Response-Generated Risk
Risk responses (including the most common response—acceptance) create varying degrees of
new risk based on the environment. In an organizational climate where management champions
projects and supports well-considered risk management practices, the project manager might
accept certain risks based on the assumption that management will provide support, even in the
project’s darkest hours. For example, the risk might be, The customer might be upset about
project performance and pull out from the project. Acceptance of such a risk might create a new
risk that the project manager’s inaction might be seen as ennui, leading to frustration not only
from the customer, but from the producing team as well. A project manager who doesn’t work in
an environment where management serves as champion might never accept the risk. Thus,
without the acceptance strategy in place, but another, more active strategy, the project and/or risk
manager will be seen as actively engaged in managing the risk, eliminating the secondary risk.
This also ties to risk tolerances. As a project moves closer to closing, the probability of many
risks is reduced. There simply isn’t time for them to occur. The other side of that equation is that
the impact of many risks dramatically increases, because late-in-the-game risks can drive far
more deleterious outcomes than those that happen on day one. Secondary risk needs to be
reevaluated repeatedly, nearing the end of the project, because the amounts at stake escalate.
Probability is rarely a consideration in risk tolerance. Impact is always a consideration.
Specific Responses That Generate Risk
Every risk response changes the risk environment; however, there are some classic responses that
inherently drive enough change to generate risk. Contract risks are a prime example. The
gradient of secondary risk driven by contract choice leads to a classic set of questions on the
PMI-RMP® exam. The contract types are described in the sections that follow, in order, coupled
with the nature of the secondary risks that they generate for the buyer, the seller, or both.
Firm-Fixed Price Contracts
Firm-fixed Price contracts are often referred to as lump-sum contracts because they’re often paid
in a single payment. The firm-fixed price contract is a low risk to the buyer and a high risk to the
seller because the contract is contingent on seller performance for a specific financial value.
These contracts are often chosen because of their low administrative costs and because there’s
very little financial tracking required by either party. For the seller, however, these
administratively low-risk efforts generate secondary risks in that if costs increase, the seller has
no recourse. The price tag will remain the same, no matter what.
Fixed-Price Economic Adjustment (FPEA) Contracts
In a fixed-price economic adjustment (FPEA) environment, the contract is designed to

minimize or eliminate a single risk to the seller. Otherwise, all the traits of this contract are
identical to firm-fixed contracts. A shipper, for example, might agree to an FPEA with a fixed
price for any shipment under 100 pounds. The caveat (which would be built into the contract)
would be that if gasoline prices on a national survey exceed $7.00/gallon, a surcharge of $20
would apply. That surcharge is the economic adjustment.
This minimizes one risk to the seller. But again, adjusting the environment creates secondary
risks. The $20 surcharge could price the seller out of the market. That risk would never exist if
this particular contract type were not in place.
Fixed-Price Incentive Fee (FPI or FPIF) Contracts
The fixed-price incentive fee (FPI or FPIF) environment allows for some degree of risk-sharing
among all parties. It is higher risk to the buyer than an FPEA, in that the buyer agrees to take on
a share of the cost overruns by the seller. (The opportunity-based risk is that the buyer also
agrees to receive a share of any cost underruns by the seller.) The buyer is further protected by a
ceiling price or not-to-exceed price. When the seller’s allowable costs (cost types that are
allowed under the contract), coupled with their adjusted fee, hit the ceiling, the contract has
reached the point of total assumption (PTA). Any costs incurred beyond that point are no longer
shared between the buyer and seller. They are owned purely by the seller.
The risk in an FPI contract is that the seller might hit the ceiling (which first happens leaving at
least some of the fee behind), causing the seller organization to pay for all excess costs from that
point forward. When that happens, the secondary risk is that the allowable costs may exceed the
ceiling with no fee whatsoever, turning the project into a loss.
All the risks in this environment are based on a contract device called the sharing ratio. That
ratio is determined contractually. Somewhere in an FPI contract, there will be a specific clause
calling out the ratio as 75/25 or 60/40 or 50/50. The first number in those ratios is the buyer’s
share. The second number is the seller’s share. If there is a $100,000 overrun in an FPI with a
75/25 sharing ratio, the buyer will assume responsibility for $75,000. If there is a $20,000
underrun in an FPI with the same ratio, the buyer will see their final price discounted by $15,000.
Cost-Plus Incentive Fee (CPIF) Contracts
As the name implies, the seller in cost-plus incentive fee (CPIF) contract situations will have all
their allowable costs covered (hence the name, cost-plus). The risk to the seller is lowered,
because there is no ceiling price in this environment. The secondary risk created by such
environments is that some sellers may no longer feel compelled to keep costs in check, leading to
both a lax attitude on cost and a willingness to accept financial risks that would otherwise seem
untenable.
As with the FPI contract, the cost-plus incentive fee contract has a sharing ratio. But without the
ceiling, the buyer is at risk of excess costs well in excess of those in the FPI environment.
Cost-Plus Award Fee (CPAF) Contracts
Cost-plus award fee (CPAF) contracts are like all cost reimbursement contracts in that the
allowable costs will be covered by the buyer. The risk to the seller is lowered in that there is a
contractually dictated scheme to determine how the award fee will be granted. In such contracts,
the seller is incentivized to meet the criteria spelled out in the contract for the award fee. Such
criteria are objective, subjective, or both.
The secondary risk of selecting such contracts is often contingent on those criteria. Objective
criteria, no matter how carefully established, need to be interpreted for the seller to receive the
fee. Management guru Peter Drucker said, What gets measured gets managed—even when it’s
pointless to measure and manage it. The secondary risk created by the contract type selection
(which is the primary risk response) is that team members, project management, and even the
customer may engage in worthless analysis, leading to increased costs and frustration. Subjective
criteria normally rest in the hands of the buyer, increasing the secondary risk to the seller,
because the buyer alone makes the determination as to whether the criteria have been met.
Cost-Plus Fixed Fee (CPFF) Contracts
The cost-plus fixed fee (CPFF) contract is selected to minimize risk to the seller, because the
seller not only recovers all of their costs, but also receives a fixed fee for work completed. The
secondary risks are similar to all those in cost reimbursement contracts—that some sellers might
no longer feel compelled to keep costs in check, leading to both a lax attitude on cost and a
willingness to accept financial risks that would otherwise seem untenable.
In this contractual environment, the incentive to keep costs in check is lower than those already
discussed, because the fee is fixed and will ultimately be awarded in full, as long as the project is
complete. The advantages to the seller are significant.
Time and Materials (T&M) Contracts
All the contract types already discussed involve actual, allowable costs. That’s not the case in a
time and materials (T&M) contract. In the T&M environment, the risk to the buyer is greater, in
that they are not billed for real costs, but for worker classifications and materials.
People enter into T&M contracts on a regular basis when they have their cars repaired. In a cost-
plus environment, the buyer would pay for the real costs (salary plus overhead plus fees) of a
mechanic. In a T&M, the mechanic would have a classification (e.g., Mechanic One, Mechanic
Seven) to identify the relative skill level of the individual required to perform an aspect of the
work. If Pat is a Mechanic One and Pat’s fully loaded (or fully burdened) rate is $80/hour, a cost
reimbursement contract would remunerate the seller organization $80 for every hour of Pat’s
time. In the same scenario, if the contract is time and materials, Mechanic One staff might be
listed on a rate sheet at $100/hour. In a T&M, the buyer would be charged $100 for every hour of
Pat’s time.
The secondary risks in a T&M are legion. Pat might be the best mechanic who ever lived,
creating an opportunity risk that the work we’ll get is actually a bargain. Conversely, Pat might
be a dolt, unable to screw in a lightbulb, creating a threat risk that the work we’ll get will be
substandard. The buyer in a T&M has extremely high risk in that new work might be required
when the project is only partially complete, and the buyer is locked into the rate sheet for the
staff performing the work.
The secondary risk to the seller in this environment is that this is the only contract type where the
buyer may, at any time, call a halt to the work and pay only for the work performed to date. The
seller might believe the buyer would never take such action, but if the costs become sufficiently
high, it’s a possibility, both logistically and legally.
Cost-Plus Percentage of Cost (CPPC) Contracts

The cost-plus percentage of cost (CPPC) contract type is so advantageous to the seller that it is
no longer legal for U.S. federal contracts. The U.S. government will not engage in these contract
types largely because of the secondary risks associated with their selection. In a cost-plus
percentage of cost contract, the seller will recover all allowable costs. In addition to the costs, the
fee for the seller is directly based on spending. If the target cost of the contract is $1,000,000,
and the fee is 10%, then the final target price to the buyer would be $1,100,000. Given that this is
a cost-plus contract, if the allowable costs under the contract climb to $4,000,000, then the final
actual price to the buyer would be $4,400,000. The secondary risk of this contract choice is that
there is zero incentive for the seller to keep costs in check, potentially leading to massive cost
overruns. It is the contract type with the highest overall risk to the buyer and the absolute lowest
risk to the seller.
Contract Type Summary
All the contract type selections represent risk responses. Every choice of contract type shifts the
risk from one party to the other and creates a unique level of pressure on buyer and/or seller. For
the exam, it’s important to know the relative levels of risk associated with the different contract
types (which are the greater risk to the buyer and seller), as well as the nature of the associated
secondary risk. Table 17-2 outlines the contract types and their relative level of risk to buyer and
seller.
Table 17-2 Contract Types and Relative Risk
Contract
Nature of the Contract Risk Level
Type
Firm-fixed Single fixed payment (lump sum) for a Highest risk to the seller.
price well-defined type of work. Lowest risk to the buyer.
Fixed- Single fixed payment for well-defined High risk to the seller.
price type of work, with a single risk element Low risk to the buyer, save for
economic transferred to the buyer. the area of economic
adjustment adjustment.
Fixed- A sharing arrangement where the buyer Higher risk to the seller if cost
price and seller agree to share overruns or overruns drive the contract to
incentive underruns based on a contractual sharing where the seller assumes all
fee ratio. The buyer is protected by a “not to future costs in the contract
exceed” ceiling price. (point of total assumption).
Mid-range risk to the buyer,
because they become
responsible for sharing cost
overruns and underruns.
Cost-plus A sharing arrangement where the buyer Higher risk to the buyer,
incentive and seller agree to share overruns or because they will cover all
fee underruns based on a contractual sharing allowable costs.
ratio. The buyer agrees to cover all Mid-range risk to the seller,
allowable costs. because they remain
responsible for sharing cost
overruns and underruns.
Cost-plus An arrangement where the buyer covers Higher risk to the buyer,
award fee all allowable costs and pays a fee based because they will cover all
on the seller’s performance against a allowable costs.
preordained set of criteria. Mid-range risk to the seller,
because they must find the
means to achieve the
performance goals of the
preordained criteria.
Cost-plus An arrangement where the buyer covers High risk to the buyer, because
fixed fee all allowable costs and pays a fee based they will cover all allowable
on the fixed amount set out in the costs plus the fixed fee.
contract. Low risk to the seller, because
they need only track their
allowable costs.
Time and An arrangement where the buyer pays all High risk to the buyer, because
materials labor costs identified in the contract, as they will cover all costs.
well as all materials costs. Costs are Low risk to the seller, because
based on a preset scale, rather than actual they preordain the labor hours
allowable costs. and the costs of materials.
Cost-plus An arrangement where the buyer covers Extremely high risk to the
percentage all allowable costs and pays a fee based buyer, because the fee is driven
of cost on a percentage of the allowable costs by allowable cost spending, no
expended. matter how high it gets.
Low risk, high opportunity to
the seller, because the more
they spend, the higher their fee
will ultimately be.
Late Risk Reporting
Complacency is the enemy of the end of a project, particularly when it comes to risk
management. The rituals of risk reporting remain in place through the very end. Risk reports,
registers, and the risk management plan need to be reviewed and potentially updated whenever
change is planned, when change occurs, and at regular intervals. Because these three reporting
instances are not mutually exclusive, this can lead to a situation where risk reports may seem
almost redundant. That does not mean that any of the instances can be skipped along the way.
The most common significant changes in risk status toward the end of a project come in the risk
register because of the fine level of granularity involved. The changes in risk status that are the
most notable are those associated with workarounds, because they are completely unplanned.
Technically, because workarounds are implemented as a risk is realized, they are more a function
of issues management, rather than risk management.
Risk Register Updates
Updates to the risk register can occur simply due to the passage of time. Other risk register
updates occur because of a change in the environment or the nature of the risk event or response
itself. For each element of the risk register, there should be a function to track the edits, because
the changes and when they happen can be meaningful in terms of having an organizational
capability to build on risk history. Every aspect of the risk register can change over time:
Risk event: The way in which a risk is described could change due to clearer understanding
or because of alterations in the lexicon.
Probability: The probability of a risk event should decline (or at worst, remain the same)
over the life of a project, as more time has passed without occurrence.
Impact: The impact of a risk event often increases over the life of the project, because any
significant risk in the latter days creates a shorter timeframe for resolution.
Urgency: The urgency can change based on the timing or based on the cultural considerations
associated with the risk.
Propinquity: The intensity of management attention (or the echelon) can shift with the
vagaries of corporate responses to the project and its risks.
Proximity: If project locations shift, the risks could shift in this regard as well.
Dormancy: Degrees of dormancy can be altered based on detectability.
Manageability/controllability: In some environments, managers grow and evolve. These
qualities can shift based on the personnel assignments or on the personal growth of the
individuals involved.
Connectivity: Connections and cascading risks tend to lessen toward the end of a project,
because there are fewer moving parts when a project is almost complete.
Detectability (FMEA): Tools, awareness, and the passage of time can all have influence over
how visible and detectable a risk can be.
Strategic impact: As organizational strategies shift, so can the strategic impacts of the risks.
Overall risk: As all the components identified thus far shift, the overall risk can shift just as
readily.
Priority: This is an aspect of risk that will change over time. Tied to the overall risk,
priorities can change based on these formal considerations or on any shifts in tolerance in the
risk management plan.
Risk owner: As people come and go from projects, the names and contact information for
these individuals need to be updated as well.
Area(s) impacted: Entire departments come and go in today’s business climate. Updating
this information becomes a critical consideration.
Escalation: As the risks, the organization, and the owners change, the higher echelon
personnel who could ultimately take over a risk need to be updated.
Response strategy type: Notably, those risks originally marked for “acceptance” should be
reaffirmed as such late in the project, because inaction doesn’t mean they haven’t been
considered and aren’t being considered moving forward.
Response strategy narrative description: For those risks that have been realized, in
particular, any changes in the way in which the response strategy is expressed need to be
captured.
Implementation schedule: This is tied directly to the passage of time.
Implementation review: As discussed earlier in this chapter, the reviews should be tied to
any time that change is planned, that change occurs, and at regular intervals. As a project
nears completion, there should be fewer remaining reviews on the calendar.
Retirement criteria: The criteria ideally shouldn’t move, but could move as the end of a
project is imminent.
Follow-up: This should definitely be updated to reflect when the next review of the particular
risk will transpire.
Outcome: Notably, those risks originally marked for “acceptance” should be reaffirmed as
such late in the project, because inaction doesn’t mean they haven’t been considered and
aren’t being considered moving forward. “No change” is not the same as “no outcome.”
Archival location: As organizations and system administrators shift to different “clouds” on
the Internet or storage servers internally, where the risk data (past and present) are stored
needs to be reflected in any late-project reporting.
Workaround Reporting
Unplanned responses can lead to surprising outcomes—positive or negative. Workarounds are

the surprise packages of any project, given that the lack of planning can bring out the best or
worst in project managers, team members, and customers. In sports, what sometimes starts as a
workaround from a mistake turns into a standard play in future contests. In winemaking,
sparkling wines were invented when winemakers accidentally bottled the wine before
fermentation was complete. As they documented what had happened, an entire dimension was
added to the industry.
Nothing good comes of episodes that are not documented (good or bad). The more thoroughly
workarounds are documented, the more an organization can leverage them on future projects.
found.

Element Number
Section Deployed and Undeployed Responses 305

Section Residual Project and Organizational Risk 306
Paragraph Secondary risks being realized are more common in the 308
later days of a project.
Section Specific Responses That Generate Risk 309
Table 17-2 Contract Types and Relative Risk 313
Section Late Risk Reporting 314
Section Workaround Reporting 316
intended outcomes
unintended consequences
residual reputational risk
firm-fixed price
fixed-price economic adjustment
fixed-price incentive fee
cost-plus incentive fee
cost-plus award fee

cost-plus fixed fee
time and materials
cost-plus percentage of cost
workaround
Review Questions
You are conducting a late-project retrospective to determine which of your risk strategies worked
well and which did not. One of your risk strategies at mid-project was to bring in an outside
consultant to deal with your team’s shortage of expertise in dealing with the Food and Drug
Administration (FDA). The consultant, Guillame, dealt with all the FDA risks flawlessly,
because it looks like your project is going to be approved without incident. Guillame, however,
aggravated many of your project team members, driving them crazy to the point that they were
ready to resign their positions if you didn’t intervene. You never considered the possibility that a
single consultant could cause that much pain. What type of situation are you dealing with?
1. A successful mitigation strategy with intended and unintended consequences

2. A successful acceptance strategy with intended and unintended consequences
3. A successful transfer strategy with intended and unintended consequences
4. An unsuccessful mitigation strategy
5. An unsuccessful transfer strategy
Which of the following best describes secondary and residual risks?
1. Residual risks are risks generated by the risk responses and might be more prevalent toward
the end of a project. Secondary risks are risks that a project or organization assumes even after
the risk resolution strategies have been put in place.
2. Secondary risks are risks generated by the risk responses and might be more prevalent toward
the end of a project. Residual risks are risks that a project or organization assumes even after
the risk resolution strategies have been put in place.
3. The two terms are basically synonyms. They are both risks generated by the risk responses
and might be more prevalent toward the end of a project.
4. The two terms are basically synonyms. They are both risks that a project or organization
assumes even after the risk resolution strategies have been put in place.
5. They represent the positive, or opportunity, perspective on risk, creating environments where
the upside of risk is the prime consideration.
Your company sells goods across the United States. Because of your contract with the shipper,
you keep close watch over the cost of tolls on the major highways. You are the buyer in a
contract relationship with the shipper, and you want to reduce your risk as much as possible. The
shipper is insistent. They need a contract that allows you, the buyer, to absorb the risk-associated
highway tolls, which seem to escalate on an almost-weekly basis. The shipper would like to
work in a time-and-materials or cost-plus arrangement. You know that those are potential recipes
for long-term overspending. To meet all the competing needs in this situation, you recommend
what type of contract arrangement?
1. Firm-fixed price
2. Fixed-price economic adjustment
3. Fixed-price incentive fee
4. Cost-plus incentive fee
5. Cost-plus award fee
Your organization has some of the best negotiators in the world. They convinced your customer
to accept a cost-plus-percentage-of-cost contract, with a 5% percentage. Your original target cost
was $10,000,000. Things have not gone well. Your allowable costs on the project have escalated
to $20,000,000. If this becomes the final cost figure, what’s the final price to the buyer?
1. $10,000,000
2. $10,500,000
3. $20,000,000
4. $20,500,000
5. $21,000,000
1. In a time-and-materials contract, the seller minimizes cost risk, because all allowable costs
will be covered.
2. In a cost-plus or cost-reimbursement contract, the seller minimizes cost risk, because all
allowable costs will be covered.
3. In a firm-fixed-price contract, the seller has the lowest possible administrative burden of any
contract type.
4. In a firm-fixed-price contract, the buyer has the highest possible administrative burden of any
contract type.
5. Contract types have little or no influence on overall project risk.
Your project is progressing nicely, and the risks you have realized to date seem completely
manageable. Although you still have your work cut out for you as a project manager, you’re
pleased that very few of the risks you’ve identified are coming to pass. The project time
remaining is now measured in days, rather than months. Your sponsor has asked for an update.
What do you tell her?
1. You will continue to update the risk reports and risk register at regular intervals.
2. You will continue to update the risk reports and risk register if anything changes.
3. You will stop issuing risk reports and will maintain the risk register for the foreseeable future.
4. You will continue to update the risk reports and risk register at regular intervals and if
anything changes.
5. You will issue updates to the risk reports and risk register as risks are realized.
One of your team members, Jacques, is known for pulling off miracles. One of Jacques’ team
members said, “He could juggle chainsaws and come out without a scratch.” Right now, you
could really use a miracle. One of the risks you didn’t identify was that the customer would be
bought out in a merger and taken over by a company with a reputation for firing third-party
consultants. Your organization is a third-party consultant, and the new owners have called you in
for a meeting. Your contract has three more years to run, but the new owners may take it upon
themselves to make your life extremely difficult, causing your organization to lose money on the
deal. Jacques suggests that you let the meeting play out, promise nothing new, stick to the
original agreement, and then start working to the exact letter of the contract, rather than trying to
play nicely with the new owners. This is opposite to the way you normally engage with your
clients. You are fastidious in trying to give them a little “extra” to win their hearts. You never
thought you would be put in a position to shift your management style, but here you are. If you
decide to follow Jacques’ strategy, what are you doing?
1. You are minimizing the probability that the client will make life difficult.
2. You are minimizing the impact of the client making life difficult.
3. You are deploying a workaround to deal with the new environment.
4. You are accepting the risk that the client’s demands may eat into your budget.
5. You are deferring to the domain expert, as Jacques clearly has mergers and acquisitions
expertise.
Chapter 18
Sharing Risk Information
Risk Reporting
Information sharing is a cornerstone of project management and risk management. PMI® is

ardent about the notion that information should be shared openly and freely in a project
environment. Although this runs counter to many organizations’ perspectives that knowledge is
power, there should be no doubt that any aspect of risk management is an open book to those
responsible for dealing with its impacts and managing the responses.
At all levels of the organization (from the risk owner, to the sponsor, to the executive suite), risk
information is shared widely. As discussed in Chapter 17, “The Leftovers and the Latecomers,”
Johnson & Johnson set the tone for how risk information should be shared, and how that works
as an opportunity, rather than a threat.
It’s important to note, too, that risk information doesn’t always come with the heading of “Risk.”
Many project documents, from backlogs to schedules to team rosters to contracts, drive risks in
the project, because they reflect the uncertainty in the information they provide. Additionally,
although project risk documentation is one consideration, those managing the risks need to
consider how they will provide information regarding how their project risks potentially
influence the organization and how the organization’s risks potentially influence the project.
This chapter reviews the implications of reporting and sharing risk information.
#
Monitor and Close Task Provide Information Required to Update Relevant Project
Risks 3 Documents
Monitor and Close Task Monitor Project Risk Levels

Risks 4
Risk Reporting 1, 2
Related Document Updates 3, 4
Project-wide Risk Updates 5, 6
Organization-wide Risk Updates 7, 8

Caution
Your project swims in a sea of documentation. The project management office (PMO) demands a
monthly report on project activity, and the customer needs a biweekly briefing, supported by a
presentation. Your supervisor loves to get the “Friday report,” and your team needs a regular
email regarding progress on the project at the various sites where implementation is underway.
1. Every document reflects the risks on the project.

2. All the documentation should be sent out to all stakeholders to ensure a consistent perspective
on the project.
3. The priority of the documentation can be determined by its frequency.
4. Risk status is best reported in more frequent documentation.
5. Because documentation, particularly internal, is administrative, there’s no risk of it increasing
costs.
You need to aggregate your project risk data. The gathering and collation of the documentation
takes time, effort, and energy. You also need to update it. Relevant project documents that will
be affected by this aggregation include which two of the following?
1. Lessons learned and the risk register

2. The project management plan and the change logs
3. The corporate mission and vision statement
4. Organizational policies on ethics
5. Contract language
Your Agile project is running into problems. The customer doesn’t seem to understand that
although you are flexible, they have to pay for new work and new user stories. Early in the
project, someone told them that changes are “freely welcomed” in the adaptive environment.
They understood that to mean that “change is free.” To deal with the risk that they will continue
to think that way, you’ve created a booklet titled: Agile: Being Adaptive…at a Price. When you
send a copy to the customer and product owner, they both acknowledge the common sense
therein. The booklet is getting rave reviews in the Agile community and within your
organization. Given that it was created for your project, what should you do about the document
as the project moves forward?
1. Send a copy to everyone in the stakeholder environment for your project.

2. Provide it to the PMO, along with instructions on its use for greater success.
3. Keep it within your project and your team for similar situations in the future.
4. Make it required reading on all Agile contracts.
5. Capture the insights as lessons learned, for your team’s consumption only.
You have a project with six mandatory pieces of documentation. They are
The risk management plan

The schedule management plan
The communications management plan
The cost management plan
The contract
The stakeholder engagement plan
Every project needs to have those components, but only one of those components won’t require
an update as the project progresses and new risks are identified and responded to. Which
mandatory document doesn’t require an update as risks are realized and the project progresses?
1. The risk management plan

2. The contract
3. The cost management plan
4. The communications management plan
5. They would all require an update as risks are realized.
Your organization is under new leadership, and the new management seems far more risk prone
than earlier management. At a corporate all-hands meeting, the new CEO said, “Get out there
and make mistakes. Not the same old mistakes, but brave, new mistakes.” You want the new
management to know that you’re doing just that on your project. Although challenges are arising
and taking their occasional toll, the range of risk is narrowing, and your confidence in project
completion is rising. Management is visually oriented. What risk document(s) would serve best
in sharing the message you believe needs to be shared?
1. Risk reports from early in the project, compared with current project risk reports
2. Monte Carlo distribution graphs from early in the project, compared with current graphs
3. The risk register from early in the project, compared with the current risk register
4. Earned value data from early in the project, compared with current earned value data
5. A face-to-face meeting where you defend the current state of affairs on your project
Your project is in Columbus, Ohio, and the risk register seemed to be dominated by a single
word—SNOW. From roof cave-ins to stranded team members, the impacts seem to go on
without end. The first seasonal snow melt happened in early March. It’s now May and summer
holds the promises both of an end to the snow and the end of the project itself. As you look
across your risk register, many of the risks that were tied to the white, fluffy powder now seem
moot. What should you do as you update your project and its risks?
1. There’s no need for an update, because the risks have largely gone away.
2. You should delete the snow risks from your risk register.
3. You should reduce the probability of the snow risks within your risk register.
4. You should document the snow risks as “expired.”
5. You should reduce the impact of the snow risks within your risk register.
At the beginning of your project, you received a risk checklist from the project office. It’s
required that every project manager track and report on achieving all the preventive actions
dictated by the checklist when a project begins. Normally, that’s the end of the checklist. As you
near project completion, you pull out the checklist, even though it’s not a corporate requirement.
You realize that four of the items on the checklist have been completely overcome by events.
The shifting global culture has rendered those four checklist requirements moot, not just for you,
but for anyone. The project office doesn’t like to change their standard templates. If you bring up
the change, you may be saddled with implementing it and enforcing the update across the
organization. What should you do?
1. Report the situation to the project office and tell them you’ll make the updates for them.
2. Report the situation to the project office, and let them determine how they’ll act on it.
3. Make the changes to the checklist for your own use.
4. Make the changes to the checklist and turn it over to the project office for their consumption.
5. Take no action outside your project boundaries.
Your company is called “The Quarter.” All your projects are to build nationally and
internationally recognized monuments, buildings, and landmarks to one-quarter scale. After your
success with the Golden Gate Bridge reconstruction over Mirror Lake, you’ve now been working
on Stonehenge just outside Centreville, Virginia, to bring home the Druid experience for folks in
the States. Despite nearing completion, you’re afraid that the latest federal action related to
national parks and preservation might shut the project down cold. Most of your company’s
projects are located near other significant historical areas, which could create headaches
organization-wide. You have your hands full trying to finish the Stonehenge, which could lead to
the next big (or small) opportunity for you—building the Eiffel Tower in Regina, Saskatchewan.
You know you wouldn’t have the same federal oversight in Canada, so the tower project would
not have this concern. Nonetheless, your current project has implications across the organization.
What should you do next?
1. Update the risk management plan to reflect the concerns with federal intervention.
2. Notify the project office that this risk could jeopardize other projects in the pipeline.
3. Tell the team that the project is in jeopardy.
4. Meet with federal regulators to ask for assurances that the one-quarter-size Stonehenge will be
completed.
5. Remove the risk from the risk register.
Foundation Topics
Risk Reporting
This topic arises again and again in risk management, because reporting is done concurrent with
any project activity. Risk reports are developed:

When change occurs
Data gathering is challenging in the risk environment because many stakeholders are reticent to
share information about the potential negatives (overlooking the positives) associated with a
project. In any case, reporting is a critical responsibility for the risk manager, and the only way to
get to the reports is to gather the data.
There are a host of approaches to reporting risk, and as a result, there are a broad variety of data
sets that need to be gathered. With many projects, risk data are simple. The project efforts either
succeeded or they didn’t. For some reporting, the details drive the nature of data gathering, both
qualitative and quantitative. Also, the nature of the risk reporting varies between adaptive or
Agile project practices and those associated with more conventional, predictive models.
Qualitative Data Gathering and Reporting: Predictive
Much of the risk data accrued during the life of the project is qualitative. It’s anecdotal. It’s
relative to other risks or to organizational norms. First and foremost, such risk information needs
to be acknowledged for what it is. It needs to be recognized as qualitative, rather than
quantitative. The downside of qualitative information gathering is that the quality of the data
relies heavily on the data source. The data sources are often individual team members or risk
owners who will have different levels of skill at reporting risk status and what qualitative
information needs to be updated on the risk register.
The risk register (coupled with the risk management plan) is the normalizing tool in gathering
qualitative data. The risk management plan serves to provide the framework and lexicon for
qualitative terms. The risk register provides a format and home for the data.
In reporting the information, having already acknowledged it as qualitative, data interpretation

becomes easier when natural groupings of risk or when risk categories can be applied. Affinity
diagrams (discussed in Chapter 7, “Practical Team-Based Risk Identification”) are an ideal tool
to generate the natural groupings. If there are no preordained risk categories, a root cause
analysis (also discussed in Chapter 7) can sometimes provide a foundation for establishing risk
sources.
Qualitative Data Gathering and Reporting: Adaptive
In the adaptive environment, particularly Agile, qualitative data is normally reflected in

additional work (or less work) associated with implementing risk responses. A risk-adjusted
backlog should reflect the original backlog and the new user stories associated with response
work. That work will be assigned its own user story, rather than becoming a component of a risk
register. The level of effort for that work will be reflected in its story points (more story points
equals more effort) and ultimately add to the backlog. Initially, in the product backlog, it will be
up to the product owner to make the determination that the risk is sufficiently imminent to
warrant inclusion in the sprint backlog. As user stories are added to the backlogs (product or
sprint) they merit inclusion in any data-gathering and reporting effort.
Proof of concept thinking also plays in here. In adaptive environments, some risks are actually
invoked. They are intentionally brought to bear to see how severe they might be. Live testing a
new platform or approach may be done just to see whether the risks are more than the project can
or should bear (or to see whether there’s a way to reduce future uncertainty). These are called
risk-based spikes. Although it might seem counterintuitive to use a risk-based spike, it allows for
the project team to fail early and fail fast if the approach is high threat. In a risk-reward
consideration, this can also lead to opportunity because early successes (or any successes at all)
can result from risk-based spikes.
Quantitative Data Gathering and Reporting: Predictive
Some industries live and die by the numbers. Petrochemical corporations, for example, rely
heavily on Monte Carlo and other quantitative tools to determine whether it’s appropriate to
explore certain opportunities. In doing so, they use vast amounts of historic data for comparison
to make the risk decisions. In Monte Carlo analysis, they need to gather data on the range of
possibilities, the distribution of potential results within that range, and the number of simulations
that will be applied for evaluation. In traditional Monte Carlo, for example, the number of
simulations is partially determined by the need to establish a standard deviation across multiple
random samples of data. Because the samples are random, they may repeat within the simulation,
and more simulations might have to be conducted. If the project team is using the modified
Monte Carlo approach known as Latin Hypercube, fewer simulations are required because the
almost-random analysis does not allow for repeating simulations, as discussed in Chapter 12,
“Risk Quantification.” In other words, traditional Monte Carlo could produce results like A-B-A-
C-F-G-J-K-F, whereas a Latin Hypercube would produce A-B-C-F-G-J-K.
In any case, carpenters are only as good as their tools. The data gathered to support a quantitative
analysis needs to be inspected for data quality, consistency, and ongoing availability.
Quantitative Data Gathering and Reporting: Adaptive

In the adaptive environment, one of the classic tools for tracking accomplishment in the most
quantitative means available is the burndown chart. The traditional burndown chart shows the
number of user stories or story points remaining, graphed to illustrate forward progress on the
work. In the risk-oriented environment, this shifts to the risk burndown chart or risk-adjusted
burndown chart. Gathering the data for a burndown chart is as simple as reviewing the number
of remaining user stories or story points over time, as illustrated in Figure 18-1.
Figure 18-1 Traditional Agile Burndown Chart
For a risk-adjusted burndown chart, risk responses have been added to the product or sprint
backlogs as user stories. This means the additional work needs to be reflected in the burndown
chart, as illustrated by the crooked line in Figure 18-2.
Figure 18-2 Risk-Adjusted Agile Burndown Chart
The number of user stories (or story points) remaining is powerful quantitative data for
consistent reporting to the team and to management.
Not all documents that need to be updated for risk toward the end of a project have the word risk
in their title. As project risks are realized (or dodged), the management plans, lessons learned,
and change logs (to name but a few) all have to be brought in alignment with current realities.
Management Plan Updates
The project management plan is a collection of subsidiary management plans, including the risk
management plan, the cost management plan, the time management plan, the stakeholder
engagement plan, the procurement management plan, the quality management plan, the
communications management plan, the resource management plan, and the scope management
plan, as well as any other management plans selected by the project manager. They all share a
common theme in that they are management plans.
Management plans are often misconstrued as being plans for the work to be performed. Instead,
they are plans for how that work will be managed. As time passes and risks are adjusted, the
management approach can change as well. If the scope changes enough to take a project from
small to extra large, the means by which it will be managed will likely have to change. If the
organization goes through multiple reorganizations during the life of a project, both the risk
management plan and the resource management plan will likely change to reflect the new
culture.
Lessons Learned Updates
Lessons learned clearly need to be updated as new lessons are learned. The tragedy in many
organizations is that lessons learned often translate into, What did we do wrong, and how can we
survive if it happens again? The updates for lessons learned do not only reflect the threats
survived during the course of a project. They should also reflect the tricks of the trade discovered
since the last update.
Lessons learned updates can be both positive and negative, but the emphasis should be on the
opportunities generated by the discoveries made during the project life cycle. During the course
of these updates, the lessons learned should be documented not as simple axioms, but as detailed
instruction guides on how to make the lessons succeed.
Be nice to the customer and they’ll be nice to you is a poor lesson learned. It’s lacking any depth
of information. It provides no guidance on several critical elements. It doesn’t explain how to be
nice, which customer to be nice to, and how this rewards your organization when implemented.
During the course of lessons learned updates, all this information should be incorporated. Any
history of what drove to the lessons learned should also be incorporated. The simple Be nice
lesson learned might translate into a far more specific paragraph (or more) explanation:
The customer contract contact at Acme (Ted) prefers face-to-face meetings and considers
them the foundation of good relationships. To build better relationships with Ted, plan on
including regular face-to-face meetings as a component of your communications, because he
considers that a positive gesture. After two or three of these meetings, you can expect that Ted
will become more willing to negotiate interpretations of contract clauses and more prone to
share risks with you in the future.
Note that it takes more time and effort to update lessons learned with a complete data set. But the
information in such detail is actionable. It’s specific and clarifies how to gain the benefits of the
lesson.
Change Log Updates
Change logs go hand-in-glove with lessons learned in that change logs generate a history of the
project. This particular effort is very easy if the change log has been updated throughout the life
of the project and if the project change control process is rigorously enforced. Trying to update
the change log on an intermittent basis becomes a lesson in administrative tedium. If it’s being
updated on a real-time, ongoing basis, there’s little true work to be done at all.
In doing the updates, although the data gathering is dependent on the frequency with which it’s
conducted, the value of the information is not. As long as there is a log of all the changes that
have been made (planned or unplanned) and the changes that have been proposed and rejected,
there is a rich project history.
“How’s it going?” That’s a common enough question with thousands of potential replies. From a
project-wide risk perspective, the question is more of an examination of how the project has
gone, what risks remain, and what the probability of success is in meeting project objectives. The
answers on all three of those facets can be positive or negative, but each provides a different
viewpoint on critical project information.
How Has the Project Gone?
In conducting a project-wide risk update, this aspect covers the risks that have been realized
(issues) as well as the risks that never came to pass. In the post-mortem evaluation of projects
following the Year 2000 (Y2K) efforts of the software industry, many in the industry celebrated
the work they put in to avoid the Y2K bug. For those who don’t remember, most early software
programs, due to storage limitations, catalogued year data as XX, rather than 19XX. It saved two
characters in programs and databases, allowing more information to be stored. But as the year
2000 approached, there was a sudden realization that the two-digit years would wreak havoc in
programs where dates had to be presented sequentially.
Some analysts contend that the Y2K bug was overblown. The risk that computers would crash
because of faulty date sequencing never came to pass. Software practitioners, however, contend
that they actually mitigated that risk by coming up with new code and fixes to the existing code
to prevent the Y2K bug from becoming bigger than it actually did. Only a handful of people
believe that the risk never came to pass. Most concur that the work that was done in late 1999
mitigated the risk successfully.
This example answers the question, “How has the project gone?” Although there are different
opinions about whether the level of effort invested in Y2K was necessary, the ultimate answer to
this component of the question is one of the steps that were taken and the outcome to date.
What Risks Remain?
On any project, risks linger even after the project is terminated. Whether the project-wide review
is conducted at the very end of the project or at mid-project, this question goes to residual risks,
as well as the risks that cannot eventuate until the project nears completion. For any project,
there are remaining risks. The exposure that they create for the project is one type of residual
risk. Although the probabilities should be going lower toward the end of the project, the reality is
that the impacts can still be significant.
Project-wide risk updates should reflect the good news and the bad. The bad news is generally
that there are still ample risks nearing the end of the project, which is a time when project and
product owners are aligned in the thinking that the worst is all behind them. It’s sometimes
difficult to be the bearer of bad tidings during an era of good feeling.
In updating risks about the potential bad news, the core elements of risk need to be reinforced.
Although the impacts can be nigh-catastrophic, the drop in probability should be seen as a
positive. Risk updates also afford the opportunity to acknowledge (and potentially praise) the
risk owners for shepherding the risks through the process (whether or not the risks have been
realized). By giving these individuals their due, there is a higher likelihood that they will do their
jobs well through the remainder of the project.
As for good news, opportunities should not be overlooked as the project moves forward or winds
down. And those opportunities will not always be financial. Relationships that have been forged
in the crucible of the project should be highlighted as opportunities for future work.
Improvements in organizational image should be acknowledged as well. Process enhancements
represent another arena where the future may bode well for the project.
What’s the Likelihood of Success?
The overall likelihood of success ties to outcomes. In the classic project management sense,
that’s a look at time, cost, and requirements. The greatest of these is requirements. Although a
Monte Carlo analysis can provide a quantitative sense of the likelihood of time and cost
outcomes, coming up with the requirements’ projections can prove more daunting. In latter-day
risk reporting, this challenge should have been overcome through risk responses throughout the
project life cycle, and in the Agile environment, it happens organically.
The primary risk mitigation strategy for a lack of customer satisfaction leading to an
unsuccessful requirements outcome is intermittent reviews and approvals. These happen in Agile
at the end of every sprint with a demonstration and a retrospective (a.k.a., lessons learned). In the
conventional or waterfall approach, regular reviews accompanied by signatures serve much the
same function. The deliverables to date are reviewed, accepted, and documented.
If this happens on a ritual basis, the likelihood of success increases dramatically. That’s because
prior to the current risk report, there’s only one time period under review, rather than the entire
project. Although the focus here is on project-wide risk reporting, the reports were generated on
an interim basis, with only one new increment to add since the last was complete.
Moving up an entire echelon, organization-wide risks can be identified and addressed at multiple
levels:
Risks generated by the project that have a lasting organizational impact

Risks during the system life cycle
Risks to the project management culture
These are risks that by their nature have an impact well outside the project environs. These risks
need to be refreshed occasionally during the project life cycle, but actually have an impact that
continues outside the project.
Organizational Impact Risks
Organizational impact risks fall into two primary categories. Those are the risks that have a
lasting impact on the stakeholders and those that have a lasting risk on the organization’s
deliverables and quality. Although those two categories are inextricably wed, the long-term
impact on each is distinctly different. The personnel and stakeholder risks are largely rooted in
personal biases and feelings. The quality risks associated with the deliverables are largely rooted
in application and serviceability.
Personnel/Stakeholders Risk Updates
Personal attitudes and biases can turn very quickly. A single episode or a change in cultural
norms can make yesterday’s nonconcerning behaviors wholly unacceptable. A project that
appeals directly to one cultural group may make perfect sense in the existing social context. If
that cultural group falls out of favor (or into favor), the long-term perspective on the project can
alter how the organization itself is perceived.
Given the different stakes of differing stakeholder groups, it’s also important to consider whether
the project has favored watching the risks of one group over watching the risks of another. Such
slights might seem outside the province of project and risk management, but risk management
means managing the risks of the project to the entire body of stakeholders in an equitable
fashion.
Deliverables Organizational Risks (Quality)
“Made in Japan.” In the 1950s, that phrase was synonymous with poor quality. Thanks to the
efforts of W. Edwards Deming, it eventually came to mean a much higher level of quality. In the
long term, any project’s quality will reflect on the organization. Most of the risk associated with
quality is driven by the perception of quality. Without clear definitions of what constitutes a
quality outcome, the best efforts of an organization may be for naught.
To determine whether there is a risk to the organization and the perception of quality, success
criteria need to be established. When building the iconic Edsel, the Ford Motor Company
conducted more market surveys to determine what the car should include than on any other
vehicle prior. As a result, the Edsel was more feature-rich than previous vehicles. It was also
more expensive. Today, the Edsel is an exemplar of what a product disaster can be. It was not
because the vehicle didn’t successfully deliver all the features the customers wanted. It was
because the vehicle was not in its customers’ price range. Price was one of the quality criteria
that Edsel’s developers overlooked. And three-quarters of a century later, the term Edsel remains
an albatross around Ford’s neck.
As risk and project managers, delivering the outcome as requested is one thing. Looking into the
future to determine how this will impact the organization going forward is another. When
assessing latter-day risks, the question of how the outcome will reflect on the organization is a
vital one. This ties directly into the long-term system life cycle.
System Life Cycle Risk Updates
A project to create an extensive case study for a major telecommunications corporation was on a
very short timeline. The project manager was told, “Don’t worry about whether or not it’s good.
Just meet the deadline. It will only be used a few times, and then we’ll do something thorough.”
He got it done. The case study went into use in 1993. By 2011, the project manager had changed
careers, moved on to create his own company, and was happily engaged in other activities. In
2011, he received a phone call:
“I’m so glad I found you. Did you write this case study for the big telecom a few years back?”
He replied in the affirmative. “This is a piece of crap! I can’t believe they let you get away with
writing this. No one likes this case study.”
The case study’s author had no idea that they would be using the case study for 18 years. It was
written to meet a short-term deadline and to be used a couple of times.
In updating organizational risk, the project manager/risk manager needs to take the time not only
to ask how the project might be used, but also how its outcomes might be misused. Many
projects are designed to serve short-term needs. The project manager should support their
organization by informing those using the outcomes from the project that there’s a planned life
cycle for the deliverables, and exceeding that life cycle may have risk consequences. The
opportunity is that the deliverable may be usable well beyond its intended time frame. The threat
is that the deliverable might not serve well or might do harm if used for far too long.
This case of unanticipated overuse is just one type of threat that can hit a project late in the
project life cycle, feeding into the ongoing system life cycle. The other major threat in the
longer-term system life cycle is associated with organic change in the environment, the
technology, and the organization itself.
Unanticipated Overuse
Beyond the example of the communications’ organization case study, many projects suffer from
unanticipated overuse. A software program expected to be used locally can shift to a global
application. A database expected to manage 10,000 records might be put to use managing
millions.
Because many of these usage alterations occur after the project has transitioned to new owners,
the project manager and risk manager will likely have no direct influence over the risks created
and their management. However, both managers have the opportunity to create alarms and alerts
prior to transition. Part of their management role is to make sure that future generations will
understand the perils of using the project outcome beyond its intended application.
The case study author would have been prudent to include notations that “this case study is
temporary and intended for use only through 1994.” It would have alerted future users that the
case was past its prime and would not have the same applicability after that date. On virtually
any project, creating a review date or termination date for the outcome affords the project
manager (and the organization) some protection against the risk of providing products and
services that are obsolete. Software companies do this regularly with version expiration.
Microsoft no longer supports Windows 7 and earlier versions. Their risk associated with that
software expired in January of 2020. For more recent versions, the out-of-support status end
dates are already determined, in an act of post-project organizational risk management.
Environmental/Technical/Organizational Change
As projects near completion or are completed, environments change. This can include the
physical or cultural environment, the technical environment, or the organizational environment.
Like the challenges with overuse, the project manager is wise to capture and catalog the nature of
the environment in which the project outcome will be applied and what it’s not expected to
withstand.
Environmental Change
Pharmaceuticals have very specific storage protocols. Insulin packages, for example, state that
they should be stored in refrigeration between 36°F and 46°F until used. Once opened, the
temperatures should not exceed 86°F. A prudent risk manager includes such information on
every package of insulin to ensure that long after the project to create the insulin delivery system
is complete, end users will still understand the environment in which the product was to be
stored for use.
In parts of the world with modern refrigeration, such boundaries seem completely reasonable. In
equatorial regions with limited or erratic electrical power, such boundaries might be almost
insurmountable. Dictating requisite environmental conditions before the project is complete is
essential to project efficacy.
Technical Change
Most readers of this text will not be able to recall their first use of a 386 computer. These were
computers in 1985 using an Intel i386 chip. In running an extensive Monte Carlo analysis on a
386, the computer power required taxed such systems to their limits. A project Monte Carlo of
several dozen tasks might take as much as a full 24 hours to compute (by way of reference, a
similar analysis today would take seconds). If a project manager delivered a system today that
took 24 hours to compile such a simple set of data, the project would be considered a long-term
laughingstock. Project managers and risk managers, as with environmental change, need to be
prescient, identifying the conditions required to survive technical changes (or to overcome
technical challenges associated with clients with outdated systems).
Organizational Change
Who’s the boss? In Chapter 3, “Tolerance, Thresholds, and Triggers,” we noted that different
stakeholders have different tolerances. This applies both during the project life cycle and after
the project is concluded during the system life cycle. Just because the project outcome has been
delivered, it doesn’t mean that risks don’t remain associated with the outcome. And those risks
will be perceived differently by different stakeholders.
This can be managed by clearly identifying the stakeholder tolerances in place at the time of
project delivery. There will be no way to stop new stakeholders from having different tolerances,
but they need to understand the organizational changes were not in place when the project
outcomes were delivered. Much as insulin can’t remain viable above 86°F, a project created for a
manager who tolerated certain software glitches won’t satisfy a manager with far more rigorous
quality aspirations. The key for the project/risk manager is early identification of the tolerances,
documented in the risk management plan. As those tolerances shift, the risks on the project will
shift. And as those tolerances shift, the risks to the organization shift as well.
Updated Risks to the Project Management Culture
The project management culture is dictated by the organization, the PMO, and the individual
managers responsible for their projects. During the course of a project, these risks might shift,
primarily due to three causes. Those causes are the propensity for some individuals to “get away
with” certain behaviors, the misapplication of risk processes (particularly by the PMO), and the
changes in tolerances as mentioned in the previous paragraph.
Cultural “Get Away with It” Risk Updates
In many projects, administrative responsibilities are seen as non-value-add activities that should
be managed by others. In some instances, individuals will simply drop such responsibilities,
believing that they are wasteful. If these practices are not enforced, over time, the practices might
be at risk of not happening at all. In updating risks to the project, the organization, and the long-
term outcome, these are the types of risks that can easily be overlooked or forgotten.
The obvious means to deal with such risks is through enforcement. Risk managers and the PMO
should enforce the policies and practices that have been included in the project environment,
because such policies in and of themselves are normally mitigating threats or enhancing
opportunities. Even if such enforcement is in place, identifying these risks afresh near the end of
a project or during project transition to its ultimate owner reinforces best practice management.
If a new law enforcement officer rigorously pursues violators of a 45-mile-an-hour speed limit
on a particular stretch of road, scofflaws will quickly learn to adhere to the rules, despite their
belief that such enforcement shouldn’t matter.
Misapplication Risk Updates
Risk processes should be consistent. The rules laid out in the risk management plan and by the
project office are meant to protect organizations against ad hoc application of risk processes. In
some cases, project managers or the project office will take it upon themselves to modify
processes. They might change the structure of risk statements, alter the risk register templates, or
redefine organizational tolerances. Any of these changes generate new risk events. Worse still,
any of these changes might invalidate earlier risk efforts by virtue of losing the earlier process to
history. To minimize the misapplication of risk processes, transparency is key.
Anytime a risk process is modified without going through formal processes, the project/risk
manager needs to document the modification, find the source of the modification, and determine
whether it is valid. If it is not, the project manager becomes responsible for retracing the
project’s steps and reapplying the original processes as they were intended. If such an effort is
purely administrative and doesn’t change any of the project’s outcomes, the changes should be
duly noted, and the date on which the project returned to the original approach should be
captured.
Tolerance Updates
Tolerances change. They change on a project. They change with different stakeholders. They
change as new narratives become normal within public discourse. In the 1940s and 1950s,
anyone with an LGBTQ+ orientation would have been considered outside tolerance for new
hires or contract personnel. The tolerance has shifted radically over the past 60 years, and these
individuals are now considered based on their professional merits, rather than their orientation.
Prior to 9/11, risk tolerance for individuals boarding planes was limited to eliminating firearms
and large knives. Tolerances changed with the terror attacks of 2001, leading to a need for
tolerance updates. Those updates are reflected in the implementation of the Transportation Safety
Administration (TSA) in the United States, with no tolerance for a much longer list of items.
Because the TSA discovered the potential threat of liquid explosives, the tolerances have
changed yet again.
The tolerances can change at a variety of levels, including the project, the organization, and the
culture. As these are updated, the project and risk managers need to reflect those updates.
Risk cultures change as individuals, teams, organizations, technology, and attitudes change. As
those cultures change, so do the tolerances. So does risk itself also change.

found.

Element Number
Paragraphs Data gathering needs to be conducted in both qualitative and 329

quantitative approaches to ensure all the latter-day risks are
identified and fully reviewed. Those review approaches differ in
the predictive and adaptive environments.
Section Quantitative Data Gathering and Reporting: Predictive 330
Section Quantitative Data Gathering and Reporting: Adaptive 331

Paragraph As a project moves forward, multiple documents need to be 332
updated. Noteworthy among these are the management plans,
lessons learned, and change log.
Section Project-wide Risk Updates 334
Paragraph At the organizational level, updates are required regarding how 336
the project has created risks that have a lasting organizational
impact, risks that might become evident during the system life
cycle, and risks that might influence the project management
culture itself.
Section System Life Cycle Risk Updates 337
Section Updated Risks to the Project Management Culture 340
risk-based spike
Monte Carlo
Latin Hypercube
risk burndown chart
risk-adjusted burndown chart
change logs
project-wide risk
organization-wide risk
system life cycle
Review Questions
You don’t have time for a lot of administrative challenges, and you’ve just been told that your
risk reports should be submitted per PMI® and other guidance. In terms of frequency, you see
that you may be reporting on risk more often than you have in the past. As you conduct research
into what’s practical and reasonable, you begin to understand that there are some clear rules as to
when risk reports should be developed. What’s the timing for your risk reports going forward?
1. A weekly basis
2. A monthly basis
3. When change is planned and at regular intervals
4. When change occurs, change is planned, and at regular intervals
5. As prescribed in the communications management plan
You need to gather a lot of qualitative data, using the terms “high, medium, low.” Where are the
definitions of those terms and where will the gathered data be housed?
1. The data terms will be defined in the risk management plan, and the gathered data will be
housed in the risk register.
2. The data terms will be defined, and the data will be stored in the risk management plan.
3. The data terms will be defined, and the data will be stored in the risk register.
4. The data terms will be defined, and the data will be stored in the risk repository.
5. The data terms will be defined, and the data will be stored by the project management office.
You need to conduct a quantitative analysis of your project, which encompasses thousands of
tasks being conducted globally. You realize that you are going to push the capabilities of your
quantitative tools to the limits and, given the technical capacity of your systems, are surprised to
learn that it could take hours or even days to compile the final results of the analysis. You need
to ensure you have a sense of the range of risk for any project-wide examination. The best
approach for this analysis is what?
1. Latin Hypercube
3. Monte Carlo
4. Monaco Straight
5. Risk registration
Your Agile project is going well, but you are concerned about the potential for a setback that
could happen if you change the size of one critical data element you planned to capture.
Everyone tells you it will be fine, but you’re still nervous about the potential impact of the
change. What is the best approach to deal with this and provide affirmation that, indeed,
everything will be fine?
1. Create a risk-adjusted burndown chart.

2. Conduct a Monte Carlo analysis.
3. Don’t change the data element.
4. Perform a risk-based spike.
5. Create a resource assignment matrix.
Which of the following statements best describes a risk-adjusted burndown chart?
1. In an adaptive environment, it’s a chart that reflects the timing of user story completion.
2. In a predictive environment, it’s a chart that reflects the timing of user story completion.
3. In an adaptive environment, it’s a chart that reflects the timing of user story completion,
including the user stories associated with risk responses.
including the adjustments made to user stories to account for the range of risk.
including the adjustments made to user stories to account for the backlog.
Which of the following statements is true when a project has been formally closed out?
1. The risks associated with the project have all expired.

2. The risks to the project have expired, but the risks to the organization may continue.
3. The risks to the organization have expired, but the risks to the project may continue.
4. All the risks that remain are secondary.
5. The project risk owners continue to own the risks going forward.
Which of the following is the best lesson learned associated with the risk that unclear
requirements may lead to poorly executed deliverables?
1. Pay attention to the requirements throughout the project life cycle.

2. Pay attention to the requirements throughout the project life cycle, and you will reap rewards
associated with a better understanding of the requirements and a better ability to express those
requirements to your project team members.
3. The best way to focus on requirements is through a requirements traceability matrix, often
available from the PMO website under “tools and templates.” Followed per the guidance with
the document, it’s hard to miss specific requirements or fail to interpret them.
4. The best way to focus on requirements is through a requirements traceability matrix, which, if
applied properly, helps you to capture all requirements on the project as well as their
interpretation. This tool has been used on 33 projects, and on each, the team members agreed
that it was helpful.
5. The best way to focus on requirements is through a requirements traceability matrix.
Part VI
Final Preparation
Chapter 19
Final Preparation
The first 18 chapters of this book cover the technologies, protocols, design concepts, and
considerations required for your preparation in passing the PMI Risk Management Professional
(PMI-RMP)® certification exam. This chapter covers the information that is necessary to pass
the exam. However, most people need more preparation than simply reading the first 18 chapters
of this book. This chapter, along with the Introduction of the book, suggests activities and a
study plan to help you complete your preparation for the exam.
Suggested Plan for Final Review and Study
This section lists a suggested study plan from the point at which you finish reading this book
through Chapter 18 until you take the PMI-RMP® certification exam. You can ignore this four-
step plan, use it as is, or modify it to better meet your needs:
Review key topics: You can use the table at the end of each chapter that lists the key topics in
each chapter or just flip the pages looking for key topics.
Review testable content: PMI maintains a list of testable content known as the PMI Risk
Management Professional (PMI-RMP)® Examination Content Outline and Specifications.
Review it and make sure you are familiar with every item that is listed. You can download a
copy at https://www.pmi.org/certifications/risk-management-rmp.
Study “Review Questions” sections: Go through the review questions at the end of each
chapter to identify areas in which you need more study.
Use the Pearson Test Prep software to practice: The Pearson Test Prep software provides a
bank of unique exam-realistic questions available only with this book.
The Introduction of this book contains detailed instructions on how to access the Pearson Test
Prep Software. This database of questions was created specifically for this book and is available
to you either online or as an offline Windows application. As covered in the Introduction, you
can choose to take the exams in one of three modes: Study Mode, Practice Exam Mode, or Flash
Card Mode.
Summary
The tools and suggestions listed in this chapter have been designed with one goal in mind: to
help you develop the skills required to pass the PMI-RMP® certification exam and gain the skills
needed to start your career as a Risk Management Professional. This book has been developed
from the beginning both to present you with a collection of facts and to help you learn how to
apply those facts. Regardless of your experience level before reading this book, it is our hope
that the broad range of preparation tools, and even the structure of the book, will help you pass
the exam with ease. I wish you success in your exam and hope that our paths cross again as you
continue to grow in your career.
Appendix A
Answers to the “Do I Know This Already?” Quizzes and Review Questions
Chapter 1
B. Risks will not yet have been identified, but the documentation structures that will house them
should already be in place. It’s one of the first actions of the risk manager.
C. Although the information the project manager generates will become crucial to building the
risk register, if the project manager has taken on the role of risk librarian, they must share that
information openly and freely with all the relevant stakeholders.
B. Organizational mission and vision statements are normally not project-specific and thus don’t
play into the document base for project risk identification. The other data cited here are crucial to
effective risk identification. On the exam, be aware that contracts and memoranda of
understanding represent customer agreements.
D. Although the customer plays a critical role in the risk process, they are not the appropriate
party to conduct a comprehensive documentation review. Their inherent bias (toward their own
interests) may prompt some concerns to be overlooked and others to be overemphasized.
C. The application of lessons learned from previous projects is a foundational element of

knowledge transfer. Without a review of lessons learned documentation, critical historical
information can be overlooked. Even though the project is novel, the interplay of people and
processes can reflect similarities with past efforts.
D. The risk owner doesn’t necessarily develop the risk response but is responsible for tracking
the risk and the implementation of any response. The risk owner also provides intermittent
reviews of the success of the risk responses for the risks to which the risk owner is assigned.
Review Questions
D. This is a risk that should be retired. Although other businesses may go out of business, Acme
is specifically called out in this risk statement. Because they are no longer even a potential
consideration, the risk should be retired.
E. The risk register explicitly describes the risk event, its probability and impact, as well as a
volume of other information to support management of the risk. The other documents here have
other purposes.
B. The risk register specifically looks at the current project’s individual risks and the background
information on their probability, impact, ownership, and response.
B. The project sponsor is the individual authorized to grant approvals to proceed on a project.
Without their signature (preferably pen and ink), the project charter might not serve the goal of
being the authorizing document for the project.
B. Tracking, implementing, and reporting are the roles of the risk owner. Although all these are
true statements, Bobbie’s primary job is to do as answer b suggests.
Chapter 2
A. The appetite directly reflects the tolerances (limits) of an organization. Although the 15%
mark represents a tolerance, the individual risks that drive us to that point are those that clarify
the organizational appetite. Attitude goes to the drivers that cause us to behave in a particular
fashion.
B. PMI® is adamant that the project manager/risk manager be as completely open as possible
about any risk. As a future phenomenon, it’s important to understand that the problem has not yet
occurred on this project, and this affords the organization an opportunity to get in front of it
before it becomes an issue.
C. Despite the fact that the organization has a waterfall history, the risk perspective on this
question is one that pushes us in the direction of agile. A hybrid methodology might be tempting,
but there are no indicators that there is any risk reduction that will occur as a result of trying to
blend the application of strict waterfall and traditional agile. Words such as “completely
innovative” and “no protocols” should be indicative of the need to approach the problem from an
agile perspective.
D. Note that this goes to a point on the PMI-RMP® exam. You will look for the best answer
rather than the perfect answer. A perfect answer to this question would have been one that
pointed to strengths and weaknesses as external to the project, while opportunities and threats are
internal to the project. In any case, the best of the four answers is D, where we explore what the
organization does well and poorly, and how the project might offer opportunity to offset our
weaknesses, as well as how the project’s threats might be counterbalanced by the organization’s
strengths.
A. The creation of business cases normally rests with the business analysts, rather than a
management tier. The background data is not likely to reside in the accounting office, or with
your direct superior. As for the “risk officer,” that’s a title that exists in very few organizations
and would not likely be a sound resource for the benefits realization plan.
D. Success doesn’t equate to risk management maturity. Maturity is achieved when an

organization is able to document and repeat the processes necessary to keep project risk within
the framework of a consistent set of practices and within organizational appetites.
B. The deadline is a classic project constraint. Something as unpredictable as the weather is

almost always based on an assumption set.
Review Questions
A. This is about Ahmed’s attitude. Attitude is a personal perspective and not what an
organization will withstand.
D. High information-sharing and retention are the hallmarks of a mature organization.
A. The selection of the Ohio vendors was done based on what you believed to be true for
planning purposes. That’s the nature of an assumption. (In this case, the assumption was
invalidated.)
A. Power reflects position in the project organization, and the project sponsor is the classic
example of high power. Interest reflects the level of engagement for the parties in question.
C. Organizational infrastructure represents the climate in which a project will evolve. In this
instance, many of the keys of organizational infrastructure are creating risks, including
communication, facilities, hardware, and capacity.
B. A tolerance is the point beyond which a project or endeavor cannot or will not proceed.
Chapter 3
A. Risk absorption is, as the term implies, the level or degree of risk that can be absorbed by an
entity. In this case, the entity is the organization, rather than a single project. Absorption can
apply at a variety of levels and reflects the organization’s (or its stakeholders’) risk appetites.
B. From the root word tolerate, tolerances are the limits of acceptable versus unacceptable risk
conditions. Although they may trigger changes in organizational behavior, tolerances are not the
same as triggers, which flag the tolerances as being near or exceeded.
B. The bells and lights are physical manifestations that a threshold is being breached and a
tolerance is imminent. The organization in this situation cannot tolerate a car being struck by a
train. The threshold (the point at which behaviors change) is 3,000 feet.
D. Note that this goes to a point about exam questions. Because each answer includes the phrase
“after thoughtful evaluation,” that element of the response is moot. And although C and D are
both true statements, the question asks who believes the organization is taking too many risks.
B. Although arguments can be made for C and D, the best available answer is B. Management
has indicated when escalation should occur, not a point beyond which the project may not
continue. Organizationally, $49,000 USD may be a small value, but for this project, it’s the
impact that the project can withstand without management attention.
A. Team and meeting ground rules (found in the team charter) apply in all project settings,
including risk reviews. By establishing consistent protocols for handling such conflict prior to
the conflict surfacing, expectations can be set and parties can understand how and why you are
responding in the manner in which you choose to respond.
Review Questions
B. Confrontation is also known as problem solving, and is the ideal solution for most conflict. It
is a situation where both sides in a conflict work together to derive a viable solution.
C. The tolerance is the point beyond which a project (or a car) cannot proceed. The threshold is a
point at which behaviors should change and tolerances are imminent. A trigger is a warning that
a threshold has been breached and a tolerance is imminent.
A. This goes to a basic understanding of absorption. An individual or organization can handle or

manage risk only to a point.
A. The driver behind the termination policy is organizational. The application of the termination
protocol is not specific to your project or the risks therein.
D. This is what team charters are designed to accomplish. They create a consistent, cohesive
approach to behavioral norms.
Chapter 4

A. Although documenting the links may capture some aspects of the risk process, the reality is
that everyone who is a party to the process should understand what the organization’s vision is.
B. In selecting tools for a risk process, the tools need to integrate with the organization’s (and
project organization’s) risk tolerances. Whereas some tools work very well in addressing time
and cost (the largely quantitative elements), others can account for qualitative considerations,
such as image.
C. Repeating the same structures and formats creates an opportunity for one-to-one comparisons
of what’s happened in the current project in comparison to others (both current and past). While
familiarity is an advantage, the primary benefit is consistency.
D. Although we might want certain answers, the goal is not to get what we want, but what we
need. What any tool should generate (anywhere in project management) is outcomes of value to
the organization while functioning within the organization’s culture.
A. The RBS is designed to break down risk by its sources, so that risks may be evaluated and
responded to either from an individual or categorical perspective.
D. Every risk has at least one source. Some risks have multiple sources. The nature of causality
is that risks with multiple sources tend to have a higher likelihood of occurrence.
D. Servant leadership involves taking tedious, less mission-critical tasks on so that team
members can perform what they see as more value-added duties.
D. Inasmuch as your project risk management strategy should be aligned with the enterprise
strategy, and your boss asked that you speak about your strategic project risk perspective, you
need to draw in as many stakeholders as possible to adopt your risk management strategy.
Review Questions
B. This is a classic example of servant leadership. Servant leaders believe that through their
support, the entire project (and sometimes the entire organization) will be encouraged to more
actively participate in the process.
C. Although it can be argued that the process is project dependent, the reality is that virtually
every risk resource (while using different names) follows the same set of steps, beginning with a
clear understanding of the language and lexicon, then moving into the identification and
evaluation of individual risks.
A. PESTLE stands for political, economic, social, technological, legal, and environmental risks.
These are considered risk sources and allow for effective risk categorization.
D. The risk management plan does not serve as a repository for risks. It is the document that
guides project and/or risk managers on how to manage risks. A component of that is the need for
a common risk lexicon. Thus, definitions of terms are housed here.
D. Risk response development can include a variety of responses, ranging from basic acceptance
up to mitigation and escalation.
E. The RBS is a breakdown of risks according to their sources.
Chapter 5
A. Again, the risk management plan is a document that supports process, rather than specific
risks. People need to know their roles within that process and the degree of participation that’s
expected.
B. Accountability goes to the understanding of who will be held liable for the process (and
ultimately accept blame for any shortcomings). The responsible individuals are those performing
the process, and in many organizations a single individual may have responsibility for a variety
of processes.
C. Repeating the same structures and formats creates an opportunity for one-to-one comparisons
of what’s happened in the current project in comparison to others (both current and past).
Although familiarity is an advantage, the primary benefit is consistency.
D. Risk management plans do not conduct the processes. RMPs detail how the processes will be
conducted. The RMP is a skeleton without any flesh on the bones. That flesh develops as the
other steps in the risk management process are conducted.
A. The RMP does not go down to a granular individual risk level. It does, however, draw on
information from other projects and the organization to ensure consistency. One means of
achieving that consistency is by reflecting structures (like RBS sources) that are used to build
detailed risk plans across the enterprise.
D. Although Human Resources generally oversees organizational training, responsibility for risk
training falls to the project manager. They need to serve as a subject matter expert for such
training and have an intimate understanding of the implications of the risk management plan as it
will progress through the project life cycle.
E. Rewriting dictionaries doesn’t solve language differences. Training and education can.
Review Questions
D. This is a classic description of where risks are identified when applying the Scrum method.
The brief, 15-minute meetings allow all team members to engage and to answer the question of
“What’s standing in your way?” on a daily basis.
E. The application of the RACI is explicit. Although you may have multiple parties responsible,
consulted, or informed, only one person can have accountability. There is no such thing as shared
accountability.
B. Risk sources allow for effective risk categorization. An RBS creates a framework for those
categories and may be unique to a project or may represent an organizational standard.
C. The distinction among these three terms is that data are inherently unbiased because the data
points have not been interpreted, filtered, or modified by any party. As soon as data are filtered
or categorized, they become information, which has a degree of bias. Reports present processed
information and have the highest degree of potential bias.
A. Whereas risk registers house a wealth of risk information, the best communication occurs in a
face-to-face environment. Virtual meetings have many of the qualities of a face-to-face setting,
but still don’t capture all the paralinguals that are evident when people are in each other’s
presence.
E. “What’s standing in your way?” provides an indicator of risk sources for a given individual
and their work.
Chapter 6
A. Although the description of cooperation and teamwork sounds like a performing team, the
reality is that the levels of performance can be high even in the nascent days of team cooperation.
Because the team has been together for only a week, they are most likely still in the forming
stage.
B. The customer understands the environment in which the project will be deployed. Although
team members have the best information on risks within their respective tasks, and the end users
have the best information on risks in application, the customer has the broad environmental
understanding.
C. Risk information needs to be shared consistently, particularly as it applies to culture and

compliance. There are no one-off situations where compliance can be circumvented or where
organizational approaches can be usurped.
D. Technology should not shift every time a new team member with different needs joins the
group. The existing approaches should have been documented in the ground rules and rules of
engagement, and they shouldn’t be changed unless there’s a teamwide need.
A. As many advertisers will attest, repetition of a message is key to inculcating it in the culture.
It works most effectively when the messages are consistent, direct, and supported from multiple
perspectives or examples.
D. If a risk team seeks synchronicity with the project team, the perfect start is by referencing the
team charter, which is designed to establish protocols for behavior, meetings, and professional
conduct on a project.
Review Questions
D. Although the nominal group technique might serve this purpose, NGT is generally used with
any group of people rather than strictly experts. One of the classic definitions of the Delphi
technique is that it is designed to achieve the consensus of experts.
D. Teams where members are occasionally confrontational about their roles and responsibilities
are in the storming stage. When members are willing to give and receive feedback in a helpful
spirit, the team is in the performing stage. When team members work independently and know
their own roles and responsibilities but don’t share or receive constructive criticism, they are in
the norming phase.
B and E. Brainstorms gather noncritiqued data without prioritization. Brainstorms favor

extroverts who draw energy from a group setting, while more reticent members of the team may
be overlooked.
A. As tempting as it may be to abandon the plan for the current meeting, meetings are scheduled,
orchestrated events with specific objectives. There’s no indication here that the newly identified
risk will more directly achieve the objective. The topic should be documented for inclusion in the
next agenda.
A. Telling the customer that the concern has been addressed does nothing to violate the
nondisclosure agreements. Anything beyond that point, however, begins to leak corporate policy
information, which would violate the NDA.
®
A. Escalation, in PMI®’s perspective, is total. When a risk is escalated, it is owned by the new
recipient. In this case, if she determines that she wants to have you manage the risk, A remains
the operative answer.
Chapter 7
A. The risk breakdown structure provides information on the sources of risk, not the risks
themselves. Reports differ from data in that reports are processed and contain an inherent level of
bias. The risk register is data, in that it is largely unprocessed and thus eliminates most of the
bias. It is the single most data-rich document in risk management.
B. The nominal group technique allows everyone to participate on paper without necessarily
airing all the risks identified for public consumption.
B. One of the best practices of risk identification is leveraging past projects and the insights
gathered from them. A thorough document review of past projects would be considered a
powerful means to identify risks on a similar effort.
D. Issues are threat risks realized. When a risk converts to an issue, it is no longer under
consideration. Although the nature of the other columns could vary, issues are already occurring
and therefore are not germane in a risk discussion (unless they have created potential future
risks).
A. Even if the results are inconclusive, the data might have value. If there are issues with team
driving behavior, they are issues rather than risks.
D. Closed-ended questions generate binary responses. Interviews are best conducted using open-
ended questions to get a deeper, more thoughtful response.
Review Questions
D. Although affinity diagramming may serve the visual needs of the team, it doesn’t necessarily
generate a higher volume of outputs. Mind mapping is brainstorming supported by the
connections among risks, visually displayed by those links.
D. The essence of Ishikawa diagrams is root causes. The diagrams, courtesy of the five whys,
produce a list of risk causes that may overlap. The higher the level of overlap with particular
causes, the greater the likelihood that you have discovered root causes.
B and E. Checklists reflect history. That’s where they come from. They reflect past project
experience but can never cover all risks for an organization. They are normally archived,
updated, and shared through the PMO, as the organizational repository for forms, tools, and
templates.
A. No one can ever identify all risks on a project. During risk identification, there’s not yet
enough information to determine which risks are minor and which are major. Similarly, it’s far
too early in the process to know whether the risks will impact this particular project. Very few
risks can be identified as exclusive or specific to a single project.
B. Sometimes a single response may ease the pressures created by multiple risks. It’s not enough
to log the response with just a single risk event. It needs to be placed in the risk register with all
the germane risks.
B. The five whys draw out sufficient causes to generate root causes. In an Ishikawa diagram,
those causes that overlap become evident and can be identified as potential root causes.
Chapter 8
A. Because you currently don’t know for sure that Lawanda will be assigned to your project, her
presence is an assumption. Because the work could be done with other talent, and her presence is
not contractually driven, it’s not a constraint.
B. A contract breach is a breach where the contract is violated, but the deliverables may still
reasonably be used for the purposes originally intended. Were the pumpkins delivered on
November 2, it would be a clear material breach.
B. Working out of Youngstown has become a constraint on the project. It’s not a belief; it’s a
mandate. Although the risks that it drives might be known or unknown, the actual fiat from
management that you work there makes it a constraint.
D. Unknown-unknown risks are those where the risk has never surfaced before within an
organization and where the probability and impact are also hitherto unidentified.
B. Known-unknowns are those risks that are generated when the uncertainty in a situation is
high, but the nature of any risks in that uncertain environment is completely unknown.
D. When a standing belief is restated as a future phenomenon that might or might not occur, it is
the moment at which assumptions convert to risks.
Review Questions
D. Risks that have never befallen an organization and could not reasonably be anticipated are the
classic unknown-unknowns. Such risks are not considered part of the project work and project
plan and thus are financed or rescheduled applying management reserves.
D. The known-unknown risks are those where the nature of the risk event remains completely
unknown, but the fact that the risks will manifest themselves during the life of the project is
keenly felt.
C. In an ideal world, all team members will participate in both assumption identification and
assumptions analysis. Although internal team members and critical stakeholders might be more
prone to share, the ideal is to gather information from all the stakeholders available.
C. Constraints represent the boundaries of a project from the contract, the agreements, or the
memoranda of understanding. Those boundaries often serve as the precursor to project
tolerances, which are the points beyond which a project cannot go. Note that the answer that
includes the word all is an absolute. Absolutes are rarely the right answer on the exam.
B. The threshold is the point at which an organization will change behavior on a project, whereas
a tolerance is a point beyond which a project cannot go.
B. It’s a constraint. Its location in the contract documentation is immaterial. If the terms of the
contract say a certain status must exist, then it’s a constraint.
Chapter 9
A. Many compliance risks are binary in nature. The project either complies or it does not. No
gray area exists in risks of this type.
A. Projects in different environments must comply with different rules. Those rules might be set
by any one or more of a variety of entities, ranging from the industry to government to the
organization conducting the project.
B. Ten is a tolerance. Go there, and the contract/project is in jeopardy. Seven is a threshold. It’s a
point at which behavior can still change to preclude hitting the tolerance.
B. A trigger is a warning sign that a threshold has been breached, and a tolerance is imminent.
The tolerance in this scenario (as noted by the manufacturer) is 9 or 10. The threshold is
somewhere before that point (and may well rely on the driver, rather than the owner’s manual).
Although C and D are possible answers, the best answer is B.
B. When a threshold has been met or exceeded, triggers alert us to that condition.
D. Triggers are the warning signs that a threshold has been breached (or is about to be breached),
and a tolerance is imminent. In this instance, the trigger is driven exclusively by Kristi’s concern.
It’s driven by a stakeholder.
Review Questions
D. From a compliance perspective, this talented team member has no business being involved in
this project. Clearance, as a compliance issue, is binary. You either have it or you don’t. And if
the contract requires that all personnel be cleared, having the team member anywhere near the
project would be an act of noncompliance.
D. The management has already let you know that €4,400,000 is a point beyond which they will
not go. The trigger is a call from accounting that the threshold of €3,500,000 has been reached.
B. The tolerance is breached when the incident actually occurs. In this instance, there’s still time
before that moment is reached. Because this was dictated by an individual and not a compliance
(contract, government, regulatory, memorandum of understanding) situation, the threshold
belongs to a stakeholder.
A. The gates could also be argued to be a visible trigger, but their real value is physical. They
constrain anyone from crossing the threshold by a physical presence, blocking the drivers’ paths.
“Visible” triggers are (as they sound like) triggers that can be sensed by sight. Although the
visible and physical sometimes both apply, they are not the same thing.
Chapter 10
A. As much as many organizations worry about sharing risk information, the reality is that more
people watching a risk means a lower probability that the risk will go unnoticed.
B. Before risk events can be added to the register, the columns need to be defined. Sample
information in the columns or simple explanations of what the columns contain come into play.
After those are in place, terms and language should be added to the risk management plan to
ensure consistency as individual risks are added.
B. Risk owners are those who have the ultimate responsibility to track risks, any shifts in the
risk’s probability or impact, and any risk responses. They are also responsible to ensure the
responses, as dictated, are carried out. Although the project manager often becomes the risk
owner for many risks (which is not the ideal), the risk owner should be an individual who has the
time and bandwidth to manage the individual risk as it evolves.
B. Although risk events that never came to pass will also be identified, the “Outcome” column is
a thorough overview of what transpired as a result of both the risk event identified and the
efficacy of the risk response.
B. When a probabilistic event is discovered that has a beneficial outcome, it is considered an

opportunity. Threats exist where a negative outcome on the organization is discovered. Although
not earning the work may be seen as a negative, if that risk is realized, the status quo is
maintained.
D. Propinquity is often a close relative of proximity, in that propinquity refers to any type of
physical or emotional kinship. In this context, propinquity is the degree to which people care or
have a vested interest in the risks at hand. Proximity is strictly about physical nearness.
Review Questions
D. The risk register is not strictly a management document. It’s a document that should ideally
be shared with all stakeholders in the interest of engaging them in the risk process from start to
finish.
D. The consistent exposure to hot and dry conditions increases the probability of wildfires. Given
that the wooden office is adjacent to a fuel source for those fires, the office is proximate to them.
The threat is high on both probability and proximity.
C. The wildfire threat may be significant in California, but in Central Ohio, it’s remote. And
given the 2,200-mile distance between Wapakoneta and Los Angeles, the risk is extremely low
in terms of proximity. (Author’s note: On the exam, there will often be two questions that appear
to be the same or very similar. As illustrated here, a few modest changes change the answers
completely.)
B. The risk owner is responsible not only for tracking the status of the risk itself, but also for
implementing the risk responses, or ensuring their implementation. Risk responses, in the ideal,
are put into action before the risk is realized, unless an active acceptance strategy is determined
to be the appropriate response.
A and D. Proximity is about the physical distance between the project and the risk event that may
happen. (People in Pennsylvania don’t have high proximity to volcanic eruptions.) Urgency
answers the “how soon?” question for either risk realization or risk response implementation.
C. Risk retirement occurs when a risk is no longer a consideration vis-à-vis the project outcomes.
C. The access issue is one that ties to the nature of risk as being a “team sport.” Risks and their
histories need to be captured in such a way that every appropriate stakeholder can review and
reflect on their strategies, responses, and outcomes.
Chapter 11
A. The risk breakdown structure is designed specifically to identify the categories and
subcategories of risk to allow for evaluation of risks on a group level, as well as an individual
event level.
A. There is no predetermination as to which category is the greatest concern when sorting risks.
Because projects are unique, there’s no way to determine which category will come to the fore
until the risks have been evaluated.
B. A risk taxonomy is similar to a risk breakdown structure, but because it is part of the
organizational process assets, it’s a document owned by the enterprise and applied consistently
across projects. In some cases, it serves as assurance that all the enterprise-specific categories are
addressed.
B. Many risk and project managers make the mistake of confusing probability with impact. Just
because a risk outcome might be catastrophic, it’s still quite reasonable that its probability would
be low (or even remote).
B. A tolerance is a point beyond which a project cannot proceed.
D. A risk matrix is normally a 3×3 or 5×5 chart that has probability and impact on the axes.
Using areas within the matrix to clarify which risks are the high-high (high probability, high
impact) risks, color coding (red, yellow, green) is sometimes used to highlight the risk events of
greatest concern.
D. Working with any team, a strong background on the application of the risk matrix and the
terminology therein goes a great distance in ensuring that the “right” risks are escalated to a
group setting.
Review Questions
D. FMEA is the only predominant risk qualification technique that takes risk detectability into
account. By assessing the relative visibility, FMEA ensures that “invisible” risks are given a
higher priority.
C. Taxonomic risk evaluation is normally associated with identifying risk source areas and
associating them with germane questions. Although a risk breakdown structure is a form of
taxonomy, it is not normally a term used with the subsequent question set.
B. The medium-probability, high-impact risks are addressed next, because they are the risks that
still pose a potentially catastrophic outcome for the project. Urgency is normally only considered
when there are too many risks to manage at a given level, and there’s no indication of that here.
A. Anytime a tolerance is met or exceeded, it has the potential to be a project-ending event.

Although this may seem an overreaction, the tolerance was clearly identified in the risk
management plan, and it has been exceeded.
A and E. The PxI matrix groups risks but does not generate a rank order. Although the risk
register uses the terms, those definitions come from the risk management plan, rather than the
register.
C. Consensus doesn’t indicate unanimity or surrender. It also doesn’t indicate a perfect

approach. It does indicate that the parties involved have determined that they will accept the
outcome.
B. Stakeholders are involved, whenever possible, in the risk ranking process.
Chapter 12
A. Earned value performance data can provide a sense of the current trends on a project. On this
project, the CPI of .84 indicates that the project is extracting 84 cents in value for every dollar
spent. Because earned value metrics aren’t applied until the project is at least 20% complete, this
is a very troublesome indicator. Conversely, the schedule data is uplifting. With an SPI of 1.11,
the project is currently 111% of where it should be on the schedule.
A. Anytime more story points are completed than planned, it will show as increased velocity on a
burndown chart. Although this doesn’t present any cost information, it is indicative of better-
than-planned schedule (and achievement) performance.
B. Expected monetary value (EMV) is a simple quantitative evaluation of risk using the approach
of probability times impact. It is very valuable in assessing the relative costs of individual risks
but has little or no applicability on a project-wide perspective. The PxI matrix is qualitative,
rather than quantitative.
B. GERT and VERT are probabilistic network diagrams. Although it may (in theory) be possible
to look at individual activities from this perspective, the reality is that they are applied to gain a
view of potential schedule outcomes based on probabilistic branching.
B. Monte Carlo requires range estimates for all activities in a project, and a standard deviation
can normally be established (even on the largest projects) after 500 simulations.
D. This probability distribution function (PDF) reads likelihood of completion along the thin
black line ascending upward from left to right.
D. Although it is a normal distribution, and the median is likely 7 days, there’s not enough
information in this diagram to determine that with certainty. What is certain is that the range
(with a 100% confidence interval) is between five and nine days.
D. This is precisely the type of information that should be predetermined in the risk management
plan. It is not something conducted ad hoc, and it would not benefit from statistical analysis or
EMV because those approaches alone don’t address the concern about prioritization.
Review Questions
D. Earned value management provides specific project cost and schedule data based on
performance measurements and the performance baseline.
B. Burndown charts provide a sprint-by-sprint view of the original user story (or story point)
completion times versus the accomplished user stories or story points.
B. The ascending dark black line from left to right highlights the probability that work will be
accomplished by a given day. Roughly 9% of the samples actually had March 27 as the
completion date.
E. EMV can apply to value or cost. However, the choice makes a difference in how any scenario
is viewed. In this scenario, it applies to cost. $500 * .05 = $25. Because this is a threat event, it
will incur additional cost.
B and C. The critical path is the path with the most schedule sensitivity. The next-closest path is
near-critical. Any path that is not critical is subcritical.
B. The $400 ticket plus the expected value of being late (40% of 1000) totals $800. It could also
be calculated as the $400 ticket times .6 (240) plus $400 times .4 (160) plus the expected value
of being late ($400) for a total of $800.
C. The “bell curve” for the PDF would be lower and flatter because less talented performers will
not be as consistent as more talented performers. Fewer of the samples would gravitate to the
mean, but the number of simulation iterations would not inherently change.
Chapter 13
A. With high technical uncertainty and a totally new environment, no approach will drive the
project to “responding well.” Although the project may be wholly achievable, the current
conditions put it in chaos. There is a high inherent level of risk.
A. Data rules in a complex environment. With strong data sets, complexity can be reined in and
brought down to an understandable level. The more data the project manager or risk manager has
at their disposal, the more they are able to render the environment less complex.
B. The situation is definitely high complexity but may be resolved if the root causes can be
found. If there are common threads, the project manager or risk manager may have the capacity
to bring these problems to heel.
B. Risk interconnectedness points to the challenges associated with risks that may have an
influence on other risks to be considered. Although individual risk events might not have a high
impact independently, if they are interconnected, the overall impact can become far more
dramatic.
B. Project and risk managers do not have the authority to countermand management’s strategic
objectives. Even when the objectives may be offensive, project managers must embrace strategy.
D. This is a potential showstopper. As it stands, both regulatory and strategic compliance are
mutually exclusive. Management should make the call.
D. The PMO has the key governance role for projects. While some organizations might develop
project boards and oversight committees, the ultimate accountability for governance of projects
rests in the hands of the PMO.
D. These are the project objectives that should be taken into account in a comprehensive impact
analysis. Project and risk managers also need to account for organizational and strategic impact
objectives in their assessments.
Review Questions
E. Opportunity is a condition that may happen to the betterment of the project or the
organization’s objectives. Although it is a form of risk, opportunity is a more specific
description.
C. Because all conditions must be met for the risk to be realized, the and-gate fault tree would be
the logical choice.
B. Although answer A is true to a degree, it is the interplay of the concerns here that make the
threat worrisome.
A. The more variables that are brought into play in a given risk scenario, the more complex the
situation becomes. If the same scenario were presented with two systems on a single platform
conducted with a team that all spoke the same language, the level of complexity (complication)
would decrease dramatically.
B and C. SWOT opportunities and threats are internal to the project. PMI® is ardent that risk
consists of both opportunities and threats.
Chapter 14

A. Enhancement is the effort to increase the probability and/or impact of an opportunity event
occurring. Exploitation creates 100% certainty, which is not the case here. If the project librarian
were from an outside vendor and would receive part of the direct benefit, then (and only then)
would sharing apply.
A. Passive acceptance acknowledges the existence of a risk event but takes no action. The
implication is that the threat is either so minimal in terms of impact or unlikely in terms of
probability that it doesn’t warrant action in advance. Passive acceptance implies that the risk will
be dealt with only if or when it is realized.
B. The risk owner might not have to conduct the review personally, but should be responsible for
ensuring that it actually happens, and that the information from the action taken is reported back
to senior management or you.
B. Risk owners do not take on the response strategies independently unless that is specifically
called for in the strategy. They also do not augment the approach by altering the action plan.
B. The original expected value of the risk was four weeks (eight weeks times 50%). The
expected value of the risk after the strategy is applied is .8 weeks (eight weeks times 10%). The
improvement is 3.2 weeks. With a time consumption of four weeks to implement the strategy,
the EMV of the improvement is not enough to offset the time consumed.
D. The burndown chart will highlight the velocity of the project and show it as stable. The
project backlog provides the volume of work remaining to be performed.
D. The British law aspect of this is not what’s important, because all the activity is in Slobbovia.
And although force majeure will preclude the organization from being punished for the impacts
of acts of nature, the risks cannot be ignored. Corporate policy has to be enforced from time to
time for it to ultimately be enforceable, particularly in difficult situations.
D. Avoidance means to take action to ensure the risk can never impact the project or the
organization. The strategy might impact both, but the risk event will not.
Review Questions
D. Avoidance creates an environment where the risk or its impact cannot occur within the project
context. Given management’s perspective, it’s the only viable strategy here. Enhancement and
exploitation are opportunity strategies, eliminating them from consideration altogether.
A. Because there’s no sign of proactivity, this would be passive acceptance. It’s a strategy where
there’s nothing done in advance to optimize the opportunistic outcome.
B. Workarounds are unplanned responses to negative risk events. This situation, with the risk in
the process of being realized, can only be helped with a workaround. A classic example occurred
after the 2014 sinkhole collapse of the floor of the National Corvette Museum in Bowling Green,
Kentucky. Rather than seeing it as an opportunity lost, the owners made the event a major feature
of their museum going forward, increasing attendance.
B. This is the risk owner’s job. Addressing the strategies does not mean that the owner is
responsible for implementation. The owner is responsible for identifying the nature of the
strategy, ensuring the strategy is deployed as planned, and tracking the progress of the risk event
and the resolution strategy.
B and C. Contingent responses are the province of active acceptance. In passive acceptance, no
proactivity is required. Risk resolution strategies need to be incorporated into the project plan,
whatever form it may take.
B. Management reserve is designed to address the unknown-unknown risks and is ultimately a

form of workaround.
C. When a strategy for threat or opportunity works, it’s important to share that information
inside and outside the team.
Chapter 15

A. Contingent reserves are set aside for threats that fit within the project context. Unknown-
unknowns and known-unknowns are normally addressed through management reserve, rather
than contingency reserve, and are not in the purview of the project manager.
A. Passive acceptance acknowledges the existence of a risk event, but takes no action. The
implication is that the threat is either so minimal in terms of impact or unlikely in terms of
probability that it doesn’t warrant action in advance. Passive acceptance implies that the risk will
be dealt with only if or when it is realized.
B. In evaluating stakeholder reactions to risk responses, tolerances cannot be exceeded. As the

customer, Angelica is right in demanding that the schedule be maintained. The approach to
achieve that is up to the project manager. The subcontractor should not be a party to that
discussion until a strategy has been determined.
B. Face-to-face meetings provide the richest context for sharing information. They allow for the
information sharing, coupled with the paralingual information that can only be achieved in
person.
B. The residual risk is $14,000,000. That’s the amount of risk the project or organization will
face after the threat strategy is applied.
D. Although the contingency funds are sufficient to cover the costs, the residual risks for the
project are the total value of the threat events, if realized. Although the funds render them
financially manageable, there are no indications of other implications associated with the
conversion of those risks to issues.
B. Prior to implementation of the strategy, there were no bollards. The threat that the truckers
may back into the bollards is a threat generated by the risk response. Without the response, that
risk would not exist. Secondary risks are those risks generated by the risk response.
C. Avoidance means to take action to ensure the risk can never impact the project or the
organization. Shutting down the power achieves that goal. However, the threat strategy of
shutting down the power creates a new subset of threats, including danger to the patients in the
neighborhood. That’s secondary risk.
Review Questions
D. For a passive acceptance strategy, contingency reserves are applied as the team is contending
with known risks. The nature of acceptance does not alter probability or impact, but does apply
funds and time to risks realized as they occur.
B. The contingent response is knowing that you can call in the snowplows. The contingent
response to that contingent response (if it fails) is the helicopters. The use of the helicopters is
more appropriately recognized as a fallback plan.
D. Although contingent responses are built into a COOP, and workarounds in such a nightmare
are inevitable, the overarching approach should be detailed in the continuity of operations plan.
B. This is a quantum shift for the project. Migrating from Agile to waterfall is a major shift both
in approach and philosophy, and anytime there is change, there will be parties who will be upset
with the change. Also, the dynamic of the team must shift with the addition of a new vendor,
because the group will be forced back into “forming” per Tuckman’s model of group
development.
B and C. Secondary risks are those risk events created by the resolution approach selected. And
if passive acceptance is the response, there are inherent residual risks because nothing proactive
has been done toward resolution.
D. The potential for job loss and additional work renders the team as committed. They have a
stake in the outcome of the risk event. The customer is involved in that the troubled system
generates their reports, but they don’t have any direct impact as a result.
C. A fallback plan is a contingency plan for a contingency plan. If the original contingency plan
for signatures doesn’t work, a contingent response would be to stop work on the project. An
argument could be made for E as a correct answer, but that’s a transfer strategy, which is not
generally seen as a contingent response.
Chapter 16
A. Data gathering within the Agile methodologies requires an assessment of the user stories and
story points completed. That information can be processed into reports in an adaptive
environment.
A. Earned value indices are such that any value less than one means project performance is
subpar. Any value of one or greater means project performance is where it should be or better.
B. Management should be aware of the contingency status, particularly if it’s going to change
significantly during the next reporting period. Given that 79 percent of the project has been
complete and 82 percent of the contingency remains, there is no cause for alarm, even with the
significant additional contingency spending.
B. If all risk priorities have remained the same, the year-over-year threat to the organization is
the same. As with most insurance, organizations (and individuals) retain it not because the
threats are regularly converting to issues, but because the threats continue with a relatively static
level of probability and impact.
B. An Agile project with higher-than-expected velocity is generally perceived as an opportunity

rather than a threat. The likely outcome is that the project will be completed sooner than planned,
which most organizations perceive as good news. Because it’s a situation that might happen,
rather than one that will happen, it remains a risk.
D. If they are potentially in violation of their contract commitments, this is a concern to be

managed by the contracts personnel, rather than by you as a project manager. Going directly to
Initech may create some of the animus you are trying to avoid. Sharing the information with
other project managers could deteriorate perfectly good relationships between Initech and others
in your organization.
B. Any option that allows for improved, appropriate communication is a good avenue. However,
the project is small enough that escalating to senior leaders would likely be considered
inappropriate. Beyond the communication, standard risk practices should ensure that the right
steps are being taken.
B. Any option that allows for improved, appropriate communication is a good avenue. If senior
leaders need visibility on the risks, your boss will elevate your concerns up the corporate ladder.
Beyond the communication, standard risk practices should ensure that the right steps are being
taken.
Review Questions
D. The data source is definitely jeopardized, and considering what’s happening, the data needs to
be reviewed. A risk manager can’t assume that all risk information is tainted, but the quality of
the data source would prompt a thorough review.
B. The fact that the counts are now consistent is a sign of high precision. An accurate count
would be to hit the 10,000 mark exactly.
B. High probability does not connote certainty. If an organization fails to encounter a high-
probability risk, it does not mean that the risk is any less likely. If the strategy made sense
before, there’s no indication here that a change is appropriate.
B. Resilience is the ability of a project, individual, or organization to bounce back from adversity
and return to a previous state. This is in contrast with anti-fragility, which is where those same
entities recover from adversity and come back in a better state with higher capabilities. Although
“risk prone” sounds like it might apply here, risk prone refers to a willingness to take the risks,
not a capacity for enduring them.
B and C. A single risk event at any level of the project can have a direct impact to the overall
project risk. As a single variable changes, the entire project might ultimately be impacted. The
single most effective way to evaluate such influences is using Monte Carlo analysis.
D. Risk-reward is not just about the financial aspects of a project. If that is the sole criterion for
moving this project forward, it should be shut down. But given the high hopes of your employer
and your project sponsor for future work, the criteria to move forward need to be reconsidered.
C. You originally identified the risk as a project risk. Now that others have come forward and
acknowledged the broader impact of the threat event, you might need to consider it as an
organizational risk with a potential need for organizational resolution(s).
Chapter 17
A. Residual risks are those that remain after the risk response has been applied. Although there
might be a temptation to evaluate this in the context of the policy as a whole or on the incident as
a whole, the reality is that the residual risk is simply the $4,000 deductible.
A. Residual risk doesn’t have to apply to only time and cost. It can go to any of the other threats
that may harm the project. Such threats need not have a hard metric attached. Reputational risk
can easily be residual if it can still hurt the objectives and continues to be “owned” by the
project.
B. Secondary risk is risk generated by the risk response.
B. Although the impacts are the same, the probabilities drive to different expected values,
because the risks are dependent. Because the impact of both risks renders the facility
uninhabitable, avoidance of the risk is the appropriate response.
B. The heart of the answer here is that the rewards are granted with ample caveats about team
expectations. The source of the secondary risk is twofold. It is first generated by the primary risk
(an opportunity) strategy. The other source is team member expectations.
D. The response succeeded in the narrow confines of this particular event. It’s clear that if the
event had happened much later in the project, the response would not have met with the same
level of success. It isn’t a function of clarification, but instead drives a realization that a
mitigation strategy (like moving to the cloud) would have a better chance of success both early
and late in the project.
B. Workarounds (unplanned responses to negative risk events) are deployed only when no
strategy is in place, the planned strategy didn’t work, or the risk was hitherto unidentified. Once
used, they should be archived in detail to ensure that others can benefit from them in future
projects. In this instance, given that the project is moving forward despite the adversity, the risk
responses in place worked well.
B. The risk remains in the risk register, no matter what. Even risks that have expired should be
retained for posterity. Because everything is going well, the probability is likely decreasing,
rather than increasing; however, the impact of the threat remains the same or gets worse as the
project approaches its final days. The best plan is to keep it in the risk register until the last
payment is made, which is when this threat can be retired.
Review Questions
C. The primary risk that the FDA might not approve the project outcome was resolved
successfully. Bringing Guillame on board to deal with that risk is a form of risk transfer. The
intended consequence? FDA approval. The unintended consequence? Team members threaten to
leave.
B. The secondary risks are risks generated by the responses, whereas residual risks are the classic
“leftovers.”
B. As the buyer, you want the lowest risk, which would be a fixed-price contract. Given the
needs of the shipper, and their unwillingness to bear the burden of highway tolls, their concern
could be addressed in an FPEA contract. It is the lowest risk contract that still addresses the
needs of the shipper.
E. The name of the contract type says it all. It’s the costs, plus the agreed-upon percentage. If the
allowable costs are $20,000,000, then 5% of $20,000,000 is $1,000,000. $20,000,000 plus
$1,000,000 is $21,000,000.
B and C. Cost-plus contracts of any type minimize seller risk, because all allowable costs will be
covered, no matter what. Firm-fixed contracts have the lowest administrative burden for all
parties.
D. Risk reporting, be it at the beginning or end of a project, is done when change is planned,
when change occurs, and at regular intervals.
C. There’s no indicator here about Jacques’ level of expertise, save as a workaround magician.
Given that you didn’t anticipate this risk event, this is a workaround.
Chapter 18
A. Every document serves multiple purposes, but every bit of project documentation reflects
threats and opportunities on the project, whether intentionally or not.
A and B. These are both project-specific documentation that requires a regular update, conducted
by the project manager, the risk manager, and/or their designees. Corporate standards and
policies (including standard contract language) don’t shift with the passage of time.
B. Because the stakeholder community can include those who are negatively impacted by your
project, sending it to the entire stakeholder base could be less than productive. Still, you want the
information shared as freely as possible, which the PMO can accomplish. Because you don’t
have the ability to dictate contract language, making it “required reading” will not prove doable.
B. Although it is tempting to say that everything should be updated as a project moves forward,
the reality is that contracts should be an anchor to which the project is tied. Although the contract
may have an influence on which risks affect the project, without an extensive process and the
involvement of legal personnel, the project contract should remain unchanged.
B. Monte Carlo highlights the range of risk by displaying the probabilistic distribution of
possible outcomes. It’s the ideal tool for highlighting project-wide alterations in the range of risk,
particularly for those who prefer a graphical display, rather than a narrative.
D. There is a temptation to keep risks alive based on their significance during a certain time
period within the project. There is also a need to document those risks that have seen both their
impact and probability drop to insignificance as expired. They do not get deleted from the risk
register, but they do need to be acknowledged as immaterial going forward.
B. A risk manager’s or project manager’s responsibility to an organization is to both share

information and to respect those who control information. In this case, the project office controls
the checklist and should be engaged in any updates. Although the project manager might be
willing to make the updates, it’s up to the project office to make any determination regarding
what should ultimately be done.
B. Of the options available here, the best answer is to notify the project office. They need to
know not only that the risk exists on your project, but that it has implications across the other
projects in the organization.
Review Questions
D. The risk reports should be done when change is planned, but also when change happens that is
not planned, as well as at regular intervals. The timing of those intervals would be dictated in the
risk management plan, rather than the communications management plan.
A. The risk management plan is home to the risk lexicon, including the definitions of terms and
tolerances. The actual data will be retained in the risk register, which is the living project
document that is regularly updated with fresh data.
A. Latin Hypercube is less taxing on systems because it does not allow for repeated simulations.
Each new simulation is different from its predecessors. This speeds the analysis with little or no
cost to the accuracy of the evaluation. Monaco Straight and risk registration are not terms used
in risk management.
D. In Agile, the concept of a risk-based spike is the notion that it’s possible to conduct a trial run
of almost any major risk environment to see whether the risks will be realized.
C. When creating a risk burndown chart, user stories are added to account for the risk responses.
B. When a project is terminated (as planned or prematurely), the risks to the project itself are
over. There may still be risk to the organization and to the system, but the risks to the project
have passed. As such, team members assigned risk ownership are free of those responsibilities.
C. This provides the benefit of applying the lesson learned, the specific actionable steps to make
the lesson learned happen, and how to implement the lesson learned. The history of satisfaction
mentioned in answer D is nice information to have but isn’t part of the lesson.
Appendix B
Risk Management Professional (PMI-RMP)® Cert Guide Exam Updates
Over time, reader feedback allows Pearson to gauge which topics give our readers the most
problems when taking the exams. To assist readers with those topics, the authors create new
materials clarifying and expanding on those troublesome exam topics. As mentioned in the
Introduction, the additional content about the exam is contained in a PDF on this book’s
companion website, at http://www.pearsonitcertification.com/title/9780138108472.
This appendix is intended to provide you with updated information if PMI makes minor
modifications to the exam on which this book is based. When PMI releases an entirely new
exam, the changes are usually too extensive to provide in a simple update appendix. In those
cases, you might need to consult the new edition of the book for the updated content. This
appendix attempts to fill the void that occurs with any print book. In particular, this appendix
does the following:
Mentions technical items that might not have been mentioned elsewhere in the book
Covers new topics if PMI adds new content to the exam over time
Provides a way to get up-to-the-minute current information about content for the exam
Always Get the Latest at the Book’s Product Page
You are reading the version of this appendix that was available when your book was printed.
However, given that the main purpose of this appendix is to be a living, changing document, it is
important that you look for the latest version online at the book’s companion website. To do so,
follow these steps:
Browse to www.pearsonitcertification.com/title/9780138108472.
Click the Updates tab.
If there is a new Appendix B document on the page, download the latest Appendix B document.
Note
The downloaded document has a version number. To compare the version of the
print Appendix B (version 1.0) with the latest online version of this appendix, you
should do the following:
Same version: Ignore the PDF that you downloaded from the companion
website.
Website has a later version: Ignore this Appendix B in your book and read
only the latest version that you downloaded from the companion website.
Technical Content
The current Version 1.0 of this appendix does not contain additional technical coverage.
acceptance (opportunity) An opportunity strategy whereby no proactivity is involved, but the

opportunity is acknowledged and, if it comes to pass, accepted and welcomed.
accuracy The degree to which a metric is close to the target value.
active acceptance (threat) A threat strategy where no action is taken prior to risk realization,
except the documentation and communication of requisite action when or if the threat is realized.
actual cost The amount of money spent to accomplish a work package or a series thereof. Actual
cost is calculated and accrued when finance or accounting can determine the amount spent. This
is the value associated with cost calculations in earned value management system calculations.
Also known as the actual cost of the work performed.
affinity diagrams Diagrams developed when brainstormed risks are placed on slips of paper,
and team members (one at a time) place the slips with other risks with some commonality. The
output is natural groupings, established by their affinities one to another.
all-gate fault tree A fault tree where all conditions must be met to prompt the risk to be realized.
and-gate fault tree Graphical displays of conditions where there are multiple faults that may
lead to a given risk outcome, but all faults must be realized for the outcome to occur.
anti-fragility The ability of an individual or organization to recover from a realized risk event
and return to an improved state as a result of the risk’s realization.
appetite A description of the willingness (or lack thereof) of an organization or individual to

accept or deal with risks. The risks may be individual risk events or risk overall as a component
of culture.
assumptions What is believed to be true for planning purposes. Assumptions remain “assumed”
until they are validated.
assumptions analysis A review of what is believed to be true about a project for planning
purposes. Assumptions (documented in an assumptions log) are assessed for their potential
validity and the risks they may generate based on that assessment.
attitude A description of the willingness (or lack thereof) of an individual to accept or deal with
risks. The risks may be individual risk events or risk overall as a component of culture.
avoidance A threat strategy that ensures the threat event will not come to pass. The total
elimination of the probability of the threat, driving it to a status as a nonrisk.
brainstorming An information-gathering technique that allows all participants to share their

thoughts on a focused topic, without criticism, until all ideas are completely exhausted.
burndown In Agile management, the rate at which sprints, user stories, and/or story points are
consumed over time.
change logs Incrementally developed records of changes proposed, included, and acted upon
within a project.
checklist analysis Rooted in organizational and project history, a checklist is a reflection of

common risks or responses in projects, which should be reviewed at the beginning and at regular
intervals during the life of a project.
claiming techniques In earned value, the technique applied to establish how much work has
been performed. The most common claiming techniques are percent complete, the 50-50 rule, the
20-80 rule, and the 0-100 rule. For the last three on that list, the first percentage (50%, 20% and
0%) is what is awarded when a work package begins. The remainder (50%, 80% and 100%) is
awarded when a work package is complete.
collaboration A win-win conflict resolution strategy involving shared solutions.
commitment A stakeholder’s level of participation in dealing with or acting on a risk resolution

approach. Commitment indicates that the stakeholder has a level of participation that may
directly threaten their personal or project objectives.
complexity The condition of being complicated. This situation is often exacerbated by high
levels of systems interaction or human interaction.
compliance A state in which the project is meeting the rules, regulations, and boundaries
established for it by the project organization or in the environment in which the project must
function. Also defined as a binary condition where tolerances are either met or not, as dictated by
a party with regulatory authority (be it internal or external).
compromise A win some, lose some conflict resolution strategy where all parties give up some
of their desired outcomes to move beyond the conflict.
connectivity The extent to which a given risk event has influence on other aspects of the project
organization, the enterprise, or other risk events.
consensus A condition where all parties either agree to or can tolerate a given set of priorities.
constraints Metrically driven clear delineations of the project environment, classically in terms
of time, cost, and requirements. Constraints may also manifest themselves in terms of available
resources, geography, and environmental limitations. Typically, constraints are expressed as
“must” or “shall” statements.
contingency An approach or funding held in abeyance for the time when risks are realized.
Funding may be used associated with virtually any response strategy, whereas contingent
responses are normally associated with active acceptance.
contingency reserve Reserves held under the project manager’s control that are used to deal
with risks as they are realized. Such risks are within the nature of the project.
contingent response A planned response under active acceptance, sometimes referred to as a

contingency plan. An approach or tactic to be applied if a risk that has been accepted is realized.
contingent/contingency reserve Funding or time set aside to finance management of risks

realized at the user story, work package, or project level. Funds are expended as the risk(s) is/are
realized.
continuity of operations plan (COOP) A plan (generally at an organizational or whole-project

level) to allow the entity to continue to function, often at a scaled-back level.
cost performance baseline The sum of the values of the individual work packages, spread
across the timeline. The work packages of the performance measurement baseline include not
only the cost of the work, but also the contingency reserve associated with each work package.
cost performance index A relative metric in earned value in terms of cost. It is calculated as
earned value over actual costs. EV/AC = cost performance index.
cost variance The difference between the earned value and the actual costs in an earned value
management approach. It is calculated as earned value minus actual costs. EV – AC = cost
variance.
cost-plus award fee A contract type where the buyer agrees to pay all allowable costs, plus a fee
based on objective and/or subjective criteria determined in the contract language. The amount of
the fee is largely determined by the buyer’s interpretation of accomplishment toward those
criteria.
cost plus fixed fee A contract type where the buyer agrees to pay all allowable costs, plus a
fixed, predetermined fee.
cost plus incentive fee A contract type where the buyer agrees to share overruns or underruns of
cost based on a sharing ratio (designated in the contract language). The buyer will pay all
allowable costs in the contract, no matter what.
cost plus percentage of cost A contract type where the buyer agrees to pay all allowable costs,
plus a fee based on a percentage of those allowable costs. This contract type represents the
highest threat to the buyer and the lowest threat (greatest opportunity?) to the seller.
customer agreements Contracts, memoranda of understanding, and other documentation

reflecting the relationship between the buyer and seller (recipient and provider) in a project.
daily Scrum (also known as a daily standup) A daily meeting in an Agile methodology where
three questions are asked of every team member every morning: What did you do yesterday?
What are you doing today? What is standing in your way?
data Unfiltered, unprocessed raw facts or fact points.
data source The originating basis or foundation from which data are drawn.
decision tree analysis A graphical display of expected monetary value in efforts to determine
which options or decisions yield the best outcomes.
Delphi technique An information-gathering technique that involves a minimum of three subject

matter experts sharing information anonymously with the other experts (normally via email)
where the ideas are captured and shared back with the experts for review, critique, and additions
in a minimum of three cycles.
dependent probability A condition where one event can happen only if another event transpires.
If event A has a probability of 40%, but can happen only if event B (with a probability of 70%)
occurs, then the likelihood of event A’s occurrence is dependent on B. 40% * 70% = 28%.
detectability (FMEA) The relative visibility of a given risk event as it nears realization.
dormancy The length of time a risk may remain undetected and/or undetectable prior to
realization.
dot voting A scoring system where all members of a group are given the same number of
adhesive “dots” and the dots are then applied to the risks causing the greatest concern by each
individual. Participants may place one or all of their dots on any given risk.
earned value The value of the work associated with a work package. Earned value is accrued
when the work is done. This is the first value applied in most earned value management system
calculations. Also known as the budgeted cost of the work performed.
enhancement (probability and/or impact) An opportunity strategy that increases the

likelihood, the amount at stake, or both.
escalation The act of shifting a risk to a higher level in the organizational hierarchy.
escalation (opportunity) An opportunity strategy where the opportunity is sufficiently

significant that it cannot be managed at the current project level and instead needs the approval
or action of someone within a higher echelon of the organization.
escalation (threat) A threat strategy where the threat is such that it cannot be managed at the
current project level and instead needs the approval or action of someone within a higher echelon
of the organization.
estimate at completion Based on any of a variety of formulae, this value in earned value
management systems is the current target cost of the entire project, based on spending to date
and other factors/assumptions. BAC/CPI = EAC (based on past performance); BAC – EV + AC
= EAC (assuming past performance was anomalous); ((BAC – EV) / (CPI * SPI)) + AC = EAC
(assuming time and cost influence the final outcome).
expected monetary value Numerically, probability times impact.

explicit knowledge Information that can be shared or transferred through clear, directive
guidance, such as an instruction manual or training.
exploitation An opportunity strategy that ensures that the opportunity will come to pass,
converting the risk event to a realized benefit. The elimination of probability with opportunity,
driving it to status as a sure thing.
failure mode effect analysis (FMEA) A well-constructed FMEA will highlight the risk sources
and the multiple impacts that may result if the events associated with those sources are realized.
In the qualitative analysis, the FMEA considers the probability, impact, and detectability of those
risk events, and through multiplication of the probability, impact, and detectability scores,
generates a risk priority number (RPN).
fallback plan A secondary contingent response to be applied in the event that the primary
contingent response did not succeed or was not sufficient to deal with risk acceptance.
fault trees Graphical displays of conditions where there are multiple faults that may lead to a
given risk outcome.
firm-fixed price A contract type where the buyer pays an agreed-upon price for the project
deliverables, with no adjustments for project cost, environment, or outcome. This is the highest
risk contract for sellers and the lowest risk to the buyer. It has the lowest administrative burden
for all parties.
fist to five A real-time, hand-scored assessment of relative risk with a fist representing the lowest
possible score and a five-finger open hand representing the highest (with all the intervening
fingers representing different relative levels of risk).
fixed-price economic adjustment A contract type where the buyer pays an agreed-upon price
for the project deliverables, with adjustments for a single aspect that is high risk to the seller.
fixed-price incentive fee A contract type where the buyer agrees to share overruns or underruns
of cost based on a sharing ratio (designated in the contract language). The buyer is protected
from excessive threat by virtue of a ceiling price, which represents the maximum price tag for the
project.
focus group An information-gathering technique where informed participants share information

in a small group setting, drawing on the ideas of others and building a data set.
forcing A win-lose conflict resolution strategy where one party gets all that they wanted, forcing
the other party to forego their desired outcome.
impact The severity associated with the occurrence for a risk event. It can be expressed
qualitatively (high-medium-low) or quantitatively ($10,000, 14 days, 6 defects).
individual risk tolerance The limit of risk that an individual will abide. It can be financial, time,
quality, environmental, or any of a host of different risk areas that may (or may not) be
withstood.
industry benchmarks Points of reference from similar efforts that may be used as standards or
targets in achieving risk goals.
information Processed or sorted data.
intended outcomes Outcomes from risk responses that are anticipated and that have
characteristics that were anticipated.
interconnectedness The area of complexity that takes into account the systems or human
interaction that compounds the likelihood of risk events being realized. When multiple
conditions must be met and the risks are dependent on one another, interconnectedness is high.
involvement A stakeholder’s level of participation in dealing with or acting on a risk resolution

approach. Involvement indicates that the stakeholder has a level of participation that does not
directly threaten their personal or project objectives.
K-L-M
known-knowns Risks that have been previously identified, and there is a shared understanding
of the likelihood and impact of those risks.
known-unknowns A condition where it is understood that some risk or risks will evolve in the
life of the project, but the nature of those risks (and their impacts) is unidentified.
Latin Hypercube A Monte Carlo analysis that looks at semi-random outcomes to determine the
probability of any given outcome or group of outcomes, based on multiple simulations—none of
which are repeated within the analysis.
lessons learned Documented historical information regarding past performance and how it can
either be achieved again or avoided at all costs.
manageability/controllability The degree to which management action (or risk owner action)
can bring a risk event within tolerance.
management reserve Reserves held under management’s control (at a level above the project
manager) used to deal with threats as they are realized. Such threats are outside of the project,
often the unknown-unknowns.
maturity The degree to which an individual or organization works within the confines of
repeatable, beneficial processes. The more such processes exist, the more mature the
organization.
meetings An information-gathering and information-sharing tool with a clear objective, an

established agenda, and participants who all contribute to both.
mind mapping A brainstorm supported by graphics highlighting the connections between risks
identified as they are developed.
mitigation A threat strategy to minimize the probability, impact, or both for a threat event.
Monte Carlo An iterative, simulation-based tool that looks at random outcomes to determine the
probability of any given outcome or group of outcomes, based on multiple simulations.
multiple-gate fault tree Graphical displays of conditions where there are multiple faults that
may lead to a given risk outcome, and when a certain number of faults causes the outcome to be
more likely.
N-O
nominal group technique (NGT) In qualification, an opportunity to evaluate risks similar to a

brainstorm, but conducted on paper with each participant providing a personal priority ranking to
the entire list.
opportunity The risk events that may occur causing an improvement in achieving the project
outcomes. Upon realization, it’s a benefit to the project.
organizational risk tolerance The limit of risk that an organization will abide. It can be
financial, time, quality, environmental, or any of a host of different risk areas that may (or may
not) be withstood.
organizationwide risks Risks that have impacts beyond the project into the organization for
both the project life cycle and the system life cycle. Often, these risks are escalated to a program,
portfolio, or enterprise.
or-gate fault tree Graphical displays of conditions where there are multiple faults that may lead
to a given risk outcome, and any one fault can be realized for the outcome to occur.
overall risk A rating scheme by which risks are given a score to determine their relative weight
in comparison to other risks. Commonly applied in failure mode effect analysis (FMEA) as a risk
priority number (RPN).
owner See risk owner.
passive acceptance (threat) A threat strategy whereby no proactivity is involved, but the threat
is acknowledged and will be dealt with only at that time.
PESTLE A classic risk categorization tool that works from the sources of the risk. The standard
PESTLE framework includes political, economic, social, technological, legal, and environmental
risks. PESTLE is sometimes used as a “prompt list” to encourage categorical discussion of the
specific risks that might exist in a project environment.
planned value The value of the work associated with a work package. Planned value is accrued
when the time planned for the work has passed. This is the value associated with schedule
calculations in earned value management system calculations. Also known as the budgeted cost
of the work scheduled.
portfolio risk Risk viewed from the perspective of all work performed by an organization.
Rather than a single project or effort, portfolio risk takes an organizational view.
precision The degree to which metrics are consistent or repeatable.
priority The application of the overall risk to generate a rank-order list of priorities.
probability The likelihood of occurrence for a risk event. It can be expressed qualitatively (high-
medium-low) or quantitatively (10%, 40%, 67%).
problem-solving A win-win conflict resolution strategy involving innovative, shared solutions.
program evaluation review technique (PERT) A weighted average that emphasizes the most
likely condition and allows for normalization of a triangular distribution assessment. The
formula is (Optimistic + (4 x MostLikely) + Pessimistic)/6.
program risk Risk viewed from the perspective of all work performed within a program. Rather
than a single project or effort, program risk takes a view from a grouping of efforts with a
common element (e.g., customer, deliverable, geography).
project assumptions Information believed to be true for planning purposes. Until validated as
true, assumptions represent sources of risk.
project charter The authorizing document for any project, incorporating a clear, metric-driven
objective statement of project goals.
project management plans Plans for how a project will be led or managed to achieve project
objectives.
project plans Plans for implementing the work to be conducted to achieve project objectives.
project risk tolerance The limit of risk that a project will abide. It can be financial, time,
quality, environmental, or any of a host of different risk areas that may (or may not) be
withstood.
project-wide risks Risks that impact the entire project or are sustained through the entire life
cycle of the project. These are not risks associated with a single task or group of tasks, but with
the project as a whole.
propinquity The level of interest and passion for a particular risk event. The degree of
propinquity is sometimes driven by an individual’s echelon in an organization or by the number
of individuals who are zealous regarding a specific risk. A sponsor or key stakeholder ideally has
high propinquity.
proximity The degree of physical nearness of a risk event.
PxI matrix A tic-tac-toe (3x3 or 5x5) chart to highlight risk priorities by grouping them in
relative probability and impact scoring areas. High-probability–high-impact and medium-
probability–high-impact risks are those that should be addressed first (and are often in the “red
zone” of the chart).
Q-R
quantitative risk analysis A numeric evaluation of the probability and/or impact of a risk, using
absolute terms to express the nature of the risk on a value scale.
RACI (responsible, accountable, consult, inform) chart The chart, more commonly
recognized by its acronym than its definition, that highlights individual risks, risk responses, or
risk areas, juxtaposing them with the individuals who have some level of involvement with them.
reports Formatted information.
residual reputational risk Risk that remains in the province of the project sponsoring
organization, which may directly influence the reputation of the organization and/or the project
itself.
residual risk Risk impact and risks that remain after resolution strategies have been applied.
Passively accepted risks are largely residual, as are risks that have been transferred only in part
(e.g., insurance with deductibles).
resilience The ability of an individual or organization to recover from a realized risk event and
return to its original state.
response strategy The plan for dealing with a particular risk to render it within tolerance.
responsibility assignment matrix (RAM) A chart that highlights individual risks, risk
responses, or risk areas, juxtaposing them with the individuals who will implement them.
retirement criterion/criteria The point at which a given risk is no longer tracked or under
consideration, because it may no longer influence project objectives.
risk absorption The amount of risk an organization, project, or individual can withstand. It can
be financial, time, quality, environmental, or any of a host of different risk areas that may (or
may not) be capable of being absorbed.
risk accountability A state of being liable for risk tracking or risk response performance.
risk alliance A condition where a variety of stakeholders share a common understanding of risks
and a common willingness to see that they are managed within the construct of the enterprise and
project strategies.
risk breakdown structure (RBS) A decomposition of risks in a project, broken out according to
the risk sources.
risk burndown chart An Agile chart that shows progressive levels of completion of user stories
remaining over time. The risk burndown chart is a simple burndown chart where risk responses
have been converted into user stories and incorporated in the product and, ultimately, sprint
backlogs.
risk identification The naming and exploration of the description of risks on the project (either
individual or projectwide), including the event that may influence project objectives and the
impact it may cause.
risk management planning The development of the risk management plan, a document that
guides on how the risk process will be applied (but not on how individual risks will be managed).
risk manager The individual responsible for oversight and implementation of the risk processes.
risk matrix See PxI matrix.
risk owner The name of an individual responsible for tracking and monitoring specific “owned”
risk events, and for ensuring the response strategies are applied as required. The risk owner also
reports out on the current status of the risk event and its related attributes.
risk process This is the process, as a whole, for risk management, including the steps of
planning, identification, analysis, response development, response implementation, control, and
retirement.
risk process tools Certain tools (e.g., forms, formats, spreadsheets, software packages) that
enable each of the steps in the risk process.
risk register A table of project risks, coupled with all the background information necessary to
track, respond to, and report on their status.
risk repository An archive of risk registers from current and past projects, used as a historical
database.
risk response development The step in the risk process where responses are evaluated and
selected for each risk event. These responses become the responsibility of the risk owner.
risk response implementation The step in the risk process where selected responses are applied
under the guidance of the risk owner.
risk responsibility A state of being answerable for risk tracking or risk response performance.
risk sources As the name implies, risk sources are the causes of risks at the most rudimentary
level. Risk sources allow for risk management at a root cause level.
risk-adjusted burndown chart See risk burndown chart.
risk-based spike Proof of concept approach to determining whether a risk will ultimately be
realized when the approach is implemented. It can also be used to obtain more information, and
in doing so, lower the uncertainty.
risk-reward The consideration of the value of risk taking in a threat environment in light of the
potential upside to the outcome.
Roman voting A thumbs-up, thumbs-down approach to establishing risk priority.
root cause analysis A practice to identify not just the various causes for a single effect, but also
(by virtue of their predominance during the analysis) which of those causes are likely the root
causes of the effect. The data is presented in an Ishikawa diagram, which is also referred to as a
fishbone diagram or cause-and-effect diagram.
salience model A stakeholder evaluation model or grid designed to highlight two aspects under
consideration for any stakeholder. The most common salience model examines relative levels of
power and interest.
schedule performance index A relative metric in earned value in terms of schedule. It is

calculated as earned value over planned value. EV/PV = schedule performance index.
schedule variance The difference between the earned value and the planned value in an earned
value management approach. It is calculated as earned value minus planned value. EV – PV =
schedule variance.
secondary risk Risks generated by the resolution strategy or approach that otherwise would not
exist.
sensitivity analysis Any analysis practice that can reflect the grand-scale change that individual
risk event adjustments can cause and the degree to which those adjustments have an impact.
servant leadership A form of leadership where project and risk managers affirm the roles of
team members by taking on some of the more onerous administrative tasks and by affirming the
importance of the team members’ respective responsibilities.
sharing An opportunity strategy that involves partnering with another party to increase the
probability of achieving the opportunity.
smoothing (accommodation) A conflict management strategy where the parties identify and
engage in discussion about areas of commonality unrelated to the conflict itself.
stakeholder engagement matrix A chart or graph delineating project stakeholders and their
respective levels of engagement in the project. Those levels might include unaware, resistant,
neutral, supportive, and leading.
stakeholder register A log of key stakeholders, incorporating supplemental information to

facilitate communications and interactions.
stakeholder-driven trigger A trigger that is established based on the personal perspective of a

stakeholder, often associated with that individual’s perception of acceptable (and unacceptable)
risk.
strategic impact The effect of a given risk event on corporate or project strategies.
SWOT analysis A simple four-square display of the strengths, weaknesses, opportunities, and
threats associated with a project. Strengths and weaknesses are external to the project, whereas
opportunities and threats are driven directly by the project’s existence.
system life cycle The time from project inception through decommissioning of its deliverables.
This includes both the project life cycle and ongoing operations and maintenance of whatever
was developed during the project. Ordinarily, the more significant and expensive component of
the system life cycle is operations and maintenance, rather than the project itself.
tacit knowledge Information that is difficult to share as it seems innate for each individual. This
information often requires experiential learning.
team charter A team-crafted document establishing normative behaviors for the team and
identifying (in advance) how future conflict will ultimately be managed.
threat The risk events that may occur, causing damage to achieving the project outcomes. Upon
realization, it’s an issue for the project.
threshold A point prior to reaching a tolerance where behavior should change to minimize the
probability or impact of hitting the state of being out of tolerance.
time and materials A contract type where the buyer agrees to pay costs for labor and materials,
based not on actual costs, but on worker classifications.
tolerance A point (in terms of time, cost, culture, behavior, or requirements) beyond which a
project will either not proceed or will undergo a major reevaluation before proceeding. In terms
of compliance, a project that is not in compliance has exceeded a tolerance.
transfer A threat strategy that involves partnering with another party to decrease the probability,
impact, or both of encountering the threat.
trigger A physical or visible manifestation that a threshold is being breached and that a tolerance
is imminent.
Tuckman’s Model of Group Development Also known as Tuckman’s Ladder of Group

Development, the model spells out how teams evolve through the steps of forming, storming,
norming, performing, and adjourning.
U-Z
unintended consequences Outcomes from risk responses that are not anticipated (short term or
long term) and that drive characteristics and reactions that were not anticipated.
unknown-knowns Risks that have been previously identified, but awareness of them is now
lacking.
unknown-unknowns Risks that have not been identified, and there is no awareness of them.
urgency The degree of exigency associated with a risk, particularly in regard to how soon the
response strategies must be applied or how soon the risk event may be realized.
withdrawal (avoidance) A conflict management strategy where one party disengages from the
conflict to allow time for reconsideration or calming.
workaround Unplanned responses to negative risk events or threats, realized or unrealized.
Index
acceptance, 308, 392

active, 245, 247
passive, 244, 246
accommodation, 47
accountability, risk, 75, 76
accuracy, 283–284, 379
action plan
Agile, 250
predictive, 250
active acceptance, 245, 247, 379
actual cost, 199, 379
adaptive approach, data gathering and reporting
qualitative, 330
quantitative, 331–332
adjourning stage, Tuckman’s Ladder of Group Development, 94
affinity diagram, 112–113, 176, 329, 379
Agile, 79
action plan, 250
daily Scrum, 133
metrics
sprint completion, 201
story point completion, 203
user stories completion, 202
agreement, customer, 8, 382
all-conditions fault tree, 228
alliance, risk, 61
analysis
assumptions, 115–116, 132–133
checklist, 115
failure mode effect, 160, 179
PESTLE, 32
preliminary data, 118–119
qualitative, 58
quantitative, 58
decision tree, 212–214
GERT (graphic evaluation review technique), 209
Ishikawa diagram, 212
Monte Carlo simulation, 204–205, 287
PERT (program evaluation review technique), 205–209
VERT (venture evaluation review technique), 209
risk, 57
root cause, 113–115, 226
sensitivity, 210
Monte Carlo, 210–211
network diagram, 211–212
SWOT, 226–227
anti-fragility, 286, 379
any-condition fault tree, 228–229
appetite, 24, 379
archive, 14, 101. See also documentation
location, 164
risk, 11
risk register, 11–14
assessment, environmental, 9
assumptions, 115–116, 125, 379. See also constraints
discussing openly, 133–134
as identified risks, 132–133
project, 8
risk, 26
attitude, 25, 379
avoidance, 47, 247, 379
BAC (budget at completion), 198

benchmarks, industry, 6
bias, 72, 78
body language, 80
brainstorming, 94–95, 379
budget at completion, 198
burndown chart, 202–203, 331–332, 389
business risk, 131
capacity, 34
categories, risk register, 156
archival location, 164
area impacted, 161
connectivity, 159
controllability, 159
detectability, 160
dormancy, 159
escalation, 161
follow-up, 164
impact, 158
implementation review, 163
implementation schedule, 163
manageability, 159
outcome, 164
overall risk, 160
priority, 161
probability, 157
propinquity, 158
proximity, 159
response strategy, 162–163
retirement criteria, 163
risk event, 157
Risk ID, 157
risk owner, 161
strategic impact, 160
urgency, 158
change
in constraints, 131–132
log, 333–334, 379
chart
burndown, 202–203, 331–332
RACI, 73–74, 254
charter
project, 8
environmental assessment, 9
signature, 9
team, 47–48
checklist analysis, 115, 379
claiming techniques, 282, 380
clarity, communication, 77
classification
information, 100
risk, 164–165
collaboration, 380
color coding scheme, RMP (risk management plan), 178
commitment, 29–30, 268–269, 380
communication, 34
author, 78
bias, 78
clarity, 77
face-to-face, 79
modes, 79–80
recipients, 78
response strategy, 253
timing, 78
complexity, 381
risk, 226
tree diagram
all-conditions fault, 228
any-condition fault, 228–229
multiple condition fault, 229
compliance, 143, 381
rules, 143–144
tolerance, 254
compromise, 47, 381
conflict management, 46
compromise, 47
discord, 46
forcing, 47
meetings, 97
problem solving, 46–47
smoothing, 47
withdrawal, 47
connectivity, 159, 231–232, 381
consensus, 183, 381
constraints, 19, 27, 125, 381
changes in, 131–132
discussing openly, 133–134
as risk drivers, 129
contingency, 266, 381
funds, 266
reserve, 130, 131, 266, 381
continuity of operations plan (COOP), 267, 381
contracts
relative risk, 313–314
secondary risk. See secondary risk
cost
actual, 199
performance baseline, 381
performance index, 199, 382
variance, 199, 382
CPAF (cost-plus award fee) contract, secondary risks, 311
CPFF (cost-plus fixed fee) contract, secondary risks, 311
CPIF (cost-plus incentive fee) contract, secondary risks, 310
CPPC (cost-plus percentage of cost) contract, secondary risks, 312–313
critical path, 211–212
culture
discord, recognizing and resolving, 46, 47–48
project management, updates, 340–341
risk, 27–29
customer agreement, 8
daily Scrum, 79, 133, 382

data, 77, 382. See also information
accuracy, 283–284
collection, 282
adaptive approach, 330, 331–332
predictive approach, 329, 330–331
gathering, 79
performance, 197
processing, 33
source, 282–283, 382
decision tree analysis, 212–214, 229–231, 382
Delphi technique, 96, 382
dependent probability, 285, 383
detailed analysis, 209–210
detectability, 160, 179, 383
diagram
affinity, 112–113, 176, 329
fishbone, 113–115
Ishikawa, 113–115, 212, 226
network, 211–212
tornado, 211
tree, 227–228
discord, recognizing and resolving, 46, 47–48
documentation, 6. See also chart; charter; communication; diagram
change log, updates, 333–334
customer agreements, 8
industry benchmarks, 6
lessons learned, 7, 333
management plan, updates, 332
project assumptions, 8
project charter, 8–9
signature, 9
project plans, 7
RACI (responsible, accountable, consult, inform) chart, 73–74
RAM (responsibility assignment matrix), 72–73
risk communication, 77
categories. See also risk, register
functionality, 155–156
RMP (risk management plan), 57
dormancy, 159, 383
dot voting, 182, 383
Drucker, P., 291
EAC (estimate at completion), 383

earned value, metrics, 197
actual cost, 199
CV (cost variance), 199
EV (earned value), 198
PV (planned value), 198
SV (schedule variance), 199
TCPI (to-complete performance index), 201
Earth Island Institute, 44
education and training
response-generated risk, 308
risk, 80–81, 100–101
efficacy, ranking approach, 284
EMV (expected monetary value), 209–210, 231
engagement
rules, 98
escalation, 99
information sharing, 100
reporting, 100
tolerance, 98
trigger, 99
team, 93
enhancement, 245, 383
enterprise, risk management, 11
escalation, 13, 99, 161, 246, 249, 383
event risk, 12, 157, 252–253
expected monetary value, 383
expertise, risk identification, 117
explicit knowledge, 23, 384
exploitation, 384
external constraint, 27
face-to-face communication, 79, 97

facilities, equipment, and hardware, 34
fallback plan, 247, 267, 384
fault tree, 384
financial risk, residual, 307
firm-fixed price contract, secondary risks, 309
fishbone diagram, 113–115
fist to five, 182, 384
fixed-price economic adjustment, 384
FMEA (failure mode effect analysis), 160, 179, 384
focus group, 95, 384
follow-up, 14, 164
force, 47, 384
forming stage, Tuckman’s Ladder of Group Development, 93
FPEA (fixed-price economic adjustment) contract, secondary risks, 309–310
FPIF (fixed-price incentive fee) contract, secondary risks, 310
functionality, risk register, 155–156
and-gate fault tree, 379

or-gate fault tree, 386
general analysis
Monte Carlo simulation, 204–205
group risk ranking, 181
high-impact risk realization, 285

anti-fragility, 286
resilience, 286
high-probability risk realization, 284–285
HIPAA (Health Insurance Portability and Accountability Act), 289
identification, risk, 57, 111

affinity diagram, 112–113
assumptions analysis, 115–116
checklist analysis, 115
expert judgement, 117
mind mapping, 111–112
preliminary data analysis, 118–119
risk questions, 117–118
root cause analysis, 113–115
SWOT analysis, 116–117
IF/THEN statement, 157
impact, 13, 58, 129, 158, 161, 221, 309, 385. See also high-impact risk realization; probability
enhancement, 245
high, 284, 285
low, 285
minimizing, 248
scale, 177–178
strategic, 160
implementation
response, 59, 261
review, 14, 163
risk response strategy, 92
schedule, 14, 163
individual ranking, 181
individual risk tolerance, 385
industry benchmarks, 6, 385
influence, project, 286–288
information, 77, 385
classification, 100
gathering, 282
adaptive approach, 330, 331–332
brainstorming, 94–95
Delphi technique, 96
focus groups, 95
interviews, 96
meetings, 96. See also meetings
nominal group technique, 95
predictive approach, 329, 330–331
sharing, 100, 323
infrastructure
capacity, 34
communication, 34
organizational, 33
insurance
residual risk, 270
risk absorption, 43–44
intended outcomes, 385
interconnectedness, 231–232, 385
interest, 29
internal constraint, 27
interviews, 96
involvement, 268–269, 385
Ishikawa diagram, 113–115, 212, 226
J-K
knowledge
explicit, 23
tacit, 23, 80
known-known, 129–130, 385
known-unknown, 131
language, body, 80
Latin Hypercube, 205, 330, 385
leadership, servant, 61
leading stakeholders, 30
lessons learned, 7, 333, 385
life cycle risk updates, 337–338
environmental change, 339
organizational change, 339–340
technical change, 339
unanticipated overuse, 338
manageability, 385
management plan, 7
risk, 57, 67–68
updates, 332
management reserve, 129, 385
matrix
probability-impact, 178, 181
responsibility assignment, 72
risk, 178
maturity, 25–26, 386
mean, PERT, 205–206
mediation, 46
meetings, 386
face-to-face, 97
reconciling conflict, 97
virtual, 97
Mehrabian, A., 79
metric/s
Agile
earned value, 197
actual costs, 199
SPI (schedule performance index), 199
resolution, 251–253
selection, 291
mind mapping, 111–112, 386
mitigation, 248, 386
model
PESTLE, 60–61
salience, 29
sender-receiver communications, 78
Tuckman’s Ladder of Group Development
adjourning stage, 94
forming stage, 93
norming stage, 93
performing stage, 94
storming stage, 93
monitoring and controlling risk, 92, 299
Monte Carlo, 204–205, 287–288, 386
Latin Hypercube, 205, 330
sensitivity analysis, 210–211
multiple condition fault tree, 229
narrative, response strategy, 13

National Institutes of Standards and Technology, 270
near-critical path, 212
network diagram sensitivity analysis, 211–212
neutral stakeholders, 30
NGT (nominal group technique), 95, 386
nominal group technique, 183–184
norming stage, Tuckman’s Ladder of Group Development, 93
objective tolerance, 255

opportunity, 233, 248, 386
strategy, 244–246, 251, 267–268
active acceptance, 245
enhancement, 245
escalation, 246
passive acceptance, 244
sharing, 246
organization
infrastructure, 33
capacity, 34
communication, 34
-level risk, 232
tolerance, 44–45
project risks, 289
risks in a project context, 289–290
rewards in risk-reward, 290–291
rewards to offset risks, 291
sources and drivers of risk, 290
tolerance
compliance, 254
policy, 254
-wide risk updates, 336, 337–338, 339–340
personnel/stakeholder, 336
project management culture, 340–341
quality, 336
outcome/s, 14, 164, 230, 299
intended, 306
unintended, 306
overall risk, 13, 160, 386
owner, risk, 31–32, 161, 250
P
passive acceptance, 244, 246, 387

performance. See also metrics
agile
data, 197
earned value metrics
actual costs, 199
performing stage, Tuckman’s Ladder of Group Development, 94
personal
commitment and involvement, 268–269
tolerance, 269–270
PERT (program evaluation review technique), 205–209, 387
PESTLE analysis, 32, 60–61, 387
physical triggers, 144–145
planned value, 387
planning
risk management, 57
stakeholder risk, 32
PMI® (Project Management Institute), 19
®
PMI-RMP® exam, 19
suggested plan for final review and study, 347–348
updates, 377
policy, tolerance, 254
portfolio
risk, 387
stakeholders, 33
power, 29, 31
precision, 283, 387. See also accuracy
predictive approach
action planning, 250
data gathering and reporting
qualitative, 329
quantitative, 330–331
preliminary data analysis, 118–119
priority, 13, 161, 214, 387
probability, 13, 58, 129, 157, 177, 387
dependent, 285
enhancement, 245
high, 284–285
-impact matrix, 178, 181
minimizing, 248
qualification, 177
problem solving, 46–47, 387
process/es
alignment, 57
risk, tools, 59–60
professional
commitment and involvement, 268–269
tolerance, 269–270
program
risk, 11, 387
stakeholders, 33
progressive elaboration, 155
project/s, 334–336
assumptions, 8, 387
charter, 8, 387
objective, 8
signature, 9
constraints, 27
influence, 286–288
management plan, 387
plans, 7, 387
risk
in an organizational context, 289
roles, 9
tolerance, 45, 133, 388
roles, 10
prompt list, 177
propinquity, 158, 388
proximity, 159, 388
pure risk, 131
qualitative
analysis, 58, 91
adaptive approach, 330
predictive approach, 329
quality risk, residual, 307
quantitative
analysis, 58, 92, 388
detailed, 209
Ishikawa diagram, 212
Monte Carlo simulation, 204–205, 287
adaptive approach, 331–332
predictive approach, 330–331
questions
follow-up, 164
risk, 111, 117–118
RACI (responsible, accountable, consult, inform) chart, 73–74, 254, 388

RAM (responsibility assignment matrix), 72–73, 389
ranking
approach efficacy, 284
group, 181
individual, 181
tools
consensus, 183
dot voting, 182
fist to five, 182
Roman voting, 183
stakeholder-based, 184
RBS (risk breakdown structure), 61, 74–75, 389
recipient, communication, 78
register
risk, 11–14, 77, 119–120, 151
categories, 156–164. See also categories, risk, register
review, 156
Risk ID, 157
updating, 155, 314–316
stakeholder, 28–29
relationships, risk, 118–119
reports and reporting, 77, 329
late, 314
qualitative data gathering
adaptive approach, 330
predictive approach, 329
quantitative data gathering
adaptive approach, 331–332
predictive approach, 330–331
rules, 100
workaround, 314, 316
repository, risk, 11
reputational risk, residual, 307–308
reserve
contingency, 130, 131
management, 129
residual risk, 248, 270, 388
financial, 307
quality, 307
reputational, 307–308
resilience, 286, 388
resistant stakeholders, 30
resolution
communication, 253
metrics, 251–253
personal/professional involvement, 268–269
response/s, 13, 244
communication, 253
contingent, 266, 381
deployed and underdeployed, 305
development, 59
-generated risk, 308. See also secondary risk
implementation, 59, 92, 261
intended outcomes, 306
opportunity strategy
enhancement, 245
escalation, 246
sharing, 246
secondary risk, 270–271
stakeholder, 267
opportunity strategy, 267–268
threat strategy, 268
stakeholder role, 92
avoidance, 247
escalation, 249
mitigation, 248
transfer, 248
type, 162–163
unintended consequences, 306
responsibility/ies
assignment matrix, 72
risk, 75
risk management, 11
retirement criteria, 389
review
implementation, 14, 163
qualitative, 179–181
risk register, 156
taxonomic, 176
rewards
to offset risk, 291
in risk-reward, 290–291
risk. See also response/s
absorption, 43–44, 389
acceptance, 308
accountability, 76, 389
alliance, 3, 61, 389
analysis, 57
qualitative, 58
quantitative, 58
appetite, 24, 379
archive, 11
area impacted, 13
assumptions, 26
attitude, 25
-based spike, 330, 390
breakdown structure, 74–75
business, 131
classification, 164–165
complexity, 226
connectivity, 159, 231–232, 381
constraints, 27
culture, 27–29
data processing, 33
detectability, 160
documentation, 6
customer agreements, 8
industry benchmarks, 6
lessons learned, 7
project assumptions, 8
project charter, 8–9
project plans, 7
dormancy, 159
drivers, 129
education and training, 80–81, 100–101
enterprise, 11
environment, 308–309
escalation, 13, 161
event, 12, 157
identification, 57, 91, 107, 111, 389
affinity diagram, 112–113
assumptions analysis, 115–116, 132–133
checklist analysis, 115
expert judgement, 117
mind mapping, 111–112
root cause analysis, 113–115
SWOT analysis, 116–117
impact, 158, 221, 309
high, 284, 285
strategic, 160
known-known, 129–130
known-unknown, 131
late reporting, 314
management, 239
management plan, 67–68
manager, 9–10, 389
matrix, 178
maturity, 25–26
monitoring and controlling, 92, 299
opportunity, 233
organizational, 232, 289–290
rewards in risk-reward, 290–291
rewards to offset risks, 291
sources and drivers of risk, 290
overall, 13, 160, 286–288
owner, 10, 13, 31–32, 161, 250, 389
planning, 32, 57
priority, 161, 214
probability, 157, 177
dependent, 285
high, 284–285
process, 389
alignment, 57
tools, 59–60
project, 288
propinquity, 158
proximity, 159
pure, 131
qualification, 91, 171, 179–181. See also ranking
quantification, 92, 191
questions, 111, 117–118
ranking
approach efficacy, 284
group, 181
register, 77, 119–120, 151, 389
categories, 156–164. See also categories, risk register
functionality, 155–156
review, 156
Risk ID, 157
updating, 155, 314–316
relationships, 118–119
reporting. See reporting
repository, 11, 390
residual, 248, 270, 299
financial, 307
quality, 307
reputational, 307–308
resolution, 239
communication, 253
metrics, 251–253
personal/professional involvement, 268–269
response
development, 59
implementation and control, 59
planning, 239
threat strategy, 246–249
responsibility, 11, 75–76, 390
-reward, 390
roles, 9
secondary, 270–271, 299, 308
CPAF (cost-plus award fee) contract, 311
CPFF (cost-plus fixed fee) contract, 311
CPIF (cost-plus incentive fee) contract, 310
CPPC (cost-plus percentage of cost) contract, 312–313
firm-fixed price contract, 309
FPEA (fixed-price economic adjustment) contract, 309–310
FPIF (fixed-price incentive fee) contract, 310
T&M (time and materials) contract, 311–313
sorting, 176
sources, 60–61, 390
statement, 107
strategic, 92
taxonomy, 176–177
team, roles and responsibilities, 10
threat, 233
threshold, 23–24, 45–46
tolerance, 23, 254, 309
compliance, 254
objective, 255
organizational, 44–45
personal/professional, 269–270
policy, 254
project, 45
updates, 341
trigger/s, 46
physical, 144–145
stakeholder-driven, 145
visible, 144
unknown-known, 130
unknown-unknown, 130–131
urgency, 158, 179
weight, 214
RMP (risk management plan), 39, 67–68, 91
color coding scheme, 178
FMEA (failure mode effect analysis), 179
impact, scale, 177–178
probability
definitions, 58
qualification, 177
qualitative analysis, 58
quantitative analysis, 58
RACI (responsible, accountable, consult, inform) chart, 73–74
RAM (responsibility assignment matrix), 72–73
RBS (risk breakdown structure), 74–75
risk accountability, 76
risk responsibility, 75–76
roles
project, 10
risk, 9
risk manager, 9–10
Roman voting, 183, 390
root cause analysis, 113–115, 212, 226, 390
rules, 23, 98
of compliance, 143–144
escalation, 99
information sharing, 100
reporting, 100
risk register update, 155
tolerance, 98
trigger, 99
salience model, 29, 390

schedule
implementation, 14, 163
performance index, 199, 390
variance, 199, 390
Scrum, daily, 79, 133, 382
secondary risk, 270–271, 299, 308
CPAF (cost-plus award fee) contract, 311
CPFF (cost-plus fixed fee) contract, 311
CPIF (cost-plus incentive fee) contract, 310
CPPC (cost-plus percentage of cost) contract, 312–313
firm-fixed price contract, 309
FPEA (fixed-price economic adjustment) contract, 309–310
FPIF (fixed-price incentive fee) contract, 310
T&M (time and materials) contract, 311–313
sender-receiver communications, 78
sensitivity analysis, 210, 391
Monte Carlo, 210–211
network diagram, 211–212
servant leadership, 61, 391
sharing, 246, 391
SMART (Specific, Measurable, Agreed-upon, Realistic, and Time limited), 8
smoothing, 47, 391
sorting, risk, 176
sources
data, 282–283
risk, 60–61
sprint, completion, 201
stakeholder
-based ranking support, 184
commitment, 29–30, 268–269
-driven trigger, 145, 391
education and training, 81
engagement matrix, 29–30, 391
involvement, 268–269
leading, 30
neutral, 30
portfolio, 33
program, 33
register, 27–29, 391
resistant, 30
response, 267
risk education, 100–101
risk planning, 32
risk process, roles, 91–92
strategic risk and, 92
supportive, 30
tolerance, 30–31
unaware, 30
updates, 336
standard deviation, PERT, 206–209
statement
IF/THEN, 157
risk, 107
storming stage, Tuckman’s Ladder of Group Development, 93
strategy, 53, 162–163. See also response
opportunity, 244–246, 251, 267–268
enhancement, 245
escalation, 246
sharing, 246
threat, 233, 246, 251, 268
avoidance, 247
escalation, 249
mitigation, 248
transfer, 248
supportive stakeholders, 30
SWOT analysis, 26, 116–117, 226–227, 391
system life cycle, 391
T
T&M (time and materials) contract, secondary risks, 311–313

tacit knowledge, 23, 80, 391
Taleb, N., Anti-Fragile: Things That Gain from Disorder, 286
taxonomy, risk, 176–177
team
charter, 47–48, 392
-driven data gathering techniques
brainstorming, 94–95
Delphi technique, 96
focus groups, 95
interviews, 96
meetings, 96–97
nominal group technique, 95
education and training, 81
engagement, 93
escalation rules, 99
information sharing rules, 100
reporting rules, 100
rules of, 98
tolerance rules, 98
trigger rules, 99
threat, 233, 392
strategy, 246, 251, 268
avoidance, 247
escalation, 249
mitigation, 248
transfer, 248
threshold, 23–24, 45–46, 143, 144, 392. See also tolerance
timing
communication, 78
risk qualification, 179–181
tolerance, 23, 254, 309, 392
compliance, 254
-driven triggers, 144
objective, 255
personal/professional, 269–270
policy, 254
risk, 133
organizational, 44–45
project, 45
rules, 98
updates, 341
tools. See also analysis
ranking
consensus, 183
dot voting, 182
fist to five, 182
Roman voting, 183
stakeholder-based, 184
risk process, 59–60
stakeholder engagement matrix, 29–30
tornado diagram, 211
training. See education and training
transfer, 248, 392
tree diagram, 227–228. See also decision tree
trigger/s, 46, 139. See also threshold
physical, 144–145
rules, 99
stakeholder-driven, 145
threshold-driven, 144
visible, 144
Ts&Cs (terms and conditions), 8
Tuckman’s Ladder of Group Development, 392
adjourning stage, 94
forming stage, 93
norming stage, 93
performing stage, 94
storming stage, 93
unaware stakeholders, 30
unintended consequences, 306, 392
unknown-known, 130, 392
unknown-unknown, 130–131, 392
updates
change log, 333–334
lessons learned, 333
management plan, 332
organization-wide, 336, 337–338, 339–340
personnel/stakeholder, 336
project management culture, 340–341
quality, 336
PMI-RMP® exam, 377
project-wide, 334–336
risk register, 155, 314–316
urgency, 158, 179, 392
user story, completion, 202
value
earned, 198
expected monetary, 209–210
planned, 198
variance
cost, 199
schedule, 199
vendors, education and training, 81
virtual meetings, 97
visible triggers, 144
voting
dot, 182
Roman, 183
waterfall management, 197

weight, risk, 214
withdrawal, 47, 392
workaround, 314, 316, 392
X-Y-Z
Y2K bug, 334

Appendix C
Study Planner
Practice Test Reading Task
Element Task Goal First Date Second Date Notes

Date Completed Completed
(Optional)
Introduction Read Introduction
1. The Risk Read Foundation Topics
Structure
1. The Risk Review Key Topics
Structure
1. The Risk Define Key Terms
Structure
1. The Risk Complete Review Questions section
Structure
Practice Test Take practice test in study mode using
Exam Bank 1 questions for Chapter 1 in
practice test software
2. Risk Read Foundation Topics
Environment and
Culture
2. Risk Review Key Topics
Environment and
Culture
2. Risk Define Key Terms
Environment and
Culture
2. Risk Complete Review Questions section
Environment and
Culture
3. Tolerance, Read Foundation Topics
Thresholds, and
Triggers
3. Tolerance, Review Key Topics
Thresholds, and
Triggers
3. Tolerance, Define Key Terms
Thresholds, and
Triggers
3. Tolerance, Complete Review Questions section
Thresholds, and
Triggers
4. Strategic Risk Read Foundation Topics
4. Strategic Risk Review Key Topics
4. Strategic Risk Define Key Terms
4. Strategic Risk Complete Review Questions section
Management Plan
(RMP)
Management Plan
(RMP)
Management Plan
(RMP)
Management Plan
(RMP)
6. Connecting Read Foundation Topics
Others in Risk
6. Connecting Review Key Topics
Others in Risk
6. Connecting Define Key Terms
Others in Risk
6. Connecting Complete Review Questions section
Others in Risk
7. Practical, Team- Read Foundation Topics
Based Risk
Identification
7. Practical, Team- Review Key Topics
Based Risk
Identification
7. Practical, Team- Define Key Terms
Based Risk
Identification
7. Practical, Team- Complete Review Questions section
Based Risk
Identification
8. Constraints and Read Foundation Topics
Assumptions
8. Constraints and Review Key Topics
Assumptions
8. Constraints and Define Key Terms
Assumptions
8. Constraints and Complete Review Questions section
Assumptions
9. Applying Read Foundation Topics
Triggers and
Thresholds
9. Applying Review Key Topics
Triggers and
Thresholds
9. Applying Define Key Terms
Triggers and
Thresholds
9. Applying Complete Review Questions section
Triggers and
Thresholds

Register
Register
Register
Register
Exam Bank 1 questions for Chapter 10
in practice test software
Qualification
Qualification
Qualification
Qualification
Quantification
Quantification
Quantification
Quantification
Complexity,
Assessment, and
Analysis
Complexity,
Assessment, and
Analysis
Complexity,
Assessment, and
Analysis
Complexity,
Assessment, and
Analysis
14. Response
Planning
14. Response Review Key Topics
Planning
14. Response Define Key Terms
Planning
14. Response Complete Review Questions section
Planning
15. Response Read Foundation Topics
Implementation
15. Response Review Key Topics
Implementation
15. Response Define Key Terms
Implementation
15. Response Complete Review Questions section
Implementation
16. Data Collection Read Foundation Topics
16. Data Collection Review Key Topics
16. Data Collection Define Key Terms
16. Data Collection Complete Review Questions section
17. The Leftovers Read Foundation Topics
and the Latecomers
17. The Leftovers Review Key Topics
and the Latecomers
17. The Leftovers Define Key Terms
and the Latecomers
17. The Leftovers Complete Review Questions section
and the Latecomers

18. Sharing Risk Read Foundation Topics
Information
18. Sharing Risk Review Key Topics
Information
18. Sharing Risk Define Key Terms
Information
18. Sharing Risk Complete Review Questions section
Information
19. Final
Preparation
19. Final Take practice test in study mode for all
Preparation book questions in practice test software
19. Final Review all Key Topics in all chapters
Preparation
19. Final Take practice test in practice exam
Preparation mode using Exam Bank #1 questions
for all chapters
19. Final Take practice test in practice exam
Preparation mode using Exam Bank #2 questions
for all chapters
Risk Management
Professional
(PMI-RMP)®
Cert Guide
ISBN: 978-0-13-810847-2
See inside ▸▸▸
for your Pearson Test Prep activation code and special offers
Complete Video Course
To enhance your preparation, Pearson IT Certification also sells Complete Video Courses for
both streaming and download. Complete Video Courses provide you with hours of expert-level
instruction mapped directly to exam objectives.
Special Offer–Save 70%
This single-use coupon code will allow you to purchase a Complete Video Course at a 70%
discount. Simply go to the product URL below, add the Complete Video Course to your cart,
and apply the coupon code at checkout.
www.pearsonITcertification.com/videostore
Coupon Code:
Risk Management
Professional (PMI-RMP)®
Cert Guide
Premium Edition eBook and Practice Test
To enhance your preparation, Pearson IT Certification also sells a digital Premium Edition of this
book. The Premium Edition provides PDF and EPUB files, as well as an enhanced edition of the
Pearson Test Prep practice test software. The Premium Edition includes two additional practice
exams with links for every question mapped to the PDF eBook.
Special Offer–Save 80%
This single-use coupon code will allow you to purchase a copy of the Premium Edition at an
80% discount. Simply go to the URL below, add the Premium Edition to your cart, and apply
the coupon code at checkout.
www.pearsonITcertification.com/title/9780138108304
Coupon Code:
DO NOT DISCARD THIS NUMBER
You will need this activation code to activate your practice test in the Pearson Test Prep practice
test software.
To access the online version, go to www.PearsonTestPrep.com. Select Pearson IT

Certification as your product group. Enter your email/password for your account. If you don’t
have an account on PearsonITCertification.com or CiscoPress.com, you will need to establish
one by going to PearsonITCertification.com/join. In the My Products tab, click the Activate New
Product button. Enter the access code printed on this insert card to activate your product. The
product will now be listed in your My Products page.
If you wish to use the Windows desktop offline version of the application, simply register your
book at www.pearsonITcertification.com/register, select the Registered Products tab on your
account page, click the Access Bonus Content link, and download and install the software from
the companion website.
This activation code can be used to register your exam in both the online and the offline versions.
Activation Code:
Where are the companion content files?
Register this digital version of Risk Management Professional (PMI-RMP)® Cert Guide to
access important downloads.
Register this eBook to unlock the companion files. Follow these steps:
1. Go to pearsonITcertification.com/account and log in or create a new account.

2. Enter the ISBN: 9780138108472 (NOTE: Please enter the print book ISBN provided to
register the eBook you purchased.)
3. Answer the challenge question as proof of purchase.
4. Click on the “Access Bonus Content” link in the Registered Products section of your account
page, to be taken to the page where your downloadable content is available.
This eBook version of the print title does not contain the practice test software that accompanies
the print book.
You May Also Like—Premium Edition eBook and Practice Test. To learn about the Premium
Edition eBook and Practice Test series, visit pearsonITcertification.com/practicetest
The Professional and Personal Technology Brands of Pearson

Special Offer
Save 80% on Premium Edition eBook and Practice Test
The Risk Management Professional (PMI-RMP)® Cert Guide Premium Edition eBook and
Practice Test provides PDF and EPUB files to read on your preferred device and an enhanced
edition of the Pearson Test Prep practice test software. You also receive two additional practice
exams with links for every question mapped to the PDF eBook.
See the card insert in the back of the book for your Pearson Test Prep activation code and
special offers.
Risk Management
Professional (PMI-RMP)®
Cert Guide
Companion Website
Access interactive study tools on this book’s companion website, including practice test
software, a Key Term flash card application, study planner, and more!
To access the companion website, simply follow these steps:
1. Go to www.pearsonITcertification.com/register.
2. Enter the print book ISBN: 9780138108472.
3. Answer the security question to validate your purchase.
4. Go to your account page.
5. Click on the Registered Products tab.
6. Under the book listing, click on the Access Bonus Content link.
If you have any issues accessing the companion website, you can contact our support team by
going to http://pearsonitp.echelp.org.

Risk Management Professional PMI RMP® Certification Guide Carl Pritchard ChidoLib 4zbqb2

Uploaded by

Copyright:

Available Formats

You might also like

Risk Management Professional PMI RMP® Certification Guide Carl Pritchard ChidoLib 4zbqb2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Risk Management Professional PMI RMP® Certification Guide Carl Pritchard ChidoLib 4zbqb2

Uploaded by

Copyright:

Available Formats

About This eBook

Copyright © 2023 by Pearson Education, Inc.

Library of Congress Control Number: 2023930987

Cover credit: Andrii Yalanskyi/Shutterstock

Warning and Disclaimer

For government sales inquiries, please contact governmentsales@pearsoned.com.

Vice President, IT Professional

Product Line Manager

Senior Project Editor

Our ambition is to purposefully contribute to a world where

Everyone has an equitable and lifelong opportunity to succeed through learning

Please contact us with concerns about any potential bias at https://www.pearson.com/report-

Professor Susan Parente is a principal consultant at S3 Technologies, LLC, the project

Register your copy of Risk Management Professional (PMI-RMP)® Cert Guide at

Goals and Methods

Who Should Read This Book?

PMI-RMP® Exam Topics

Table I-1 PMI-RMP® Exam Domains

Risk Strategy and Planning 22%

Risk Identification 23%

Risk Analysis 23%

Risk Response 13%

Table I-2 PMI-RMP® Exam Domains, Tasks, and Chapter Mapping

Domain I: Risk Strategy and Planning

1 Perform a preliminary document analysis 1

2 Assess project environment for threats and opportunities 2

3 Confirm risk threshold based on risk appetites 3

4 Establish risk management strategy 4

5 Document the risk management plan 5

6 Plan and lead risk management activities with stakeholders 6

Domain II: Risk Identification

2 Examine assumption and constraint analyses 8

3 Document risk triggers and thresholds based on context/environment 9

4 Develop risk register 10

Domain III: Risk Analysis

1 Perform qualitative analysis 11

2 Perform quantitative analysis 12

3 Identify threats and opportunities 13

Domain IV: Risk Response

1 Plan risk response 14

2 Implement risk response 15

Domain V: Monitor and Close Risks

1 Gather and analyze performance data 16

3 Provide information required to update relevant project documents 18

4 Monitor project risk levels 18

To access this companion website, follow these steps:

Go to www.pearsonitcertification.com/register and log in or create a new account.

Enter this book’s ISBN (9780138108472).

Answer the challenge question as proof of book ownership.

Pearson Test Prep Practice Test Software

Accessing the Pearson Test Prep Software Online

Go to www.PearsonTestPrep.com and select Pearson IT Certification as your product group.

Accessing the Pearson Test Prep Software Offline

Register your book by going to http://www.pearsonitcertification.com/register and entering the

Respond to the challenge questions.

Go to your account page and select the Registered Products tab.

Customizing Your Exams

Updating Your Exams