Risk Management Professional (PMI-RMP)® (Certification Guide) 9780138108472, 0138108471

Table of contents :
Cover Page
About This eBook
Title Page
Copyright Page
Pearson’s Commitment to Diversity, Equity, and Inclusion
Contents at a Glance
Table of Contents
About the Author
Dedication
Acknowledgments
About the Technical Reviewer
We Want to Hear from You!
Reader Services
Introduction
Goals and Methods
Who Should Read This Book?
PMI-RMP® Exam Topics
Companion Website
Pearson Test Prep Practice Test Software
Premium Edition eBook and Practice Tests
Part I: Strategic Risk and Risk Planning
Chapter 1. The Risk Structure
“Do I Know This Already?” Quiz
Foundation Topics
Risk Documentation Capture
Risk Roles and Responsibilities
The Risk Archive
Exam Preparation Tasks
Review All the Key Topics
Key Terms You Should Know
Review Questions
Chapter 2. Risk Environment and Culture
“Do I Know This Already?” Quiz
Foundation Topics
Risk Attitude, Appetite, and Maturity
Risk Assumptions
Constraint-Driven Risks
Stakeholders and Risk Culture
Organizational Infrastructure
Exam Preparation Tasks
Review All the Key Topics
Key Terms You Should Know
Review Questions
Chapter 3. Tolerance, Thresholds, and Triggers
“Do I Know This Already?” Quiz
Foundation Topics
Risk Absorption
Organizational and Project Risk Tolerance
Recognizing and Resolving Cultural Discord
Exam Preparation Tasks
Review All the Key Topics
Key Terms You Should Know
Review Questions
Chapter 4. Strategic Risk
“Do I Know This Already?” Quiz
Foundation Topics
Risk Process Alignment
Risk Process Tools
Risk Sources and Their Roles
Risk Alliances
Exam Preparation Tasks
Review All the Key Topics
Key Terms You Should Know
Review Questions
Chapter 5. The Risk Management Plan (RMP)
“Do I Know This Already?” Quiz
Foundation Topics
The Three R’s: RAM, RACI, and RBS
Risk Responsibility and Accountability
Risk Communication Documentation
Risk Education and Training
Exam Preparation Tasks
Review All the Key Topics
Key Terms You Should Know
Review Questions
Chapter 6. Connecting Others in Risk
“Do I Know This Already?” Quiz
Foundation Topics
Stakeholders and Their Roles
Team Engagement in Appetites, Attitudes, and Priorities
Rules of Engagement
Risk Education Beyond the Strategic
Exam Preparation Tasks
Review All the Key Topics
Key Terms You Should Know
Review Questions
Part II: Risk Identification
Chapter 7. Practical, Team-Based Risk Identification
“Do I Know This Already?” Quiz
Foundation Topics
Identification Approaches
Preliminary Data Analysis
The Risk Register
Exam Preparation Tasks
Review All the Key Topics
Key Terms You Should Know
Review Questions
Chapter 8. Constraints and Assumptions
“Do I Know This Already?” Quiz
Foundation Topics
Constraints as Risk Drivers
Assumptions as Identified Risks
The Open Assumptions and Constraints Discussion
Exam Preparation Tasks
Review All the Key Topics
Key Terms You Should Know
Review Questions
Chapter 9. Applying Triggers and Thresholds
“Do I Know This Already?” Quiz
Foundation Topics
Compliance and the Implications of Tolerance
Tolerance- and Threshold-Driven Triggers
Stakeholder-Driven Triggers
Exam Preparation Tasks
Review All the Key Topics
Key Terms You Should Know
Review Questions
Chapter 10. The Risk Register
“Do I Know This Already?” Quiz
Foundation Topics
Register Functionality
Register Categories
Risk Classification
Exam Preparation Tasks
Review All the Key Topics
Key Terms You Should Know
Review Questions
Part III: Risk Analytics
Chapter 11. Risk Qualification
“Do I Know This Already?” Quiz
Foundation Topics
Risk Sorting
Taxonomic Review
Risk Management Plan Application
Risk Ranking
Stakeholder-Based Ranking Support
Exam Preparation Tasks
Review All the Key Topics
Key Terms You Should Know
Review Questions
Chapter 12. Risk Quantification
“Do I Know This Already?” Quiz
Foundation Topics
Performance Data and Its Implications
General Versus Detailed Quantitative Analysis
Sensitivity Analysis Tools
Relative Risk Weight and Priority
Exam Preparation Tasks
Review All the Key Topics
Key Terms You Should Know
Review Questions
Chapter 13. Risk Complexity, Assessment, and Analysis
“Do I Know This Already?” Quiz
Foundation Topics
Risk Complexity
Risk Interconnectedness
Risk at the Organizational Level
Threat Versus Opportunity
Exam Preparation Tasks
Review All the Key Topics
Key Terms You Should Know
Review Questions
Part IV: Risk Management and Resolution
Chapter 14. Response Planning
“Do I Know This Already?” Quiz
Foundation Topics
Opportunity Versus Threat Strategies
Action Plans and Risk Owners
Resolution Metrics and Communication
Organizational Impacts
Exam Preparation Tasks
Review All the Key Topics
Key Terms You Should Know
Review Questions
Chapter 15. Response Implementation
“Do I Know This Already?” Quiz
Foundation Topics
Response Plans Versus Contingencies
Stakeholder Response Reactions
Residual Risk and Its Implications
Secondary Risk and Its Implications
Exam Preparation Tasks
Review All the Key Topics
Key Terms You Should Know
Review Questions
Part V: Tracking and Closing Out Risks
Chapter 16. Data Collection
“Do I Know This Already?” Quiz
Foundation Topics
Gathering Information
Ranking Approach Efficacy
Contrasting Project and Organizational Risk
Exam Preparation Tasks
Review All the Key Topics
Key Terms You Should Know
Review Questions
Chapter 17. The Leftovers and the Latecomers
“Do I Know This Already?” Quiz
Foundation Topics
Residuals and Deductibles
Response-Generated Risks
Late Risk Reporting
Exam Preparation Tasks
Review All the Key Topics
Key Terms You Should Know
Review Questions
Chapter 18. Sharing Risk Information
“Do I Know This Already?” Quiz
Foundation Topics
Risk Reporting
Related Document Updates
Project-wide Risk Updates
Organization-wide Risk Updates
Exam Preparation Tasks
Review All the Key Topics
Key Terms You Should Know
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
Glossary of Key Terms
Index
Appendix C. Study Planner
Access Card
Where are the companion content files? - Register
Inside Front Cover
Inside Back Cover

Citation preview

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 [email protected] or (800) 382-3419. For government sales inquiries, please contact [email protected]. For questions about sales outside the U.S., please contact [email protected]. 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/reportbias.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 “Do I Know This Already?” Quiz 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 Exam Preparation Tasks Review All the Key Topics Key Terms You Should Know Review Questions Chapter 3 Tolerance, Thresholds, and Triggers “Do I Know This Already?” Quiz Foundation Topics Risk Absorption Organizational and Project Risk Tolerance Organizational Risk Tolerance

Project Risk Tolerance Thresholds Triggers Recognizing and Resolving Cultural Discord Exam Preparation Tasks Review All the Key Topics Key Terms You Should Know Review Questions Chapter 4 Strategic Risk “Do I Know This Already?” Quiz 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 Exam Preparation Tasks Review All the Key Topics Key Terms You Should Know Review Questions Chapter 5 The Risk Management Plan (RMP) “Do I Know This Already?” Quiz 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 Exam Preparation Tasks Review All the Key Topics Key Terms You Should Know Review Questions Chapter 6 Connecting Others in Risk “Do I Know This Already?” Quiz 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 Exam Preparation Tasks Review All the Key Topics Key Terms You Should Know Review Questions Part II: Risk Identification Chapter 7 Practical, Team-Based Risk Identification “Do I Know This Already?” Quiz 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

Exam Preparation Tasks Review All the Key Topics Key Terms You Should Know Review Questions Chapter 8 Constraints and Assumptions “Do I Know This Already?” Quiz 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 Exam Preparation Tasks Review All the Key Topics Key Terms You Should Know Review Questions Chapter 9 Applying Triggers and Thresholds “Do I Know This Already?” Quiz Foundation Topics Compliance and the Implications of Tolerance Tolerance- and Threshold-Driven Triggers Visible Triggers Physical Triggers Stakeholder-Driven Triggers Exam Preparation Tasks

Review All the Key Topics Key Terms You Should Know Review Questions Chapter 10 The Risk Register “Do I Know This Already?” Quiz 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 Exam Preparation Tasks Review All the Key Topics Key Terms You Should Know Review Questions Part III: Risk Analytics Chapter 11 Risk Qualification “Do I Know This Already?” Quiz 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 Nominal Group Technique Stakeholder-Based Ranking Support Exam Preparation Tasks Review All the Key Topics Key Terms You Should Know Review Questions Chapter 12 Risk Quantification “Do I Know This Already?” Quiz

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 Exam Preparation Tasks Review All the Key Topics Key Terms You Should Know Review Questions Chapter 13 Risk Complexity, Assessment, and Analysis

“Do I Know This Already?” Quiz 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 Exam Preparation Tasks Review All the Key Topics Key Terms You Should Know Review Questions Part IV: Risk Management and Resolution Chapter 14 Response Planning “Do I Know This Already?” Quiz 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 Exam Preparation Tasks Review All the Key Topics Key Terms You Should Know Review Questions Chapter 15 Response Implementation “Do I Know This Already?” Quiz 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

Exam Preparation Tasks Review All the Key Topics Key Terms You Should Know Review Questions Part V: Tracking and Closing Out Risks Chapter 16 Data Collection “Do I Know This Already?” Quiz 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 Exam Preparation Tasks Review All the Key Topics Key Terms You Should Know Review Questions Chapter 17 The Leftovers and the Latecomers “Do I Know This Already?” Quiz 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 Exam Preparation Tasks Review All the Key Topics Key Terms You Should Know Review Questions Chapter 18 Sharing Risk Information “Do I Know This Already?” Quiz 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 Exam Preparation Tasks Review All the Key Topics Key Terms You Should Know 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 Glossary of Key Terms 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: [email protected]

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 (PMIRMP)® 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: Risk Documentation Capture Risk Roles and Responsibilities 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

“Do I Know This Already?” Quiz 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 selfassessment. 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 Risk Documentation Capture

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.

Risk Roles and Responsibilities 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

Event

Overall

Priority

Risk

Risk

Area

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

Table 1-3 Risk Register (Section 2)

Area

Escalation

Impacted

Response

Response

Implementation

Implementation

Strategy

Strategy

Schedule

Review

Strategy Timing

Date

Narrative

Department

Name and

Avoidance,

Strategy

or project

Contact

Acceptance

described

component

Information

(active/passive),

or work

Mitigation,

package/user

Transfer, or

story

Escalation

Table 1-4 Risk Register (Section 3)

Retirement Criteria

Follow-

Outcome

Archive

Result of

Date and

action/inaction

location

up

Narrative of when/how the risk might be retired

Date

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.

Exam Preparation Tasks 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 All the Key Topics 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

Key Terms You Should Know 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? 1. The project manager 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 This chapter covers the following topics: Risk Attitude, Appetite, and Maturity Risk Assumptions Constraint-Driven Risks Stakeholders and Risk Culture Organizational Infrastructure 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

“Do I Know This Already?” Quiz The “Do I Know This Already?” quiz enables 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 2-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 2-1 “Do I Know This Already?” Section-to-Question Mapping

Foundation Topics Section

Questions

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 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 selfassessment. Giving yourself credit for an answer you correctly guess skews your self-assessment results and might provide you with a false sense of security.

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 Risk Attitude, Appetite, and Maturity 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 proves false, 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.

Constraint-Driven Risks 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 noncompliant. Theoretically (and for the exam), non-compliant projects cannot be implemented.

Stakeholders and Risk Culture 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

Name

Information

Title

Role on the

Key

Engagement

Project

Expectations

Level (Current and Desired)

Don Diehl

301-606-

VP

6519 (cell)

Vendor

We’ll use

Supportive

representative

their product

(c)

throughout.

Supportive (d)

Mary

301-482-

End

Holliday

4519

user

Beta tester

The system

Supportive

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 highhigh 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.

Organizational Infrastructure 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.

Exam Preparation Tasks

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 2-3 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 2-3 Chapter Review Tracking

Review Element

Review Date(s)

Resource Used

Review Key Topics

Book, Website

Review Key Terms

Book, Website

Answer DIKTA Questions

Book

Review Practice Questions

Book, Website

Rewrite/Document Chapter Headings

Book

Review All the Key Topics Review the most important topics in this chapter, noted with the Key Topic icon in the margin of the page. Table 2-4 lists a reference of these key topics and the page numbers on which each is found.

Table 2-4 Key Topics for Chapter 2

Key Topic

Description

Page

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

Elements

Key Terms You Should Know Define the following key terms from this chapter and check your answers in the glossary: tolerance threshold appetite attitude maturity assumptions constraints stakeholder register

32

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 Organizational and Project Risk Tolerance 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:

Domain

Task #

Exam Objective

Risk Strategy and Planning

Task 3

Confirm risk thresholds based on risk appetites

“Do I Know This Already?” Quiz The “Do I Know This Already?” quiz enables 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 3-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 3-1 “Do I Know This Already?” Section-to-Question Mapping

Foundation Topics Section

Questions

Risk Absorption

1

Organizational and Project Risk Tolerance

2–5

Recognizing and Resolving Cultural Discord

6

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 selfassessment. Giving yourself credit for an answer you correctly guess skews your self-assessment results and might provide you with a false sense of security.

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 hotbutton 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

Comprehensive Insurance

Policy A

Policy B

Policy C

Not offered

Offered with a

Offered with a

$250 USD

$500 USD

deductible

deductible

(for non-driving coverage)

Collision and Liability

Covered up

Covered up to

Covered up to

Coverage

to

$500,000

$20,000,000

$100

$1,000

$1,000,000

Collision and Liability

$400

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.

Organizational and Project Risk Tolerance

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.

Exam Preparation Tasks 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 3-3 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 3-3 Chapter Review Tracking

Review Element

Review Date(s)

Resource Used

Review Key Topics

Book, Website

Review Key Terms

Book, Website

Answer DIKTA Questions

Book

Review Practice Questions

Book, Website

Rewrite/Document Chapter Headings

Book

Review All the Key Topics Review the most important topics in this chapter, noted with the Key Topic icon in the margin of the page. Table 3-4 lists a reference of these key topics and the page numbers on which each is found.

Table 3-4 Key Topics for Chapter 3

Key Topic Elements

Description

Page

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

Key Terms You Should Know Define the following key terms from this chapter and check your answers in the glossary: risk absorption organizational tolerance project tolerance thresholds triggers problem-solving (confrontation) collaboration

47

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 This chapter covers the following subjects: Risk Process Alignment Risk Process Tools Risk Sources and Their Roles 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. This chapter addresses the following objectives from the PMI-RMP® Exam Content Outline:

Domain

Task

Exam Objective

#

Risk Strategy and

Task

Establish Risk Management Strategy in the

Planning

4

Introduction

“Do I Know This Already?” Quiz The “Do I Know This Already?” quiz enables 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 4-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 4-1 “Do I Know This Already?” Section-to-Question Mapping

Foundation Topics Section

Questions

Risk Process Alignment

1, 2

Risk Process Tools

3, 4

Risk Sources and Their Roles

5, 6

Risk Alliances

7, 8

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 selfassessment. Giving yourself credit for an answer you correctly guess skews your self-assessment results and might provide you with a false sense of security.

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 Risk Process Alignment

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 timeconsuming. 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.

Risk Sources and Their Roles

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, projectspecific, 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.

Exam Preparation Tasks 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 4-4 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 4-4 Chapter Review Tracking

Review Element

Review Date(s)

Resource Used

Review Key Topics

Book, Website

Review Key Terms

Book, Website

Answer DIKTA Questions

Book

Review Practice Questions

Book, Website

Rewrite/Document Chapter Headings

Book

Review All the Key Topics Review the most important topics in this chapter, noted with the Key Topic icon in the margin of the page. Table 4-5 lists a reference of these key topics and the page numbers on which each is found.

Table 4-5 Key Topics for Chapter 4

Key Topic Element

Description

Page Number

Section

Risk Process Alignment

57

Section

Risk Process Tools

59

Section

Risk Sources and Their Roles

60

Section

Risk Alliances

61

Key Terms You Should Know Define the following key terms from this chapter and check your answers in the glossary: 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) This chapter covers the following topics: The Three R’s: RAM, RACI, and RBS Risk Responsibility and Accountability Risk Communication Documentation Risk Education and Training 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. This chapter addresses the following objectives from the PMI-RMP® Exam Content Outline:

Domain

Task #

Exam Objective

Risk Strategy and Planning

Task 5

Document the Risk Management Plan

“Do I Know This Already?” Quiz 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 5-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 5-1 “Do I Know This Already?” Section-to-Question Mapping

Foundation Topics Section

Questions

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 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 selfassessment. Giving yourself credit for an answer you correctly guess skews your self-assessment results and might provide you with a false sense of security.

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 Three R’s: RAM, RACI, and RBS 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

Data Capture

Martine

Executive

Project

Product

Sponsor

Manager

Owner

X

X

Archiving

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

Risk Responsibility and Accountability 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 55.

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 Communication Documentation

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.

Risk Education and Training

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.

Exam Preparation Tasks 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 5-6 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 5-6 Chapter Review Tracking

Review Element

Review Date(s)

Resource Used

Review Key Topics

Book, Website

Review Key Terms

Book, Website

Answer DIKTA Questions

Book

Review Practice Questions

Book, Website

Rewrite/Document Chapter Headings

Book

Review All the Key Topics Review the most important topics in this chapter, noted with the Key Topic icon in the margin of the page. Table 5-7 lists the key topics and the page numbers on which each is found.

Table 5-7 Key Topics for Chapter 5

Key Topic Element

Description

Page Number

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

Key Terms You Should Know Define the following key terms from this chapter and check your answers in the glossary: 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 This chapter covers the following subjects: Stakeholders and Their Roles Team Engagement in Appetites, Attitudes, and Priorities Rules of Engagement Risk Education Beyond the Strategic 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. This chapter addresses the following objectives from the PMI-RMP® Exam Content Outline:

Domain

Task

Exam Objective

#

Risk Strategy and

Task

Plan and Lead Risk Management Activities with

Planning

6

Stakeholders

“Do I Know This Already?” Quiz

The “Do I Know This Already?” quiz enables 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 6-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 6-1 “Do I Know This Already?” Section-to-Question Mapping

Foundation Topics Section

Questions

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 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 selfassessment. Giving yourself credit for an answer you correctly guess skews your self-assessment results and might provide you with a false sense of security.

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 3. The project manager 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 Stakeholders and Their Roles

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 lowprobability, 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-theheadlights” 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.

Team Engagement in Appetites, Attitudes, and Priorities 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. Nominal Group Technique 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. Openended 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 offagenda 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.

Risk Education Beyond the Strategic 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.

Exam Preparation Tasks One key to doing well on the exam 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 6-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.

Table 6-2 Chapter Review Tracking

Review Element

Review Date(s)

Resource Used

Review Key Topics

Book, Website

Review Key Terms

Book, Website

Answer DIKTA Questions

Book

Review Practice Questions

Book, Website

Rewrite/Document Chapter Headings

Book

Review All the Key Topics Review the most important topics in this chapter, noted with the Key Topic icon in the margin of the page. Table 6-3 lists a reference of these key topics and the page numbers on which each is found.

Table 6-3 Key Topics for Chapter 6

Key

Description

Topic

Page 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

Key Terms You Should Know Define the following key terms from this chapter and check your answers in the glossary: 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 This chapter covers the following subjects: Identification Approaches Preliminary Data Analysis 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. This chapter addresses the following objectives from the PMI-RMP® Exam Content Outline:

Domain

Task #

Exam Objective

Risk Identification

Task 1

Conduct Risk Identification Exercises

“Do I Know This Already?” Quiz 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 7-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 7-1 “Do I Know This Already?” Section-to-Question Mapping

Foundation Topics Section

Questions

Identification Approaches

2, 6

Preliminary Data Analysis

3, 5

The Risk Register

1, 4

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 selfassessment. Giving yourself credit for an answer you correctly guess skews your self-assessment results and might provide you with a false sense of security.

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? 1. The risk register 2. The risk breakdown structure 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 Identification Approaches

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 75 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.

Preliminary Data Analysis 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.

Exam Preparation Tasks 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 7-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.

Table 7-2 Chapter Review Tracking

Review Element

Review Date(s)

Resource Used

Review Key Topics

Book, Website

Review Key Terms

Book, Website

Answer DIKTA Questions

Book

Review Practice Questions

Book, Website

Rewrite/Document Chapter Headings

Book

Review All the Key Topics Review the most important topics in this chapter, noted with the Key Topic icon in the margin of the page. Table 7-3 lists a reference of these key topics and the page numbers on which each is found.

Table 7-3 Key Topics for Chapter 7

Key Topic Element

Description

Page Number

Section

Identification Approaches

111

Section

Root Cause Analysis

113

Section

SWOT Analysis

116

Section

The Risk Register

119

Key Terms You Should Know Define the following key terms from this chapter and check your answers in the glossary: 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 3. The risk register 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 This chapter covers the following subjects: Constraints as Risk Drivers Assumptions as Identified Risks The Open Assumptions and Constraints Discussion 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. This chapter addresses the following objectives from the PMI-RMP® Exam Content Outline:

Domain

Task #

Exam Objective

Risk Identification

Task 2

Examine Assumption and Constraint Analyses

“Do I Know This Already?” Quiz The “Do I Know This Already?” quiz enables 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 8-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 8-1 “Do I Know This Already?” Section-to-Question Mapping

Foundation Topics Section

Questions

Constraints as Risk Drivers

2, 3

Assumptions as Identified Risks

1, 6

The Open Assumptions and Constraints Discussion

4, 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 selfassessment. Giving yourself credit for an answer you correctly guess skews your self-assessment results and might provide you with a false sense of security.

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 Constraints as Risk Drivers

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.

Assumptions as Identified Risks

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.

The Open Assumptions and Constraints Discussion

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.

Exam Preparation Tasks 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 8-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.

Table 8-2 Chapter Review Tracking

Review Element

Review Date(s)

Resource Used

Review Key Topics

Book, Website

Review Key Terms

Book, Website

Answer DIKTA Questions

Book

Review Practice Questions

Book, Website

Rewrite/Document Chapter Headings

Book

Review All the Key Topics Review the most important topics in this chapter, noted with the Key Topic icon in the margin of the page. Table 8-3 lists a reference of these key topics and the page numbers on which each is found.

Table 8-3 Key Topics for Chapter 8

Key Topic

Description

Element

Page 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

Key Terms You Should Know

Define the following key terms from this chapter and check your answers in the glossary: 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 Which of the following statements is true? 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. 3. $7,900,000 is the threshold and $8,000,000 is the tolerance. 4. $8,000,000 is the threshold and $8,300,000 is the tolerance.

5. $8,000,000 is the threshold and $8,000,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 This chapter covers the following subjects: Compliance and the Implications of Tolerance Tolerance- and Threshold-Driven Triggers Stakeholder-Driven Triggers 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. This chapter addresses the following objectives from the PMI-RMP® Exam Content Outline:

Domain

Task

Exam Objective

#

Risk

Task

Document Risk Triggers and Thresholds Based on

Identification

3

Context/Environment

“Do I Know This Already?” Quiz The “Do I Know This Already?” quiz enables 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 9-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 9-1 “Do I Know This Already?” Section-to-Question Mapping

Foundation Topics Section

Questions

Compliance and the Implications of Tolerance

1, 2

Tolerance- and Threshold-Driven Triggers

3–5

Stakeholder-Driven Triggers

6

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 selfassessment. Giving yourself credit for an answer you correctly guess skews your

self-assessment results and might provide you with a false sense of security.

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

Compliance and the Implications of Tolerance 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.

Tolerance- and Threshold-Driven Triggers

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.

Stakeholder-Driven Triggers 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.

Exam Preparation Tasks 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 9-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.

Table 9-2 Chapter Review Tracking

Review Element

Review Key Topics

Review Date(s)

Resource Used

Book, Website

Review Key Terms

Book, Website

Answer DIKTA Questions

Book

Review Practice Questions

Book, Website

Rewrite/Document Chapter Headings

Book

Review All the Key Topics Review the most important topics in this chapter, noted with the Key Topic icon in the margin of the page. Table 9-3 lists a reference of these key topics and the page numbers on which each is found.

Table 9-3 Key Topics for Chapter 9

Key Topic Element

Description

Page Number

Section

Compliance and the Implications of Tolerance

143

Section

Tolerance- and Threshold-Driven Triggers

144

Section

Stakeholder-Driven Triggers

145

Key Terms You Should Know Define the following key terms from this chapter and check your answers in the glossary:

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. Which of the following statements is true? 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 This chapter covers the following subjects: Register Functionality 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.

®

This chapter addresses the following objectives from the PMI-RMP® Exam Content Outline:

Domain

Task #

Exam Objective

Risk Identification

Task 4

Develop Risk Register

“Do I Know This Already?” Quiz The “Do I Know This Already?” quiz enables 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 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.”

Table 10-1 “Do I Know This Already?” Section-to-Question Mapping

Foundation Topics Section

Questions

Register Functionality

1, 2

Register Categories

3, 4, 6

Risk Classification

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.

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 5. The project manager 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

Register Functionality 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 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 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 mid1200s. 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.

Detectability (FMEA) 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.

Exam Preparation Tasks 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 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.

Table 10-2 Chapter Review Tracking

Review Element

Review Date(s)

Resource Used

Review Key Topics

Book, Website

Review Key Terms

Book, Website

Answer DIKTA Questions

Book

Review Practice Questions

Book, Website

Rewrite/Document Chapter Headings

Book

Review All the Key Topics Review the most important topics in this chapter, noted with the Key Topic icon in the margin of the page. Table 10-3 lists a reference of these key topics and the page numbers on which each is found.

Table 10-3 Key Topics for Chapter 10

Key Topic Element

Description

Page Number

Section

Register Functionality

155

Section

Register Categories

156

Section

Detectability (FMEA)

160

Section

Risk Classification

164

Key Terms You Should Know Define the following key terms from this chapter and check your answers in the glossary: 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 This chapter covers the following subjects: Risk Sorting Taxonomic Review Risk Management Plan Application Risk Ranking Stakeholder-Based Ranking Support 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. This chapter addresses the following objectives from the PMI-RMP® Exam Content Outline:

Domain

Task #

Exam Objective

Risk Analysis

Task 1

Perform Qualitative Analysis

“Do I Know This Already?” Quiz The “Do I Know This Already?” quiz enables 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 11-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 11-1 “Do I Know This Already?” Section-to-Question Mapping

Foundation Topics Section

Questions

Risk Sorting

1, 2

Taxonomic Review

3

Risk Management Plan Application

4, 5

Risk Ranking

6

Stakeholder-Based Ranking Support

7

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 selfassessment. Giving yourself credit for an answer you correctly guess skews your self-assessment results and might provide you with a false sense of security.

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? 1. The risk breakdown structure 2. The work breakdown structure 3. The risk register 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.

Risk Management Plan Application

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

Element

Mode

Mode

(S)

Cause/Probability

Probability (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 is planned When change occurs At regular intervals 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

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.

Stakeholder-Based Ranking Support

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.

Exam Preparation Tasks 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 11-3 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 11-3 Chapter Review Tracking

Review Element

Review Date(s)

Resource Used

Review Key Topics

Book, Website

Review Key Terms

Book, Website

Answer DIKTA Questions

Book

Review Practice Questions

Book, Website

Rewrite/Document Chapter Headings

Book

Review All the Key Topics Review the most important topics in this chapter, noted with the Key Topic icon in the margin of the page. Table 11-4 lists a reference of these key topics and the page numbers on which each is found.

Table 11-4 Key Topics for Chapter 11

Key Topic

Page 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

Section

Risk Ranking

181

Section

Stakeholder-Based Ranking Support

184

2

Key Terms You Should Know Define the following key terms from this chapter and check your answers in the glossary:

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 This chapter covers the following subjects: Performance Data and Its Implications General Versus Detailed Quantitative Analysis Sensitivity Analysis Tools Relative Risk Weight and Priority 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. This chapter addresses the following objectives from the PMI-RMP® Exam Content Outline:

Domain

Task #

Exam Objective

Risk Analysis

Task 2

Perform Quantitative Analysis

“Do I Know This Already?” Quiz The “Do I Know This Already?” quiz enables 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 12-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 12-1 “Do I Know This Already?” Section-to-Question Mapping

Foundation Topics Section

Questions

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

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 selfassessment. Giving yourself credit for an answer you correctly guess skews your self-assessment results and might provide you with a false sense of security.

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. 4. We don’t know if she ran enough simulations because we don’t know how big the project was, but she needed the range of possible task durations and costs, as well as the distributions for those ranges. 5. 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. 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 Performance Data and Its Implications 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.

General Versus Detailed Quantitative Analysis 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

PERT Mean =

Optimistic+(4 MostLikely)+Pessimistic 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.

Sensitivity Analysis Tools

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.

Relative Risk Weight and Priority

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).

Exam Preparation Tasks 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 12-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.

Table 12-2 Chapter Review Tracking

Review Element

Review Date(s)

Resource Used

Review Key Topics

Book, Website

Review Key Terms

Book, Website

Answer DIKTA Questions

Book

Review Practice Questions

Book, Website

Rewrite/Document Chapter Headings

Book

Review All the Key Topics Review the most important topics in this chapter, noted with the Key Topic icon in the margin of the page. Table 12-3 lists a reference of these key topics and the page numbers on which each is found.

Table 12-3 Key Topics for Chapter 12

Key

Description

Topic

Page 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

Key Terms You Should Know

Define the following key terms from this chapter and check your answers in the glossary: 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? 1. Failure mode effect analysis 2. Burndown charts 3. Expected monetary value 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? 1. Failure mode effect analysis 2. Burndown charts 3. Expected monetary value 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 This chapter covers the following subjects: Risk Complexity Risk Interconnectedness Risk at the Organizational Level Threat Versus Opportunity 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:

Domain

Task #

Exam Objective

Risk Analysis

Task 3

Identify threats and opportunities

“Do I Know This Already?” Quiz The “Do I Know This Already?” quiz enables 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 13-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 13-1 “Do I Know This Already?” Section-to-Question Mapping

Foundation Topics Section

Questions

Risk Complexity

1, 2

Risk Interconnectedness

3, 4

Risk at the Organizational Level

5, 6, 7

Threat Versus Opportunity

8

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 selfassessment. Giving yourself credit for an answer you correctly guess skews your self-assessment results and might provide you with a false sense of security.

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 2. The project manager 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.

Risk Interconnectedness

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.

Risk at the Organizational Level

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.

Threat Versus Opportunity

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.

Exam Preparation Tasks 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 13-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.

Table 13-2 Chapter Review Tracking

Review Element

Review Date(s)

Resource Used

Review Key Topics

Book, Website

Review Key Terms

Book, Website

Answer DIKTA Questions

Book

Review Practice Questions

Book, Website

Rewrite/Document Chapter Headings

Book

Review All the Key Topics Review the most important topics in this chapter, noted with the Key Topic icon in the margin of the page. Table 13-3 lists a reference of these key topics and the page numbers on which each is found.

Table 13-3 Key Topics for Chapter 13

Key Topic

Description

Element

Paragraph

Page Number

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

Key Terms You Should Know Define the following key terms from this chapter and check your answers in the glossary: 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 This chapter covers the following subjects: Opportunity Versus Threat Strategies Action Plans and Risk Owners Resolution Metrics and Communication Organizational Impacts 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. This chapter addresses the following objectives from the PMI-RMP® Exam Content Outline:

Domain

Task #

Exam Objective

Risk Response

Task 1

Plan risk response

“Do I Know This Already?” Quiz The “Do I Know This Already?” quiz enables 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 14-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 14-1 “Do I Know This Already?” Section-to-Question Mapping

Foundation Topics Section

Questions

Opportunity Versus Threat Strategies

1, 2

Action Plans and Risk Owners

3, 4

Resolution Metrics and Communication

5, 6

Organizational Impacts

7, 8

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 selfassessment. Giving yourself credit for an answer you correctly guess skews your self-assessment results and might provide you with a false sense of security.

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 Opportunity Versus Threat Strategies 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

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.

Action Plans and Risk Owners 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.

Resolution Metrics and Communication 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

Response 1

Ted

Alice

Response 2

Ted

Bob

Alice

Response 3

Bob

Alice

Carol

Informed

Carol

Ted

Organizational Impacts 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.

Exam Preparation Tasks 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 14-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 14-5 Chapter Review Tracking

Review Element

Review Date(s)

Resource Used

Review Key Topics

Book, Website

Review Key Terms

Book, Website

Answer DIKTA Questions

Book

Review Practice Questions

Book, Website

Rewrite/Document Chapter Headings

Book

Review All the Key Topics Review the most important topics in this chapter, noted with the Key Topic icon in the margin of the page. Table 14-6 lists a reference of these key topics and the page numbers on which each is found.

Table 14-6 Key Topics for Chapter 14

Key Topic

Description

Element

Paragraphs

Page Number

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

Key Terms You Should Know Define the following key terms from this chapter and check your answers in the glossary: 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 3. The project manager 4. The customer 5. The product owner or project owner Which of the following two statements are true? 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 This chapter covers the following subjects: Response Plans Versus Contingencies Stakeholder Response Reactions Residual Risk and Its Implications Secondary Risk and Its Implications 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. ®

This chapter addresses the following objectives from the PMI-RMP® Exam Content Outline:

Domain

Task #

Exam Objective

Risk Response

Task 2

Implement risk response

“Do I Know This Already?” Quiz The “Do I Know This Already?” quiz enables 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 15-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 15-1 “Do I Know This Already?” Section-to-Question Mapping

Foundation Topics Section

Questions

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 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 selfassessment. Giving yourself credit for an answer you correctly guess skews your self-assessment results and might provide you with a false sense of security.

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 Response Plans Versus Contingencies

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).

Stakeholder Response Reactions

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

Opportunity Strategies

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 and Its Implications

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 Risk and Its Implications

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.

Exam Preparation Tasks

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 15-3 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 15-3 Chapter Review Tracking

Review Element

Review Date(s)

Resource Used

Review Key Topics

Book, Website

Review Key Terms

Book, Website

Answer DIKTA Questions

Book

Review Practice Questions

Book, Website

Rewrite/Document Chapter Headings

Book

Review All the Key Topics Review the most important topics in this chapter, noted with the Key Topic icon in the margin of the page. Table 15-4 lists a reference of these key topics and the page numbers on which each is found.

Table 15-4 Key Topics for Chapter 15

Key Topic Element

Description

Page Number

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

Key Terms You Should Know Define the following key terms from this chapter and check your answers in the glossary: 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 This chapter covers the following subjects: Gathering Information Ranking Approach Efficacy Contrasting Project and Organizational Risk 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:

Domain

Task #

Exam Objective

Monitor and Close Risks

Task 1

Gather and analyze performance data

“Do I Know This Already?” Quiz The “Do I Know This Already?” quiz enables 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 16-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 16-1 “Do I Know This Already?” Section-to-Question Mapping

Foundation Topics Section

Questions

Gathering Information

1, 2

Ranking Approach Efficacy

3–5

Contrasting Project and Organizational Risk

6–8

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 selfassessment. Giving yourself credit for an answer you correctly guess skews your self-assessment results and might provide you with a false sense of security.

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 Gathering Information

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 pennyfor-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 onemonth 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.

Ranking Approach Efficacy 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 highprobability 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 antifragility. 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.

Contrasting Project and Organizational Risk

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.

Exam Preparation Tasks 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 16-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.

Table 16-2 Chapter Review Tracking

Review Element

Review Date(s)

Resource Used

Review Key Topics

Book, Website

Review Key Terms

Book, Website

Answer DIKTA Questions

Book

Review Practice Questions

Book, Website

Rewrite/Document Chapter Headings

Book

Review All the Key Topics Review the most important topics in this chapter, noted with the Key Topic icon in the margin of the page. Table 16-3 lists a reference of these key topics and the page numbers on which each is found.

Table 16-3 Key Topics for Chapter 16

Key Topic

Description

Element

Page 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.

Key Terms You Should Know Define the following key terms from this chapter and check your answers in the glossary: 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 This chapter covers the following subjects: Residuals and Deductibles Response-Generated Risks 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. This chapter addresses the following objectives from the PMI-RMP® Exam Content Outline:

Domain

Task #

Exam Objective

Monitor and Close Risks

Task 2

Monitor residual and secondary risks

“Do I Know This Already?” Quiz The “Do I Know This Already?” quiz enables 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 17-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 17-1 “Do I Know This Already?” Section-to-Question Mapping

Foundation Topics Section

Questions

Residuals and Deductibles

1, 2

Response-Generated Risks

3–5

Late Risk Reporting

6–8

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 selfassessment. Giving yourself credit for an answer you correctly guess skews your self-assessment results and might provide you with a false sense of security.

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 Residuals and Deductibles 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 tamperproof 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.

Response-Generated Risks

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 costplus 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

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.

Type

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.

Exam Preparation Tasks 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 17-3 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 17-3 Chapter Review Tracking

Review Element

Review Date(s)

Resource Used

Review Key Topics

Book, Website

Review Key Terms

Book, Website

Answer DIKTA Questions

Book

Review Practice Questions

Book, Website

Rewrite/Document Chapter Headings

Book

Review All the Key Topics Review the most important topics in this chapter, noted with the Key Topic icon in the margin of the page. Table 17-4 lists a reference of these key topics and the page numbers on which each is found.

Table 17-4 Key Topics for Chapter 17

Key Topic

Description

Element

Section

Page Number

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

Key Terms You Should Know Define the following key terms from this chapter and check your answers in the glossary: 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

Which of the following two statements are true? 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 This chapter covers the following topics: Risk Reporting Related Document Updates Project-wide Risk Updates Organization-wide Risk Updates 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. This chapter addresses the following objectives from the PMI-RMP® Exam Content Outline:

Domain

Task

Exam Objective

#

Monitor and Close

Task

Provide Information Required to Update Relevant Project

Risks

3

Documents

Monitor and Close

Task

Monitor Project Risk Levels

Risks

4

“Do I Know This Already?” Quiz The “Do I Know This Already?” quiz enables 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 18-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 18-1 “Do I Know This Already?” Section-to-Question Mapping

Foundation Topics Section

Questions

Risk Reporting

1, 2

Related Document Updates

3, 4

Project-wide Risk Updates

5, 6

Organization-wide Risk Updates

7, 8

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 selfassessment. Giving yourself credit for an answer you correctly guess skews your self-assessment results and might provide you with a false sense of security.

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. Which of the following statements is true? 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 is planned When change occurs At regular intervals 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-AC-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.

Related Document Updates

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.

Project-wide Risk Updates “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.

Organization-wide Risk Updates

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 longterm 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.

Exam Preparation Tasks 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 18-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.

Table 18-2 Chapter Review Tracking

Review Element

Review Key Topics

Review Date(s)

Resource Used

Book, Website

Review Key Terms

Book, Website

Answer DIKTA Questions

Book

Review Practice Questions

Book, Website

Rewrite/Document Chapter Headings

Book

Review All the Key Topics Review the most important topics in this chapter, noted with the Key Topic icon in the margin of the page. Table 18-3 lists a reference of these key topics and the page numbers on which each is found.

Table 18-3 Key Topics for Chapter 18

Key Topic

Description

Element

Paragraphs

Page Number

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

Key Terms You Should Know Define the following key terms from this chapter and check your answers in the glossary: 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 2. Expected monetary value 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. 4. In an adaptive environment, it’s a chart that reflects the timing of user story completion, including the adjustments made to user stories to account for the range of risk. 5. In an adaptive environment, it’s a chart that reflects the timing of user story completion, 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 fourstep 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 “Do I Know This Already?” Quiz 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 “Do I Know This Already?” Quiz 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 “Do I Know This Already?” Quiz 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 “Do I Know This Already?” Quiz

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 “Do I Know This Already?” Quiz 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 “Do I Know This Already?” Quiz 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 “Do I Know This Already?” Quiz 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 openended 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 “Do I Know This Already?” Quiz 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 “Do I Know This Already?” Quiz 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 “Do I Know This Already?” Quiz 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 “Do I Know This Already?” Quiz 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 “Do I Know This Already?” Quiz 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 betterthan-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 “Do I Know This Already?” Quiz 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 “Do I Know This Already?” Quiz

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 “Do I Know This Already?” Quiz

A. Contingent reserves are set aside for threats that fit within the project context. Unknownunknowns 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 “Do I Know This Already?” Quiz 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 highprobability 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 “Do I Know This Already?” Quiz 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 “Do I Know This Already?” Quiz 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.

Glossary of Key Terms A 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.

B 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.

C 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.

D 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.

E 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.

F 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.

I 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.

P 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 (highmedium-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 mediumprobability–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.

S 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.

T 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 A 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

B 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

C 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 decision tree, 229–231 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 controllability, 159 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

D 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 all-conditions fault, 228 any-condition fault, 228–229 multiple condition fault, 229 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 environmental assessment, 9 signature, 9 project plans, 7 RACI (responsible, accountable, consult, inform) chart, 73–74 RAM (responsibility assignment matrix), 72–73 risk communication, 77 risk register, 11–14 categories. See also risk, register functionality, 155–156 RMP (risk management plan), 57 dormancy, 159, 383 dot voting, 182, 383 Drucker, P., 291

E EAC (estimate at completion), 383 earned value, metrics, 197 actual cost, 199 BAC (budget at completion), 198 CV (cost variance), 199 EAC (estimate at completion), 200 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 environmental assessment, 9 escalation, 13, 99, 161, 246, 249, 383 EV (earned value), 198 event risk, 12, 157, 252–253 expected monetary value, 383 expertise, risk identification, 117 explicit knowledge, 23, 384 exploitation, 384 external constraint, 27

F 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

G and-gate fault tree, 379 or-gate fault tree, 386 general analysis Monte Carlo simulation, 204–205 PERT (program evaluation review technique), 205–209 GERT (graphic evaluation review technique), 209 group risk ranking, 181

H high-impact risk realization, 285 anti-fragility, 286

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

I 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 facilities, equipment, and hardware, 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

L 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

M 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 sprint completion, 201 story point completion, 203 user stories completion, 202 earned value, 197 actual costs, 199 BAC (budget at completion), 198 CV (cost variance), 199 EAC (estimate at completion), 200 EV (earned value), 198 PV (planned value), 198 SPI (schedule performance index), 199 SV (schedule variance), 199 TCPI (to-complete performance index), 201 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

N 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

O 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 facilities, equipment, and hardware, 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 environmental change, 339 personnel/stakeholder, 336 project management culture, 340–341 quality, 336 technical change, 339 unanticipated overuse, 338 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 sprint completion, 201 story point completion, 203 user stories completion, 202 data, 197 earned value metrics actual costs, 199 BAC (budget at completion), 198 CV (cost variance), 199 EAC (estimate at completion), 200 EV (earned value), 198 PV (planned value), 198 SPI (schedule performance index), 199 SV (schedule variance), 199 TCPI (to-complete performance index), 201 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 environmental assessment, 9 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 PV (planned value), 198

Q qualitative analysis, 58, 91 data gathering and reporting adaptive approach, 330

predictive approach, 329 quality risk, residual, 307 quantitative analysis, 58, 92, 388 decision tree, 212–214 detailed, 209 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 data gathering and reporting adaptive approach, 331–332 predictive approach, 330–331 questions follow-up, 164 risk, 111, 117–118

R 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 nominal group technique, 183–184

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 active acceptance, 245 enhancement, 245 escalation, 246 passive acceptance, 244 sharing, 246 secondary risk, 270–271 stakeholder, 267 opportunity strategy, 267–268 threat strategy, 268 stakeholder role, 92 threat strategy, 246 active acceptance, 247 avoidance, 247 escalation, 249

mitigation, 248 passive acceptance, 246 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 controllability, 159 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 risk register, 11–14 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 opportunity strategy, 244–246 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 stakeholder, 91–92

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

S 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 SPI (schedule performance index), 199 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 opportunity strategy, 267–268 threat strategy, 268 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 story point completion, 203 strategy, 53, 162–163. See also response opportunity, 244–246, 251, 267–268 active acceptance, 245 enhancement, 245 escalation, 246 passive acceptance, 244 sharing, 246 threat, 233, 246, 251, 268 active acceptance, 247 avoidance, 247 escalation, 249 mitigation, 248 passive acceptance, 246 transfer, 248 supportive stakeholders, 30 SV (schedule variance), 199 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 TCPI (to-complete performance index), 201 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 active acceptance, 247 avoidance, 247 escalation, 249 mitigation, 248 passive acceptance, 246

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 stakeholder, 30–31 updates, 341 tools. See also analysis ranking consensus, 183 dot voting, 182 fist to five, 182 nominal group technique, 183–184 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 all-conditions fault, 228 any-condition fault, 228–229 multiple condition fault, 229 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

U 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 environmental change, 339 personnel/stakeholder, 336

project management culture, 340–341 quality, 336 technical change, 339 unanticipated overuse, 338 PMI-RMP® exam, 377 project-wide, 334–336 risk register, 155, 314–316 urgency, 158, 179, 392 user story, completion, 202

V value earned, 198 expected monetary, 209–210 planned, 198 variance cost, 199 schedule, 199 vendors, education and training, 81 VERT (venture evaluation review technique), 209 virtual meetings, 97 visible triggers, 144 voting dot, 182 Roman, 183

W 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

Element

Reading

Task

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 Practice Test

Take practice test in study mode using Exam Bank 1 questions for Chapter 2 in practice test software

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 Practice Test

Take practice test in study mode using Exam Bank 1 questions for Chapter 3 in practice test software

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

Practice Test

Take practice test in study mode using Exam Bank 1 questions for Chapter 4 in practice test software

5. The Risk

Read Foundation Topics

Management Plan (RMP) 5. The Risk

Review Key Topics

Management Plan (RMP) 5. The Risk

Define Key Terms

Management Plan (RMP) 5. The Risk

Complete Review Questions section

Management Plan (RMP) Practice Test

Take practice test in study mode using Exam Bank 1 questions for Chapter 5 in practice test software

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 Practice Test

Take practice test in study mode using Exam Bank 1 questions for Chapter 6 in practice test software

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 Practice Test

Take practice test in study mode using Exam Bank 1 questions for Chapter 7 in practice test software

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 Practice Test

Take practice test in study mode using Exam Bank 1 questions for Chapter 8 in practice test software

9. Applying

Read Foundation Topics

Triggers and Thresholds 9. Applying

Review Key Topics

Triggers and Thresholds 9. Applying Triggers and

Define Key Terms

Thresholds 9. Applying

Complete Review Questions section

Triggers and Thresholds Practice Test

Take practice test in study mode using Exam Bank 1 questions for Chapter 9 in practice test software

10. The Risk

Read Foundation Topics

Register 10. The Risk

Review Key Topics

Register 10. The Risk

Define Key Terms

Register 10. The Risk

Complete Review Questions section

Register Practice Test

Take practice test in study mode using Exam Bank 1 questions for Chapter 10 in practice test software

11. Risk

Read Foundation Topics

Qualification 11. Risk

Review Key Topics

Qualification 11. Risk

Define Key Terms

Qualification 11. Risk

Complete Review Questions section

Qualification Practice Test

Take practice test in study mode using Exam Bank 1 questions for Chapter 11 in practice test software

12. Risk

Read Foundation Topics

Quantification 12. Risk

Review Key Topics

Quantification 12. Risk

Define Key Terms

Quantification 12. Risk

Complete Review Questions section

Quantification Practice Test

Take practice test in study mode using Exam Bank 1 questions for Chapter 12 in practice test software

13. Risk

Read Foundation Topics

Complexity, Assessment, and Analysis 13. Risk

Review Key Topics

Complexity, Assessment, and Analysis 13. Risk

Define Key Terms

Complexity, Assessment, and Analysis 13. Risk

Complete Review Questions section

Complexity, Assessment, and Analysis Practice Test

Take practice test in study mode using Exam Bank 1 questions for Chapter 13 in practice test software

14. Response

Planning 14. Response

Review Key Topics

Planning 14. Response

Define Key Terms

Planning 14. Response

Complete Review Questions section

Planning Practice Test

Take practice test in study mode using Exam Bank 1 questions for Chapter 14 in practice test software

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 Practice Test

Take practice test in study mode using Exam Bank 1 questions for Chapter 15 in practice test software

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 Practice Test

Take practice test in study mode using Exam Bank 1 questions for Chapter 16 in practice test software

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 Practice Test

Take practice test in study mode using Exam Bank 1 questions for Chapter 17 in practice test software

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 Practice Test

Take practice test in study mode using Exam Bank 1 questions for Chapter 18 in practice test software

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.