PMP Exam Prep - 2023 11th Edition (Rita Mulcahy, PMP With Margo Kirwin)

The International Best-Selling PMP® Exam Prep Book for 30+ Years
Rita Mulcahy’s
PMP
Exam Prep
Eleventh Edition
Aligned with the current ECO (Examination Content
Outline/) and the PMBOK® Guide, Seventh Edition
Proven study method
Exclusive exam prep tips and tricks
Interactive chapter quizzes with scoring
Essential info on plan-driven and agile approaches

PMP® Exam Prep
Accelerated Learning to Pass the
Project Management Professional (PMP)® Exam
By Rita Mulcahy, PMP
with Margo Kirwin, CPLP, PMP, PMI-ACP, PMI-PBA

Contents
Section I Studying for the PMP® Exam 1

Chapter 1 Tricks of the Trade for Studying for the PMP® Exam 3
Qualifying to Take the Exam 3
Applying to Take the Exam 4
Are You Ready for the PMP Exam? 5
Self-evaluation Checklist 6
How to Use This Book 7
What Is the PMP Exam Like? 11
How to Study for the PMP Exam 22
How to Use This Book in a Study Group 25
Section II Foundations 27
Chapter 2 PMP® Exam References in Context 29
Introduction 29
Examination Content Outline (ECO) Overview 30
The Process Groups Model Overview 31
Rita’s Process Chart”: A Vital Study Tool 37
Study Notes for Rita’s Process Chart™ 39
Rita’s Process Chart™ Game 44
Agile Process Overview 44
Rita’s Agile Process Chart™ 45
PMBOK* Guide, Seventh Edition Overview 49
Putting It All Together 50
Chapter 3 Project Management Foundations 53

Project Management’s Organizational Context 53
Project Selection 59
Project Methods and Artifacts 64
Project Roles 68
Responsibilities Lists by Role 72
Chapter 4 Integration 77
Introduction 77
Integration Management Overview 78
Develop Project Charter 80
Develop Project Management Plan 84
Direct and Manage Project Work 90
Manage Project Knowledge 91
Monitor and Control Project Work 93
Perform Integrated Change Control 95
Close Project or Phase 99
A Case Study You Can Use 100
Integration: Putting It All Together 100
Section III Domain 1: People 103
Chapter 5 Leadership Skills 105

Introduction 105
Overview of Leadership 105
Communication Skills 108
Motivation Models 114
Models of Skill Mastery 116
Situational Leadership Models 118
Team Development Models 119
Other Leadership Concepts 121
Conflict Management 122
Chapter 6 Build and Support Team Performance 125

Introduction 125
Overview of Building and Supporting Performance 125
Plan Resources 129
Estimate Resource Requirements 133
Acquire (and Release) Resources 136
Develop Team 139
Manage Team 144
Section IV Domain II: Process 151

Chapter 7 Scope 153
Introduction 153
Scope Management Overview 155
Scope Management Planning 158
Eliciting and Analyzing Requirements 161
Define Scope 171
Create WBS (Decompose Scope) 173
Validate and Control Scope 182
Scope: Putting It All Together 186
Chapter 8 Schedule 189

Introduction 189
Schedule Process Overview 190
Plan Schedule Management 192
Define Activities 193
Sequencing Activities 194
Estimating Activity Durations 198
Develop Schedule 207
Control Schedule 223
Chapter 9 Budget and Resources 229
Introduction 229
Definitions Related to Budget and Resource Management 229
Cost Management Overview 230
Plan and Estimate Project Costs 231
Determine Budget 234
Control Costs 237
Chapter 10 Quality of Deliverables and Products 249

Introduction 249
Overview of Planning and Managing Quality 252
Plan Quality Management 256
Manage Quality 257
Control Quality 258
Quality Management Methods 259
Agile Quality Management Concepts 267
Quality Management Outcomes: A Summary 270
Understanding the Tools and Techniques Used in Quality Management 270
Chapter 11 Communications 273

Introduction 273
Communications Management Overview 273
Communications Planning 276
Managing Effective Communications 278
Monitor Communication Effectiveness 282
Chapter 12 Risks and Issues 285

Introduction 285
Risk Management Overview 288
Plan Risk Management 290
Identify Risks 291
Perform Qualitative Risk Analysis 294
Perform Quantitative Risk Analysis 296
Plan Risk Responses 300
Implement Risk Responses 310
Monitor Risks 311
iii
Chapter 13 Procurement 321
Introduction 321
Procurement Management Overview 322
Understanding Contracts 325
Plan Procurements 335
Conduct Procurements 340
Control Procurements 343
Chapter 14 Stakeholders 351

Introduction 351
Stakeholder Engagement Overview 352
Stakeholder Identification (and Analysis) 355
Plan Stakeholder Engagement 358
Manage Stakeholder Engagement 362
Monitor Stakeholder Engagement 365
Stakeholder Engagement in Agile Environments 368
Section V Domain III: Business Environment 375

Chapter 15 Compliance and Delivering Value 377
Introduction 377
Planning and Managing Project Compliance 380
Delivering Value 382
Evaluate and Address External Business Environment Changes for Impact on Scope 387
Support Organizational Change 390
Section VI Pulling It All Together 393

Chapter 16 Tips for Passing the PMP® Exam the First Time 395
Introduction 395
Review of Core Concepts 395
The Significance of Quantitative Measures on the Exam 401
More Tips for Exam Preparation 403
Preparing for the Exam Environment 404
Common Project Management Errors and Pitfalls 406
A Day-in-the-Life 407
iv
Chapter 17 Common Agile Methodologies 409
Introduction 409
Overview 409
Lean 410
Kanban 410
Scrum 412
XP (eXtreme Programming) 414
Crystal Family of Methodologies 416
DSDM 416
Scaled Agile Framework* (SAFe*) 417
Feature Driven Development (FDD) 418
Agile Values and Principles 418
The Agile Mindset 420
Chapter 18 PMBOK® Guide and the PMStandard Principles and Domains 423
Introduction 423
The PMBOK* Guide, the ECO, and Process Groups 423
Mapping the PMBOK* Guide to the ECO and Practice Groups Processes 427
The Standard and the PMBOK* Guide 430
Conclusion 431
Index 433
v
Introduction to the Eleventh Edition
Welcome to the eleventh edition of PMP® Exam Prep. We can't believe that it has been 25 years since
Rita published the first edition of this book. RMC has come far since the publication of the first edition in
1998, as has the project management profession.
Back when the first edition was published, most project managers were in the United States. Now
there are more international project managers than ever before. As a result of this industry growth, RMC s
best-selling materials are now sold all over the world.
Project management is also a more complex profession than it used to be. Along with the processes,
concepts, and methods added within the last few years, there are now just as many adaptive approaches to
project management as there are predictive. The general methodologies and overall practices of project
management have changed dramatically, which has increased the size of a project managers toolbox.
PMI has recently introduced A Guide to Project Management Book of Knowledge (PMBOK* Guide),
Seventh Edition and the Process Groups: A Practice Guide. There is more to learn today than ever. This
increased complexity is reflected in the eleventh edition of new book.
This book is vastly different than our previous editions. It's structure is aligned to the Examination
Content Outline (ECO). Previous editions of this book were built around knowledge areas. In this edition,
sections directly relate to the ECO's three domains: People (Domain I), Process (Domain II), and Business
Environment (Domain III). It is more important than ever to read and understand the ECO because it
covers the domains and introduces adaptive approaches to project management and the PMP* exam.
Throughout this book, we will remind you to look at your copy of the ECO, and we provide
opportunities to use it with some new exercises.
In this book, we bring together the terminology and concepts used in the ECO, the PMBOK* Guide,
and the Process Groups: A Practice Guide. We synthesize the concepts in a way that makes it easier to
understand and prepares you for the exam.
Rita's Process Chart™ has helped thousands of students comprehend and apply predictive project
management. It remains in this edition and we also introduce Rita's Agile Process Chart™. We believe this
chart will also help you prepare for the agile content found on the PMP* exam.
And, you can still play the Rita's Process Chart™ game and Rita's Agile Process Chart™ game on our
all-new RMC Resources page. The digital RMC Resources page has additional content for a deeper dive
into concepts found in the book, a searchable glossary for project management terms, access to more games
and interactive eLearning modules, as well as a mini version of our Hot Topics book.
With this edition, you also get access to our new interactive tool, RMC Chapter Quizzes. With more
than 100 questions, you will be able to test your knowledge and you will get exposure to how the real
exam looks.
Finally, we present a case study that will be carried throughout the book. You will be able to apply
concepts presented in the chapters based on this case study.
While these are significant changes, important aspects of our book remain the same. First, and most
importantly, is the conversational tone of the book. The eleventh edition maintains its down-to-earth
conversational style—explaining things simply and clearly. Students say that when they read this book, it
feels like Rita is talking to them. In many ways, she still is.
Another thing that remains the same is our continued commitment to helping our students not only
pass the exam but also become better project managers. That is what the book, and, in fact, our company, is
all about.
As you read this book, know that our plan is not to have you memorize a bunch of rules and formulas
just to pass the exam and then promptly forget them. For one thing, given the situational nature of most
questions on the exam, we believe that such an approach would be unsuccessful. For another, it’s not what
we’re about. This book is not just a prep guide—it’s a learning tool. If you master the contents of our book,
you will pass the exam, but it’s more than that. After you learn what we have to teach, you’ll be a better
project manager. At the end of the day, that’s what the world needs. Still, our goal with this book is to get
you to pass the exam on the first try.
I couldn’t allow this book to go out the door without acknowledging the efforts of the team at RMC
that made this happen. In particular, I’d like to thank Margo Kirwin for her significant work in updating this
book. I'd also like to thank Patti Frazee and Jason Craft for their dedication and hard work on this edition.
Margo was a student of Rita's, served as RMC's Director of Training, and has trained on RMC products
for a number of years. She has the knowledge and clarity to capture Rita's vision. In addition to being an
outstanding trainer, Margo has an extensive background in instructional design, which she brought to the
development of this edition. She is also a talented writer who was able to maintain the conversational tone
and feel of the book while working hard to explain all the elements of project management in a clear and
easy-to-read way.
Patti served as the project manager and content editor for this book. Patti brought an incomparable set
of skills that allowed her to help develop and edit content while also managing the constantly moving
pieces of the project. Without her, this book would not have been published on time, if at all.
Jason was the talented designer of this book. With a keen eye to detail and his creative sensibilities, he
made this book visually appealing and engaging. He also took our vision of the RMC Resources page and
made it a reality.
When Rita created RMC, she did so to help people. That is still our goal and one of the driving values
of this company. So enjoy the book, learn, and have fun.
What are you waiting for? Go get ‘em.
Tim Mulcahy
President and CEO
RMC Learning Solutions and RMC Publications
Section I
Studying for the PMP® Exam
RMC has helped thousands of students worldwide pass the PMP* exam. In this section, we provide information on our
proven study methods to help prepare you for the exam. We will also give you information on how to apply to take the
exam and the requirements needed. In addition you will find the following:
• A self-evaluation checklist: Discover the knowledge needed to pass the exam
• How to use this book to maximize your studying time
• Some key definitions
• Other tools from RMC that can enhance your studies
• What the PMP* exam is like
• Important aspects of the exam
• Sample questions
• PMI-isms
• Study plans
2
QUICKTEST
You will find a list at
Tricks of the Trade for the beginning of each

chapter of key topics
covered in the chapter.
Studying for the PMP® Exam Use the Quicktest to test

your knowledge of those
topics and uncover your
gaps in understanding.
Preparing to take the PMP® exam is a journey. This journey can help you grow your career and develop
your skills and abilities. This isn’t just about passing an exam—you can become a better project manag
er. This opportunity to learn is one of the best reasons to get your PMP certification.
To pass the PMP exam, you need to truly understand project management processes, good
practices, and the project manager’s role and responsibilities. You also need to be able to tailor your
tactics and strategies to the situations that different projects present—and to the different situations
presented to you on exam questions. The PMP exam is designed to test your knowledge and experience
in applying the art and science of project management.
In addition to the learning opportunity, there can also be financial incentives for passing the
exam. According to Project Management Institutes (PMI®) salary survey (2020), globally,
PMP-certified project managers are paid on average 16% more than those without the certification.
RMC has had students who received a bonus, a raise, or both when they passed the exam. Others have
reported they landed a job ahead of other qualified candidates because they were PMP certified.
Having a PMP certification can be the reason you get a job, keep your job, or are promoted.
Qualifying to Take the Exam

To take the PMP exam, you must meet the current requirements as summarized below and in the fol
lowing table. Requirements are subject to change, so make sure you review the requirements at
pmi.org, or in PMI’s Examination Content Outline (ECO), where this information is published.
• Your experience leading projects cannot overlap. For example: If you managed two projects at the
same time for six months, you may use your experience with only one of these projects for that
six-month period.
• If you are a graduate of a PMI Global Accreditation Center for Project Management Education
Program (GAC) program, you will receive a 12-month credit towards the required experience.
• Work experience must be professional experience. For example: Managing a project to build
your own house cannot be counted toward the work experience.
• In addition to the educational background and professional work experience found in the table
on the next page, you must have at least 35 contact hours of formal project management
education, unless you are an active Certified Associate in Project Management (CAPM)® holder.
Active CAPM holders do not need these 35 contact hours of project management training.
• Check PMI’s site to ensure that these requirements are current as PMP requirements are subject
to change.
s
Tricks of the Trade for Studying for the Exam o n e
Educational Background Project Management Work Experience

• Secondary degree (high school diploma, • Minimum five years/60 months unique
associate degree or global equivalent) non-overlapping professional project
management experience
OR
• Four-year degree (bachelor’s or global • Minimum three years/36 months unique,
equivalent) non-overlapping professional project
management experience
OR
• Bachelor’s or post-graduate degree from a • Minimum two years/24 months unique,
GAC accredited program (bachelor’s, non-overlapping professional project
master’s or global equivalent) management experience
This book will help you become familiar with the project management practices and terminology needed to pass the
exam. If you don’t meet the minimum requirements listed in the previous table, consider taking PMI’s CAPM exam. You
can find the requirements for the CAPM exam at pmi.org.
Applying to Take the Exam

Applications to take the exam must be submitted online to PMI. Here is what the process looks like after you submit your
application:
• You must log into pmi.org to see if the status of your application is “accepted.”
• Once your eligibility is verified, you will need to pay for your exam.* *
• After you pay for the exam you can schedule it at a testing center. Alternatively, there is an option to take the exam
online from your home or office.
• Once you receive authorization to take the PMP exam, you must pass the exam within one year. You can take the exam
up to three times within that year.
• If you fail the exam three times, you must wait one year to reapply for the exam.
*A percentage of candidates are selected at random for audit. If you are selected for an audit, you will need to provide
to PMI a copy of your degree, verification of your experience by a manager, and proof of your 35 training hours (with
exceptions to these 35 training hours for active CAPM holders).
There are specific rules and instructions for each type of exam (online or at a testing center). For online exams it is
highly recommended to test your computer system with their testing system before exam day. In most cases, the
confirmation of your scheduled exam will give you specific details. Consult PMI’s certification handbook and visit pmi.org
for the most detailed and up-to-date information about testing options, locations, and exam languages available.
ONE Tricks of the Trade for Studying for the Exam
Are You Ready for the PMP Exam?

In our experience, half of those who fail the exam do so because they have not had fundamental project management train
ing, or experience and training that uses PMI terminology and concepts. This is a serious factor to consider in determining
whether you are ready to take the exam. This PMP*1 Exam Prep book will help you understand project management from
PMI’s perspective; however, if you find that many of the concepts and terms presented in this book are new to you—or you
do not use many of the methods discussed in this book (such as a charter, WBS or prioritized backlog, network diagram,
and management plans)— you probably need fundamental project management training before continuing to study.
Other people who fail the exam do not have enough real-world project management experience and do not understand
the range of possible project types and development approaches. Instead, they may be managing very small projects or
repeatable processes. Some might not even be working as a project manager. On the exam, you will need to be able to
recognize from the information in scenario-based questions what type of project the question is referring to, and to answer
from that perspective. This could be a large project using a plan-based project management approach, a project using an
agile approach, or an approach that is a hybrid of the two. The more experience you have with a variety of project
management approaches, the better prepared you will be for the exam.
The following are examples of projects that are likely to use a plan-based approach:
• Building a bridge
• Designing and constructing a new building
The following are examples of projects that are likely to use an agile approach:
• Creating a new product that does not need to have all features before its first release but can instead be released with a
set of defined, critical features
• Incremental delivery of a solution where scope is emerging
The following are examples of projects or programs using a hybrid approach:

• The construction of a new building uses a plan-based approach. Then, the division and finishing of the inside of the
building into office suites is completed iteratively and incrementally as leases for suites are signed.
• An internal software product for a large organization is developed and tested using a plan-based approach. It is then
rolled out to a small pilot group of end users. By the end of this predictive phase and pilot, the software installation and
training have been field-tested. Installation and training for the remainder of the organization can be done iteratively
by department and by office until the rollout is complete.
• A very large technology project may have several adaptive “feature teams,” each assigned to develop different software
components. The project management work of integrating the features produced by the feature teams may be done
using agile methods while development takes place. Predictive methods may be used for rolling out the solution to
user groups.
What is the depth of your knowledge and understanding of project management? Think about your project
management training and experience as you review the following self-evaluation checklist. Do you understand most of
these topics, and do you currently apply many of the methods included in these lists when working on your projects?
This book will help you find and fill your gaps in the project management knowledge needed to apply to situational
exam questions in order to pass the exam. However, the starting assumption is that with your project management
experience and education, you are already familiar with many of these concepts. The more gaps you identify, the more
effort you will need to apply to exam preparation. Most chapters in this book will provide a Quicktest, or list of concepts
contained in that chapter. Use that and the other instructions we provide to be sure you are filling your gaps as you work
through the material in this book.
5
Self-evaluation Checklist
The following checklist provides an idea of the breadth of knowledge and the application of skills required to pass the exam.
If you understand a list item, mark it off so that you can pay attention to those items where you have gaps in your knowledge.
□ Managing a project with the urgency needed to deliver the benefits and value for which the project was selected.
□ Using a systematic, plan-driven project management process, and understanding why each step is necessary. Think
about this as you review PMI’s Process Groups model in the “PMP* Exam References in Context” chapter and
elsewhere throughout this book. Plan-driven and agile methods will be identified and compared.
□ Agile philosophy for project management, and good agile practices from a variety of agile methods, including
Scrum, Lean, and Kanban.
□ The roles of the project manager, sponsor, product owner, team, and stakeholders.
□ The use of historical information from previous projects, including lessons learned.
□ What a formal project charter is and knowing what it requires.
□ Prioritizing project constraints sufficiently to balance and manage competing constraints.
□ What a work breakdown structure (WBS) is and how to create it.
□ Creating a product and project vision sufficient to create a high-level product roadmap.
□ Using a prioritized, risk-adjusted backlog of product features to create stories for iterations of product development.
□ Understanding the interconnected relationship of activities (dependencies) to create the network diagram for a
plan-driven project.
□ What the critical path is, how to find it, and what benefits it provides the project manager.
□ Using a variety of estimating techniques, including rough order of magnitude (ROM), three-point estimating, or
relative estimating such as affinity sizing and story point estimating.
□ Doing earned value analysis and management.
□ Carrying out schedule “what if” analysis and schedule compression (crashing and fast tracking).
□ Managing project float and activities that do not have float.
□ Creating a realistic schedule.
□ Managing the quality of both the project and the resulting deliverables.
□ Developing relationships with stakeholders, and keeping them interested and involved in the project.
□ Using the meetings and feedback loops necessary to continuous progress and continuous improvement on agile
projects—for example, daily standups, iteration review, and iteration retrospectives.
□ Using information radiators to keep stakeholders informed and engaged.
□ Understanding the process of risk management.
□ Calculating reserves and understanding their relationship to risk management.
□ Creating a realistic and approved project management plan that you are willing to be held accountable to achieving.
□ Monitoring and controlling the project according to the project management plan.
□ Managing change requests and controlling change.
□ Planning and developing iteratively and incrementally for change-driven projects.
□ Understanding the professional and social leadership responsibilities expected of a project manager.
□ Ensuring that roles and responsibilities are clear and that team members are properly trained and oriented to the
project and the selected life cycle and development approach.
6
How to Use This Book

First, be sure you have the most current materials. This edition of the PMPxExam Prep book is in alignment with the Exam
ination Content Outline (ECO) for exams taken after January 2021. It also uses concepts found in resources from PMI:
• The PMBOK* Guide, Seventh Edition (©2021)
• The Standard for Project Management (published with the PMBOK* Guide)
• Process Groups: A Practice Guide (©2023)
• Agile Practice Guide (©2017)
Does this mean you have to read all these resources? No! We have researched what you need to know for the exam and
have provided that information in this book.
How Terminology Is Used

It’s important to define some terms up front. We have listed these here. You will find other terms described in the chapter
where they have the most context. If a term is not defined, we may have assumed that it is a fundamental project management
term, and most people understand it as common knowledge. PMI provides a Lexicon of Project Management Terms in
their list of standards and publications (on pmi.org).
Project Environments and Project Management Approaches

Project Environment Some organizations use a single type of project management approach, like plan-driven or agile.
Other organizations use a variety of approaches across the spectrum from plan-driven to agile, and hybrid. This will depend
upon a variety of factors, including the type of organization, the types of products or services the organization creates and
supports, organizational governance, and the characteristics of the projects the organization needs to complete to achieve
its strategic goals and deliver value to its stakeholders.
Project Approach (or development approach) This refers to a selective approach to project management and product
development based on the type, size, priority, and complexity of a particular project. Among other considerations, the
project approach is typically selected based on how possible it is to accurately define scope and other project constraints
early in the project. There is a spectrum of approaches from plan-based to agile, and hybrid.
When we talk about project environments we are generalizing about the project management (or development)
approach that an organization tends to use or is using for a variety of projects at the present time. In everyday language this
terminology is used differently depending on the organization, project management office (PMO), or project team. For
consistency and to avoid confusion in this book we use the following terminology to describe project environments and
project management approaches:
• Environments We describe project environments as either predictive, adaptive, or hybrid.
• Approaches We describe project management approaches as either plan-driven, agile, or hybrid.
>/ A plan-driven approach is also knows as traditional or waterfall (or predictive).
>/ An agile approach may also be known as adaptive. Some people use the terms agile and Scrum interchangeably,
even though Scrum is a specific agile methodology.
Project Life Cycle

A life cycle is a progression through a series of developmental stages. The project development life cycle reflects the
performing organizations methodology for managing a project. It is a logical breakdown of what the project manager
needs to do to produce the project deliverables, and is selected based on factors such as the type of product being developed,
the industry, the organization’s preferences, and the development approach.
A project life cycle can use a plan-driven or change-driven development approach, or a hybrid of the two. An example
of a life cycle for new product development might include the following phases: research, design, build, test, and implement.
1
Tricks of the Trade for Studying for the Exam ONE
How This Book Is Organized

This book contains six exam content-related sections.
Section I Tricks of the Trade for Studying for the PMP Exam
This is the only chapter in this section.
Section II Foundations
This section of this book is where you will learn the base knowledge that you need to understand the rest of the content of
this book and to begin preparing for the exam.
“Exam References in Context” This chapter provides foundational information about the:
• Examination Content Outline (ECO)—which exam question writers are directed to use when writing exam questions.
• PMI’s Process Groups Model—is found in PMI’s book, Process Groups: A Practice Guide. We refer to the content of
Process Groups: A Practice Guide as the “Process Groups model” because we consider it a great learning model for plan
based approaches, which make up a large proportion of exam questions. Your understanding the Practice Groups
model will also help you understand the tasks of the ECO, and it also informs many of the practices understood to be
part of the plan-based components of hybrid project management approaches.
• Rita’s Process Chart'”, a vital study tool that has helped many thousands of students prepare for the exam by
summarizing the detailed plan-driven approach to project management.
• Rita’s Agile Process Chart”, another vital study tool that will help students prepare for the exam by summarizing an
agile approach to project management.
• Agile Approach Overview.
• Hybrid Approach Overview.
• PMBOK* Guide, Seventh Edition Overview.
“Project Management Foundations” This chapter discusses basics like projects, programs, portfolios, and organizational
and project governance. It also discusses organization types, project selection, and project roles and responsibilities.
“Integration” This chapter discusses arguably the project manager’s most important job, which is to provide the necessary
leadership to bring the needs of many stakeholders and the work of team experts together into a cohesive whole to
successfully deliver the business value for which the project was selected to the organization and its stakeholders.
The next three sections of the book discuss the information you need to know for the exam from the combined
perspectives of the ECO domains, the Process Groups model, and plan-driven, agile, and hybrid practices. These
sections are:
Section III: The ECO People Domain

Section IV: The ECO Process Domain
Section V: The ECO Business Environment Domain
Section VI: How to Pass the First Time
This section of the book follows up on what you have learned, with instructions for continuing your studies until you are
prepared to sit for and pass the PMP exam. It includes the following chapters:
• “Tips for Passing the PMP* Exam the First Time”
• “Common Agile Methodologies”
• “Additional PMBOK* Guide, Seventh Edition Concepts”
Book Chapter Organization

Most of the chapters in this book have been organized the same way: an introductory discussion, a list of Quicktest topics,
an overview of the process, and review materials. This PMP* Exam Prep book can be used alone, but it is also part of our
PMP Exam Prep System that includes our PM FASTrack* Cloud exam simulator as well as our Hot Topics flashcards. With
your book purchase you receive access to our new tool, RMC Interactive Chapter Quizzes.
8
Each of chapters four through nineteen contains:

• Introduction and processes overview The introductory discussion provides key information for understanding
the material covered in the chapter and definitions of some key terms. The overview begins your understanding of the
main concepts and processes.
• Quicktest The list at the beginning of each chapter indicates the key topics covered in the chapter. To test your
knowledge of chapter content and to review what is most important, refer back to this list when you are finished with
each chapter. Use the Quicktest to test your knowledge of those topics and uncover your gaps in understanding.
• Graphic tables and process overview charts These outline key ECO tasks as they relate to the Process Groups
model, along with associated content from PMBOK* Guide, Seventh Edition. The process overview charts in the
Process domain chapters will give you a high-level graphic view of each process.
• Review materials and exercises This book contains extensive review materials and exercises within each of these
chapters, where applicable. These materials have been developed based on accelerated learning theory and an
understanding of the exam content.
The answers are listed immediately following the exercises. We have found that it is most effective to place the answers
right after the exercises rather than later in the book. Do not skip the exercises or go straight to the answers, even if their
value does not seem evident to you. The exercises and activities are key benefits of this book and will help you pass the
exam. Actively working with the information by doing the exercises on your own before checking the answers will better
prepare you than if you just passively read the answers.
Exercise Notebook For the exercises, you’ll be prompted to create and use an Exercise Notebook. While some people
will have our BMP* Exam Prep book in a printed form, many others will have access to our digital book. Because of this, we
encourage users to create a separate notebook (either physical or electronic) to record answers. The important thing is to
actively produce the answers to the exercises in a place you can come back to for review, and to make any other notes that
will help you review the material for the exam.
We have numbered each exercise and encourage you to record these numbers in your Exercise Notebook. Use this
tool to keep track of any gaps in your knowledge. Pay attention to any patterns in gaps. At any time, you may review your
notebook for anv incorrect answers or retrv an exercise.
Included in the review material are tricks to passing the exam called Tricks of the Trade*. These tricks are
designated by the image shown here to the left and will give you some extra insight about what you need to
know about project management and how to study for the exam.
Think About It. This icon indicates a section where you will be asked to slow down and really think through
a concept being presented. The “Think About It” sections will sometimes present a scenario and ask you to
consider how it should be addressed; other times it may present more information on the topic at hand.
Agile Focus When we delve into the agile aspect of a topic, this icon will appear next to the text. Use it to
easily find where agile concepts are being presented.
RMC Resources Web Page

New information about the exam is always emerging. RMC offers a web-based resource to help you
stay up-to-date on materials. Our RMC Resources web page (rmcls.com/rmc-resources or scan the https://rmcls.com/rmc-
QR code) is a robust study tool that provides supplemental material for you to work with as well as
errata and other updates to this book. RMC Resources includes interactive games, more in-depth
information on particular topics, a project management glossary, and more. As we observe trends
relevant to exam prep, we will publish additional materials on RMC Resources. Be sure to review the
materials at RMC Resources to see which items will be of most help to you in preparing for the
RMC RESOURCES
exam. We will refer to RMC Resources throughout the book where appropriate and provide the QR
code for easy access.
9
RMC Interactive Chapter Quizzes

The RMC Interactive Chapter Quizzes is an interactive tool with questions that pertain to chapters 2 through 15, which
allows you to review the material and test your understanding. Refer to the “How to Study for the PMP Exam” section on
page 22 to understand how and when to use these practice exams as part of your study plan. This tool will show you how
you scored on the chapter quizzes as you work with this tool.
The questions in the chapter quizzes are representative of the knowledge and principles tested on the exam. Keep in
mind that you cannot simply practice answering questions to prepare for the exam. The questions in the RMC Interactive
Chapter Quizzes help you assess your knowledge and become familiar with the types of questions on the exam. Make sure
to focus your study efforts on reading this book, doing the exercises and review activities, and filling gaps in your project
management knowledge.
10
What Is the PMP Exam Like?
Keep in mind three important things about the PMP exam. First, the exam is not a test of the information in the PMBOK*
Guide. Its questions are written by project managers with the PMP certification, based on real-world situations. Second,
while your real-world experience is essential to helping you pass the exam, you cannot rely on it alone. Third, training in
professional project management that is aligned with the ECO, the Process Groups model presented in Process Groups: A
Practice Guide, and the Agile Practice Guide is critical for exam success.
The exam includes 180 questions, all of which are situational. The questions may appear in one of five different
formats. These include multiple-choice, multiple responses, matching, limited fill-in-the-blank, and hot spot (e.g., you are
asked to place identifying plots on a chart). See the Question Examples section in this chapter for examples of these
question formats. The exam must be completed in 230 minutes, which is just under four hours. You will be given the
opportunity for two 10-minute breaks during which the exam timer pauses.
You will be scored on 175 of the 180 exam questions (since five are newly written “trial” questions that will not be
scored). PMI does not publish what it considers to be a passing score. Based on exam history, however, we estimate that it
is somewhere between 61 and 64 percent (about 110 to 114 questions correct out of 180).
The questions are randomly generated from a database based on how many questions must be included from a
particular content area (the ECO People domain, for example). One point is given for each correct answer, and of course,
you must accumulate enough correct answers to exceed the passing threshold.
The following table shows the percentage of scored questions on the exam for each Examination Content Outline
(ECO) domain.
Examination Content Outline (ECO) Domains Percentage of Questions

People 42%
Process 50%
Business Environment 8%
TOTAL 100%
The “PMP5 Exam Reference in Context” chapter contains more detail on ECO domains. PMI occasionally
makes changes to aspects of the exam, including the qualification requirements, the application
process, and the breakdown of questions in each domain. For the latest information, please visit
pmi.org and read the ECO, the Certification Handbook, and your authorization notice carefully. Any
differences between what is listed here and what is communicated by PMI should be resolved in favor
of the latest information posted on pmi.org.
Additional Important Aspects of the Exam

• The exam tests knowledge, application, and analysis. This makes the exam more than a test of memory. You must
know how to apply the information in this book and be able to analyze situations involving this information. Do not
expect the exam to have a majority of straightforward, definition-type questions.
• The exam deals with practical experience. Questions are based on a situation, described in each one. For those who do
not have the appropriate project management experience, these questions can be very difficult.
• There may be instances on the exam where the same data are used for multiple questions. You may also see data
repeated in answer choices.
• Many questions focus on “what should the project manager do” in the given question situation. It is important not just
to understand project management processes, but to understand the relationships of artifacts and methods related to
these processes.
•/ As you recognize a process on an exam question you should be able to bring to mind what artifacts
(sometimes referred to as inputs) and what methods you need as a project manager to carry out the process.
For example, in order to carry out a Manage Stakeholder Engagement process properly, you need a
stakeholder engagement plan (which is part of the project management plan for plan-based projects).
>/ You must also understand what artifacts you have as a result of a particular process once it is carried out
(sometimes referred to as outputs). A process often results in updates to some of the same artifacts you
needed to use to begin the process. For example, the stakeholder engagement plan (created during the Plan
Stakeholder Engagement process) is used and followed during the Manage Stakeholder Engagement
process, but the plan is also updated as a result of the Manage Stakeholder Engagement process.
■/ In addition to artifacts and methods for carrying out processes, you should understand the desired outcomes
of processes. In the previous example of the Manage Stakeholder Engagement process, there are artifacts
that result from the work, but you also have good relationships with your stakeholders, are able to manage
their expectations appropriate to project conditions, and therefore achieve stakeholder satisfaction with the
project and its results.
• Historically, there have been up to 6 or 7 formula-related calculations on the exam, but more recently there have been
only 1 to 3.
• Expect 7 to 10 earned-value questions on the exam. Note that most earned value questions focus primarily on your
understanding of the concepts behind earned value and not on performing calculations.
• Project management terminology often uses acronyms. Most acronyms will be spelled out (for example, the exam
typically uses the full term “work breakdown structure” rather than “ WBS”) Nevertheless, you should know both the
acronym and the full term for the exam.
• Most people feel uncertain about only 36 or fewer of the 180 questions on the exam. Concentrating on understanding
the concepts and being able to think holistically about these concepts will contribute to your confidence in answering
questions.
• The exam software has tools helpful in processing questions. For example, you can use:
y Mark for Review to tag questions you are unsure of, to come back to later before you submit the exam,
y Highlight parts of a question you think are most important to the situation and to selecting the right answer,
y Strikethrough parts of a question you think are least important to the right answer or are “distractors” that
will complicate your ability to correctly answer the question.
Question Examples
Questions on the exam are situational, meaning to answer them you must apply your knowledge and experience to the
given scenario rather than just giving a textbook response. Many questions are ambiguous. Questions often seem like they
have two or more right answers. Prepare for the following types of questions so you will not be caught off guard when you
are taking the exam.
12
1. Situational questions These demonstrate why project management experience and knowledge of good practices
are critical to passing this exam. Such questions require you to align your real-world experience with knowledge of
the exam concepts. For example:
Question The project manager receives notification that a major item they purchased for a project will be
delayed. What is the best thing for the project manager to do?
A. Replan the project to accommodate this delay.

B. Notify the project sponsor.
C. Let the customer know about it and talk over options.
D. Meet with the team and identify alternatives.
Answer D
2. Questions with two or more right answers Multiple choice questions that appear to have two or more right
answers are a major complaint from test takers. These questions, which list several choices that could reasonably
be done, require analysis and the process of elimination to find the best answer for the given scenario and
question details.
As you go through questions and review the answers in the RMC Interactive Chapter Quizzes, look for questions
you think have more than one right answer and try to figure out why you think multiple choices are correct. We have
intentionally included such questions in the RMC Interactive Chapter Quizzes to give you exposure to these types of
questions. We provide explanations to help you understand why your right answer may not be the best choice.
Let’s look again at the previous situational question. Couldn’t we really do all the choices? The right answer is D,
but isn’t it also correct to tell the customer? Yes, but that is not thefirst thing to do. This question is really saying, “What
is the best thing to do next?” or “What should the project manager do next?” As you answer practice questions, keep
in mind the concept of the “best thing to do next” to help you decide which answer identifies the project manager’s
responsibilities in the given situation.
Note: By “proper project management” we generally mean project management according to systematic and
agreed-upon good practices. More specifically for the exam, if we are talking about the order of activities within a
process, it should relate to how processes are described in the ECO domains, the Process Groups model, or the Agile
Practice Guide. We know that processes can vary in their order of activities but as PMI has sometimes been specific on
this, we will be specific as well. In other words, for the exam we mean “proper project management” according to PMI.
Be careful—this will sometimes not align with your everyday project management experience.
3. Questions with extraneous information Not all information in a question will be relevant.
Question Your next project involves managing an agile initiative to distribute new driver management software
to your firm's taxi fleet. At this point the project steering committee is debating whether to contract with a usability
testing service for the project. They ask for your input on whether this would be cost-effective. You reply that while
you don't have the specific data yet, as a general rule:
A. The most economical time to test would be near the end of the project when the screens are done and less
likely to change.
B. Finding issues earlier is always preferable since it is likely to save a lot of money in the long run.
C. Defects found by the developers are less costly to fix than those found in review or testing.
D. Testing the screens near the end of the project will leave little time to incorporate changes.
Answer B
In this example, the type of system being developed (driver management) doesn’t affect the answer. It is extraneous
information meant to distract you.
13
4. Questions using made-up terms Many people taking the exam expect that all the terms used as choices should
mean something. That is not the case. Answer choices sometimes include made-up terms. If you consider yourself
well prepared and see a term on the exam you do not know, chances are it is not the right answer. For example:
Question The WBS, estimates for each work package, and the network diagram are completed. The next thing
for the project manager to do is:
A. Sequence Activities
B. Develop Schedule
C. Validate Scope
D. Resource Simulation
Answer B
In this question “resource simulation” (choice D) is not a real project management term.
5. Questions where understanding is important. Let’s look at the following question:
Question The senior web designer on a project just came down with the flu in the middle of an iteration. What
should the project manager do?
A. Meet with the team to find out how much of the planned work will be done.
B. Ask the two other designers to work overtime this week.
C. Ask the product owner to postpone the product demo until the iteration goal is done.
D. Call the web designer's functional manager and ask for a new designer for the rest of the iteration.
Answer A
In order to answer this question, you must understand iteration timeboxes and how agile teams work.
6. Questions with a new approach to a known topic There will be many instances where you understand the topic
but have never thought about it as described. For example:
Question A product is being built iteratively on a new technology platform. When the project manager asks the
team members about the quality of the early product increments, they say "They're fine." How can the project
manager verify that the new technology is supporting the quality objectives of the project?
A. Ask the team to present performance testing results showing the actual vs. expected measures.
B. Ask the product owner how well the technology is delivering business value.
C. Present the quality management plan to the team's coach and ask if the technology is supporting the plan.
D. Bring in an auditor to assess the quality.
Answer C
Seeing the words “iterative” and “increments” should make you think this is an adaptive life cycle project but that
might steer you away from an answer referring to a management plan. Management plans can be used on adaptive
and hybrid project life cycles if the project manager sees value in the plan.
M
o n e Tricks of the Trade for Studying for the Exam
7. Questions with more than one item in each choice Let’s look at the following example:
Question The seller has presented the project manager with a formal notification that the seller has been
damaged by the buyers activities. The seller claims that the buyer’s slow response to the requested approvals has
delayed the project and has caused the seller unexpected expense. The first things the project manager should
do are:
A. Collect all relevant data, send the data to the company attorney, and consult with the attorney about
legal responses.
B. Review the contract for specific agreed-upon terms that relate to the issue, see if there is a clear response, and
consult an attorney if needed.
C. Review the procurement statement of work for requirements, send a receipt of claim response, and meet to
resolve the issue without resorting to legal action if possible.
D. Hold a meeting with the team to review why the acceptances have been late, make a list of the specific reasons,
and correct those reasons.
Answer B
These questions can seem hard until you apply this little trick. Use the process of elimination, one item at a time.
Consider the first item listed in each choice and eliminate the choices that contain an implausible first item, if
applicable. Then look at the second item in each remaining choice and eliminate any implausible choices. Keep
going until you have one choice remaining.
Watch out! Sometimes the items in each choice show a flow or process. See the following example to think about
how sometimes the items in each answer choice show a flow or a process:
Question A resource issue has come up on a construction project. Which of the following is the best way to deal
with the problem?
A. Go to the team, go to management, go to resources managers

B. Go to resource managers, go to management, go to the customer
C. Handle it yourself, go to the customer, go to management
D. Resolve problems with resources you control, go to resource managers, got to the customer.
Answer D
In this case you need to look at each choice independently to see if the process listed is correct.
8. Excessively wordy questions Instead of saying “The project is behind schedule,” the exam might use wordier
phrasing such as “The project float was zero and has recently gone to negative 2.” Instead of saying “The team is not
reporting properly,” the exam could say “The team has lost sight of the communications management plan.” The
first step in answering many questions is to determine what the question is really asking, and then to translate the
wordy phrasing.
15
Questions in Different Format Types

Our examples so far have used a typical multiple-choice format to point out specific characteristics of the way questions
are worded on the exam. Now take time to look at the other, newer question formats that are used on the PMP exam.
1. Multiple responses answer Questions using this format ask you to choose two or three correct answers, as in this
example:
Question Several stakeholders have different opinions about the product requirements. Which two of the
following techniques could the project manager use to bring the group to consensus?
A. Facilitated workshop
B. Interview
C. Backlog refinement session
D. Observation
E. Survey
F. Mind mapping
Answer A, C
2. Hot spot questions These types of questions show you a graphic on which you will have to click a “hot spot”
containing the correct answer:
Question Review the Burnup Chart. The team’s velocity has averaged 4.6 story points per iteration with 27
points completed. The project scope was increased during iterations 3 and 4 to a total of 48 story points.
Management would like the project scope to be completed by iteration 9. What should be the team goal for
iteration 7? Click on the diagram showing the next data point in the Work Accepted line.
Iterations
16
3. Matching question Questions in this format will give you two columns of concepts to match. In the following
example, the test taker would drag the cards in the “Action” column to to the center box that aligns with the “Order
in which to perform” column.
Question During a team retrospective, the project manager senses a conflict. In what order should the project
manager use the following actions to address the conflict?
Action Order in which to perform
Answer
4. Limited fill-in-the blank These types of questions will ask that you type the answer (represented by a blank
space in the question) in a box given:
Question Review the fishbone diagram for the problem: Increased customer complaints. Enter the letter
indicating the area that includes the possible causes of the problem related to people.
Answer C
17
Recurring Themes—PMI-isms to Know for the PMP Exam

RMC has been helping people pass the PMP exam and become better project managers for more than 30 years. During
that time, we have developed the following list of “PMI-isms” the exam assumes but many project managers do not know.
We suggest you read it now and then remember to reread it along with the Tricks of the Trade in this book, before you take
the actual exam. Assuming PMI-isms to be true (unless the question evidence says otherwise) will help you pick the best
answer from what seems like more than one correct answer. Look for PMI-isms in the “Quality of Deliverables and
Products” chapter as well. We have some there that are specific to quality. For the exam, assume that you have (or do) all
the following and that these concepts are true for your projects. As you review these PMI-isms, think about which ones are
true for your projects. If there are any that aren’t true for your projects, you may have a gap in your knowledge. It’s important
to make note of any gaps you may have and review these gap areas as part of your overall study plan.
Important: PMI represents project management practices along a range of approaches that are predictive, adaptive,
and hybrid (a combination of approaches). As you study these PMI-isms, keep in mind that a project manager should tailor
the approach to fit the needs of the project.
General PMI-isms
□ Without a skilled project manager, the vast majority of projects will fail. With a person educated in the skills of
project management, regardless of title, a project has a high likelihood of success.
□ The project manager puts the best interests of the project first—not their own interests.
□ The project manager understands the value of the principles, methods, models, and artifacts of project management
and knows how to adapt them to the type of project they are managing.
□ The project manager is assigned during project initiating (or sooner), not later in the project.
□ The project manager understands the process of project management (i.e., what to do first, second, etc., and why)
and has the ability to make proactive tailoring decisions.
□ Organizations have a formal project selection process, and they choose projects based on how well those projects
meet the organization’s and its stakeholders’ needs and strategic goals.
□ The project manager understands why their project was selected. They ensure while planning and managing the
project that the project delivers the benefits and value for which it was selected.
□ The project manager and team create a product and project vision and the project manager works throughout the
project to foster a common understanding of the product and project vision.
□ The project manager plans, manages, monitors and controls scope, schedule, cost, quality, risk, and resources,
using projects to deliver value to the organization and its stakeholders.
□ In an adaptive environment, the agile coach (or Scrum Master) ensures that the appropriate processes and tools
and techniques are well understood and being followed.
□ Agile teams are empowered to manage their own work according to objectives as prioritized by a product owner
(or value management team).
□ Teams are trained and coached by the project manager (agile coach, Scrum Master) for skills appropriate to the
approach being used on the project on which they are working.
□ Agile teams are coached to not just know agile processes but to “be” agile.
□ Each project is approached holistically and managed and executed as a value delivery system for the organization
and its stakeholders.
□ Team members are motivated, empowered, and engaged, and come prepared with suggestions; they don’t require
micromanagement from the project manager.
□ Organizations have a project management office (PMO), and that office has important, clearly defined
responsibilities regarding projects across the organization.
□ Organizations have project management policies, which the project manager complies with on their project. These
policies may include project management methodologies, risk procedures, quality procedures, and development
approach preferences.
18
□ Projects have a beginning and an end and are used to create unique solutions to solve particular business problems
and serve particular business needs.
□ A project may be part of a program or portfolio, and the projects relationship to other projects could significantly
influence how the project manager works.
□ Organizations keep records (e.g., historical information and lessons learned) from previous projects that include
planning artifacts and artifacts of the project’s actual results. The project manager uses these organizational process
assets to plan their project. The project manager then feeds their own projects records and lessons learned back
into the organizations knowledge base.
□ Organizational governance includes policies related to safety, diversity, and inclusion and a variety of other social
responsibilities meant to protect workers, stakeholders, the organization, and society at large. Project managers
proactively learn these and use them on projects.
□ Project managers and other organizational leadership are screened for and otherwise trained in, and practice,
emotional intelligence in relationships with the team and project stakeholders, as part of their leadership skills.
□ The project manager works within the existing systems and culture of a company (enterprise environmental
factors), and one of a project’s results is to provide input to improve those systems.
□ □□□ □□□□□ □□
Every project has a project charter, which authorizes the project and the role of the project manager.
Every project has adequately planned and executed transition of the product of the project to the customer (or
operations, for internal projects). The transition is an integral part of the Close Project or Phase process.
A work breakdown structure (WBS) and WBS dictionary are used on all plan-based projects. An agile project
manager uses a product backlog, a product roadmap, story maps, and stories.
A project management plan is a series of management plans. The project manager creates a project management
plan and other project artifacts tailored to the projects’ development approach and life cycle, and other specific
project characteristics.
The project manager keeps all project artifacts current to help manage and control a project.
Stakeholders are involved throughout the project. Their needs are considered while planning the project and
creating the communications management plan and the stakeholder engagement plan.
People must be compensated for their work and deserve a fair and positive environment in which they can
contribute their best work.
Agile project stakeholders are represented by a product owner as part of the team. Team members can see
stakeholder perspectives through the use of personas and other agile tools.
Agile team members engage daily with stakeholders either directly or through the product owner to design and
build the product, conduct iteration reviews, and then use iteration retrospectives as part of their own continuous
improvement process.
Gold plating (adding extra functionality) is not in the best interests of the project and should be prevented.
Projects are managed in a matrix environment in which tools and techniques are typically straightforward.
However, it’s important to know that concepts and tools such as motivation theories and conflict resolution may
become more complicated in alternate environments.
□ The project manager has a professional responsibility to properly use and tailor tools and processes appropriate to
the selected development approach and life cycle.
□ Project managers practice servant leadership to facilitate success of the team and the project. They are trusted
stewards of organizational and stakeholder resources and needs and carry out their responsibilities in the best
interests of both.
□ Stewardship for the project managers include holistic points of view and holistic practices to carry out their
financial, social, technical, and environmental responsibilities to the organization, its teams and stakeholders, and
the larger society.
□ Project managers are knowledgeable about the business environment and carry out their responsibilities related to
environmental factors affecting the project or factors that the project affects. 19
Planning the Project
□ All projects must be planned using planning processes tailored to the project.
□ In a predictive environment the project manager plans the project with input from the team and stakeholders.
Adaptive environments include the whole team to do the planning.
□ Planning involves selecting a project life cycle and development approach suitable for the project.
□ Each project constraint plus other factors important to project success (requirements and scope, schedule, cost,
quality, resources, communications, risk, procurement, stakeholder management) will be planned, managed, and
controlled. Plan length and detail may vary by size, complexity, and priority of the project as well as by
development approach.
□ In agile environments a project manager uses guidelines from an appropriate holistic and formalized methodology
established according to the performing organizations governance.
□ The project manager, team, and other appropriate subject matter experts determine quality measurement metrics.
□ The project manager plans for and practices continuous process improvement.
□ The project manager creates and uses a recognition and rewards system appropriate to each project.
□ The project manager clearly documents and assigns project roles and responsibilities with the help of the team.
These include reporting responsibilities, risk management assignments, meeting attendance, and project work.
Agile teams have generalizing specialists who are experts in one or more field but can and will help in other areas
where needed.
□ The project manager and team focus with rigor on identifying risks in alignment with the approach.
□ Team members and other stakeholders participate in risk identification and risk management responsibilities.
□ The project manager and team appreciate that managing risks saves the project time and money.
□ Project cost and schedule cannot be finalized without completing risk management.
□ Plan-based project management includes creating realistic schedules and budgets based on the project’s defined
scope. Agile project management entails being flexible with scope while keeping schedule and cost realistic
and fixed.
□ The project manager assesses whether a plan-based project can meet the end date(s) and other project constraints
and objectives. They meet with management to resolve differences before project work starts. The project manager
knows unrealistic schedules are their fault because they have tools and skills to help solve them.
□ The project manager for an agile project establishes the minimally viable product (MVP) that can be delivered
within the cost, schedule, and other project constraints. They provide plans for delivering the MVP in releases
through iterative and incremental product building and delivery.
□ The project manager plans when and how to measure performance against the performance measurement baseline,
as documented in the project management plan. They plan for other methods, like value stream mapping, to be
used to determine how the project and processes are performing while the work is being done.
□ The project manager plans for stakeholder engagement at all levels and creates tactics to establish and maintain
stakeholder engagement at the desired level for each stakeholder or group.
□ The project management plan is realistic, and everyone believes it can be achieved.
□ The project manager holds a kickoff meeting with the team.
20
o n e Tricks of the Trade for Studying for the Exam
While the Project Work Is Being Done
The project manager is responsible for facilitating documentation and knowledge sharing during the project.
The project manager measures against the project management plan to help determine project status throughout
the life of the project.
Projects are re-estimated throughout the life of the project to make sure the end date(s) and cost objectives will be
met. Therefore, the project manager almost always knows if the project can meet the agreed-upon end date(s)
and budget.
The project manager has authority and agency. They can say no and work to control the project for the benefit of
the organization and its stakeholders.
A change in scope must be evaluated for its impacts to the project’s schedule, cost, quality, risk, resources, and
customer satisfaction. The project manager has enough data about the project to do this analysis.
The project manager realizes that, over time, people associated with the project may have different understandings
about what the project is and what could occur during the project life cycle. The project manager is continually
facilitating a common understanding and appropriate expectations.
The project manager understands, and takes seriously, resource responsibilities on a project.
The project manager spends time on such activities as team building and ensuring high team performance.
The project manager is proactive, finds problems early, looks for changes, and prevents problems.
Risk is proactively managed. Most issues that occur have risk response plans to deal with them. Agile teams work
□ □□ □□□ □ □ □ □ □□ □□□□ □ □ □ □ □□
with a risk-adjusted backlog that includes risk response plans.

Risks are addressed at every team meeting.
Project meetings have planned agendas that are followed. Agile team meetings take the form of daily standup
meetings that are short and follow their set agenda strictly.
All changes to a project management plan flow through the change management process and integrated change
control (or its agile equivalent).
The project manager and team execute and control the project with the urgency needed to accomplish the goals
and objectives for which the project was undertaken.
The project manager ensures that the project is compliant with organizational governance and with any applicable
laws and regulations external to the organization.
The project manager recommends improvements to the performing organizations standards, policies, and
processes. Such recommendations are expected and welcomed by management.
Quality should be considered whenever there is a change to any component of the project.
Quality should be checked before an activity or work package is considered completed.
The project manager works closely with the quality department in performing some of the quality activities
discussed in Process Groups: A Practice Guide.
The project manager is actively involved with the procurement process and assists in managing procurements.
The project manager understands contract language.
The project manager makes sure all the terms of a contract are met, including those that do not seem important.
Closing the Project
□ No project is complete until the product is transitioned to the stakeholders, and training has been provided on use
and maintenance of the product to realize its benefits, as needed.
□ No project is complete until there has been final acceptance from the customer.
□ All projects produce a final report that gives the project team a chance to announce the project objectives have
been met.
□ The project manager and team ensure that all project records are updated and archived.
Which items in this list seem different from the way you or your organization manages projects? Which of these items
do you not understand? Review this list when you think you are finished studying. Pay particular attention to those items
that aren’t true of your projects. Are there any items you need to think about more to make sure you will remember them
when you take the exam? Knowing these PMI-isms can make a significant difference. Most students have everyday project
management experience that differs from a good number of these PMI-isms, making this a significant gap that students
need to bridge before taking the exam.
How to Study for the PMP Exam

Some people believe you need to read every known resource available, watch lots of videos and spend as much time as
possible preparing for the PMP exam. Do not make that mistake. You should not read everything you can find, as some
resources are not well vetted. We recommend the approach outlined in the following sections.
The Magic Three Studies have shown that if you visit a topic three times, you are more likely to remember it. Read this
book once and then skim through it two more times, focusing most on the activities you do not do in the real world and on
the concepts you have trouble understanding or remembering. You should document these as you work through this book
as they represent the gaps in your knowledge and understanding to fill before the exam.
Be in Test-taking Mode Get used to jumping from one topic to another. You’ll also need to practice answering questions
for four hours. You can do this by waiting to do any chapter quizzes until you feel ready to answer the questions. Then take
all of RMC Interactive Chapter Quizzes in one sitting (see step 4 in plan B on page 24). Do not underestimate the
physical, mental, and emotional aspects of taking an exam lasting that long. You can also get into test-taking mode using
our PM FASTrack® exam simulator.
Your Step-by-Step Study Plan

We recommend that you use one of the following study plans. Follow Plan A if you own RMC’s complete PMP Exam Prep
System (This PMP* Exam Prep book, the PM FASTrack® Cloud Exam Simulator license, and Hot Topics). Follow Plan B if
you own only the book and not the entire system.
Plan A: Using This Book with the PMP Exam Prep System
(PMP® Exam Prep book, PM FASTrack® Cloud Exam Simulator, and Hot Topics)
One common mistake people who purchase the PMP® Exam Prep System make is to spend most of their study time
answering questions in PM FASTrack®. This approach won’t work. As we mentioned earlier, focus your efforts on reading
this book, completing the exercises and review activities, and filling the gaps in your applicable knowledge of proper
project management practices for plan-based, agile, and hybrid projects. Use the following steps to study this book along
with PM FASTrack® and Hot Topics:
Read this book for the first time and complete the exercises. Spend more time on the areas where you recognize you
have knowledge or experience gaps; items you did not know or do prior to beginning this course of study. Refer to Rita’s
Process Chart™ and Rita’s Agile Process Chart™ frequently (included in chapter 3 of this book). Be sure you understand all
the efforts involved in the topics you are working on. Use the ECO as directed in each of the ECO domain chapters to
become comfortably familiar with the ECO content by the time you are finished with this book.
22
1. As you finish each chapter, review the Quicktest at the beginning of the chapter. Make sure you know the meaning
of each concept. Use Hot Topics to improve recall and test your knowledge of each chapter.
2. If possible, form a study group after you have read the book for the first time on your own. Your study time will be
more effective. You will be able to discuss content together and the studying (and celebrating afterward) will be
more fun. A study group should consist of only three or four people. (See How to Use This Book in a Study Group
on page 25.)
3. Skim through this book again, reviewing areas where you are not confident with the content.
4. For these areas you reviewed because you had less confidence, answer a small sample of questions (no more than
20) using the Focused Test function in PM FASTrack*. Analyze why you answered questions wrong and continue
to study these gap areas. PM FASTrack* helps with this by allowing you to download a spreadsheet of the questions
you got wrong. It is called “Export Analysis Data” in PM FASTrack*.
5. When you feel you are prepared to do so, take a full exam simulation on PM FASTrack*. This step will give you a
baseline against which to track your progress as you continue to study.
WARNING: Limit yourself to no more than two full exam simulations before you take the actual exam.
Otherwise, you diminish the value of PM FASTrack* by memorizing questions and answers that will not be
presented in the same way on the exam.
WARNING: If you do not score 70 percent or more the first time you take a full exam simulation (not just a
shorter exam on a single content area or ECO domain), you may need a refresher in basic project management
concepts. If you have taken a project management fundamentals class, review the materials you received from
that class. If you have not had this class, consider taking one. Or you may need a PMP Prep class. Contact us
using the information on rmcls.com/contact-us/. We can help assess your needs.
6. Review each question you got wrong in PM FASTrack*, recording the specific reasons for each wrong answer.
Assess why the correct choice is correct and why the other answers are wrong. In PM FASTrack*, we explain the
answers and give references to help you quickly return to the related content. Use the “Export Analysis Data”
within FASTrack to download a spreadsheet of questions you got wrong.
7. Use your list of why you got each question wrong (from the previous step) to determine what to study further. This
will help you determine how much more study time you need and which content areas to review more carefully.
Continue to study this book, focusing on areas in which you have more gaps and skimming sections or chapters on
which you did well. For chapters you need to review, always start by reviewing the Overview sections of the
chapter, where we map the ECO to other PMI resources and point out important aspects of ECO domain tasks.
And remember, think about good project management practices according to PMI as discussed in this book and
based on approaches along the plan-driven, agile, and hybrid spectrum. Do this regardless of how you manage your
projects in the real world.
8. For the topic areas where you had the most trouble, review these again. Then you may want to answer a small
sample of questions (no more than 20) using the Focused Test function in PM FASTrack*1. Analyze why you
answered questions wrong and continue to study gap areas.
WARNING: You might be tempted to answer more than 20 questions, but this should be sufficient to assess
your progress in the particular content area and whether you need to study more. Answering more than 20
questions in a particular area can diminish the value of PM FASTrack* and will not prepare you for the breadth
of the exam experience.
9. Take your second and final PMP simulation exam. You should score over 75 percent before you take the real exam.
You are overusing PM FASTrack* if you see many repeated questions.
10. Use Hot Topics and other materials to continue to review the content until you take the exam.
11. Create your test strategy (see the “Tips for Passing the PMP Exam the First Time” chapter).
12. PASS THE EXAM!
Plan B: Using This Book As a Stand-Alone

(PMP* Exam Prep book, RMC Resources, RMC Interactive Chapter Quizzes)
Read this book for the first time and complete the exercises. Spend more time on the areas where you recognize you
have knowledge or experience gaps; items you did not know or do prior to beginning this course of study. Refer to Rita’s
Process Chart7” and Ritas Agile Process Chart7” frequently (included in chapter 3 of this book). Be sure you understand all
the efforts involved in the topics you are working on. Use the ECO as we direct in each of the ECO domain chapters, to
become comfortably familiar with the ECO content by the time you are finished with this book.
1. As you finish each chapter, review the Quicktest at the beginning of the chapter. Make sure you know the meaning
of each concept.
2. If possible, form a study group after you have read the book for the first time on your own. Your study time will be
more effective. You will be able to discuss content together and the studying (and celebrating afterward) will be
more fun. A study group should consist of only three or four people. (See “How to Use This Book in a Study
Group” on page 25.)
3. Skim through this book again, reviewing areas where you are not confident with the content.
4. Once you feel confident about the material, take the interactive RMC Interactive Chapter Quizzes in one sitting.
This will give you a baseline to tell you how much you have learned. It will also help you determine how much
additional study time you need and which chapters to read more carefully.
5. Review each question you got wrong in RMC Interactive Chapter Quizzes, writing down the specific reasons for
each wrong answer. Assess why the correct choice is correct and why the other answers are wrong. Review each
question you got wrong in RMC Interactive Chapter Quizzes, recording the specific reasons for each wrong
answer. Assess why the correct choice is correct and why the other answers are wrong. In RMC Interactive Chapter
Quizzes, we explain the answers and give references to help you quickly return to the related content. RMC
Interactive Chapter Quizzes help with this by allowing you to download a spreadsheet of the questions you got
wrong (it is called “Export Analysis Data” within the RMC Interactive Chapter Quizzes tool). Continue to study
this book, focusing on the areas in which you have gaps in your knowledge and skimming the sections or chapters
on which you did well.
6. Correct any errors in your understanding of the concepts discussed in this book.
WARNING: If you do not score 70 percent or more the first time you take the RMC Chapter Quizzes, you
may need a refresher in basic project management concepts. If you have taken a project management
fundamentals class, review the materials you received from that class. If you have not had this class, consider
taking one. Or you may need a PMP* Prep class. Contact us using the information on rmcls.com/contact-us/.
We can help assess your needs.
7. Make sure you really know the material, and then retake the RMC Interactive Chapter Quizzes. As with step 5, use
downloaded spreadsheet from the tool to identify the specific, not general, reason you got each question wrong.
8. Use your list of why you got each question wrong (from the previous step) to determine what to study further. This
will help you determine how much more study time you need and which content areas to review more carefully.
Continue to study this book, focusing on areas in which you have more gaps and skimming sections or chapters on
which you did well. For chapters you need to review, always start by reviewing the Overview sections of the
chapter, where we map the ECO to other PMI resources and point out important aspects of ECO domain tasks.
And remember, think about good project management practices according to PMI as we discuss in this book and
based on approaches along the spectrum of plan-based, agile, and hybrid. Do this regardless of how you manage
your projects in the real world.
9. Create your test strategy (see the “Tips for Passing the PMP* Exam the First Time” chapter).
10. PASS THE EXAM!
How to Use This Book in a Study Group

To get started, pick someone to lead the discussion of each chapter (preferably someone who is not comfortable with the
chapter, because the presenter often learns and retains the most in the group). Each time you meet, go over questions about
topics you do not understand and review the hot topics on the exam using the Hot Topics flashcards ifyou have them. Most
groups meet for one hour per chapter. Either independently or with your study group do further research on content you
are not confident with questions you answered incorrectly in RMC Interactive Chapter Quizzes or PM FASTrack*.
Each member of the study group should have their own copy of this book, which can be used within the group to
make study and discussion commitments for group sessions. (Please note that it is a violation of international copyright
laws to make copies of the material in this book or to create derivative works from this copyrighted book.)
25
26
Section II
Foundations
In this section, you will learn the foundations of project management. First, we will guide you through key PMI references
and how they relate to the exam. Then, we will discuss predictive, hybrid, and adaptive approaches to project management.
You’ll find out how projects are selected and what the roles are on a project. Here are some highlights of this section:
• Predictive and agile approach overviews

• Plan-based process groups: initiating, planning, executing, monitoring and controlling, and closing
• Agile processes: feasibility, initiation, release planning, iterations and product release, and closing
• Rita’s Process Chart (a valuable study tool when learning about plan-based projects)
• Rita’s Agile Process Chart (when learning about agile projects)
• How project management relates to the organization
• How projects are selected
• Project roles and responsibilities
• What integration means and how it is a key part of managing a project
27
28
QUICKTEST
• Rolling wave planning
PMP® Exam References • Progressive elaboration

• Examination Content
Outline (ECO)
- People
in Context -
-
Process
Business Environment
• Process Group model
- Initiating
- Planning
- Executing
Introduction - Monitoring and
Controlling
In this chapter we provide an overview of the Process Groups model for plan-driven (or predictive) - Closing
project management, an agile model overview for adaptive project management, and an overview of • Phase gates
possible hybrid models of project management. This chapter also explains the relationships between • Rita’s Process Chart™
groups of concepts presented in this book, and what you need to know about these concepts for the • Agile process
exam. We provide an overview of PMI’s Examination Content Outline (ECO), the PMBOK* Guide, Sev - Feasibility
- Initiation
enth Edition, and Agile Practice Guide. While PMI says the exam is based on the ECO, our research tells
- Release Planning
us there are also questions on the exam based on content in these references.
- Iteration
We will ask you to look at the ECO periodically in reference to something specific being discussed. - Close-out
If you have not yet downloaded a copy of the ECO from PMI’s website, do that now. It will be a good • Rita’s Agile Process
reference tool as you read this book. Feel free to refer to it as you complete exercises too. Chart™
• Personas
PMI publishes a copy of its suggested reference list on its website, and it is a long list of publica
• Product release
tions. Does this mean you have to read all these books? No! The good news is that we have done the
• Hybrid project
research for you and the information you need to pass the exam is in this book. We suggest that you
management
obtain copies of the PMBOK* Guide, Seventh Edition, Process Groups: A Practice Guide, and Agile • Value delivery system
Practice Guide. If you have a PMI membership, you can access electronic copies of these books for no
additional charge on PMI’s website. You can also purchase a hard-copy of the PMBOK* Guide on
RMC’s website.
You will not need to read these cover-to-cover. Instead, think of them as resource guides that you
browse or open to a certain page to look up something specific. The most important information from
each of those resources is summarized in this book.
Definitions Related to Planning

We will start with the following definitions to remind you, as you read this chapter and the rest of the
book, that planning is iterative, regardless of what project life cycle and development approach you
have selected with which to manage a project.
Rolling Wave Planning and Progressive Elaboration

Have you ever worked on a project that seemed to have too many unknown components to adequately
break down the work and then schedule it? Or the project will have phases and it makes more sense to
plan some later phases in detail at a later time? Even in a predictive environment, it is often better to
not plan the entire project to the smallest detail in advance. Instead, it is sometimes better to just plan
at a high level and then develop more detailed plans when the early project work is being done. This
practice is called rolling wave planning. It is a form of progressive elaboration.
Progressive elaboration refers to the process of clarifying and refining plans as the project
progresses and more information becomes available. With this common tailoring method, you plan
activities in the detail needed to manage the work just before you are ready to start that part of
the project.
Iterations of rolling wave planning during the project may result in additional activities being
added, and in the further elaboration of other activities. Therefore, rolling wave planning may create
the need for updates to the project management plan and other project artifacts. Since the earlier
version of the project plan is usually already baselined, these changes often require formal change
requests and integrated change control.
29
PMP® Exam References in Context TWO
Examination Content Outline (ECO) Overview

Hie Examination Content Outline (ECO) organizes the exam material into three performance domains:
• People
• Process
• Business Environment
Each domain lists a number of tasks, which taken together, summarize the responsibilities of a project manager within
that domain. The order of the performance domains and the tasks within them are not important. In this book we organize
the domains and tasks in terms of where they most make sense for what you need to know and what part of the project
management process we are talking about. We include domain and task numbers to make it easy for you to find them in
the ECO.
The following overview will help you with a basic understanding of what the ECO includes. We will include specific
content from it in proper context throughout this book.
The domain names will not be tested on the exam but you should understand their tasks and enablers as they relate
to managing projects in both adaptive and predictive environments. You can use the domains to manage your study time
since PMI states that 42% of the exam is based on the People domain, 50% of the exam is based on the Process domain,
and 8% of the exam is based on the Business Environment domain. As you study, identify your gaps in each domain so you
can focus your time on filling those gaps before the exam.
Domain I: People
The People domain concerns skills and methods that help you succeed as a project manager and that you can use to help
others succeed on projects. These include servant leadership, team building, motivation, and conflict management. We will
focus on specific tasks listed in the ECO, appropriate to each of the following chapters. To start, here is a good list of
“people skills” a successful project manager needs:
• Active listening • Facilitation • Personal integrity and
• Adaptive leadership • Individual trust building
• Coaching and mentoring performance evaluation • Rewards and
• Collaboration • Negotiation recognition systems
• Conflict resolution • Participatory decision making • Team performance evaluation

• Team development • Understanding of motivation
• Emotional intelligence
Domain II: Process

The Process domain includes the technical project management skills, methods, and the activities needed to manage a
project and deliver the benefits for which the project was undertaken. People work together in this effort—the project
manager and team—so wouldn’t you expect to be using skills and abilities from the People domain? Of course! You lead
the organization of the project and facilitate the development of its product with these skills alongside a balanced
understanding of the business environment in which you are operating.
The tasks in the Process domain involve managing many of the processes you have probably already handled in your
experience as a project manager. They include the management of the following project management processes, along with
the integration of all aspects of the project and other related tasks:
• Communications • Procurement • Scope
• Budget and Resources • Risk • Stakeholder engagement
• Quality • Schedule
Managing project governance, artifacts, issues, changes, the use and transfer of lessons learned, and product turnover
to operations are also part of this domain. Once the project has been closed and turned over, a key measure of success is
the continuation of the projects value and benefits (also part of the Business Environment domain).
so
TWO PMP@ Exam References in Context
Domain III: Business Environment

Projects occur within the larger organization and business environment. Let’s say you have the skills associated with people
and experience with project management processes. You also need to know how to navigate the internal and external
business environments. You probably know this, but you may not have thought about it as a separate factor in your success.
The presentation of the business environment as a separate ECO domain helps you focus on understanding the
organization in which you work and the environment in which it does business. Understanding the business and
environmental factors are critical to accomplishing project objectives for the betterment of your organization and its
stakeholders. Let’s take as an example the task of evaluating and delivering project benefits. You can only accomplish this
task if you use skills related to the People and Process domains together with a complete understanding ofyour organization’s
culture, processes, and practices, and of the external, cultural, and legal environments in which they operate.
As another example, let’s say that as part of renovating a library, the project manager plans to work with the city on
enhancing transit options for getting to the library. Then they hear that a new highway interchange will be built nearby with
a major transit hub included. This will affect the project in a number of ways. Organizations evaluate the external business
environment during project selection. Then the project manager continuously monitors the business environment as they
plan, execute, and control the project to ensure that environmental changes do not negatively affect project objectives.
The Process Groups Model Overview

PMI recently released its Process Groups: A Practice Guide, to explain its Process Groups model. The Process Groups model
content originated in previous editions of the PMBOK* Guide, so it is familiar to many project managers that have used
previous editions of the PMBOK* Guide.
The Process Groups model describes a prescriptive or plan-driven approach to project management. Much of the
information in the Process Groups model can be used as a learning model for project management in general. It is with
good reason that the Process Groups model is so widely used today, and that we include it in this book. It is a good and
comprehensive model for prescriptive project management. In addition, over many years, through PMI’s propagation of it
in previous editions of the PMBOK* Guide, organizations throughout the world have adopted it and tailored it to their own
needs. So many thousands of project managers are familiar with some form of this model. More important yet:
Understanding it will greatly enhance your ability to answer many of the 50% of questions based in predictive environ
ments. In addition, this model is useful in many hybrid project management approaches across the approach spectrum. For
these reasons we use it extensively in this book as a learning model.
Process Groups
The Process Groups model starts with five process groups that in a general way describe how a project is managed, from
beginning to end. These process groups are:
• Initiating
• Planning
• Executing
• Monitoring and Controlling
• Closing
For now, you may draw the conclusion that to manage a project you would follow the process groups from initiating
to planning, executing, monitoring and controlling, to closing, one after the other, from the beginning to the end of the
project. You would be right—but only partly right. While the process groups generally lead you in order from the beginning
to the end of a project, at the same time you carry out the activities associated with them in a very dynamic fashion,
sometimes going back and forth between the process groups.
The real story is that project management is a very dynamic process that cannot be adequately described as a linear
progression through these processes, although understanding its linear progression is useful. The process groups order the
progression through a project. But at the same time, an activity belonging to one process group might cause a return to an
“earlier” process group to respond to a request, carry out an activity, or solve a problem.
SI
Understand the rest of this section and you will be well positioned to understand the Process Groups model and the
processes within it, as we explain them further, especially in the Process domain section of this book. You will also
understand how everything fits together to help you manage plan-driven projects successfully—and, of course, to answer
related questions on the exam.
Figure 2.1 shows generally how the five process groups interact on a project. You have the overall initiating effort,
followed by planning. Notice the double-arrows between planning, executing (where we are building the product), and
monitoring and controlling (where we are observing and assessing activities to keep things on track). These double arrows
are meant to indicate the dynamic, non-linear nature of much of project management work. For example, something that
happens in executing and monitoring and controlling, like a change in product scope, may send you back to planning in
order to replan to accommodate that change. Many changes like this occur on projects after initial planning is “complete.”
Now notice two more important things about figure 2.1. First, there’s a dotted line representing the directional arrow
going from monitoring and controlling, back to initiating. This broken arrow is there to remind you that returning to
initiating is not a given. In fact, once you leave initiating, it is only under limited circumstances that you would return to
initiating. See figure 2.6, where we show those limited circumstances to you.
The second important thing to note right now is that there are two components in figure 2.1 representing “M&C,” or
monitoring and controlling. The M&C inside the smaller circle represents monitoring and controlling as a process you
carry out along with the others, roughly following the start of executing. The larger, shaded circle also labeled M&C
signifies that you are monitoring and controlling throughout the project. No matter what other activities you are carrying
out, from whatever process groups, you should also be monitoring and controlling the situation.
Key:
I = Initiating
P = Planning
E = Executing
M&C = Monitoring & controlling
C = Closing
FIGURE 2.1 Project management process
The five process groups interact with the selected

project life cycle, shown at the top of figure 2.2. Small
projects following a plan-driven life cycle may be
completed after going through all the process groups
(initiating through closing) once for the entire project,
although portions of the processes may be iterated or
repeated throughout the project life cycle as shown in
figure 2.2.
Large projects often require the project manager
to manage each life cycle phase iteratively through the
project management process groups.
FIGURE 2.2 Small project with a predictive life cycle
The example illustrated in figure 2.3 is for a large construction project. In this large project, the development life cycle
phases of feasibility, planning, design, construction, and turnover are all extensive, requiring revisiting the five process
groups for each phase. For example, there would be an overall initiating effort in which the project manager helps create a
charter and does high-level planning for the entire project to get charter approval. Then, a separate initiating process for the
J5
TWO PMP® Exam References in Context
feasibility phase would take place, followed by a planning effort for that phase, the execution and control of that work, and,
finally, a closeout of the phase, which typically includes a handoff of deliverables—in this case, the results of the feasibility
analysis. This would be repeated for each life cycle phase.
FIGURE 2.3 Large project with a plan-driven approach and phase gates (indicated by the vertical bars)
Phase Gates At the end of each phase, an event called a phase gate may take place. A phase gate involves analyzing the
results of the completed phase against what was planned for that phase. Based on that analysis, options may include redoing
the same phase, moving forward with the next phase, or choosing not to continue with the project. If the decision is made
to move forward, the project would begin initiating work on the next phase and progress through the project management
process groups for that phase.
Projects may also be broken into phases and then into smaller releases and iterations within those phases. The project
management processes of initiating, planning, executing, monitoring and controlling, and closing are done for each phase.
The level of detail and the time spent on each process group may vary, but the entire project management process is
typically followed, as indicated in figure 2.4, which depicts the plan-driven process groups with an agile approach. This
could be a project using a strictly agile approach, or a hybrid project using project management methods from both plan-
driven and agile approaches.
Initiation
FIGURE 2.4 Large project with an agile approach
Agile approaches usually don’t include the use of the term “phase.” The traditional “phase gate” system is
TRICKS
OF THE different from an adaptive environment where iterations tend to be short and include product reviews (demos)
TRADE® and retrospectives. The overall process is usually more flexible and evolves throughout the project.
Looking at figure 2.4 again, where in the life cycle do you think are opportunities for using a hybrid approach?
TRICKS While the entire life cycle may look adaptive, at the “release” level you can see an iterative approach is most
OF THE
TRADE obvious. It’s most likely during feasibility, initiation, release planning, and close-out that you’d weave in
predictive elements if you chose to do so.
The illustration that appeared in figure 2.1 is shown again here in figure 2.5 for your reference as you read the rest of
this section and continue to understand the project management process through the process groups.
PMP® Exam References in Context
Start Here: Take time to fully understand figure 2.5

before continuing.
• Arrows move clockwise from Initiating (I). The
process moves mostly in order from Initiating
(I) through Planning (P), Executing (E),
Monitoring & Controlling (M&C), and Closing
(C).
• Double arrows between Planning (P),
Executing (E), and Monitoring and
Controlling (M&C) process groups show that
you often move back and forth between them as
you tailor to events taking place. New
information becoming available in executing
(E) may return you to planning (P).
• The single dotted arrow returning from FIGURE 2.5 Project management process
monitoring and controlling (M&C) to initiating
(I) indicates that only under limited
circumstances you may enter initiating once
you leave it (see figure 2.6).
Keep in mind that monitoring and controlling is carried out from start to finish on the project. Remember for the exam:
Work in all other process groups takes place in the context of ongoing monitoring and controlling.
The following figures illustrate the reasons for entering the various process groups. Remember, project management
is not linear. For example, project planning can be entered into because the results of project monitoring and controlling
necessitates additional planning.
FIGURE 2.6 Reasons for entering project initiating FIGURE 2.7 Reasons for entering project planning
FIGURE 2.8 Reasons for entering project executing FIGURE 2.9 Reasons for entering project closing
Let’s stop here for a moment to talk about the executing process in a predictive environment versus an
adaptive environment. The plan-driven approach to executing is to “go do the items identified in the project
plan” and update the project plan baseline if changes occur. These changes may be necessary due to
unanticipated issues and risks in activity durations and resource productivity or availability, or for other
reasons. We assume that to a certain extent planned activities are fully understood prior to starting work and
are completed according to the plan, even though that is not always the case.
Agile methods employ an executing approach in which additional efforts may be made to replan some or all of a
project. This is due to the nature of projects that may require a lot of change because project and product scope are
emerging. We assume all aspects of work are not known in advance and learning with adaptation will be necessary to
complete the project, either because of technical uncertainty or changes to requirements.
We are showing you monitoring and controlling last because its relationships to the other process groups are more
intricate. Think about these relationships as you study for the exam. Many students struggle to define what happens during
monitoring and controlling versus other process groups, especially executing. Figure 2.10 illustrates key project outputs
(on the left) that trigger a focus on monitoring and controlling. It also shows (on the right) that you may tailor your
processes to go from monitoring and controlling to any of the other process groups, depending on the situation.
FIGURE 2.10 Key outputs that trigger monitoring and controlling, and potential next steps
35
One reason test takers often find monitoring and controlling to be particularly challenging is that you are expected to
know how to observe, measure, evaluate, and analyze a project in a more complete and systematic way than many project
managers have experience with.
Monitoring and controlling applies to both agile and plan-driven projects. However, it is useful to think
in terms of plan-driven approaches to understand the work of this process group for now because agile
practitioners tend not to use the language associated with the five process groups, like “monitoring and
controlling.” Nevertheless, just as plan-driven project managers and teams do, agile practitioners measure
project and team performance as the product is being built. They also adjust the plan or their actions to remain in line with
the plan, as needed.
Agile approaches use different techniques for controlling, with more demos and feedback rather than tests to
specification, but the goal of adjusting the product and processes as needed is the same. These environments, which have
a high amount of change, usually handle evaluating and approving project changes through the role of a product owner. By
putting the product owner in charge of the backlog, an agile team delegates the authority for local decision making to this
team member to streamline the change control process.
The iteration review and the retrospective that follow an agile iteration are indicative of the experimental and learn-
as-we-go nature of agile projects. These are “measure and control” efforts although the term “monitoring and control” is
not used. Special iterations (sometimes called spikes) can be created specifically to try new technology or test new process
changes. These short cycles provide important feedback on what is working and what needs further tuning.
Project Constraints and Other Management Areas

You will see a lot of discussion in this book about both the ECO and the Process Groups model. Both represent the
processes you are managing in project management. Figure 2.11 compares the main content of the ECO Process domain
with that of the Process Groups model, with a symbol between them illustrating their rough equivalence as we have
mapped it. Take a moment now to open your ECO so you may read the integration-associated tasks.
ECO Process Tasks (Domain II) Process Groups Model
Integration
Integration Management
(Tasks 1,9,10,12,13,14 16,17)
Plan and manage scope

& Scope Management
Plan and manage schedule

&
£
Schedule Management
Cost Management
Plan and manage
r
budget and resources
Resource Management
Plan and manage quality

of products/deliverables & Quality Management
Manage Communications
& Communications Management
Assess and manage risks &

Manage project issues & Risk Management
Plan and manage procurement

& Procurement Management
Engage stakeholders
& Stakeholder Engagement
Note: The “budget and resources” Process domain task is comparable to costand resource management
in the Process Groups model. “Human resources” (or soft) skills are addressed in the People domain.
FIGURE 2.11 Relationship between ECO Process domain and Process Groups model
lb
Rita’s Process Chart™: A Vital Study Tool

We are here to help you really learn plan-driven project management with the Process Groups model! Since the first edition
of this book, people all over the world have used Rita’s Process Chart™ as a tool to learn this project management process
in detail, quickly and effectively. Once you understand it, you can use Rita’s Process Chart™ to initiate, plan, and run a
plan-driven project, and many of its concepts can also be applied on agile and hybrid projects.
On the exam, although you may not have to identify specific process names from Process Groups: A Practice Guide,
knowing where you are in the project management process when you read a question’s scenario will help you get the
right answer.
How to Use Rita’s Process Chart™

Located on page 38, Rita’s Process Chart’s™ function is to state, simply and directly, the efforts involved in managing a
project. Understanding these efforts will provide the context you need for the exam.
As you review Rita’s Process Chart™, make sure you:
• Understand the overall project management process.
• Find terms you do not know and learn what they are by looking them up in this book.
• Know why each item is in the column (process group) it falls into.
• Understand the project management process groups of initiating through closing, including when each effort should
be done on projects. The exam asks questions that present a situation and require you to know where you are in the
project management process.
• Can replicate the specific order of the planning activities by understanding what happens when, how previous work
supports what comes next and why. Use Rita’s Process Chart™ Game (discussed later in this chapter) for this.
Knowing Rita’s Planning column in this order can help you get a large number of questions right on the exam because
the exam often asks what should be done next. The work in the other process groups does not have a set order.
• Understand that project planning is an iterative process. Consider how you might go back and redo (iterate) some of
the items in the Planning column to refine the plan. Think about how rolling wave planning (a form of progressive
elaboration) would be used on a large project to refine and detail plans for each phase as you move through the project
life cycle. Here, the earliest parts of the project are planned in sufficient detail for work to begin. Later phases of work
are planned at a high level. As the project progresses, and more information impacting the work becomes available,
plans are elaborated in sufficient detail to accomplish the work.
• Complete Rita’s Process Chart™ Game at least three times. Repeating the game will re-enforce your understanding
of the overall project management process and help you find your knowledge gaps. Focus your study on your gap areas
so you fill those gaps before taking the exam.
57
Rita’s Process Chart™
INITIATING PLANNING EXECUTING MONITORING & CLOSING

(This is the only process group
Select project manager Execute work according to the CONTROLLING Confirm work is done to
with a set order.)
project management plan requirements
Determine company culture Take action to monitor and
Determine development
and existing systems Produce product deliverables control the project Complete final procurement
approach, life cycle, and
how you will plan for each (product scope) closure
Collect processes, procedures, Measure performance against
knowledge area performance measurement
and historical information Gather work performance data Gain final acceptance of
baseline product
Define and prioritize
Divide large projects into Request changes
requirements Measure performance against
phases or smaller projects Complete financial closure
Implement only approved other metrics in the project
Create project scope statement
Understand business case and changes management plan Hand off completed product
benefits management plan Assess what to purchase and
Continuously improve; Analyze and evaluate data and Solicit customer’s feedback
create procurement documents
Uncover initial requirements, perform progressive performance about the project
assumptions, risks, constraints, Determine planning team elaboration
and existing agreements Determine if variances warrant Complete final performance
Create WBS and WBS Follow processes a corrective action or other reporting
Assess project and product dictionary change request(s)
feasibility within the given Determine whether quality Index and archive records
constraints plan and processes are correct Influence factors that cause
Create activity list
and effective change Gather final lessons learned
Create measurable objectives Create network diagram and update knowledge bases
and success criteria Perform quality audits and Request changes
Estimate resource requirements issue quality reports
Develop project charter Perform integrated change
Estimate activity durations Acquire final team and physical control
Identify stakeholders and and costs resources
determine their expectations, Approve or reject changes
interest, influence, and impact Determine critical path Manage people
Update project management
Develop schedule Evaluate team and individual plan and project documents
Request changes performance; provide training
Develop budget Inform stakeholders of all
Develop assumption log change request results
Hold team-building activities
Determine quality standards,
Develop stakeholder register Monitor stakeholder
processes, and metrics Give recognition and rewards
engagement
Determine team charter and all Use issue logs
roles and responsibilities Confirm configuration
Facilitate conflict resolution compliance
Plan communications and
stakeholder engagement Release resources as work is Create forecasts
completed
Perform risk identification, Gain customers acceptance of
qualitative and quantitative Send and receive information, interim deliverables
risk analysis, and risk response and solicit feedback
planning Perform quality control
Report on project performance
Perform risk reviews,
Go back—iterations
Facilitate stakeholder reassessments, and audits
Finalize procurement strategy engagement and manage
and documents expectations Manage reserves
Create change and Hold meetings Manage, evaluate, and close

configuration management procurements
Evaluate sellers; negotiate and
plans
contract with sellers Evaluate use of physical
Finalize all management plans resources
Use and share project
Develop realistic and sufficient knowledge
project management plan and
Execute contingency plans
baselines
Update project management
Gain formal approval of the
plan and project documents
plan
Hold kickoff meeting
Request changes
58
Study Notes for Rita’s Process Chart™

Remember while this focuses primarily on plan-driven project management, many of the same concepts apply to agile
projects as well. We continue to note the differences throughout the book.
INITIATING Initiating
• You will read more about project selection in the following “Foundations”
Select project manager
chapter of this book. Does it matter for you to know why your project was
Determine company culture and selected? Yes, of course. It will influence how you plan the project, what kinds of
existing systems changes are allowed, and how the project scope is defined. The business case and
Collect processes, procedures, the benefits management plan are inputs to developing the project charter (and
and historical information the project charter is covered in more detail in the Integration chapter of the
Divide large projects into phases Domain II: Process section of this book.)
or smaller projects • Notice the phrase “Understand business case and benefits management plan.”
Understand business case and This could be read as “Understand the reason the project is being done and the
benefits management plan benefits the organization expects to gain as a result of it.” These business
documents are created before the project begins and contribute to the project
Uncover initial requirements,
assumptions, risks, constraints, being selected by the organization among many project proposals. They will
and existing agreements guide all project management activities to ensure the project is worth the
Assess project and product investment and that it will return the expected benefits to the organization.
feasibility within the given This is an exam concept that many project managers miss. As the project
constraints
manager, you should understand why your project was selected and what benefits it
Create measurable objectives is expected to deliver. Is the project being done so the organization can enter a new
and success criteria market? Is it intended to meet a regulatory requirement? Is it the result of a
Develop project charter customer request? Is it a priority project for a company executive? Is it expected to
dramatically improve the future of the company? If you lose sight of objectives, the
Identify stakeholders and
determine their expectations, project may finish on schedule and on budget but still fail because it does not
interest, influence, and impact achieve its objectives or does not deliver the expected value.
• Team building, risk identification, stakeholder identification, risk response
Request changes planning, and many other activities primarily occur in the process groups in
Develop assumption log which they are placed on the chart, but these activities can start in initiating and
continue until closing.
Develop stakeholder register
• Identifying and analyzing stakeholders help to align their expectations about the
project and assess their potential involvement and influence on the project.
• The project manager determines whether the project objectives can be achieved
and if it is likely to be completed within the given constraints. High-level planning
is summarized in a project charter, which documents high-level estimates,
measurable objectives, success criteria, milestones, and an initial budget. Initial
planning may also include creating a high-level WBS and high-level risk
identification.
• The charter, once formally approved by the sponsor, gives the project manager
the authority to continue the project beyond initiating. It also provides a guiding
vision of the project’s business case and benefits management plan, and the
organizations strategic objectives.
• Besides an approved project charter, an artifact of initiating is the stakeholder
register. Then, detailed planning can begin.
59
PLANNING Planning
(This is the only process group • In the planning column, note the first box: “Determine development approach, life
with a set order.) cycle, and how you will plan for each knowledge area.” In plan-driven approaches,
Determine development each knowledge area (scope, schedule, cost, etc.) requires a management plan.
approach, life cycle, and how you Additional plans are needed for configuration (or updating of project artifacts),
will plan for each knowledge area
change, and requirements management. The first thing you need to do is figure out
Define and prioritize how you will plan, execute, and control for each knowledge area. This will guide the
requirements rest of your planning efforts.
Create project scope statement • The project manager and team perform a detailed analysis of whether the objectives
in the project charter and the expected business benefits can be achieved. They
Assess what to purchase and
create procurement documents determine what processes are appropriate for the needs of the project and tailor
processes to those needs.
Determine planning team
• Notice the phrase “Determine team charter and all roles and responsibilities.”
Create WBS and WBS dictionary Determining roles and responsibilities involves determining who is going to do
Create activity list
which product-related work activities but also who will provide reports, attend
meetings, help with risk identification, work with the quality department, etc. Roles
Create network diagram and responsibilities may be documented as part of the resource management plan,
Estimate resource requirements in project job descriptions, or in the management plans for each area. This item may
also include developing a responsibility assignment matrix (RAM) and a rewards
Estimate activity durations and
costs and recognition system.
• Some projects may be organized by phases where detailed planning for the next
Determine critical path
phase is started as the previous phase nears completion. In agile planning only the
Develop schedule first part of the project may be fully planned, while the later portions are planned at
Develop budget a high level and then progressively elaborated when more is information about the
project becomes available.
Determine quality standards,
processes, and metrics • Remember when we said project management seems linear but is dynamic? The
Planning column has a reminder that planning is the only process group with a set
Derermlne team charter and all
order. However, a planning process may require an input that isn’t available yet. The
roles and responsibilities
risk register, for example, is an input to several processes leading to the creation of
Plan communications and the schedule. Initial risks are documented in the charter, so although the risk
stakeholder engagement
register will by no means be complete when the schedule is created, known risks
Perform risk identification, can be factored into planning. Then, after performing risk management activities,
qualitative and quantitative
risk analysis, and risk response
the more complete risk register can be used to refine the schedule.
planning • Look at the phrase “Go back—iterations.” This is an important concept. Planning is
iterative. When planning a project, the project manager and the team complete each
Go back—iterations
item listed above this point to the best of their ability. But even a plan-driven project
Finalize procurement strategy will evolve as the project progresses and earlier planning work is then modified. For
and documents
example, it is only after completing risk management planning that the WBS and
Create change and configuration the other items can be finalized. A risk response strategy may be used to avoid a
management plans
portion or all of a threat (see the “Risks and Issues” chapter). This will require
Finalize all management plans adjusting the WBS for added scope (the risk response plans), the network diagram
Develop realistic and sufficient
to redetermine the order of the work, the budget for added cost, and so on. The
project management plan and project manager might also work with discretionary dependencies to change the
baselines network diagram and thereby decrease some risk (see the “Schedule” chapter).
Gain formal approval of the plan • Notice the term “procurement strategy and documents” in the Planning column.
Hold kickoff meeting Also note the placement of “Finalize procurement strategy and documents” after
“Go back—iterations.” The risk management process may generate risk response
Request changes strategies involving contracts; through iterations the procurement documents can
be created, refined, and finalized.
40
• The important thing to remember is that planning should lead to a realistic, bought-into, approved, and formal project
management plan that is updated throughout the project to reflect approved changes.
• The distinction between predictive and adaptive approaches is worth thinking about here. The Process Groups: A
Practice Guide planning processes describe all the traditional activities performed to define the total scope and courses
of action for a project. It assumes that with sufficient analysis these are knowable, and development is then largely the
execution of this course of action. Progressive elaboration and rolling wave planning are effective mechanisms to tune
plans to emerging details, and they act as accepted adjustments to detailed initial planning.
• Although the project management plan is “finalized” in planning, items such as detailed estimates and product and
project scope descriptions may be modified as the work is being done during the executing and monitoring and
controlling processes.
• The project management plan and documents (also known as project artifacts) resulting from planning guide the
execution and control of the project. After the plan is iterated and includes the appropriate detail for the project life
cycle and development approach, the sponsor approves it.
Rolling wave planning and progressive elaboration exist within the predictive framework of project management as
supporting elements. Agile planning is deliberately more incremental and iterates to discover and refine scope, making
progressive elaboration a central rather than a supporting element.
PMP@ Exam References in Context TWO
EXECUTING Executing
• With an approved project management plan, the project
Execute work according to the project management plan
moves into executing, where the team completes the
Produce product deliverables (product scope) work according to the plan. The project manager’s focus
is on leading people and managing the project,
Gather work performance data
including engaging stakeholders, working with the team,
Request changes following processes, and communicating according to
Implement only approved changes the plan. For the exam, get your mind around the
critical difference appropriate planning makes. Assume
Continuously improve; perform progressive elaboration
the project was properly planned before work began
Follow processes unless the question indicates otherwise.
Determine whether quality plan and processes are correct • The purpose of project executing is to complete the
and effective project work as defined in the plan, to produce the
Perform quality audits and issue quality reports project deliverables (the product scope) at agreed
quality levels, within the project's approved budget and
Acquire final team and physical resources
schedule. This achieves the expected business value and
Manage people agreed-upon benefits.
Evaluate team and individual performance; provide training

• Team members can be released at any time once their
work is approved and accepted and they have completed
Hold team-building activities
their project activities.
Give recognition and rewards Example Electricians on a project to build a house
may test their work, get acceptance of their work,
Use issue logs
document lessons learned, suggest process
Facilitate conflict resolution improvements, and turn the work over. They are released
Release resources as work is completed while other team members doing drywall are still
working. Some team members remain on the project to
Send and receive information, and solicit feedback
its end to assist the project manager in creating the final
Report on project performance lessons learned, archiving final records, and producing the
Facilitate stakeholder engagement and manage expectations final report.

• As executing progresses, the project manager may
Hold meetings
determine that a change is needed. The same could
Evaluate sellers; negotiate and contract with sellers happen while the project manager is monitoring and
controlling the work, or in planning as a result of rolling
Use and share project knowledge
wave planning that occurs after the plan has been
Execute contingency plans approved and work has started. Change requests are
Update project management plan and project documents evaluated and approved or rejected as part of the
Perform Integrated Change Control process (see the
“Integration” chapter).
MONITORING & Monitoring and Controlling

• Do the project management process groups occur sequentially? Yes, in a sense,
CONTROLLING
but the paradox is that they overlap. For example, you could be using monitoring
Take action to monitor and control and controlling processes to control stakeholder identification and adherence to
the project
organizational requirements while project planning and the creation of baselines
Measure performance against and project documents. Defects could be identified in executing that require
performance measurement work in monitoring and controlling to decide if the defects require a change to
baseline
the plan to prevent future rework or delays as well as work in executing to fix
Measure performance against them. Controlling procurements and the closure of procurements can occur
other metrics in the project
management plan
simultaneously on projects because some sellers will complete their contractual
obligations to the project while others are still producing deliverables. Look
Analyze and evaluate data and
again at Rita’s Process Chart™ and think about the overall focus of each
performance
process group, but also about how the work can overlap at various points in
Determine if variances warrant a time.
corrective action or other change
request(s) • While the work is being done, work results (or data) are fed into monitoring and
controlling to make sure the project is advancing according to the established
Influence factors that cause change
baselines. This requires evaluating hard data on how the project is conforming to
Request changes the plan, and taking action to address variances that are outside of acceptable
Perform integrated change control limits. The project manager and team are also assessing how stakeholders are
participating, communicating, and feeling about the project and the work, and
Approve or reject changes
addressing uncertainties (or risks) that have been identified.
Update project management plan • The project management plan includes monitoring activities, such as observing,
and project documents
communicating, and evaluating. It also specifies control activities along with a
Inform stakeholders of all change plan for how variations from planned metrics should be addressed.
request results • Outcomes of monitoring and controlling include recommended changes to the
Monitor stakeholder engagement way the work is being done or possibly requesting adjustments to baselines to
reflect more achievable outcomes. Change requests are evaluated in Integrated
Confirm configuration compliance
Change Control to determine their impact on the project, identify the best
Create forecasts options for dealing with them, and decide whether they should be approved,
Gain customer s acceptance of rejected, or deferred.

interim deliverables • Approved changes that require adjustments to baselines and other plan elements
Perform quality control require replanning before the team starts working on them (in executing). If the
project gets so far off the baselines that it requires an analysis of whether it
Perform risk reviews,
should continue at all, or if significant changes are suggested that are outside the
reassessments, and audits
project charter, it may move back into initiating while that evaluation is done.
Manage reserves
• Executing and monitoring and controlling actions continually overlap while the
Manage, evaluate, and close work of the project is ongoing, including keeping all project artifacts up-to-date.
procurements The focus for the project manager in executing is leading people, removing
Evaluate use of physical resources impediments to progress, and managing physical resources to accomplish the
project as planned. The focus of monitoring and controlling is ensuring the
project is progressing according to plan and approving necessary changes to the
plan to meet the organizations strategic objectives and deliver the expected
benefits.
CLOSING Closing
• The closing efforts are similar for plan-driven and agile projects. They
Confirm work is done to requirements
include collecting and finalizing all the artifacts needed to complete the
Complete final procurement closure project, and technical and administrative work to confirm that the final
Gain final acceptance of product product of the project is accepted. They also include transferring the
completed product to those who will use it and soliciting feedback from
Complete financial closure
the customer about the product and the project.
Hand off completed product • Lessons learned should be collected on an ongoing basis on plan-based
Solicit customer’s feedback about the project projects and on agile projects after every iteration. They are finalized at
closing. In both cases they should be put to use right away and after
Complete final performance reporting
closing be made available to future projects.
Index and archive records • In many real-world situations, projects never seem to officially finish.
Gather final lessons learned and update Keep in mind that all projects must complete the required
knowledge bases closing activities.
Rita’s Process Chart™ Game

Our students invariably report that Rita’s Process Chart " and the associated explanations have been instrumental for
them to pass the exam. The Rita’s Process Chart ™ Game has helped thousands of students remember and ensure their
understanding of the overall project management process. You may at first find this game overwhelming, so just play it once
before you finish reading this book. Then, come back to the game and play it a few more times before the exam and you will
find it getting easier as you are better prepared.
There are two formats you can use to play this game.
• An online version of Rita’s Process Chart’" Game is available at https://rmcls.com/rm
rmcls.com/process-chart-game-vll.
• A printable version of the game is available for download. This version is available on our RMC
Resources page: rmcls.com/rmc-resources (or scan the QR code). You can then cut apart the
component “cards” and play the game using this high-touch, low tech format.
RMC RESOURCES
Agile Process Overview

The Rita’s Agile Process Chart ” is a matrix representing an agile approach to project management. We draw
comparisons between agile, plan-driven and hybrid approaches throughout the book so as you study you
should become familiar with how both predictive and adaptive environments work. In addition, always keep
in mind that as a project manager you always tailor the methods you use to the needs of the project, and that
hybrid approaches work on some projects.
Rita’s Agile Process Chart™
FEASIBILITY INITIATION RELEASE ITERATION CLOSE-OUT

Project visioning takes place Develop project charter PLANNING Perform iteration planning Obtain final release approval
Establish business case Create team charter Slice user stories Build features as described Turn over maintenance of
(decompose features) in user stories product release to another
Create high-level user stories Hold daily standup meetings team
(features) Build a release plan Hold daily standup meetings
Build a release plan Hold final retrospective
Establish high-level Build a release map Remove impediments for
estimates Create personas the team Ensure procurement closure
Hold daily standup meetings
Identify stakeholders and Update bumup charts Archive project artifacts
contact Perform story estimation
using Planning Poker* Identify acceptance tests for
Create backlog of features stories
Create high-level estimates value Prepare accceptance tests

using affinity estimating
Define “done” Run exploratory tests
Create product roadmap
using story maps Estimate how much work Test user stories
can be done
Remove impediments for Hold iteration review
the team Calculate team velocity
Hold retrospective
Reprioritize the backlog
Prepare stories of next
Define the first iteration goal iteration
Ensure there is shared Collaborate with team to
understanding among team answer questions and obtain
members story signoff
Prepare stories of next

iteration
Remove impediments for

the team
Feasibility
Agile teams are stable over time so projects are brought to the teams. There typically is not a new team assembled for each
project, as is often the case with plan-driven project. Feasibility consists of the following.
• Establishing a business case often involves management and includes things like cost-benefits analysis, calculating
expected return on investment and using other metrics to ensure that the project will create the desired value for the
organization and its stakeholders.
• Creating a product and project vision is an exercise where the team develops an “elevator pitch” or short statement
describing the project and its product, benefits, and value in the time a ride in an elevator might take.
• High-level features are documented along with very high-level estimates of the costs and other resources needed to
create the product of the project. The features are very general descriptions of what will be needed from the product.
Initiation
At the point of initiating, you can assume feasibility studies and project selection are complete, just as you would when you
are given a plan-driven project. The team develops the following:
• A project charter This is a high-level summary of the project and its scope, requirements, risks and other broad
features of the project and product as known. The team charter is a set of agreements about how the team will commit
to working together to communicate, build the product, and meet the needs of the project and each other. If the team
already has a team charter, they will tailor it to the needs of the project.
• Personas These are profiles of the various types of stakeholders who will use the product. The team develops them
to understand requirements from the perspectives of their various stakeholders, usually end users of the product. The
team also identifies specific stakeholders and stakeholder groups, gathers their contact information, and begins to
contact them. See figure 2.12.
• A product backlog This is an elaboration of the feature list started in Feasibility. This single artifact holds all the
features needed from the product. It is elaborated and decomposed iteratively throughout the project. The team
completes affinity estimation, or grouping features by high-level estimates of their size (estimated effort to build, for
example small, medium, large, extra-large). Common terms used here are “bucket size” or “t-shirt size.” See figure 2.13
• A product roadmap (or story map) This graphic depicts features that will be built first, and then next, etc., across
a period of time. Product increments are built and delivered to the customer in releases, so the product roadmap or
story map may also be referred to as a release map. See figure 2.14.
Remember that the product owner is an integral part of the team and helps in all these endeavors. The project manager
meanwhile is ensuring that processes are understood and being followed, and is working to remove impediments to the
team’s progress.
Jemelia Job Seeker
Description Values
• Looking for new job after completing • Free access to computer with easy apps
bachelor’s degree in nursing • Free internet access
• Working as a home health aide • Easy instructions on the application
• Does not have a computer for finding jobs process and how to access job boards
• Needs access to job resources at odd
hours during time off
FIGURE 2.12 Example persona for library case
# Backlog Item Stakeholders

Pl Manage appointments Patients, administrators, practitioners
P2 Change personal data and preferences Patients, administrators, practitioners
P3 View health information library Patients, practitioners
P4 Outreach (marketing) campaigns Patients, marketing
P5 Practitioner and patient communications Patients, practitioners, marketing
P6 Regulation compliance Patients, government
P7 View patient’s own medical data from The Center Patients, administrators, practitioners
FIGURE 2.13 Example partial backlog for clinic user website
46
Release 1 (Mar 28) Release 2 (May 30) Release 3 (Jul 31)

- Regulation compliance - Regulation compliance - Manage bill and payments
- Branding/style schemes - UID - Manage own insur

ance information
- Database integration - Database integration
- View patient data from
- Investigate network infrastruc - Manage web accounts (login,
other institutions
ture expansion password, etc.)
- User interface design (UID) - Patient views own data from The
Health Center
- Site security
- Change personal data
- Manage web accounts (login,
and preferences
password, etc.)
- Manage appointments
- Patient views own data from The
Health Center
- RISK Current web site capacity
- RISK Patients with “edit” access

could damage data
FIGURE 2.14 Example roadmap from clinic user website case
Agile Release Planning

The release map (or product roadmap) was created during Initiation, along with the feature backlog. In release planning
these will be planned further for the release of the first increment of the product. Once that first increment is released the
team begins work on the second release, and so on, for the number of releases decided on by the team during initiation. The
release plan is developed iteratively throughout the project because in adaptive environments planning occurs throughout
the project. Other activities the team carries out are as follows:
• Features are “sliced,” or decomposed into smaller units, or stories. The stories are estimated in finer detail using
estimating tools like Planning Poker*, where each story is estimated using more finely detailed relative sizing.
Additional requirements about the stories are gathered as they can become known, and a “definition of done” (i.e.,
what does “done” look like?) is created for each story.
• The team establishes its initial “velocity,” which is a measure of how much work can be completed in an iteration (a
defined period of time for building the product increment, like two weeks, or three weeks, for example). The team also
selects, with the help of the product owner who is responsible for prioritizing the backlog, the stories that will be
completed in the first iteration.
• The team continues to gather the detailed requirements for the first (or next) iteration. The product owner, meanwhile,
is continuously prioritizing the backlog. The project manager is fostering a common understanding and removing
impediments for the team.
Agile Iterations and Product Release

Monitoring and controlling occur throughout an agile project as the product is being built, although most agile practitioners
do not use the term “monitoring and controlling.” The team moves through a defined series of iterations (two-to-four
usually) per release, until a product increment is ready to be delivered to the customer. This is what these processes
look like:
• There is a last, quick effort to finish the iteration planning before the iteration begins. Once the iteration begins the
team will simply build the stories that have been selected for that iteration while the project manager is facilitating
their work and removing impediments to progress.
• The team has already begun daily standup meetings, which are very short meetings (usually 15 minutes) where they
discuss what has been completed since they last met, what will be completed next, and whether there are any
impediments to progress. Any elaboration or follow up from the meeting happens after the meeting so everyone can
get back to work quickly.
• The team’s work consists of building, testing, and finishing stories so they can be presented to the customer for
approval in an iteration review, where the product is demonstrated and the customer has an opportunity to
provide feedback.
• The product owner meanwhile is answering questions the team has about missing story details, prioritizing the
backlog, and preparing more stories for the next iteration by continually gathering their detailed requirements.
• After the iteration review, the team responds to customer feedback requiring changes. The team also holds an iteration
retrospective where they discuss what they did well, what went wrong, and what they would do differently. The daily
standups, the iteration reviews, and retrospectives are all part of living a philosophy of continuous improvement.
• Iterations continue until a “minimally marketable” increment of the product is ready for release to the customer.
Minimally marketable increments are those that meet the minimum requirements for something that the customer
can use while the team builds the next product release.
Agile Closing
There is no appreciable difference between closing processes in adaptive and predictive environments. You can review this
information in the Closing section on Rita’s Agile Process Chart”. Essentially the team obtains final approval of the last
product increment to be released during the project, turns it over to the customer, and holds their final retrospective. The
project manager also makes sure all procurements have been closed and that all project artifacts are current and are archived
as part of the organizations process assets.
Rita’s Agile Process Chart™ Game

Rita’s Agile Process Chart™ game will help you gain understanding on how an agile project flows. We suggest you only play
the game once before you have read through this book. Then return to it as many times as you’d like to increase your
understanding of agile projects.
• An online version of Rita’s Agile Process Chart™ Game is available at rmcls.com/ https://rmcls.com/rm
agile-process-chart-game-vl 1.
• A printable version of the game is available for download. This version is available on our RMC
Resources page: rmcls.com/rmc-resources. You can then cut apart the component “cards” and
play the game.
RMC RESOURCES
Hybrid approaches embody the principle of tailoring. As you read this book, use your
Bis experience to practice awareness of tailoring. Think about tailoring the processes and
IlitVH tools discussed in this book with projects you are familiar with and examples we give you. Could you be
creative with project management methods to better manage a situation on a project? Think about advantages
the different approaches offer. As you become comfortable with these approaches, you will be able to identify them on
the exam depending on the given scenario and therefore select the best answer.
48
Hybrid Environments
A hybrid project management environment uses a combination of plan-driven and agile development
approaches. These approaches may take one of many forms. Below are a few examples:
• We can use predictive methods to manage project requirements that are well defined, and adaptive
methods to manage requirements that are less clear.
Example Build a small building with plan-driven methods. Build out office spaces iteratively.
• Use a plan-driven approach but add agile elements.
Example The project manager for a mainly plan-driven project uses electronic task boards (“information
radiators” in agile) for a remote team and institutes daily standup meetings during designated periods along the
critical path.
• Use an adaptive approach to develop the product and then use a predictive approach to implement the product once
it has been approved for release.
Example Develop a large, complex software installation incrementally and iteratively. Once it is ready to be
released, complete the rollout and training using plan-driven methods.
Figure 2.15 illustrates the spectrum of development approaches, using the small office building construction example
from chapter 1. The dotted line indicates that with a hybrid approach, any combination of methods along the spectrum
maybe used.
Agile
Combination plan-driven and agile for interiors as space is leased

FIGURE 2.15 Development Approach Spectrum
PMBOK® Guide, Seventh Edition Overview

As we mentioned earlier in this chapter, PMI states that the exam is based on the ECO but also gives ten other references,
including the PMBOK* Guide, Seventh Edition. Since we have found that you could see questions on the exam based on
information in the PMBOK* Guide, we want to provide an overview. We will also present concepts from it throughout the
book, where appropriate.
Updates in the PMBOK® Guide’s Seventh Edition

The seventh edition of the PMBOK* Guide is not prescriptive since it does not endorse a single framework or approach to
good project management. Connected to this idea of not endorsing a single project management model, the PMBOK*
Guide describes the continuum of approaches along which projects maybe managed. This continuum of practices ranges
from managing projects using only plan-driven methods, to doing so using only agile methods. Between these two extremes
are hybrid models that combine methods from both plan-driven and agile project management.
Anywhere along this continuum, remember, is the basic tenet of tailoring. You must tailor your project management
approach and methods to the needs of the project you are managing and its potential benefits to your organization and its
stakeholders. These benefits tie back to the reason a given project was selected by the organization.
Other fundamentals in the PMBOK* Guide to think about focus on project management as:
• A system of value delivery You still need to understand the definitions of projects, programs, portfolios, and
operations from the perspective of their unique attributes and connections to one another. PMI now also emphasizes
thinking of these collective efforts from the perspective of a system of delivering value to the business and to achieving
its strategic objectives—and those of its stakeholders. These two perspectives are completely compatible with each
other, with the principles in the ECO, and with everything we teach in this book.
• A principles-based system Complementary to PMI’s Code of Ethics and Professional Responsibility, PMI
introduces the PMBOK' Guide as a principles-based system of managing projects to deliver value. These principles are
listed later in this book, in the “PMBOK* Guide and the PM Standard” chapter.
• Having a performance domain focus The PMBOK* Guide is based on performance domains, each of which
describe a collection of skills and abilities that a project manager should have and use on a project, in whatever ways
necessary depending on the project s needs and attributes.
The PMBOK* Guide’s performance domains are not the same as those described in the ECO, but they are
compatible with them. Do not worry about having to memorize all these performance domains. It will not be hard for
you to relate to the PMBOK* Guide’s performance domains as you gain an understanding of plan-driven, agile, and
hybrid project management approaches (along with the concepts expressed in the ECO), as taught in this book. The
domains are:
y Stakeholders -/ Planning -/ Measurement
■/ Team ■/ Project Work ■/ Uncertainty
-/ Development Approach •/ Delivery

and Life Cycle
• An outcomes-based system Projects inevitably deliver outputs—those deliverables that result from the project-
related activities the project manager and team complete. There is a difference between outputs (deliverables directly
resulting from the work on a project), and outcomes—what needs to be accomplished with these deliverables. The
PMBOK* Guide places an increased emphasis on the outcomes that should result from these deliverables.
Example It is one thing for a project to deliver improved sales and engineering processes (the outputs, or
deliverables), but do these new or improved processes achieve the desired outcome of measurably improving sales
results? The output of the project is the new or improved processes, and the desired outcome is the measurable
improvement in sales and product delivery.
• Models, methods, and artifacts A model is a way of understanding a concept or a set of tools, a method is the set
of tools itself, and artifacts are all of the documentation and other useful organizational assets project managers use on
a project, keep updated, and leave behind from a properly managed project.
Putting It All Together

We would like you to have more practice with the two main project management process models before you read the rest
of this book.
Read through the concepts in the first column (the Agile column), and study how they are illustrated in the Agile
Process Overview in figure 2.16. The Agile Process Overview will help you better understand the agile model. Next, read
through the concepts in the plan-driven column and go back to Rita’s Process Chart™ earlier in this chapter and read
through it again.
Make sure you understand both process models and, at a high level, how they are similar to and different from each
other.
It is useful to draw parallels between plan-driven and agile project management so that you may understand
TRICKS both, along with their similarities and differences. As we show these parallels also keep in mind that they are
OF THE
TRADE* models, and all models have limits. So do not look for exact parallels from these comparisons. Come to a
general understanding that each approach arrives at the same goals by taking different paths.
50
Agile (Agile Process Overview, figure 2.16): Initiating Plan-driven (Rita’s Process Chart™: Initiating)
- Chartering and identify stakeholders: Personas. - Project charter and identify stakeholders:
Stakeholder register.
- Create Backlog: High-level requirements; features
and functions. - High-level known requirements: In project charter.
- High-level estimation: Bucket size (like t-shirt size: S, M, - High level estimation: In project charter.
L).
- Create roadmap: Time-phased story map.
Agile (Agile Process Overview, figure 2.16): Release

Planning and Iteration Planning Plan-driven (Rita’s Process Chart™: Planning)
Story slicing Decomposed from feature-level (high-level) Gather requirements, define scope, decompose to create
to smaller chunks of functionality (stories). WBS (work packages) and WBS dictionary.
Story estimation using Planning Poker*: An all-team Create activity list, estimate activity durations, costs,
participatory estimating method. resource requirements.
Cost and schedule (not shown on figure 2.16): Cost is Build the rest of the project management plan (detailed
stable and estimated early; scope is emerging and quality, procurement, communications, stakeholder,
more negotiable. and risk plans).
Build a release plan: Risk-adjusted backlog contains Team charter, roles and responsibilities.
sliced stories; prioritized sufficiently to plan the (first Go back - iterations, create change and configuration
and) next iteration. Quality, procurement, communica plans. Finalize procurement and other management
tions planned in. plans. Get final project management plan approval, hold
Team charter, roles, & responsibilities: SMEs as general kickoff meeting.
izing specialists (can help where needed); project Project manager and team consult plan for next steps;
manager/servant leader; product owner represents adjustments are made as needed.
the customer.
Project manager as servant leader.
Iteration 0 and spikes: Detailed requirements are
Technical team builds with excellence.
gathered in Iteration 0. Spikes are experimental iterations
to explore a new risk, technology, or approach. Project manager controls to the plan.
Iteration planning: Short, whole-team meeting (the team Meetings for various reasons including project
manages their own work). reporting.
Project manager as servant leader. Servant leader (project manager) helps remove
impediments, engage stakeholders, manage procure
Building with excellence: Technical team.
ments, etc.
Answer questions; prepare stories for next iteration:
Product Owner/value management. Meetings to execute and control, including integrated
change control and project reporting.
Daily standup meetings: Short—What is done; what are
you working on; are there impediments? Executing and control continues; replanning happens
for approved changes; iterative planning happens for
Servant leader (project manager): Helps remove progressive elaboration as needed.
impediments after the meeting.
Product scope is built, verified, and validated (accepted)
Iteration review: Demo product increment to customer, until scope as planned is completed and the project can
get feedback, and go back to make changes as needed. close (or the project is terminated early).
Planning executing, and control: happens iteratively
until defined product scope is built or the customer
decides that the built scope is enough and the project can
close (or the project is terminated early).
51
Key
Q Whole team or available team members
O Value management (product owner) team
Technical development team

0 Testers
Inage credit: Ahmed Sidky, Santeon Group, www.santeoncom
FIGURE 2.16 Agile Process Overview
52
QUICKTEST
• Definition of a project
Project Management • Program management

• Portfolio management
• Organizational project
management (0PM)
Foundations • Governance
• Organizational structure
- Functional
- Project-oriented
This is a very important chapter. Yes, we could say that about every chapter in this book, as they all will - Matrix
add to your understanding of project management. But this chapter is especially important because it • Project coordinator
provides the foundation for understanding the other chapters in this book. Use the Quicktest to look • Project expediter
for gaps in your knowledge and work on filling those gaps as you read the rest of the chapter. • Project management
office (PMO)
- Supportive
Project Management’s Organizational Context - Controlling
- Directive
Successful projects provide business value and deliver benefits defined in a business case and a benefits
• Value delivery office
management plan. Projects are designed to bring value to an organization and its stakeholders by add
(VDO)
ing or improving products or services, and in some cases to satisfy regulatory or other legal require • Return on investment
ments. They are selected, initiated, and exist within an organizational context that influences their de (ROI)
sired outcomes and what is needed (inputs) to work to achieve these outcomes. Organizational context • Present value (PV)
includes an organizations operations and projects, its governance, and its organizational structure. • Net present value (NPV)
Organizational context also includes what the PMBOK* Guide calls influences: enterprise • Internal rate of return
(IRR)
environmental factors (EEFs) and organizational process assets (OPAs). EEFs are outside the control
• Payback period
of the project team but impact its work, like an organizations culture, technology, and external
• Cost-benefit analysis
governmental standards, rules, and regulations. OPAs are an organizations processes, procedures, and
• Economic value added
policies, along with organizational knowledge repositories — things within the organization that can (EVA)
facilitate the work of project management and product development. A project manager and team use • Opportunity cost
these and update them for the organization. We will discuss other aspects of project management’s • Sunk costs
organizational context when we discuss the Business Environment domain of the PMP Examination • Law of diminishing
Content Outline fF.COY returns
• Working capital
Operations and Projects • Depreciation
Most work done in organizations can be described as either operational or project work. Operational • Project roles
- Project manager
work is ongoing work to support the business and systems of the organization, whereas project work
- Agile Team Leader
ends when the project is closed. People often see their work as a project when it is not.
• Agile coach
Example A person who processes payroll every month may consider this a monthly project. • Team lead
Technically, this repeatable process is part of operations. Now, what’s wrong with this thinking or with • Scrum Master
using project management techniques to get the job done? Nothing. In fact, project management - Product owner
methods can be used in many areas of work and life. But for the exam, you should understand the - Product manager
distinction. - Project sponsor/lnitiator
- Project team
A project has a distinct beginning and end, and is an effort to produce something that has not
- Stakeholder
been done before. When a project is finished, the deliverables are transitioned to ongoing business - Functional or resource
operations so the value and benefits of the project work can be integrated into the organization, manager
permanently or until another change to that operation is needed. A successful transition may require - Program manager
employee training or adjustments to operational processes. - Portfolio manager
Example An insurance company’s internal project to develop a new caseload tracking system is
completed. As part of the same project or as a different project, the new system has to be launched.
Employees will need to be trained on how to use the system and to adjust their ways of working to
incorporate the new system into their daily work so the benefits can be realized. And this relationship
goes both ways. While a project may develop a product or service to be used in operational work, the
need for change to operational work may prompt the initiation of a project. Here are ways that could
happen in the caseload tracking system example:
53
Project Management Foundations
• The need for a new caseload tracking system may have arisen from problems occurring in the organizations
business operations.
• Imagine the caseload tracking system has moved into operations and users have started working with it, but some
bugs have been identified. Fixing these bugs would likely be addressed as the operational work of maintaining business
systems rather than as a new project.
• The organization decides to add new features to the caseload tracking system after it is in operation. This would
prompt a new project.
Projects, Programs, and Portfolios

The PMP exam mostly focuses on project management, but understanding a bit about how projects fit into programs and
portfolios will help you approach the exam with a holistic understanding of the context in which projects are managed.
Project and Program Management

On the exam, a project is assumed to have the following characteristics:
• It is a temporary endeavor—with a beginning and an end.
• It creates a unique product, service, or result.
• It is undertaken to drive a change in a product or process from a current state to a future state, to achieve a
specific objective.
• It is undertaken to create business value for the organization and its stakeholders. PMI’s Process Groups: A Practice
Guide defines business value as “the net quantifiable benefit derived from a business endeavor.” The benefit may be
tangible, intangible, or both.
Does the exam ask, “What is a project?” No. But it will describe scenarios and your answer will be different if the
scenario is not describing a project. If your manager walked into your office today and said, “The system is broken. Can you
figure out what is wrong with it and fix it?” Would this be a project?
It depends. On the exam, the right answer will depend upon the evidence given in the question. In this book, we will
give you some tricks about answering questions.
Projects are selected among many possible business endeavors for a variety of reasons including:
• Stakeholder (customer) needs and requests for new or improved products or services, often initiated by market forces
or by the stakeholders themselves
• Improvements to the performing organizations business or technology strategies and/or their products or services
• Satisfy regulatory, legal, or social requirements
A program is a group of related, sub-projects and other program-related activities, organized and managed into a
coordinated set of efforts. In addition to the work required to complete each individual project, the program also includes
a program managers coordination and management activities. The project manager will collaborate with a program
manager if the project is part of a program. If the assigned work involves more than one project, the project manager can
manage the projects as a program if they determine the program approach adds value. Figures 3.1 and 3.2 illustrate program
and portfolio management. Portfolio management and PMI’s Organizational Project Management (OPM) framework are
discussed in the sections that follow.
Program
Other
Project Project Project
related work
Figure 3.1 Program management
FIGURE 3.2 Portfolio management

THREE Project Management Foundations
Portfolio Management
A portfolio includes programs, projects, and related operational work, all prioritized and implemented to achieve a specific
business objective (see figure 3.3). Programs and projects that make up a portfolio may not be related, other than by their
relationship to this common business objective. A portfolio may also include smaller, subsidiary portfolios. Combining
programs, projects, and operations into one or more portfolios helps to manage the dependencies between them and the
individual projects. It also optimizes the use of resources, enhances the value they produce for the organization and its
stakeholders, and reduces risk. The work of an organization comprises one or multiple portfolios. A project is included in
a portfolio based on potential return on investment, strategic benefits, alignment with corporate strategy, and other factors
critical to organizational success.
Organizational Project Management (OPM)

Organizational project management (OPM) serves as a guide Organizational Project
or driver for project, program, and portfolio management as Management (OPM)
Provides a strategic framework
well as other organizational practices. It is a framework for to use and guide portfolio, program,
keeping the organization focused on overall strategy. OPM and project management to achieve
the organization’s strategic goals
provides direction for how portfolios, programs, projects, and
operational work should be prioritized, managed, executed, Portfolio Management
and measured to best achieve business objectives and value Selects and prioritizes programs
and projects that will best achieve
for the organization and its stakeholders. the organization’s strategic goals
Think About It. Take a couple of minutes to think

Program Management
about the information depicted in figure 3.3, which Coordinates the management of related
shows how OPM drives an organization to achieve projects to achieve specific benefits that
support the organization’s strategic goals
business objectives.
A key point to understand is that all efforts in the >
a Project Management
organization—whether they are part of project, program, Manages efforts to develop specific scope,
which supports the portfolio or program
portfolio management, or operational work—should be ▼ management objectives and, ultimately,
guided by the organization and support its business objectives. the organization’s strategic goals
Changes to organizational strategy will necessitate changes to

the affected work in each of these areas—both ongoing efforts
and future initiatives.
FIGURE 3.3 Organizational project management
Example If a project no longer aligns with organizational
strategy, the project may be changed midcourse to bring it into alignment, or it may be terminated.
Organizational and Project Governance

Every organization is different, and organizational governance is designed to support the specific culture and attributes of
the organization. Organizational governance affects and is affected by project governance, the organizations culture and
structure, and the business environment.
Organizational Governance
Organizational governance refers to the the way an organization sets the policies and procedures for how work will be
performed to meet business objectives and to support decision-making. Generally, a board of directors is responsible to
ensure that work throughout the organization conforms to external (government or regulatory) and internal standards and
requirements. Internal requirements include policies and procedures regarding portfolio, program, project, and operations
work to ensure that these are all within the strategic plan of the organization and that they contribute to the delivery of
business objectives while meeting ethical, social, and environmental sustainability obligations.
Project Governance
In the Examination Content Outline (ECO), task 14 of the Process domain is to establish project governance structure. It
requires project managers to ensure their project management practices align with organizational governance. Do you
establish a project governance structure on your projects? Regardless of what type of project you are managing, you are
still responsible to understand your organizations governance and align your project's governance to it.
55
Project governance can be established and administered by a project management office (PMO—see the PMO
section later in this chapter). It may involve defining a project managers authority and the creation or enforcement of
organizational processes and policies regarding areas such as risk, resources, communications, and change management.
Governance may also involve planning and managing project compliance in regulations, security, and safety. The
awareness of these requirements helps shape the best approach for a project.
Example Potential regulatory restrictions on a new energy project might inform the project manager as to when a
project must be completed. It may also help determine the approach and methodology for developing the product of the
project.
How does governance differ between predictive and adaptive projects? Predictive governance typically
involves formal documentation and upfront analysis and agreement. Agile governance, in contrast, is
generally less structured but still aligns with the necessary policies and procedures of the organization.
Organizational Structure
Along with organizational and project governance, a primary form of influence on projects is how the company is
structured. The organizational structure establishes who the project manager goes to for help with resources, how
communications must be handled, and other aspects of project management.
An answer to a question on the exam can change depending on the structure of the organization being discussed.
Exam questions are sometimes phrased in terms of the project manager s level of authority and how the form of organization
impacts their management of projects. Exam questions may deal with who has the power in a particular type of organization
or situation (the project manager or the functional manager), or they may require you to understand the advantages and
disadvantages to the project manager in each type of organization.
As you read through the following sections defining the different organizational structures, take time to think about
how each form would impact your work as a project manager and how you would solve problems in different situations
within each structure. In the real world individual organizational structures can vary within these general models, but on
the exam you will be able to see clear distinctions between them in the scenarios given in the questions.
Functional Organizations
Functional organizations are common and are grouped by areas of specialization, such as accounting, marketing, or
manufacturing. Projects generally occur within a single department, so when you see “functional” on the exam, think “silo.”
If information or project work is needed from another department, employees transmit the request to the head of the
department (one silo) who communicates the request to the other department head (another silo). Team members
complete project work in addition to normal departmental work.
Project-oriented Organizations
In a project-oriented or projectized organization, the entire company is organized by projects. The project manager has
complete project control and project resources are assigned and report to them. When you see “project-oriented” on the
exam, think “no home.” Team members complete only project work, so when the project is over, they do not have a
department to go back to. They need to be assigned to another project or get a job with a different employer. Communication
primarily occurs within the project.
Matrix Organizations
This organizational model seeks to maximize the strengths of both the functional and project-oriented models. When you
see “matrix” on the exam, think “two managers.” Team members report to two managers: the project manager and the
functional manager (e.g., the engineering manager). Communication goes from team members to both managers. Team
members do project work in addition to operations work. Following are the different subcategories of matrix organizations:
• A balanced matrix shares the power between the functional manager and the project manager.
• In a strong matrix power rests with the project manager.
• In a weak matrix power rests with the functional manager, and the power of the project manager is comparable to that
of a coordinator or expediter:
>/ A project coordinator has some authority and can make some decisions but reports to a higher-level manager
>/ A project expediter organizes communications and assists administratively but cannot make or
enforce decisions.
56
Exam questions typically do not identify the form of organization being discussed; in which case you should
TRICKS
OF THE assume matrix. This is most common and will help you answer questions correctly.
TRADE
A “tight matrix” has nothing to do with a matrix organization. It simply refers to colocation—the practice of
TRICKS locating workspaces for the project team in the same room. Because it sounds similar to other forms, it has
OF THE
TRADE sometimes been used as a fourth choice for multiple choice questions on the exam.
3.1 Exercise
Test yourself! In your Exercise Notebook, list the advantages and disadvantages of each organizational structure:
functional, project-oriented, and matrix. Understanding the differences between these structures will help you
evaluate scenarios presented on the exam, and you’ll be able to choose the right answer within that context.
Answer
Functional Organizations
Advantages Disadvantages
• Easier management of specialists • People place more emphasis on their functional
• Team members report to only one supervisor specialty to the detriment of the project
• Similar resources are centralized, as the company • Limited career path in project management
is grouped by specialties • The project manager has little or no authority
• Clearly defined career paths in areas of work
specialization
Project-Oriented Organizations
• Efficient project organization • No “home” for team members when project is
• Team loyalty to the project completed
• More efficient communications than functional • Lack of specialization in disciplines
• Project manager has more power to make • Duplication of facilities and job functions
decisions • May result in less efficient use of resources
Matrix Organizations
• Highly visible project objectives • Extra administration is required
• Improved project manager control over resources • Project team members have more than one
(as compared to functional) manager
• More support from functional areas • More complex to monitor and control
• Maximum utilization of scarce resources • Resource allocation is more complex
• Better coordination • Extensive policies and procedures are needed
• Better horizontal and vertical dissemination of • Functional managers may have different priorities
information than project managers
• Team members maintain a “home” • Higher potential for conflict
57
The Project Management Office (PMO)

The PMO is a department within an organization that can take a number of different forms based on an individual
organizations structure. A PMO supports projects, helps the organization mature its project management capabilities, and
helps ensure compliance with project governance. The PMO oversees and standardizes project management practices for
the organization.
Depending on the structure of the organization and its PMO, the PMO may:
Bea stakeholder Help provide project resources
Prioritize projects Manage the interdependencies among projects,
Monitor compliance with organizational governance programs, and portfolios
Facilitate the achievement of project outcomes with Provide centralized communication about projects
the project manager Provide project artifact templates (e.g., work
Analyze project information to assess whether it is breakdown structures, user stories, communications
achieving its objectives and aid in management plans)
continuous improvement Provide training and support for the acquisition of
Recommend the termination of projects project management skills
when appropriate Help gather lessons learned into a repository and
Have representation on the change control board; make them available to other projects
help with change management Assist in selection of project development approach
Provide guidance for the project manager and and life cycle
sponsor in decision making Assist in tailoring strategies and tactics
A PMO can take one of several forms. A PMO may be described as supportive, controlling, or directive based on the
level of control it maintains over the management of projects, or it may take on a variety of these roles based on the size and
complexity of the organization and its structure. Following are scenarios that describe ways in which a PMO may operate:
• A supportive PMO provides the policies, methodologies, templates, and lessons learned for projects within the
organization. It typically exercises a low level of control over projects.
• A controlling PMO provides support and guidance on how to manage projects, trains others in project management
software and other tools, and ensures compliance with organizational policies. It typically has a moderate level of
control over projects.
• A directive PMO provides project managers for different projects and is responsible for the results of those projects.
All projects, or projects of a certain size, type, or priority are managed by this office. A directive PMO has a high level
of control over projects.
• Characteristics of above types may be combined depending on the organizations needs.
• A functional organization may have departments that control how projects are run within them, but may get support
from a central PMO for various needs like those services described for a supportive PMO. The PMO may also provide
help with other things—for example risk assessment based on internal and external environmental conditions, or
project performance tracking where the project manager or team may need help with it
Value Delivery Office (VDO) Some organizations with less hierarchical structures and more adaptive
project management environments have a value delivery office or Agile Center of Excellence (ACoE) to
better enable project management in this type of environment.
When answering exam questions, assume there is a PMO, unless the question indicates otherwise. Read
TRICKS
OF THE questions carefully to determine if the PMO is supportive, controlling, or directive.
TRADE
58
3.2 Exercise
Read each description of a PMO. Determine whether it is likely to be supporting, controlling, directive, or a
combination of two or three. Write the answers in your Exercise Notebook.
Description
1. Manages all projects throughout the organization
2. Provides support and guidance; requires all projects within the organization to use designated project
management software and templates, but doesn’t otherwise exert control over the project
3. Coordinates all projects within the organization
4. Recommends common terminology, templates, reporting, and procedures to be used on projects
throughout the organization to promote consistency and streamline efforts
5. Appoints project manager
6. Prioritizes projects
7. Has the highest level of control over projects
Answer
1. Directive
2. Controlling
3. Controlling or Directive
4. Supportive
5. Directive
6. Controlling or Directive
7. Directive
Project Selection
A project manager should know a project s history in order to manage it effectively and achieve its intended deliverables and
outcomes. Departments and individuals within your company present management with requests for many different initia
tives (potential projects), all of which would require an investment of corporate resources. When answering questions on
the exam, assume that the organization has a formal process to review and analyze potential projects and select the projects
that best align with the business objectives of the organization and its stakeholders. There might even be a project selection
committee in place to evaluate project proposals.
How Projects Are Selected

A project manager is not typically involved in project selection. So you might ask, “Why is this an important topic to
understand?” Good question! Think of it as one element of understanding the business environment. The reasons a project
is selected and the value it is expected to deliver indicate its significance to the organization. As a few common examples,
as a project manager you need to know if your project:
• Was selected because it will establish a new area of business
• Is being implemented to meet regulatory or compliance requirements
• Was chosen because it was the least expensive or most feasible solution to a problem
59
The reasons a project was selected can impact which constraints are most flexible and will influence how the project
manager plans and manages the project. A project manager must keep the reasons the project was selected in mind
throughout the project to ensure the objectives are achieved.
For the exam, you should be familiar with the project selection methods described next. Just knowing that such
activities occur prior to initiating a project will help you. Project selection activities fall outside the project boundaries (or
period from project authorization through closure).
Economic Measures for Project Selection

The following sections discuss several economic measures that can be used for analyzing potential projects for selection.
Some of these measures are also used in processes such as quality, cost, and risk management, and in integrated change
control. The measures take a comparative approach and can be used to develop project metrics, determine when changes
to the plan are needed, and evaluate progress, changes, and overall project success.
An organization would likely consider more than one of these measures (along with other factors) when selecting a
project, rather than any one measure on its own.
Return on Investment (ROI)

Return on investment determines the potential profitability of an investment by calculating the benefits received in relation
to the cost.
Present Value (PV)

You may encounter a question on the exam that requires you to calculate present value. Present value means the value
today of future cash flows, and it can be calculated using the formula shown in figure 3.4.
FV FV = future value
PV=———n r = interest rate
(1+r) n= number of time periods
Figure 3.4 Present value formula
The acronym PV is also used for planned value (described in the “Cost” chapter). You can avoid confusing these
terms by considering the context in which they are used:
• If the question is discussing how the project was evaluated for selection or funding, PV represents present value.
• If the question involves project work that has started and schedule or cost performance is being evaluated, then PV
represents planned value within earned value management (EVM).
'Think About It. Think about the following question:

Question:
Is the present value of $300,000 to be received three years from now, with an expected interest rate of 10 percent,
more or less than $300,000?
Answer:
Less. You can put an amount of money less than $300,000 in the bank and in three years have $300,000.
To perform the calculation: $300,000/(1 + 0.1 )J = $300,000/1.331 = $225,394.
Net Present Value (NPV)

NPV is the present value of the total benefits (income or revenue) minus the costs over many time periods. You will not
have to calculate NPV. Know that generally, if the NPV is positive, the investment is a good choice — unless an even better
investment opportunity exists. The project with the greatest NPV is typically selected.
60
Think About It. Do you already have a good understanding of this topic? Think about the following question.
0 Question:
An organization has two projects from which to choose. Project A will take three years to complete and has an
NPV of $45,000. Project B will take six years to complete and has an NPV of $85,000. Which one is a
better investment?
Answer:
Project B. The number of years is not relevant, as that would have been considered in the calculation of the NPV
(remember, over many time periods).
Internal Rate of Return (IRR)

To understand internal rate of return, think of a bank account. You put money in a bank account and expect to get a
return—for example, 1 percent. You can think of a project in the same way. If a company has more than one project in
which it could invest, the company may look at the returns of the different projects and then select the project with the
highest return.
IRR does get confusing when you give it this formal definition: The rate (interest rate) at which the project inflows
(revenues) and project outflows (costs) are equal. Calculating IRR is complex and requires the aid of a computer.
You will not have to perform any IRR calculations on the exam. Simply know that the higher the IRR number, the
better.
Think About It. An example is always a good way to remember something so think about the next example.
Question:
An organization has two projects from which to choose: Project A with an IRR of 21 percent and Project B with
an IRR of 15 percent. Which one is a better option?
Answer:
Project A
Payback Period
The term payback period refers to the length of time it takes for the organization to recover its investment in a project
before it starts accumulating profit.
Think About It. Here is an example to think about for the concept of payback period.
£ ' Question:
There are two projects from which to choose: Project A with a payback period of six months and Project B with
a payback period of eighteen months. Which one should the organization select?
Answer:
Project A
Based on the information given in this example, the project with the shorter payback period is the best choice, but
that payback period is likely to be one of several financial factors, along with other considerations used in selecting a
project. Remember to look at all the factors given in an exam question scenario. The best choice might be a project that has
a longer payback period but has other advantages.
Cost-benefit Analysis
A cost-benefit analysis compares the expected costs of a project to the potential benefits it could bring the organization or
its stakeholders. This analysis results in a calculated benefit-cost ratio, which can be expressed as a decimal or a ratio.
The resulting “benefit-cost” ratio flips the terms in the more familiar “cost-benefit analysis.” Don’t be distracted
TRICKS
OF THE by that on the exam.
TRADE A benefit-cost ratio of:
• Greater than 1 means the benefits are greater than the costs.
• Less than 1 means the costs are greater than the benefits.
• Exactly 1 means the costs and benefits are equal.
Think About It.

Question:
What does a benefit-cost ratio of 1.7 mean?
A. The costs are greater than the benefits.
B. Revenue is 1.7 times the costs.
C. Profit is 1.7 times the costs.
D. Costs are 1.7 times the profit.
Answer:
B. The benefits, or revenue, the project brings to the organization are 1.7 times the cost of the initiative. Remember,
the benefit-cost ratio calculation is looking at revenue, not the smaller figure of profits.
Other things to know about this concept are:
• The organization may use the benefit-cost ratio to help choose from many potential projects.
• A project manager may perform cost-benefit analysis to determine the best solution approach to a selected project.
The project manager may perform the analysis at a high level during initiating and at a more detailed level during
planning. This information helps determine things such as what level of quality efforts are appropriate for the project,
what equipment or technology should be purchased, and whether it would be best to outsource certain pieces of work.
3.3 Exercise
Remember, you do not have to use accounting formulas to pass the exam (aside, possibly, from a present value
question). But you do need to have a general understanding of what the terms mean. Test yourself! For each row of
the following chart, write in your Exercise Notebook which project (A or B) you would pick based on the
information provided.
Project A Project B
1. Net Present Value $95,000 $75,000
2. IRR 13 percent 17 percent
3. Payback period 16 months 21 months
4. Benefit-cost ratio 2.79 1.3
Answer:
1. A
2. B
3. A
4. A
62
The following are some additional accounting terms related to project selection. Each one you are familiar with could
mean a point or more on the exam.
Economic Value Added (EVA)

For project selection, EVA asks whether the project returns more value than it costs.
Note: This is a different concept than earned value analysis (also known as earned value management or EVM),
which can also have the acronym EVA. Earned value analysis (EVA) (in the “Cost” chapter) is more frequently mentioned
on the exam, whereas economic value added appears rarely.
Opportunity Cost
The term opportunity cost refers to the opportunity given up by selecting one project over another. This does not require
any calculation.
Think About It. Think about the following example.

Question:
An organization has two projects to choose from: Project A with an NPV of $45,000 and Project B with an NPV
of $85,000. What is the opportunity cost of selecting Project B?
Answer:
$45,000. The opportunity cost is the value of the project not selected.
Sunk Costs
Sunk costs are expended costs — what you already spent, in other words. Sunk costs should not be considered when
deciding whether to continue with a troubled project.
Think About It. Those who are unfamiliar with accounting standards have trouble with the following question.
Question:
An organization has a project with an initial budget of $1,000,000. It is half complete and has spent $2,000,000.
Should the organization consider that it is already $1,000,000 over budget in determining whether to continue
with the project?
Answer
No. The money spent is gone.
Law of Diminishing Returns

This law states that after a certain point, adding more input (for example, programmers) will not produce a proportional
increase in productivity (such as modules of code per hour). A single programmer may produce at a rate of 1 module per
hour. With a second programmer, the two may produce at a rate of 1.75 modules per hour (0.75 increase). With a third
programmer, the group may produce at a rate of 2.25 modules per hour (0.5 increase). This disparity may be due to many
factors. For example, additional coordination is required as more programmers are added to a project.
Working Capital
This term refers to an organizations current assets minus its current liabilities. In other words, it is the amount of money
the company has available to invest, including investing in projects.
Depreciation
Large assets, such as equipment, lose value over time. This is called depreciation. Several methods are used to account for
depreciation. The exam may ask you what they are. You will not have to perform any calculations. (See, we said we could
make this easy for you!) Rather, you should simply understand the following about the two forms of depreciation:
• Straight-line depreciation With straight-line depreciation, the same amount of depreciation is taken each year.
Example A $ 1,000 item with a 10-year useful life and no salvage value (the value of an item at the end of its life)
would be depreciated at $ 100 per year.
• Accelerated depreciation Just know the following. You will not be questioned in further detail.
</ There are two forms of accelerated depreciation:
- Double declining balance
- Sum of the years’digits
■J Accelerated depreciation depreciates faster than straight-line depreciation.
Think About It. Here’s an example: $1,000 item with a 10-year useful life and no salvage value would be
depreciated at $ 180 the first year, $ 150 the second, $ 130 the next, and so on.
The exam may present information about project selection in the following ways.
TRICKS
OF THE • Business cases and project selection methods You need to understand that the project must support the
TRADE company’s strategic goals, there is a selection process for projects, and generally how the selection
process works.
• Project selection concepts An example is using internal rate of return (IRR) as an answer to a question or
as a distractor. A concept like this may be provided in the question even when you do not need it to answer
the question. Read the questions carefully to pick out the relevant data.
In summary, the project selection process includes the development of a business case and evaluating specific metrics
as described in this section. The business case describes the business need, the proposed solution, and the expected value
of the change the project will deliver to the organization and its stakeholders. It includes both tangible and intangible costs
and benefits of the proposed solution. The business case will influence how you approach every project management
process covered in this book, beginning with the creation of a project charter — the first of many processes that facilitate
the success of a project.
Project Methods and Artifacts

We briefly discussed OPAs and EEFs at the beginning of this chapter. In this section, we look at them in more detail and
discuss some methods that are frequently used in project management
Organizational Process Assets (OPAs)

Most organizations maintain two types of OPAs: processes, procedures, and policies; and organizational
knowledge repositories.
Processes, Procedures, and Policies Over time, organizations develop or adopt processes, procedures, and policies for
projects. Collectively, these processes, procedures, and policies are referred to as organizational process assets, and they
apply to aspects of the project such as quality, procurement, and resource management, as well as change control, safety,
compliance, and more. Artifacts from projects may recommend changes or ways to increase the efficiency of these processes
and procedures, but they are generally owned by the project management office or other departments responsible for
organizational governance.
Organizational Knowledge Repositories The other type of organizational process asset is organizational knowledge
repositories, which include information on many facets of projects.
Historical knowledge bases are maintained and updated by every project and made accessible to the rest of the
organization as part of organization repositories. Historical information can be used to plan and manage projects, thereby
improving the process of project management and avoiding challenges experienced by past projects. Here are examples of
historical information:
• Activities • Risks and risk response plans • Project documents
• WBSs • Estimates • Prototypes
• Backlogs • Retrospective findings • Baselines
• Benchmarks • Resources used • Correspondence
• Reports • Project management plans
Another aspect of historical information is lessons learned. We will discuss lessons learned in more detail in the
“Integration” chapter. For now, you need to know that lessons learned, which are created throughout projects, document
what went right, what went wrong, and what the team would do differently if they had the opportunity to start the project
over again. Lessons learned from each project become part of the lessons learned repository after project closure.
Other organizational knowledge repositories include:
• Configuration management, including file structure, file-naming conventions, baselines of organizational standards,
and templates of project documents
• Financial data, including budgets and actual costs of completed projects
• Issue logs and documentation regarding defects on projects
• Metrics that may be useful for other projects
• Project management plans and baselines, as well as project documents, such as network diagrams, risk registers, and
stakeholder registers
When answering questions on the exam, assume the organization has historical records and lessons learned from
previous projects and that the company has incorporated these records into an indexed organizational knowledge
repository available to all.
Enterprise Environmental Factors (EEF)

EEFs are similar to organizational process assets as they provide context within which to plan the project. However,
enterprise environmental factors are generally outside the control of the project team.
Enterprise environmental factors external to the organization include governmental or other rules and regulations
that apply to the performing organization. Internal enterprise environmental factors include the structure, governance,
culture, systems, and geographic location(s) of the organization. Resource-related EEFs include the technology and
resources available for assignment to projects, such as documentation of the skills and abilities of internal and preapproved
external resources that are available through approved agreements. EEFs related to project management may include a
resource management system, a procurement system, and a quality management system.
When answering questions on the exam, assume that the impacts and limitations imposed by enterprise environmental
factors are taken into consideration during planning and as the work is carried out.
Since EEFs and OPAs contribute to and are influenced by the organizational context in which projects exist, they are
essential to understanding domain III (Business Environment) in the Examination Content Outline (ECO). For a
complete view of the project environment, you should also understand that these factors influence and are influenced by a
set of frequently used tools and techniques available within the organization and developed through individual experience.
Assumption Log The assumption log is a repository of both assumptions and specifics related to constraints. It is started
at the time the project charter is developed. Assumptions and constraints are first identified at a high level in the business
case and project charter. They will receive further attention as the project progresses. The assumption log is an input to
many project processes, and assumption log updates are a frequent output.
Assumptions are comparable to expectations, as they may not be entirely
based on fact. Stakeholders may not realize they are making assumptions, and
therefore may not articulate them when communicating their requirements.
Incorrect assumptions introduce risk to the project, so they must be identified and
managed by the project manager.
Constraints Constraints are easier to identify than assumptions, as they are

usually clearly imposed by management or the sponsor. A project manager must
juggle many things on a project, including project constraints such as schedule,
cost, risk, scope, quality, resources, customer satisfaction, and any other factors that
limit options (see figure 3.5). For example, the date a milestone deliverable is due,
the date by which the project must be completed, and the maximum allowable risk
a project may have are all constraints.
FIGURE 3.5 Project constraints
65
Management directly or indirectly sets the priority of each constraint. This prioritization is then used to plan the
project, evaluate the impact of changes, and prove successful project completion. It is important to evaluate the effect a
change to one constraint has on another. Changes to the project plan generally impact multiple constraints.
Take time to really understand the discussion of integrated change control in the “Integration” chapter. Understanding
the relationship between the constraints and how they impact a project can help you get several questions right on the exam.
Frequently Used Methods

There are over 100 tools and techniques in the PMBOK" Guide, and there are many more that we discuss in this book. It’s
important to use the right method for the right purpose under the right conditions. It is also important to realize methods
can have multiple applications throughout the project management process.
You don’t have to be an expert at using all of them, but you do need to understand the purpose of each method. The
following are categorized by their function.
Data Gathering If you need to collect input from stakeholders, you can use one or more of the following data-
gathering methods:
• Benchmarking • Cost of quality
• Brainstorming • Interviews
• Prompt lists • Market research
• Checklists • Questionnaires and surveys
• Check sheet
Data Analysis Depending on the type of data you are working with and the depth of analysis you need to do, you can
choose from many data analysis methods, including the following:
• Alternative analysis • Forecasting
• Assumptions and constraints • Performance reviews
• Business justification analysis • Reserve analysis
y Payback period • Root cause analysis
>/ Internal rate of return • Simulation
• SWOT
y Return on investment
• Trend analysis
y Cost-benefit analysis
• Value stream mapping
• Decision tree analysis • Variance analysis
• Document analysis • What-if analysis
• Earned value analysis
• Expected monetary value
Data Representation Throughout the project, you will gather and generate data from various sources for a number of
purposes and transform that data to information through data analysis. This category includes options for representing, or
communicating, data and information. Data representation methods include the following:
• Affinity diagrams • Probability and impact matrices
• Cause-and-effect diagrams • Release maps
• Control charts • Scatter diagrams
• Flowcharts • Stakeholder engagement assessment matrices
• Hierarchical charts • Stakeholder mapping/representation
• Histograms • Text-oriented formats
• Logical data models
• Matrix diagrams/charts
• Mind mapping
66
Decision-Making Throughout the project, you will have to make countless decisions, often with the input of the project
team. The use of data analysis and representation all support decision making. There are many approaches to decision
making, including the following methods, which are used in many project management processes:
• Fist of five
• Multicriteria decision analysis
• Voting
Communication As you will read later in this book, a great deal of a project manager s time is spent communicating with
management, the team, the customer, and other stakeholders. The following are several important communication
methods and concepts you will use throughout the project:
• Active listening • Presentations
• Appreciative inquiry • Meeting management
• Daily standup • Communication methods
• Feedback • Communications technology
Interpersonal and Team Skills Interpersonal and team skills are elements of the art of project management. Closely
related to the communication methods and concepts listed above, the following skills are essential for project success:
• Conflict management • Meeting management
• Cultural awareness • Motivation
• Decision-making • Negotiation
• Emotional intelligence • Networking
• Facilitation • Observation/conversation
• Influencing • Political awareness
• Leadership • Team building
Estimating The project manager is responsible for leading estimating efforts for many aspects of the project, including
schedule, cost, and resources. The following are common estimating methods you will learn about in this book:
• Analogous • Top-down
• Bottom-up • Expert judgment
• Parametric • Planning poker
Project Management Information System (PMIS) An organizations project management information system is part of
its enterprise environmental factors. The PMIS includes automated tools, such as scheduling software, a configuration
management system, shared workspaces for file storage or distribution, work authorization software, time-tracking
software, and procurement management software, as well as repositories for historical information. The PMIS is used in
many planning, executing, and monitoring and controlling processes.
Expert Judgment Sometimes, the easiest way to get information is to consult experts. Often, those with expertise needed
by the project are working on the team, or at least within the organization. Expert judgment is a common tool of the project
management planning processes, although it is not frequently discussed in this book.
Meetings Meetings are often used in the planning processes of a project, although you will not always see meetings
discussed in this book as a planning tool. Meetings can be an effective way to get input or feedback from groups of people,
but they can be overused. The project manager is responsible for determining whether a meeting is worth the time of those
who would attend it, or if there is a more efficient way to achieve an objective.
Work Performance Data, Information, and Reports A great deal of data and information is generated, considered, and
communicated throughout the life of a project, from initial observations and measurements to analyzed content and
reports. The Process Groups Model: A Practice Guide uses these three terms to identify the stages through which this data
and information move.
67
Work performance data includes the initial measurements and details about activities gathered during the Direct and
Manage Project Work process in executing. When monitoring and controlling a project, work performance data is analyzed
to make sure it conforms to the project management plan. It is also assessed to determine what the data means for the
project as a whole. The result is known as work performance information. Work performance information can then be
organized into work performance reports, which are distributed to the various stakeholders who need to receive and
possibly act on the information.
For example, let’s say a project team performs their assigned work according to the project management plan. A
certain activity took 10 hours and was completed on July 21. This is work performance data. The next step is to look at how
this data compares to the project management plan (in this case, the project schedule). The activity was estimated to take
12 hours, with an estimated completion date of July 22. The project manager can analyze why this activity took less time
than planned and what this will mean for the rest of the project. Why was the work completed early? Will this mean
improved performance for the rest of the project? Did the team follow the communications management plan and notify
resources assigned to successor activities about the anticipated early completion so they could start their work early?
Should future activities be re-estimated if similar resources will be performing similar work?
If the activity was on the critical path and had taken longer than scheduled, a formal change request might have been
required to adjust the rest of the schedule.
Project Roles
Who are the people involved in delivering a project and what should they each be doing? This section will help you under
stand the roles of the project manager, agile coach (or team lead or Scrum Master), the product owner, sponsor, team, and
other stakeholders, as well as functional (resource) managers and program and portfolio managers. Read each role over
view and then examine the more specific activities listed for each role.
Think About It. Responsibilities vary by organization so think about your own experience, but be sure you
. understand roles as described here for exam purposes. Use each of these overviews to gain a general understanding
of each role on a project and for understanding roles as used in the rest of this book. Responsibilities are further
elaborated on in the section following this one. Also keep in mind that these overviews and the responsibilities
lists that follow are not exhaustive but are certainly more than sufficient to help you correctly answer exam
questions.
The Project Manager Role

You no doubt understand that a project manager is accountable for ensuring a project meets its objectives and delivers its
value and benefits to the organization and its stakeholders. Collectively, of course, the entire project team is responsible for
making this happen, and other stakeholders have responsibilities to this goal too. But how is the project manager referred
to in exam questions?
Do not assume that if you recognize a question as describing an agile or hybrid environment, you will not see
TRICKS
OF THE the term “project manager” used in the question or answers. The exam may use the term “project manager” in
TRADE questions regardless of whether it is referring to a predictive, adaptive, or hybrid project.
Predictive Project Environments The project manager s role includes gathering information to initiate the project,
ensuring that the projects scope is completed on time and within budget. This includes approved changes, which go
through a formal change control process. This work includes ensuring that the project meets other objectives related to
communications, stakeholder, risk, quality, and procurement management. The project manager directs and contributes to
planning and manages the teams work and physical resources while the team works to build the product of the project.
68
Adaptive Project Environments In addition to the agile coach (described next), there is often the need for
the project manager on agile projects. For example, the product owner (described next) and the rest of the
team are focused on project risk as it relates to product features and stories (increments of work broken down
from features). What happens if the organization moves in a direction that may mean the project will be
cancelled or changed in a significant way? This strategic information is something the project manager pays attention to
and negotiates within the business environment. The project manager then circles back to the team on what should be
done on the project moving forward.
The project manager will also be focused on organizational change management that may result from the project
while the team is focused on building the product and not these broader changes.
The Process Groups Model In a predictive environment the project manager is responsible to plan the project with help
from the team and other stakeholders, and communicate with the project sponsor and other stakeholders who may
represent the customer or organizational point of view. The project manager is accountable to ensure that the project is
properly initiated, planned, executed, monitored and controlled, and closed according to the Process Groups model or
whatever plan-driven methodology an organization uses.
When you see a question on the exam about a project that clearly uses a plan-driven methodology, think
TRICKS
OF THE “Process Groups.” An answer that fits the scenario in question whose terminology adheres to Process Groups
TRADE model practices is correct over one that appears to fit with agile methods. For example, a plan-driven project
“ question will not lldVC
Will 11UU havedllan
<1 answer that includes the terms “iteration” or “retrospective,” but instead will include
1terms like “phase” or lessons learned.
The Agile Team Leader Role

The term “agile coach” is one of several terms used to refer to an agile team’s servant leader, and it is the one
we will use in this book unless we are specifying a Scrum Master. These are the relevant terms to understand
in the context of the exam:
• Agile coach This is as a servant leader whose responsibility is to ensure that the adaptive methods and processes to
be used on the project are well understood and being followed, and to help the team by removing impediments to
building and delivering the product of the project The agile coach is also a member of the team where everyone is
collectively responsible for all stages of the project and the building and delivery of the product.
• Team lead You may or may not see this term on the exam, but it is generally considered to be synonymous with “agile
coach.”
• Scrum Master By definition the term “Scrum Master” is used to refer to the servant leader of an agile project that is
using the specific agile methodology known as Scrum (see “Common Agile Methodologies” chapter). But in practice
people mix the terms “agile coach” and “Scrum Master” all the time. So it maybe used on the exam to refer specifically
to a Scrum scenario, or it may be used as a synonym for “agile coach.”
On the exam, you may see more general terms referring to “agile” projects and methods mixed with those
referring to “Scrum Master” or other Scrum-specific terms. PMI may mix and match these terms so don’t let
that distract you from the correct answer!
The Product Owner Role

This role was originally associated with Scrum although all types of agile teams may utilize it. The product owner
(representing value management on the project) is responsible for maximizing the value of the product to the customer
and return on investment for the organization. They prioritize all work in the backlog to realize the business value of the
product as quickly as possible. In this respect the development team members take direction from the product owner on
work item priority, pulling from the top of the backlog (or worklist) that the product owner has prioritized. The team also
assists the product owner in prioritization by sharing technical requirements, dependencies, and work estimates.
The product owner is a team member and works with the team daily. While the team is building the product during a
given iteration (or sprint in Scrum), the product owner is answering questions and getting stories prepared for the
next iteration.
The Product Manager Role

The term “product manager” is not limited to agile or even project environments and its exact meaning may depend on
organizational culture. While you are not likely to see a specific question about this on the exam you should understand it
as distinguished from the product owner role on agile projects. There are usually multiple projects over any one products
life cycle. A product manager is the liaison between an organizations business strategy, its design and development subject
matter experts (SMEs), and its customers (internal or external). You can think of the product manager optimizing value to
the customer and return on investment for the organization over a product’s fife, while a product owner does this in service
to a particular project. The product manager may lead product owners within an organization or within the needs of a
specific product, depending on the size and complexity of the organization and its products.
The Project Sponsor/lnitiator Role

A sponsor is one who represents organizational leadership and supports the project, both financially and to help the project
manager and team with decisions outside of the project managers and team’s authority. The sponsor partners with the
team to facilitate their success and can protect the project from unnecessary changes. In procurement situations, the selling
organization should also have a sponsor.
The sponsor is accountable to ensure that the project and its product delivers the business value for
which it was undertaken. In this respect, in agile and hybrid approaches, the product owners role is in some
ways analogous to that of a sponsor, being responsible for ensuring the project delivers value and benefits. But Agile
Focus
this is a shared responsibility and the project should still have a sponsor in organizational leadership. Notice
that the product owner was also described as having a role similar in some ways to that of a project manager.
For the exam, be careful to think about the role being described in the question. While there is overlap, the roles are distinct.
Think about your organization’s leadership as you read this. Do your projects have sponsors, and do they know what
their role is on your projects? Someone must serve as a protector of the project and its priorities as long as the project
continues to meet the organizations strategic goals.
The Project Team Role

The project team is a group of people, including the project manager, who will complete the work of the project. Team
members can change throughout the project as people are added to and released from the project. An agile environment
may include the concept of keeping stable teams within an organization and bringing projects to the team, while more
traditional approaches tend to assemble teams as new projects are initiated.
Generally, it is the team’s role to help plan what needs to be done by creating the WBS or backlog and estimates for
work packages or activities. Team members complete activities to produce the deliverables represented as work packages
or features and help look for deviations from the project management plan during project executing and monitoring and
controlling. In agile environments, team members are responsible for clarifying user stories with the customer so they can
estimate and plan the releases and iterations, hold reviews and retrospectives, and update the project information using
tools like Kanban boards and burndown charts.
On large projects, the project manager may select team members to help perform project management activities. This
group is known as the project management team. Members of this team must have project management training. For the
exam the term “project management team” refers to this subset of the team or project team, and it includes the
project manager.
The Stakeholder Role

A stakeholder is anyone who will be impacted by the project or may positively or negatively impact the project. This
includes the customer or end user, the project manager and team, the project’s sponsor, program and portfolio managers,
the project management office, functional or operational managers within the organization, other departments or groups
within the organization (such as business analysis, marketing, procurement, quality, or legal), and external sellers that
provide services or materials for the project. Questions about the role of stakeholders and how they or their work should
be managed appear throughout the exam.
70
Stakeholders may be actively involved in the project work or may fill an advisory role. The stakeholders’ role on a
project is determined by the project manager and the stakeholders themselves. Stakeholders should be involved in planning
the project and managing it more extensively than many people are accustomed to on their projects. For example, project
managers should involve the customer in planning and controlling a project.
Customer representation is built into agile environments through the role of product owner or value
management team, and this is increasingly so on hybrid and traditional projects. The product owner role can
be filled by someone from the business who is responsible for working with the team to prioritize features.
A project manager should analyze and manage the needs and levels of influence of stakeholders
throughout a project and in balance with project constraints. Although the “Stakeholders” chapter includes an in-depth
discussion of stakeholder management, stakeholders are discussed throughout this book.
The Functional or Resource Manager Role

A functional or resource manager is responsible for the human and physical resources in a specific department, such as IT,
engineering, public relations, marketing, etc., and for working with the project manager to meet the needs of the project.
As managers of people, facilities, or equipment, functional or resource managers maintain a calendar indicating availability
of these resources for projects and organizational work. This might involve negotiation if people, facilities, or equipment
are needed by more than one project at the same time. If there are issues with resources provided by the functional manager,
project managers collaborate with them to resolve the issues.
Earlier in this chapter we discussed different organizational structures. The degree that functional managers are
involved in a project depends on whether the organization has a matrix, project-oriented, or functional organizational
structure. To avoid conflict, the project manager and functional managers must balance their respective needs regarding
the use of resources to complete project and operational work. It is generally the responsibility of the project manager to
manage this relationship by using clear communication and interpersonal and team skills, such as conflict management
and emotional intelligence.
The Program and Portfolio Manager Roles

These roles are not likely to have a big impact on exam questions but they should be understood in terms of the environment
where projects take place.
Program Manager This person is responsible for managing a group of related projects, combined into programs to
provide coordinated control, support, and guidance. The program manager provides oversight to meet both project and
program goals.
Portfolio Manager This person is responsible for governance at an executive level of the programs, projects, and
operational work that make up a portfolio.
3.4 Exercise
The following lists contain the responsibilities for each of the project roles. Read these lists carefully and check off
each responsibility you think you truly understand. Completing this exercise will help you identify gaps so you can
pay particular attention to understanding those responsibilities as you read the rest of this book. You will want to
come back to this exercise after you have completed your studies and ensure you can check off all the responsibilities,
meaning you understand them all in the project context. Getting some exam questions right will depend upon your
understanding or “who is responsible for what” on a project.
Note: Each of these lists should give you a good sense of the respective role, but they are not all-inclusive or pre
sented in a particular order.
Responsibilities Lists by Role

Now that you understand the fundamentals of each role on a project, use these lists to think more specifically about what a
person in each of these roles should be doing on a project.
Project Manager Responsibilities List (in collaboration with the team)

□ Assigned to the project no later than initiating □ Write the project charter
□ Be a servant leader □ Identify stakeholders, support stakeholder
□ Apply project management knowledge and engagement, and manage stakeholder expectations
interpersonal and leadership skills to achieve throughout the project
project success □ Identify and deliver required levels of quality
□ Assist the team and other stakeholders □ Manage project knowledge, including sharing
□ Identify and analyze constraints and assumptions lessons learned
□ Lead and direct project planning □ Use rewards and recognition
□ Control the project but not necessarily the resources □ Solve problems and remove impediments to the
□ Help identify dependencies between activities teams progress
□ Take action to produce a realistic schedule □ Demonstrate ethics and leadership
□ Develop time and cost reserves for the project □ Manage and control resources
□ Understand and foster professional and □ Keep team members focused on risk management
social responsibility and risk responses
□ Control the project by measuring performance and □ Coordinate interactions between the project team
determining variances from the plan and key stakeholders
□ Monitor risk, communications, and stakeholder
□ Integrate project components into a cohesive whole
that meets the customer s needs engagement to ensure they’re in conformance
with requirements
□ Determine the need for change requests, including
recommended corrective and preventive actions and □ Finalize and gain approval of the project
defect repair management plan
□ Influence team success by promoting good □ Use metrics to identify variances and trends in
communication, enhancing positive aspects of project work, and be responsible for analyzing the
cultural differences, and resolving team issues impact of variances and trends
□ Understand how cultural differences may impact the □ Work with the team to resolve variances from the
project (including global teams, virtual teams, or project management plan
projects involving multiple organizations) □ Approve or reject changes as authorized, facilitate
□ Spend more time being proactive than dealing change control, and sit on the change control board
with problems (Note for agile this is the product owner)
□ Perform project closing at the end of each phase and □ Ensure professional interactions between the team
for the project as a whole and other stakeholders
□ Select appropriate processes for the project
Agile Team Leader Responsibilities List

□ Be a servant leader □ Attend team meetings such as daily standups,
□ Ensure the processes to be used on the project are iteration planning, reviews, and retrospectives
understood and being followed □ Apply ground rules or team charter
□ Remove impediments for the team □ Help resolve conflict where appropriate
□ Help identify requirements □ Help ensure a common understanding of the project
□ Help identify and analyze project constraints and product visions
and assumptions □ Influence the team and environment by facilitating
□ Help identify, analyze, and engage stakeholders communication and enhancing positive aspects of
□ Participate in the risk management process cultural differences
72
Product Owner Responsibilities List

□ Represent value management for the team □ Attend team meetings such as daily standups,
and stakeholders iteration planning, reviews, and retrospectives
□ Help identify and engage stakeholders □ Serve as spokesperson for the project
□ Help identify requirements □ Help ensure a common understanding of the project
□ Help identify constraints and assumptions and product visions
□ Prioritize product and iteration backlogs for □ Participate in the risk management process
the project □ Accept product increments or describe what is
□ Keep the backlog updated missing or inadequate during reviews
□ Enforce ground rules or team charter
Project Sponsor Responsibilities List

During Initiating (or before):
□ Provide high-level scope and requirements □ Provide funding
□ Participate in developing the business case and □ May (with the customer) dictate milestones, key
vision for the project events, or the project end date
□ Guide the process to get the project approved □ Help to set priorities between projects
□ Help to define the measurable objectives □ Advocate for or champion the project
□ Determine (with the customer) priorities between □ Provide information that helps develop the
project constraints project charter
□ Maintain support for the project □ Approve the project charter
□ Serve as spokesperson for the project, including to □ Give the project manager authority as outlined in the
upper management project charter
□ Facilitate buy-in throughout the organization □ Encourage the finalization of high-level requirements
and scope by stakeholders
During Planning:
□ Communicate the project vision to the project □ Help the project manager and team to balance
manager and team stakeholder priorities
□ Provide the project team with time to plan □ May review the WBS
□ Determine the reports needed by management to □ Help evaluate trade-offs during crashing, fast
oversee the project tracking, and re-estimating
□ Help identify project risks □ Approve the final project management plan
During Executing and Monitoring & Controlling:

□ Support the efforts of the project manager and team □ Approve, reject, or defer changes, or authorize a
□ Protect the project from outside influences and change control board to do so
unnecessary changes □ May direct that a quality review be performed
□ Enforce quality policies □ Resolve conflicts that extend beyond the project
□ Provide expert judgment manager s control
□ Help evaluate trade-offs during crashing, fast □ Support the project manager in monitoring
tracking, and re-estimating project progress
□ Clarify project vision and project scope questions
75
Project Management Foundations THREE
During Closing:
□ Provide formal acceptance of the deliverables (if they □ Support the collection of historical records from
represent the customer) the project
□ Enable an efficient and integrated transfer of □ Provide rewards and recognition
deliverables to the customer
Team Responsibilities List

□ Help identify and involve stakeholders □ Apply ground rules or team charter
□ Help identify requirements □ Execute the project management plan to accomplish
□ Help identify constraints and assumptions the project scope
□ Help create the WBS or product backlog □ Attend project team meetings
□ Decompose work packages into activities, or □ Recommend project changes, including corrective
decompose stories into tasks and preventive actions
□ Identify dependencies between activities □ Implement approved changes
□ Provide schedule and cost estimates □ Share acquired knowledge
□ Participate in the risk management process □ Contribute to the lessons learned register
□ Comply with quality and communications plans
Stakeholder (Customer) Responsibilities List

□ Help create the project charter □ Identify constraints and assumptions
□ Be involved with governance □ Identify requirements and project scope
□ Approve project changes □ Manage risk
□ Attend reviews and accept or reject deliverables □ Help develop the project management plan or the
presented; provide feedback backlog and release roadmap
□ Be a risk owner □ Help document lessons learned
□ Participate in phase gate reviews □ Provide expert judgment

□ Identify issues □ Participate as a member of the change control board
Functional or Resource Manager Responsibilities List

□ Assign specific individuals to the team and negotiate □ Inform the project manager of other projects or
with the project manager regarding team and departmental work demands that may impact
physical resources the project
□ Manage activities within their functional area □ Sit on the change control board
□ Participate in project planning until work packages □ Participate in rewards and recognition for
or activities are assigned team members
□ Provide subject matter expertise □ Improve resource utilization
□ Participate in risk identification □ Participate in quality management
□ Approve the final schedule during schedule □ Approve the final project management plan or
development when it involves team or physical backlog/release roadmap when it involves team or
resources under their control other resources under their control
□ Recommend project changes including preventive □ Assist with issues related to team or physical
and corrective actions resources under their control
Program Manager Responsibilities List

□ Manage related projects to achieve results not □ Provide oversight to adjust projects for the
obtainable by managing them separately programs benefit
□ Ensure selected projects support strategic goals of □ Guide and support individual project
the organization managers’ efforts
Portfolio Manager Responsibilities List

□ Direct projects and programs that maybe □ Work with senior executives to gather support for
largely unrelated individual projects
□ Ensure selected projects provide value to □ Get the best return from resources invested
the organization
75
lb
QUICKTEST
• Integration Management
Integration process
• Project charter
• Project management plan
• Individual management
plans
• Project life cycle
• Development approach
• Management reviews
Introduction • Tailoring
• Performance
How would you respond if you were asked, “What is a project manager s primary role?” The correct
measurement baseline
answer is: To perform integration management—to pull all the pieces of a project together into a cohe
• Requirements
sive whole—the processes, people, and goals for which the project was undertaken. This is so much a management plan
part of a project manager s job that it is arguably the reason for the project manager s existence in an • Change management
organization and on a project. plan
All stakeholders have the common purpose of achieving project objectives efficiently and in • Configuration
management plan
compliance with scope, schedule, and cost baselines as well as agreed-upon quality requirements,
• Project documents
while effectively managing uncertainty. While the work is being done:
• Kickoff meeting
• Team members are concentrating on completing the work packages or stories. • Work authorization
• The project sponsor is supporting the project and the team, protecting assigned resources from system
being diverted to other activities within the organization, and acting as a management consultant • Knowledge management
to the project manager. - Explicit knowledge
- Tacit knowledge
• The project manager is integrating all project components—the team and all other stakeholders,
• Osmotic communications
project constraints, processes, and internal and external elements that may affect the project both • Lessons learned
internal and external to the project and the organization. • Change Requests
• The project manager is also communicating within the organization, usually with management, - Corrective action
to integrate the project s needs with those of related portfolios and programs within the larger - Preventive action
organization, and within society at large. - Defect repair

• Change control board
(CCB)
This difficult and challenging job requires a project manager to have technical project management
• Process for making
skills, of course, but they must also be an accomplished innovative thinker and collaborative leader and
changes on a plan-driven
possess empathy and business savvy. project
• Agile change
Think about integration as balancing all project activities with each other while at the
management
same time being a project ambassador for all stakeholders: The team, customers, • Transitions
management, government regulatory bodies, and any others involved.
Keep in mind that project management activities do not happen independently of one another.
Example To complete an estimated budget, factors must be taken into account such as time and
resources needed to create individual work packages or stories (i.e. product increments), available
resources, and the costs of managing identified risks. The draft budget must also be reconciled with
financial considerations within the larger organization before it is approved.
Read this chapter carefully. Integration management can be a difficult content area because it is
something we do as project managers, but we may not often think about it as a separate process, with
everything that process entails.
77
Integration FOUR
Integration Management Overview

As mentioned in chapter 1, we will include here an illustration showing select Examination Content Outline (ECO) tasks
alongside PMI’s Process Groups model for that process. This will help you understand an overall process - in this case, In
tegration Management. Again, the PMBOK* Guide domains listed here are ones we think fit well into the discussion of the
process, but we will delve into the PMBOK9 Guide in more detail in chapter 18.
For now, focus on the processes represented by the Process Groups model, the ECO tasks, and the associated agile
and hybrid concepts.
The Examination Content Outline and Process Groups Model
Think About It. In the ECO, domain II has seven tasks most closely associated with integration management in
the Process Groups model. Some tasks might not translate as easily, but in reality, integration and the tasks
associated with it are some of the most important tasks of a project manager. If you haven’t done so already, take
out your copy of the ECO and review these domain II tasks and their enablers as you review this page of this book.
Example Task 1: “Execute project with the urgency required to deliver business value.” Wouldn’t you say that is
exactly what we are doing all the time as project managers? We are executing the project with the urgency required to
deliver the business value to the organization and its customers, for which the project was undertaken.
Task 1 is also related to directing and managing project work, managing project knowledge, monitoring and controlling
project work, change control, and closing project phases and the project—all processes in the Integration Management
area of the Process Groups model.
ECO Process Groups Model PMBOK® Guide

Domain II Integration Management
Taski Domain 2.1
Execute project with the urgency required to Develop Project Charter — Initiating Stakeholders
deliver business value
Develop Project Management Plan — Planning Domain 2.2
Task 9 Team
Integrate project planning activities Direct and Manage Project Work —>
Domain 2.3
Executing
Task 10 Manage Project Knowledge —I Development Approach and Life Cycle
Manage project changes
Monitor and Control Project Work —i Monitoring Domain 2.4
Task 12 Planning
Manage project artifacts Perform Integrated Change Control —I & C°ntro,lin9
Domain 2.5
Task 13 Close Project or Phase — Closing Project Work
Determine appropriate project
Domain 2.6
methodology/methods and practices
Delivery
Task 16
Domain 2.7
Ensure knowledge transfer for project continuity
Measurement
Task 17
Domain 2.8
Plan and manage project/phase closure
Uncertainty
or transitions
Now think about the other domain II ECO tasks as they relate to what is in the Process Groups model:
• Task 9: Integrating project planning activities starts in Initiating with developing the project charter (and stakeholder
analysis and development of the stakeholder register).
• Task 13: Determining appropriate methodology and practices is just like the first activity in the Planning column of
Rita’s Process Chart™ (in the “Project Management Foundations” chapter). While not directly listed as an integration
process in the Process Groups model, it is what the project manager needs to start creating the project management plan.
• Tasks 9 and 12: The first of these is obvious—task 9. The project manager needs to integrate the many planning
activities to develop the project management plan (a project artifact). The project management plan is a series of plans
for each project constraint (scope, schedule, cost, quality, risk, etc.), plus plans for requirements management,
78
Integration
configuration management, and change management. These plans are started separately but as each plan matures it
requires integration with the other plans, since each project constraint is interdependent with and can affect all others.
• Task 10: Project changes will be managed according to the plan for change management.
• Task 16: As the project manager and the team learn throughout the project, the project manager will need to see that
this knowledge is shared for the benefit of the project and documented so the project artifacts can benefit the
organization in the future. You can also map task 16 to the Process Groups model processes Direct and Manage
Project Work and Manage Project Knowledge.
• Task 17: Can you see from the wording of this task that it carries the same responsibility as Close Project or Phase in
the Process Groups model?
Figure 4.1 is a visualization of the integration management processes from the Process Groups model. Remember
that for each chapter in which the domain II processes are discussed, we will use the Process Groups model to help you
understand the general process. Since the Process Groups model was created based on managing plan-driven projects, we
also explain the different methods agile practitioners use to get to the same goals. It is worth repeating: The goal is to work
to meet project requirements with the urgency needed to deliver the benefits and value for which the project was selected
and undertaken.
FIGURE 4.1 Integration management process
Besides the five process groups, the Process Groups model identifies certain areas that work is focused on (most of
which are project constraints). These categories are integration, stakeholders, communications, resources, scope, schedule,
cost, quality, risk, and procurement. Figure 4.2 shows the relationship between these categories and process groups from
the Process Groups model. With figure 4.2 you can easily see where a project manager s activities are focused by category.
For example:
• All project management categories have project management processes in planning and monitoring and controlling.
• Scope, schedule, and cost show no project management activity because it is the team that is executing the work to
build the product of the project, while the project manager monitors and controls all project work.
• Stakeholder engagement has no process for closing because when a project or phase is closed, the project manager has
already managed the stakeholder engagement for that phase or the project.
• Did you notice that Integration Management is the only project management category that has processes occurring in
all process groups? The project manager is always integrating.
79
Integration FOUR
We encourage you to return to figure 4.2 after you have had the opportunity to study the process-related chapters in
this book. The process-related chapters help you with the details while this figure helps you understand the big picture.
Process Groups
Monitoring
Initiating Planning Executing & Controlling Closing
Integration
Scope Scope
Schedule Schedule
CD Cost Cost
o
CTi Quality
O
ro
o Resources
Communications
Risk
Procurement
Stakeholders
Figure 4.2 The relationship between the process groups and the major project management process categories
Develop Project Charter
The Develop Project Charter process includes using all the information known about Process Groups Model
a project from the project selection process to achieve an approved (signed) project PG: Initiating
charter. The project charter authorizes the project to continue. This process also in Process: Develop Project Charter
cludes the creation of an assumption log, which is an artifact of developing the project
charter. The assumption log is updated throughout the project, as assumptions and ECO
constraints change and new assumptions are uncovered. Domain II

Task 8 Plan & manage scope
Task 9 Integrate project plan
Creating the Project Charter ning activities
The purpose of the charter is to plan the project at a high level to assess whether it is
feasible within the given constraints. Detailed planning begins only after the charter is
signed. In project initiating, the project manager meets with key stakeholders to refine PMBOK* Guide
the high-level objectives, requirements, scope, risks, assumptions, and other Domain 2.4 Planning
constraints. Then, the information gathered is used to confirm the project is realistic,
aligns with the organizations strategic goals, and is likely to deliver the anticipated
benefits and value. Additional resources (time and money) are spent only after the project charter is approved.
The project manager most often creates the project charter, but it is issued (signed off on) by the sponsor during
initiating. The charter should be broad enough that it does not need to change as the project progresses. Changes to the
project charter, beyond initiating, should call into question whether the project should continue.
Projects that include agile or hybrid approaches tailor charter documents. For example, a project charter
may articulate that there is more uncertainty about requirements or the product deliverables at the beginning
of the project. How the governance of the project is explained may also contain different information. For Agile
Focus
instance, instead of a formal change control board a project’s product owner may typically have the authority
to make decisions regarding change management and prioritizing requirements.
80
FOUR Integration
4.1 Exercise
Test yourself! Answer the following questions in your Exercise Notebook.
• What does the project charter do for the project and the organization?
• Why is it so necessary?
Answer
The project charter describes the project goals and objectives and defines how success will be measured. For the
exam, know that the charter at a minimum does the following:
• Formally authorizes the existence of the project, or establishes the project
• Gives the project manager authority to commit resources to the project
• Provides the project objectives, high-level requirements, and success criteria
• Defines roles and responsibilities at a high level
• Clarifies a common understanding of the project’s major deliverables and milestones, between the sponsor
and project manager
• Links the project to the ongoing work of the organization
On the exam, assume it is the project charter that gives the project manager the authority on the project (to use the
organizations resources to the projects needs). This authority helps the project manager get work done through others
who do not directly report to them.
The process of creating the charter uncovers the assumptions recorded as the start of the assumption log. These
assumptions will later be updated or addressed in the detailed requirements gathering, scope definition, and risk
management efforts. Can you see that the creation of a project charter should address and influence all the project
management constraints? Aside from the assumption log and the charter, you should have the following documented in
their respective project artifacts:
• Identified and analyzed stakeholders
• Defined project objectives, constraints, and success criteria
• Confirmed high-level requirements
• Preliminary product scope definition
• Documented initial risks and issues
Some of the tools and techniques that can be used during this process include data gathering (interviews,
brainstorming, focus groups, etc.), conflict management, and meeting management. During meetings with the sponsor
and key stakeholders, the project manager can obtain needed information and work with experts to understand and
address organizational strategy and develop measurable project objectives.
Note: The following charter example is not an exact template; a charter should be tailored to meet the needs of the
business and project. This example is meant to show you the types of sections that maybe included and what those sections
may summarize. Also note that this charter refers to attached documents that are not included in this example.
81
Integration
Project Charter
Project Title and Description (What is the project?) Upgrade the Payroll Systems
We’re a large, multinational organization with more than 20,000 employees, so human resource management is critical to
our success. To more efficiently compensate our employees, we want to replace or upgrade the employee payroll systems
to better reflect the changing nature of our workforce. Employees now work in various locations (offices and homes)
around the world, work simultaneously for multiple business units, and have more varied work schedules than ever
before. Current geographically focused payroll systems are not integrated, are inflexible, and require significant clerical
time to maintain them manually. With the existing systems, consolidated corporate reporting and analysis is expensive
and inefficient.
Project Manager Assigned and Authority Level (Who is given authority to lead the project, and can they determine, manage,
and approve changes to budget, schedule, staffing, etc.?)
Isaiah Higgins will be the project manager for this project. He may request any team members he sees fit and will work
with resource managers to secure the needed resources. He has signature authority up to $10,000. Ashley Chan is
assigned as assistant project manager.
Business Case (Why is the project being done? On what financial or other basis can we justify doing this project?)
Administering payroll currently costs $2.4 million annually along with the unmeasured costs of procedural inefficiencies.
The industry average payroll processing costs for a global company our size is $100 per employee per year, or $2 million
overall per year. Anticipated savings of $400,000 per year (assuming a three-year payback period) justifies the approval of
this project. See the detailed business case attached to this charter.
Resources Preassigned (How many or which resources will be provided?)

The corporate payroll processing group will be closely involved in this project, along with the payroll specialists who
work in our local offices. A senior team of business analysts, enterprise architects, and software designers has been iden
tified for the initial research and analysis phase. Procurement and legal representatives will be involved in seller contract
processes, including development of RFPs and contracts when deemed necessary. English will be the primary project
language; local language experts will be involved to ensure country-specific regulations and laws are understood. Other
required resources must be identified and negotiated for by the project manager.
Key Stakeholder List (Who will affect or be affected by the project [influence the project], as known to date?)
Attached is a list of stakeholder groups that will be impacted by this project. It includes all employees, divided into payees,
corporate management, legal, procurement, and payroll administrators. It also includes outside representatives of gov
ernment taxing authorities, benefit providers, and suppliers of payroll-processing solutions.
Stakeholder Requirements as Known (Requirements related to both project and product scope.)
Req. Number High-Level Requirements

Rl Pay employees based on the agreed-upon rate/salary on the agreed-upon schedule.
R2 Adhere to country-specific government requirements related to tax withholding and
payment schedules.
R3 Adhere to state, province, county, or other local government requirements related to tax
withholding and payment schedules.
R4 Allow the company to provide benefits for employees as approved by the Board of Directors.
R5 Allow the company to collect benefit premium payments from employee pay as agreed to by
each employee.
R6 Keep all employee data confidential, secure, and archived as required by law in each jurisdiction.
82
FOUR Integration
High Level Product Description/Key Deliverables (What are the key product deliverables that are wanted and what will be the
end result of the project?)
The result of this project should be one or more systems that support payroll processing for all employees, at or below the
industry average cost. Specific desired features include:
• The systems should allow direct deposit of employee pay into any financial institution in the world, along with
notification of deposit via email or text message to any device.
• Workers should be able to change their address, number of dependents, tax withholding parameters, and benefit
characteristics via a website at any time from any location.
• The systems must support consolidated management and reporting of corporate payroll processing, plus government
mandated reporting and payments.
High-Level Assumptions (What is believed to be true or reliable in the situation? What do we believe to be the case but do not
have proof or data for? See details in the assumption log.)
• There are payroll applications available that support the countries in which our employees are located.
• The average cost of $ 100 per employee per year is accurate for our industry.
• Each employee reports their primary residence in just one country for tax reporting purposes.
• We have internal resources available to evaluate and do the work assigned.
High-Level Constraints (What factors may limit our ability to deliver? What boundaries or parameters will the project have to
function within?)
• The system must be able to comply with all international payroll rules and perform direct deposits globally.
• The solution and the supporting systems must be able to maintain organizational information security standards
that meet or exceed individual country standards.
• Year-end tax reporting must be completed by the new system in the year of the implementation (payroll data must
be converted).
• Summary milestone schedule: Due no later than October 6,20XX
• Preapproved financial resources: $1,200,000
Measurable Project Objectives (How does the project tie into the organization’s strategic goals? What project objectives
support those goals? The objectives need to be measurable and will depend on the defined priority of the project constraints.)
The main objective of this project is to decrease costs by at least $400,000 annually. A second objective, which supports
the first, is to increase productivity for new employees and payroll processing employees.
• Decrease payroll processing costs by 15 percent in two years by decreasing manual clerical processes.
• Decrease the duration of the new worker onboarding process from an average of 5 business days to 2 business days
within 18 months.
Project Approval Requirements (What items need to be approved for the project, and who will have sign-off authority? What
designates success?)
Approvals for this project include:
• Decision to purchase application software to support the payroll systems (VP of Operations)
• Choice of seller application package (Director of HR)
• High-level design of the new systems (Director of HR)
• Global transition plan for new systems rollout (VP of Operations)
Overall Project Risks (Overall potential threats and opportunities for the project)
• Because of the complexity of employee pay calculations and the large number of employees, we may have errors in
employee payroll during implementation of the new systems. (High impact)
• Because of the number of localities supported and differing regulations, we may have errors in government tax
payments and regulatory compliance during implementation of the new systems. (High impact)
• Because of the volatility in the software application marketplace, we may select an unreliable seller for delivery of
the payroll-processing applications. (High impact)
81
Integration FOUR
Project Exit Criteria (What needs must be met so that the project manager will be able to close or terminate the project or
phase?)
• A new payroll processing system that meets the project objectives and requirements and incorporates all key
deliverables described herein will be delivered within defined cost and budget constraints.
• Or, if it is determined that the project objectives of cost saving cannot be met, the project manager will recommend
termination of the project.
• Or, if it is determined that another solution will better meet the organizational needs, the sponsor should be notified
for closing approval, and a business case will be developed for the new solution.
Project Sponsors Authorizing This Project
Muhammad Chauhan, Executive Vice President Jessica Bouchard, Director of Human Resources
Develop Project Management Plan

The project management plan describes the project’s development approach Process Groups Model
and life cycle, and how the project will be executed and controlled. It identifies PG: Planning
when project management reviews will be needed and contains the perfor Process: Develop Project Management Plan
mance measurement baseline (scope, schedule, and cost baselines). It contains
and integrates plans for managing the following categories: ECO
• Scope • Resources Domain II

Task 1 Efficiently deliver business value
• Requirements • Communications Task 9 Integrate project planning activities
• Schedule • Risk Task 10 Manage project changes
• Cost • Procurement Task 12 Manage project artifacts
Task 13 Use right methods & practices
• Quality • Stakeholder engagement
Task 16 Ensure knowledge transfer
Task 17 Plan & manage project/phase closure
Let’s discuss then, what is a management plan.
or transitions
Management Plans PMBOKS Guide

Management plans document the strategy and approach for managing the Domain 2.4 Planning
project and the processes, related project constraints, and other major areas Domain 2.8 Uncertainty
needing management and integration, like communications and stakeholder
engagement. Plans include processes, procedures, practices, and standards the team will follow to ensure consistent results.
When creating a management plan, ask yourself, “How will I define, plan, manage (execute), and control scope (or
schedule, cost, quality, etc.) for the project?” “How will closing phases be performed, if that’s part of the overall project?”
You think ahead, and document how you will plan and manage for each project management category based on its
particular needs.
Planning Components
Management plans must be tailored to each project, including the format and level of detail needed at each stage of
planning. If you don’t create management plans for your projects, this area of the exam may be difficult for you. Let’s
consider an example of how you would address cost management.
Example Let’s say you are planning for the cost on a project. You need to address questions such as:
• How will you ensure all costs are identified • What estimating methods will you employ?
and estimated? • What level of accuracy is appropriate ?
• Who will be involved in estimating costs? • How will funding and cost constraints be considered
• What cost estimating methods will you use? when establishing the budget?
• What historical records, processes, and • What data, metrics, and measurements do you need
organizational requirements will need to be used for planning cost?
or met? 84
FOUR Integration
Agile and hybrid environments may not have these plans documented as separate artifacts. However, this
does not mean the planning of these attributes is absent. Rather, they are incorporated into other artifacts. For
example, scope, schedule, and risk management plans are often incorporated into a product backlog and
release roadmaps. These artifacts show the plan for project work, inclusive of risk response decisions and
when product increments are planned for delivery.
Executing Components
The executing portion of a management plan focuses on the processes and procedures for doing the work. Some
management categories, such as cost management, won’t have separate executing processes for the project manager. This
is a function of integration management.
Example The executing component of a cost management plan answers questions such as:
• What cost data are needed?
• Who is responsible for gathering the data?
• Where will the raw data be captured that will later be used in monitoring and controlling?
Monitoring and Controlling Components

The monitoring and controlling components of a management plan define the processes and procedures to measure
project progress, compare actual project results to what was planned, and determine how to handle variances that require
a change.
Before you read further, spend some time imagining what management plans for the different categories (scope,
schedule, quality, resources, communications, risk, procurement, and stakeholder engagement) might contain. Many
project managers don’t realize how big their knowledge gap is regarding management plans until it finds them on the exam.
Don’t let this happen to you!
Here is a trick to understanding management plans for the exam. Know that management plans look forward
TRICKS in time and that there are management plans for all the project management categories. There are also these
OF THE
TRADE* management plans:
• Change management plan
• Configuration management plan
• Requirements management plan
When you are taking the exam, assume the project manager has created each of these management plans. If a question
refers to a problem on a project, the answer might be for the project manager to look at the management plan for that
aspect of the project to see how the plan says to handle such a problem. For example, when the work is being done, the
project manager might refer to the cost management plan to see how costs are to be measured and evaluated.
The Project Management Plan

The project management plan integrates all the individual management plans into a cohesive whole, creating a centralized
artifact to describe what is involved in the project. The overall project management plan also includes the baselines for the
project. This means a project management plan is a set of plans and baselines (not just a schedule). The key components of
the project management plan are discussed in the following sections. Remember the agile and hybrid differences we
discussed in the previous section, and think through how an adaptive approach may tailor any of the following plans and
project management components.
85
Integration FOUR
Project Life Cycle

The project life cycle describes the phases of work on a project required to produce the deliverables (for example,
requirements, design, code, test, implement). Project life cycles range from plan-driven to change-driven.
Development Approach
Development approaches to produce the project deliverables range from plan-driven to change-driven.
Management Reviews
Milestones will be built into the project management plan, indicating times when management and stakeholders will
compare project progress to what was planned and identify needed changes to any of the management plans.
Tailoring
Think about the science of project management for a moment. Would you want to use everything in the Process Groups
model to the same extent on every project? No. A project manager should determine what processes and the extent to
which processes are to be used, based on the needs of the project. Tailoring the processes and the project work is part of
developing the project management plan.
Although we don’t always use the word “tailoring” or call tailoring out in separate sections, we talk about tailoring
throughout this book. Be aware as you are reading: Everything you do as a project manager is a creative use of the knowledge
and skills you have and the methods available to you. This, in essence, is tailoring.
Individual Management Plans

These are the management plans for scope, schedule, cost, quality, resources, communications, risk, procurement, and
stakeholder engagement. (The individual management plans are discussed in the Process domain chapters of this book.)
The Performance Measurement Baseline

The project management plan includes scope, schedule, and cost baselines, against which the project manager will analyze
and report project performance, Created during planning, these baselines are collectively referred to as the performance
measurement baseline. The following are the elements included in each baseline:
• Scope baseline The project scope statement, work breakdown structure (WBS), and WBS dictionary
• Schedule baseline The agreed-upon schedule, including the start and stop dates for each activity, and
scheduled milestones
• Cost baseline The time-phased cost budget (the spending plan indicating how much money is approved for the
project and when the funds are required and will be available)
The project manager and team will watch for deviations from the baselines while the work is being done. If a deviation
is discovered, they will assess whether adjustments can be made to bring the project back in line with the baseline. These
adjustments might involve submitting a change request for corrective or preventive action or defect repair.
If minor adjustments will not correct a deviation, a request to change the baselines might be necessary. A substantial
part of managing a project beyond planning is making sure the baselines are achieved, which in turn helps ensure the
sponsor and the organization get the complete benefits of the project they chartered. Therefore, as a project manager, your
ability to not only plan a project but also to control the project and get it completed as planned is very important.
On plan-driven projects, requested changes to the baselines are evaluated and approved in the Perform Integrated
Change Control process, discussed later in this chapter. Baseline changes are serious and the evolution of the baselines
should be documented to show when and why changes were made. Baselines are mentioned frequently on the exam. Make
sure you understand the concepts described here, including what the project manager s approach should be to the projects
baselines and any changes to those baselines.
Deviations from baselines are often due to incomplete risk management. Therefore, if the exam asks what to
TRICKS do when a project deviates significantly from established baselines, consider that the correct answer may be
OF THE
TRADE the one about reviewing the projects risk management process. Many project managers are not aware of this.
86
Integration
Requirements Management Plan

Part of the scope management process (described in the “Scope” chapter) involves defining and planning for stakeholders’
needs, wants, expectations, and assumptions to determine the requirements for the project. The requirements management
plan defines how requirements will be gathered, analyzed, prioritized, evaluated, and documented, as well as how the
requirements will be managed and controlled throughout the project.
Change Management Plan

Controlling a project to the baselines and the rest of the project management plan is so important that the project manager
needs to think in advance about where there might be changes and what to do to limit the negative effects of changes. Are
you this focused on change management on your projects? In a plan-driven environment, the project manager needs to
plan to minimize changes and prevent unnecessary changes. They also need to proactively look for needed changes, thereby
solving issues before they have a major negative impact on the project.
The change management plan describes how changes will be managed and controlled, and may include:
• An outline of how changes will be managed and controlled
• Change control procedures (how and who)
• Approval levels for authorizing changes
• The creation of a change control board (described later in this chapter) to approve changes, as well as the roles and
responsibilities of those on the board
• Who should attend meetings regarding changes
• The organizational tools to use to track and control changes
• Information on reporting the outcome of change requests
• The emergency change process
In agile environments the team expects change, which is why this type of project planning is described as
adaptive. Project and product requirements, including risk management activities, are prioritized in the
backlog in order to maximize the team’s ability to deliver value through incremental delivery of product
features while maintaining an established schedule and budget.
Configuration Management Plan

The configuration management plan defines artifact naming conventions, a version control system, and document storage
and retrieval processes and locations. This plan details how the project manager will manage changes to the documentation,
including which organizational toolswill be used in this effort. Configuration management is essential to ensure all relevant
stakeholders are aware of and have access to the latest versions of the project management plan components.
Putting the Project Management Plan Together

The project manager and the team create the project management plan by completing the activities described in the
Planning column of Rita’s Process Chart™. Once the project management plan is complete, the sponsor or key stakeholders
review and approve it
The Develop Project Management Plan process must result in a plan that is bought into, approved, realistic, and
formal. In other words, the project management plan needs to be agreed to by the key stakeholders involved in the project,
it needs to be formally approved, everyone needs to believe the project can be done according to the plan, and it needs to
remain a formal artifact that is revised and used throughout the project. If this is a new concept to you, make sure you
spend time thinking about how to accomplish this in the real world.
On an agile or hybrid project initial plans will be deliberately light and progressively elaborated. Planning
takes the form of release and iteration planning and early iterations of product building provide clarification
and additional information. Agile methods also encourage shifting planning responsibilities to the team, with
scope prioritization by a product owner. The product owner is part of the team and they will, along with the
project manager, help ensure that the project plan is viable via the prioritization of the backlog and through a timephased
product roadmap. Plans and processes may be less formal than those for a plan-based project but they are made and
controlled with as much rigor.
87
Integration
Through initiating and planning, let’s see how everything connects so far by looking at figure 4.3.
A need is identified: “What do I want?”
Sponsor/
customer/
product
owner
FIGURE 4.3 Project initiating and planning
Once the project management plan has been completed, the project manager uses it as a tool to help
manage the project on a daily basis. Although it may evolve over the life of the project through progressive
elaboration or approved changes, the project management plan in a predictive environment is designed to be
as complete as possible when project executing begins. In adaptive environments the frequency of progressive
elaboration related to planning and requirements elicitation is more frequent.
4.2 Exercise
Test yourself! In your Exercise Notebook, make a list of the specific actions required to create a project management
plan that is bought into, approved, realistic, and formal.
Answer
Some possible answers include:
• Select the best life cycle and development approach for the project
• Agree on processes to report, control, incorporate, and communicate changes
• Analyze the stakeholders’ needs, wants, expectations, and assumptions
• Capture the project requirements as completely as possible
• Work with team members to estimate the project
• Give team members a chance to approve the final schedule that converts the team’s activity estimates into
a calendar schedule
• Get resource managers to approve the schedule and confirm when their resources will be used
• Work through iterations of the plan (for example, update the work breakdown structure after completing
risk analysis)
• Create the necessary supporting project documents (for example, the stakeholder register).
• Apply risk reserves to the project schedule and budget
• Let the sponsor know if any of the project requirements that were outlined in the project charter cannot
be met
88
FOUR Integration
• Perform schedule compression (crash, fast track, change scope or quality, etc.), and present options to
the sponsor
• Look for impacts on the project from other projects
• Make sure the approach and processes are consistent with the PMO and/or program management plan if
the project is part of a program
If you included most of the answers from the exercise, you are in good shape. But why is it so important to have a
project management plan that is realistic and that everyone believes can be done? Because while the work is being
done, progress against the plan is measured to see how the project is going. The constraints agreed to as the project
management plan is approved must be met.
So when you think of the project management plan, think of all the facilitations, meetings, sign-offs, interactions with
other projects, conflict resolution, negotiations, schedule compressions, etc.—everything required to bring the plan to the
point of being bought into, approved, realistic, and formal.
Project Documents
The term “project documents” refers to any project-related documents that are not part of the project management plan.
They include artifacts like the following (although not an exhaustive list):
• Project charter • Schedule and • Agreements
• Assumption log resource calendars • Contracts
• Issue log * Reports (quality, risk, etc.) • Statements of work
• Estimates • Resource requirements • Risk register
• Lessons learned register * Requirements documentation • Forecasts
• Team charter * Change log • Quality metrics
While the sponsor and/or key stakeholders will see and approve the project management plan, most project
documents (excluding the project charter, agreements, contracts, and statements of work) are created and used by the
project manager and team and do not require sponsor approval.
Due to the iterative nature of planning and the nature of the work throughout the rest of the project, project artifacts
are updated frequently. Though this book will not cover these updates as an output of every process, know for the exam
that project documents updates are an output of many project management activities.
Example Midway through the project the project manager and team agree that a particular risk that has not occurred
is no longer likely to occur. The risk register and other risk artifacts are updated and the funds in the contingency reserve
for that risk are theoretically no longer available to the project.
Project Management Plan Approval

Since the project management plan is a formal document, it requires formal approval by management, the sponsor, the
project team, and other key stakeholders. Formal approval means sign-off (signatures). If the project manager has identified
all stakeholders and their requirements and objectives, included the appropriate project and product scope in the plan, and
dealt with conflicting priorities in advance, getting the project management plan approved should be relatively
straightforward.
Kickoff Meeting
Before the Develop Project Management Plan process is considered complete and project executing begins, a kickoff
meeting should be held. This is a meeting of the key parties involved in the project to announce the start of the project, to
ensure everyone is familiar with its details—including objectives and roles and responsibilities—and to ensure a
commitment to the project from everyone. In addition to introducing those involved in the project, the meeting may
review such items as milestones, risks, the communications management plan, and the meeting schedule.
While kickoff meetings are common on agile projects, the project information exchanged at this meeting
remains high-level. Detailed information about product features and product increments emerge as release
and iteration planning continues, followed by iteration reviews with the customer and/or management
representatives in iteration review meetings. 89
Integration FOUR
Direct and Manage Project Work

This process represents the integration aspect of project executing—the part of the Process Groups Model
project where the team does the work to build the product of the project. In Direct PG: Executing
and Manage Project Work, the project manager integrates all the executing work Process: Direct and Manage Project Work
into one coordinated effort to accomplish the project management plan and pro
duce the deliverables. In addition, Direct and Manage Project Work involves gath ECO
ering work performance data, creating and using the issue log, requesting changes, Domain II
and completing work resulting from approved change requests. Task 1 Efficiently deliver business value
Task 10 Manage project changes
These tasks involve managing the work and keeping people engaged.
Task 12 Manage project artifacts
Ultimately, it’s about being of service to the team to help them get the work
completed, ensuring a common understanding of the project among stakeholders, Task 17 Plan & manage project/phase
and keeping everyone informed by documenting and facilitating issue resolution. closure or transitions
The project manager also facilitates meetings and technical discussions, and on
plan-driven projects uses a work authorization system (part of the project PMBOK® Guide
management information system or PMIS) to keep the team and functional Domain 2.5 Project Work
managers informed of upcoming work assignments and milestones. The project Domain 2.6 Delivery
manager also removes impediments for the team, works on process improvement, Domain 2.8 Uncertainty
and informs other departments within the organization how the project may affect
their work.
Integration management requires project managers to keep all constraints in mind at all times and to properly look at
how issues relating to one constraint affect others. For example, scope management issues can affect quality metrics and
resource management.
If you have never used a work authorization system, imagine a large construction project with hundreds of
TRICKS people working on the project. Can you have a plumber and an electrician show up to work in one small area
OF THE
TRADE. at the same time? No. Remember that a project is planned to the level of detail needed for that project. To
handle these types of situations, a work authorization system makes sure work is only started when a formal
authorization is given. In many cases, this tool is a company-wide system and not created just for the project. The term
“work authorization system” could appear in a question on the exam or be included as an answer choice.
Depending on the needs of the project and its development approach, the use of meetings as a method can range from
informal standup sessions to structured meetings with an agenda that focuses on a specific aspect of the project. Other
meetings may be related to project updates, lessons learned, upcoming project activities (like an iteration planning
meeting), and risk management or change control.
The Direct and Manage Project Work process can be illustrated as shown in figure 4.4. The primary outputs of this
process include completed deliverables along with any new work performance data and change requests. Other outputs are
updates to organizational process assets and project artifacts.
Figure 4.4 Direct and Manage Project Work process

90
Integration
4.3 Exercise
What are some of the most likely project artifacts to be updated as an outcome of the Direct and Manage Project
Work process? Write the answer in your Exercise Notebook.
Answer
Project artifacts that may be updated as a part of this process include the following:
• Project management plan
• Requirements documentation
• Activity list
• Assumption and issue logs
• Lessons learned, stakeholder, and risk registers
Keep in mind as you read the rest of this book, that for every process there are project artifacts that are likely
TRICKS
OF THE to be updated as the project progresses.
TRADE®
Manage Project Knowledge

Think of the tremendous amount of knowledge required to properly plan and exe Process Groups Model
cute a project. Project managers can benefit from the knowledge base the organiza
PG: Executing
tion has accumulated over time, particularly from the experiences and discoveries Process: Manage Project Knowledge
of others on past, similar projects. The Manage Project Knowledge process requires
each project to actively contribute to that knowledge base. This includes sharing ECO
new processes, successes, etc., internally within the project, as well as making that Domain II
knowledge accessible throughout the entire organization. Task 10 Manage project changes
Information and Knowledge Management Task 17 Plan & manage project/phase
Successful and consistent knowledge and information sharing contributes to a closure or transitions
productive work environment and increases the ability of project teams to achieve
project and organizational objectives. Successful knowledge management requires PMBOK® Guide
an organizational culture of trust in which the project manager and stakeholders Domain 2.8 Uncertainty
exchange knowledge without fear of judgment. The project manager needs to
foster an environment that will support collaboration and knowledge sharing. As an example, discussion forums and other
interactive online tools may help to facilitate this type of environment.
New knowledge that is important to share often involves experiences that did not work out as planned. The project
manager can learn from each unidentified stakeholder, each missed risk trigger, and each unrealistic schedule component.
Sharing such information and possibly saving another project or person from a similar issue is invaluable. This philosophy
has evolved in the traditional project management world and was built into agile project management practices since
people started using agile.
Knowledge management includes two distinct types of knowledge—explicit and tacit.
• Explicit knowledge is fact-based and can be easily communicated through words and symbols. Traditional lessons
learned, processes and procedures, and other information repositories fall under this knowledge type. These are
generated and shared as the project is ongoing and consolidated as part of project closing. Explicit knowledge,
however, may need explanation or context to provide value.
• Tacit knowledge may provide context or explanation to explicit knowledge. It is not easily documented. It includes
emotions, experience, and ability, which are difficult to communicate in words and symbols but can be learned
through job shadowing or apprenticeship.
Integration FOUR
Example You can learn a lot about performing an activity by reading the organizations documentation on it and
being trained by an experienced employee. This is explicit knowledge. However, you will learn tricks and shortcuts by job
shadowing. Watching an experienced person doing the job will give you tacit knowledge they may not think to tell you if
they were to train you on the activity.
On the exam, you may see questions related to establishing an environment that encourages the project team to share
tacit and explicit knowledge. Or a scenario-based question may have an implicit assumption that knowledge sharing is part
of executing a project.
You should also be aware that legal and regulatory requirements and constraints such as nondisclosure agreements
may limit or impact the gathering and sharing of particular information.
Example On a project to develop banking software, the team may have access to personal and financial information
about customers of the bank for which the software is being developed. Team members would obviously not be permitted
to share this information other than for project work.
Managing Project Knowledge

Project artifacts such as the project management plan, project documents (like the lessons learned register and project
team assignments), and deliverables are inputs to the Manage Project Knowledge process. Techniques for learning and
sharing knowledge may include workshops, training, and observation. Simply asking, “Walk me through how you would
do this task,” can encourage understanding.
Osmotic Communication Informal sharing occurs through the application of interpersonal and team skills,
including active listening and networking. The agile concept of osmotic communication describes the
phenomena of communication and knowledge sharing being facilitated and enhanced simply by team
members being in proximity to one another.
Example Imagine you work in a cubicle and on the other side of that cubicle works a close colleague. You also have
a colleague with whom you work closely, but their desk is down the hall. Would you agree that even without trying you
would know more about the colleague who works right on the other side of your cubicle, just from overhearing their daily
conversation? That is osmotic communication.
Lessons Learned
You will see lessons learned mentioned throughout this book, both as an input to and an output of many processes. As an
input, they help improve the current project. As an output, they help make the organization better by providing historical
lessons learned for future projects and project managers. They describe “what was done right, what was done wrong, and
what would be done differently.” Accurately and thoroughly documenting lessons learned is a professional responsibility,
and the lessons learned register is a main output of managing project knowledge. Lessons learned should include an
overview of each situation, what corrective actions were taken, the impacts of actions taken, and the resulting updates to
project artifacts.
In the first chapter of this book, we described lessons learned under General PMI-isms. Lessons learned are an
essential asset to managing a project, as they are taken into account as well as created throughout a project.
Some useful lessons learned categories that should be captured are:
Technical Lessons Learned What was right and wrong about how we completed the work? What did we learn that will
be useful in the future? (Examples include acceptable metrics and variance levels, new processes, improved or revised
processes for particular results, and the effectiveness of particular acceptance criteria.)
Project Management Lessons Learned How did we do with work breakdown structure (WBS) creation, risk planning,
etc.? What did we learn that will be useful in the future? (Examples include recommendations for transitioning project
results to the business and operations teams, recommended changes to the organizations procurements process, and
experiences working with particular sellers.)
Management Lessons Learned What did we learn from communications and leadership efforts that will be useful in the
future? (Examples include the results of stakeholder analysis and stakeholder engagement efforts.)
92
FOUR Integration
Figure 4.5 Lessons learned on a project
Monitor and Control Project Work

Monitor and Control Project Work proceeds from project initiating through clos Process Groups Model
ing. It involves observing project activities and their results, and comparing the ac PG: Monitoring and Controlling
tual and forecasted performance to what was planned. This process involves aggre Process: Monitor and Control Project Work
gating the work performance information from the project management processes
to evaluate and assess how their results are impacting plans and baselines. This pro ECO
cess involves monitoring any performance requirements that were included in the Domain II
project management plan. Task 1 Efficiently deliver business value

Example Scope may be completed but quality may not be acceptable. The
Task 13 Use right methods & practices
schedule might be met but at excessive cost. Task 17 Plan & manage project/phase
This work encourages a holistic view of project performance and enables the closure or transitions
project manager to take appropriate action to keep the project on track. It also
PMBOK* Guide
includes activities such as analyzing and tracking risks, performing quality control
Domain 2.7 Measurement
activities, assessing possible outcomes across the project using data analysis
techniques (including alternatives, cost-benefit, earned value, root cause, trend, Domain 2.8 Uncertainty
and variance analysis), and reviewing changes and corrective actions made on the
project to see if they were effective.
Artifacts of Monitor and Control Project Work

Ihis effort may result in change requests, work performance reports, and updates to project artifacts. The change requests
from this and other processes are evaluated and approved, rejected, or deferred in the Perform Integrated Change Control
process, described later in this chapter.
Change Requests
Change requests can have differing focuses, depending on which process they are generated from. Examples of changes are
additions to project scope requested by the customer, changes to the plan that the team believes would make their work
more efficient, or even changes to the policies and procedures used on the project. Needed changes are identified as the
project manager manages the execution of the project and as part of monitoring and controlling when project performance
is measured against the baseline.
Not all changes require change requests, but change requests are generated from many processes if they require a
change to the project management plan or the performance measurement baseline. The three main categories into which
changes fall are corrective action, preventive action, and defect repair.
95
Integration FOUR
Corrective Action
Any action taken to bring expected future project performance in line with the project management plan is a corrective
action. Since corrective actions deal with actual deviations, there needs to be a realistic performance measurement baseline
and/or project management plan, including acceptable variances, to determine when a variance has occurred and when
corrective action is needed. Those who have problems with this in the real world have problems on the exam.
What do you do on your projects? Do you have predetermined areas to measure, and have you identified an acceptable
range into which the measurements can fall (control limits) to determine if a project is on schedule and on budget?
You need to:
• Have a realistic project management plan to measure against
• Have metrics created during project planning that cover all aspects of the project
• Consciously focus on identifying areas that need corrective action
• Look for problems using observation, active listening, and measurement rather than waiting for them to be brought
to your attention
• Know when the project is off track and requires corrective action
• Find the root causes of variances
• Measure project performance after a corrective action is implemented to evaluate the effectiveness of the
corrective action
• Determine whether there is a need to recommend further corrective action
• Continue to measure throughout the project
As you can see, a significant portion of the project manager s time while the project work is being done is spent
TRICKS measuring performance and implementing corrective actions as needed. You can expect questions about this
OF THE
TRADE on the exam. Do not expect all these questions to use the words “corrective action.”
Preventive Action
While taking corrective action involves dealing with actual deviations from the performance measurement baseline or
other metrics, preventive action means dealing with anticipated deviations from the baseline and other metrics. Knowing
when preventive action is needed requires more experience than calculation because the project manager is evaluating
trends in the measurement analysis and anticipating that, if they continue, they could lead to deviation from the baseline
or other metrics. Examples of preventive actions include:
• Adjusting the project to prevent the same problem from occurring again later in the project
• Changing a resource because the resource s last activity nearly failed to meet its acceptance criteria
• Arranging for team members to take training in a certain area because there is no one with the necessary skills to back
up a team member who may unexpectedly get sick
Proposed changes that would affect the baselines, policies or procedures, charter, contracts, or statements of work
would likely have to go to the change control board or sponsor for approval, as outlined in the change management plan.
Defect Repair
Defect repair is another way of saying “rework.” Defect repair may be necessary when a component of the project does not
meet requirements. As with corrective and preventive actions, defect repair may be reviewed and approved or rejected as
part of Perform Integrated Change Control.
FOUR Integration
Perform Integrated Change Control

In the previous section we discussed three main categories of changes request Process Groups Model
ed on a project. On plan-driven projects, change requests are evaluated and PG: Monitoring and Controlling
accepted, rejected, or deferred in the Perform Integrated Change Control pro Process: Perform Integrated Change Control
cess. A key focus of integrated change control is to look at the impact of each
change on all the project constraints, the value of which is to reduce the poten ECO
tial risk of not meeting project objectives. For example, any scope change needs Domain II
to be assessed for its impact on quality, risk, schedule, cost, resources, and cus Task 10 Manage project changes
tomer satisfaction. It then needs approval through integrated change control
before it can be implemented, since the scope baseline is part of the perfor Task 17 Plan & manage project/phase closure
mance measurement baseline. or transitions
Integrated change control ensures that as changes are accepted, updates
and re-planning efforts are completed and project artifacts updated. The PMBOfC Guide
approved changes are implemented as a function of Direct and Manage Domain 2.7 Measurement
Domain 2.8 Uncertainty
Project Work, Control Quality, and Control Procurements.
So, do you need to go through Perform Integrated Change Control to
make changes to processes or plans that haven’t been finalized? No. When
developing the project charter, project management plan, and baseline, changes can be made without a formal change
request. But after the charter and the project management plan have been approved, requested changes need to be evaluated
in the context of integrated change control. Project document changes like those to lessons learned and the issue log do not
require change requests if they do not affect the performance measurement baseline or another project management plan
component.
Read exam questions carefully to understand whether a requested change pertains to something that is still in
the process of being finalized or has already been finalized. This will help you determine whether integrated
change control is required.
Integrated change control can be a difficult topic on the exam for people who do not work on projects that have
formal change procedures. It can also be difficult for project managers who simply estimate the cost and/or schedule
impact of a change and stop there, rather than looking for the impacts of a change on all project constraints. Check your
understanding of this topic with the following example.
Think About It. A stakeholder wants to add scope to the project. You estimate that the change will add two
weeks to the project duration. What do you do next?
Try to answer the question. Is your answer to look for ways to save time so the change can be accommodated? Or
should you get the change approved? How about asking for an extension of time to accommodate the change?
None of the previous choices are correct. The next thing to do would be to see how the proposed change impacts the
project cost, quality, risk, resources, and possibly customer satisfaction. Whenever the exam mentions change, keep in
mind that a change to one project constraint should be evaluated for impacts on all the other constraints.
Are changes bad? In plan-driven project management and in some industries this may be a controversial question.
Changes can have negative effects as they may be expensive or disrupt the project. The cost of change tends to increase as
the project progresses. The function of each process within monitoring and controlling is to control changes.
In an adaptive environment accommodating many changes is assumed to be an ongoing part of the
project management process. The definition of scope is emergent rather than defined at the beginning of the
project. But even in change-driven environments change needs to be carefully planned and managed.
A project manager should work to prevent the root cause of unnecessary changes. The need for many changes in a
predictive environment may indicate that the project manager did not fully identify stakeholders and uncover their
requirements, plan for risk, or properly complete other project management actions.
95
Integration FOUR
To control changes on a plan-driven project, the project manager should:

• Work to obtain complete and thorough requirements as soon as possible
• Continue to observe the environment for the possibility of new or missed stakeholders and new or missed
requirements
• Spend enough time on risk management to comprehensively identify the project’s risks
• Establish schedule and cost reserves (see the “Risks and Issues” chapter)
• Have a process in place to manage change
• Follow the change management process
• Have a process and templates in place for creating change requests
• Have clear roles and responsibilities for approving changes
• Allow only approved changes to be executed
• Reevaluate the business case in the project charter if the number of changes becomes excessive
• Consider terminating a project that has excessive changes and starting a new project with a more complete set
of requirements
Changes can be grouped into two broad categories—those that affect the baselines, policies and procedures, the
charter, contracts, or statements of work, and those that do not. If a change does not affect these artifacts, change
management policies may allow the project manager to approve the change. If the change does affect those key elements,
the change typically needs to go to a change control board and/or sponsor for a decision. Product owners normally make
these decisions on agile projects.
Change Control Board (CCB)

Depending on the project manager s level of authority, their role might be to facilitate decisions about certain changes,
rather than actually make the decisions. Many projects have formally established change control boards responsible for
reviewing change requests in accordance with the change management plan for the project. The CCB (sometimes referred
to as the steering committee) approves, defers, or rejects the changes. The results of the decisions are documented in the
project s change log. The board may include the project manager, the customer, experts, the sponsor, functional managers,
and others. For the exam, assume that plan-driven projects have change control boards.
Summary Process for Making Changes on Plan-driven Projects

The exam has many situational questions that deal with how to manage project changes. Here are two examples.
Question A functional manager wants to make a change to the project. What is the first thing a project manager
should do?
Question Someone wants to make a change to the project scope. What is the best thing to do first?
The answers are the same in either case. A trick for answering questions that ask about the process for making
TRICKS
OF THE changes is to know that, at a high-level, the project manager (and team) should follow these steps:
TRADE 1. Evaluate the impact Assess the impact of the change on all aspects of the project (for example, this change
will add three weeks to the project length, require $20,000 additional funding, and have no effect on
resources).
2. Identify options This can include cutting other activities, compressing the schedule by crashing or fast
tracking, or looking at other options. For example, you may be able to decrease the potential effect of the
change on the project by spending more time decreasing project risk, or by adding another resource to the
project team.
3. Get the change request approved internally (through the CCB)
4. Get customer buy-in (if required)
Note that changes are always evaluated before any other action is taken. In many cases, evaluation involves using data
analysis techniques to determine the impact of the change on all the project constraints.
96
FOUR Integration
Next, options to handle the change, such as crashing, fast tracking, re-estimating, and using “what if” analysis are
considered and evaluated. (See the “Schedule” chapter for a discussion of crashing, fast tracking, and re-estimating.)
Think About It. Do you remember the following question from earlier in the chapter? It is an example of the
type of question you may see on the exam:
A stakeholder wants to add scope to the project. You estimate that the change will add two weeks to the project duration.
What do you do next?
Notice how the following question is different:
A change in scope has been determined to have no effect on the project constraints. What is the best thing to do?
Be careful when reading these questions. Expect the right answer to depend on other details in the question.
Sometimes evaluation has been done, so the best thing to do is to look for options. Sometimes evaluation and looking for
options have been done, and the best thing to do is to meet with the sponsor or change control board to ask for approval,
deferral, or rejection of the change.
In the second question, evaluation (step 1 in the previous Trick of the Trade™) has been done. The answer would be
to look for options (step 2), and then meet with the sponsor or change control board (step 3) to discuss the change and its
lack of impact on the project constraints. After informing the sponsor or change control board, the project manager may
inform the customer using the process defined in the communications management plan (step 4).
Detailed Process for Making Changes Now that you know the high-level process, let’s look at a more
TRICKS
OF THE detailed process for making changes:
TRADE- 1. Prevent the root cause of changes The project manager should not just focus on managing changes; they
should proactively minimize the need for changes.
2. Identify the need for a change Changes can come from the project manager, as a result of measuring
against the performance measurement baseline, from the sponsor, or any other stakeholder. The project
manager should be actively looking for changes from all sources because discovering a change early will
decrease the impact of the change.
3. Evaluate the impact of the change within the project constraints If it is a scope change, how will it affect
the rest of the scope of the project? If it is a schedule change, how will it affect the rest of the schedule for
the project?
4. Create a change request Changes can be made to the product scope, any part of the project management
plan, contracts, charter, statements of work, policies and procedures, or even the performance measurement
baseline. The process of making a change should follow the change management plan.
5. Perform integrated change control How will the change affect all the other project constraints?
a. Assess the change Does the change fall within the project charter? If not, it should not be a change to
the project; it may be an entirely different project. If the change is not beneficial to the project, it should
not be approved. Also note that any change for which a reserve has been created (a previously identified
risk event) would be accounted for in the project management plan as part of risk management efforts
and should be handled as part of the Implement Risk Responses process rather than Perform Integrated
Change Control. The techniques of alternative and cost-benefit analysis are helpful in understanding the
full impact of a change request.
b. Identify options Actions to decrease threats or increase opportunities include compressing the
schedule through crashing or fast tracking, changing how the work is performed, adjusting quality, or
cutting scope so that the effect of the change will be minimized. Sometimes it may be necessary to accept
the negative consequences of a change, if the positive impact that would result from the change is more
valuable to the project. It is a matter of balancing project constraints.
Example The benefits of adding new scope to the project may outweigh any negative impact. (See the
“Schedule" chapter for a discussion of the critical path.)
97
Integration FOUR
c. Get the change approved, rejected, or deferred Again, the project manager may be able to approve
many changes. But those that affect the project management plan, baselines, charter, etc. would likely
need to go to a change control board and/or the sponsor. The approved changes are then implemented in
the Direct and Manage Project Work, Control Quality, and Control Procurements processes.
d. Update the status of the change in the change log This helps everyone know the status of the change.
If a change is not approved, the reasons it was rejected should be documented.
e. Adjust the project management plan, project documents, and baselines as necessary Some
approved changes need to be incorporated into the project baselines. The changes could affect other parts
of the project management plan or project documents or could affect the way the project manager will
manage the project. Project documentation must be updated to reflect the changes. This means replanning
must be done to incorporate the impacts of the change into the new version of the documents and plan
before the team starts executing the change. For example, if there is a change in scope, the scope baseline
(the WBS, WBS dictionary, and project scope statement), the project management plan, and the
requirements traceability matrix should be updated. If that change in scope affects other areas of the
project, the associated documentation (such as the activity list, resource management plan and other
resource documentation, schedule, budget, or risk register) also needs to be updated.
6. Manage stakeholders’ expectations by communicating the change to stakeholders affected by the
change How often do you remember to do this? You could think of this, in part, as configuration
management (version control to make sure everyone is working off the same project documentation).
7. Manage the project to the revised project management plan and other project artifacts
Agile Change Management

In agile and hybrid environments, change control is streamlined as there are often many changes to evaluate
and make decisions about every day. The product owner is part of the team and has much change approval
authority. They will authorize changes that would not significantly alter the outcome or benefits of the project.
Note that there are some additional guidelines in relation to agile change management. For example, the
product owner is typically given a description of business benefits to deliver within a firm budget and timeline. Changes
that would impact the intended benefits or require more time or budget than tolerances allow still need to be escalated
outside the project to a steering committee or sponsors for approval. However, everyday decisions and minor changes that
come with building something new or complex are managed within the team.
4.4 Exercise
Test yourself! In your Exercise Notebook, list some common changes on projects and what you would do to
manage each change.
Answer
Because of the wide variety of possible changes that may occur throughout the life of a project, this exercise only
includes one answer, but it will help you prepare for questions related to change on the exam.
Common Change How to Handle It

Customer wants to Make sure you know what the specific scope is and why it is necessary. Make sure all the
add scope data required in the change request is filled out. Assess the change, including whether risk
reserves were allocated to accommodate the addition of the scope. Evaluate the impact of
the change on all constraints. Look for options. Have the change reviewed by the change
control board if necessary.
98
FOUR Integration
Close Project or Phase

In the ECO, domain II, this is known as task 17: “Plan and Manage Process Groups Model
Project/Phase Closure or Transitions.” This process finalizes all ac PG: Closing
tivities across tasks and processes to formally close the project, Process: Close Project or Phase
phase, and transition of the product to the customer or operations.
Plan-driven projects generally have transitions between phases and then a tran ECO
sition at the end, while change-driven projects are organized around more fre Domain II
quently occurring iteration cycles according to a product release plan. In either Task 12 Manage project artifacts
case, similar activities need to be completed to close a project once its phases
Task 17 Plan & manage project/phase closure
or iterations have been completed. This is an area that is often overlooked or
or transitions
done incompletely so think about this section carefully.
The project manager will work with subject matter experts to analyze the PMBOK® Guide
data, including all the project artifacts, and complete the final work to close the Domain 2.5 Project Work
project. Regression analysis will be done to examine the project variables— Domain 2.6 Delivery
such as the schedule, budget, and risks that occurred—and how they impacted
the project and its outcomes. The project manager will look at planned versus actual project results, identify variances to
the plan, along with their impacts, and identify additional lessons learned that can be shared or used in the organization.
A project manager must get formal acceptance of the project and its deliverables, issue a final report that shows the
project has been successful, issue the final lessons learned, and index and archive all the project records. Do you understand
the importance of the items in the Closing column included in Ritas Process Chart™? Make sure you are familiar with the
concepts and actions listed here, and, if you do not currently do these things on your projects, imagine completing these
activities in the real world. For the exam, be sure to remember that you always close out a project, no matter the circumstances
under which it stops, is terminated, or is completed!
Is your project really done when the technical work is done? Not if you don’t close it out! The Close Project or
TRICKS Phase process encompasses the actions of closing as outlined in the project management plan. You must
OF THE
TRADE- ensure final requirements have been fulfilled and all product acceptance work is done. This much you could
have guessed. But there is often work overlooked that is part of the project work, or is known to be project
work but gets lost in the rush to the next project assigned by the organization.
Example Outstanding financial work should be facilitated with the organizations finance department (including
ensuring proper procurement closures). The product is handed off to the customer and customer feedback is solicited.
Often there is facilitation needed for the customer or operations like training and supervision to ensure operations are
running as intended. Was this part of the project management plan or is it a separate project? In either case, transitions
like this are often haphazard at best, but PMI assumes they are well planned as part of the project.
Finally, appropriate indexing and archiving of records occurs, including final lessons learned. This is another transition
step that often gets lost at the end of a project but PMI assumes is done properly and completely.
For the exam, do not forget that there are financial, legal, and administrative efforts involved in closing. Let’s look
again at the activities presented in Rita’s Process Chart”:
• Confirm work is done to requirements
• Complete final procurement closure
• Gain final acceptance of the product
• Complete financial closure
• Hand off completed product
• Solicit customer’s feedback about the project
• Complete final performance reporting
• Index and archive records
• Gather final lessons learned, and update the knowledge base
Integration FOUR
Note that the Close Project or Phase process involves getting the final, formal acceptance of the project or phase as a
whole from the customer, whereas Validate Scope (a monitoring and controlling process) involves getting formal
acceptance from the customer for interim deliverables. The project needs both processes.
Does it make sense to you that the Close Project or Phase process is an integration management function? If not,
think of the example of final performance reporting. Can you see how you would have to report on all project constraints?
Make sure you are comfortable with project closing and how it applies to proper project management before you take
the exam.
A Word on Transitions
Sometimes transitions to the customer or operations, of products or services built during your project, are included in the
project as a phase or product increment. But if transition needs are numerous and complex, transitions are a separate
project in a program. In either case, transitions require that the project manager has a sophisticated understanding of the
business environment in which the project is taking place. More information on this topic is discussed in the Business
Environment section of this book.
A Case Study You Can Use

Throughout this book we provide numerous examples and analogies to help you think about the material being presented.
Since your real-world experience is necessary to qualify for and pass the exam, and yet PMI’s framework processes and
vocabulary do not always align with your experience, a variety of examples and analogies will help stimulate you to “imag
ine into reality” what you need to know for the exam. We chose one case study for repeated use throughout this book to
help you with a consistent application of the concepts discussed.

Integration management occurs throughout the project. The project manager is constantly pulling all the pieces of the
project together into a cohesive whole. It is during this process that the project charter and project management plan are
developed. These two artifacts will guide the project manager s work. The project manager works to manage project chang
es and artifacts. During project integration, they also determine which methodologies and practices work best for the proj
ect; in other words, they are tailoring to meet the needs of the project. Finally, they ensure that the project or phase is closed
out properly.
Do you remember everything involved with project integration? Revisit the Quicktest at the beginning of this chapter
and make sure you have filled all the gaps you identified when you began the chapter. Go through the chapter again to
review the areas you are still unsure about.
Here is the case study that will be presented throughout this book. In each chapter you will learn more about this
project and answer questions to reinforce your learning. Read the overview here and then complete the following exercise.
Introducing the Library Case Study

A project manager has been hired to oversee the creation of a new community library. The scope of the project includes
construction of a new building, acquisition of furnishings, movement of resources from the old library, and upgrade of a
software application for patrons using the library.
100
Integration
4.5 Exercise
Review each description of work done by the project manager as part of Integration Management. In your Exercise
Notebook, write down the integration process and the other project management constraints and categories
(scope, schedule, cost, quality, communications, risk, stakeholders, and procurement) involved.
Integration Constraints; other project

Work of the PM Process(s) management areas involved
1. Prepared a report for the city council including actual
spending vs. planned budget, actual schedule vs. plan,
and risks identified since last monthly report.
2. Met with the team to discuss estimates for work packages,
to talk about vacation schedules, and decide on the best
communication methods for the team to use.
3. After the foundation of the building was complete, the
project manager held a team meeting to discuss what
went well, any quality issues that occurred during the
work and how those issues were resolved. They also
talked about any changes to the original design that
might be needed going forward.
4. Building foundation adjustments will require a change to
the architect’s design. These changes require more time
and cost, these must be approved by the CCB.
5. The project manager reviews the project every Friday.
They review the risk register and work performance data
comparing it to the planned schedule and budget. They
also read the local paper and read and respond to
communications from the city council members, mayor,
and head librarian.
6. During the grand opening of the library, patrons are
asked to complete a survey about their thoughts about
the new facility.
7. The project manager interviews the mayor to understand
the community objectives of the new library and the
key stakeholders.
Integration FOUR
Answer
Integration Constraints; other project
Work of the PM Process(s) management areas involved
1. Prepared a report for the city council including actual Direct and • Cost
spending vs. planned budget, actual schedule vs. plan, Manage • Schedule
and risks identified since last monthly report. Project Work • Risk
• Stakeholders
• Communication
2. Met with the team to discuss estimates for work packages, Develop • Communication
to talk about vacation schedules, and decide on the best Project • Resources
communication methods for the team to use. Management • Schedule
Plan
3. After the foundation of the building was complete, the Manage • Scope (design)
project manager held a team meeting to discuss what Project • Quality
went well, any quality issues that occurred during the Knowledge
work and how those issues were resolved. They also
talked about any changes to the original design that
might be needed going forward.
4. Building foundation adjustments will require a change to Perform • Scope
the architect’s design. These changes require more time Integrated • Schedule
and cost, these must be approved by the CCB. Change • Cost
Control
5. The project manager reviews the project every Friday. Monitor and • Risk
They review the risk register and work performance data Control • Stakeholder
comparing it to the planned schedule and budget. They Project Work • Communications
also read the local paper and read and respond to
• Resources
communications from the city council members, mayor,
and head librarian. • Cost
• Schedule
6. During the grand opening of the library, patrons are Close • Stakeholders
asked to complete a survey about their thoughts about Project or • Quality
the new facility. Phase • Communications
7. The project manager interviews the mayor to understand Develop • Stakeholders
the community objectives of the new library and the Project
key stakeholders. Charter
102
Section III
Domain I: People
In this section, which covers 42% of the exam, we will look at the most important aspects of leadership you will need to
know for the exam. The People domain concerns skills and methods that help you succeed as a project manager and that
you can use to help others succeed on projects. We will focus on specific tasks listed in the ECO, appropriate to each of
the following chapters. First, we discuss models related to leadership and communication. Then, we talk about how a good
leader creates a high-performing team.
In this section, we cover:
• Servant leadership
• Critical thinking
• Communication skills and models
• The skillful use of communication technology
• Communication methods
• Motivation models
• Models of skill mastery
• Situational leadership models
• Team development models
• Conflict management
• Leadership responsibilities
• Resource management plan
• Team charter
• Estimating resource requirements
• Acquiring resources
• Types of team configurations
• Methods for developing a high-performing team
• Colocation and virtual teams
• Individual and team assessments, and project performance appraisals
• Key performance indicators (KPIs)
• Methods for managing the team
103
10^1
QUICKTEST
• Leadership
Leadership Skills • Management vs.

leadership
• Critical thinking
• Servant leadership
• Centralized vs. distributed
management and
Introduction
leadership
Much of a project manager’s job involves interacting and communicating with people, so it’s important • Flow of communication
• Communication types
for you to have good interpersonal and team skills, including cultural awareness and conflict manage
• Five Cs of Communication
ment. You need to be a leader, motivator, and team builder. You need to be able to establish trust on a
• Communication models
project, be approachable and influential, and be an effective listener. Your job as project manager is to
• Active listening
orchestrate and facilitate the success of other experts in their fields. You should also keep in mind going • Gulf of execution
into this chapter that while these related Examination Content Outline (ECO) tasks tend to focus on the • Gulf of evaluation
team, these skills apply to working with all stakeholders. • Communication blockers
Without people skills, as a project manager you will lose opportunities to learn about issues • Communication
technology
before they become serious problems. In addition, you need to be willing to address conflict directly
• Communication methods
and in a timely manner. Conflict is inevitable. Always assume you will approach conflict as an
• Communication channels
opportunity to improve the project and relationships with stakeholders.
• Intrinsic vs. extrinsic
So-called “people skills” are so important that the ECO has an entire domain devoted to it. By motivation
building these skills and effectively working with the team, you can be successful in creating a high- • Motivation models
performing team. In this chapter we present various models and theories related to learning, motivation, - Theories of X, Y, Z
and other foundational skills you need to understand and apply as you lead people and projects. - Maslow's Hierarchy of
Needs
Many students think this is all intuitive and do not study these sections carefully. They usually
- McClelland's Theory of
end up struggling on the exam, or even scoring below target as a result. Pay careful attention to this
Needs
chapter and make sure you understand the concepts presented here. - Herzberg’s Two-factor
Theory of Motivation
Overview of Leadership • Models of Skill Mastery
- Shu-Ha-Ri
Project managers must be effective leaders and communicators and have the ability to inspire others. - Dreyfus Model of Adult
There is no one right way to lead. You need to know the science of project management and be able to Skill Acquisition
utilize different leadership skills and styles based on any given situation throughout the project life • T-shaped skills
cycle. This means you should also be able to make expert decisions about what you are doing, even • Situational leadership
models
when it comes to interacting with and managing people. For example, you may sometimes need to
- Situational Leadership
coach team members, and at other times simply delegate work. In some cases, you may solicit the
II®
team’s input or involve the team in making decisions. Whatever the case may be, a project manager - OSCAR
must be intuitive when leading team members in order to achieve the best possible project perfor • Team development
mance. models
Leadership involves a sophisticated approach to working with people. We don’t manage people; - Tuckman’s Ladder of
we get work done through others. When leading a project team, consider skills, learning styles, and Team Formation
- Drexler/Sibbet Team
motivations of the team and align project tasks and goals accordingly. This will create more productivity.
Performance Model
The following chart shows some key differences between management and leadership. • Trust
• Negotiation
Management Focus Leadership Focus • Influencing
• Training
Tasks/things People
• Coaching
Control Empowerment • Recognition and rewards
Efficiency Effectiveness • Conflict management
Doing things right Doing the right things • Conflict model
Speed Direction
Practices Principles
Command Communication
105
Leadership Skills FIVE
Is leadership independent of management? Do you practice one and not the other when managing a project? A
project manager must be able to both manage and lead on projects, with the emphasis on leadership that aids a team and
other stakeholders in performing at their best.
5.1 Exercise
Review the activities below, and determine whether they are mainly leadership or management based.
1. Human resource management 5. Task assignment

2. Career planning 6. Team brainstorming
3. Team time tracking 7. Planning workshops
4. Team member recognition 8. Negotiating a contract
Answer
1. Management 5. Management
2. Leadership 6. Leadership
3. Management 7. Leadership
4. Leadership 8. Management
Definitions Related to Leadership

Critical Thinking
It is the project manager’s responsibility to apply critical thinking skills to effectively manage a project. Like solving a
Rubiks Cube, the project manager should look at a project from all angles, and move the pieces to the right place at the
right time. Different options will present themselves, emotions will arise, but the project manager thinks strategically
about how to produce the best end result. Critical thinking involves the following:
• Gathering unbiased information
• Responding logically, and without bringing more emotion to the situation
• Resolving issues using analytical skills
• Analyzing data to address the issue and choose the right path
• Being aware of relationships and related patterns
• Identifying when someone is off-base with their reasoning
Emotional Intelligence
Emotional intelligence is a well-known set of interpersonal skills associated with having greater leadership success. It
describes the ability to perceive, evaluate, and control emotions in self and others. For example, an emotionally intelligent
project manager is able to establish and maintain positive relationships by adjusting communications and anticipating the
needs of others. They understand how emotion can drive the behavior of others and are able to use this understanding
when dealing with the issues and concerns of the team. Emotionally intelligent project managers are able to effectively use
conflict resolution techniques (discussed later in this chapter) because they are perceived as being trustworthy and fair.
106
FIVE Leadership Skills
Emotional intelligence is something that can be learned and developed. It enables a project manager to bring out the
best in coworkers and team members by making them feel valued and important. Figure 5.1 shows the quadrants of
emotional intelligence: self-awareness, self-management, social awareness, and relationship management. The core
competencies are listed in each quadrant.
What 1 understand What 1 do
Self-awareness Self-management
• Self-confidence • Self-Control
With me • Accurate self-assessment • Conscientiousness
• Emotional self-awareness • Adaptability
Social awareness Relationship management

• Empathy (social skills)
With others • Organizational awareness • Influence others
• Environmental awareness • Develop others
• Inspire others
• Teamwork and collaboration
Motivation, or understanding what drives and inspires people, is often

described as a fifth component of emotional intelligence.
Figure 5.1 Quadrants of emotional intelligence
Servant Leadership
As compared to traditional hierarchical leadership where emphasis is on the authority of the leader, servant leadership
means the leader shares power and helps enable those they lead to perform their best and to grow. A project manager as
servant leader, for example, ensures team members can effectively do the work in order to deliver business value. There are
certain aspects to this kind ofleadership and the focus is always on maximizing team productivity by removing impediments
and supporting the team’s work. If you see an agile question on the exam that is dealing with leadership, think servant
leadership.
There are four primary duties a leader performs in this role of serving the team:
1. The project manager will make sure team members stay on track and have no unnecessary interruptions, and that
work unrelated to the project does not get added.
2. In the daily standup meeting team members name any impediments. These could be compliance- or
documentation-related issues. The project manager works to remove impediments to keep the team moving
forward.
3. The servant leader will continually communicate the project vision so team members have a good understanding
of the final goal. By doing so, the team can make good decisions to produce the final product.
4. The servant leader gives the team everything they need to be productive and to stay motivated. The essentials can
include everything from rewards, compensation, support, or encouragement.
Centralized vs. Distributed Management and Leadership

The PMBOK® Guide outlines the differences between centralized and distributed leadership. Centralized teams report to
one leader, such as the project manager. Distributed management is when the team follows the leadership of several
individuals. This could be the project manager plus the project management team. Or, the team could be self-organizing
and no one person is leading the team but rather they share the responsibility.
107
Communication Skills
Communication is an important part of leadership, and effective communication underpins project success. You will need
to understand the following aspects of communication for the exam.
The Flow of Communication

It’s important to pay attention to how communication flows on a project.
Project communications occur internally and externally to the core project team—vertically (up and down the
TRICKS
OF THE levels of the organization) and horizontally (between peers). Make sure your planning includes communicating
TRADE in all directions, as shown in figure 5.2.
Customer, sponsor, other stakeholders
<-------------------
Other project managers,
Scrum Masters, and team leaders
Project Team
Portfolio and program managers
<----------------
PMO
FIGURE 5.2 Flow of communication on a project
Communication Types
The first step in effective communication is choosing the best type of communication for each situation. Information can
be expressed in different ways—formally or informally, written or verbal. You need to decide what approach to use for each
instance of communication. Make sure you understand the following chart.
Communication Type When Used

Formal written Project charter, planning documentation, backlogs, contracts, and
reports; can be physical and electronic
Formal verbal Planned meetings and stakeholder briefings; standup meetings and
retrospectives; can be face-to-face or remote
Informal written Email, handwritten notes, text messages, instant messaging, social
media, and websites
Informal verbal Unscheduled meetings, conversations, and other casual discussions
108
5.2 Exercise
Test yourself! What is the best type of communication in the following situations?
Situation
1. Updating project communications strategies
2. Giving presentations to management
3. Trying to solve a complex problem
4. Updating the product backlog
5. Making notes regarding a telephone conversation
6. Making changes to a contract
7. Scheduling a meeting
8. Clarifying a work package
9. Requesting additional resources
10. Trying to discover the root cause of a problem
11. Sending an email to ask for clarification of an issue
12. Holding a milestone party
13. Conducting an online bidder conference
Answer
Imagine these as situational questions. Exam questions may have more words, but they will boil down to
straightforward situations like the ones described in the exercise table.
1. Formal written
2. Formal verbal
3. Formal written
4. Formal written
5. Informal written
6. Formal written
7. Informal written
8. Formal written
9. Formal written
10. Informal verbal
11. Informal written
12. Informal verbal
13. Formal written
109
The Five Cs of Communication

Certain qualities of written communication enhance the likelihood that communications will be correctly interpreted and
understood by the recipients. The following qualities should be incorporated by the project manager to ensure that
messages are effective:
• Correct grammar and spelling
• Concise and well-crafted
• Clear and purposeful
• Coherent and logical
• Controlled flow of words and ideas
Communication Models
The most basic communication model only ensures that a message has been delivered, but excellent project communication
requires a more complete approach to communications. A more comprehensive communication model, interactive
communication, includes three main components: the sender, the receiver, and the confirmation that the message is
correctly understood. Each message is encoded by the sender and decoded by the receiver. The receiver acknowledges
receipt of the message, and both the sender and receiver are responsible for confirming that it has been properly interpreted
by the receiver.
Factors such as working with different languages and cultures are important, but even the receiver’s perception of the
message, everyday distractions, or a lack of interest can affect the way the receiver decodes a message. Communication
models often refer to these types of factors as “noise” because they can interfere with the receiver’s ability to understand
the message.
More complicated communication models exist, and different models may be appropriate for different projects or
components of a single project. Keep the interactive model of communication, as shown in figure 5.3, in mind when
answering questions on the exam related to communications.
Sending Effective Communication The sender should determine which communication method to use to
send a message, and then encode the message carefully and confirm that it is understood. When encoding the
message, the sender needs to be aware of the following communication factors:
• Nonverbal A significant portion of in-person communication is nonverbal; this can include gestures, facial
expressions, and body language.
• Verbal There are two important aspects of verbal communication:
/ The words and phrases a sender chooses are essential components of the message, but their meaning can
be obscured by the accompanying nonverbal factors.
/ Pitch and tone of voice also help to convey a spoken message.
To confirm the message is understood, it’s helpful for the sender to ask for feedback using questions such as, “Could
you rephrase what I’ve said in your own words?” But it’s also up to the receiver to make sure they have received and
understood the entire message.
This is especially true in situations involving cross-cultural communication. Senders and receivers of communications
must be aware of cultural differences, including age, gender, and nationality, and take those factors into account when
planning, transmitting, and interpreting communications.
110
If a message is not understood, the receiver should acknowledge the message by saying something like, “I’m not sure
I understand. Can you explain that again?” Like the sender, the receiver needs to encode their response carefully, keeping
in mind the potential effects of verbal and nonverbal communication, when giving feedback to the sender, as illustrated in
figure 5.3.
Communication Type
Encoded message sent Message received and decoded
Active AZ
/V Listening
((( NOISE ))}

Feedback received and decoded Encoded feedback sent
Communication Type
FIGURE 5.3 The interactive communication model
These factors apply to individual interactions as well as to project communications. It’s possible to plan not just the
types of communications to be used, but also ways for the sender to confirm the receiver has interpreted the message as
intended. A project manager provides guidance to stakeholders regarding what to communicate and when to communicate
it. It can be included in planning documents, information radiators, and verbally, and may also include direction on how to
confirm the understanding of communications.
Effective Listening So what should a receiver do during in-person communication to accurately decode a
TRICKS
OF THE message and confirm it has been understood? The receiver should pay attention to the sender’s gestures and
TRADE facial expressions, and try to focus on the content of the message without distraction. It ’s also important that
a receiver practices active listening. Active listening means the receiver confirms they are listening, accurately
reflects back on the speaker’s remarks, expresses agreement or disagreement, and asks for clarification as necessary.
A gap in communication can cause something known as the gulf of execution or gulf of evaluation.
The gulf of execution is related to how closely a feature or product can actually be implemented compared to what the
user wants. For example, content developers for a zoo website want users to be able to find content related to a search on a
particular topic, such as “bears.” The content developers want the user to be able to get images, information, blog posts,
etc., in just one click of the mouse. Because of the massive amount of content their database holds, developers discover that
users will have to select the type of bear they want more information on. Will it be a polar bear, a black bear, a grizzly bear?
There is a gap, or gulf, in what the content developers envisioned and what is actually possible. The one-click operation is
actually more than one click.
The gulf of evaluation is a communication gap between the user and the developer. It’s a bit like a game of “telephone.”
What one person hears is different from what they tell the next person. This reinforces the need to have a good interactive
model of communication. Figure 5.4 shows what happens when there is a gulf of evaluation on the project.
Communication Blockers
Like noise in a communication channel, blockers can range from a lack of cultural sensitivity to a failure to provide concise
messages. Blockers cause miscommunication and can lead to disagreement and confusion. The exam has often included
one or two questions that ask, “What can get in the way of communication?” or “The following has occurred; what is
wrong?” The correct answer may include:
• Noisy surroundings • Language challenges
• Distance between those trying to communicate • Culture
• Improper encoding of messages
Skillful Use of Communication Technology

Communications can take place in many ways: in person or virtually, over the phone, in writing, through instant messaging
or text, and via email. These means of communicating are collectively referred to as communications technology. A key
aspect of planning communications is determining the optimal technology with which to communicate information. Agile
emphasizes more face-to-face communication, while more formal written communications are necessary when utilizing a
predictive approach. You can use the following list of questions to determine the appropriate technology based on
the situation:
• Would it be better to communicate this information in person or virtually?
• Would it be better to communicate the information through an email or a phone call?
• What technology is the team familiar and comfortable with ?
• How quickly and how often does the information need to be communicated?
• Are there security or confidentiality issues that should be considered when choosing a means of communi
cating information?
• Would a letter sent through the mail get more attention?
Also consider the complexity of the information that needs to be communicated. Alistair Cockbum
developed a communication effectiveness model to compare communication methods for their effectiveness
and richness, or “temperature.” Figure 5.5, is based on Cockburn s model. Notice two key factors—interactivity Agile
Focus
and information density—for several communication methods. This concept is especially important in agile
environments where complex information is communicated in less formal ways.
112
Interactivity and information density indicate a communication methods ability to transfer complex information
efficiently relative to other methods. In figure 5.5, paper-based communications are the lowest in interactivity and
information density. Written documents take a long time to create and have to be written so that all stakeholders can
understand the information, regardless of their expertise. Paper documents are also low in bandwidth, so they do not
convey emotional tone, feeling, or implicit assumptions.
Figure 5.5 Information transfer efficiency via technology
At the other end of the scale, face-to-face communication at an electronic or low-tech whiteboard has the highest
efficiency. Participants can converse and draw their ideas on the whiteboard. They can use shortcuts for well-understood
concepts to speed the exchange of information, and they can ask each other questions and get immediate feedback.
Nonverbal communication such as gestures, facial expressions, and tone of voice are also included.
Face-to-face communication allows for the most information to be transferred in a given period of time, but it is less
convenient than other forms of communication. Can you see how this approach would be helpful for the project team, but
may be impossible with all stakeholders on a project? Think about how you would use this model for your real-world
projects.
Communication Methods
Communication methods can be grouped into the following categories: interactive, push, and pull. In choosing a
communication method, you should consider whether feedback is needed or if it is enough to simply provide the
information. Where possible, its worth involving stakeholders in the final decision about which methods will meet their
communication needs. Such decisions will support the stakeholder engagement efforts on the project.
• Interactive communication This method is reciprocal and involves two or more people. One person provides
information; others receive it and then respond to the information. Examples of interactive communication include
conversations, phone calls, meetings, instant messaging, and video calls.
• Push communication This method involves a one-way stream of information. The sender provides information to
the people who need it but does not expect feedback from the recipients. Examples of push communication are status
reports, emailed updates, blogs, and company memos.
• Pull communication In this method, the sender places the information in a central location. The recipients are then
responsible for retrieving the information from that location. This method is often used to distribute large documents
or to provide information to many people.
IIS
Communication Channels
Communication channels can be thought of as the number of pathways for communication between parties. When you
add one more person to the team, does the number of communication channels simply increase by one? No. In fact, there
is a substantial increase in communication channels. As a result, communication needs can grow rapidly with each
added stakeholder.
Communication channels can be calculated using the following formula:
—— n = the number of stakeholders
Note that n equals the total number of stakeholders. For the exam, be sure to understand the concept, and know how
to calculate the number of communication channels.
Let’s practice using this formula with an example. If you have four people on your project and you add one more, how
many more communication channels do you have? To get the answer you calculate the number of communication channels
with a team of four and with a team of five, and then subtract to identify the difference.
Example For a team of four: calculate 4 times 3 (which is n - 1) to get 12, and then divide by 2 to reach the answer,
which is 6.
Figure 5.6 Communication Figure 5.7 If you add one more,

channels for a team of 4. how many more do you have?
Example For a team of five: calculate 5 times 4 (which is n 1) to get 20, and then divide by 2 to reach the answer,
which is 10. The difference between 10 and 6 is 4. Simple!
Did you think the answer was 10? Be carefill of the wording of exam questions. This question did not ask how
many total channels you have; it asked how many more channels you have. Also notice this: It is surprising
how much the number of communication channels rises when you add one person to the mix! The formula is
simple but not intuitive. Whether or not you have to calculate this formula on the exam, you will have to
I understand its implications.
Motivation Models
How can you maintain the cooperation and motivation of the team if you don’t understand what motivates its members?
Here, we will look at some motivational theory models. You may need to identify some of these theories on the exam, or
you may see them as answer choices.
Intrinsic Versus Extrinsic Motivation

According to Daniel Pink, extrinsic (external) motivation factors like salary are limited and short-lived motivators. Once a
person is fairly compensated for their work, it is intrinsic (internal) factors that motivate people. Luckily it is these factors
you have the most influence over as a project manager.
Pink put internal motivators into three categories: autonomy, mastery, and purpose.
• Autonomy This motivational factor appeals to desires people have to direct their own lives. Examples: Flexible work
hours, working from home, and being able to influence what projects they are on. While self-managing teams are
typically associated with agile, good leadership on any project means people on any project team should be able to
manage their own work.
IM
• Mastery This is the desire to improve, excel, learn, and do excellent work. You should be able to assume that the team
you work with want this and then do what you can to help them be their best.
• Purpose People also have an intrinsic need for a sense of purpose. Ensuring a cohesive team, a clear project vision,
and a common understanding will help meet this goal, as well as simply letting people know they’re doing a good job
and making a difference.
Theories of X, Y, and Z
McGregor created the Theory X and Y models of worker motivation and suggested optimal related management styles.
Maslow added the Theory Z dimension, and Ouchi developed his own version of theory Z.
XX
TRICKS Theory X Based on the first picture on the right, take a guess as to what Theory X is.
OF THE
TRADE* Answer Managers who accept this theory believe people need to be watched every minute.
They believe employees are incapable, avoid responsibility, and avoid work whenever possible.
Theory Y Based on the second picture on the right, take a guess as to what Theory Y is.
Answer Managers who accept this theory believe people are willing to work without supervision, and
want to achieve. They believe employees can direct their own efforts. It’s a PMI-ism that this is indeed how
team members behave, so unless directed otherwise, assume this perspective when responding to exam
questions.
Theory Z Maslow proposed the Z dimension as transcendent over goal orientation or even being
intrinsically motivated. Here motivation is linked to self-realization, values, and a higher calling.
Ouchi s version of Theory Z focuses on the well-being of employees and their families—a job for life
that takes care of them promotes morale and productivity.
Maslow’s Hierarchy of Needs

Maslow’s message is that the highest motivation for most people is to contribute, to grow, and to use their skills. Maslow
called this “self-actualization.” He created a hierarchy of needs to explain how people are motivated and stated once the
needs at the bottom of the pyramid are met people move on to the next level. A person cannot ascend to the next level until
the levels below are fulfilled as shown in figure 5.8.
Self
actualization Self-fulfillment, growth, learning
Esteem Accomplishment, respect, attention, appreciation
Social Love, affection, approval, friends, association
Safety Security, stability, freedom from harm
Physiological Need for air, water, food, housing, clothing
FIGURE 5.8 A representation of Maslow’s hierarchy of needs
115
Leadership Skills
McClelland’s Theory of Needs (or Acquired Needs Theory)

This theory states that people are most motivated by one of three needs. A person falling into one need category would be
managed differently than a person falling into another category. The following table explains the three need categories.
Primary Need Behavioral Style
These people should be given projects that are challenging but are reachable.
Achievement
They like recognition.
These people work best when cooperating with others.

Affiliation
They seek approval rather than recognition.
People whose need for power is socially oriented, rather than personally
Power oriented, are effective leaders and should be allowed to manage others.
These people like to organize and influence others.
Herzberg’s Two-Factor Theory of Motivation

Herzberg’s theory deals with hygiene factors and motivating agents.
Hygiene Factors Poor hygiene factors may destroy motivation, but improving them, under most circumstances, will not
improve motivation. Hygiene factors are not sufficient to motivate people. Examples of hygiene factors include
the following:
• Working conditions • Relationships at work
• Salary • Security
• Personallife • Status
Motivating Agents Assuming hygiene factors are satisfied, people are motivated, energized, and engaged by the work
itself, including factors such as:
• Responsibility • Professional growth
• Self-actualization • Recognition
So, the lesson here is that motivating people is best done by rewarding them and letting them grow. Solving an
individual or team issue may mean the project manager has to make sure certain basic needs are met within the project.
Then they can use rewards, recognition, and the roles and responsibilities assigned to individuals and teams.
Models of Skill Mastery
Shu-Ha-Ri Model of Skill Mastery

The shu-ha-ri model comes from martial arts training. It has been adopted by agile practitioners as a way to move through
three levels of mastering a new skill or process. The three levels are as follows:
1. Shu: This is where the rules are learned and obeyed—shu means “to keep, protect, or maintain”
2. Ha: This is when the rules have been mastered through practice—ha means “to detach or break free”
3. Ri: This is the final stage where the rules become second nature. Practitioners in this stage can also teach and lead
others—ri means “to go beyond or transcend”
The leader on an agile team uses this model to develop a high-performing team.
116
Dreyfus Model of Adult Skill Acquisition

This model proposes that adults learn new skills through
five different stages: novice, advanced beginner, Expert
^Proficient
competent, proficient, and expert Like the shu-ha-ri
model, the idea is that knowledge is gained as the person Competent
moves through each phase. As shown in figure 5.9, the ^Advanced

commitment, decision-making skills, and perspective beginner
also shift as a person moves through the phases. Here,
c‘Novice
you can see that on the top row the novice starts with a
detached commitment, and that commitment evolves.
Detached Detached Increased
On the second row, decision-making skills start at Committed Committed
commitment commitment commitment
analytical and move into intuitive as expertise is gained. Analytical
Measured Holistic view
On the bottom row, the perspective changes from none, Follows rules
planning of project
Intuitive
or no opinion, to experienced. The person becomes an
Does not have Situational Perspective Sets
expert in their perspective. perspective Perspective of goals priorities Visionary
T-Shaped Skills
One metaphor for assessing skill sets needed for Figure 5.9 Dreyfus Model of Skill Mastery
individual team members is to designate them as
I-shaped or T-shaped. I-shaped team members specialize
in one area, while T-shaped team members have a broad range of skills. On hybrid and agile projects where
the work is done iteratively and incrementally, teams prefer T-shaped people who can help share the workload
or adapt to the changing needs of the project. T-shaped people help optimize value to the project by
reducing bottlenecks.
Note: While this model in project management is currently associated with hybrid and agile projects, the fact is team
members on all projects and employees in general are being asked to expand their skill sets so that more team members will
have a T-shaped skill set. Most important to note here is that people with T-shaped skill sets excel in their core competency.
Specialists are still needed; hence the agile term generalizing specialists.
Qi Qi
G G
•SQ . c:
-g* S
1
§i
Dev. Q Dev. Q cq
FIGURE 5.10 I- and T-shaped team members
117
Situational Leadership Models

Leadership demands different approaches in different situations, so of course you must tailor your approach to interper
sonal communications and leadership depending on the situation. There are many situational leadership models, but here
we profile the two that are in the PMBOK* Guide: the Situational Leadership 11“ model proposed by Ken Blanchard, and
Whittleworths and Gilbert s OSCAR model.
Situational Leadership II®

Think of the many people with whom you interact. You probably have an intuitive sense of how to interact with them based
on a number of things you may know about them: How they take in information, how they react to things in general, and
factors related to the content of what you are communicating about. Blanchard s Situational Leadership 11“ model is useful
in project management as it focuses on two factors: competence and commitment. As you learn a persons competence and
know how to help them to continuously improve their skills and abilities, and you know their commitment is solid, your
leadership approach evolves from directing and then coaching to supporting to eventually just delegating.
• Competence This variable is just what you would expect: a combination of knowledge, skills, and abilities.
• Commitment This factor is about the confidence and motivation a person has.
The OSCAR Model

The OSCAR model is a popular coaching tool that helps leaders define the goals for individual team members. OSCAR
stands for Outcome, Situation, Choices/Consequences, Actions, and Review.
• Outcome This is about individual long-term goals. What does that team member want?
• Situation This is about where the team member is right now in their skill development.
• Choices/consequences It s here that the team member decides how they will achieve their long-term goals. The
project manager can help the team member understand the consequences of any choice they make.
• Actions In this stage, the team member comes up with a plan of action to achieve those goals.
• Review Once the team member is on the path, it’s important to review how well those goals are being achieved and
make course corrections if necessary.
https://rmcls.com/
To learn more about leadership for the exam, be sure to read the free articles “Management and
Leadership Styles” and “Powers of the Project Manager” on the RMC Resources web page (rmcls.com/
rmc-resources).
5.3 Exercise
Try this exercise to test yourself on the models we’ve covered so far. Identify which team model belongs to the
following statements. Note, each model is used more than once.
1. Unconsciously finding an individual path

2. Primary Need: Achievement. “They like recognition”
3. Motivating Agents
4. Self-actualization: self-fulfillment, growth, learning
5. Hygiene Factors
6. Choices/Consequences
7. Primary Need: Affiliation—“They seek approval rather than recognition”
8. Obeying the rules
9. Esteem: accomplishment, respect, attention, appreciation
10. Outcome
118
Answer
1. Shu-ha-ri Model of Skill Mastery
2. McClelland s Theory of Needs
3. Herzberg s Two-Factor Theory of Motivation
4. Maslows Hierarchy of Needs
5. Herzberg s Two-Factor Theory of Motivation
6. OSCAR Model
7. McClellands Theory of Needs
8. Shu-ha-ri Model of Skill Mastery
9. Maslows Hierarchy of Needs
10. OSCAR Model
Team Development Models

High-performing teams are made through leadership and the efforts of the team itself. It is about more than the capabilities
and commitment of the individuals involved. It is very normal for teams to pass through a series of stages or a cycle of
stages before reaching the level of a high-performance team. The process is very human and not always comfortable, so
good leadership is needed to foster a safe team environment. Here are two models of team formation and team perfor
mance.
Tuckman’s Ladder Model of Team Formation

The way the Tuckman model sounds can help you remember it for the exam: “Forming, Storming, Norming, and
Performing” (and then adjourning). The Tuckman ladder model formally identifies these stages of team formation
and development:
• Forming People are brought together as a team.

• Storming There are disagreements as people learn to work together.
• Norming Team members begin to build good working relationships and learn to trust the project manager and
each other.
• Performing The team becomes efficient and works effectively together. This is the point when the project manager
can give the most attention to developing individual team members.
• Adjourning The project ends, and the team is disbanded.
119
New teams may go through each step, while teams that have worked together before may experience a shortened
version, possibly even skipping some of the early steps.
“Me" thinking stage.

Getting-to-know-you stage. Conflicts and disagreements
Lots of questions about result from people looking
purpose, team, roles. out for their own Interests.
Forming Storming
Performing Norming
“We" thinking stage.
“Efficient processes" stage. Team begins to norm around
Team is working on improving a common purpose and goal
their processes so they are and show signs of healthy
lean and efficient. team dynamics.
FIGURE 5.11 Tuckman’s Model of Team Formation
Drexler/SibbetTeam Performance Model

Like the Tuckman model, the Drexler/Sibbet Team Performance Model depicts stages (steps) teams go through to form,
develop, and become high performing. Drexler/Sibbet defines seven stages.
Steps 1-4 describe where the team is at with the project as they form and develop. In these steps, the team learns “why,
who, what, and how” of their coming together.
Steps 5-7 describe what is happening as high performance is attained and sustained.
Step 1: Orientation, or “Why” The team comes together and learns the purpose of the project. In terms of project
management meetings and artifacts, think kickoff meeting, business case, project charter, or lean start-up canvas (which
is a simple yet comprehensive framework for building a clear project vision, proposed solution scope, and success
criteria).
Step 2: Trust building, or “Who” This stage is where information is shared and learned about the project team and
each member s skills and abilities, as well as whatever other key stakeholder information is available.
Step 3: Goal clarification, or “What” At this stage the team elaborates on the project information they already have.
It includes finding out more about stakeholder expectations, project and product requirements, project and stakeholder
assumptions, and deliverable acceptance criteria.
Step 4: Commitment, or “How” At this stage the team has formed. It plans for and begins to achieve the projects
goals. Artifacts can include milestone schedules, release plans, high-level budgets, resources needs, and other high-level
planning artifacts.
Step 5: Implementation The high-level plans are decomposed into the greater level of detail for detailed planning,
and then execution against the plan to produce deliverables. Artifacts to associate with this stage include the projects
release map, schedule, backlog, or its scope baseline.
Step 6: High performance At this stage the team has been working together for some time, they work well together,
have their working agreements ironed out, and have reached a level of high performance. They do not need
much oversight.
Step 7: Renewal As changes occur within the project (deliverables, for example) or team (leadership, team members,
or other stakeholders, for example), the team has an opportunity to look at past performance in perspective to see if
anything about the way they operate needs to change. The team may revisit previous stages to renew goal clarification,
commitment, or other ways of working together.
It is the leader s responsibility to guide stakeholders through organizational change or change on a project. As a leader
it’s important to have an awareness of how change impacts stakeholders.
120
Other Leadership Concepts

Trust
Think of project problems you have recently experienced. Now ask yourself the following questions: “Could these problems
be caused by a lack of trust? Do team members trust each other? Do they trust the project manager?” The team needs to
feel that the project manager is working in the best interests of the project, the company, and the team—rather than in the
best interest of the project manager. Trust is gained or lost from the minute the project manager meets each team member
for the first time. If the team does not trust the project manager, then they cannot easily be successful. The team will not
take direction or follow instructions, and the project will suffer.
An important role of a project manager is to create a psychologically safe work environment where people can ask
questions and show incomplete versions of their work without being criticized. Providing a team with this level of trust
increases collaboration and helps improve the project.
A common method for increasing trust on agile projects is to engage the team in the development of *
estimates. Activities like Planning Poker®, as described in the Schedule chapter, build trust amongst the team
members, the estimate, and the solution.
Once you have trust, it can be lost if you are not honest and consistent. Assuming you work in a matrix
organization, how do you get people to cooperate if you do not have the ability to give them a raise or a promotion? Trust,
as well as a recognition and reward system are the answers.
Think About It. Trust also affects, and is affected by, reputation. Do you know what your reputation is? Many of
the people you meet know. Why not ask them about it, so you can deal with any changes you need to make?
Negotiation
Negotiation can provide value in developing the team while working to build consensus on project decisions. Including
the team members in the decision-making process shows that the project manager values and considers their input.
Influencing
Influencing is an important aspect of a project manager s role that begins with actively listening to differing viewpoints
expressed by team members. Acknowledging those different perspectives and using communication and persuasion skills
helps the project manager develop mutual trust and, eventually, agreement within the team.
Training
Team members may require training to perform on the project or to enhance their performance. Such training can help
team members while also decreasing the overall project cost and schedule through increased efficiency. If the training will
benefit the organization in the long run or can be used on future projects, it may be covered as an organizational cost.
Otherwise, it is paid for by the project and documented in the resource management plan and included in the project
budget.
Coaching
The goal of coaching is to help team members stay on track, overcome issues, continually improve their skills, and achieve
their goals. Coaching is done at two levels—with the team and with individual team members. Individual coaching sessions
should be confidential meetings in a safe environment. During the conversation, it’s important to be frank, yet remain
positive and respectful. After the meeting, the coach should follow up to make sure there is improvement.
Recognition and Rewards

The project manager appraises performance and provides recognition and rewards in response to the work of the team or
individual team members. To be effective, such rewards should be determined based on the project manager s understanding
of what is valuable to the team member or group being recognized. In addition to recognizing past accomplishments,
rewards provide incentive for ongoing achievement and efforts.
Conflict Management
Many situational questions on the exam describe conflicts. Therefore, to be able to pick the best choice from many “right”
answers, you should understand different conflict resolution techniques and be able to determine which one is best for the
situation described.
Think About It. Think about conflict. Is it bad? Should we spend time preventing the root causes of conflict?
Who should resolve the conflict? Try to answer the questions just posed. Get them right, and you are likely to do
well on this part of the exam.
The answers are:
• No, conflict is not inherently bad.
• Yes, it is important to identify and deal with the root causes of conflict.
• Conflict should be resolved by those who are involved, possibly assisted by the project manager.
• Although we often think of conflict as a bad thing, it actually presents opportunities for improvement. Many people
still have outdated beliefs about conflict. For the exam, make sure your understanding reflects the current
(new) perspective.
Changing Views of Conflict

Old New
Conflict is dysfunctional and caused by personality Conflict is an inevitable consequence of
differences or a failure of leadership. organizational interactions and the many different
ways that projects can be accomplished.
Conflict is to be avoided. Conflict can be beneficial.
Conflict is resolved by physical separation or the Conflict is resolved through openness, identifying
intervention of upper management. the causes, and problem-solving by the people
involved and their immediate managers.
Conflict is inevitable, in part, because of the following factors.

• The nature of projects, which attempt to address the needs and requirements of many stakeholders
• The level of emotional intelligence held by team members
• The necessity of obtaining resources from functional (resource) managers
The project manager has a professional responsibility as part of basic project management to attempt to avoid conflicts
through the following actions:
• Keeping the team informed about the following:
>/ Exactly where the project is headed
V Project constraints and objectives

>/ The contents of the project charter
All key decisions
y Changes
• Clearly assigning work without ambiguity or overlapping responsibilities

• Encouraging collaboration and consensus building
• Making work assignments interesting and challenging
• Following good project management and project planning practices
122
Many people think the main source of conflict on a project is personality differences. They may be surprised to learn
that this is rarely the case. It only becomes personal if the root cause of the problem is not resolved. On a project, the seven
sources of conflict in order of frequency are as follows—note that personality is last.
1. Schedules (unrealistic)
2. Project priorities
3. Resources
4. Technical opinions
5. Administrative procedures
6. Cost
7. Personality
Conflict is best resolved by those involved in the conflict. The project manager should generally try to facilitate the
resolution of problems and conflict as long as they have authority over those in conflict or over the issues in conflict. If not,
the sponsor or functional managers may be called in to assist. There is one exception. In instances related to professional
and social responsibility (someone breaking the law, not following policies, or acting unethically), the project manager
must take the issue to someone higher in the organization.
Conflict Model
Based on the work of Thomas and Kilmann, this conflict model offers various conflict resolution techniques to know for
the exam. Notice that some have more than one title; you should know both.
• Collaborating (problem-solving) With this technique, the parties openly discuss differences and try to incorporate
multiple viewpoints to arrive at a consensus. Collaboration leads to a win-win situation.
• Compromising (reconciling) This technique involves finding solutions that bring some degree of satisfaction to
both parties. This is a lose-lose situation, since no party gets everything. Did you know that compromise is not the best
choice, but rather second to collaborating?
• Withdrawal (avoidance) With this technique, the parties retreat or postpone a decision on a problem. Dealing with
problems is a PMI-ism; therefore, withdrawal is not usually the best choice for resolving conflict, though there may be
situations where it is necessary.
• Smoothing (accommodating) This technique includes making some concessions; it emphasizes agreement rather
than differences of opinion. It does not result in a permanent or complete resolution of the conflict.
• Forcing (directing or competing) This technique involves pushing one viewpoint at the expense of another. It is a
win-lose situation.
TRICKS Remember to look for collaborating or problem-solving choices as generally the best answers. Forcing is
OF THE usually the worst, but the answer depends on the situation described. There could be situations in which
TRADE- withdrawal is the best option.
Note that we have presented the conflict model definitions as the original sources (Thomas and Kilmann) present
them. The PMBOK* Guide has a different interpretation on these definitions. On p. 263, the PMBOK* Guide gives a sixth
definition: Confronting/problem solving, which means treating a conflict as a problem to solve, so “confronting the
problem.” Notice we used the parenthetical (problem-solving) as associated with collaborating instead because that is
what Thomas and Kilmann do, as of this writing. It is hard to know if PMI will change this on their PMIstandards+™
platform, of it they will include their take in exam questions, so you should understand both of these characterizations.
Be sure to read about another important conflict management model in the free article “Levels of https://rmcls.com/rmc
Conflict - Leas Model,” on the RMC Resources web page (rmcls.com/rmc-resources).
RMC RESOURCES
123
5.4 Exercise
Read each statement made to try to resolve a conflict, and determine which technique is being used.
Description
1. “Do it my way!”
2. “Let’s calm down and get the job done.”
3. “Let us do a little of what both of you suggest.”
4. “Let’s deal with this issue next week.”
5. “Miguel and Kathleen, both of you want this project to cause as little distraction to your departments as
possible. With that in mind, I am sure we can come to an agreement on the purchase of equipment and
what is best for the project.”
6. “We have talked about new computers enough. The decision has been made to not get them.”
7. “Miguel, you say the project should include the purchase of new computers, and Kathleen, you say the
project can use existing equipment. I suggest we perform the following test on the existing equipment to
determine if it needs to be replaced.”
8. “Let’s see what everyone thinks, and try to reach a consensus.”
9. “Since we cannot decide on the purchase of new computers, we will have to wait until our meeting next
month.”
10. “Miguel, what if we get new computers for the design activity on the project and use the existing computers
for the monitoring functions?”
Answer
1. Forcing 6. Forcing
2. Smoothing 7. Collaborating
3. Compromising 8. Collaborating
4. Withdrawal 9. Withdrawal
5. Smoothing 10. Compromising
The next chapter will continue the discussion of working with the team, including acquiring, developing, and
managing a team.
I24
QUICKTEST
6 Build and Support Team • Resource Management

process
• Responsibility assignment
matrix (RAM)
• RACI chart
Performance • Organizational breakdown

structure
• Resource breakdown
structure (RBS)
• Organizational theory
• Resource management
Introduction plan
- Human resources
This chapter will cover the technical project management skills related to working with human resourc management plan
es on projects that you need to know to pass the exam. These skills are part of the Process Groups - Recognition
model for predictive project management, along with related agile project management concepts. As management plan
you study this chapter, be mindful of the material in the “Leadership Skills” chapter. Technical project • Team charter
management skills are not enough to be successful in project management, or on the exam. Working • Resource histogram
• Resource leveling
with others is so important that 42% of exam questions are based on the People domain in the Exam
• Types of team
ination Content Outline (ECO).
configuation
The ECO s Process domain does not have a task dedicated to human resources. Instead, the ECO - Dedicated
combines interpersonal and team skills with the project management technical skills for leading teams - Part-time
and other stakeholders into the fourteen tasks in the People domain. The “Leadership Skills” chapter - Partnerships
contains information on theories and models related to communication and human psychology, - Virtual
which is helpful in applying interpersonal and team skills. - Pre-assigned
- Agile
Be sure to review this chapter’s Quicktest before and after you read the chapter. Make note of the
• Negotiating for resources
gaps in your skills and experience so that you can work to fill your gaps prior to taking the exam. • Pre-assignment
• Halo effect
Overview of Building and Supporting Performance • Team building
• Team culture
Can we all agree it is amazing to be part of a high-performing team? Yet attaining and maintaining that • Colocation
performance level as a team takes effort. There are many things a project manager needs to do to build • Individual and team
and support high performance within the project team and among all stakeholders, like applying the assessments
knowledge gained in the “Leadership Skills” chapter to the methods for acquiring resources, develop • Hybrid assessments
• Project performance
ing the team, and managing the team that are covered in this chapter.
appraisals
• Key performance
The Examination Content Outline and Process Groups Model indicators (KPIs)
The following shows the fourteen People domain skills, the Process Group model for resources • Burndown charts
management in predictive environments, and of course those PMBOK* Guide domains that most • Burnup charts
directly map to these skills. The People domain of the ECO focuses mostly on the project team, so this • Issue log
chapter starts there before covering the Process Groups model for (human) resources. Take a moment
to glance down the first column here. Notice all tasks are dedicated to building and supporting the
team. The Process Groups model, while focusing on technical project management activities, relies on
skills in leadership and in supporting team performance.
125
Build and Support Team Performance
Think About It. ECO domain I: It’s all about the people! Let’s face it, you need to be doing all these tasks in the
ECO domain, and the enablers serve as examples of the ways they may manifest on a project. As you look at this
chart and the ECO, notice how many of the People domain tasks have the word “team” in the name.
We will talk more about the Process Groups model and agile methods later in this chapter, but for now, notice that we
have crossed out Control Resources in the middle column of the above table. This is because that process is dedicated to
material resources like equipment and supplies and not related to managing the team. The concept still applies to predictive
project management but we discuss it in the Process domain chapter on “Budget and Resources,” since the ECO addresses
this process with that task.
We have broken the People domain’s fourteen tasks into two groups of seven. This will make them easier for
TRICKS
OF THE you to study. We grouped seven People domain tasks that fit easily into the concept of building performance.
TRADE We then placed the remaining seven tasks into a group that fits nicely with the concept of supporting
performance. The exercise below supports using this model. Don’t worry about whether our model is perfect.
You will not be tested on the task numbers or the order of the tasks in the ECO. Ultimately all these tasks are related and
we include the task numbers in this book only to make them easy for you to find in the ECO.
Do not worry about memorizing ECO tasks and their enablers. What is important here is to make associations
TRICKS in your mind between these tasks and how they relate to building and supporting performance. Also think
OF THE
TRADE about the tasks in terms of the information you learned in the “Leadership Skills” chapter and what you are
learning in this chapter. Having an understanding of the ECO tasks will help you prepare for situational
questions on the exam better than memorization.
126
SIX Build and Support Team Performance
6.1 Exercise
If you have two different colored pens or highlighters available, use them to do the following. You want your
markings on the ECO to be very visible.
• Open your downloaded copy of the ECO. If you have not printed it, please do so now.
• Then open the ECO to the People domain section.
1. Look at the following lists, where we have broken the People domain tasks into “build” and
“support” performance.
2. In the People domain task list of your ECO, place a large, visible “B” under the task numbers in the ECO
we have placed in the Build column below.
3. Then place a large, visible “S” under the task numbers we have placed in the Support column below—in
a different color, if possible.
4. Now spend just two minutes going through the tasks and their enablers. Think of them as relating to
building a team, and supporting a team, respectively.
5. As you continue to prepare for the exam, take additional opportunities to review these tasks, their
enablers, and their associations with building and supporting a team.
Note: We abbreviated some task names while maintaining their meaning.
Answer
People Domain Tasks - A Grouping Memory Trick
Building Performance Supporting Performance
(2) Lead a team (1) Manage conflict
(4) Empower team members & stakeholders (3) Support team performance
(5) Ensure adequate training is provided (7) Address & remove impediments for the team
(6) Build a team (9) Collaborate with stakeholders
(8) Negotiate project agreements (ID Engage & support virtual teams
(10) Build shared understanding (13) Mentor relevant stakeholders
(12) Define team ground rules (14) Promote performance using emotional intelligence
Leadership Responsibilities
As the project work is being done, the project manager should know from the project charter what decisions they can make
and enforce and when they need the approval of someone higher in the organization. It is important to understand how the
role of the project manager interrelates to the other roles on the project, such as the project sponsor, the functional
managers, and the team.
An agile team lead’s roles are defined broadly in terms of being of service to the team. This means doing
everything from the ECO People domain tasks. A good leader will focus on making sure the processes needed
on the project are understood and being followed and that these processes are serving the needs of the
team—to provide team training where needed and to remove impediments to project progress.
If there is a separate project manager role on an agile project, they interface with other appropriate stakeholders like
the project sponsor and other organizational management. They also help with organizational change management when
the project will usher in a big organizational change, and they watch for internal and external business environmental
factors that may affect the project.
127
Build and Support Team Performance SIX
There are other responsibilities that a project manager role will fill on an agile project, where an agile team lead and a
project manager role both exist on the same project, like leading a group of several agile teams on the same large and
complex project. Assume the exam is using the term "agile coach” or “Scrum Master” interchangeably with “project
manager,” unless information in the question indicates otherwise.
Here are some important aspects of team leadership to know for the exam:
• The project manager’s resource management activities are formal and require documentation.
• There should be clear roles and responsibilities on the project. For example, who should be assigned to assist the
project manager, who should take on specific responsibilities at meetings, and who should be completing other work
not directly related to project activities? Exam topics such as motivation, conflict management, and powers of the
project manager are more challenging than you might expect. It’s important to know that these concepts need to be
planned for and managed throughout the project.
• Projects are planned by the team and coordinated by the project manager.
• Geographically and culturally diverse teams require additional attention and planning by the project manager.
• The project manager formally plans team-building activities in advance; these activities are a required part of
project management.
• Creating a recognition and reward system is an important resource management function, and such systems are a
required part of project management.
• The project manager is responsible for improving the competencies of team members so they are able to perform the
work on the project most effectively.
• The project manager must continually confirm resource availability.
• The processes of resource management are repeated and updated throughout the project.
• The project manager is responsible for controlling physical resources on the project; this is not only the responsibility
of procurement or other departments that may provide physical resources.
The resource management process takes time and effort to plan. You must do things such as identify all resources
needed to complete the project (including the required skills of team resources and the required quality and grade of
material or equipment), define everyone’s roles, create reward systems, provide training and motivation for team members,
manage the use of physical resources, and track performance.
Figure 6.1 is a visualization of team leadership at a high level from the Process Groups model perspective, which calls
the process Resource Management. For this reason, we generally use the term “resource” in place of “team” when talking
about the specific processes in the
Process Groups model. The
model will help you visualize the
responsibilities and skills for the
team leadership process, and
although it applies most directly
to the Process Groups model,
many of the concepts make sense
to know and employ on any
project. Take a few minutes
visualizing the process before
moving on to the Plan Resource
Management section of this
chapter.
FIGURE 6.1 Resource management process
128
Plan Resources
Roles and responsibilities and the authority that goes with them are agreed upon in Process Groups Model
planning and documented in the resource management plan. Roles and responsibili PG: Planning
ties definition is a critical part of the Plan Resource Management process. Project Process: Plan Resource Management
work often includes not just completing work packages, but other responsibilities,
such as assisting with risk, quality, and project management activities. Team members ECO
need to know what work packages and activities they are assigned to, when and how Domain I
they are expected to report, what meetings they will be required to attend, and any All Tasks
other work they will be asked to do on the project. In a functional or matrix environ
PMBOK* Guide
ment, the managers of team resources also need to understand when and for how long
Domain 2.2 Team
these resources will be needed on the project.
Domain 2.4 Planning
In short, Plan Resource Management answers the following questions:
Domain 2.5 Project Work
• How are we going to do all this as a team ?
• Who needs to be on the team to accomplish it?
• What do I need to do to be a good servant leader on this project?
Notice the sidebar for this section lists the ECO s People domain, “all tasks.” In Plan Resource Management, you are
planning to:
• Lead the team • Build that team (for high performance)
• Empower the team • Build and maintain a shared understanding
• Get the team the training they need
To do all this, you need to plan for negotiating project agreements and help the team define their own ground rules.
Now, that covers the “build performance” concepts discussed earlier in the first exercise in this chapter. What about
the “supporting performance” work for the project, as the team gets to building the product and things get more challenging?
Yes—you must support performance, too, by:
• Managing conflict • Mentoring stakeholders
• Removing impediments • Using emotional intelligence to
• Collaborating with (other) stakeholders promote performance
• Engaging and supporting a virtual team, if needed
Your plan must also answer questions such as:

• What resources are required?
• What quantity of each type of resource is needed to complete the project work?
• When and for how long will each resource be needed?
• Is there a limited time during which each resource will be available for the project?
• How will the resources be acquired?
• Are all resources available internally, or will the procurement department need to be involved?
• What will be the cost of these resources?
• How will resources be managed throughout the project?
On agile projects, its more common for the same team members to remain on the project from
it >
beginning to end. Teams remain stable and projects are brought to the team. Team members are often
“T-shaped” generalizing specialists—generalists in many things, expert of a few. Many agile team members
share responsibilities for several roles; for example, testing as well as building the product.
129
Artifacts Needed for Planning Resource Management

Before you can define roles, responsibilities, reporting structure, and so forth, you’ll need to consider many factors often
already documented in the project management plan:
• Project life cycle and processes This should be determined for you to do resource planning.
• Work approaches How work will be done.
• Communication needs of stakeholders One of the most early documented factors.
• Stakeholder register This lists the individuals and groups who are project stakeholders. It includes analysis of
factors such as each stakeholder s power and interest related to the project.
• Stakeholder engagement plan This includes the approach for team and other stakeholder involvement, for
engaging them in the planning, decision-making, and project work.
• Scope baseline This includes descriptions of project deliverables and helps the project manager determine resources
needed to create them.
• Quality management plan This includes agreed-upon levels of quality and grade of physical resources needed to
satisfy project requirements. These decisions will impact the teams options in terms of how and where they will
obtain these resources.
• Procurement management plan This plan describes how the project manager should interact with the
procurement department to facilitate obtaining needed human or physical resources.
Project Documents Several project documents can be used to plan resources, for example, requirements documentation,
the project schedule, and the risk and stakeholder registers. These documents provide key information for what type of
resources will be needed to complete project work, the timeline for them, and how many resources will be required to get
particular work done.
Enterprise Environmental Factors Before you develop a resource management plan, understand what enterprise
environmental factors may come into play. These are the company culture and existing systems the project will have to deal
with or can make use of. Consider the following:
• What internal organizations will be involved in the project?

• Are there hidden agendas?
• Is there anyone who does not want the project?
• Are assigned and potential team members colocated or based in different offices and/or countries?
• What is the availability of contract help?
• What is the availability of training for project team members?
Organizational Process Assets These can increase the efficiency of creating the resource management plan, and the
effectiveness of the resulting plan. Consider assets such as:
• A resource management plan template (typically describes standard resource needs and responsibilities)
• Existing policies and procedures for resource management
• Historical information, such as lessons learned from similar projects
Methods for Planning Resource Management

There are many tools and techniques that can be used to document and communicate roles and responsibilities of
management, team members, and other stakeholders. The PMBOK* Guide lists these as artifacts, but of course you also
need to know how to use the data gathering and analysis methods (or tools) for creating these artifacts. Examples include:
• Responsibility assignment matrix (RAM) • Organizational breakdown structure
• RACI chart • Resource breakdown structure (RBS)
• The work breakdown structure (WBS) • Organizational theory
For the exam, you will not be asked whether any of these are methods or artifacts. Rather, you will need to know what
each tool displays and is used for so you can answer situational questions that include them.
ISO
Responsibility Assignment Matrix (RAM)

Ibis chart cross-references team members with the activities or work packages they are to accomplish. Figure 6.2 is an
example of a RAM. Note it does not show time, or when people will do their jobs.
Team Member
Activity Karla Patrick Muhammad Trisha
A P S Key
B S P P = Primary
responsibility
S = Secondary
FIGURE 6.2 responsibility
Responsibility ass•ignment matrix
RACI Chart (Responsible, Accountable, Consult, and Inform)

This chart is a type of RAM that defines role assignments more clearly than the example shown in figure 6.2. Instead of the
P and S shown in the figure, the letters R for Responsible, A for Accountable, C for Consult, and I for Inform are used. Note
that multiple resources may be responsible, informed, or consulted, but only one person is held accountable.
Organizational Breakdown Structure Project
This tool (figure 6.3) is used to assign responsibilities to

divisions or departments within the organization, such as I ZZL
marketing or IT. In a matrix environment, the project manager Marketing
department department
Etc.
will interface with the managers of each department involved

in the project to coordinate availability and scheduling of
WBS 2.4.6
human and physical resources for the project. Cloud transition plan
Resource Breakdown Structure (RBS) WBS 1.1.2

Data security design
A WBS is typically referenced to create this chart. Similar in
format, the RBS breaks the work down by type of resource WBS 2.3.4
needed, as shown in figure 6.4. Usability test plans
FIGURE 6.3 Organizational breakdown structure
FIGURE 6.4 Resource breakdown structure
Work Breakdown Structure (WBS)

You’ve already seen that we refer to a WBS to create an RBS. The WBS, which we discuss in the “Scope” chapter, is a great
tool to ensure each work package has an “owner”—a team member responsible for that work.
Organizational Theory
Organizational theory is a method to study organizations to identify how they solve problems and how they maximize
efficiency and productivity and meet the expectations of stakeholders. This analysis helps the organization develop
effective resource management policies and procedures for the acquisition, management, and evaluation of
human and physical resources. Adopting practices such as Lean, Kaizen, just in time (JIT), or Six Sigma
influences how projects will handle the management of physical resources. These practices are covered in the
“Quality of Deliverables and Products” chapter and the “Agile Methodologies” chapter.
Artifacts of Plan Resource Management

The Plan Resource Management process results in a resource management plan, a team charter (including ground rules),
and updates to the project management plan and project documents such as the assumption log and risk register.
Resource Management Plan

If you manage small projects, think about what the resource management effort would involve on a large predictive project
that has hundreds of assigned resources. Would it take more work than you are doing now to manage the resources on your
project?
Components of a resource management plan include the following:
• Human Resources (Team) Management Plan
>/ Team requirements (who, when, how many, what skills, what level of expertise, duration)
y Roles and responsibilities
y Project organizational charts
y Process for acquiring human resources (internal or procurement)
y Training, team development, and recognition (goals, what, when)
y Project team management (team charter, ground rules, engagement, communications)
y Compliance (How will the project comply with any rules related to human resources?)
y Safety (policies to protect the resources)
y Release of human resources
• Recognition Plan
Recognizing individual and team accomplishments is one of the most effective ways to motivate people. It should
include when and how resources will be recognized, and what actions or achievements will be rewarded.
Everyone likes to feel appreciated. A good start to planning how to use recognition and rewards is to make a
conscious effort to personally acknowledge the efforts of team members. A smile and a “thank you” are often more
meaningful than you might think. To make the rewards more personal, you can ask team members and stakeholders
what they want to get out of the project, on a professional and personal level. They might respond with such things as,
“I want to learn more about XYZ,” “I want to decrease the time I am allocated to this project,” “I want to make sure I
leave work on time on Tuesday nights because I have a family obligation,” or “I want to be assigned a certain piece of
the project work.”
As the project progresses, the plan may be iterated as new team members are added, and as the project manager
becomes more familiar with the team and what motivates them. Recognizing and rewarding might include doing the
following on an ongoing basis, while project work is being done:
y Saying “thank you” more often
y Awarding prizes for performance
y Recommending team members for raises or choice of work assignments (which may not officially be part of
the team members’ performance reviews)
y Sending notes about great performance to team members’ managers
y Planning milestone parties or other celebrations
y Adjusting the project to assign people to activities they want to work on
y Assigning a new team member to a non-critical-path activity so they can learn in that area
The list could go on and on, but ask yourself, “Do I do any of these things? Do I do them systematically?” This requires
planning in advance and then iterating that plan as the project progresses.
Team Charter
This document is a working agreement developed by the members of the project team. The team charter describes the
approach the team will take regarding communications, decision-making, and conflict resolution, as well as ground rules
for team meetings. The team charter is a project document and can be referenced at any time during the project.
Setting ground rules can help eliminate conflicts or problems with the team during the project because everyone
knows what is expected of them. And if team members have input on the creation of the ground rules, they’re more likely
to follow them. Ground rules can be especially important when the team is managed virtually.
The ground rules may include items such as the following:
• How a team member should resolve a conflict with another team member
• When a team member should notify the project manager that they are having difficulty with an activity
• Rules for meetings
• Who is authorized to give direction to contractors
• How the team will decide work assignments
• When and how to provide status updates to the project manager
• Methods for coordinating and approving changes to team members’ calendars, both in normal and
emergency situations
On predictive projects with unchanging requirements or technology, it is appropriate to plan thoroughly and then
execute. But on agile projects key elements are likely to change so a high degree of planning may be inappropriate. Therefore,
it’s important for teams to have the processes (e.g., prioritization, demos, retrospectives) in place to allow for effective and
efficient adjustments during the project.
Estimate Resource Requirements

At this point in resource planning the project manager and the team have a plan in Process Groups Model
place for how resource needs will be coordinated. In predictive project management, PG: Planning
the project manager now must estimate the type and quantity of all resources needed Process: Estimate Activity Resources
to complete project work at the work package and activity level.
ECO
The resource management plan includes documentation on estimating methods
that may be used. Other artifacts containing the needed information are on the Domain I
following list. Remember that planning is iterative, so the team may use all these Task 5 Ensure adequate training
artifacts together to plan requirements while at the same time refining scope, is provided
schedule, and cost planning. These are artifacts of tasks in the Process domain: Task 6 Build a team
Task 8 Negotiate project agreements
• Scope baseline and activity list (see “Schedule” chapter).
• Work breakdown structure (WBS) Work package estimates are created PMBOK” Guide
while planning scope. Domain 2.4 Planning
• Network diagram Activities are shown in the network diagram (see the
“Schedule” chapter).
• Activity attributes These provide specific information about each activity, like the type and quantity of resources
expected to be needed to complete those activities.
• Cost estimates These provide resource estimating constraints since resource costs must fall within the cost baseline.
• Resource calendars Also related to Schedule Management, these identify organizational work hours and company
holidays, thus helping to show the availability of potential resources.
• Organizational process assets Established policies and procedures are always considered when arranging for staff
and needed equipment.
Methods for Estimating Resource Requirements

Estimating techniques are discussed in the “Schedule” and “Budget and Resources” chapters. Several of those techniques,
such as analogous estimating, may also be used to estimate activity resources. Here are some other methods to know for
the exam about estimating resources.
Resource Histograms and Resource Leveling

Resource histograms and resource leveling are methods for the “what if” analysis to refine estimates and ensure resources
are available when they are needed, and not when they are not needed.
Resource Histograms This tool provides a method for visualizing resource requirements and comparing required
resources to their availability to better enable estimating. Figure 6.5 shows a resource histogram (a bar chart) illustrating
the number of resources needed per time period. It allows a project manager to easily see where there is a spike in the need
for resources. If the people are not available when they are needed, the project manager must evaluate available options,
which may include:
• Negotiating with another department to provide resources
• Procuring the resources from an external source
• Adjusting the schedule to do the work when the resources are available
Project Time Period

FIGURE 6.5 Resource histogram
Resource Leveling This technique maybe used to change a project to minimize the peaks and valleys of resource usage
(level the resources). A resource histogram can also be used to help perform that task.
Artifacts of Estimate Resource Requirements

After estimating resource requirements the project manager and the team will have determined requirements for project
activities, including cost, quantity, and availability of team members. Remember from figure 6.4, the requirements may be
documented in a resource breakdown structure (RBS), so this artifact will have undergone another iteration.
I 54
6.2 Exercise
In the below table, identify which activities are involved in Estimate Activity Resources. Here or in your Exercise
Notebook write “ Y” if the described action is part of the Estimate Activity Resources process. If it’s not, write “N.”
Action: Is it part of Estimate Activity Resources? (Y/N)

1. Review project management plan.
2. Review scope baseline.
3. Review resource availability.
4. Review cost estimates.
5. Get one time estimate per activity.
6. Complete an analysis of the reserves needed on the project.
7. Create a company calendar identifying working and nonworking days.
8. Create milestones.
9. Review the WBS, activity list, and activity attributes.
10. Review the risk register and assumption log.
11. Identify potentially available resources and their skill levels.
12. Review historical information about the use of resources on similar projects.
13. Review organizational policies on resource use.
14. See how leads and lags affect the time estimate.
15. Solicit expert judgment on what resources are needed and available.
16. Create bottom-up, analogous, or parametric estimates.
17. Analyze alternative equipment or methods to use in completing the work and approaches to better
utilize resources.
18. Show network dependencies per activity.
19. Identify areas of the project that cannot be completed internally or would otherwise be more efficiently
achieved through outsourcing. This information will be shared with the procurement department.
20. Crash the project.
21. Break the activity down further if the activity is too complex to estimate resources
(bottom-up estimating).
22. Quantify resource requirements by activity.
23. Create a hierarchical image that organizes the planned resources by their category and type (a resource
breakdown structure).
24. Fast track the project.
25. Develop the schedule.
26. Develop a plan as to what types of resources will be used.
27. Update project documents.
155
Answer
Action: Is it part of Estimate Activity Resources? (Y/N)

1. Y 7. N 13. Y 19. Y 25. N
2. Y 8. N 14. N 20. N 26. Y
3. Y 9. Y 15. Y 21. Y 27. Y
4. Y 10. Y 16. Y 22. Y
5. N 11. Y 17. Y 23. Y
6. N 12. Y 18. N 24. N
Acquire (and Release) Resources

The sidebar tells you that once again we have mapped Acquire Resources from the Process Groups Model
Process Groups model to all tasks in the People domain. In predictive environments PG: Executing
this process describes how people join the project at the times needed to complete Process: Acquire Resources
their work. While this process is called “Acquire Resources,” releasing people from the
project happens throughout it as they finish their work. As the project manager on ECO
boards new team members, works with them, and releases them from the project the Domain I
project manager is indeed combining all tasks associated with the People domain. All Tasks
Notice that in the Process Groups model this is an executing process. It involves PMBOK® Guide
following the resource management plan to secure people as they are needed. Ihe
Domain 2.2 Team
resource requirements documentation tells the project manager what types of team
members are needed, and the resource management plan describes from where team
Domain 2.6 Delivery
members will come (from within the organization or as contractors, for example).
The schedule and cost baselines provide essential information regarding when
different team members will be required and the amount of funds budgeted to pay for them.
To understand why this is an executing process, think of a large project that may last a very long time, require a
hundred or more people and lots of physical resources.
• A planning team is acquired early in the project to help the project manager.
• Many of the people needed for the work may not be needed until long after the project starts.
• The final team list might include contractors, sellers, and people who will work on the project far into the future and
may not even be employed by the company until needed.
• Over time people and physical resources will enter and leave the project as their associated work is needed.
The project manager will also use the resource requirements documentation as a reference in acquiring physical
resources. Often this involves working with the procurement or inventory management department.
As mentioned earlier when resource calendars and resource leveling was discussed, resource availability is coordinated
to ensure that the right resources will be available when they are required.
To review, acquiring project resources includes all the following:
• Knowing which resources are preassigned to the project and confirming their availability
• Negotiating for the best possible resources
• Hiring new employees
• Hiring resources through the contracting process from outside the performing organization (outsourcing)
• Using JIT, Lean, or other methods as required by the organization
• Managing the risk of resources becoming unavailable ■v
Agile Teams
An agile environment looks a little different from the predictive environment described in the Acquire
Resources process. Here is how it typically works. Agile teams:
• Are stable They work together over time, and projects are brought to the team, not the other way
around. This practice takes advantage of time and effort taken to bring a team to the level of high performance. Team
members are on the project together from start to finish, so the scenario describing acquiring and releasing resources
throughout the project does not apply.
• Are relatively small They include about 8-12 people. Although this range may vary slightly depending on what
source you consult, it is a good rule of thumb to describe team size. Agile projects are typically smaller than their plan-
driven counterparts, and although they can be very large, the exam does not test agile on a large scale.
• Have all needed team members An agile team typically includes the project manager (for the exam, a role akin to
an agile coach or Scrum Master), product owner, product developers, and testers.
Hybrid Environments
On a hybrid project it is not unusual to plan the overall project using predictive methods and then build the product
features using iterative and incremental (agile) methods. Variations on these approaches depend on the project and the
business environment.
Types of Team Configurations

The makeup of the final project team can take one or a combination the following:
Dedicated Teams Most of the team members work full-time and exclusively on the project. Team members can dedicate
most of their energy to the project and often report directly to the project manager. In a predictive environment, these are
most common in projectized organizations, but can also be found in matrix organizations. They’re least likely to exist in
functional organizations.
Part-time Team Members Team members and the project manager spend a portion of their time working on the project
while also working on other projects and/or their operations-related work responsibilities. Part-time teams are most often
seen in functional and matrix organizations.
Partnerships In cases where several organizations undertake a project, the teams are likely to consist of people from each
of the participating organizations, plus the project manager from the organization taking the lead on the project. Such
teams may offer advantages, such as cost savings, but team management and communication can be more difficult.
Virtual Teams Geographic distance necessitates the use of virtual teams, and technology can help with virtual team
communication (see the “Communications” chapter). Advantages of virtual teams are that the project manager can
negotiate for the best resources needed without regard to location and, increasingly, people see working virtually as a
personal value added.
Pre-assigned Team Members As noted earlier, sometimes resources are assigned before the project begins. Preassigned
resources are listed in the project charter.
Agile Team Structures Remember that dedicated teams are important on rapidly changing agile projects.
In these environments, more information is communicated face-to-face and tacit knowledge is more valuable.
Agile organizations also try to avoid virtual teams where possible. Technology helps agile teams work
virtually, but face-to-face communication is always preferred.
157
For the exam, be aware how the type of team described in a situational question could impact the project
TRICKS
OF THE manager s work. For example, the project manager will have more rapport with a dedicated team. With a part-
TRADE time team, the project manager will likely have to negotiate with functional managers and organizational
I leadership to acquire and retain team members. With a partnership or virtual team, coordination among the
various organizations or locations might require increased risk management work, more effort to coordinate
communication, and so on.
Negotiating for Resources We mainly reference negotiation in this book in two contexts: procurement and onboarding
internal resources. If people need to be hired or contracted, the project manager may need to work with the human resource
or procurement departments. This section covers negotiating for internal resources, which are always constrained. To
negotiate for team members from within the organization, the project manager should do the following with each
resource manager:
• Know the needs of the project.
• Know the projects priority in the organizations initiatives.
• Be able to express how the resource manager will benefit from assisting the project manager.
• Understand that each resource manager has their own priorities and supporting the project may not be of direct
benefit to them.
• Do not ask for the best resources if the project does not need them.
• Be able to prove, using artifacts like the network diagram and project schedule, why the project requires the stated
quantity and quality of resources.
• Try to discover what the resource manager may need.
• Be open to finding creative ways to help the resource manager meet their own resource needs.
• Build relationships in order to call on the expertise of the resource manager later in the project as necessary.
• Work with the resource manager to deal with situations as they arise.
Methods for Acquiring Resources

There are several methods for acquiring resources. Here are the main ones to know for the exam.
• Multicriteria decision analysis
• Interpersonal and team skills
• Pre-assignment
• Virtual teams
The project manager may establish a set of criteria to help choose potential team members. Factors that address the
needs of the project, such as availability, cost, experience, location, and/or a required skill set, are weighted by importance,
and the project manager evaluates potential team members based on the selected criteria.
Pre-assignment
Sometimes resources are assigned before the project begins. Preassigned resources are documented in the project charter.
Beware, however, of the halo effect.
Halo Effect Project managers (and managers in general) have a tendency to rate team members high or low on all criteria
due to the impression of a high or low rating on one specific criterion.
Example A project manager might say to a team member who is a great programmer: ”We are making you a leader
of a programming team for the project and think you will be great at that.” Since a person who is a great programmer may
in fact, be neither qualified nor want to be a team leader, such assumptions may have negative impacts on the project
schedule, cost, quality, and team morale.
I 58
Artifacts of Acquire Resources

Outputs from the Acquire Resources process are:
• Resource assignments
• Resource calendars showing the planned utilization and availability of resources
• Project management plan updates:
V Resource management plan
>/ Cost baseline
• Project document updates:
■/ Lessons learned, risk register, resource requirements
>/ Resource breakdown structure (RBS), stakeholder register, project schedule
Think About It. Take a look at the list of outputs from Aquire Resources again. For exam questions, you will
need to understand these intuitively, but to also quickly know, “Where am I in the project management process?”
Example If a scenario describes adjusting a plan and uses future tense (like “adjusting the plan that will be
used...”) without mentioning integrated change control, is it an agile project? If it is not an agile project, then
you are probably in planning and should pick an answer related to planning.
Here are things to remember about what you have from (outputs of) the Acquire Resources process:
• If decisions made in this process require changes to approved management plans or project documents, change
requests are submitted to integrated change control. Affected documents and plans may include any of the plans or
baselines within the project management plan.
• The resource management plan may be changed based on the project experience to date. For example, the plan to
acquire future team members may need to be adjusted if it doesn’t work as expected.
• The project schedule may need to be adjusted to accommodate the availability of people with specific expertise
needed by the project. The cost baseline may be impacted if hourly rates are different from what was estimated.
• Project documents need to be updated or changed, with new team members added or information changed in the
stakeholder register. The resource breakdown structure is iterated to include specific information about people that
have been committed to the project.
• Newly identified risks related to human resources are added to the risk register, reviewed, and analyzed. For example,
a person with unique qualifications could be called away during the project.
• Resource requirements, including the type, quantity, and skill level may change.
• There are usually lessons learned to be captured, integrated into the project for future work, and shared with
the organization.
Develop Team
Models for human development and motivation were discussed in the previous, Process Groups Model
“Leadership Skills” chapter. Again here, all the People domain skills are also needed. PG: Executing
The Develop Team process involves the work to lead, empower, and motivate the Process: Develop Team
team to achieve high performance levels in meeting project objectives.
Apian for making all this happen should be included in the resource management ECO
plan. And the project manager will need to make use of lessons learned earlier in the Domain 1
All Tasks
project and on other, similar projects. Before continuing, go back to the “Leadership
Skills” chapter and review the models there. They are useful for distilling complicated PMBOIC Guide
human interaction into understandable common experiences.
Domain 2.2 Team
Domain 2.6 Delivery
159
Methods for the Developing Team Process

Here are the methods for developing a team:
• Colocation Training
• Virtual teams Individual and team assessments
• Interpersonal and team skills y Individual assessments
Team building y Team assessments
y Conflict management y Hybrid assessments
Influencing y Project performance appraisals
>/ Motivation y Key performance indicators (KPIs)
y Negotiation Communications technology for virtual teams
• Recognition and rewards
Team Building
Team building can play a major role in team development—helping to form the project team into a cohesive group working
for the best interests of the project and enhancing project performance. Strong teams will result when you know the
following key points:
• It is the project manager s job to guide, manage, and improve the interactions of team members.
• The project manager should work to improve trust and cohesiveness among the team members.
• The project manager should make sure that the project vision is clear, and continuously communicate that vision.
• The project manager needs to ensure that roles and responsibilities are clearly defined.
• The project manager should incorporate team-building activities into project activities.
• Team building requires a concerted effort and continued attention throughout the life of the project.
• Team building should start early in the life of the project.
Project managers who feel they do not have time for team building typically are not using project management best
practices on their projects. Practices such as properly planning a project and managing risks and quality save significant
amounts of time on a project, freeing up the project manager to do other important things, like team-building activities.
When you take the exam, assume the project manager featured in the questions has a team-building plan appropriate to the
size and characteristics of the team.
Team-building activities can include the following:
• Involving team members in planning the project, including creating the WBS or backlog as a group
• Taking classes together
• Retrospectives by the team to evaluate and improve their processes and interactions
• Collaborative problem-solving
• Milestone parties
• Holiday and birthday celebrations
• Skills assessments and development
Team Culture
The project manager plays an important role in developing a positive team culture. While human beings are complex and
will create their own habits and relationships, the project manager can lead by example to create a positive work
environment. Here are some of the ways this can be done:
• Transparency • Support
• Integrity • Courage
• Respect • Celebrating successes
• Positive interactions
MO
The more a project manager works to display the actions they want to see from team members, the more successful
the leader, the team members, and the project will be. All these traits also lend to a safe and open environment where
people feel comfortable to voice opinions, bring up issues, and solve any problems as a cohesive team.
Colocation
A project manager might try to arrange for the entire team in each city to have offices together in one place or one room.
This is called colocation, and it helps improve communication, decreases the impact of conflict (since all parties are right
there), and improves project identity for the project team and for management in a matrix organization. The project
charter, work breakdown structure (WBS), network diagram, and schedule may be posted on the walls to keep everyone
focused on the work of the project. Adaptive development approaches encourage colocation.
Virtual Teams
Not all teams meet face-to-face. Virtual teams have to rely on other forms of communication to work together. Although
virtual teams can be more challenging to manage because of communication issues and differences in schedules, languages,
and/or culture, they offer the opportunity to benefit from the expertise of team members who are in distant locations or
who are otherwise unavailable to participate with the team onsite.
The challenge for virtual teams is finding ways to create “virtual colocation”—in other words, replicate the benefits of
face-to-face collaboration, osmotic communication, tacit knowledge, and improved relationships that come from working
near each other. Fortunately, the same tools making virtual teams more common also provide ways to simulate the benefits
of face-to-face collaboration. Let’s look at some examples.
Videoconferencing and Live Chat These tools can be used to simulate a shared team environment and allow virtual
stakeholders to chat and interact as if their colleagues were within earshot.
Interactive Whiteboards These tools allow team members to share content with multiple locations and collaborate in a
visual whiteboard-type environment.
Instant Messaging (IM) Instant messaging allows people halfway around the world to communicate instantaneously
with ease.
Presence-based Applications These applications extend IM capabilities by managing the status of participants to create
a virtual office environment for sharing information.
Virtual Kanban Boards These allow for the use of a Kanban board with a virtual team. Kanban boards are discussed in
the “Communications” chapter.
There may be questions on the exam that:

• Ask why virtual teams might be necessary
• Describe situations that involve acquiring and managing virtual teams.
• Describe a situation in which choosing the correct answer depends on your understanding that a virtual team might
require a different approach than a colocated team.
Individual and Team Assessments

The best assessments are only useful if we put them to work to improve performance. Here are some practices through
which the project manager can help the team to develop into and remain a high-performing team.
Individual Assessments The more the project manager knows about each person on the project team, the easier it is to
build trust, improve team communication, and encourage cooperation among team members. Personnel assessment tools
can help the project manager learn more about team members by revealing how they make decisions, interact with others,
and process information. This information can provide insight into how to lead and guide the team. Formal and informal
assessment of team members by the project manager should continue throughout the project.
Team Assessments The project manager completes formal and informal team performance assessments as part of
developing the project team. These assessments are meant to evaluate and enhance the effectiveness of the team as a whole.
They may include an analysis of how much team members’ skills have improved over the course of the project; how well
the team is performing, interacting, and dealing with conflict; and how they are progressing through the stages of team
development. The assessments also help identify needed support or intervention by the project manager. Such assessments
should be ongoing while project work is being done. The results of team assessments can be used to recognize the team’s
progress or to motivate them to improve. Think of team performance assessment as looking at team effectiveness. The
results of these assessments are also inputs to the Manage Team process, in which the project manager uses them to address
issues identified.
Hybrid Assessments One way to assess individual team members is to designate them as I-shaped or T-shaped. More
information about these types is in the “Leadership Skills” chapter.
Project Performance Appraisals

Project performance appraisals are evaluations of individual team member performance. In this effort, the project manager
collects information from team members’ supervisors and adjusts the project accordingly. It’s also important to understand
that an appraisal might bring to the project manager s attention the need to provide additional training or encouragement
to a team member. Note that the focus of this appraisal is on the individual’s performance of their assigned responsibilities,
rather than on team performance.
Because the Develop Team and Manage Team processes are performed at the same time, it is sometimes difficult to
determine what happens in which process. For example, did you know project performance appraisals are performed as
part of Manage Team, while the rewards and additional training indicated by the results of those appraisals are given as part
of Develop Team?
Key Performance Indicators

Key Performance Indicators (KPIs) are measures used to review project performance. Project managers use KPIs to assess
their team’s performance and help plan the project as it is ongoing. This is conceptually related to earned value measurement
(EVM) for baseline performance (also called earned value analysis or EVA), which is covered in the “Budget and Resources”
chapter.
KPIs can be used to estimate the cost of the project at a given time. The following uses an agile focus as
an example but this can be done on any project.
• Rate of progress How many user stories and features is the product owner accepting per time period?
• Remaining work How much work is left to complete?
• Likely completion date This is the remaining work left to complete, divided by the current rate of progress. For
example, the number of user stories (times their story point numbers) divided by the team’s current velocity.
• Likely costs remaining This could be a simple salary rate for the team multiplied by the remaining weeks. On
traditional or more complex projects this is likely to be a more comprehensive costing calculated to include personnel
as well as equipment and other contracted costs.
6.3 Exercise
In your Exercise Notebook, write down the answer to this question: What does a project manager need to do to
develop a team? Before looking at the answer, write down all you can think of for developing the team. The exam
will emphasize your understanding of the interpersonal and team skills needed to be a good project manager.
M2
Answer
You may do some of the activities listed below on your projects, even if you may not plan them formally or
consistently. Keep them in mind for the exam to help you understand the situations described and select the best
answer choices. The project manager must ensure the team is working together as effectively and efficiently
as possible.
Checklist: Developing the Team

□ Use soft skills, such as mentoring, leadership, negotiation, influencing, and openness.
□ Seek to empathize, and practice active listening.
□ Encourage teamwork. Lead by example. Be a project leader, but be a peer, too.
□ Communicate honestly, effectively, and in a timely manner.
□ Assess and act in harmony with team members’ strengths and weaknesses, learning styles, and preferences.
□ Establish and maintain trust among team members and all stakeholders.
□ Collaborate to create a shared vision.
□ Use participatory decision-making where possible; work to find mutually beneficial solutions to issues.
□ Embrace cultural differences and capitalize on them for enriching team life.
□ Hold team-building activities.
□ Help foster a sense of team identity.
□ Set realistic goals.
□ Provide training for team members as needed.
□ Support the upholding of agreements made with the team charter.
□ Allow team members to resolve conflict on their own but assist with resolution when needed.
□ Make the environment one full of recognition and rewards.
□ Co-locate the team if possible; work hard to support virtual teams.
□ Facilitate team communication.
□ Evaluate and work to improve team performance; be creative and also get team involvement.
Artifacts of Develop Team

The outputs of the Develop Team process include:
• Results of assessments • Organizational process asset updates

• Change requests ■/ Training requirements changes
• Updated project documents >/ Newly adopted team-building exercises
>/ Team charter
• Revisions to existing templates for assessments
-/ Lessons learned
■/ Schedule
-/ Assignments and resource calendars
These results are direct inputs to the Manage Team process, the subject of the next section. Remember that they
provide insight for the project manager toward continuous improvement of performance. If the project manager determines
changes to plan documents affecting the performance measurement baseline are needed, they must process these through
integrated change control.
M3
Manage Team
Manage Team involves the day-to-day management activities that you’re likely al- Process Groups Model
ready doing on projects, and you are probably very good at it. But it is important to PG: Executing
solidify your knowledge from an exam perspective. Process: Manage Team
First, we have our updated project management plan and documents from all
other processes, not least of which is Develop Team. Details related to team- ECO
management activities are included in the resource management plan. Aside from Domain 1
All Tasks
those artifacts listed for the process of developing the team, other things that go into
this maybe the: PMBOfC Guide
• Issue log Domain 2.2 Team
• Project team assignments (possibly documented in a RACI chart) Domain 2.5 Project Work
• Team charter Domain 2.6 Delivery
• Work performance reports
The work performance reports provide an indication of project progress as compared to the project management
plan. lhis information is used to identify necessary corrective actions. The project manager analyzes results from
performance assessments to identify successes that need to be recognized, areas in which the team may need additional
support or assistance, and issues or conflicts that need to be resolved in this process. Team members are also released as
their work is completed.
Here are some reminders of what to do during the Manage Team process, to help team members sustain
high performance:
• Observe what is happening • Look for conflicts team members cannot resolve on
• Track and evaluate team performance their own
• Provide leadership * Facilitate conflict resolution
• Mentor team members * Negotiate and influence
• Plan and facilitate career development * Adjust plans based on performance data
• Deal with team issues • Manage risks to team success
• Use an issue log to track resolution
Methods for Managing the Team

Interpersonal and team skills are a primary method of managing the team, including conflict resolution, emotional
intelligence, leadership, and influencing. Part of supporting a high-performing team is assessing how each team member is
fulfilling their responsibilities. Project performance appraisals and progress tracking provide this information on individual
team members. Earned value measurement (EVM), discussed in the “Budget and Resources” chapter, reflects how the
project is progressing relative to planned progression. This is a window into how the team is performing (as well as whether
the plan needs to change).
Burndown and burnup charts are used on an agile project to track team performance. These charts can
be part of the information radiators.
Burndown Charts
Burndown charts track work to be done on a project. As work is completed, the progress line on the chart will move
downward, reflecting the amount of work that still needs to be done. They are commonly used to measure the team’s
progress in completing the project work. A sample burndown chart is shown in figure 6.6.
Burnup Charts
Burnup charts track the work that has been completed. Therefore, over the course of the project, the progress line on a
burnup chart will move upward, showing the increasing amount of work that has been completed. The big advantage of
using a burnup chart is that it can show changes in scope, making the impact of those changes visible. A sample burnup
chart is shown in figure 6.6.
I'M
Note: Keep in mind that this is also a very important tool for controlling scope, schedule, and cost. Rather than
repeating the information in each of those chapters, it will be cross-referenced from this chapter.
XYZ Project - Estimated Effort Remaining
FIGURE 6.6 Burndown chart (left); burnup chart (right)
Every project is different and presents unique challenges to the project manager. Factors such as the size and makeup
of the team, the experience level of the team, and the complexity of the actual project work must be considered by the
project manager in their efforts to get the best from the team.
Think About It. If you were an observer of your project management work, what would you see? Do you tend
to busy yourself with reports rather than really seeing what the team is doing, how team members are interacting,
what they feel is missing or doesn’t work, and what may be generating problems? Whether your team is colocated
or virtual, paying attention to the tone of interactions, including emails and phone conversations will tell you
more about what is going on than simply analyzing data. A project manager should observe what is happening
and talk to people to understand how things are going.
Artifacts of Manage Team

The outputs of the Manage Team process include:
• Updated project document
Issue log
Lessons learned
• Enterprise environmental factors like human resources evaluation systems
• Organizational process assets like human resources appraisal templates
• Change requests (resource needs, costs, schedule or any part of the project management plan)
Plans for releasing team members are included in the resource management plan. Because the length and focus of
assigned work varies, team members may be released at different times throughout the project, as their work is completed.
Issue Log
Many project managers use issue logs, also known as issue registers or action item logs, to record problems and their
resolutions. Because it is updated to reflect new issues as well as the resolution of issues, it is frequently an input and an
output of the same processes.
As part of managing team members and stakeholders, the issue log can be used to communicate about issues on the
project. It facilitates the assessment of the causes of issues, the impact of issues on scope, schedule, cost, risk, and other
aspects of the project, and the recommendation of corrective actions that could be taken. Such a log indicates to people
that their needs will be considered, even if they are not addressed at the time the issue arises. Effective project managers
control issues so they do not impact the project. The issue log is updated as part of project documents updates throughout
the project.
M5
An issue log might look like the one shown here.
Date Raised Person Resolution Date

Issue # Issue Added By Assigned Due Date Status Resolved Resolution
FIGURE 6.7 Issue log
An issue log should be customized to meet the needs of the people who will be using it. For example, an issue log
could include more detail—such as a description or the category of the issue (such as team, schedule, or technical)—as
preferred by the team.

Be diligent when you study this and the previous chapter. Many students think this is an easy topic and do not study
enough. For the exam, you should know the different motivational theories, management styles, understand servant lead
ership, emotional intelligence, and how to manage conflict.
Review the QuickTest to make sure you understand these concepts and that you don’t have any gaps in your
knowledge. Then complete this exercise.
6.4 Exercise
For each Resource Management process, give an example of the work the project manager on the library project
should perform. Write the answers in your Exercise Notebook.
Resources Process
1. Plan resource management
2. Estimate activity resources
3. Acquire team
4. Develop team
5. Manage team
M6
Answer
Did you come up with some of these? You may have identified some other examples.
Resources Process Example of work

1. Plan resource management Since the city has few employees available to help with the project, the project
manager will identify companies who can provide the needed talent to the team.
2. Estimate activity resources The project manager requested public records for the last two libraries built in
the same county as this one to research the time and costs used.
3. Acquire team The project manager used past library construction records to list the skills
needed for the team. These skills were provided to the outsourcing companies.
Resumes were reviewed for matches to the needed skills. The head librarian
assisted with evaluating potential workers.
4. Develop team Schedule training in cyber security for the IT team.
5. Manage team Bi-weekly meetings with key team members are scheduled to check on progress
and outstanding issues.
The following exercise tests your knowledge of some typical roles on a project. Do you remember the discussion on
project roles in the “Project Management Foundations” chapter? Your understanding of that content will impact how well
you do on this exercise. You may want to review those pages before starting this exercise, or use the information in that
chapter to fill your gaps.
M7
6.5 Exercise
Here or in your Exercise Notebook, write the initials of the key role responsible for solving each of the issues listed.
Because much of the confusion for students is between roles of team members (T), the project manager (PM), the
sponsor (SP), and the functional manager (FM), this exercise is limited to those roles.
Consider what you have learned about project roles and remember to keep matrix organizations in mind when
reading through these situations.
Situation
1. Two project team members are having a disagreement.
2. There is a change to the overall project deliverable.
3. A functional manager is trying to pull a team member off the project to do other work.
4. The project manager does not have the authority to get things done.
5. There are not enough resources to complete the project.
6. The team is unsure of what needs to happen when.
7. An activity needs more time and will cause the project to be delayed.
8. An activity needs more time without causing the project to be delayed.
9. A team member is not performing.
10. The team is not sure who is in charge of the project.
11. There is talk that the project may no longer be needed.
12. The sponsor provides an unrealistic schedule objective.
13. The team is in conflict over priorities between activities.
14. The project is behind schedule.
15. A team member decides another method should be used to complete their activity.
16. The project is running out of funds.
17. Additional work that will increase cost (not identified during the risk management process)
is added to the project.
M8
Answer
This exercise is designed to help you answer situational questions on the exam dealing with roles and responsibilities.
If you disagree with some of the answers, make sure you are not reading something into the question, and assess
whether it indicates a gap in your project management knowledge.
Make sure you have a clear understanding of how stakeholder, communications, and human resource management
relate to each other. This will help you answer questions correctly on the exam.
Role Explanation
1. T People involved in a conflict should attempt to resolve it themselves.
A change to the overall deliverable is a change to the charter. Only the sponsor can approve
2. SP
changes to the project charter.
Assume project management is done right (unless an exam question tells you otherwise). The
project manager gives team members enough information (e.g., schedule, network diagram,
project management plan, identified risks) so they can manage their own workloads. The word
3. T
“trying” denotes this situation is occurring in the present. If it said “has pulled,” the answer
would be the project manager.
Read situational questions carefully.
4. SP It is the sponsors role to give the project manager authority via the project charter.
5. SP/FM The sponsor and functional manager control resources.
The project manager takes individual time estimates, combines them into the project schedule,
6. PM
and communicates that schedule to the team.
The project completion date is most likely in the project charter. Notice the word “will.” This
7. SP means the evaluation by the team is completed and there is no available reserve. Any such
changes are changes to the project charter and require sponsor involvement.
It is the project manager s role to look for impacts to the other project constraints. (Think
8. PM about integrated change control here. It may need to be used but we don’t know since the
indication is that the schedule baseline is not to be affected.)
The project manager (and the team member s functional manager) share responsibility for
9. PM/FM
directing resources.
10. SP The sponsor designates the project manager in the project charter.
The sponsor protects the project from a large change like termination. If it becomes clear that
11. SP
the project will not meet organizational objectives the sponsor will authorize termination.
Only the sponsor can make a change to the charter (including a schedule constraint). The
12. PM/SP project manager must provide evidence that it is unrealistic and work with the sponsor to
resolve it.
It is the project manager s role to settle such conflicts (and ensure a network diagram and
13. PM
critical path are established).
14. PM The project manager is responsible to control the overall project schedule.
A team member has control over their activities as long as they meet time, quality, cost, and
scope objectives in the project management plan. The team member must keep the project
15. T
manager informed of method changes, however. As appropriate, the project manager can
integrate method changes into the project and look for unintended impacts.
16. SP It is the sponsor s role to provide funding for the project.
Additional work not identified in the risk management process means it was not included in
17. SP the original project budget (or contingency reserve). The sponsor must be involved in
providing additional funds.
M9
150
Section IV
Domain II: Process
The Examination Content Outline (ECO) specifies that Domain II covers 50% of the exam. The Process domain includes
the technical project management skills, methods, and the activities needed to manage a project and deliver the benefits
for which the project was undertaken. In this section, you’ll find the following chapters:
• Scope • Communications
• Schedule • Risks and Issues
• Budget and Resources • Procurement
• Quality of Deliverables and Products • Stakeholders
Managing project governance, artifacts, issues, changes, the use and transfer of lessons learned, and product turnover to
operations are also part of this domain.
152
QUICKTEST
• Product Scope
Scope •
•
•
Project Scope
Timeboxing
Minimal viable product
(MVP)
• Scope Management
process
Introduction • Scope management plan
• Requirements
You already know that a project must, from start to finish, help to achieve the goals and objectives for management plan
which it was selected. Eliciting and analyzing requirements, defining project and product scope, and • Product roadmap
• Product backlog
then building and delivering that scope in accordance with those requirements are all at the heart of
• Requirements elicitation
this value delivery system.
methods
The goals for delivering project scope are the same regardless of the project life cycle and delivery - Brainstorming
approach. When managing scope, a project manager must define what work is required and then - Interviewing
ensure all that work—and only that work—is completed. This is generally an easy topic, but we all - Focus groups
have gaps in our knowledge. Be sure to review the Quicktest and make note of your gaps so you can pay - Questionnairesand
particular attention to those sections in this chapter. surveys
- Voting
In addition to reviewing the Quicktest, see if the following list helps you uncover gaps in your
- Multicriteria decision
knowledge. analysis
- Nominal group
Things to Know about Scope Management for the Exam technique
• The project manager must plan how they will determine the scope, as well as how they - Observation
- Prototyping
will manage and control scope. This is part of the scope management plan.
- Facilitation
• Scope must be clearly defined and formally approved before work starts. If using an - Mind maps
adaptive approach, this may be done at a higher level with a summarized agreement. - Context diagrams
- Affinity diagrams
• Requirements are elicited from all stakeholders, not just the person who assigned
• Balancing requirements
the project.
• Iteration reviews
• Requirements elicitation can take a substantial amount of time, especially on • Acceptance criteria
large projects. • Definition of done
• Requirements traceability
• Requirements must be evaluated against the business case, ranked, and prioritized to
matrix
determine what is in and out of scope. • Product analysis
• A work breakdown structure (WBS) is utilized on all projects that use a predictive • Project scope statement
• Work breakdown
approach. Using this tool enables the project manager to clarify identified scope as well
structure (WBS)
as find additional scope.
• WBS dictionary
• A backlog, an agile alternative to a traditional WBS, may be utilized on projects using • Scope baseline
adaptive approaches. A backlog creates visibility into the scope as well as the overall • Agile scope
priorities of the project because a backlog is ranked in priority order. decomposition
• Inspection
• While the project is being completed, the project manager must check to make sure all • Customer-valued
the work included in the project management plan is being done—and only that work. prioritization
• Gold plating a project (adding extras) is not allowed. • Incremental product
delivery
• Any change to scope must be evaluated for its effect on schedule, cost, risk, quality,
resources, and customer satisfaction.
• On plan-driven projects, changes to scope require approval; scope changes should not
be approved if they relate to work that does not fit within the project charter.
• Scope priorities and changes are more flexible on agile projects where work is planned
and completed iteratively and incrementally, but change is not free. This means that
when scope is added, the backlog is reprioritized and earlier prioritized items move
below the new scope that has been added. It is possible that some scope on the bottom
of the backlog will be pushed to another release or another project to preserve cost and
schedule baselines.
153
Scope SEVEN
• Hie project manager and the project team should continuously determine what is and is not included in the
project scope.
• Internal verification followed by customer acceptance of deliverables happens throughout the project.
Definitions Related to Scope Management

It’s important to understand the distinction between product scope and project scope. Those definitions follow, along with
a few more definitions we want to start you off with for understanding the chapter content.
Product Scope
Product scope can be defined as the product deliverables with their associated features and functions. Another way to say
this is: The requirements that relate to the product, service, or result of the project is the product scope. It answers the
question, “What end result is needed?” There maybe a separate, preliminary project to determine product scope, or the
requirements may be defined as part of the project, depending on the needs of the project and the organization.
Example Let’s say the project is to build a new train terminal. The product scope is “a train terminal that meets these
technical specifications.” The technical specifications would be complex and comprehensive as defined by qualified subject
matter experts. To determine if the project successfully achieved the product scope, the new train terminal is compared to
the specifications, which were recorded in the requirements documentation and the project scope statement for the
project. All aspects of the train station would need to be tested to ensure they work according to plan before the train
station is accepted as complete and turned over to operations.
Project Scope
The project scope is the work the project team will do to deliver the product scope. It includes the product scope. For the
train terminal example, the project scope would be “a train terminal that meets these technical specifications,” plus the
management and delivery of all the work to deliver the train terminal. In other words, project scope includes the planning,
coordination, and management activities that ensure the product scope is achieved. These efforts become part of the scope
baseline and scope management plan, which are parts of the project management plan.
Iteration
On agile projects, this is a specifically set period of time during which a project team refines plans or builds
the product of the project. In the context of planning, plans are iterated and refined as new information
becomes available. In the context of scope, the team builds the product in increments during fixed periods of
time called iterations (or sprints, in Scrum). Iterations are set in specific “timeboxes.” (See timeboxing next.)
Timeboxing
For an agile project a timebox is a short, fixed period of time set for the team to complete a selected and prioritized set of
activities. In the context of scope this can translate as the completion of a specific set of stories during a two-week iteration
(or sprint), for example. If the work planned for the iteration isn’t complete within the two-week iteration, the team leaves
the uncompleted work on the backlog to be undertaken during another iteration. So it is the timebox (the iteration) that is
honored. There is no “complete all the stories no matter how long it takes” approach.
Minimal Viable Product (Minimal Marketable Feature or MMF)

The term “MVP,” or minimal viable product, refers in agile to an increment of product that is at least useful enough that the
customer can potentially take delivery of the MVP and use it while the team continues to build the rest of the product. We
say “potentially” here because while the team can show the customer the MVP, the customer can sign off on it and accept
delivery of it and use it. Alternatively, the customer can accept it, sign off on it, and wait for additional MVPs to be added
before taking delivery. These valuable but partially completed products are also known as minimal marketable features, or
MMFs. A product release will typically have several MMFs integrated together, but what is included is up to the customer.
Example The customer could take delivery of a skateboard that has the potential to be electric. They could then use
it without the electric components, and have it upgraded once the electrical features are ready. They could later decide if
they want the already available handles, which are optional, but while they are waiting for the team to build the electrical
components for installation, they have the value of using the skateboard in its basic form, its MVP.
1
SEVEN Scope
Scope Management Overview

For the exam, you need to understand the scope management process from the perspective of the Process Groups model
as well as from the perspective of an adaptive environment. You also need a solid understanding of how these models fit into
the concepts found in the Examination Content Outline (ECO) and the PMBOK* Guide.
The Examination Content Outline (ECO) and Process Groups Model

The ECO s Process domain shows a task called Plan and Manage Scope, which is analogous to the Process Groups model’s
Scope Management process. This is illustrated in the first two columns of the following chart.
Now, only one task is listed in the ECO column above. Does this mean that only “Plan and manage scope” in the ECO
is relevant to the Process Groups models planning and monitoring and controlling of scope, regardless of the project
attributes and the selected project life cycle? Of course not. It would help you to hold the ECO in your hands right now or
to have it open on your computer as you work through this section of the chapter. Thinking holistically, you may have
already identified that the ECO task, “plan and manage quality of products/deliverables” is intimately tied to managing
scope. The team also uses the schedule and budget to create the scope.
First, remember that many or all People domain skills are used to manage all project constraints, since the project
manager works with others to get things done. Now, review the following examples and skim through the ECO to think
about how these and other tasks fit together with the plan and manage scope task. Think about the ECO tasks holistically.
These are just a few examples of other ECO tasks helpful in managing scope:
• Scope management relies on the project manager s work to ensure that team members/stakeholders are adequately
trained (domain 1, task 5). Regardless of whether there are generalizing specialists for an agile project or specialist
team members for a plan-driven project, the project manager identifies what training is needed and provides it as part
of supporting team performance and addressing and removing impediments (People domain, tasks 4 and 7).
• Look at the ECO s Business Environment domain, task 2: Evaluate and deliver project benefits and value. This is
about balancing competing constraints, including cost, time, and quality in order to build product scope.
Requirements for the most part are defined early in a plan-driven project, while on an agile project it is understood
that scope emerges and more requirements gathering with stakeholders is necessary over time. Figure 7.1 is a visualization
of scope management at a high level from the Process Groups model perspective. It can help you visualize where you are
155
Scope SEVEN
in the scope management process as you continue with this chapter, and understanding it will help you on the exam as you
read scenario questions.
FIGURE 7.1 Scope management process
Plan-driven Scope Management

There are a lot of acceptable ways to manage scope. If you do it differently than described here, you are not necessarily
wrong. For the exam think of the scope management process as including the following for predictive project management:
1. A plan is developed for how to plan, validate, and control scope and requirements.
2. Determine requirements. Ensure they support the projects business case (as described in the project charter)—
the benefits and value the project is meant to deliver (Business Environment domain, task 2).
3. Analyze and balance stakeholder needs to determine scope.
4. Create a WBS to break the scope down to smaller, more manageable pieces. Define each piece in a WBS dictionary.
5. Obtain validation (signed acceptance) that the completed scope of work is acceptable to the customer or sponsor.
6. Measure scope performance and adjust as needed.
No one can request or add work that is not related to the reason for initiating the project. Yet, in your real world, do
people want work done and try to attach it to any project they can to get that work accomplished? Do you see scope on
projects that doesn’t support the company’s business objectives? It happens all the time. Change control is about protecting
the project from unapproved changes in a predictive environment.
When taking the exam, assume you have the authority in a predictive environment to say no when someone tries to
add unrelated scope to your project. This is important to internalize because so many of us do not have this authority in the
real world.
Note that in a predictive environment, creating a work breakdown structure (WBS) is a required part of project
management. If you have never created one or do not currently use a WBS on your projects, this chapter will help you
understand how beneficial this tool is and what it can do for you. Remember, the exam asks questions at an expert level and
assumes you have experience using various tools.
156
SEVEN Scope
Agile Scope Management

In adaptive environments, scope management looks like this:
1. Requirements are identified and documented at a sufficient level of detail so they can be prioritized Focus
and estimated at a high level.
2. The products features—collectively the product scope—are kept in a list called the product backlog.
3. The work is broken into product releases. A project may include one or more releases.
4. For each release, the work is completed through iterations (specifically defined periods of time, like two weeks, or
three weeks, for example).
5. The work of each iteration (and release) is defined successively in more detail just before the work for each iteration
begins. In this way, decisions are deferred to “the last responsible moment.”
Product scope is typically more flexible in agile projects than it is for plan-driven projects. As essential product
features are delivered in early agile releases, more optional features may be deferred.
Example You are buying a new, custom-made electric car. You travel a lot, so you want the front seats to recline into
beds so you can pull into a campground to sleep. Your budget doesn’t support these adaptive seats right now, but you need
the car right away. Neither your budget nor timeline support the self-driving features that will eventually allow you to nap
while the car drives autonomously on a long road trip. So the electric car company builds the basic car and delivers it
quickly in Release 1. Later, for another release, you return for installation of a few more custom features you have agreed
upon with the car builder. Eventually you will come back for the adaptive seats when the price goes down and you have the
money and time for their installation.
Early agile practitioners came from the software development industry. They were keenly aware that most
TRICKS software users actually use only a small percentage of the features of a given software package. So they thought
OF THE
why wait for the entire package to be built when the most valuable features can be used right away (while delivering
a large feature set is notoriously difficult to do on time) ? They recognized what became an agile tenet: a distinct
advantage of an adaptive environment is the value saved on the features not built. In other words, part of delivering value
I is deciding on what work is not done (immediately, or possibly ever).
In our example above, what if later you decided your car did not need seats that reclined into beds? You could cancel
that feature and just stay with the basic car. If you did decide to get that feature later though, the chances maybe good that
you will be buying an improved feature that has also become more economical.
Note: For a plan-driven project life cycle you will definitely need a WBS, while in a more change-driven life cycle you
may have a WBS, the product backlog may take its place, or you may have both. Look for evidence in exam questions that
tells you which type of life cycle you are dealing with.
Desired Outcomes of Scope Management

Assume for the exam that scope is properly planned and managed unless information in an exam question indicates
otherwise. This means that the following outcomes should be expected as a result of scope management:
• Throughout the project, the project team has a clear understanding of product and project requirements or they have
the ability to make those requirements clear through interactions with the project manager and stakeholders.
• Throughout the project, data are gathered and earned value measurement is performed to indicate project progress
relative to plan. This allows the team and stakeholders to best manage target results and make adjustments where
necessary. This may take the form of traditional earned value measurement for plan-driven projects (see the “Budget
and Resources” chapter). For agile projects, teams may use burnup and bumdown charts (see the “Build and Support
Performance” chapter).
• Project scope as agreed to by the performing organization and its stakeholders is delivered on time, within budget, and
with sufficient levels of quality, as agreed to with the customer.
• Scope can be readily controlled, verified internally, and validated with the customer. Scope and quality management,
along with stakeholder engagement and stakeholder expectation management, lead to customer satisfaction with
project progress.
• The customer is satisfied with project deliverables.
157
Scope SEVEN
Scope Management Planning

Together, the requirements and scope management plans provide direction on how the project and product scope will be
defined, managed, and controlled. The project charter, project life cycle, and development approach descriptions, and or
ganizational process assets are all inputs to the process of planning scope management. The development approach influ
ences how requirements will be elicited and how the scope statement will be developed.
Scope Management Plan

The scope management plan, which is the primary artifact of planning scope management, is part of the project management
plan. The project manager uses it to guide the building of the product until closing. It details how scope will be planned,
executed, and controlled. It describes how to do the following:
• Achieve the overall project scope
• Create the WBS and WBS dictionary, or product backlog and stories
• Manage and control scope to the project management plan
• Obtain acceptance of deliverables
Each scope management plan must be tailored to the particular project, but it may cover topics that can be standardized
for a company or for a particular type of project. Therefore, organizations often utilize templates, forms, and accepted
standards for scope management. These are examples of organizational process assets.
Requirements Management Plan

In addition to describing the methods the project manager intends to use to identify requirements, the requirements
management plan should answer the following questions:
• Which requirements techniques will be used to analyze and document the requirements?
• Once I have as many requirements as I can gather, what will I do to analyze, prioritize, manage, and track changes?
• What should I include in the requirements traceability matrix? (Described later in this chapter.)
The requirements and scope management plans can be developed in stages or iterated during project planning. The
first step is to plan how scope will be defined and who will be involved. Planning decisions will then become part of the
scope management plan. Later planning efforts may result in scope being added so the process is iterative. For example, the
completion of the Plan Risk Responses process means these risk responses are part of the project scope, causing a new
iteration of the scope management plan, scope statement, and WBS, or the product roadmap and backlog, for agile.
Agile Scope Planning

Project and product planning is more iterative on agile projects than it is on plan-driven projects. Specifically,
iterative product planning happens first at a high level during product visioning. Then the team begins to A
decompose the product into a backlog containing stories, which may be decomposed further. Once
decomposition happens, the product roadmap is created in more detail. Finally, the team plans for Focus
each iteration.
Agile Visioning
We discussed product visioning in the “PMP* Exam References in Context” chapter. This is about establishing a common
understanding of what the product is, what it does, and creating a succinct way of describing it and the value it delivers.
This is often referred to as an “elevator statement,” since it should be short enough to describe in a short elevator ride.
Agile Product Roadmap

A product roadmap alone is not the agile equivalent of a plan-driven scope management plan, but it is a visual representation
of the product s main components, broken into sequential product releases. It also acts as:
• A communication tool that provides stakeholders with a high-level view of the intended functionality of each release
• A high-level planning tool with the assumption that there will be changes to it
• A tool that allows you and the team to go back to confirm (and change) roadmap components over time
158
SEVEN Scope
The roadmap and backlog work together like this to help the team plan the project:
• The roadmap shows how the product will grow by release.
• The backlog further breaks down the features in each release into smaller, more manageable pieces called stories.
The product roadmap and backlog influence each other, and changes to project priorities or requirements are reflected
on both. Figure 7.2 shows one way a product roadmap might look for a software product that allows the consumer to
manage appointments and bills on their health clinics website. The “(P)” following some of the entries indicates a planned
partial completion for that release, while “(C)” indicates a planned full feature completion. You will also notice at the
bottom of column one that there are often “stretch” goals, which are agreed upon. This means that if the team finishes the
stories for the release more quickly than anticipated they will work on the stretch goals, but the customer is already aware
that it is a stretch and may not be completed or even started for that release.
Release 1 Release 2 Release 3

Patient can manage insurance and
Comply with regulations (P) Comply with regulations (C)
payments
Patient can view their data from

Branding/style schemes User interface design (UID)
other institutions (P)
Database integration (phase l) Database integration (phase2)
Patient can change personal data
Site security
and preferences
Manage web accounts (login,
Patient can manage appointments
password, etc.) (P)
Patient can view own medical data Patients with edit access could
(P) damage the database RISK
Current website capacity may not
be enough RISK
System architecture RISK
Conduct outreach marketing
campaign (stretch) (P)
FIGURE 7.2 Patient client portal project roadmap example
Agile Product Backlog

A product backlog is a single, visible master list of all functional and nonfunctional work identified for the project. In other
words, a backlog is a list of work that needs to be done. Backlog stories have a description of each piece of functionality and
are reviewed for risks by the team. They are prioritized by the product owner (as an integral team member). A story should
also include the following information:
• The business benefit
• Definition of done for determining when it is complete
• Acceptance criteria for determining under what conditions (requirements) it will be accepted by the customer (like
scope verification and validation)
• The stakeholder who requested it
Here is the principle behind the building and prioritizing of stories:

• The product owner organizes the backlog by priority from the top down.
• The highest value stories are always at the top, from which the development team pulls to build the product.
159
Scope
• While the product backlog contains all the formally recognized scope, low-priority items at the bottom of the backlog
may never be developed if the cost or time to produce them is deemed greater than the value they would return.
Because scope is emerging, this is sometimes not known until later in the project.
• Initial backlog prioritization happens early during release planning and then later again during iteration planning.
• The team builds stories for a current iteration while the product owner refines and reprioritizes the backlog for the
next iteration. While doing this, the product owner also answers questions for the current iteration.
Figure 7.3 shows an example product backlog for the healthcare clinic patient website. Some additional functions of
the backlog include:
• A single source of information about the project to aid in effective communication and provide a visible artifact of the
projects scope and status.
• A tool for continually updating scope as the project progresses and new information becomes available.
# Features Stakeholders
Pl Manage appointments Patients, administrators, practitioners
Change personal data and
P2 Patients, administrators, practitioners
preferences
View health information
P3 Patients, practitioners
library
Outreach (marketing)
P4 Patients, marketing
campaigns
Practitioner and patient
PS Patients, practitioners, marketing
communications
P6 Regulation compliance Patients, government
View patient’s own medical
data from The Center
View patient’s own medical
data from other institutions
Manage web accounts
P9 Patients, administrators
(login, password, etc.)
FIGURE 7.3 Partial product backlog for patient web page
Iteration Planning
After release planning and the product backlog is created and prioritized, the team, including and importantly the product
owner, decide which increments of the product will be built during the first iteration. Then as each iteration is successfully
completed the product owner has already prepared the stories to be built for the next iteration, and so on throughout
the project.
Hybrid Project Planning

Parts of hybrid projects are plan-driven, and parts are planned and delivered using agile methods. For example, let’s say
there is a large, complex product that needs a complex variety of working features, like a control system for a new solar
energy-based community. This system may need to be built using a plan-driven approach, while the rollout of the solar
panels may be done iteratively using agile methods as new homes are completed in the community. The design, build,
testing, and installation of the control system in the community building would be done using a WBS while the solar panel
systems for the individual homes could use lists, like backlogs, that would be customized per customer.
160
SEVEN Scope
Often, in mixed corporate environments, projects using a hybrid approach will have a WBS (or similar tool). Work
will be broken down to a certain level and will be used to share information with the PMO or executive management, who
may be accustomed to predictive approaches and traditional documentation. A backlog may then be used for organizing
work with the team. The project manager acts as an interface between groups.
Eliciting and Analyzing Requirements

Stakeholders can often describe a problem they have or an opportunity they want to Process Groups Model
take advantage of. Yet it is difficult or impossible for them to describe the solution. PG: Planning
Business analysis is needed to help the project team elicit and analyze requirements Process: Collect Requirements
before product and project scope can be fully defined. Requirements are the product
features, or what stakeholders need from the product and from the project. The “Col ECO
lect Requirements” process, as it was named in the Process Groups model, looks for Domain II
all requirements, not just those related to the product. The process of eliciting and Task 8 Plan and manage scope
analyzing requirements is critical to project success, as a missed requirement could

PMBOK* * Guide
mean significant changes and conflict throughout the remainder of a project.
Domain 2.4 Planning
Note: The term “elicit and analyze” requirements better represents the
magnitude and importance of this process. However, when referring to the historical
name given to this process in the PMI Process Groups model, we will use “Collect Requirements.” You may see either term
on the exam.
The objectives for which the project was initiated were originally the result of a Needs Assessment process that would
have taken place to help establish the business case for the project. Using this information, all requirements should relate
to achieving these objectives, as outlined and approved via the project charter. They may include requests about how the
work is planned and managed.
Example A stakeholder could request that systems not be shut down during peak business hours to accommodate
a project.
Requirements include the capabilities stakeholders need from the product, such as a software application that opens
at a set time when it has updates for the user. But requirements can also be non-functional, in categories related to the
following examples:
• Quality The component D must be able to withstand 200 pounds of pressure.
• Business process You must track and report the project’s expenses in this way.
• Compliance By law, we have to meet this safety standard.
• Project management We require risk management procedure X to be used.
• Environmental consideration Results of the full environmental impact study must be followed so the project has
no negative impact on the environment.
• Social need The new transit line must have accommodations for people with disabilities who cannot drive cars.
Functional requirements are also often designed to answer specific questions, like the following:
• Business requirements Why was the project undertaken? What business need is the project intended to address?
• Stakeholder requirements What do stakeholders want to gain from the project?
• Solution requirements What does the product need to look like? What are its functional requirements (how the
product should work) and nonfunctional requirements (what will make the product effective)?
• Transition requirements What types of handoff procedures or training are needed to transfer the product to the
customer or organization?
• Quality requirements What quality measures does the product need to meet? What constitutes a successfully
completed deliverable?
• Technical requirements How will the product be built? What are the product specifications?
161
Scope SEVEN
Agile methods do not attempt to specify fully detailed requirements up front. Agile teams initially
define requirements at a high level and then progressively refine them. This approach delays decisions on
implementation details until the last responsible moment, helping to avoid or lessen the effect of change
requests.
Think About It. The “Collect Requirements” process involves using the following inputs to create the
requirements documentation and the requirements traceability matrix. These are artifacts needed in order to
elicit and analyze requirements for a plan-driven project. Review them and think through how each may help to
elicit and analyze requirements.
• Project charter The Collect Requirements process begins with descriptions of the high-level requirements in the
charter. More detailed input from stakeholders is part of the reason for Collect Requirements.
• Assumption log This documents known stakeholder assumptions related to product and project requirements.
Eliciting and analyzing requirements includes refining and adding to this list.
• Stakeholder register Created in initiating, this includes a list of stakeholders identified thus far, as well as their
requirements and expectations.
• Agreements Buyers’ requirements are documented in contracts if the project includes procurements. Agreed-upon
requirements included in letters of agreement internal to the organization are also a source of requirements.
• Organizational process assets Examples of these could be historical records and lessons learned. These may
provide information about requirements from past, similar projects as well as information that may identify commonly
overlooked areas of scope.
• Stakeholder expectations The Collect Requirements effort also includes eliciting stakeholders’ expectations—
their beliefs or mental pictures about how the project will turn out—and translating those expectations into
requirements as necessary. Not all expectations are requirements so this is an area requiring trust and effective
stakeholder communication.
On large projects, there could be hundreds of stakeholders, and no single method of eliciting and analyzing
requirements will work for all of them. Since missing a requirement can be costly, a concerted effort is made to find as many
requirements as possible before work starts on a development phase.
Methods for Eliciting and Analyzing Requirements

The project manager needs to tailor their method choices to the project and its stakeholders. The following methods are
representative examples of those used to elicit and analyze requirements.
Verbal Requirements Elicitation Methods

With conversational methods for eliciting and analyzing requirements, the exchange between the team—which may
include a business analyst—results in written artifacts that are then used to define, plan, and manage project and
product scope.
Brainstorming Many people think this is just a meeting where people discuss ideas, but it is more than that. The purpose
of brainstorming is to get people to share ideas on a topic, but importantly, to build on each other’s ideas. It can be highly
beneficial to include people with different perspectives or backgrounds. The participants may be internal or external to the
project and/or the organization. Here’s how it works:
• One person mentions an idea to solve a problem or, in this case, elicit requirements and ultimately determine scope.
No evaluation happens during the idea-generation period.
• The idea generates an idea from another participant, which leads to yet another idea, and so on.
• After the ideas have been captured, the group evaluates and ranks the ideas using the nominal group technique or
multicriteria decision analysis (described later in this section).
Interviews You may also see the term “expert interview” on the exam. The project manager and/or a team member
interview stakeholders to elicit their requirements for a specific element of the product or project work, or for the overall
project. These interviews take place between two individuals or in group settings. They may also be conducted via email or
phone or using virtual collaboration tools.
162
Scope
Focus Groups This technique elicits opinions and requirements for the product or project from stakeholders and subject
matter experts. Usually selected from a specific demographic group of customers, focus group members discuss their ideas
with each other. The conversation is directed by a moderator.
Questionnaires and Surveys These are typically used for large groups. Questions are crafted to specifically elicit
requirements and expectations from respondents.
Benchmarking This looks at what the competition is doing. Benchmarking focuses on measuring an organizations
performance against that of other organizations in the same industry. Limitations on this include that it can be time
consuming and costly. It may also inhibit creativity because the focus is on examining solutions that have been used rather
than on innovation.
Facilitation This technique brings together stakeholders with different perspectives, such as product designers and end
users, to talk about the product and, ultimately, define requirements. It uses a consensus approach, which achieves general
agreement about a decision. Those who would prefer another option are willing to accept the decision supported by most
members of the group. Facilitators sometimes use voting to help a group discuss various opinions.
Voting Voting is commonly used for group decision making. Soliciting input about requirements from stakeholders often
results in conflicting requirements. A decision-making process might have the goal of unanimous agreement. Or, when
there are conflicting opinions, groups may take a majority approach, taking the decision that more than half of its members
support. If there is no majority opinion, the group may go with the decision that has the largest number of supporters. This
is known as the plurality approach. PMs should be careful making decisions based on majority rules in case key stakeholders
are in the minority.
Agile teams use voting all the time for group decision making but it may be more difficult to use with customers, in
which case other methods should be used.
Multicriteria Decision Analysis With this technique, stakeholders quantify requirements using a decision matrix based
on factors such as expected risk levels, time estimates, and cost and benefit estimates.
Nominal Group Technique This technique can be (but is not always) done during the same meeting as brainstorming.
It follows these steps:
• A question or issue is posed
• All participants write down their ideas privately
• Each participant shares their ideas
• The group discusses what has been shared
• The group ranks the ideas based on which are most useful in the given context
Observation This is a great way to learn about business processes and to get a feel for the work environment of stakeholders.
This technique is useful for projects aiming to streamline a business process. It generally involves job shadowing—watching
a potential user of the product at work, asking questions and, in some cases, participating in the work to help
identify requirements.
Prototypes A prototype is a model of the proposed product that is presented to stakeholders for feedback.
The prototype may be updated multiple times to incorporate stakeholders’ feedback until the requirements
have been solidified for the product.
User Stories Stakeholders may help develop user stories during facilitated discussion sessions. Stories
describe functionality or features that stakeholders hope to see. They are often written in the following format:
As a <role>, I want <functionality/goal> so that ebusiness benefit>
Figure 7.4 Story format
163
Scope
Example “As a community organizer, I want the library to offer public meeting spaces so we have a place to gather
and show community members the library’s benefits through neighborhood events.”
Other examples of facilitation sessions include the following:
• Joint application design ( JAD) Used primarily in software development efforts, JAD sessions involve eliciting
requirements and other input to enhance the process of developing the software.
• Quality functional deployment (QFD) Also referred to as the Voice of the Customer (VOC), this technique is
generally used in manufacturing to elicit and prioritize customer requirements.
Graphic Requirements Elicitation Methods

Different types of artifacts result from eliciting and gathering requirements, which will help to define, plan, and manage
project scope. The following methods for eliciting and analyzing requirements result in graphic images, or different ways
of representing project requirements.
Mind Maps This is a way of diagramming ideas or notes to help generate, classify, or record information. It branches out
of a central core as shown in figure 7.5. Colors, pictures, and notations can be used to make the diagram more readable.
Figure 7.5 Mind map
Context Diagrams Also known as a context level data flow diagram, a context diagram is frequently used to define and
model scope. It shows the boundaries of the product scope by highlighting the product and its interfaces with people,
processes, or systems.
Figure 7.6 shows an example of a context diagram for the payroll system upgrade described in the project charter in
the “Integration” chapter.
FIGURE 7.6 Context diagram

164
Scope
Think About It. Stop for a moment to think about how you might use the following two methods for eliciting
and analyzing requirements. You may initially create a context diagram with the help of stakeholders, to get
overall understanding of the product and who might use it. You may then use a combination of surveys,
observation, and facilitated discussions with stakeholders to elicit their requirements. Then, as part of analyzing
the requirements you have elicited you might sort them into an affinity diagram so that similar items are grouped
together for further analysis into how they relate to the overall product.
Affinity Diagrams This technique groups requirements (generated from other gathering methods) by similarities. This
sorting makes it easier to see additional areas of scope that have not been identified. Figure 7.7 shows an example of an
affinity diagram.
Library Project Requirements
Book storage Computers Office space Customer service
150,000 books
15 different categories
Signage above for easy

locating
Children’s area Reading area Public meeting space Audio
Small chairs (80%) Magazines 3 rooms 2,000 sq ft for audio

books and music
Story time locale Newspapers 10 person, 20 person, and
50 person 15 shelves for audio
Comfortable chairs books
Drop-down screens
2 desks 12 racks for music
Podium for 50-person
room 5 computers with
capability to play
audio
Figure 7.7 Affinity diagram
165
Scope
Artifacts of Eliciting, Analyzing, and Balancing Requirements

Important aspects of eliciting and analyzing requirements are balancing them against one another, resolving conflicts
where there are competing requirements, and, finally, completing the requirements artifacts, so they will help you with the
next process, which is Define Scope.
Balancing Requirements
Part of balancing stakeholder requirements involves making sure the requirements can be met within the project objectives.
If they cannot, then the project manager needs to look for options to adjust the competing demands of scope, time, cost,
quality, resources, risk, and customer satisfaction.
This is never easy or fast. It can become impossible if there aren’t clear project objectives. Do you try to get as close to
final requirements as possible when managing projects? Are your requirements ranked by order of importance? If not,
think about how such actions could improve your projects. When you take the exam, assume that every effort has been
made by the project manager to uncover all requirements to the degree that can be known, and that those requirements are
ranked by order of importance.
Agile and hybrid approaches are often used when the exact requirements are unknown.
Example You may be building something your organization has not done before, such as creating a
customer (or patient) self-service portal that allows each customer to manage their own account. In this case:
• You may not know what the most popular functions will be or the exact extent of the scope.
• You may allow customers to change their own name and address fields and enrolled services, but what about deleting
their accounts?
• Do all the key stakeholders agree about what features should and should not be included in a self-service portal?
Additional requirements are often uncovered after some use of the product or service as well.
• After launching the self-service portal, you might learn that a large percent of customers access it on a mobile device,
but the portal was optimized for a PC.
• You might also discover a competitor s portal features a “refer-a-fr iend” option that offers rewards, and you may want
to create a similar program.
A project like this, where the scope is not well defined, may be best completed using an agile or hybrid project. You
could, for example, use questionnaires and surveys to find out what the most important and first features of the product
should be. You could create committed focus groups so that as the first release is rolled out you have customers willing to
use it and help you further develop the features to come next, and so on, until the product is mature and periodic upgrades
are all that are needed.
Think About It. Often, scope and priorities change. Hie longer the project, the more likely the scope will
change because of changes in the market, technology, or organization. Take a moment to think about the patient
portal example in terms of the ECO’s Business Environment domain. Here are some examples:
• Plan and manage project compliance (task 1) How often do the regulations change? What type of SME (subject
matter expert) is needed to ensure compliance, and where will those SMEs come from? Outside the United States,
what are the compliance requirements and how will you ensure your site complies with them?
• Support organizational change (task 4) How will you ensure that everyone within the clinic understands the
product vision, is trained on using it but also embraces the changes to come within the organization and for the
customer (patient). This type of supporting organizational change is so significant and often so big that it could be
done as a sub-project or a “release” of its own.
166
SEVEN Scope
Resolving Conflicting Requirements

It is often difficult to prioritize conflicting requirements.
Example Consider the following examples from an organization that is embarking on a project to improve their
product development processes:
• What if the engineering department wants the project to focus on decreasing defects while the accounting department
wants the project to focus on lowering costs? Can both needs be met?
• What if the engineering department is the primary stakeholder or even the sponsor of the project? Should that
department s needs outweigh the needs of the accounting department?
• What if the needs of the engineering department negatively impact the accounting department?
Some issues cannot be resolved by the project manager and team. These require sponsor or other management
intervention. However, there are some standard guidelines for balancing competing requirements. For the exam, keep in
mind that competing requirements can be resolved by accepting those that best comply with the:
• Business case • Scope statement
• Project charter • Known project constraints
Here are additional considerations:

• Reject a stakeholders request to do or add something that is not related to the reason the project was initiated. It
cannot deliver project benefits if it is not related to the project charter.
• If a requirement is related to the reason the project was initiated but does not fall within the project charter, this
request should also be rejected. The project manager could encourage submission of a new project request instead.
• Suggested changes to the project charter must be brought to the sponsor for approval. Typically a project charter does
not change beyond the initiation and visioning stages of the project.
When considering constraints, if the most important constraint is schedule, then:
• New requirements that would delay the schedule will not likely be accepted. On an agile project, of course, they could
be added to the backlog and other requirements deprioritized to another project. An agile project backlog does not
have to be completed at the end of a project because some features could be deferred to another, future project.
• New requirements that compress the schedule or at least do not delay the schedule (without serious impact to other
project constraints) will likely be accepted.
Whether a project is plan-driven, agile, or hybrid, requests that do not fall within these guidelines could become part
of a future project instead.
167
Scope
7.1 Exercise
This exercise describes some of the key actions involved in balancing stakeholder requirements. It goes beyond the
Collect Requirements process and looks at this effort throughout the project. Spend time thinking about balancing
requirements. This exercise will help you determine whether you really understand the process.
In your Exercise Notebook, create a table like the one below (you do not need to write down every action, simply
write down the number). Read through each action and place a checkmark in the “Know” column ifyou understand
the action described. Put a checkmark in the “Do” if you actually apply the action in the real world. After you’ve
gone through the list, make sure you return to the actions without two checkmarks and spend time working
through them in a way that makes them real to you so you can answer related questions on the exam.
Action Know Do
1. Identify all stakeholders; understand their needs, wants, assumptions, and expectations
for the project.
2. Get requirements as clear and complete as appropriate for the selected development
approach before starting project work.
3. Use information about stakeholders and their requirements to resolve competing
requirements while work is being done on the project.
4. Look for competing interests during project planning; don’t wait for competing
interests to show up during execution.
5. Look for possible options to resolve competing interests and alternative ways of
completing project activities. This may involve using techniques such as brainstorming,
schedule compression, reestimating, and other practices.
6. Resolve competing requirements from stakeholders based on how the requirements
affect the project.
7. Give priority to the customer. (For the exam, know that if any needs conflict with
those of the customer, the customer’s needs normally take precedence.)
8. Use quality management to support the project’s satisfaction of the problems or
opportunities for which it was undertaken.
9. Deal with problems and conflicts as soon as they arise through the use of consensus
building, problem-solving, and conflict management techniques.
10. Say no to some of the competing interests. (For the exam, assume the project manager
has the authority to say no when necessary to protect the project.)
11. Fix the project when the project metrics start to deviate from the requirements, rather
than changing the requirements to meet the results of the project.
12. Work toward fair resolutions to disputes—solutions that consider the interests of all
stakeholders as well as the needs of the project.
13. Hold meetings, interviews, and discussions to facilitate the resolution of
competing requirements.
14. Call on management to help resolve competing interests when the project manager
and team cannot come up with a fair and equitable solution.
15. Use negotiation techniques to resolve conflicts between stakeholders.
16. Plan and implement effective communication.
17. Gather, assess, and integrate information into the project.
168
SEVEN Scope
Verifying Requirements
It is important for plan-driven and agile projects alike to verify requirements at every opportunity. This often entails
meeting with the customer to clarify requirements that are not clear and discuss requirements that have already been
elicited in order to make sure they are well understood. There should be a common understanding about requirements
between the customer and team. Often prototypes are useful to show the customer and ensure the requirements are well
understood before building an increment of the product.
Iteration Reviews (Post-iteration Product Demos) Projects that use agile and hybrid approaches
frequently demonstrate completed increments. Sometimes stakeholders are not interested in early increments
where there is not yet much visible functionality. But this is exactly when teams most want feedback. Getting
stakeholders involved in early reviews is important because it stimulates their ability to see and articulate what
their requirements really are. The project manager and the team must explain how important this early feedback is to get
the design and features right before change becomes more costly.
Project managers on agile and hybrid projects should explain the cost of change (see “Stakeholders” chapter) to
stakeholders. Teams want to discuss changes when the product design is still in development and the cost of change is
relatively low. This requires the team to have courage to demonstrate incomplete solutions that may face criticism and the
business to have trust and imagination into how the system may look in order to provide feedback as soon as possible.
Requirements Documentation and Other Artifacts

After requirements have been elicited and analyzed, verified, and prioritized, documentation can be completed.
Requirements documentation on predictive projects is typically more formal than on adaptive projects which use
lightweight techniques like hand-drawn diagrams. Imagine eliciting requirements from hundreds of people. Can you see
how documenting those requirements would be useful? This documentation is an output of the Collect Requirements
process and helps to ensure all requirements are clear and unambiguous.
Acceptance Criteria Requirements documentation can contain many types of information, but one thing that must be
included is acceptance criteria. To avoid having requirements that could easily be misunderstood, a great question to ask
stakeholders is, “How will we know if the work we do will meet this requirement?” Not only is this a good way to make sure
you understand the stakeholder s requirement, but it also helps to ensure the work being done will be acceptable.
Definition of Done Most often associated with agile projects, this is beneficial on any type of project. Teams
specify a “definition of done" for each product component at the user story and the release levels, as well as at
the final product deliverable level. For example, imagine a case study where we are building a house. Because
funding is only going to be available at different intervals, the house has to be built using an agile life cycle. The
following examples describe when deliverables for the house are “done,” and the final product is the
completed house:
• User story level (The story is "Concrete Curing completed”) "Curing completed” requires first that the foundation
is laid, and the concrete has been poured. The “Concreate Curing Completed” is done after 7 days which is sufficient
to allow the weight of walking on it (24-48 hours) but also the weight of construction vehicles (7 days).
• Release level (“Foundation complete”) “Foundation complete” is “done” when the foundation is laid, concrete
curing completed, tests completed, inspection completed, shown to homebuilder, response to homebuilder feedback
is completed, and homebuilder has approved/signed off on it.
• Final product deliverable (The “dream house” project is completed!) “Dream house” is "done” when all high- and
medium-level priorities are complete according to their individual definitions of done, all inspections and inspection
sign-offs are complete. The buyer has moved in and has successfully used all mechanicals in everyday usage for two
months. They have completed a customer satisfaction survey giving at least a 4 on a 1-5 scale. (Note that low-level
priority items for a home build might include finished landscaping or a planned finished basement. The buyer may
take ownership with these items remaining on a backlog.)
Relationship to Validate Scope Requirements must be described in such a way that associated deliverables can be tested
or measured for the Validate Scope process to confirm that the deliverables are acceptable. The level of documentation
detail is iterated until each requirement satisfies the criteria of being clear, complete, and measurable, and acceptance
criteria are established.
169
Scope SEVEN
Requirements Traceability Matrix Have you ever worked on a project in which some requirements got lost in the
details? It can be difficult to remember where a requirement came from, what its significance is to the project, or what other
requirements it is related to. Losing track of requirement details can result in a project objective being missed. The
requirements traceability matrix is a form of requirements documentation that helps link requirements to the objectives
and to other requirements to ensure the strategic goals are accomplished. The matrix is used throughout the project in
analyzing proposed changes to project or product scope. An example of a requirements traceability matrix is shown in
figure 7.8.
Information like requirement identification numbers, the source of each requirement, who is assigned to manage the
requirement, and the status of the requirement should be documented in the requirements traceability matrix. For large
projects, however, including all this information in the matrix would make it cumbersome and difficult to use. Another
option is to store this data in a separate repository, preserving the matrix as an easy-to-reference tool. For the exam, simply
understand that the requirements traceability matrix links requirements to objectives and/or other requirements, and that
the requirements attributes, such as identification numbers, source, and status, also need to be documented.
Assigning responsibility for certain requirements management is similar to the concept of assigning risk owners,
described in the “Risks and Issues” chapter. Assigning team members to manage certain requirements helps to ensure the
objectives are met and also helps free up the project manager s time. Requirement ownership is another type of work team
members may do on a project in addition to their work to produce the product. If a business analyst is on the project team,
they would manage requirements.
170
Scope
Define Scope
The Define Scope process is concerned with what specifically is and is not included in Process Groups Model
the project and its deliverables. This process uses the requirements documentation PG: Planning
just discussed as resulting from the “Collect Requirements” process. Other artifacts to Process: Define Scope
work with are the project charter, scope management plan, assumption log, and the
risk register. ECO
Domain II
Task 8 Plan and manage scope
Predictive Project Management and Scope Defintion
This is how scope definition plays out in predictive environments: PMBOK* Guide
• Everything known at a high level about scope was documented in the Domain 2.4 Planning
project charter.
• Many more details about scope are uncovered and documented during the
Collect Requirements process. At this point the requirements determination is sufficient to finalize the scope
definition for the project management plan.
• Once the project management plan (with this definition in it) has been approved there may be changes to it but they
will be subject to the Integrated Change Control process.
Adaptive Scope Definition

How would you define scope in adaptive environments? Let’s look at this process from an agile perspective. A
good reason to use agile is that scope is emerging, so scope will be relatively flexible.
Agile Requirements and Scope Definition

In adaptive environments, requirements and scope definitions are emerging through much of the project. On agile projects
scope is defined with progressive elaboration; first at the chartering and visioning levels in Initiation, and then with the
creation of a high-level backlog and a release plan. Agile teams then decompose product feature requirements from the
high-level backlog by progressively elaborating feature requirement details and “slicing,” or decomposing, high-level stories
into smaller, more manageable pieces of work, much like creating and decomposing the work packages of a WBS in a
predictive environment. Decomposition is discussed in the Agile Scope Decomposition section of this chapter.
Visioning and chartering The value and
benefits of the product of the project is
succinctly described during visioning (in
feasibility—not shown here). In chartering,
project objectives are documented.
Backlog The high-level list of features
is created.
Release plan This is completed with the
previous two artifacts. The plan (or release
map) will show at least the known
functionality for the first release but could
show further releases.
Detailed requirements These are collected
later as features and stories from the backlog
are decomposed and the team prepares to
build prioritized features for the first release.
Story writing workshops are held to “slice,”
or decompose, those stories to the most
manageable size and complexity.
Scope SEVEN
Flexible Scope Definition in Favor of Time and Cost

Timeboxes allow agile teams to define and manage a flexible scope to achieve the highest priority, best-quality product
within a fixed cost and a fixed timeframe. You can think of scope on an agile project then to be very flexible while time and
cost are more fixed. The highest priority items are achieved within the time given for the project.
Product Analysis As a Scope-defining Method

As noted at the beginning of this section, part of defining scope is determining what the deliverables of the project are.
Product analysis is a method of analyzing the objectives and description of the product as stated by the customer or
sponsor. That information is then used to define tangible deliverables. The work of product analysis may entail analyzing
the product description and stated requirements, or using techniques such as systems engineering, value analysis, or
value engineering.
Product analysis allows the project manager to make sure the product and project scope are understood and accurate.
For the exam, realize you may need to determine and define deliverables as part of the project, rather than receiving a
complete list from the customer.
Artifacts of Defining Scope

Project artifacts resulting from the Define Scope process for a plan-driven project include the project scope statement and
updates to other project artifacts like the requirements documentation, a requirements traceability matrix if one will be
used, and updates to the stakeholder register and the assumption log.
Project Scope Statement

This is the primary artifact of Define Scope. This document in effect says, “Here is what we will do on this project,” or “Here
is the approved project and product or service scope for this project.” The project manager and the team will have had
many discussions with stakeholders. Many things that are not in the project will have been discussed and not accepted
because they were not in the charter and did not belong to the project. So in the project scope statement, the project
manager must also be sure to identify what is not in the project. They should also clarify areas where they have learned
there are elements of the scope that could be easily misunderstood.
The project scope statement in predictive environments typically includes the following:
• Product scope
• Project scope (including descriptions of project management components)
• List of product deliverables
• Acceptance criteria
• What is not part of the project
• Assumptions and constraints
In agile there may or may not be a scope definition in the form of a scope statement. There will definitely
be components of scope as described in the Adaptive Scope Definition section of this chapter. Additionally,
agile teams decompose large or complex stories into smaller, more manageable stories. These smaller “more
manageable stories” are analogous to work packages of a WBS on a plan-driven project. What this means is
they've been broken down so that they can be more easily estimated for time, cost, and other resource needs and assigned
to team members to be built. Completed stories prioritized to be part of a release are then integrated together to become a
working increment of the product that can be released to the customer.
172
Scope
Create WBS (Decompose Scope)

In planning for predictive practices, scope decomposition consists of creating a WBS Process Groups Model
and WBS dictionary. The scope definition consisting of the scope statement, WBS, PG: Planning
and WBS dictionary make up the projects scope baseline, so there is no questioning Process: Create WBS
the need for all three of these components.
ECO
The following sections about the work breakdown structure (WBS), WBS
dictionary, and the scope baseline are largely from the Process Groups model’s Domain II
perspective. We will discuss agile scope decomposition following these sections.
PMBOKS Guide
The Work Breakdown Structure (WBS) Domain 2.4 Planning
What is a WBS? Understanding and using this tool is essential for successful projects
using a traditional approach, and for passing the exam. Start by testing your
current understanding.
7.2 Exercise
What does a WBS contain and what is its value as part of the scope baseline? Write the answer in your
Exercise Notebook.
Answer
The WBS is a visual, organizational tool (like an information radiator!) showing all the scope on a project, broken
down into manageable deliverables called work packages. It helps ensure that no deliverables are missed. It is also
a communication tool since it gives an image of what is included in the project.
Here are a few additional answers that may further define a WBS and its value to the project.
• The construction of a WBS graphically provides a structured vision for a project and helps to ensure that
nothing, including deliverables, is forgotten.
• A WBS is created with input from the team and stakeholders. Involving the team and stakeholders helps gain
buy-in, and increased buy-in leads to improved performance.
• Ihe process of creating a WBS allows the team to go through a project in their minds and thus improves
project plans. The execution of a project is typically easier and less risky as a result.
• Being involved in the creation of a WBS helps people better understand a project. It also makes a project seem
more achievable.
• A WBS shows a complete hierarchy of a project, making it easier to see how one deliverable relates to another.
173
Scope SEVEN
Review the WBS example in figure 7.10.
Requirement Design Installed hardware Test Trained Turnover

document document and software reports staff documentation
r
1
Hardware Software
11
Interview R±?‘ Signed Operational Software Database Hardware Unit test System User test Turnover Warranty
design design
report document hardware files files test report report test report report report fixes
document document
1 —1
Racks
1
Tested Installed Interface Program
ready for
hardware hardware files files
hardware
FIGURE 7.10 A (summary level) WBS for a hardware/software creation and installation project
Decomposition, of course, needs to be tailored to the project. Typically the project name goes at the top of a WBS and
the next level is the development life cycle. Subsequent levels break the project into deliverables, which are then broken
down in succession until decomposition gets to the work package level (described next).
Did you know that a WBS allows you to break down a seemingly overwhelming project into pieces you can plan,
organize, manage, and control? The creation of a WBS is an effort to decompose deliverables into the smaller component
deliverables (work packages). Decomposition can be done using a top-down approach (starting with the high-level pieces
of a project), a bottom-up approach (starting at the work package level), or by following organizational and industry
guidelines or templates.
For the exam, know that on a WBS, work refers not to an activity, but to the work products that result from an activity
or group of activities. Work packages are things (deliverables, product) rather than actions (activities). The complete
product scope as well as the project scope (including project management activities) are included.
WBS Guidelines
Every WBS is unique, and every project manager will create a WBS in their own way. For the exam, here are some guidelines
that every project manager should follow:
• The project manager creates the WBS using input from the team and other stakeholders.
• Each level of a WBS is a breakdown of the previous level.
• The entire project should be included in the highest levels of the WBS. Not every level needs to be broken down
further but those resulting in work packages must be broken down to the work package level.
• A WBS includes only project deliverables that are requirements. Deliverables not included in the WBS are not part of
the project
During planning, the project management team and subject matter experts break down the scope definition until the
work package levels are reached. This occurs when the deliverables:
• Can be realistically and confidently estimated (including the activities, duration, and cost associated with them)
• Can be logically assigned to a distinct resource or resources
• Can be completed relatively quickly
• Can be completed without interruption and without the need for more information
• May be outsourced with minimal or no disruption to the internal team.
The levels in the WBS are often numbered for ease of reference. WBS software does this automatically and there are
different numbering systems you can use.
Figure 7.11 provides an example.
174
SEVEN Scope
On the exam you may see the term “planning package” or “control account,” as seen in the figure.
1.1.1.1.1 1.1.1.12 1.121.1 2.121.1 2.1212 22.12.1 Z2.122 2212.3 221.1.1 2221.1
■ Control account
Work packages
FIGURE 7.11 Sample WBS numbering system
Control accounts, which may include one or more planning packages, allow you to collectively manage and control
costs, schedule, and scope at a higher level than the work package. Each work package in the WBS is assigned to only one
control account.
The WBS and Schedule Planning

As planning progresses the team breaks down the work packages from the WBS into the schedule activities that are required
to produce the work packages. The activities and their data are typically entered into a Gantt chart of traditional project
management software. The data can help to create the project schedule. Often project management software can also
generate a network diagram from the Gantt chart data. In the following list you can see from some of the basic activity data
how planning scope is related to planning schedule, cost, resources, and other constraints:
Name (of work package) Start date
Duration Finish date (typically driven by duration)
Dependencies (what must be done before this work Resource assigned
package?)
Scope Statement, WBS, and WBS dictionary

The team uses these three plan components to help to define the activities required to produce the deliverables. The WBS
dictionary is described in the next section of this chapter, and the Define Activities process is described in the
“Schedule” chapter.
How Work Packages Are Defined

Just how project scope is broken down into work packages is tailored to the project. Historically the guidelines have been
that on small projects a WBS is often broken down into work packages that take between 4 and 40 hours to complete.
Medium-sized projects may start with work packages of 8 to 80 hours in work, while large projects may start with packages
of300 hours of work. While we include them here in case you run into them on the exam, these historical examples are not
as likely to appear in questions as they once were. This practice has decreased in favor of a subjective-level decision by the
team as to “what makes sense” in terms of being able to estimate, resource, and build a work package. Since the project is
planned iteratively regardless of the approach, work package definitions can be iteratively refined.
The WBS As Organizational Process Asset

If your company works on many similar projects, the WBS from one project may be used as the basis for another. Expect
for exam purposes that the PMO collects and shares WBS examples, encouraging the creation of templates.
Do you really understand the WBS and its importance to planning and managing scope in predictive environments?
Try the next exercise. If you miss many of the answers, then this is a gap area for continued review before the exam.
175
Scope SEVEN
7.3 Exercise
Test yourself! What are the benefits of a WBS? Write the answers in your Exercise Notebook.
Answer
The following are benefits of using a WBS:
• Gives a picture of the entire project's scope
• Helps people better understand the project
• Provides the team with an understanding of how deliverables fit into the overall plan
• Gives team members an indication of the impact of their work on the project as a whole
• Facilitates communication and cooperation for the project team and other stakeholders
• Helps manage stakeholder expectations regarding deliverables
• Helps identify risks
• Helps prevent work from slipping through the cracks
• Helps prevent unnecessary changes
• Focuses the team’s experience on what needs to be done, resulting in increased quality and a project that is
easier to manage
• Provides a basis for estimating resources, costs, and schedules
• Provides proof of the need for resources, funds, and schedules
• Helps with planning control efforts
• Helps in establishing deliverable acceptance criteria
• Gets team buy-in and facilitates team building
A WBS is a foundational component of project

management. Almost everything that occurs in planning
revolves around the WBS.
We have already mentioned the relationship of scope
planning for cost, schedule, and resources. Figure 7.12
illustrates how many other project planning components Network
rely on the WBS. Following are some examples of how the diagram
WBS facilities planning with project constraints:
• During project selection and during initiation, costs
Resources
and the schedule are estimated at a very high level and
for the project as a whole. During planning, though,
costs and the schedule are estimated at the work
Estimating
package or activity level.
• A WBS can help a project manager and team identify
more risks by examining a project at the work Figure 7.12 Much planning revolves around the WBS
package level.
• Resource planning and management are aided by the WBS. Work packages are assigned to resources by work package
and activity.
Think ahead for a moment to the project control aspect of having a WBS. The following exercise will help you review
how the WBS is used beyond planning to also control the project as the team is building the product.
176
SEVEN Scope
7.4 Exercise
What do you do with a WBS during executing and controlling the project? The WBS is created and used in planning
but the exam also tests your knowledge of how it is used throughout the rest of the project. So, take some time to
really think about this question. Write the answers in your Exercise Notebook.
Answer
When completed, the WBS can be used any time the project scope needs to be evaluated. You may have thought of
other things, but some examples follow.
• Scope-related change requests A project manager can use the WBS, along with the project scope statement,
to determine if a change request is within the approved project scope.
• Impacts of change The project manager and team can use the WBS as part of the integrated change control
process to evaluate impacts of requested changes to project scope.
• Controlling scope creep Project managers can control scope creep by using the WBS to reinforce what work
is to be done. (“Scope creep” refers to scope increasing without appropriate change control processes.)
• Communications The WBS is a communications tool when discussing the project among the team or with
other stakeholders (e.g., the sponsor, the customer).
• Team orientation The WBS can facilitate new team members understanding their project roles.
Now, would you like to get more exam questions right? First, know that the exam may use the term
“deconstruction” as well as “decomposition.” Both terms mean the same thing. Second, many people confuse
the terms “WBS” and “decomposition.” They are related but there is a distinction. The best way to think of
decomposition is that decomposition is what you are doing, and a WBS is the method to do it, and it is also the
artifact that results from the effort. In other words, you decompose a project and manage its scope and other constraints
I using a WBS.
WBS Dictionary
Think about how a work package is identified in a WBS. It is usually described using only one or two words. But assigning
a deliverable with such a brief description to a team member allows for too much variation (which itself could cause scope
creep). The WBS dictionary is the documentation providing details needed to build each work package. It also lists
acceptance criteria for each deliverable, ensuring the resulting work matches what is needed. The project manager and
team can use a WBS dictionary to further understand the work that needs to be done, and to prevent scope creep before
work even starts rather than dealing with scope creep while the work is being done.
The WBS dictionary is an output of the Create WBS process. It may be used as part of a work authorization system,
which informs team members when their work package is going to start. You can also use it to clarify a stakeholders
understanding of effort needed for a work package. Figure 7.13 is an example of a WBS dictionary. A WBS dictionary can
include descriptions of:
• Schedule milestones • Interdependencies
• Acceptance criteria • Other work package information
• Durations
177
Scope SEVEN
Control Account Work Package Date of Update Responsible

ID# Name/Number Organization/Individual
Work Package Deliverable Description:
Work Involved to Produce Deliverable:
Acceptance Criteria (How to know if the deliverable/work is acceptable):
Assumptions and Constraints:
Quality Metrics:
Technical Source Document:
Risks:
Resources Assigned:
Duration:
Schedule Milestones:
Cost:
Due Date:
Intedependencies (before this work package):
Interdependencies (after this work package):
Approved by: Date:
Figure 7.13 WBS dictionary
Note: Some of the entries in a WBS dictionary, such as durations and interdependencies, may be filled in during
planning iterations rather than when the WBS and WBS Dictionary are first drafted. Interdependencies, for example, are
best defined and understood as a result of doing a network diagram, which is part of schedule planning.
Scope Baseline
In predictive environments the scope baseline is a set of artifacts that make up part of the project management plan and
includes the project scope statement, the WBS, and WBS dictionary.
The scope baseline is approved at the end of planning and before the work of building the product begins. Then, as
the work on the project is being done, the project manager reviews how the project is progressing and compares that data
to the baseline by answering the following questions:
• What scope has been completed on the project?
• Does it match what is defined in the WBS, WBS dictionary, and project scope statement?
Scope
Changes to the Scope Baseline

If scope is needed that is not in the baseline:
• A change has to be formally approved through the Integrated Change Control process.
• A new item (or items) needs to be added to the WBS, WBS dictionary, and project scope statement to reflect
the change.
• The updated documentation becomes the projects new scope baseline.
• Other artifact components that are affected by the scope change need to be updated, including (most commonly)
requirements documentation and the assumption log.
Performance Measurement
Measurements of project success include whether the project has met all the requirements, including the scope baseline. It
is essential to use these tools of project management in the real world. Aside from their use in achieving project success,
you need to feel comfortable with them for the exam.
Agile Scope Decomposition

Now let’s talk about decomposing project scope from an agile perspective. Ibis is worth repeating from the
Adaptive Scope Definition section of this chapter:
• In agile, product scope is defined at a high-level during project visioning and chartering.
• After this, a high-level product backlog is created, and release planning is started.
• From that high-level product backlog, product features are decomposed into smaller stories that can be estimated,
assigned resources and built.
Notice that this is in essence the principle of progressive elaboration. Early on the project manager and the team
gather high-level scope definition details. From there product features are progressively decomposed into these smaller
stories through story writing workshops and “slicing” (decomposing) stories.
Requirements Identification and Decomposition Progression

Think about it. The following is agile scope decomposition, illustrated. Figure 7.14 shows levels of agile
£ requirements. Following the figure, the sections of the illustration (numbered for convenience) are explained in
greater detail. Then, walk through an agile project in your mind, using the health clinic client portal case as
an example.
High-Level Medium Small Details

Just In Time
Business Rules
Feature A Acceptance Tests
Requirement Ul Wireframe
Feature B Activity Diagram
Tasks
1 2 3
Just In Time Requirements Breakdown...More Definition
Figure 7.14 Levels of agile requirements
179
Scope SEVEN
1. High-level Requirements or objectives are identified at the beginning of the project. Although agile practitioners
accept that scope is emerging, they still make the effort to uncover as many requirements as possible from the start.
It is unlikely you will see the word epic on the exam but in case you do, know that some agile practitioners use it to
describe the biggest of requirements (or stories). Epics are too large and complicated to build without
decomposition.
2. Medium Features are created from large and complex, high-level requirements. The level of decomposition here
is called “medium” in the figure but notice that we are just using relative terms. There is no exact definition of
“high-level” versus “medium,” etc.
3. Small Medium-level requirements are broken into smaller stories.
4. Details Each story needs to be broken further by various types of requirements, some of which are depicted in
figure 7.14. The breakdown is described as just in time because agile teams wait for the last responsible moment to
make sure they have all the details to build a story. The last responsible moment is the moment at which story
decomposition has reached its logical conclusion and the most information is available about what needs to be
done to build a story.
Agile Decomposition: Health Clinic Client Portal

First and foremost, agile product feature prioritization and decomposition is value-based, always done from the standpoint
of what stakeholders find most valuable.
• Release map scope decomposition level Review figure 7.2 on page 159 of the patient client portal project
roadmap example. This will make it easier to walk through the project in your mind. The roadmap for the patient client
portal project is shown in three releases. These are the high-level requirements (or epics).
• Product backlog decomposition level Review figure 7.3 on page 160: This is the product backlog. Listed in it is
likely to be a combination of high- to medium-level features, which must be decomposed further into smaller stories.
The “manage web accounts” set of features shown in the product roadmap for Release 1 could be comprised of Pl
(manage appointments), P2 (change personal data and preferences), and maybe other features in this backlog.
• Story decomposition level A given feature is usually sliced (decomposed) into two or more stories; as this is done
more details about the individual stories emerge. Stories can be compound, complex, or both. Figures 7.15 and 7.16
gives examples of each in the patient portal case study.
>/ A compound story has multiple independent stories within it
>/ A complex story is a big story that has to be broken down to decrease its complexity
• Detailed decomposition level At this level the team needs to have detailed story information established, like
definitions for business rules, unit tests, acceptance tests, and tasks to build the story.
Patient website Regulation A Patient website

As a patient
I want to
create an
account
As apatient
government
I require
Regulation B I want to
manage mg As a patient
regulation web account I want to
compliance
Regulation C
As a patient
I want to
recover a
password
Figure 7.15 Slicing a compound story Figure 7.16 Slicing a complex story
180
Scope
Other Agile Scope Decomposition Opportunities

In addition to product and project visioning, product roadmap, release, and iteration planning opportunities for scope
decomposition on agile projects, agile teams are aware of the fact that throughout the project, opportunities emerge for
better and different ways of breaking down requirements so the related stories are easier to build. Here are a few examples:
• Example from the daily standup At a daily standup meeting for the patient client portal project, a team member
mentions they are having problems with regulation C because its technical requirements in the program interfere with
the technical requirements of regulation A. After the meeting, the project manager gets the team member in touch
with a systems architect they know has experience in this area to help simplify the programing for these regulations.
• Example from a “design, build, test, accept, release” model These steps describe the common iterative cycle
process that continues throughout the project. At any time during this process opportunities for improvement in
story decomposition can emerge. For example, let’s say during the build step two team members are practicing paired
programming. (This means two programmers sit together and take turns with one person programming while the
other watches.) What if the observing programmer on the “manage account” story in figure 7.17 suddenly realizes
that the stories for this feature can be broken down and built in a different way that results in a better, simpler design?
Although perhaps invisible to the end user, the product has just been improved.
Methods for Agile Story Decomposition

You probably know intuitively that there can be many methods of breaking down features and functions of a product, but
you may not be aware of these less obvious methods. Here is a list of some common story breakdown methods.
• Process-based breakdown The “manage account” story in figure 7.17 shows a process-based breakdown. The
process described as “Manage account" is shown to have three sub-processes associated with it (although there are
more than the sub-processes shown in this simple example).
• CRUD (Create, Read, Update, Delete) This acronym stands for the list of things a programmer wants to allow a
user to do with data. See the illustration in figure 7.17. We provide this example to help you remember the term
CRUD, which may be used on the exam. You will not need to know more than this about this method.
• Business rule-based breakdown An example of a business rules breakdown might sound like this: “There are
many ways for a patient to pay a bill. On the website we only accept the use of VISA, Mastercard, bank information for
automatic withdrawals (if a payment plan is needed), and PayPal. For this example, the team will break down stories
based on what it takes to build in this functionality.
• User or platform-based breakdown An example of the need for this type of breakdown is “We have to make this
product easily usable on desktop PCs, laptops, tablets, and mobile devices.”
• Acceptance test breakdown An example of this is employing acceptance test-driven development (ATDD). With
ATDD, acceptance tests are built before the story is built and then the story is built to pass the test.
• MoSCoW analysis This is a breakdown method of higher-level requirements at the release map and product
(feature) backlog levels. MoSCoW stands for “Must have, Should have, Could have, and Would like to have,” and is a
prioritization scheme for selecting features and functionality.
Scope SEVEN
Figure 7.17 shows how “manage account” may be broken down using CRUD. Notice that “D” is not included since
the clinic will not want a patient to be able to delete their own account.
Original:
Manage account
(login, password,
Create contact us)
Read
As a
Update As a
patient
patient As a
Delete I (want to) patient
create n\y I (want to)
read w\.y site I (want to)
site account
account page update w\y
password
Figure 7.17 CRUD functional decomposition
Validate and Control Scope

Many people are confused about what it means to validate scope. If you correctly un Process Groups Model
derstand scope control and validation from the perspective of the Process Groups PG: Monitoring & Controlling
model, you can get more questions right on the exam. According to the Process Process: Validate Scope; Control Scope
Groups model, validate and control scope are two distinct processes, but let’s review
the process of validating scope together with the process of controlling scope so you ECO
understand them holistically and are ready for related exam questions. Domain II
TRICKS First understand where in the project management process scope is PMBOKS Guide
OF THE validated. Many people think scope validation means confirming the
TRADE* validity and appropriateness of the scope definition during project Domain 2.6 Delivery
planning. The Validate Scope process actually involves frequent planned Domain 2.7 Measurement
meetings with the customer or sponsor to inspect and gain approval of deliverables
I during project control. That’s a big difference, isn’t it?
Validate Scope
This is ideally the result of all project work—accepted deliverables! Validate Scope means taking already verified results to
the customer. The customer will either accept deliverables or make change requests. The successful process culminates in
the customer signing off on the results. This process is repeated throughout the project as interim deliverables are completed
until the end of the project when the customer signs-off on (or validates) the final, delivered product—or on agile projects,
the minimal viable product.
Control Scope
The project manager and team control scope throughout the project—before, in concert with, and after the validate scope
process. This, then, for the project manager is about monitoring progress, looking for ways to remove impediments to the
team who are completing the scope in the allotted time and cost. This is how the project manager can help the team ensure
that Control Quality will bring about expected, verified results, and the Validate Scope process can happen without
difficulty. It involves measuring and assessing work performance data against the scope baseline and managing scope
baseline changes.
182
SEVEN Scope
What are the inputs to validate scope? Here’s an exercise to look at the inputs to this process.
7.5 Exercise
In your Exercise Notebook, write the answer to this question: “What do I need before I can validate scope?”
Answer
• Verified deliverables Validate Scope is intimately tied to Control Quality. Completed work must be checked
before meeting with the customer. The deliverables are verified in Control Quality.
• Scope baseline This is needed (from the project management plan) for comparison. It’s helpful to have the
approved scope when meeting with the customer.
• Scope management plan This plan shows and plans for gaining formal acceptance of approved deliverables
(described in the scope baseline).
• Requirements management plan and requirements traceability matrix The project manager exchanges
information about the requirements and shows the customer how they have been validated. Comparing the
requirements to results will help to determine if any action or change is needed.
• Work performance data This data from the Direct and Manage Project Work process helps the project
manager assess how well product deliverables are meeting the requirements.
• Other project documents Quality reports and lessons learned should also be reviewed at the start of this
process. Quality reports can include information about open or closed issues. Lessons learned can be used to
improve the process of validating project deliverables.
Did you notice that we didn’t just list what the project manager needs to do but described how each artifact will
TRICKS
OF THE be used? Whenever you think about the inputs of a process, make sure you can describe them and explain
TRADE where they come from and what they offer to completing the process. Similarly, make sure you understand how
outputs flow logically from each process. For the exam, this deeper understanding will often give you more
insight into situational questions, help you distinguish between relevant and extraneous data, and help you select the
correct answers. As you study, this understanding will spare you the need to memorize lists of terms like those used to
name inputs, outputs, and tools and techniques.
Think About It. Did you happen to notice that there are no executing processes in the Process Groups model
for the project manager for scope? This will be true of schedule and cost processes too, and it is because the team
is responsible for the executing processes of scope, schedule, and cost. They are building the product (and
spending the time and money to do so).
Now try an exercise on the efforts and outputs (artifacts) of these processes.
183
Scope SEVEN
7.6 Exercise
In your Exercise Notebook, list what you are doing to control and validate scope, and what you have when you’re
done with the same processes.
Answer
What We Have When We Are Done with
What to Do to Control and Validate Scope Control and Validate Scope
• Help the team focus on approved scope; do not • Change requests
add extras • Accepted deliverables
• Help the team build from the top of a • Updates to project artifacts
prioritized list like a backlog • Work performance information
• Collaborate with the team on ensuring a • Possible updates to processes and procedures
common understanding of scope
• Remove impediments for the team
• Gather and analyze work performance data
• Work on continuous improvement of processes
and product quality
• Compare the deliverables to the requirements
to make sure they meet stakeholder needs.
Methods for Control and Validate Scope

Traditional methods for controlling and validating scope in predictive environments are based on observation and analysis.
They include:
Inspection Product inspection is a routine part of controlling and verifying scope internally before validating scope with
the customer and is in fact part of Control Quality.
Data Analysis is used in Control Scope. It includes variance analysis, which is comparing the scope baseline to actual
project results to determine if variances are within acceptable limits. Related to this over a longer period of time is trend
analysis, which helps tell the project manager and team if project performance is improving or worsening.
Decision Making Based on the data the project manager and team observe and analyze, and inspection of the workings
of the product, the project manager and team can make decisions, largely based on consensus. Decisions may include how
to handle issues, work around or fix problems on the spot, and otherwise prepare the product increment in question to
either go to the customer for validation or remain in development until all issues are resolved.
Controlling and Validating Scope in an Agile Environment

On a change-driven project, controlling, verifying, and validating scope happens at the end of each iteration
as part of the iteration review with the customer. Let’s say the team, in collaboration with the customer, has
settled on doing three, two-week iterations, plus a “hardening off” iteration (to make sure everything is ready
for release) before each product release. By the time an MVP is ready for the first product release, the team and
customer have participated in three or four iteration reviews (if the hardening off iteration is included, and it typically is)
where the customer has seen the increasingly mature product release before it is delivered to the marketplace.
Agile Ceremonies (Meetings) Throughout the project and during every iteration the team has daily standup meetings to
report to each other what they have been working on and have completed, what they will continue working on toward
completion, and whether there are any impediments to progress. At the end of each iteration the team meets with the
customer to demo and discuss what they have built, hopefully getting acceptance of that iteration’s work but also taking
back any customer feedback with which to improve the product increment before delivery. The team follows up each
iteration review with an iteration retrospective among themselves to further the goal of continuous improvement in all
SEVEN Scope
their processes, and particularly in improving the product of the current project. Agile ceremonies are focused on
controlling and producing project scope.
Customer-valued Prioritization The role of the product owner is about prioritizing the product backlog according to
customer priorities. The product owner represents the end users of the product and must bring anyone into the conversation
who is important to the continuous delivery of the features the end-users (or customers) most value. It is the team’s job
then to help the product owner maximize that value with advice on technical requirements and risks. These requirements
and risks are added to the backlog and integrated with the customer requirements for the product.
Incremental Product Delivery Through frequent product releases the team delivers minimal marketable features
(MMFs) to the customer until the agreed-upon project backlog is complete. The product backlog usually continues to
exist across several or many projects, and for some kinds of products, like software, smaller upgrades can be delivered on a
regular basis as part of product maintenance.
Artifacts of Control and Validate Scope

The artifacts of the Control and Validate Scope processes include:
• Project management plan and document updates
• Work performance information (analyzed work performance data)
• Change requests
For Validate Scope the resulting artifacts also include accepted deliverables. This means approval and formal sign-off
by the customer, and may happen the first time the team shows a deliverable (product increment) to the customer, or only
after changes have been made as a result of customer feedback.
There are a few more aspects to remember about Validate Scope:
• It can be done at any point in the project (within a phase) to get formal acceptance of interim deliverables that require
approval (as part of monitoring and controlling). On agile it is done at the end of each iteration.
• It is done at the end of each project phase to get formal acceptance of interim deliverables.
• It is done at the end of a planned product release in agile.
• The difference between the Validate Scope and the Close Project or Phase processes can be a little tricky.
V The Validate Scope process results in formal acceptance by the customer of deliverables.
The Close Project or Phase process is an integration process, to get final acceptance from the customer for
the project or phase as a whole including not just product scope but project and phase closing activities, like
indexing and archiving records, for example.
• We have already mentioned that Validate Scope and Control Quality are related. The high-level diagram in figure 7.18
should help you visualize this.
FIGURE 7.18 Relationship of Validate Scope to Control Quality
185
Scope
Although Control Quality is generally done first to verify that the deliverable meets requirements before it is shown
to the customer, the two processes are similar. Both involve checking for the correctness of work according to requirements.
The focus is on who is inspecting and approving.
• In Control Quality, quality control checks to see if the requirements specified for the deliverables are met.
• In Validate Scope, the customer checks and hopefully accepts the deliverables.
As you take the exam, assume that the project manager is controlling scope to make sure the scope is being completed
according to the project management plan. There should be a clear definition of and elaboration on scope in the scope
baseline. Assume proper project management is being done on the project unless the question states otherwise.
The project manager then has to measure the completed work against the scope baseline, perform data analysis,
including analyzing any variances, and determine whether the variances are significant enough to warrant changes. If
necessary, they would submit a change request through the Perform Integrated Change Control process to assess the
impact the change would have on all aspects of the project. New work performance information may result, along with
updates to the project management plan and project documents.
Remember that the Control Scope process is proactive. It includes thinking about where changes to scope may be
coming from on the project and what can be done to prevent or remove the need for any more changes from that source.
Properly using project management tools, techniques, and practices will save you from unnecessary problems throughout
the life of a project.
Scope: Putting It All Together
7.7 Exercise
In our library case study, the project manager who is overseeing the creation of the new community library has
gathered requirements, but the stakeholders differ on what is needed (or not needed) and on what they would like
to see in the new library. How might the project manager work to resolve these competing requirements?
Stakeholder(s) Requirement(s)
1. City Council A small coffee shop included in the library so people can meet and talk and have a drink/
member snack.
2. Librarian No food or drink should be allowed or encouraged in the library. Spills damage books and
technology, and costs more for cleaning every night.
3. Library staff A small kitchen/break room where staff could refrigerate and heat lunches to decrease the
need to go out for lunch which is costly and takes time. Also beneficial to patrons;
sometimes a parent wants to heat their baby’s food for story time without leaving the library.
4. Librarian Against a kitchen because of additional mess and cleaning costs. She thinks the staff can
simply bring cold sandwiches if they want to bring their lunch. Many employees only work
part time so don’t take a lunch break.
5. Mayor Wants everyone who uses the library to login to the system and provide their demographic
info (name, address, phone, email). They think this data will be useful for increasing voter
registration and participation.
6. Citizens group Does not want the library to collect demographic information. They want people to be able
advocating for to use the library without providing private information. They think the mayor is trying to
online privacy build a database for campaigning.
7. IT Security For security, the least amount of information needed should be collected. The system
Consultant should also require users to view a short security video before they are allowed to use the
system.
8. Librarian Some patron information is needed. If a patron checks out a book, and does not return it,
reminders need to be sent and possibly late fees need to be charged.
186
SEVEN Scope
Answer
Here are some sample answers. You may have come up with some other solutions. Just make sure you understand
our solutions, and that your solutions will help the situation.
Stakeholder(s) Requirement(s) Ways to resolve

1. City Council Small coffee shop be included in the library so — Interview architect and construction
member people can meet and talk and have a drink/snack. teams; get high-level cost estimate of a
coffee shop.
2. Librarian No food or drink should be allowed or encouraged
in the library. Spills damage books and technology, — Send survey to include opinions of
and cost more for cleaning every night. citizens (potential library patrons).
—Assist the librarian to research
estimates for additional cleaning
costs/damage costs expected.
— Get bids from coffee shop managers
who would run the operations.
— Have a brainstorming session about a
coffee shop; generate ideas for
decreasing or eliminating library
materials damage.
3. Library staff A small kitchen/break room; staff could refrigerate - Interview architect and construction
and heat lunches to decrease the need to go out for teams; get a high-level estimate of the
lunch which is costly and takes time. Beneficial to cost of a breakroom with kitchen.
patrons; sometimes a parent wants to heat up baby’s
- Have a workshop with the current
food for story time without leaving the library.
staff and librarian to talk about the
4. Librarian Against a kitchen because of the additional mess and pros and cons of this idea. Would the
cleaning costs. She thinks the staff can simply bring staff be willing to clean the kitchen?
cold sandwiches if they want to bring their lunch.
- Analyze current and future staffing
Many employees only work part time so don’t even
needs: part time vs. full time.
take a lunch break.
5. Mayor Would like everyone who uses the library to login - Library software system can be built
and provide demographic info (name, address, using an agile approach.
phone, email). The mayor thinks this data will help
-A backlog of requests will be compiled
increase voter registration and participation.
and prioritized at workshops with the
6. Citizens group Does not want the library to collect citizen stakeholders.
advocating for information. They want people to be able to use the
-Aproduct owner could help the
online privacy library without providing private information. They
various stakeholders reach consensus
think the mayor is trying to build a database for
on the next requirement meet.
campaigning.
7. IT Security For security, the least amount of information needed - MVP could be basic searches for
Consultant should be collected. The system should also require materials and the security video.
users to view a short security video before they are Future releases could consider some
allowed to use the system. collection of data as the need arises.
8. Librarian Some patron information is needed. If a patron

checks out a book, and does not return it, reminders
need to be sent and possibly late fees need to be
charged.
187
188
QUICKTEST
• Dependencies
8 Schedule • Float
• Leads and lags
• Critical path
• Milestone
• Schedule model
• Schedule Management
Introduction process
• Schedule management
Planning a project schedule and the overall process of schedule management primarily relies on tech plan
nical project management skills. How do you manage a project schedule? For this question, many peo • Precedence diagramming
method (PDM)
ple immediately think about software or a Gantt chart. Yes, software is a valuable tool. It can save time
• Dependencies
with scheduling, analyzing what-if scenarios, performing status reporting, and other things. But you
- Mandatory
need to understand the details behind the data. - Discretionary
This chapter, along with additional exercises on the RMC Resources page - External
(rmcls.com/rmc-resources), will help you thoroughly understand the process of https://rmcls.com/rmc-resources
- Internal
planning and managing a project schedule. Historically, exam questions related • Network diagram
to scheduling have required the knowledge of how to draw a network diagram. • Analogous estimating
• Bottom-up estimating
Agile questions may require you to know how to build a story map.
• Parametric estimating
Although the process to plan and manage a schedule is straightforward, you • Single-point estimating
need to know options for developing and compressing a project schedule. A • Three-point estimating
RMC RESOURCES
project schedule must be realistic before the work to build the product begins. - Triangular distribution
For the exam, assume you have the authority and responsibility to create a - Beta distribution
realistic schedule. The exam is written with this assumption although it is not always true in real life. • Activity standard deviation
• Affinity estimating
• T-shirt sizing
Definitions Related to Plan and Manage Schedule
• Planning Poker®
This is some basic estimating and schedule-related vocabulary that will be used in upcoming sections,
• Alternative analysis
where we will cover each concept in more detail. • Reserve analysis
• Contingency reserves
Dependencies • Management reserves
Dependencies are logical relationships between activities in a project. The most obvious dependency
• Fist of five
example is: “Activity A must be completed before activity B can start.” There are other types of • Basis of estimates
dependencies, which are covered later in this chapter. • Critical path method
• Fast tracking
Float • Crashing
Float represents schedule flexibility. Most simply, float is the amount of time an activity can be delayed • Monte Carlo analysis
without delaying the end date of the project. The definition in practice is a little more involved than • Resource leveling
this, however. There are several different types of float, which are covered later in this chapter. • Resource smoothing
• Agile release planning
Leads and Lags • Cumulative flow diagram
A lead may be used to indicate that an activity can start before its predecessor activity is completed. For • Velocity
example, web page design might be able to start five days before the database design is finished. A lag • Project schedule
is waiting time inserted between activities. For example, a three-day lag time after pouring concrete is • Milestone chart
• Bar chart
needed before constructing the frame for a building.
• Schedule baseline
Critical Path • Reestimating
The critical path is the shortest path to finishing the project. Projects are complex and have many
workstreams. The critical path is important because it is the one workstream that has no float (schedule
flexibility). Since the critical path has no float, any activity along it that is finished late represents a risk
of the project finishing late.
189
Schedule EIGHT
Milestones
Identified points in the project schedule where particular objectives should be met are called milestones. They are not
work activities and have no duration but they do fall on certain dates. Initial milestones are documented in the project
charter. The project manager can also insert milestones as checkpoints to help control the project. A milestone list is a
project document, often created as an abbreviated view of the schedule. If a milestone in the schedule is reached and any
of the planned work is not complete, the project is not progressing as planned, i.e., the project is behind schedule.
Examples A completed design, a company-required checkpoint, a phase gate, or an iteration completion point.
Schedule Model
The schedule is always a model of sorts because it is subject to changes based on constant monitoring and controlling of
the project. The project calendar (or schedule), plus all the associated planning documents is referred to as the schedule
model. At first it is a working model of the schedule, along with artifacts like the activity attributes and estimates and the
project schedule network diagram (once it is created). An agile equivalent would include the release map and other release
planning artifacts, the prioritized backlog plus the current iteration plan.
As the project schedule is approved the schedule model becomes the current approved version of the schedule along
with these other schedule-related artifacts. For both agile and plan-driven approaches the projects historical planned and
actual results data and analyses inform the current schedule model.
Schedule Process Overview

As with all project management processes, you will need to understand how to plan and manage the project schedule from
several perspectives. The Schedule Management process from the Process Groups model is one way to speak about project
scheduling, and the Plan and Manage Schedule task in the Process domain of the Examination Content Outline (ECO) is
another. Remember that while much of the Process Groups model can be applied to any project life cycle and development
approach, agile has its own methods and practices. You will also want to understand agile scheduling practices, and how
they are similar and how they are the different from plan-driven practices.
Think About It. Take time now with the ECO and the following diagram to think through the Process Groups
model’s Schedule Management process as it relates to the Plan and Manage Schedule task from the ECO’s
domain I (Process).
• In the Process Groups model, these are all planning functions:
✓ Define activities
✓ Sequence activities
✓ Estimate activity durations
• Then you are ready to develop the schedule—also a planning function.
• Throughout the project you are using earned value measurement (EVM) to control the schedule (including
procurement schedules) and manage changes to it. EVM is covered in more detail in “Budget and Resources,”
as it is used for tracking progress on scope, schedule, and cost together.
190
EIGHT Schedule

Domain II Schedule Management Domain 2.4
Planning
Task 6 Plan Schedule Management — Domain 2.7
Plan and Manage Schedule Measurement
Define Activities
Planning Domain 2.8
Sequence Activities
Uncertainty
Estimate Activity Durations
Develop Schedule —
Monitoring
Control Schedule —
& Controlling
Can you see how other ECO tasks support Plan and Manage Schedule? For example, supporting ECO processes are
Manage Conflict and Negotiate Project Agreements (People domain I, tasks 1 and 8). Also think about the supporting
roles of Promote Team Performance through the Application of Emotional Intelligence, and Ensure Team Members/
Stakeholders Are Adequately Trained (People domain I, tasks 14 and 5). Think systematically as you review the ECO.
Other ECO tasks also often play a role in planning and managing the project schedule.
Process Groups Model

KA: Schedule Management
Key
Continuous change control
7 is consistent with all
approaches
Change prompts a process
C to be reiterated through
progressive elaboration
or agile methods
.—Changes that cause a

return to Initiating are rare
Figure 8.1 Schedule management process
Desired Outcomes of Schedule Management

For the exam, unless the question indicates otherwise, assume that schedule management has been properly planned
according to the concepts presented in this chapter related to planning and managing the schedule. Having a plan means
that when a problem arises the first option is to look to the plan for how to handle it. The following should be expected of
a properly planned and managed project:
191
Schedule EIGHT
• All or most deliverables are completed and delivered in the planned timeframes, within budget and with the agreed
quality attributes.
• The number of changes to the project and product requirements are within the project manager and team s expectations.
More changes are expected on agile projects than on plan-driven projects. Negotiating scope to keep the
project on schedule on agile projects is also expected as scope is understood to be the more flexible constraint.
A significant number of changes to requirements on plan-driven projects should be evaluated for possible
issues with stakeholders or the clarity of the scope and requirements definitions.
• Stakeholder behaviors and relationships indicate project outputs are largely accepted and stakeholders seem satisfied
at a given point.
• The cadence of development, testing, and implementation is appropriate to the specific project and to the development
approach and life cycle selected.
• Measurements indicate the project is performing as planned. Reviewing past forecasts against present project
performance indicates the project is largely or wholly on schedule.
• Project benefits can be realized in the timeframe they were planned for.
Plan Schedule Management

The Plan Schedule Management process involves documenting how you will plan, Process Groups Model
manage, and control the project to the schedule baseline, and how you will manage PG: Planning
schedule variances. You also need to determine in advance and ensure a common Process: Plan Schedule Management
understanding about:
ECO
• What the measures of performance will be
Domain II
• How and when to capture data to evaluate performance Task 6 Plan and manage schedule
• How you will use the data to keep the project on track
PMBOK° Guide
• What you will do when variances occur
Domain 2.4 Planning
Plan Schedule Management answers questions such as:

• Who will be involved, and what approach will be taken to plan the schedule for the project.
• What processes and procedures will be used to create the schedule?
Did you remember that hybrid and agile approaches take a more short-term view of scope and schedule
than traditional approaches? Teams form a general plan and then schedule and perform project work in
iterations. They then re-evaluate to determine the next best steps based on actual progress. Agile teams also
continually refine the schedule as new details emerge. This approach is best when trying something new.
When the work is new and scope is emerging rather than stable, discovery is a better guide for progress than detailed analysis.
When work and environments are familiar and predictable, it is possible to accurately schedule work in advance. A
hybrid approach uses traditional scheduling methods in some areas of the project while using agile methods in others.
Example A traditional approach is typically used to build an office building. A realistic hybrid option is to start and
finish the building s most durable aspects using a traditional approach, and then customizing the inside spaces iteratively
as office space is leased.
To plan the projects schedule, the project manager will also need to:
• Review the project charter
• Use expert judgment
• Use data analysis techniques, such as alternatives analysis
• Hold meetings that include the:
y project sponsor
y team members
y other stakeholders
192
EIGHT Schedule
The project life cycle and development approach agreed on in Develop Project Management Plan (an Integration
process) will influence the level and type of schedule management planning the project manager does. They may also
consider using or creating enterprise environmental factors, such as:
• A work authorization system for the project
• A preferred project management scheduling software, which the organization may already have
• The impact of the company culture and overall structure on the project schedule
Schedule Management Plan What is the key output of this process? A formal or informal schedule management plan
(part of the project management plan). It helps make estimating and schedule development faster by specifying
the following:
• Scheduling methodology and software • How schedule variances will be managed
• Rules for how estimates will be stated (Examples: • Performance measures that will help identify
hours, days, story points) variances early
• Whether to state both effort and duration • Acceptable variance threshold (s)
• How a schedule baseline to measure against will • A process for determining whether a variance must
be stated be acted on
• Estimates for where changes may occur • Types, formats, and frequency of reports needed
• Change control procedures • Length of iterations and releases for agile
Define Activities
The Define Activities process involves doing the following for the work packages cre Process Groups Model
ated in the WBS (created as part of Plan and Manage Scope): PG: Planning
• Decomposing them into the activities that are required to produce the Process: Define Activities
work packages
ECO
• Making sure decomposition is at a level small enough to:
Domain II
x/ Estimate Task 6 Plan and manage schedule
y Schedule
PMBOK9 Guide
y Monitor and control Domain 2.4 Planning
• Prepare to sequence these activities in the next process
The Context for Defining Activities

Project managers often combine the Define Activities effort with creating a WBS and WBS dictionary. The project manager
and team decompose work packages into the activities required to produce them, rather than stopping at the work package
level. So, what is needed in order to define activities?
• The schedule management plan gives the project manager important information about the agreed sched
uling methodology
• The traditional scope baseline (scope statement, WBS, and WBS dictionary), or the projects product backlog for
agile projects
• Story cards for agile projects
This is the work the project manager will now break down into project activities. Collaborating with the team helps
define activities completely and accurately and later will make the estimates more accurate. The project manager may refer
to organizational process assets, including:
• Existing templates,
• Historical information such as:
Activity lists
■/ Issue lists from other similar projects
• Standards, such as prescribed scheduling methodologies
193
Schedule EIGHT
TRICKS While reading exam questions remember to identify: “Where am I in the project management process?”
OF THE Decomposition is used in schedule, scope, and cost management. When you see the term “decomposition” on
TRADE the exam, look for context. If deliverables are being decomposed with the team into smaller deliverables (or
work packages) the question is referring to the Create WBS process (in scope management) and a predictive
aI . If work packages are being broken down into activities to produce them, the question is referring to Define
; (for schedule management).
TRICKS I With an agile approach, the team helps to define the activities and the product owner sequences the work by
OF THE prioritizing stories in the backlog. The team helps identify dependencies, develop estimates, and provide input
TRADE on what is achievable. Development of the schedule is a joint effort.
Sequencing Activities
Once work package activities are defined, the next process involves sequencing them Process Groups Model
in the order in which the work should be performed. The result is a project schedule PG: Planning
network diagram. A simple network diagram is illustrated in figure 8.2. There is prac Process: Sequence Activities
tice work designed to help you learn how to draw and interpret network diagrams
later in this chapter. ECO
Domain II
Task 6 Plan and manage schedule
PMBOK® Guide
Domain 2.4 Planning
FIGURE 8.2 Network diagram
For the exam, know this about a network diagram:

• In its simplest form, it just shows dependencies between activities.
• If activity duration estimates and leads and lags are added to the diagram, it can also show the critical path, which is
the shortest path to finishing the project.
• If plotted out against time (is made calendar-based), the network diagram is a time-scaled schedule network diagram.
Inputs that may influence dependencies in the sequencing of activities include the:
• Assumption log
• Activity list
• Activity attributes
• Milestone list
Precedence Diagramming Method (PDM)

This method uses nodes (or boxes) to represent activities, and arrows to show dependencies. In figure 8.3, for example,
activity B is dependent on the completion of activity A.
Activity --- > Activity

A B
FIGURE 8.3 Precedence diagramming method
194
EIGHT Schedule
Logical Relationships
There can be four types of logical relationships between activities, as shown in figure 8.4.
• Finish-to-start (FS) An activity must finish before the successor can start. This is the most commonly used
relationship. Example: You must finish digging a hole before you can start the next activity of planting a tree.
• Start-to-start (SS) An activity must start before the successor can start. Example: You must start designing and wait
for two weeks’ lag in order to have enough of the design completed to start coding.
• Finish-to-finish (FF) An activity must finish before the successor can finish. Example: You must finish testing
before you can finish documentation.
• Start-to-finish (SF) An activity must start before the successor can finish. This dependency is rarely used. An
example of this type is, “The first shift security guard cannot leave until the second shift security guard arrives.”
FIGURE 8.4 Finish-to-start, start-to-start, and finish-to-finish dependencies
Types of Dependencies
The sequence of activities is also determined based on these dependencies:
• Mandatory dependency (hard logic) A mandatory dependency is inherent in the nature of the work or is required
by a contract. Example: You must design before you can construct.
• Discretionary dependency (preferred, preferential, or soft logic) This means there are other ways it could be done,
but this is the approach the organization has chosen to perform the work. Discretionary dependencies are the most
flexible type, and they are important when analyzing how to compress the schedule to decrease the project duration
(i.e., to fast track it).
• External dependency This type of dependency is based on the factors relating to a party outside the project (for
example, government or suppliers).
• Internal dependency This type of dependency is based on needs internal to the project and may be something the
project team can control.
More than one dependency can be identified for the same work. Combinations include:
• Mandatory external • Discretionary external
• Mandatory internal • Discretionary internal
Dependencies in Hybrid Environments

Digital products have different characteristics than traditional, physical products. Consider how a contractor
builds a house. They wouldn’t complete the interior of the house before they built the roof, would they? Of
course not. The roof needs the walls, the walls need a foundation, and the foundation needs land and permits
in place. The dependencies are static, well understood, and slow to change. Techniques like network diagrams,
critical path analysis, and detailed Gantt charts are valuable and necessary.
In the digital product space, however, there are many more options and possibilities. Good IT architecture allows
services to be swapped out easily and promotes isolating changes. This means there are far fewer dependencies on digital
projects. This coupled with more requirements renders much of the traditional dependency analysis and dependency
management redundant, unreliable, and wasteful. Therefore, many of these techniques are not used in software-heavy
digital projects. Instead, project managers work with product owners to define what the priorities are, and they work with
the teams on how best to build them. Typically, features can be implemented and evaluated independently of each other.
195
Schedule EIGHT
For example, using a hybrid approach to build an energy trading system for an electrical operator, the product owner
may use a traditional approach to create an initial sequence of features to be developed. Then they may reorder the
remaining features once the initial product is in place. The product owner may reorder these features again after the
regulatory body responses get integrated, and again later as additional features come on board. This would all require
extensive schedule rework with traditional network diagrams and Gantt charts. By comparison, reordering the backlog at
this stage of a hybrid project is much less work.
Project Schedule Network Diagram

A schedule network diagram is an artifact of planning and managing the project schedule. It is an illustration depicting the
flow of project activities in the logical order in which they will be performed (see figure 8.11). Here are some guidelines to
understand about schedule network diagrams:
• The project manager needs the activities list and to know the dependencies between activities. Later, after they have
all the duration estimates for each activity, they can add that data to the network diagram.
• All activities after the Start should be connected to at least one predecessor activity (except the first one in each
workstream after Start).
• All activities on the network diagram before the Finish should be connected to at least one successor activity.
• The network diagram helps the project manager plan which activities can be completed in parallel and to see where
leads or lags are required.
• The more complex the project, the more likely it is that activities will overlap.
• Path convergence An activity having two or more activities directly preceding it on different paths is referred to as
path convergence.
• Path divergence An activity having two or more successor activities directly following it on different paths is referred
to as path divergence.
• Both path convergence and divergence are indicators of risk within the impacted activities.
Example Using the simple example in figure 8.2, here is how to build a network diagram.
1. Put <Start> and <End> in shapes that distinguish them from the nodes (named activities).
2. From <Start>, create the first rectangle and label it Activity A.
3. Draw a line from Activity A and add another node, labeling this second node Activity B. The line indicates a
dependency connection between the two
4. Draw a line from Activity B and add another node, labeling this third node Activity C.
5. Add an <End> and draw a line from Activity C to <End>.
6. Repeat the process to add the second path (add Activities D and E; add lines between them and then a line to
<End>. The network diagram is ready for the activity duration estimate data.
Complex project schedule network diagrams that include leads and lags as well as other dependencies are best done
with an automated scheduling system that is part of the PMIS. You will be expected to answer questions on the exam
related to interpreting information these diagrams provide. You need to have worked with network diagrams to accurately
answer such questions.
In summary, network diagrams can be used to:
• Help justify the project manager s time estimate for the project.
• Aid in effectively planning, organizing, and controlling the project.
• Show interdependencies of all activities, and thereby identify riskier activities.
• Show workflow so the team will know what activities need to happen in a specific sequence.
• Identify opportunities to compress the schedule in planning and throughout the life of the project (explained later in
this chapter).
• Show project progress and help with forecasting. This is used for controlling the schedule and reporting, and is related
to earned value measurement (EVM). EVM is related to scope, schedule, and cost, and is covered in the “Budget and
Resources” chapter.
196
EIGHT Schedule
Estimating Activity Durations

When the activities have been defined and sequenced, the next step is to estimate how Process Groups Model
long each activity will take. This is the Estimate Activity Durations process. When PG: Planning
possible, estimators should be those who will be doing the work, or on large projects, Process: Estimate Activity Durations
members of the project management team most familiar with the specific work to be
done. ECO
Both the Estimate Activity Durations and Estimate Costs (in the “Budget and Domain II
Resources” chapter) processes involve estimating. Historically, the exam has focused
on the methods required to produce good estimates more than on calculations. PMBOK® Guide
Use this checklist to evaluate your understanding of activity and schedule Domain 2.4 Planning
estimating. Identify gaps that may impact how you answer exam questions. Keep
track of items you currently do not do in your project work and pay extra attention to
studying these topics. Remember, bad project management practices (like padding estimates, for example) may be listed
as choices on the exam.
Think About It. Things to Know About Estimating for the Exam
j Management plans provide the approach to estimating.
DThe project manager and team may use one or many techniques to estimate project work.
Estimating should be based on small amounts of work, from a WBS or from story cards in agile. This
improves accuracy.
Duration, cost, and resource estimates are interrelated. Duration and resource estimates often impact cost estimates.
Identified risks must be considered when estimating the duration, cost, and resource requirements of project
work. Risk management actions are specific line items in a project contingency reserve (part of the budget). For
agile risk management actions are represented as stories in the backlog.
Estimating duration, cost, and resource requirements may uncover additional risks.
Estimating should be done by those doing the work or those most familiar with it to improve accuracy.
Historical information from past projects (part of organizational process assets) is often key to getting started and
improving estimates.
Estimates are more accurate on smaller-size work components.
A project manager doesn’t just accept management-given constraints. They evaluate project requirements, develop
estimates with the team and reconcile differences, producing a realistic plan.
The project manager may periodically recalculate the estimate to complete (ETC) for the project to ensure
adequate time, funds, and resources for the project (getting needed approved changes). ETC and other project
control metrics are discussed in the “Budget and Resources” chapter.
Plans based on estimates should be revised, with approved changes, during completion of the work, as necessary.
There is a process in the project management plan to create the most accurate estimate possible.
Padding estimates is not an acceptable project management practice.
The project manager must meet any agreed-upon estimates.
Estimates (from team members or sellers) must be reviewed to ensure they are reasonable and do not contain
padding or unidentified risks.
Estimates must be kept realistic throughout the project by re-estimating periodically as needed.
Estimates can be positively impacted by reducing or eliminating risks.
The project manager has a professional accountability to (with the help of the team) provide estimates that are as
accurate as feasible, and to maintain the integrity of those estimates throughout the project.
197
Schedule EIGHT
Inputs to Good Activity Estimates

To arrive at realistic time estimates, these individuals need to have access to the following:
Activity List and Activity Attributes The relevant inputs may include the time for required leads or lags between
activities, which must be factored in to duration estimates.
Assumption Log Assumptions or constraints that contribute to risk within the activities to be estimated should be
found here.
Lessons Learned Register Information relevant to the duration of activities include lessons learned from earlier in the
current project or from past, similar projects within the organization.
Resource Breakdown Structure Created in the Estimate Activity Resources process (of Resource Management), the
resource breakdown structure shows categories of resources required for the project.
Resource Requirements These requirements indicate the skills needed from resources to perform specific project work.
Project Team Assignments Team assignments should include the number and experience level of individuals who have
been committed to the project.
Resource Calendars These calendars provide information on when key resources with specialized skills needed for
activities will be available. If the resources are not available within the timeframe of the project, the project manager needs
to estimate time for those to allow less experienced resources to do the work.
Risk Register The risk register may include identified threats and/or opportunities that should be reflected in the estimates.
The Knowledge to Avoid Padding A pad is extra time or cost added to an estimate because the estimator does not have
enough information or feels insecure in their estimating. It is not a viable way to plan a project. What is wrong with
padding? Think about how estimating works on your projects for a moment. Can you see how, if individual team members
pad their estimates, the project estimates become increasingly unreliable? In turn, padding undermines the ability to create
a realistic schedule and budget.
In cases where the information required to clarify the unknowns is unavailable, the potential need for additional time
or funds should be addressed with reserves within the risk management process. Through risk management, uncertainties
are turned into identifiable opportunities and threats. Uncertainties then do not remain hidden.
Remember it is a PMI-ism that proper project management has been done unless an exam question indicates
otherwise. There is no need for padding when the following is in place in a properly managed project:
• The estimators have a WBS and may even have helped create it.
• They also have a description of each work package (the WBS dictionary) and may have helped create that as well.
• They may even have helped create the activity list from the work packages.
• Three-point estimates can be used, which by averaging the worst-case scenario, the most likely scenario, and the best
case scenario, builds uncertainty into the estimate.
• The estimators know there will be time and cost reserves on the project determined through the risk management
process to address identified risks.
198
EIGHT Schedule
How Estimating Is Done

The part of the team doing the estimating may use one or many techniques as identified earlier in the schedule
management plan.
First, lets look at the project manager s role in estimating. The project manager s role here is to:
• Provide the team with enough information to properly estimate each activity.
• Let those doing the estimating know how refined their estimates must be.
• Complete a sanity check of the estimates.
• Prevent padding.
• Formulate a reserve (more on this in the “Risks and Issues” chapter).
• Make sure assumptions made during estimating are recorded for later review.
Now let’s look at estimating techniques that may be used on a project. We have organized the following two sections
into predictive and adaptive estimating techniques. These methods are generally used with these approaches and are likely
to appear on the exam in these contexts. However, any variety of these techniques may be used, especially with a
hybrid approach.
Methods for Predictive Estimating

Traditional projects use the following methods for estimating. Analogous estimating is an example of an estimating practice
applicable to both predictive and adaptive approaches.
Analogous Estimating (top-down) Analogous estimating uses expert judgment and historical information to estimate.
It can be applicable to time, cost, and resources. It is usually not considered definitive. For example, management or the
sponsor might use analogous estimating for high-level estimation while establishing a business case and for project
selection. As the project is chartered the project manager may use analogous estimating at the project level, using historical
data from past, similar projects. For example, “the last five projects similar to this one each took eight months, so this one
should as well.” Analogous estimates are refined later during planning.
Analogous estimating can also be used at the activity level if the activity has been done on previous projects and if
there is substantial historical data to support accuracy. For example, “This company has created many thousands of
programming modules and they have taken an average of X hours so we will use that as a starting point.”
On the other hand, analogous estimates are used when there are little supporting data. For example, “The last two
times this activity was done each took three days. Since we have no other data to go on, we will estimate three days and
review estimates as we learn more details.”
For the exam, know analogous estimating can be done at various times. It is usually not thought to be definitive
TRICKS
OF THE but the level of accuracy can also depend on how much analogous data are available and how closely the project
TRADE* or activity matches the historical record.
Bottom-up Estimating
This method involves creating detailed estimates for each activity or work package, using an accurate WBS. The individual
estimates are then rolled up into control accounts and finally into an overall project estimate. You will see how these
estimates roll up into a budget in the “Budget and Resources” chapter.
Parametric Estimating
Parametric estimating involves a mathematical equation using data from historical records or other sources, such as
industry requirements or standard metrics. The technique analyzes relationships between historical data and other
variables to estimate duration or cost. It can be applied to some or all the activities within a project. For example, when
estimating activity duration, the estimator may use measures such as time per line of code, time per linear meter, or time
per installation. When used in cost estimating, the measures include cost as one of the variables. So the measures would be
cost per line of code, cost per linear meter, etc.
199
Schedule EIGHT
An estimator might create parametric estimates using the following:
Regression Analysis (Scatter Diagram) This diagram tracks two variables to see if they are related; the diagram is then
used to create a mathematical formula for future parametric estimating. Figure 8.5 shows an example of a scatter diagram.
Learning Curve (by example): The 100th room painted will take less time than the first room because of
improved efficiency.
FIGURE 8.5 Regression analysis (scatter diagram)
Single-point Estimating (One-point Estimating)

This type is based on a single estimate; however, it can be problematic. For example, the person doing the estimate may say
that an activity will take five weeks. This may be based on expert judgment or historical information, or it could be just
a guess.
One-point estimating can have the following negative effects on the project:
• Being limited to making a one-point estimate may encourage people to pad their estimates since it doesn’t include
best- and worst-case scenarios.
• When a persons one-point estimates turn out flawed—for example an activity takes 15 days instead of an estimated
20, it can make the project estimates and estimators seem unreliable.
• One-point estimating can result in a schedule that no one believes in, thus decreasing buy-in to the project
management process.
We can come together to use single numbers for project activity estimates, for example, using a more realistic
estimating method like three-point estimating, covered next. For each activity, it is easier to use a single number (of days,
for example) to draw a network diagram and find the project s critical path. On the exam, one-point estimates allow for
quick calculation (if a question supports that) and demonstrates that you understand concepts such as the critical path.
Three-Point Estimating (a version of multi-point estimating)

Estimates are best given in a range since there is a very small probability of completing a project on exactly any one date.
Three-point estimates are the best known of multi-point estimating techniques.
Three-point estimates better account for uncertainty: What could go right (opportunities) and what could go wrong
(threats), to help estimators determine an expected range. This way the project manager can better understand the potential
variation of the activity estimates.
There are two ways of calculating three-point estimates for the exam, as follows. Memorize these formulas and
remember they can be used for both time and cost estimates:
Triangular Distribution (Simple Average) A triangular distribution of the three-point estimates can be calculated using
the formula (P + O + M)/3. The use of simple averaging gives equal weight to each of the three-point estimates when
calculating the expected activity duration or cost. Using this formula, the risks (or the uncertainties, which are the P and
O estimates) are considered equally along with the most likely (M) estimate.
200
EIGHT Schedule
Beta Distribution (Weighted Average) The beta distribution (a weighted average) gives more consideration to the most
likely (M) estimate. This method uses the formula (P + 4M + O)/6, a weighted average. When a good risk management
process is followed, the most likely estimates are more accurate because risk response plans have been developed to deal
with identified opportunities and threats that have been factored into the pessimistic and optimistic estimates.
Think About It. For the exam, know these formulas and how they are applied to estimating.
Expected activity duration Expected activity duration

(triangular distribution) (beta distribution)
P+M+0 P + 4M + 0
3 6
Legend: P = Pessimistic, M Most likely, 0 = Optimistic
FIGURE 8.6 Three-point estimating formulas
If you are asked to calculate the activity duration or cost, read the situation carefully to determine which
TRICKS
OF THE formula to use. Terms like “simple” or “straight” refer to triangular distribution. “Weighted” refers to beta
TRADE. distribution. Knowing this will help you choose the correct formula.
You may be asked to perform a calculation or just analyze information to determine which formula is best for the
scenario. Use triangular distribution if the scenario indicates that the project manager doesn’t have a lot of experience or
historical information; it provides a straight average. Use beta distribution when there are historical data or samples to
work with. Most of exam questions relating to this are relatively simple and may require assessment but not calculations.
But the calculations are not difficult and the following exercises can help you prepare for them. First, review the three-point
estimating formulas in figure 8.6.
8.1 Exercise (Triangular Distribution)

Calculate the expected activity duration using triangular distribution. You may write the answer here or use your
Exercise Notebook. All estimates are in hours.
Activity P M 0 Expected Duration

A 47 27 14
B 89 60 41
C 48 44 39
D 42 37 29
Answer (Triangular Distribution)
Activity Expected Duration

A 29.33
B 63.33
C 43.66
D 36
Schedule EIGHT
8.2 Exercise (Beta Distribution)

Calculate the expected activity duration using beta distribution. You may write the answer here or use your Exercise
Notebook. All estimates are in hours.
Activity P M 0 Expected Duration

A 47 27 14
B 89 60 41
C 48 44 39
D 42 37 29
Answer (Beta Distribution)
Activity Expected Duration

A 28.17
B 61.67
C 43.83
D 36.50
Compare the answers using triangular distribution to the answers for the beta distribution. It may seem that the
results are not significantly different, but think about it in terms of a cumulative effect with many activities.
Activity Standard Deviation This concept describes a possible range for an estimate.
Example An activity estimate of 30 hours with a standard deviation of +/- 2 is expected to take between 28 hours
and 32 hours.
Think About It. You won’t be asked to calculate “beta activity standard deviation,” or (P - O)/6 but interpreting
) it in a situational question is important. Think through the following so you understand it.
To establish a range for an individual activity estimate using weighted (beta) averaging, you need to know the beta
expected activity duration (EAD) and the beta activity standard deviation (SD). The SD is likely to be given. You calculate
the range using beta EAD +/- SD.
The start of the range is beta EAD - SD, and the end of the range is beta EAD + SD. Review the following table to see
how the information is presented. Keep in mind that the exam scenario may include information for you to do the same
evaluation with triangular distribution.
Beta Activity
Activity P M 0 Expected Duration Standard Deviation Range of the Estimate
A 47 27 14 28.167 5.500 22.667 to 33.667, or
28.167 +/- 5.500
B 89 60 41 61.667 8.000 53.667 to 69.667, or
61.667 +/- 8.000
c 48 44 39 43.833 1.500 42.333 to 45.333, or
43.833 +/- 1.500
D 42 37 29 36.500 2.167 34.333 to 38.667, or
36.500 +/- 2.167
202
EIGHT Schedule
Additional points to know:

• Understand that estimates of time (or cost) should be in a range.
• Although there is a standard deviation formula for triangular distribution, it’s complicated and is unlikely to be on the
exam so we are not showing it here. What you need to remember for the exam is that the greater the standard deviation,
the greater the risk.
• The formulas we’ve been discussing relate to activities. The exam concentrates on three-point estimates to find ranges
for activity duration and cost estimates. Be prepared to do simple calculations using these formulas
• You may also see beta total project duration used in questions that require you to evaluate the situation rather than do
a calculation (Example: The project duration is 35 months plus or minus 3 months). As with an activity, the greater
the range for the project, the greater the risk.
• You can use these concepts to better monitor and control projects. The expected durations help you know the potential
variances on your project and determine appropriate courses of action.
• You can use estimated ranges and standard deviation to assess risk. Looking back at the table presenting beta standard
deviation, which activity has the most risk? The answer is Activity B. It has the widest range and the highest standard
deviation, and is therefore likely to have the greatest risk.
Methods for Adaptive Estimating

It is worth repeating that while we have organized these sections into predictive and adaptive estimating
techniques, any variety of these techniques may be used with approaches from predictive to hybrid to
adaptive. For example, although it is common to think about “affinity estimating” in an agile context,
categorizing activities on predictive projects into those taking more or less than 40 hours to complete is also
a form of affinity estimating.
Adaptive estimating is done in stages, using progressive elaboration. Story collection estimating typically begins with
“t-shirt sizing” for the initial plan, which is refined during release and iteration planning, and throughout the project.
Affinity Estimating
This is a technique where groups of similar items are grouped into collections—i.e., “affinities.” For example, placing user
stories into size categories makes it easier to see whether stories with similar estimates are, in fact, comparable in size.
T-shirt Sizing
A form of affinity estimating, or grouping like items together, t-shirt sizing is an approach to estimating product features
and user stories early in the project. The team is not yet trying to generate thorough estimates. They are aiming for high-
level (course-grained) estimates, sufficient to map out the overall project effort.
Here is an example from a project for an online movie service. The team has identified six features:
ES s M L XL XXL
Sort movies Rate movies Browse Rent movies Sell movies
by year movies
Review
movies
FIGURE 8.7 Features by t-shirt size
The results of the sizing effort are shown in figure 8.7. As you can see, it’s been decided that:
• “Sort movies by year” will require the least effort to build; this is Extra Small.
• Two features that we think will take Medium effort are “Browse movies”; “Review movies.”
• An online shopping cart for “Sell Movies” will require the most effort; this is Extra Large.
• None of these features will require an Extra-Extra-Large effort.
203
Schedule EIGHT
Once the team has identified

the features, they will decompose
ES s
them into user stories. In figure 8.8, Sort movies Rate
the user story cards are stacked by year movies
under each column. These user 2 user stories 5 user stories
B
story cards represent the work
estimated by the team to be done to
e
build the product.
You can see at a glance what
will take the most effort to build
(“Sell movies” with 14 user stories)
and what will take the least (“Sort Review
movies by year” with 2 user stories). movies
9 user stories
It also appears that “Rent
movies,” which was sized Large,
might actually be smaller than
“Browse movies” and “Review
movies,” which were sized Medium.
However, the team has not yet
determined the relative size of the
stories. Some of the stories may be FIGURE 8.8 Features and user stories
very small, and others may be very
large. The team has to estimate all
the user stories in t-shirt sizes, like ES S M L XL XXL
they did for the features.
After that, they can also use
affinity estimating to ensure the
stories in each category are
comparable in size. The stories
based on t-shirt sizes might look
something like figure 8.9.
Now that all the stories have
been sized, the team can use the
relative sizes of the stories in each
feature to refine their t-shirt
FIGURE 8.9 User stories by t-shirt size
estimates for each one. For
example, let’s say they find out that,
on average, the stories in “Rent movies” are larger than the stories in “Browse movies” or “Review movies.” Then “Rent
movies” will require more effort than the two Medium features, as originally thought.
Planning Poker*
Planning Poker* is a common and collaborative game using relative sizing. The goal is not to create precise estimates. It
aims to help the team quickly and efficiently reach consensus on reasonable estimates. The project can keep moving forward.
Here’s how to play. An agile team gathers to estimate the stories that need to be built. Each player gets a set of cards
with the numbers as shown in figure 8.10. Someone reads a story and each player evaluates it for the work effort they think
it requires. The estimating process continues as follows.
m
EIGHT Schedule
Remember these stories are in a backlog that the product owner has prioritized.
1. All at once (to avoid group think), each team member throws down a card (representing a number of story points).
2. The group discusses differences. As they do this, they are discussing the work involved in each story.
3. As needed, they play another estimating round or two before coming to consensus on the number of points
assigned to the story.
4. They repeat this for all stories needing estimates.
5. For the project’s first iteration the team estimates how many stories they think they can complete.
6. Once the first iteration is complete, they compare estimated to actual story points completed.
7. The actual number of completed story points is used to select stories for the next iteration.
8. After a few iterations they can average their story points for a working average, or velocity, of story points completed
per iteration. They can adjust velocity as appropriate throughout the project.
It is important to note that story points have no value except as measured against other stories in the same project. Be
careful if an exam question talks about comparing two team velocities (speed at which they can build stories). Comparing
two teams’ velocities on two different projects is not relevant or useful.
Methods for Data Analysis

The process Estimate Activity Durations uses two forms of data analysis: alternatives analysis and reserve analysis.
Alternatives Analysis
When activity estimates are not acceptable within the constraints of the project, alternatives analysis is used to look more
closely at the variables that impact the estimates.
Example Comparing options such as outsourcing work versus completing it internally to meet a schedule constraint.
Alternatives analysis involves evaluating the impact of each option on project constraints, including cost versus time saved
and level of risk. This process will result in the determination of the best approach to complete project work within
the constraints.
Reserve Analysis
This connects the topics of estimating and risk management. Estimating helps to identify more risks. Risk management
reduces uncertainty in time and cost estimates. This is accomplished by evaluating and planning for significant opportunities
and threats, including how they will be dealt with if they occur. Risk management saves the project time and money!
As described in the “Risks and Issues” chapter, two types of reserves can be added to the project schedule (and
budget): contingency reserves and management reserves.
Contingency Reserves Contingency reserves are allocated in the schedule baseline for identified risks after the Plan Risk
Responses process. Significant risks to critical path activities may be managed by allocating a specific amount of schedule
reserve. Employing contingency plans using contingency reserves helps keep the project within the schedule baseline.
Management Reserves These are additional funds and time to cover unforeseen risks (or “unknown unknowns”) that
may impact the ability to meet the schedule. Management reserves are not part of the schedule baseline. They may not be
applied at the project manager s discretion. They require approval through the change control system.
205
Schedule EIGHT
Methods for Decision Making

We’ve said that involving team members in estimating is beneficial because those most familiar with the work have the best
understanding of the time required to complete each effort. This and the team’s inclusion in decision making increases
their buy-in to the resulting schedule. Here are some group decision-making methods that are useful in project estimating
- and in many types of decision making. Each are a variation on using voting in decision making.
Plurality, Majority, or Unanimity

On plan-driven projects, the project manager may take a simple vote to reach one of these, depending on the circumstances.
Take the example of a scheduling decision regarding a small activity that is far into the future of the project and not on the
critical path. The project manager may reach this decision with a simple plurality agreement, while one regarding an activity
on the critical path in the near future may require a majority or unanimous agreement.
Roman Voting
Here people phyiscally show their level of support for a decision with a simple “thumbs up, thumbs down” voting style.
“Thumbs sideways” can also be used for those who are not sure of their vote or have misgivings.
Fist of Five
This voting technique is commonly used on change-driven projects (and also called “fist to five”). In this
variation, a closed fist indicates a zero (no support) and an open fist indicates five (full support). Team
members who are not supportive (who showed two or fewer fingers in the vote) share why they are not in
support of the option. Voting is repeated until everyone in the group indicates their support by showing at
least three fingers.
Artifacts of Schedule Estimating

When the Estimate Activity Durations process is complete—including risk management processes—the
project manager will have estimates, including reserves. Here are summaries of outputs from this process re
lated to both predictive and adaptive projects. These may be already-existing artifacts that are being updated.
Predictive Project Outputs Adaptive Project Outputs

— Activity attributes — Prioritized backlog of user stories
—Assumption log updates — Coarse-grained estimates of user stories
— Lessons learned register updates — Release goal focused on customer value
— Target release date or release number
Basis of Estimates Another artifact of estimating activity durations, the basis of estimates, explains how estimates were
derived, including assumptions, constraints, what risks were taken into consideration. Basis of estimates also includes the
confidence level for the estimates, expressed as a range, such as plus or minus 20% within which the actual project results
are expected to fall.
206
EIGHT Schedule
Develop Schedule
Once the network diagram and activity duration estimates are completed—or for ag Process Groups Model
ile a release plan, feature and story prioritization in a backlog, and estimates—it is PG: Planning
time to create a schedule model. This can be done using a variety of software tools Process: Develop Schedule
within a PMIS.
For traditional projects, the schedule model is the first schedule rendition and ECO
may be updated throughout the project based on approved changes. During the Domain II
original project planning it is iterated until ready for approval. It is created using
project data gathered thus far, including: PMBOK® Guide
• Activities • Dependencies Domain 2.4 Planning
• Start dates (for activities without dependencies) • Leads and lags
• Duration estimates
Think About It. Representations of the schedule include milestone charts and bar charts (as often shown
♦ through Gantt chart view in project management software). Once approved, the schedule becomes part of the
projects baseline (which is part of the project management plan). It is calendar-based, comprehensive, and
realistic. Inherent in it are contingency reserves to manage risk. Consider what creating a schedule model involves.
Let’s start at the beginning. What do you need before you can develop a schedule for your project? To develop a
schedule, you need to have:
• Historical records of previous, similar projects • Activity duration estimates
including lessons learned • Resource requirements estimates
• Schedule management plan and scope baseline • Resource calendars
• Defined activities (activity list and attributes) • The required resources by category (resource
• Milestone list breakdown structure)
• Assumption log • A company calendar identifying working and
• The order in which the work will be done nonworking days
(network diagram) • Already existing project team assignments list
• Basis of estimates • Risk register
8.3 Exercise
As a project manager, you need to use the estimating data and other inputs to create a schedule that you will be able
to stake your reputation on meeting. What do you need to do to create such a schedule? Write the answer in your
Exercise Notebook.
207
Schedule EIGHT
Answer
The Develop Schedule process really includes everything you need to do to develop a finalized schedule that is
bought into, approved, realistic, and formal. This is what developing the schedule is all about. What do you need to
do to get it to that level?
• Work with stakeholders’ priorities.
• Look for alternative ways to complete the work.
• Look for impacts on other projects and on operations.
• Take into consideration the skill levels and availability of known resources assigned to the team.
• Apply leads and lags to the schedule.
• Compress the schedule by crashing, fast tracking, and reestimating.
• Adjust components of the project management plan as necessary (for example, change the WBS to reflect
planned risk responses).
• Input the data into a scheduling tool and perform calculations to determine the optimum schedule.
• Simulate the project using Monte Carlo and other analysis techniques to determine the likelihood of
completing the project as scheduled.
• Optimize resources if necessary.
• Give the team a chance to approve the final schedule; they should review the calendar allocation of their
estimates to see if they are still feasible.
• Conduct meetings and conversations to gain stakeholder buy-in and formal management approval.
The Develop Schedule process is iterative and can occur many times over the life of the project (at least once per
project life cycle phase on a large project). The Develop Schedule process is a source of problems on the exam for many
project managers. The exam will test you as an expert in handling schedule development during project planning and
whenever there are changes to the project.
Schedule Network Analysis

Schedule network analysis is used to analyze and iterate the schedule model until the project schedule is approved. This
analysis may use one or more of the following techniques:
• Critical path method • Resource optimization
• Schedule compression • Agile release planning
• What-if analysis (e.g. Monte Carlo analysis)
Critical Path Method

The critical path method involves determining the earliest and latest times each activity can start, and the earliest and latest
times each can be completed. In software this can be done by entering activity start dates and durations. Where activities
have dependent activities following (or succeeding) them, the software can calculate succeeding start and finish dates
using duration data. Understanding this method requires you to understand the following basic concepts.
Using the Critical Path As the longest duration path through a network diagram, the critical path determines the shortest
possible duration for the project. It is along this path that there is the least schedule flexibility. The easiest way to find the
critical path is to identify all paths through the network diagram and add the activity durations along each path. The path
with the longest duration is the critical path. Be sure you do the exercises that follow and practice doing this work for
the exam.
208
EIGHT Schedule
Near-Critical Path This path is closest in duration to the critical path and should also be watched closely. The closer in
length the critical and near-critical paths are, the more risk the project has. Close monitoring and controlling activities on
both the critical and near-critical paths (yes, there can be more than one) is needed to ensure the project can finish on time.
Using Float For the exam, you should understand float and be able to calculate it. Note that the terms “float” and “slack”
mean the same thing. Slack is an older term and is rarely used anymore. It is unlikely that you will see it on the exam but
know it just in case it is used. Here are the three types of float to know for the exam.
• Total float The amount of time an activity can be delayed without delaying the project end date (or an intermediary
milestone) while still adhering to imposed schedule constraints.
• Free float This is the amount of time an activity can be delayed without delaying the early start date of its successor(s)
while still adhering to imposed schedule constraints.
• Project float Also known as positive total float, this is the amount of time a project can be delayed without delaying
an externally imposed project completion date required by the customer or management, or the date previously
committed to by the project manager.
Other things to know about float are:

• Activities on the critical path have zero float.
• Total and free float are related to activities.
• Project float is specific to the entire project.
• Negative float results when externally imposed completion dates are not feasible. These issues must be addressed in
planning to ensure the approved schedule is achievable.
• If critical path activities are delayed, negative float analysis helps in looking for corrective actions to bring the schedule
back within the schedule baseline.
When you know the critical path(s) and near-critical path(s), you can use float as a way to achieve better allocation of
resources.
Example If you have a resource who has the needed skill set but is not very experienced, you can assign them to work
on activities with float. Even if their activities take longer, the project is less likely to be delayed.
Knowing float also helps team members juggle their work on multiple projects. The amount of float tells them how
much time flexibility they may have for each activity they are assigned to. Collaborating with the project manager, they may
flex the exact start time of some activities with float.
Sometimes the exam questions are presented in such a way that you can simply see the amount of float, but other
times you will need to calculate it. Float is calculated using either of the following equations:
• Float = Late finish (LF) - Early finish (EF)
• Float = Late start (LS) - Early start (ES)
Either formula gets you the same answer. Here is a trick for remembering the formulas:
“There is a start formula and a finish formula, and we always begin late.” Notice that the formula uses either two
TRICKS
OF THE start or two finish data elements and each begins with late.
TRADE
Start Formula Finish Formula
Float = LS - ES Float = LF - EF
You determine whether to use the start or finish formula based on the information available.
Example An exam question says: “You have a late start of 30, an early start of 18, and a late finish of 34.” How do you
find the float? You know to subtract the two starts or the two finishes (using the previous trick). You have not been given
two finishes, so you use the equation 30-18, which equals 12.
209
Schedule EIGHT
Practice with the Critical Path Method
Think About It. Now that we have discussed the basic concepts, let’s look at how the critical path method
works. We’ll use the network diagram in figure 8.11 as an example. The letters in the boxes indicate the activities,
k and the numbers above the boxes indicate the duration of each activity. The critical path is identified by the
bold arrows.
FIGURE 8.11 Critical path method
• To determine the earliest and latest each activity can start, and the earliest and latest each activity can end, perform a
forward and backward pass through the network diagram.
• Forward pass The “early” figures are found by calculating from <Start> to <End> of the project, following the
dependencies in the network diagram.
• Backward pass The “late” figures are found by calculating from <End> to <Start> of the project, following the
dependencies in the network diagram.
Let’s start with the forward pass. You need to calculate through the activities from <Start> to <End>, determining
early starts and early finishes for all activities. This example uses zero as the early start for the first activity. Use figure 8.12
to walk through this.
Note: Some people, use 1 as the early start of the first activity; others use zero. Either method will get you the right
answer. Pick one method and use it consistently. We use zero as the first activity’s early start because people consistently
find it easier when learning this concept.
Activity name ES = Early start

Amount of float EF = Early finish
LS = Late start
LF LF = Late finish
FIGURE 8.12 Forward pass through network diagram
• It is important to look at path convergence (where paths meet). To calculate the early start and the early finish in a
forward pass, you must account for all the paths that lead into that activity (notice activities F and G in figure 8.12).
• The same concept applies to the backward pass. To calculate the late finish and late start you need to consider all paths
that flow backward into an activity (activities D and F in figure 8.12).
To make it easier to follow, we will step you through a forward pass here (EF and ES in parenthesis are early finish and
early start, respectively):
1. In figure 8.12, paths converge at activities F and G.
2. Therefore, you must do the forward pass on both paths leading up to activity F. So:
/ Calculate the early finishes for activities D (EF = 4) and A (EF = 3).
210
EIGHT Schedule
•/ Select the latest early finish between activities D and A. Use it as the early start for activity F (since F cannot
start until both D and A are complete).
Therefore, the early start of activity F is 4.
3. Use the same process for calculating the early finish of activities E (EF =13) and F (EF = 12), before determining
the early start of activity G (ES =13).
Once you have completed the forward pass, you can begin the backward pass, computing the late finish and late start
for each activity. The backward pass uses the duration of the critical path (in this case, 26) as the late finish of the last
activity (or activities) in the network diagram.
See figure 8.13 for the late start and late finish data.
Activity name ES = Early start

Amount of float EF = Early finish
LS = Late start
LF LF = Late finish
FIGURE 8.13 Backward pass through network diagram
1. Be careful at points where paths converge as you move through the network diagram.
2. Paths converge at activity F and at activity G.
3. Work from <End> backwards. First compute the late start of activities B (LS = 22) and G (LS = 13).
4. Select the earlier late start for the late finish of activity F (since activity F must be finished before either activity B
or G can start).
5. The late finish of activity F is 13.
6. This same process should be used on activities E (LS = 4) and F (LS =5) before calculating the late finish for
activity D (LF = 4).
Once you finish calculating the starts and finishes, you have the data required to calculate float. It’s time to use those
formulas.
What was that trick again? “There is a start formula and a finish formula, and we always begin late.” The
RICKS
)FTHE formulas are:
rRADE
Start Formula Finish Formula
(For Forward Pass) (For Backward Pass)
Float = LS - ES Float = LF - EF
The activities with zero float are on the critical path (see the bold arrows). See figure 8.14 for the float of each activity.
9 4
17
17
1 13 22 10 26
Duration
ES EF Key:
ES = Early start
Activity name
EF = Early finish
Amount of float
LS = Late start
LS LF LF = Late finish
FIGURE 8.14 Float of activities on network diagram

2
Schedule EIGHT
Think About It. Practice will help you understand these concepts better. As you do the following exercise, think
about how knowing float helps you manage your projects. On the exam there are not many questions requiring
you to do these calculations, and you may not be asked to draw a network diagram. But understanding this entire
process will help you get more questions right.
8.4 Exercise
Test yourself. In your Exercise Notebook, draw a network diagram based on the following information, and then
answer questions 1-7 below.
You are the project manager for a new project and have figured out the following dependencies:
• Activity 1 can start immediately and has an estimated duration of 3 weeks.
• Activity 2 can start after activity 1 is completed and has an estimated duration of 3 weeks.
• Activity 5 can start after activity 4 is completed and after activity 3 is completed. This activity takes 4 weeks.
Questions:
1. What is the duration of the critical path?
2. What is the float of activity 3?
3. What is the float of activity 2?
4. What is the float of the path with the most float?
5. The resource working on activity 3 is replaced with another resource who is less experienced. The activity will
now take 10 weeks. How will this affect the project schedule?
6. A new activity 6 is added to the project. It will take 11 weeks to complete and must be completed before
activity 5 and after activity 3. Management is concerned that adding the activity will add 11 weeks to the
project. Another stakeholder argues the time will be less than 11 weeks. Who is correct? Use the original
information (without the change to activity 3 listed in the previous question) to answer this question.
7. Based on the information in the previous question, how much longer will the project take?
Answer
There are many ways to answer these questions. If you learned another way in other project management training
and are comfortable with that method, use it. Here is a simple way to compute the answers.
1. The length of the critical path is 18. There are two paths here:
Paths Duration
Start, 1, 2,4, 5, End 18
Start, 1, 2,4, 5, End is the longest duration path and is therefore the critical path at 18 weeks.
212
EIGHT Schedule
2. The float of activity 3 is 5 weeks, per the following diagram, which shows how to calculate float using the
forward and backward pass.
You can use either float formula to compute float:

• Late finish - Early finish = 14 - 9 = 5, or
• Late start - Early start = 8-3 = 5.
3. The float of activity 2 is zero; it is on the critical path. An activity on the critical path generally has no float.
4. The float of the path with the longest float is 5 weeks. There are only two paths in this example:
a. Start, 1, 2,4,5, End and Start, 1, 3,5, End.
b. Only the non-critical path (Start, 1, 3, 5, End) will have float.
c. You can calculate the float for this path by adding the float for each activity: 0 + 5 + 0 = 5.
d. Therefore, the total float of the path with the longest float is 5.
5. The resource change on activity 3 will have no effect.
a. The length of path activities 1, 3, and 5 is 13.
b. Adding 4 more weeks to the length of activity 3 will make that path 17.
c. Since that path is still shorter than the critical path, the critical path does not change.
d. The length of the critical path is still 18 weeks because activity 3 is not on the critical path.
6. The stakeholder who says the time added to the project will be less than 11 weeks is correct.
a. The new activity will be added to a non-critical path that has a float of 5 weeks.
b. Therefore, adding 11 weeks will make this path the new critical path.
c. The effect of adding an activity that takes 11 weeks is a delay to the project of 6 weeks.
7. The project will take 6 weeks longer. (Note: If you answered 24, you did not read the question correctly!)
Follow the bold arrows in the following diagram.
Note: If you want more practice, there is an extra float and critical path exercise on the RMC Resources page
(rmcls.com/rmc-resources).
215
Schedule EIGHT
The following are good questions to practice concepts related to the critical path, float, and network diagrams:
TRICKS
OF THE • Can there be more than one critical path? Yes, you can have two, three, or many critical paths.
TRADE • Do you want there to be? No; having more than one critical path increases risk.
• Can a critical path change? Yes.
• Can there be negative float? Yes; it means you are behind schedule.
• How much float does the critical path have? In planning, the critical path generally has zero total float.
During project executing, if an activity on the critical path is completed earlier or later than planned, the
critical path may then have positive or negative float. Negative float on the critical path requires corrective
action or changes to the project to bring it back in line with the schedule baseline.
• Does the network diagram change when the end date changes? Not automatically, but the project manager
should investigate schedule compression options such as fast tracking and crashing, to meet the new date.
Then, with approved changes, the project manager should change the network diagram. See Schedule
compression in the next section of this chapter.
• Would you leave the project with negative float? No; you would compress the schedule. If schedule
compression efforts do not result in zero or positive float, you need to request a change to adjust the baseline.
If you manually create a network diagram while taking the exam, label it with the question number, in case you
TRICKS
OF THEwant to go back to it later. You may be able to reuse the same network diagram to answer additional questions
TRADE later in the exam.
It is easy to miss paths in a network diagram. When attempting to identify a critical path, carefully look at each path
to ensure you calculate them all before determining which is critical.
Methods for Schedule Compression

One of the most common problems on projects is a difficult or unrealistic timeframe. This problem can arise during
planning when management or the customer requires a completion date that cannot be met, or during executing when the
project needs to be brought back in line with the schedule baseline due to delays or changes. It is the project manager s
responsibility to present options and to make sure the project is achievable. Schedule network analysis techniques such as
schedule compression can help.
Schedule compression describes using methods such as fast tracking and crashing to decrease project length. Schedule
compression can be used during planning. Beyond the initial planning period, schedule compression may be used during
Perform Integrated Change Control and Control Schedule to evaluate options and manage the impacts of change. In this
case the objective would be to control the schedule without changing the schedule baseline.
Fast Tracking
This technique involves taking critical path activities that were originally planned to be completed sequentially and doing
them in parallel for some or all of their duration, as shown in figure 8.15. The down sides: Fast tracking often results in
rework, usually increases risk, and requires more attention to communication.
FIGURE 8.15 Fast tracking
Think About It. Which activity in figure 8.16 would you fast track to shorten the project?
EIGHT Schedule
Total length is 33 months
FIGURE 8.16 Which activity would you fast track?
Assuming the dependencies are discretionary:

• Activity H could be fast tracked by making it occur at the same time as (in parallel with) Activity G.
• Activities C and H could be fast tracked by doing part of Activity C in parallel with Activity H.
• Any other pair of activities on the critical path could possibly be fast tracked.
Think About It. Let’s look at an example scenario to help you further think about fast tracking and creating
options. This example may or may not have made use of a network diagram.
Example A cable TV provider was using a hybrid approach to implement web analytics tools. The team was
asked to fast track the product launch to coincide with a large marketing push in response to competition from
streaming channels.
• The product owner met with management to review the release map and product backlog.
• They identified scope that could be deferred until after initial launch, allowing most functionality to be
delivered on time and accommodate the new promotion.
• The customer could at first create some reports in spreadsheets rather than relying on the tool, and
some metrics could be eliminated from scope or deferred.
• The core data and decision-making frameworks would be delivered on time.
• Management approved the reduced functionality and workarounds.
• The team proceeded and delivered most of the business value in time for the campaign.
• The team prepared instructions and training for early buyers to mitigate the effects of a reduced
reporting functionality.
• A future release of the project completed the functionality and retired the spreadsheets.
Here, scope was compromised temporarily to fast track the schedule. This added some risk and reduced initial
functionality. Yet it was an effective way to meet a decreased schedule requirement.
Crashing
The schedule compression method called “crashing” involves adding or adjusting resources while maintaining the original
project scope. Crashing by definition results in increased costs. It trades time for money. It may also increase risk.
Example In the network diagram in figure 8.16, a contracted resource could supplement the internal resources
efforts on a critical path activity. Another option to crash the project might be to buy a software application. This assumes
either option adds cost but helps the team save time.
In the cable TV provider scenario, it may also be possible to crash by adding resources and get all the functionality
completed in time for the campaign. For the exam, remember that you need to identify all possible options and, if given a
choice between crashing or fast tracking, select the choice or combination of choices with the least negative impact on the
project, and adds the least risk.
Think About It. If you have negative project float (meaning the estimated completion date is after the desired
date), would your first choice be to tell the customer the date cannot be met and to ask for more time? No; the
first choice would be to analyze what could be done about the negative float by compressing the schedule. In
crashing or fast tracking, it is best to carefully consider all potential choices and then select the option or options
that have the least negative impact on the project and/or adds the least additional risk.
215
Schedule EIGHT
Many project managers have gaps in their knowledge in this area. Lets review another scenario. Figure 8.16 shows
that a project duration is estimated to be 33 months. But what if you’re given a constraint of 30 months? Options are listed
in the following table to illustrate how the project duration may be shortened by three months.
How to Achieve It Explanation

Option (or what it is called) (including assumptions made)
Reestimate. Reduce risks. Look at the estimates and see which contain hidden risks.
By reducing risks, estimates can often be lowered. This
way, the project finishes faster.
Execute Activities H and C Fast track (compress Will work if the dependency between activities H and C
in parallel. schedule). is discretionary. Or may add risk.
Add resources to Activity Crash (compress Would work if adding resources to activity G is practical
G from the within the schedule). and there are resources available.
organization (adds cost).
Cut Activity H. Reduce scope. Not the first choice as it may affect the customer; still,
reducing scope should be considered an option.
Hire consultants to assist Crash (compress Would work if adding external resources to these activities
on Activity G, H, or C schedule). is practical and resources are available.
(adds cost).
Move more experienced Compress schedule. Would work if some of the critical path activities are being
people to critical path done by less experienced people, and more experienced
activities (activities G, H, people are available.
or C).
Cut time by cutting quality. Lower quality Quality is a project constraint; lowering quality standards
(Do not get excited! Read standards. is an option. If it is feasible, it would probably be faster to
on.) complete the project with lowered quality standards.
Might add risk.
Get more work done with Work overtime. Not an option during project planning. There are many
the same number of other ways to compress a schedule that do not have the
resources. negative effects of overtime. Save it for a last resort.
Say no; the project must Say it can’t be done. A viable option only after other alternatives are exhausted.
have 33 months. Always endeavor to provide options.
Think About It. Now consider the following questions in thinking about which of the options listed are best.
There is no way to know since the scenario is limited. The goal here is, as always, to consider the impacts of
each one:
• Is the best option to cut time by lowering quality standards?
• What are the impacts of cutting quality?
• Is there another option?
• Why not do what many project managers do—ask for more resources? But adding resources also adds cost.
• Why not work overtime? Overtime is not free. Most organizations are working at close to 100 percent
capacity. The project team working overtime runs the risk of burnout. Also, the possibilities for responding to
emergencies for other projects are narrowed, putting other projects at risk. For the exam, don’t consider
overtime a viable option until all other options are exhausted.
• Generally, it’s best to look at risks and then reestimate. Once you know that the schedule (or budget) must
be reduced, investigate activity estimates that contain the most unknowns. Reduce or eliminate these risks,
thus decreasing the schedule. Eliminate more risks; everyone wins! If this offers only a partial solution, you
could continue looking to shorten the schedule with other methods.
216
EIGHT Schedule
Schedule Compression Summary

Look at the schedule compression options again, and review the impacts of each option. Note that these methods can
apply to a project using any life cycle and development approach.
Option General Impacts on the Project

Fast track • Always adds risk
• May add management time for the project manager
Crash • Always adds cost
• May add management time for the project manager
• May add risk
Reduce scope • May save cost, resources, and time
• May negatively impact customer satisfaction
Cut quality • May save cost, resources, and time
• May increase risk
• Requires good metrics on current and desired quality levels to be effective
• May negatively impact customer satisfaction
There is an additional schedule compression exercise on the RMC Resources page (rmcls.com/rmc-resources).
8.5 Exercise
Consider the following question and write the answer. You may choose to do so in your Exercise Notebook.
Management has said to get the project completed two weeks early. What is the best thing to do?
A. Consult the project sponsor
B. Crash
C. Fast track
D. Advise management of the impact of the change
Answer
Did you get fooled by this question? Did you think you had to choose between crashing and fast tracking? There is
no information provided to help you determine which one is better. Therefore, the best choice presented is D,
advise management of the impact of the change. This is the best choice because you will have to assess the impact
of the change and inform management of that no matter what else you do. There is no data to back up the other
possible answers.
The exam will include many such questions requiring you to know that a project manager needs to analyze first, create
options to deal with the change, and then let management, the sponsor, the customer, or other parties know the impacts of
their request (see the four-step process for handling changes in the “Integration” chapter). A project manager does not just
say yes! Instead, after analyzing the change for its impact on all areas of the project (cost, risk, resources, etc.), they could
say something like, “Yes, I would be happy to make the change, but the project will be delayed two weeks. And I will need
two more resources, or the project will cost $25,000 more.”
For questions about changes to the network diagram, make sure you look for shifts to new critical paths caused
by the changes to the network diagram or to activity durations.
217
Schedule EIGHT
Data Analysis and Simulation

In creating a finalized, realistic schedule, it is helpful to ask, “What if a particular factor changed on the project? Would that
produce a shorter schedule?” The assumptions for each activity can change and, therefore, the activity durations can also
change. One of the ways to calculate the effect of these changes is through what-if scenario analysis. One example is Monte
Carlo analysis.
Monte Carlo Analysis

This technique uses computer software to simulate the outcome of a project, based on the three-point estimates (optimistic,
pessimistic, and most likely) for each activity and the network diagram. It is more accurate than other methods because it
simulates the actual details of the project and calculates probability.
The simulation can tell you:
• The probability of completing the project on any specific day
• The probability of completing the project for any specific cost
• The probability of any activity actually being on the critical path
• An indication of the overall project risk
Monte Carlo analysis can help deal with “path convergence,” places in the network diagram where multiple paths
converge into one or more activities, thus adding risk to the project (see figure 8.17). Monte Carlo analysis is also used as
a risk management tool to quantitatively analyze risks (see the “Risk” chapter).
FIGURE 8.17 Path convergence

Resource Optimization
Resource optimization refers to finding ways to adjust the use of resources. There are two techniques that can achieve
this outcome.
Resource Leveling
Resource leveling is used to produce a resource-limited schedule. Leveling lengthens the schedule and increases cost to
deal with a limited number of resources, resource availability, and other resource constraints. A little-used function in
project management software, this technique allows you to level the peaks and valleys of the schedule from one month to
another, resulting in a more stable number of resources used on your project.
You might level the resources if your project used 5 resources one month, 15 the next, and 3 the next, or some other
up-and-down pattern that was not acceptable. Leveling could also be used if you did not have 15 resources available and
preferred to lengthen the project (which is a result of leveling) instead of hiring more resources.
Resource Smoothing
Resource smoothing is a modified form of resource leveling, where resources are leveled only within the limits of the float
of their activities, so the completion dates of activities are not delayed.
218
EIGHT Schedule
Agile Schedule Development

Agile teams attempt to keep schedule and cost stable while negotiating scope to make that happen. The
concept of float certainly applies to agile although agile practitioners do not always use the project schedule
network diagram. Instead, based upon the estimated story sizes and prioritization, an agile team will gather
stories for each iteration and estimate how much can be completed in a given iteration, adjusting estimates
until an average velocity is established.
Agile Release Planning

Agile projects are often divided into releases and iterations. An iteration is a short, timeboxed development period,
typically one to four weeks in duration. A release is a group of iterations that results in the completion of a valuable
deliverable on the project. An agile project will have one or more releases, each of which will contain one or more iterations,
as illustrated in figure 8.18.
10% -15% 80% - 85% 5%

Schedule Schedule <- Schedule ->
Upfront
H222 222 2 2 2 0* 2 2 2 0 Closeout
Planning
♦
/ \T7
Iteration 0 ' Development
iterations
Assuming your initial velocity is 20 pts/iteration

Stabilization (“Hardening")
Capacity per release = 60pts
Pre-release Iteration
FIGURE 8.18 Project broken into releases and iterations
This diagram shows a single project with four planned releases. Agile teams start planning releases and iterations early
in the project life cycle and progressively refine the planning effort multiple times as the project progresses.
Do you remember our discussion on the backlog and product roadmap in the “Scope” chapter? While the backlog
and the product roadmap help identify and manage project scope, they are also valuable tools that help develop and
manage the project schedule.
On agile projects, teams select from the top-priority backlog items to come up with their next iteration goal. Then,
they decompose the iteration goal into user stories to get
the iteration plan. Planning continues by decomposing
those user stories into tasks. While the work is being done,
the team discusses the details of the work in the daily
standup meetings.
Cumulative Flow Diagrams

Cumulative flow diagrams (CFDs) are valuable tools for
tracking and forecasting the delivery of value. They can help
the project manager gain insight into project issues, cycle
times, and likely completion dates. Basically, CFDs are
stacked area graphs that depict the features that are in
progress, remaining, and completed over time. An example
of a CFD is illustrated in figure 8.19.
This figure shows the features completed versus the
features remaining for a fictional project that is still in
progress. The orange area represents all the planned features Time
to be built. This number rose from 400 to 450 in June and
then to 500 in August as additional features were added to FIGURE 8.19 Cumulative flow example
219
Schedule EIGHT
the project. The dotted section plots the work in progress, and the striped section shows the total number of features
completed on the project.
Velocity
As mentioned in an earlier section of this chapter, teams establish an average velocity, which describes how much work
(what stories) can be completed in a given iteration. The team iteratively analyzes their actual velocity against the stories
in the backlog to be completed, so this practice works as a planning method and as a control method. Velocity works
like this:
• Before the first iteration of the project the team establishes a starting velocity. The metric is most often story points.
This helps estimate what stories can be completed in the first iteration.
• For the first iteration, the team selects and builds stories from the top of the prioritized backlog based on the
starting velocity.
• After the first iteration (not including iteration zero), the estimate is compared to what the team actually completed,
and for the second iteration the team will use the actual velocity from the first iteration. They select stories from the
top of the prioritized backlog based on this number.
• After several iterations the team has an average or working velocity. They will continue to select stories from the top of
the backlog based on average velocity. They recalculate the average velocity as it stabilizes.
FIGURE 8.20 Velocity tracking chart
Cautions on Story Point Estimates and Velocity

The use of story points is a relative estimating method that is very effective. But problems with this method can only be
avoided if teams use it properly and good leadership skills and communications ensure that other stakeholders understand
it. Story points in estimating and velocity in practice are strictly tailored to every team and every project. For analyzing
performance, the progress of no two teams can be compared based on story points or velocity, and no single team can
compare their story points or velocities from one project to the next.
Think About It. Consider this scenario. A hybrid team is using story points to track their velocity on a rewrite
of a customer account management website. The team is using short iterations and demos to deliver functionality
in a largely predictive organization. After the steering committee learned the team was using story points and
velocity to track their progress, they focused on the weekly velocity figures.
If the points completed did not increase each week, the team was asked to explain. Consciously or unconsciously, the
team started to inflate their story point estimates for work. That way, they would have more points to report as complete
each week. A screen that might have been originally estimated as three points became five. However, the points were now
meaningless to the team since they could not compare current to past performance. Questions like "are these five new
points or five old points?” became common wastes of time.
220
EIGHT Schedule
To reset the process, the team used affinity estimation to compare and reset new stories with the point value from
previous stories of comparable size and complexity. Story point inflation was reversed, and points became useful for the
team once more. The project manager explained the situation to the steering committee, who agreed not to focus on
weekly velocity but to use velocity only to track actual versus planned project progress across iterations toward a scheduled
release. The project manager no longer showed detailed velocity metrics to management but instead used graphics like the
following burndown chart. Figure 8.21 shows project progress over 4 iterations. It turns data into information, using
velocity but better representing project progress than would focusing on the actual velocity data.
Planned vs Actual Work toward Release 1
0 12 3 4
--------Planned Velocity ^—Actual Velocity ^—Planned Remaining ^—Actual Remaining
FIGURE 8.21 Progress tracking burndown chart
Outputs of Developing the Plan-driven Schedule

The Develop Schedule process results in the project schedule, the schedule baseline, schedule data, change requests, and
updates to any related project documents. The following sections describe these outputs.
Project Schedule
The project schedule is the result of the previous planning processes and the schedule network analysis that is performed
as part of the Develop Schedule process. As planning progresses, the schedule will be iterated in response to risk
management and other parts of project planning until an acceptable and realistic schedule can be agreed upon. The iterated
and realistic schedule that results from this effort is called the schedule baseline, which becomes part of the project
management plan.
The project schedule includes project activities with assigned dates for each activity, and includes milestones inserted
by the project manager or management. The project schedule may be represented in formats such as bar charts or
network diagrams.
The project schedule can be shown with or without dependencies (logical relationships) and can be shown in any of
the following presentations created from the schedule model, depending on the needs of the project:
• Network diagram (described earlier in this chapter)
• Milestone chart
• Bar chart
Schedule EIGHT
Milestone Charts
These are similar to bar charts (described next), but they only show major events. Remember that milestones have no
duration; they simply represent the completion of activities. Milestones, which may include “requirements are complete”
or “design is finished,” are part of the inputs to the Sequence Activities process. Milestone charts are good tools for reporting
to management and to the customer. See the example in figure 8.22.
ID Milestone December January February March April

1 Start ♦12/14
2 Requirements
gathered 4 ►12/31
3 Design
complete ♦1/17
4 Coding
complete ♦2/15
5 Testing
complete ♦3/15
6 Implementation
complete ♦4/4
7 End ♦4/15
FIGURE 8.22 Milestone chart
Bar Charts
Bar charts are weak planning tools, but they are effective for progress reporting and control. They are not project
management plans. The velocity tracking chart in figure 8.20 is a bar chart.
Schedule Baseline
The schedule baseline is the approved version of the schedule model used to manage the project; what the project and
team performance is measured against. On plan-based projects the baseline can only be changed as a result of formally
approved changes. If the project can be done faster than the customer requested, there may be a difference between the
schedule baseline and the end date required by the customer. This difference is project float. Agile projects tend to have a
“moving baseline” for velocity but it is assumed that this will soon stabilize after a few iterations. Agile project schedules
are normally baselined since exact scope is negotiable.
Schedule Data Schedule data encompasses all the data used to create the schedule model, including milestones, project
activities, activity attributes, duration estimates, dependencies, and the assumptions and constraints used in creating
the schedule.
Change Requests This is another planning process with change requests as an output. As the project progresses, any
changes to the schedule may necessitate changes to other parts of the project management plan. Change requests are
addressed through the integrated change control process.
Project Documents Updates The process of creating a final and realistic schedule could result in updates to project
documents including duration estimates, resource requirements, activity attributes, risk register, assumption log, and the
lessons learned register.
Understanding the Benefits of Different Presentation Formats

No matter how much you know about project management, there are always questions on the exam that will be tricky if
you have never thought about them before. The different types of schedule presentations can be one of those areas. Think
through the next exercise. Make sure you look for anything you did not know, and organize your knowledge according to
the exercise answers. You can get quite a few questions right on the exam if you know what each of the schedule presentations
is used for.
222
EIGHT Schedule
8.6 Exercise
Test yourself! In your Exercise Notebook, record the answers to the following questions.
1. Under what circumstances would you use a network diagram?
2. Under what circumstances would you use a milestone chart?
3. Under what circumstances would you use a bar chart?
Answer
1. To show interdependencies between activities; to calculate the critical path; to show the length of the project
2. To report to senior management
3. To track progress; to report to the team
Control Schedule
A major measure of project (and project manager) success is the schedule baseline—
the end date agreed to in planning and adjusted for approved changes—being met. PG: Monitoring and Controlling
Monitoring and controlling efforts and taking preventive and corrective action Process: Control Schedule
throughout the project keeps it in line with the plan. This is as important to the proj
ect’s success as planning it well. ECO
Schedule control includes looking for the things that are causing preventable Domain II
changes and influencing the sources, or root causes, of the changes.
Example There is one person or one piece of work causing a lot of changes. PMBOK8 Guide
This is a signal that the project manager and team need to evaluate it and do something Domain 2.7 Measurement
about it rather than letting the issues and the high number of changes continue. Using
diligence and being proactive is the key to success.
If the project can no longer meet the agreed-upon completion date, and achieving the completion date is a critical
factor for success of the project, the project manager might recommend the termination of the project before any more
company time is wasted.
Think of schedule control as protecting the hard work of all those involved in planning to make sure what was planned
occurs as close to the plan as possible. Think of being constantly on the lookout for anything that might be affecting the
schedule. The following are some activities that can be used to help control the schedule:
• Access the PMIS to review current work performance data and compare actual progress to what was planned.
• Reestimate the remaining components of the project partway through the project (see the following discussion).
• Conduct performance reviews by formally analyzing how the project is doing (see the Earned Value Management
discussion in the “Budget and Resources” chapter).
• Perform data analysis (this can include earned value analysis, trend analysis, variance analysis, and what-if scenario
analysis) of project performance.
• Confirm that critical path activities are being completed within the schedule baseline. If they are not, adjust the critical
path by taking advantage of available float.
• Adjust future parts of the project to deal with delays, rather than asking for a schedule extension (using schedule
compression techniques such as leads and lags, crashing, and fast tracking).
• Consider adjusting to optimize resources assigned to activities to improve the performance.
• Continue efforts to optimize the schedule.
• Adjust metrics that are not giving the project manager the information needed to properly understand performance
and manage the project. Add new metrics if needed.
223
Schedule EIGHT
• Adjust the format or required content of reports as needed to capture the information necessary to control and
manage the project (see the Progress Reporting discussion in the “Budget and Resources” chapter).
• Identify the need for changes, including corrective and preventive actions.
• Follow the change control process.
Efforts to control the schedule when the project is using a change-driven approach include:
• Comparing work actually completed to what was predicted to be complete within a given work cycle using an iteration
burndown chart.
• Holding retrospectives to address possible process improvements.
• Reprioritizing the backlog of work.
• Identifying and managing changes as they arise.
Methods for Control Schedule

Although the project manager did their best to understand the project well enough to estimate it sufficiently in planning,
there are always changes that occur during a project that impacts those plans. Measuring performance on a regular basis,
using schedule compression methods where necessary, and reestimating as needed are common methods of adjusting for
normal changes to time management on projects.
Measurement
The schedule itself has a natural set of metrics with which to measure progress. Traditional EVM is a common practice on
plan-driven projects and agile teams use velocity to constantly measure actual progress against planned, and adjust as
needed. Agile teams also use burnup and burndown charts to measure overall project progress.
Reestimating
It is standard practice to reestimate the remaining work at planned times and whenever it seems prudent. This is how the
project manager makes sure they can still satisfy the project objectives within the schedule, budget, and other project
constraints, and adjust the performance measurement baseline if they cannot.
Artifacts of Control Schedule

The Control Schedule process results in work performance information, schedule forecasts, and sometimes change
requests. For example, a change to the schedule might require additional resources or a change in scope. Such changes
must be handled as part of the Perform Integrated Change Control process. Make sure you review this important process
in the “Integration” chapter. On agile projects, again, it is most often scope—features and functions—that are renegotiated
if, as usual, schedule is to be kept stable and the team is behind when measured against the plan.
This process may also result in updates to the schedule management plan and performance measurement baseline in
addition to project documents such as the assumption log, risk register, and lessons learned register, and changes to any
other part of the project.

Were you surprised at the amount of effort it takes to plan and manage a project schedule? It is the project managers re
sponsibility to create a realistic schedule and to monitor and control it. For the exam, make sure you understand the prece
dence diagramming method and know how estimating is done in both predictive and adaptive environments. Go through
the Quicktest at the beginning of the chapter again to help identify any gaps in your knowledge. Review the concepts you
are still unsure about.
Complete the following exercises based on our library case study.
EIGHT Schedule
8.7 Exercise
Review the list of work the project manager needs to do to create the project schedule. Here or in your Exercise
Notebook indicate the order in which this work should be completed by placing the letter assigned to each item
into the order table below. Also indicate which process this work describes.
A. Each of the stakeholders or team members who are responsible for an activity will be responsible for
determining how long the activity should take.
B. The project manager will bring together the architect, construction team lead, librarian, and the other team
members to review the work breakdown structure and determine the activities needed to complete the project.
C. The project manager needs to think about who will be needed to complete the project and how to
measure performance
D. All the activities will be plotted onto a calendar based on the availability of the person assigned to complete it.
E. The team will discuss each activity required and identify its predecessors and successors.
Order Work Process Groups Model Name

1st
2nd
3rd
4th
Sth
Answer
Order Work Process Groups Model Name

1st C Plan Schedule Management
2nd B Define Activities
3rd E Sequence Activities
4th A Estimate Activity Duration
Sth D Develop Schedule
225
Schedule EIGHT
8.8 Exercise
Try this exercise based on a case study using adaptive tools.
The library software application needs to be upgraded. A backlog of requested features has been collected and
prioritized in the following backlog. Review this list and with the information provided, draft a Product Roadmap
with three releases. Each release should include an extra feature if the team has time (stretch goal). Be sure to
consider the dependencies.
Backlog
Feature# Feature Priority Dependencies Estimate (est.)

l Map of library High None 1 story points
2 Collect patron profile information Med None 3 story points
3 Allow patron to set up login id and password High 2 5 story points
4 “Resume Builder” High 3 5 story points
5 “Job application cover letter builder” Med 4 3 story points
6 Connect to popular job boards Med None 5 story points each
7 Search by author name Med None 3 story points
8 Search by book title High None 5 story points
9 Search by magazine article title Med None 8 story points
10 Ability to join a book club Med 11 3 story points
11 Ability to add a new book club Med 3 5 story points
Product Roadmap
Total with
Stretch
226
EIGHT Schedule
Answer
Does your product roadmap look like this ? In parentheses is the feature number for each story. If you have variations,
make sure that you understand the differences and think about why your version is a plausible way to approach the
project as well as why ours is a plausible version of completing the project.
Release 1 Release 2 Release 3
Feature Est. Feature Est. Feature Est.

High Map of library (l) l Search by book title (8) 5 Connect to first job 5
priorities board (6)
Collect patron profile (2) 3 “Resume Builder” (4) 5 “Job application cover 3
letter builder” (5)
Allow patron to set up 5 Ability to add a book 5 Ability to join a book 3

login id and password club (11) club online (10)
(3)
Total 9 15 11
Stretch goal Search by magazine 8 Search by author name 3 Connect to second job 5
article titles (9) (7) board (6)
Total with
17 18 16
Stretch Goal
227
228
QUICKTEST
• Cost Management
Budget and Resources process

• Earned value (EV)
• Earned value analysis
(EVA)
• Earned value
management (EVM)
Introduction • Cost management plan

• Types of cost
Do you create a budget for your projects? Do you have practical experience managing and controlling - Variable
project budgets? If these efforts are not part of how you manage your real-world projects, make sure - Fixed
- Direct
you read this chapter carefully and fully understand the concepts presented.
- Indirect
While managing cost (i.e., the project budget) the project manager is primarily concerned with • Top-down estimating
estimating, and with earned value management (EVM). A subset of budget management is material • Bottom-up estimating
resource management since resources cost money, so must be in the project budget. Cost management • Estimate ranges
includes estimating and uses the same estimating techniques covered in the Schedule chapter. In this - Rough order of
chapter we explain in detail the EVM content, which is also applicable to both schedule and cost. magnitude (ROM)
- Budget
Think About It. A project manager has to be able to think simultaneously about the big - Definitive
picture as well as the details. To think holistically, it’s hard to think about cost without also • Basis of estimates
• Adaptive estimating
considering scope and schedule. The team uses the project budget and schedule to build the
• Cost aggregation
project scope. Many of the same estimating and EVM methods are used for cost management
• Burn rate
as well as schedule management. Earned value analysis is all about how much of the project s
• Progress reports
schedule and budget have been used to build the scope as compared to what was planned to • Reserve analysis
be built and spent at a certain point in time. • Earned value terms
- PV
If you recall, a plan-driven project decomposes the product and project management work into
- SV
work packages, the artifact of which is the WBS (“Scope” chapter). The activities to build the work
- AC
packages are then sequenced into a schedule network diagram (“Schedule” chapter) where activity - BAC
duration estimates are placed. In this chapter, we’ll discuss how cost is estimated based on those - EAC
activities. - ETC
Agile teams have a fixed cost and time so budgeting is more straightforward. For - VAC
agile projects the work is also decomposed, but remember it is kept track of in a backlog. • Formulas for earned value
A product backlog is somewhat analogous to a WBS in this context because it should analysis
include everything in the project. The backlog is broken down from the feature level to
the story level, and then each story may be broken into tasks. Here the (agile) use of the word “task” is
analogous to “activity” in plan-driven projects. In either case the work is being broken down so it can
be easily understood, estimated, and assigned to resources. On exam questions, look for the appropriate
context so you can identify the correct answer.
Definitions Related to Budget and Resource Management

Here is the budget-related vocabulary you will want to be sure you know for reading this chapter and
for the exam. Vocabulary related to specific EVM metrics will be discussed in the Earned Value Man
agement section later in this chapter.
Earned Value (EV)

EV is a metric that gives the estimated value of the work that has actually been completed on the
project to date. A project manager uses EV along with other metrics in earned value analysis to
determine how well the project is doing compared to its performance measurement baseline (the
scope, schedule, and cost baselines).
229
Budget and Resources NINE
Earned Value Analysis (EVA)

This is an analysis method that uses earned value and other metrics to evaluate how well the project is doing relative to
what was planned to date. The previous CV example is one measure, but schedule variance (SV) can also be measured, and
together with other measures the project manager can determine the overall project performance against the performance
measurement baseline.
Earned Value Management (EVM)

EVM is the practice of managing scope, schedule, and cost using earned value analysis to control the project. The results of
earned value management tell the project manager what changes, if any, are needed to complete all the project s scope on
time and within budget. Agile projects use earned value management with the qualification that some of the least critical
scope stories may be put off to another release or a later project to meet cost and time constraints. Anywhere along the
spectrum of development approaches, agreed quality requirements must be met.
Cost Management Overview

As you have come to expect, we will use PMI’s Process Groups model to help you understand the overall Cost Management
process.

Below you will see how in the Examination Content Outline (ECO), the single budget and resources management task maps
to the Cost Management process in the Process Groups model. Like with scope and schedule management, the Process
Groups model has processes related to Planning and Monitoring and Control, but not to executing. This is because the
team does the work of spending time and budgetary resources to build the scope of the product while the project manager
monitors and controls that work—equivalent to the “manage” part of “Plan and manage budget and resources” in the ECO
Process domain. Note that this ECO task also includes managing physical, or material, resources.

Domain II Cost Management Domain 2.4
Planning
Task 5 Plan Cost Management —■ Domain 2.6
Plan and manage budget and resources
Estimate Costs Planning Delivery
Determine Budget —1 Domain 2.7

Measurement
Control Costs —I Monitoring
Domain 2.8
Control Resources —1 & Controlling Uncertainty
Think About It. Estimating is initially done during planning, and EVM is used to control costs (and resources
and procurement) throughout the project. As you manage costs you will also:
• Manage conflict and negotiate project agreements (domain I, tasks 1 and 8)
• Promote team performance through training and the use of emotional intelligence (domain 1, tasks 5 and 14).
These all support value-driven delivery and cost savings. What can you add to this list of interactions between
processes and ECO tasks? Practice thinking holistically by scanning the ECO for other tasks that work in unison with
these. Think about how decisions around financial resources might affect procurements, project risks, and other project
constraints. Some material resources, like equipment, for example, may be available within the organization or may be
procured for the project. These decisions influence how the project is planned across all constraints and how work will be
completed. If you haven’t had to deal with these concerns on your own projects, it’s easy to miss questions on the exam
about how cost-related decisions could impact the rest of the project.
230
NINE Budget and Resources
Figure 9.1 can help you visualize the cost management process from the Process Groups model perspective, which
can help you understand, in general, cost management no matter a project s development approach. Take time to review it
before moving on to the rest of this chapter.

KA: Cost Management
Key
' ' is consistent with all
approaches
_Change prompts a process

to be reiterated through
si progressive elaboration
or agile methods
Changes that cause a

Figure 9.1 Cost management process
Desired Outcomes From Successful Budget and Resources Management

Assume for the exam that project budget and resources are properly planned and managed unless information in an exam
question indicates otherwise. This means that the following outcomes should be expected as a result of successful
communications management:
• Budget strategies on the project are planned and executed according to the needs of the project. This results in few or
no problems that cause the need to increase the budget baseline. Risk planning helps with this goal because most risks
will have planned contingency plans and budgets built into the project budget.
• Good servant leadership in the management of the team should have the outcome that the project has on it a qualified,
motivated, and high-functioning team. This team will have the support and training needed to build and deliver the
project’s deliverables at the appropriate levels of quality and within the project budget.
Plan and Estimate Project Costs

Besides having a plan for how costs will be managed, the project manager also Process Groups Model
needs to estimate costs and determine the budget. The Plan Cost Management pro PG: Planning
cess involves answering questions such as, “How will 1 go about planning cost for Process: Plan Cost Management;
the project and who needs to be involved?” and “How will I effectively manage the Estimate Costs
project to the cost baseline and manage variances?”
ECO
The project charter includes the high-level cost constraint and other available
Domain II
requirements regarding cost management on the project. Organizational process
Task 5 Plan & manage budget/resources
assets used in this process include cost data and lessons learned from previous
projects as well as organizational standards and policies for estimating PMBOK* Guide
and budgeting. Domain 2.4 Planning
Plan Cost Management

In some organizations, cost planning may involve determining whether the project will be paid for with the organization s
existing funds or will be funded through equity or debt. It can also include decisions about how to finance project
resources—such as choosing whether to purchase or lease equipment. As the project manager gets detailed estimates and
develops the budget, calculations are used that were created for project selection (covered in the “Foundations” chapter),
like net present value (NPV), return on investment (ROI), payback period, and discounted cash flow. With these the
project manager evaluates whether the project is still feasible within the charter and whether the measurable project
objectives can be achieved.
The cost management plan can be formal or informal, but it is part of the project management plan. It may include
the following:
• Specifications for how estimates should be stated (in what currency)
• Levels of estimate precision needed
• Approved estimating techniques
• Roles and responsibilities for various cost activities (e.g., estimating, tracking, reporting)
• Reporting formats
• Whether costs will include indirect costs (not directly attributable to one project, like overhead)
• Guidelines for establishing a cost baseline to measure against
• Methods for documenting costs
• Control thresholds (amount of allowable variation before the project manager needs to act)
• Rules for measuring cost performance
• Cost change control procedures
• Information on control accounts or other ways to monitor spending
• Funding decisions
• Guidelines for dealing with potential fluctuations in resource costs and exchange rates
Estimate Costs
The process of estimating project costs involves estimating individual components and then aggregating all estimates into
a time-phased spending plan (detailed next in Determine Budget).
Think About It. In the “Schedule” chapter there is a checklist called “Things to Know about Estimating for the
Exam” on page 197. Take some time now to review that list since it applies to estimating schedule and cost. It is
helpful to have those concepts fresh in your mind before continuing.
So what costs should be estimated ? In addition to labor and material resources and training for the project, the project
manager also estimates the following:
Labor costs for all project activities or tasks Project management activities
Material resources to complete activities or tasks Physical spaces used directly for the project
Training Overhead costs, as applicable
Quality efforts (those indirect costs like management salaries and
Risk efforts general office expenses)
Types of Cost
In the past, the exam has included questions regarding types of cost. A cost can be either variable or fixed, direct or
indirect—and these two pairs are not mutually exclusive. For example, there can be both direct variable costs and direct
fixed costs.
• Variable costs These change with the amount of production work.
Examples Materials, supplies, wages.
• Fixed costs These do not change as production changes.
Examples Rent, utilities.
232
• Direct costs These are directly attributable to work on the project.

Examples Team wages, training, travel and recognition expenses; project materials costs.
• Indirect costs These are overhead costs incurred for the benefit of more than one project.
Examples Taxes, fringe benefits, janitorial services.
Artifacts Needed to Estimate Costs

We all would agree wed want our estimates to be as accurate as possible. Where is the first place you would look for help
with this? Previous, similar projects! Imagine having a repository of all the previous WBSs for similar projects, along with
the estimates and actual costs for each activity. Can you see how that might be helpful in creating more accurate estimates
on your own projects? Other historical project artifacts include:
• Resource requirements documentation • Templates and processes including those from
• Cost and quality management plans Past projects
• Scope and schedule baselines • Corporate governance
• Lessons learned and risk registers * Marketplace conditions, commercial cost databases,
• Policies and historical records related to estimating exchange rates, inflation, and supply sources
Estimating Methods and Accuracy

As described in the “Schedule” chapter, estimates should be created from ranges as it is very unlikely an activity’s completion
will result in a single, exact estimated time or cost. Estimating is done using common methods like analogous, parametric,
and three-point estimating.
Think About It. From a general perspective, these methods fall into the top-down or bottom-up categories. For
example, say someone walks into your office and asks you to estimate the total cost of a new project. The first
question you may ask is, “How accurate do you want me to be?” Early in the project during initiating, estimates
are top-down, high-level estimates. Over time, as you break down project deliverables during planning, you
narrow the estimate range as you do bottom-up estimating.
Top-down and bottom-up estimating each have the following advantages and disadvantages:
Top-Down (Analogous) Estimating
• Quick • Low accuracy level
• Activities and material resources do not need to • Reflects limited information about the project or
be identified key deliverables
• Less costly to create • Requires considerable experience to do well
• In initiating, provides cost constraints to evaluate • Conflicts to gain budget priorities may not have the data
high-level project feasibility able to justify the need
• Overall project costs can be capped for this type • Difficult for projects with uncertainty or without similar
of estimate projects to reference
• Does not consider differences between projects
Bottom-up Estimating
• Based on detailed project and deliverable analyses • Requires that the project be well defined and understood
• More accurate (at the activity or task level) • Requires effort to break project deliverables into
• Gains buy-in from the team because the team smaller pieces
helps creates the estimates • Takes relatively more time and money
• Provides a basis for control and management • Risk of padded estimates unless the team understands the
use of reserves
233
Budget and Resources
Estimate Ranges The standard estimate range types are order of magnitude, budget, and definitive. Using each implies a
particular level of accuracy. These are discussed below:
• Rough order of magnitude (ROM) estimate Usually made during initiating, a typical range for ROM estimates is
-25 to +75 percent. It varies depending on how much is known about the project.
• Budget estimate A refinement from a ROM estimate, a budget estimate is typically in the range of -10 to +25
percent The range is narrowed from ROM before reiterating the budget.
• Definitive estimate As planning progresses, the estimate should become even more refined. Some project managers
use the range of +/-10 percent, while others use -5 to +10 percent, and this may depend on what management
requires.
What you see here may be different from your experience. For the exam, make sure you understand estimating
TRICKS in ranges and that estimates become more refined as project planning progresses. Remember that organizations
OF THE
TRADE have different rules for the acceptable estimate range for an activity or the project. It is wise to estimate in a
range, based on the level of uncertainty remaining in the estimate.
' Even the approved baseline may be expressed as a range.
I Example “$1,000,000 (-5 to +10 percent).”
Human and Material Resource Cost Rates

It may seem obvious that resource costs involve estimating the work of consultants, sellers, and equipment and supplies.
Although many project managers do not have access to this information on their projects, the exam assumes a project
manager also uses the actual cost of internal human resources when performing cost estimating.
Estimating Costs: Final Notes

Spreadsheets and software within the PMIS can speed up calculation and analysis and integrate finance and accounting.
Quality, risk, and scheduling tools are useful here as well. Alternatives analysis, reserve analysis, and decision making (all
discussed in the “Schedule” chapter) may also be used as part of the Estimate Costs process.
The Estimate Costs process results in cost estimates and the basis of the estimates (an explanation of how the estimates
were derived). It can also result in project document updates, such as the risk register, assumption log, and lessons
learned register.
Once the project manager has completed estimating costs they have the costs for each work package or story based
on the activities needed to build them, the documentation on the basis of estimates (what are their assumptions, etc), and
other project artifact updates like those to the assumption log and the lessons learned and risk registers.
Determine Budget
The project manager aggregates the total estimated costs (including estimated risk Process Groups Model
reserves) for the project to determine the cost baseline. An approved budget in PG: Planning
cludes that baseline plus a management reserve (more on reserves in the “Risks and Process: Determine Budget
Issues” chapter). The traditional projects cost baseline is a measure of project suc
cess. The project manager uses it to control costs while the project work is being ECO
done. Domain II
Task 5 Plan & manage budget/resources
The project manager also revisits the feasibility of the project in determining
the budget during planning. They review the business case and the benefits PMBOK* Guide
management plan. The business case may be expressed in financial terms such as
Domain 2.4 Planning
expected return on investment (ROI). The benefits management plan can be used
to compare the estimated budget to the business value the project is supposed to
bring to the organization and its stakeholders.
Lets review the planning process as it culminates in getting to this point with the projects cost baseline. Here the
project manager has done the following:
• In initiating, incorporated the information provided (through top-down estimating) into a project charter, which
became a basis for planning since planning and executing must remain true to the project charter.
• Determined the project scope—both what is and what is not included in the project. This becomes the scope baseline.
• Decomposed product scope into deliverables and then smaller, more manageable pieces (like activities or tasks) for
the purpose of estimating, assigning resources, and building that scope.
• Estimated time and costs for each of the product scope components.
• Calculated the aggregate project costs for the project using the estimates for each of the product scope components
(bottom-up estimating). Remember that materials costs may appear in line items separate from team resources
assigned to activities.
• Assigned time estimates to each activity along a network diagram to help establish the project s critical path and the
project schedule baseline.
To finish the budget the project manager will include estimated risk reserves (included in the cost baseline) and
management reserves (part of the budget but not the cost baseline; see figure 9.2).
Future Performance Measurement

Once risk planning is included (see the “Risk and Issues” chapter), the project manager has the projects performance
measurement baseline: the scope, schedule, and cost baselines. We cover performance measurement in more detail in the
following Control Costs section of this chapter.
Adaptive Estimating Methods

On adaptive projects the team breaks down scope using t-shirt sizing, affinity estimating, and Planning
Poker*. The team uses story maps to plan releases. Refer to the “Schedule” chapter for a review of these
concepts. A story map is analogous to a network diagram, but do not take the analogy too far. The resulting
schedules and budgets approved for traditional projects are thought to be more fixed, where a release map is
meant to give a general idea of how the product releases will unfold. Agile projects do tend to fix cost and time while
varying scope, but if a customer decides to drop some features as the product is developed during early releases, this will
inevitably affect the projects costs. Adaptive teams also use retrospectives to determine the accuracy of budget estimates
and whether budget adjustments should be made.
Artifacts of Determine Budget

Two artifacts of Estimate Costs—cost estimates and the basis of estimates—are essential inputs to the Determine Budget
process. Many of the inputs to Estimate Costs are used here as well:
• Cost management plan
• Scope baseline
• Project schedule model
• Risk register
• Existing policies on cost control and cost budgeting
• Resource requirements documentation (for example, for how long and at what costs for particular resources, including
materials, supplies, and equipment costs)
• Agreements (regarding the purchase of services or products for the project)
255
Aggregating Costs into a Budget

To prepare the budget for approval, the project manager needs to do what’s called cost aggregation. To do this, they would
pull together the costs of all activities—including risk management activities, which go into the budget as risk reserves
(covered in the “Risk” chapter).
Think About It. Review the following list and follow along with the Figure 9.2. Read the figure from the bottom
up as you think about the items in this list:
1. Activity estimates are rolled up into work package estimates (see #2).
2. Work package estimates are rolled up to control account estimates (see #3).
3. Control account estimates track entities that cost will be assigned to (and do not affect totals).
4. Project estimates is a total for the budget, to this point.
5. Contingency reserves are established during risk planning. When added here, contingency reserves
determine the cost baseline (#6).
6. Cost baseline An estimated total cost performance measurement baseline.
7. Management reserves are added in the final step.
8. Cost budget is a total that includes the cost baseline + management reserves.
Notes: 1) Estimated costs and reserves are shown aggregated at the cost budget level and depicted in figure 9.2, but
remember contingency reserves are added at the activity level and work package levels initially during planning for risk
management. 2) It is the management reserve (covered in the “Risk” chapter) that makes the difference between the cost
baseline and the budget.
8. Cost budget | $1,423 ~~|
After the cost baseline and budget are estimated, the project manager may compare these numbers to parametric
estimates or to expert judgment, or perform an historical information review, comparing their estimates to those of past,
similar projects. For example, a general rule for a high-level parametric estimate in some industries is that design should be
15 percent of the cost of construction. Other industries estimate the cost of design to be 60 percent of the project budget.
The project manager needs to investigate and justify any significant differences between the project estimates and the
reference data to ensure the estimates are reasonable and as accurate as possible.
236
Cash Flow, Financing, and Budget Reconciliation

For the exam, a well-planned, approved budget assumes that the project manager has worked with the performing
organizations finance department to ensure that cash flow planning for the organization will include expenditures for the
project just when they are needed. The cost baseline, therefore, is time-phased.
Example Equipment costing $500,000 is scheduled to be purchased on June 1 but the money for the purchase is not
available until July 1. The activities dependent on that equipment will have to be moved to later points in the schedule.
Burn rate on agile projects Are you familiar with the term “bum rate”? It is a common business metric
referring to the rate at which an entity—in this case an agile team—is using (or losing) money. You may
remember that on adaptive projects, teams are often stable and consistent because more value is placed on
retaining project knowledge and keeping together a team that has already developed its high-performance
capabilities. One advantage of stable teams is that there are consistent burn rates and simplified cost estimating. As
discussed in the “Schedule” chapter, agile teams use velocity to help create a project schedule based on story point estimates.
Velocity can help anticipate future budgetary issues as well.
Think About It. A team is averaging 50 story points per month and there are 500 story points left in the backlog.
They would need 10 more months to complete the project. If their salary burn rate is $45,000 per month, can you
estimate the cost for the 10 months?
It is 10 x $45,000 = $450,000. Knowing this, you can look at the budget and decide if you have correctly estimated a
budget for 10 more months of the team’s monthly salary bum rate.
Checking with the Project Charter

The project budget must be reconciled with any cost constraints in the charter. If the project estimate exceeds these
constraints, the project manager must meet with the sponsor, explain why their cost requirement cannot be met, and
propose options to decrease costs. If that cannot be done, the project’s budget baseline must be increased. Pay particular
attention to these last two sentences. As with the schedule, project managers have a professional responsibility to reconcile
the budget in this way.
When the Determine Budget process is complete, the cost baseline, including all funding requirements, is established.
Naturally, many of the inputs to the process will be updated, for example the cost estimates, the risk register, and the
project schedule.
Control Costs and Resources

Once the project cost measurement baseline and budget are complete, the Process Groups Model
project manager will need to continuously look for anything that affects that PG: Monitoring and Controlling
baseline even if it can cause the project to be terminated. Start this section by Process: Control Costs
completing the following exercise and imagine how this would apply to real- Control Resources
world projects.
ECO
Think of yourself as a detective looking for anything that can get in Domain II
the way of project success. This mindset will help you select the Task 5 Plan & manage budget/resources
best choice when answering questions on the exam that may seem
PMB0K* Guide
to have more than one correct answer.
Domain 2.6 Delivery Performance

For more information on controlling resources, be sure https://rmcls.com/rmc-resources
to read these free articles on the RMC Resources page (rmcis.
com/rmc-resources): “Controlling Resources Checklist,”
“Resource Responsibilities for the Project Manager,” and
“Resources and the Project Budget.”
257
9.1 Exercise
This is an important topic so be sure to take your time to think this through. In your Exercise Notebook, list the
actions a project manager may take to control costs and resources.
Answer
• Follow the cost and resource management plans for how to control costs
• Tailor control activities to the needs of the project
• Consider policies, procedures, tools, and reporting templates and formats related to controlling costs
(selected from organizational process assets during planning)
• Measure project performance and compare it against the plan
• Determine if variances require change, including preventive and corrective action
• Request changes
• Implement approved changes
• Prevent unnecessary changes
• Look for the root cause of factors causing costs to rise
• Conduct earned value measurement
• Conduct reserve analysis (related to risk)
• Aggregate data, analyze it, and produce reports
Managing Change
Controlling costs is an important responsibility for project managers, but you must also understand and plan for potential
budget variations. No matter how well the project manager plans in a predictive environment, change is inevitable. In
adaptive environments changes to scope are more frequent so agile teams have built in methods to handle changes
throughout the project and meanwhile try to preserve the original budget if possible. Change management is covered in
more detail in the “Integration” chapter. In any case, it should go without saying that changes to the cost baseline must be
made formally with approval.
Think About It. Your team worked overtime to complete a new feature for an upcoming sponsor demo.
While the new feature was completed on time, the overtime work means your monthly budget goal for
payroll will be missed. As the project manager, you weighed the value of this through an analysis of benefits
and costs. The benefit outweighed the cost, so you approved the overtime. You need to revisit this decision
when forecasting the future of the project. Was this months higher payroll atypical or has your team consistently
needed overtime hours to complete the necessary work? Should you adjust the budget for future months or adjust the
schedule to avoid unnecessary overtime?
Think About It. What would happen if a team member suddenly realizes the materials they need to finish
an activity are out of stock? More will have to be ordered. Time will be lost to waiting for the materials and
- a last-minute order is likely to be more costly than if the materials had been better controlled.
There can be many unplanned scenarios that impact the project budget, and additional costs may be unavoidable. As
the project manager, you should look for these situations, anticipate the potential risks, and plan ahead. You will never be
able to foresee everything, but if you try to imagine the unplanned costs on your project, you will have a much easier time
planning and managing a realistic budget.
238
Progress Reporting
Through earned value measurement, the project manager analyzes data about project progress to help control the schedule
and costs and to assess whether the project is on track (described later in this section). Progress reports convey information
based on this data analysis method. Asking team members for percent complete of their deliverables may be used by some
project managers but this does not convey a realistic estimate of progress. They can carefully track progress using percent
complete at the work package or story level but the cost and schedule estimates for the work package or story should also
be factored in.
In terms of data gathering, an often-cited metric on traditional projects is that 80 hours is a small
enough work increment to track progress against and still have accurate data. For the exam, remember that https://rmcls.com/r
traditional projects using proper project management make use of a WBS, and activities to produce work
packages are broken down to an appropriate level for controlling. Material resources like equipment
usually appear in the budget as separate line items, and may even be related to costs detailed in procurement
documents. For more information on the relationship of costs and resources, see the “Resources on
Projects” article on the RMC Resources webpage.
On agile projects, data gathering and analysis will be centered around the backlog and how many
features have been developed to date relative to what was planned. Story points by iteration are tracked for
the team’s use and burnup and burndown charts are used for both the team and other stakeholders. Review
these types of reports in figure 6.6 in the “Build and Support Team Performance" chapter.
Reserve Analysis
Remember the contingency reserves that get factored into the cost baseline to address known risks? Reserve analysis allows
you to identify and apply lessons learned in controlling costs. Part of cost control is analyzing where contingency reserves
are still necessary or where new reserves are required. Both of the following examples would require a formally approved
change request.
Example A project team identifies a highly ranked risk and sets aside a contingency reserve to address it. If the risk
does not occur and is no longer a threat, the contingency reserve can be removed from the cost baseline.
Example A risk review on a project identifies new risks, which could lead to a decision to increase the contingency
reserves.
Think About it. A formally approved change request is also required to move management reserve funds
into the cost baseline for a similar purpose. It may also be necessary to reassess the amount of management
reserve that was set aside to address unknown risks. This difference between contingency reserves (for
identified risks) and management reserves (for unknown risks) is an important distinction that can help you
get more questions right on the exam. We have mentioned this distinction earlier in this chapter and discuss
it again in the “Risks and Issues” chapter.
Earned Value Management

As a project manager, you manage project performance and you account for that performance to stakeholders by comparing
planned to actual results. This is the essence of earned value management, which includes earned value analysis. Earned
value analysis is a data analysis method used to evaluate project performance against the entire performance measurement
baseline (the scope, schedule, and cost baselines). Earned value analysis results indicate whether there are any potential
deviations from the performance measurement baseline.
Earned value analysis can be used to forecast future performance and project completion dates and costs. This
information is conveyed to stakeholders through reports in meetings and other communication methods.
239
Formulas for Earned Value Analysis

As of this book’s publication, very few questions on the exam contain formulas. Nevertheless, you should go through this
section carefully. Even if you get few or no formula questions, earned value analysis is on the exam and understanding this
content will help you get those questions right. Of course, memorizing the formulas we specify in this section will help you
with questions requiring you to calculate formulas, even if there are not many.
Are you worried about it? Don’t be. We are going to make it easier. First, think about this: How valuable would it be
to know how your project is really going? Could you sleep better at night? Would you be able to spend your time in more
productive ways than worrying? Keep the benefits of the earned value analysis method in mind as you read this section.
’Think About It: Terms to Know. Here are the earned value terms you need to know.
Acronym Term Interpretation

PV Planned value As of today, what is the estimated value of the work planned to
be done?
EV Earned value As of today, what is the estimated value of the work actually
accomplished?
AC Actual cost As of today, what is the actual cost incurred for the work
(total cost) accomplished?
BAC Budget at completion How much did we budget for the total project effort?
(the cost baseline)
EAC Estimate at completion What do we currently expect the total project to cost (a
forecast)?
ETC Estimate to complete From this point on, how much more do we expect it to cost to
finish the project (a forecast)?
VAC Variance at completion As of today, how much over or under budget do we expect to be
at the end of the project?
Think About It: Formulas and Interpretations to Memorize. On the exam, you may not need to perform
many calculations but you must understand what the numbers mean. Therefore, you should know and understand
* all the formulas in the following table.
Name Formula Interpretation
Cost variance (CV) EV-AC Negative is over budget; positive is under budget.
Schedule variance (SV) EV-PV Negative is behind schedule; positive is ahead of schedule.
Cost performance index We are getting $ worth of work out of every $ 1 spent. Funds
EV
(CPI) are or are not being used efficiently. Greater than one is good; less
AC
than one is bad.
Schedule performance EV We are (only) progressing at________ percent of the rate originally
index (SPI) planned. Greater than one is good; less than one is bad.
PV
Estimate at completion As of now, how much do we expect the total project to cost?
(EAC) $_____ ■
NOTE: There are many This formula calculates actual costs to date plus a revised estimate
ways to calculate EAC, AC + Bottom-up ETC for all the remaining work. It is used when the original estimate
depending on the assump was fundamentally flawed.
tions made. Notice how the
purpose of the formulas This formula is used if no variances from the BAC have occurred
really is to create forecasts BAC or if you will continue at the same rate of spending (as calculated
based on past performance CPIC in your cumulative CPI or based on the trends that have led to the
of the project. Exam current CPI).
questions may require you
This formula calculates actual costs to date plus remaining budget.
to determine which EAC
It is used when current variances are thought to be atypical of the
formula is appropriate. Pay AC + (BAC - EV)
future. It is essentially AC plus the remaining value of work to
attention to the information
perform.
provided in the question. It
will help you determine This formula calculates actual to date plus the remaining budget
which formula to use. modified by performance. It is used when current variances are
AC, (BAC-EV) thought to be typical of the future and when project schedule
(CPIC x SPIC) constraints will influence the completion of the remaining effort.
So for example, it might be used when the cumulative CPI is less
than one and a firm completion date must be met.
To-complete performance This formula divides the value of the work remaining to be done
index (TCPI) (BAC - EV) by the money remaining to do it. It answers the question “To stay
(BAC-AC) within budget, what rate do we need to meet for the remaining
work?” Greater than one is bad; less than one is good.
Estimate to complete How much more will the project cost?

(ETC)
NOTE: You can determine This formula calculates the total project cost as of today minus
EAC - AC
ETC by either using the what has been spent to date.
formula listed here or
reestimating the cost of the Reestimate Reestimate the remaining work from the bottom up.
work remaining.
Variance at completion How much over or under budget will we be at the end of the
BAC - EAC
(VAC) project?
The following should help solidify your understanding about CV, SV, CPI, and SPI:
TRICKS
OF THE • EV comes first in each of these formulas.
TRADE
• u it is a variance ^ainerence;, me rormuia is tv minus al or rv.
• If it is an index (ratio), the formula is EV divided by AC or PV.
• If the formula relates to cost, use AC.
• If the formula relates to schedule, use PV.
• For variances interpretation: Negative is bad (J) and positive is good (S).
Example A -200 cost variance means you spent more than planned @ (are over budget). A -200
schedule variance means you are behind schedule @. This also applies to VAC.
• For indices interpretation: Greater than one is good Q) and less than one is bad (v). Remember, this only
applies to CPI and SPI. The opposite is true of TCPI.
Understanding Earned Value Terminology

People often incorrectly answer exam questions requiring them to simply interpret earned value terms without having to
calculate formulas. This section is an opportunity to help you get those questions right.
Think About it. Sometimes thinking about things in a different way can give you that “aha" moment when
everything falls into place. Think about the following bulleted lists and figure 9.3. Together they illustrate the
terminology to help you see it from another angle. Then, if you are still uncomfortable with earned value concepts
put it aside for now. However, come back another day and review all the content from the “Earned Value
Management” section of this book. Sometimes new information takes a bit of extra effort and this area is certainly in
that category for many students.
Planned value (PV) and actual cost (AC) look backward at what has been done on the project:
• P V: What is the expected value of work done at this point in the project (according to the plan) ?
• AC: What has the actual cost been on the project to this point?
Budget at completion (BAC), estimate to complete (ETC), and estimate at completion (EAC) look forward at
the project:
• BAC refers to the projects currently approved budget. It is a known quantity indicating what the end cost of the
project would be if everything went according to plan.
• ETC and EAC forecast future performance based on what has actually been done on the project, considering
variances from the plan the project has already experienced.
• ETC is an estimate of how much more the remainder of the project will cost to complete.
• EAC indicates what the total project cost is forecasted to be.
FIGURE 9.3 Earned value concepts by looking backward and forward on a project
Earned Value in Action

Earned value is an effective tool for measuring performance and determining the need to request changes. The following is
a sample team conversation on this subject.
The project manager calls a team meeting and says, “We are six months into this million-dollar project, and my latest
analysis shows a CPI of 1.2 and an SPI of 0.89. This means we are getting 1.2 dollars for every dollar we put into the project,
but only progressing at 89 percent of the rate originally planned. Let’s look for options to correct this problem.”
The network specialist suggests that she could be removed from the project team and replaced with someone less
expensive. The IT coordinator suggests either removing the purchase of new computers from the project or telling the
customer the project will be two weeks late.
The project manager looks at the network specialist and says, “It would sadden me to lose you, and your suggestion
would improve costs but not schedule. You are the company’s best network specialist. Someone else would not be as
proficient as you in completing the work.” To the IT coordinator’s suggestion, the project manager responds that canceling
the new computers would save money but not time. “Let’s focus on time.”
Another team member suggests that since the project is doing well on cost, the project manager could bring in another
programmer from the IT department to work on the project to get the next two activities completed more quickly.
The project manager says, “That sounds like the most effective choice in this situation. Let’s see if we can find someone
who will improve performance, at the lowest cost. Thanks for your help.”
Earned Value Analysis Practice

The best way to learn the earned value analysis technique is to use it. The following exercises are designed to give you a
chance to practice both calculations and interpretation. Earned value questions on the exam have generally required fewer
calculations per question than these exercises.
9.2 Exercise
The cost performance index (CPI) and the schedule performance index (SPI) can be charted each month to show
the project trends. Based on the diagram, would you be more concerned about cost or schedule if you were taking
over this project from another project manager? Write the answer in your Exercise Notebook.
2nd 3rd 4th

Qtr Qtr Qtr
Answer
You should be more concerned about schedule. The data in the chart is historical. Ihe last, most current
measurement was in the fourth quarter, which shows both SPI and CPI being above one (good). As of the fourth
quarter, the SPI is lower. An easy way to answer performance index questions that ask whether cost or schedule
should concern you most is to pick the option with the lowest index.
9.3 The Fence Exercise

You have a project to build a new fence. The fence has four sides equal in length. Each side is to take one day to
build, and $ 1,000 has been budgeted per side. The sides are planned to be completed one after the other. Today is
the end of day 3.
Using the information in the project status chart, calculate the following in your Exercise Notebook. Interpretation
is important on the exam. Can you interpret what each answer means?
l.PV= 5. CV= 9. EAC=

2. EV= 6. CPI= 10. ETC=
3.AC= 7. SV= ll.VAC=
4. BAC= 8. SPI=
Project Status Chart
Activity Day 1 Day 2 Day 3 Day 4 Status End of Day 3

Side 1 S........F Complete, spent $1,000
Side 2 S------- PF —F Complete, spent $1,200
Side 3 PS-S—PF 50% done, spent $600
Side 4 PS------ PF Not yet started
Key S = Actual Start, F = Actual Finish, PS = Planned Start, and PF = Planned Finish
nine Budget and Resources
Answer: The Fence Exercise

What Is: Calculation Answer Interpretation of the Answer
1. PV $1,000 plus $1,000 plus $1,000 $3,000 We should have done $3,000 worth of
work.
2. EV Complete, complete, and half $2,500 We have actually completed $2,500
done; or $1,000 plus $1,000 plus worth of work.
$500
3. AC $1,000 plus $1,200 plus $600 $2,800 We have actually spent $2,800.
4. BAC $ 1,000 plus $ 1,000 plus $ 1,000 $4,000 Our project budget is $4,000.
plus $1,000
5. CV $2,500 minus $2,800 -$300 We are over budget by $300.
6. CPI $2,500 divided by $2,800 0.893 We are only getting about 89 cents out
of every dollar we put into the project.
7. SV $2,500 minus $3,000 -$500 We are behind schedule.
8. SPI $2,500 divided by $3,000 0.833 We are only progressing at about 83
percent of the rate planned.
9. EAC $4,000 divided by $0,893 $4,479 We currently estimate that the total
project will cost $4,479.
10. ETC $4,479 minus $2,800 $1,679 We need to spend an additional $1,679
to finish the project.
11. VAC $4,000 minus $4,479 -$479 We currently expect to be $479 over
budget when the project is completed.
Did you select the correct EAC formula? If not, did you miss information in the question that could have guided
you to the correct formula? In this example, side 2 cost $1,200. Side 3 is SO percent complete and has cost $600.
This suggests a trend that indicates side 4 is likely to cost $1,200 when complete. When there is a trend and no
other information to indicate the trend will not continue, it’s most appropriate to use the BAC/CPI formula.
Understanding the meaning of earned value analysis calculations is as important as knowing how to calculate them.
Expect questions on the exam such as:
Example “The CPI is 0.9, and the SPI is 0.92. What should you do?”
The data show the project as both over budget and behind schedule (J). You need to interpret this and other data in
the question and then determine which choice would address the issue(s) described.
9.4 Exercise
What is the SPI if the CV is $10,000, the SV is -$3,000, and the PV is $100,000? Write the answer in your
Exercise Notebook.
Answer
To find the SPI here, you need to perform two calculations. The formula for SPI is SPI = EV/PV. We know what the
PV is, but we don’t know the EV. Luckily, we can figure it out using the information given in the question. We’re
given the SV and PV, so we can use the following reverse formula to determine EV.
Reverse formula: EV = SV + PV.
EV = $3,000 + $100,000 = $97,000.
Now we can plug the PV and EV into the SPI formula as follows:
SPI = EV/PB = $97000/$ 100,000 = .97
9.5 Exercise
What is the AC if the CV is $10,000 and the EV is $97,000? Write the answer in your Exercise Notebook.
Answer
Answer. The CV is $10,000 and the EV is $97,000. With Known formula: CV = EV - AC
this information, we can determine the AC by using the
formula CV = EV - AC. We first plug the information we $10,000 = $97,000-AC
know into the formula.
To solve for AC, we need to get AC alone on one side of the $ 10,000 + AC = $97,000 - AC + AC
equation. First, add AC to both sides of the equation:
$10,000 +AC = $97,000
The -AC and +AC on the right-hand side of the equation $10,000 + AC - $10,000 = $97,000 - $10,000;
canceled each other out. But we still need to isolate AC on
the left-hand side of the equation. To do this, we’re going to AC = $87,000
subtract $ 10,000 from both sides.
Summary: Earned Value Analysis and Managing Costs

Whew! You made it. In summary, earned value analysis enables the project manager and team to identify and analyze
trends in performance and variances. The information gleaned from earned value analysis allows the project manager and
team to know how the project is performing at a given point in time and to report on this performance and also provide
forecasts for the future of the project. Indications may require action to bring the project in line with what was planned, or
formally approved changes to the performance measurement baseline, which may require additional funds for the project.
Control Costs also includes monitoring the use of contingency reserves to ensure the amount of reserves remaining
is adequate.

Did you recognize the estimating tools that were also used in the “Schedule" chapter? The project manager uses estimating
tools to create the budget for the project. Remember that meeting the cost baseline will be a measure of project success, so
the budget should be in a form the project manager can use to control costs while the work is being done. During Monitor
ing and Controlling, the project manager uses earned value measurement to measure project performance against the per
formance measurement baseline.
For the exam, make sure you understand the difference between the different types of reserves (contingency vs.
management). You may get 1-3 questions on the exam that require you to use a formula. It’s best if you at least know
formulas for SV, CV, CPI, and SPI, and understand what those formulas are measuring.
246
Revisit the Quicktest at the beginning of this chapter. Do you still have gaps in your knowledge? Go through the
chapter again to review the areas you are still unsure about. Then complete the following chapter review.
9.6 Exercise
Read the following case study and review the table to see some examples of what the project manager will do
during each of the Cost Management processes.
The city council reviewed a high-level recommendation for the new library (considered the charter for this project).
The project manager (PM) reviews the recommendation to plan and develop a more detailed cost estimate along
with a schedule.
• The (PM) knows that talking with the architect and construction team leader will help formulate
cost estimates.
• Understanding the size and interest rate of the debt will factor into needed funds and scheduling urgency.
• Talking with the mayor will determine how and when to effectively report progress against the budget as
the mayor will have final signoff on the budget.
• The PM will ask for clarity on spending authorizations and change orders.
• Reviewing results from the city’s last building project will provide insights into costs, risks, and
potential resources.
• The city manager will help with reviewing and controlling the budget, as this manager will be responsible
for project procurement.
• To track costs, the PM will use the city’s financial reporting system, recording all expenditures within a
month of their paid dates.
• The PM will create monthly financial reports of expenditures and earned value.
• Any unexpected costs or change orders, over the city authorization policy covering the PM, must be
approved by the city manager or mayor.
Cost Process Examples of the PM’s work

Plan cost • Plan to talk with architect and head of construction about costs
management • Plan to talk with major about frequency of reporting expenditures
• Review the lessons learned from the prior city building project
• Review the expected debt amount with associated interest payments
• Learn about PM’s authority for expenditures and changes to budget
• Get access to city financial system
Estimate costs • Talk with involved stakeholders; review price estimates of needed resources
• Get estimates for several completion dates to compare the time vs. cost considerations
Determine budget • Present two different budget options to the city council for approval, answer questions
as needed.
• After council budget selection, prepare the final budget and schedule for the city manager to
review. Adjust as needed and get signoff.
Control costs • Enter expenditures into city financial system within one month of payments.
• Monthly reporting of total expenditures, including earned value analysis.
• Extra expenditures over PM authorization must be approved by mayor or manager.
9.7 Exercise
Ulis exercise uses agile processes for the library case study. Read the scenario below and then complete the exercise
by writing down the meanings of the given terms. Look up any terms for which you do not know the meaning, and
do write them down. Writing them will help you learn them better than just reading them will.
For the first set of releases, a team of 5 product developers will be assigned for a period of 6 months (besides the
product owner and project manager). Their goal will be to offer as many features to library patrons as can be
released in 6 months, based on the product owners (head librarians) priority and other stakeholder feedback.
• The team will work in two-week iterations with releases every quarter.
• The PM will track team velocity and report which features patrons value most, compared with the time
required to create them.
• At the end of the 6 months, the PM will present accomplishments to management along with the product
owner’s recommendation for next steps.
Hands-on: Define the following terms, either here or in your Exercise Notebook.
Term Definition
Release
Feature
Product Owner
Iteration
Velocity
Answer
The wording of your answers may not match these exactly, but should be substantively the same.
Term Definition
Release A version of the product that is useful to the user and that can be delivered
Feature A particular, defined aspect of the product that is useful to the user.
Product Owner The person who decides on the priority of feature development based on expected
value to users and cost and time to complete.
Iteration A timebox used to complete work on a product (for example, a “two-week iteration”).
Velocity A calculated rate of work completed per iteration, usually measured in story points.
248
QUICKTEST
10 Quality of Deliverables • Definition of quality

• Quality Management
process
• Prevention over
inspection
and Products • Continuous improvement

• Just in time (JIT)
• Quality metrics
• Mutual exclusivity
• Probability
• Normal distribution
Introduction
• Statistical independence
Take a moment to think about how quality is handled on your projects. If you do not currently use a • Standard deviation
quality management plan this could be a difficult topic for you on the exam. This chapter will help you • Interviews, brainstorming,
benchmarking
understand quality and its role in the project management process. In any organization, senior manage
• Cost-benefit analysis
ment is responsible for promoting an organizational approach that supports quality efforts. Team
• Cost of quality
members must inspect their own work. For the exam, assume there is a quality department that helps
• Marginal analysis
determine quality management methods the project manager and team are required to follow. • Logical data models
Organizational process assets (OPAs) are often available in the form of templates and documented • Mind mapping
procedures and quality requirements. Within the quality constraints already given, the project manager • Prioritization matrix
and team must tailor their practices to the needs of the project. • Test and inspection
planning
Quality must be planned in and the quality plan must be executed against, reviewed, and changed
• Checklistsand
as needed. Then, the results of the work—the deliverables—should meet the product requirements.
checksheets
Testing should be done before submitting the work to the customer for approval.
• Cause-and-effect
With this in mind, let’s start with some basic definitions related to quality. diagrams
• Scatter diagrams
Definitions Related to Quality • Histograms
The definition of quality is the same for both predictive and adaptive environments. All stakeholders • Alternatives analysis
must be represented in the requirements-gathering process. This makes the requirements-gathering • Design of experiments
effort, the requirements documentation, and the project scope baseline very important to the quality • Process, root cause,
management effort. failure analysis
• Multicriteria decision
Quality analysis
Quality is the degree to which a project and the components of its product fulfill requirements. • Affinity diagrams
Nothing more, nothing less. Memorize this definition; it may help you get more questions right on • Audits
the exam. • Design for X

• Statistical sampling
Here is an example of an issue with quality requirements. Imagine a project in which a large group
• Questionnaires and
of truck drivers are required to use tablets with touch-sensitive screens. Prior to fleet deployment and surveys
during the test process, the project manager received comments that no matter how much the drivers • Project performance
tapped on the screens, nothing would happen. After some discussion with truck drivers and software reviews
engineers, the project manager realized the truck drivers’ hands were too rough and calloused for the • Inspection
touchscreens to work correctly. Here, the requirements were gathered and initial development had • Control charts
been done with the product owner alone, who lacked direct experience with drivers. The drivers would • Cost of change
• Frequent verification and
have been able to provide insight on their use of the technology during requirements gathering.
validation
Organizations and project managers determine how to approach the management of quality.
• WIP and cycle time
Ideally, this means planning quality standards and processes into projects and their products. The
quality process generally involves a range of practices. This includes following the established processes,
and inspecting deliverables to ensure they meet quality standards before meeting with the customer to
get validation and offer delivery. Along the way lessons are learned, and preventive or corrective action
may be taken on a process or deliverable. Quality processes and standards may be updated upon review
of how well they are working to bring about the desired product or service features.
If asked, “Is it better to plan in quality or to inspect to find quality problems?” almost everyone
will answer correctly that it is better to plan in quality. Exam questions focus on situations to see if you
know how to apply this knowledge.
249
Quality of Deliverables and Products TEN
Example Hie project manager finds that one of the team members has created their own process for installing
hardware. What should the project manager do? If this were an exam question, beginning project managers might choose
a response that relates to thanking the team member for the effort. More experienced project managers might select a
choice that relates to finding out ifthe process was a good one. The most experienced project managers, who also understand
these quality processes, select the choice that relates to investigating the quality management plan to determine if a standard
process should have been followed.
In an adaptive environment a project manager would likely capture quality requirements and acceptance
criteria in user stories. As user stories are prioritized, quality efforts will be planned in more detail for
upcoming releases and iterations. Short, time-boxed iterations ensure frequent opportunities to identify and
rectify quality issues through daily standups and retrospective meetings.
Definition of Done
Agile teams define what “done" looks like throughout the project. They decide on definitions of done at the project, release,
and story levels. The project level is roughed out based upon how much time and money there is to complete the project.
Requirements (or product functionality increments) are prioritized at this high level. A release map is created based on
how many releases are needed to get to the desired level of functionality. Releases are populated with stories, which
represent functionality decomposed into smaller, more manageable pieces. If you think of the handwritten “story card”
image, the definition of “done” is written on the back of the card (even though in reality story cards are now often created
electronically).
Remember that in adaptive environments requirements may change frequently so the project team reviews and
revises definitions of done on a regular basis. Here is an example of definitions of done using our earlier example of a
project to produce touchscreen tablets for truck drivers:
• Story The two stories that make up feature b have been developed and integrated, documented, tested, and accepted
by users in the field.
• Release For release 1, a working prototype touchscreen tablet has been tested and accepted by users in the field,
including features a, b, d, and g.
• Project A working touchscreen tablet has been tested and accepted by users in the field and passed on to operations
for manufacture, with features a, b, d, g, k, t, x, and y.
Grade
Different from quality, grade refers to a general classification of a product like the strength of concrete (e.g. how much
weight can it hold) that can be used for various technical specifications (e.g., foundation of a building or sidewalk). You
may see a situational question on the exam that uses the term “grade” in discussing quality so do not confuse the two.
Example A low grade of concrete that supports limited weight and has zero defects might be sufficient for a project s
needs as long as it meets the established quality requirements (for example, a small basketball court in a playground that
just needs to hold the weight of human foot traffic). It is not necessary to spend more on materials that will hold more
weight than requirements call for. Similarly a high grade of concrete intended to sustain more weight could be of
unacceptable quality if it is mixed, poured, or cured to low standards or otherwise fails to meet established quality metrics.
Think About It. Imagine a project to build a stadium. The concrete part of the work is two-thirds done when the
buyer arrives one day and tests the strength of the concrete. The buyer finds that the concrete does not meet the
requirements for strength that are clearly stated in the contract. You can imagine the problems when the buyer
says, “Rip out the concrete; it is not acceptable.” Whose fault is this? Why did this occur?
Could we say it is the buyers fault for not testing the concrete sooner? You might argue that case, but isn’t the real
fault with the seller for not selecting the right grade of concrete and ensuring the quality of the finished deliverable
before meeting with the customer to validate it? Where was their quality plan? They should have planned for when and
how they would confirm they had met this requirement. Lack of attention to quality in this scenario needlessly added
considerable risk to the project, which resulted in rework and additional expense.
250
TEN Quality of Deliverables and Products
Here is something else to consider. Have any of your customers ever said one of your deliverables was not acceptable,
even though they had not provided you with a definition of what was acceptable? It is important to know—in advance—
what acceptable quality is and how it will be measured on the project. You can then determine what you will do to make
sure the project meets those requirements. It is the project manager’s responsibility to make sure quality is defined in the
plan for each deliverable, otherwise there will be unclear acceptance criteria, such as “the customer likes it.” Performing the
quality management process well helps the project manager avoid many issues on the project.
Gold Plating
Do you remember a time on a project when one of your team members delivered more than what was needed? Can you
think of a time when you’ve had trouble keeping a project from producing a palace when all you needed was a garage, for
example? Gold plating refers to giving the customer extras (extra functionality, higher-quality components, extra scope, or
better performance). Gold plating is often the team’s impression of what is valued by the customer, and the customer might
not agree. Since most project teams have difficulty meeting the project objectives, all available effort should go into
achieving those objectives, instead of into gold plating.
Sometimes gold plating is not planned, but rather arises out of a team member’s efforts to do their best. The project
manager must be on the lookout for team members providing more than is required for the project.
Prevention over Inspection

Is it better to inspect work to find problems or to prevent them in the first place? Which takes less effort and is less costly?
Remember that quality must be planned in, not inspected in! You may see exam questions that test your understanding
that failure to plan quality into a project will lead to problems later in the project.
Continuous Improvement
Continuous improvement involves continuously looking for ways to improve the quality of work, processes, and results.
Within an organization it can include analysis of how quality management is planned and utilized on projects. There are
several approaches to continuous improvement relevant to the exam.
• Kaizen The terms “continuous improvement” and “Kaizen” are taken to mean the same thing on the exam; however,
in Japan, Kaizen means to alter (kai) and make better or improve (zen). Kaizen is a general term, while continuous
improvement is a quality movement. In the United States and most of Western Europe, continuous improvement
focuses on major improvements. In Japan, the emphasis is on smaller improvements.
• Total Quality Management (TQM) TQM encourages companies and their employees to focus on finding ways to
continuously improve the quality of their products and their business practices at every level of the organization.
• Six Sigma Sigma (another name for standard deviation) indicates how much variance from the mean has been
established as permissible in a process. This is a methodology for achieving organizational process improvement and
high levels of correctness with extremely reduced variances. The higher the sigma, the fewer deviations (or less
variance) in the process. The level of quality required by an organization is usually represented by 3 or 6 sigma.
Just in Time ( JIT)

JIT means having suppliers deliver resources just before they are needed, thus decreasing inventory to nearly zero and
decreasing unnecessary cost. A company using JIT must achieve a high level of quality in their practices; otherwise, there
will not be enough materials or equipment to meet requirements because of waste and rework. A JIT system forces
attention on quality as well as schedule.
Quality-related PMI-isms. The exam may test your understanding of the need to satisfy project requirements
as opposed to giving the customer extras to “make them happy." Know the following PMI-isms to answer exam
questions correctly:
• Quality means meeting requirements, not adding extras.
• All product developers must know the quality standards and metrics to be used on the project.
• Quality should be checked before an activity or work package is completed.
• Quality should be considered whenever there is a change to any project constraint.
• Some quality activities may be performed by a quality department.
• The project manager should:
/ Determine the metrics to be used to measure quality before project work begins.
/ Define project quality management processes and plan for continuous improvement.
/ Recommend improvements to the organizations standards, policies, and processes, which are expected
and welcomed by management.
/ Ensure that authorized approaches and processes are followed.
/ Ensure the quality standards and processes on the project are adequate to meet product
quality requirements.
Overview of Planning and Managing Quality

The following references indicate that Quality Management in the predictive Process Groups model is represented by Plan
and Manage Quality of Products/Deliverables in the Examination Content Outline (ECO). In addition, when managing
procurements, you will need to ensure that the buyer and seller have the same understanding of the quality process. See the
“Procurement” chapter for more information.

Domain II Quality Management Domain 2.4
Planning
Task 7 Plan Quality Management — Planning Domain 2.6
Plan and manage quality of products/deliverables
Manage Quality — Executing Delivery
Control Quality — Monitoring Domain 2.7

& Controlling Measurement
Domain 2.8
Uncertainty
Think About It. Can you see how other tasks from domain II, such as stakeholder engagement and
communications, can affect quality management? What if two team members disagree on how to approach
building a deliverable? The quality management plan needs to reflect the best, agreed-upon, and bought-into
approach. Skills such as conflict management and team leadership from domain I are invaluable to come to the
best solution. Negotiation and team-building skills (also from domain I) support the best quality management
plan and overall quality control. Take time now to review the ECO and think about these connections.
Here is an example to help you commit your understanding of quality for the exam to memory:
Example A student in one of RMC’s classes looked out the window and noticed someone painting the limestone of
an old building white. The student said, “That is not quality!” Let’s think about this for a moment. Why would painting the
limestone white not be considered “quality ”? The student s issue was that the wonderful old stone was being painted instead
of being cleaned. This was a disagreement with the requirements, not the quality of the work. If the painting contract
252
required the painter to use a certain paint and follow painting standards, and he was doing so, the work was meeting the
Figure 10.1 shows the Quality Management process from the Process Groups model perspective. This figure and the
following discussions of Plan, Manage, and Control Quality can help you envision what the plan-driven Process Groups
model of quality management looks like. It can also help you understand quality management in general.
This is not meant to suggest that agile approaches do not have their distinctions, but planning for and managing
quality on projects has the same principle regardless of your projects life cycle and development approach. Following this
discussion based on the Process Groups model is additional information that comes from agile methodologies.

KA: Quality Management
Key
approaches
or agile methods
——> Changes that cause a

Figure 10.1 Quality management process
Think About It. Many people getting ready for the exam have limited quality management experience, so they
O struggle with envisioning how quality management efforts fit into managing a project in the real world. Now that
you can envision the overall quality management process, walk through it as you review the following quality
“ management process flow:
Change
procedures available to help.

Quality
Continuous
Dept Tailor
improve
helps processes &
ment
standards
Figure 10.2 Quality management process flow
253
Understanding the Differences between Plan, Manage, and Control Quality

One of the major challenges people have while studying this topic is understanding the differences between Plan, Manage,
and Control Quality in the Process Groups model. Here are those three quality processes and a brief overview of each.
• Plan Quality Management This process focuses on defining quality for the project, the product, and project
management, and planning how it will be achieved.
• Manage Quality This process is focused on how work is being done. Its purpose is to ensure the team is following
organizational standards, policies, and processes as planned to produce the projects deliverables. The project manager
also evaluates whether the quality management plan or processes need to be improved.
• Control Quality This process includes examining the actual deliverables produced on the project to ensure they are
correct and meet the planned level of quality, evaluating variances, finding the source of problems, and recommending
ways to address them.
TRICKS You are not likely to encounter differences between “manage” and “control” for quality on agile-related
OF THE questions, but understanding the difference in the Process Groups model can help you get more predictive
TRADE* questions right.
The following chart presents a trick for understanding the three quality management processes. Study it now
TRICKS to gain an understanding of the focus of each process before reading the rest of this chapter. The trick is to
OF THE
TRADE understand that in the “manage” process the project manager is concerned about the quality processes,
procedures, and standards that are supposed to be used on the project, whereas in “control” the project
manager is concerned about determining the quality of deliverables. Come back and review this chart after you read the
rest of the chapter.
Plan Quality Management Manage Quality Control Quality

Process Group
Planning Executing Monitoring and controlling
High-Level Description of What Each Process Focuses On

• What is quality? • Are we following the policies, • Are the results of our work
metrics, procedures, and meeting the standards and
• How will we ensure it?
processes as planned? required metrics?
• Are the procedures and • Is the variance within acceptable
processes giving us the limits, or do we have to take
intended results? action?
• Will we meet the quality
objectives?
More Detailed Description of What Each Process Focuses On

• Review project plans and • Use measurements from Inspect and measure the quality
artifacts to understand project Control Quality to confirm of deliverables to determine
quality requirements. that: whether they meet requirements.
• Identify quality practices and - Policies and processes are Use the PMIS to track deviations
internal and external standards being followed. from planned quality.
relevant to the product and
- Policies, metrics, and processes are Identify the need for quality
project (OPAs and EEFs).
still appropriate for the project. improvements (corrective or
• Tailor practices and process to preventive action, and defect
- Policies and processes are effective
the project. repair).
in achieving planned quality results.
Plan Quality Management Manage Quality Control Quality

• Determine quality processes for • Use data-representation • Complete checklists and
the project. techniques to analyze results checksheets, perform tests;
of quality testing. evaluate results.
• Determine how you will
measure and what work you • Determine the root cause of • Use data-representation methods
will do to ensure you meet the problems/variances from plan. to graphically depict testing
standards. results.
• Continuously improve to
• Plan for process improvement. increase efficiency and • Verify deliverables.
effectiveness.
• Perform cost of quality, • Validate approved changes.
cost-benefit, and other analyses • Create test and evaluation
• Recommend testing process
to ensure the appropriate levels documents for use in Control
improvements.
of quality. Quality.
• Use and update lessons learned.
• Determine roles and • Quality audit: Determine if
responsibilities for achieving project activities comply with • Submit change requests.
quality requirements. organizational and project • Update the project plan and
policies, processes, artifacts.
• Plan for testing and inspection
procedures.
to ensure requirements,
performance, reliability, and • Solve problems.
quality objectives will be
• Produce reports.
achieved.
• Share good practices with
• Integrate the quality
others in the organization.
management plan with other
plans to balance the needs of • Submit change requests.
quality with other project • Update the project plan and
requirements and constraints. artifacts.
Desired Outcomes From Successful Quality Management

Assume for the exam that quality is properly planned and managed unless information in an exam question indicates
otherwise. This means that the following outcomes should be expected as a result of quality management:
• Quality processes, procedures, and inspections are completed.
• The team has carefully inspected their own work to ensure it meets requirements (in manage and control quality)
• Product quality changes are made as needed before meeting with the customer to gain acceptance of deliverables (in
validate scope).
• Changes are made to quality processes and procedures throughout the project to ensure that they are bringing the
team and stakeholders the desired results.
• Few quality problems arise on the project since quality is carefully planned, executed, and controlled. However, in
cases where projects are of a “research and development” nature, it is understood that trial and error is part of the
project outcome.
• Stakeholder engagement and communications are of high quality so few or no misunderstandings with stakeholders
should result.
• Projects routinely achieve their goals and objectives and their products deliver the value needed for the customer. This
gives the customer the benefit for which the project was undertaken and contributes to advance the strategic objectives
of the performing organization.
255
Plan Quality Management

Plan Quality Management is a process to identify all relevant organizational or indus Process Groups Model
try practices, standards, and requirements for the quality of the project and its prod PG: Planning
uct, and then plan on how to meet those standards and requirements. The main out Process: Plan Quality Management
put of this process is a quality management plan.
ECO
The level of quality efforts should be tailored to the needs of the project and
quality must be balanced with the other project constraints. Standards may come Domain II
Task 7 Plan & manage quality of
from within the organization or from an external resource.
products/deliverables
That sounds easy, right? Often it is not. In many organizations, practices are not
standardized. If this is true on your projects, take some time now to imagine PMBOIC Guide
standardized practices that would be ideal for your projects and how they might help Domain 2.4 Planning
you. Here is a practical example:
Example A construction company could establish a standardized practice for
installations on home kitchen construction projects. Imagine all the installers within that organization putting together
their best ideas to improve the installation work on future projects. That would be a valuable effort that could improve
quality and safety while saving time and money. Each project team would then be required to review the standard and
tailor it to their particular project s install.
Examples of available external standards include ISO 9000 (from the International Organization for Standardization),
OSHA (from the Occupational Safety and Health Administration), and the United Nations Convention on Contracts for
International Sale of Goods (CISG).
Creating the Quality Management Plan

As quality management is being planned, keep the following in mind:
• OPAs can help identify relevant standards, policies, and procedures and include lessons learned from previous projects.
• A project manager may create additional project-specific standards and procedures that are needed on how quality is
defined for each piece of work.
• For the exam, understand that this effort should also include defining processes for how project management activities
should be done and suggesting improvements to existing processes.
• The customer s quality standards might be specified in a contract or need to be discovered as part of the Collect
Requirements process.
Quality requirements that are later used to control quality are documented, analyzed, and prioritized according to the
requirements management plan. Examples of such standards are the:
• Procedure for how to install a particular custom • Acceptable number of software bugs per module
kitchen faucet • Strength of concrete
• Average time per installation
Management plans and documentation that aid in quality planning include the:
• Stakeholder engagement plan • Stakeholder register
• List of the major project deliverables • Risk thresholds
(in the requirements management plan) (in the risk management plan)
• Approval requirement • Scope baseline
(in the project charter) • Requirements traceability matrix
• Assumption log
The scope baseline helps the project manager maintain the proper perspective and plan quality to the appropriate
level. The assumption log provides insight into the level of quality that is assumed to be acceptable on the project. The
requirements traceability matrix shows the origin of requirements related to quality and will be used to confirm that quality
requirements, including external compliance requirements, have been achieved.
256
Artifacts of Plan Quality Management

Most quality management plans include the standard practices already discussed, along with roles and responsibilities for
quality management. Reports and metrics that will be used are included, along with what parts of the project or deliverables
will be measured and at what intervals. Strategies for continuous improvement of processes and procedures are
also included.
Planning quality will result in a number of artifacts and updates to existing documents, including:
• Quality management plan • Project document updates
• Project management plan updates • Quality metrics
Planning quality management will also result in iterations of other project artifacts. Here are some examples:
• Scope baseline • Budget
(Scope statement, WBS and WBS dictionary) • Risk register (to add quality-related risks)
• Project activity list • Schedule
• Requirements traceability matrix • Resource assignments
Quality Metrics
Throughout this book there is an underlying theme that the project manager must know how the project is performing
compared to what was planned and be able to determine when to request changes. The only way to effectively do this is to
determine metrics in advance whenever possible and decide what range of variation is acceptable.
Metrics to use on a project could represent the:
• Number of changes (to help measure the quality of the planning process)
• Variance related to resources utilization (Were more or less resources needed than planned? How big is the variance?)
• Number of items that fail inspection
• Variance of the weight of a product produced by the project compared to the planned weight
• Number of bugs found in software being developed as part of the project
Manage Quality
The efforts for this Manage Quality process focus on making certain that the project Process Groups Model
work to create the deliverables is done according to the standards and processes estab PG: Executing
lished for the project in the project management plan. The project manager must also Process: Manage Quality
make sure that these quality standards are effective in meeting the needs of the proj
ect. ECO
A group outside the project team, such as a quality department, often helps with Domain II
this work. For the exam, assume there is a quality department unless evidence in the
products/deliverables
question suggests otherwise.
The Manage Quality and Control Quality processes work hand-in-hand. In PMBOK* * Guide
Manage Quality, test and evaluation documents are prepared for use in Control Domain 2.6 Delivery Performance
Quality. In turn, this process analyzes measurements gathered in Control Quality and
uses the quality management plan, including quality requirements, to answer the
following questions:
• Are the procedures and processes being followed as planned ?
• Are the quality requirements, organizational policies, and processes identified in the quality management plan
producing the intended results?
• Can the processes and procedures be improved?
• How can we increase efficiency and prevent problems?
• Based on what we know now, is the work we planned the right quality work for this project and the right work to
meet customer requirements?
The process of managing quality also includes evaluating all aspects of the product design to confirm the end result
will meet quality requirements and identifying possible improvements to the design.
257
Artifacts of Manage Quality

Test and evaluation documents for use in Control Quality, such as control charts, checklists, and test plans provide a
format with which to evaluate whether quality objectives have been met. Project documents such as a requirements
traceability matrix may also be updated here. Quality reports interpret and document the results of both Manage and
Control Quality activities. They can present information in different formats and are used to identify necessary changes to
plans, policies, and processes (for Manage Quality) and to the product (for Control Quality) to ensure that quality
requirements will be met throughout the life of a project.
Control Quality
The Control Quality process addresses the quality of the product, service, or result Process Groups Model
of a project. Control means measure, and in controlling quality we measure whether PG: Monitoring and Controlling
the product of the project conforms to requirements. This process helps ensure cus Process: Control Quality
tomer acceptance, as it involves confirming and documenting the achievement of
agreed-upon goals for each deliverable. ECO
What is needed to carry out Control Quality? Inputs include: Domain II
• Deliverables products/deliverables
• Test and evaluation documents (developed in Manage Quality)
• Work performance data PMBOK* Guide
• Quality management plan and possibly other project artifacts
• Quality metrics (agreed-upon measures of quality developed in planning)
• Approved change requests (from integrated change control)
Although a project manager and team must be involved in quality control, a quality department may complete much
of this work in large companies. The department then informs the project manager about quality issues through change
requests accompanied by the necessary documentation.
It is during Control Quality that the height of doors in a manufacturing process or the number of bugs per module
will be measured. Quality control helps answer the following questions:
• Are the results of the work meeting agreed-upon standards and thereby meeting requirements?
• What are the actual variances from the standards and are they within acceptable limits?
• What changes in the project should be considered?
Artifacts of Control Quality

Control Quality artifacts include measurements, work performance information, verified deliverables, and possibly change
requests, as well as updates to the quality management plan, issue log, test and evaluation documents, lessons learned, and
the risk register.
Control Quality—Specific Terminology

To better understand questions relating to Control Quality, be familiar with the following terms:
• Mutual exclusivity The exam may reference statistical terms such as “mutual exclusivity.” Two events are said to be
mutually exclusive if they cannot both occur in a single trial.
Example You cannot at the same time see both sides of the same coin.
• Probability This term refers to the likelihood that something will occur. Probability is usually expressed as a decimal
or a fraction.
• Normal distribution A normal distribution is expressed as a chart that takes the shape of a bell curve. It is used to
measure variations away from the “norm.”
258
• Statistical independence This concept means that the probability of one event occurring does not affect the
probability of another event occurring.
Example The probability of rolling a six on a die is statistically independent from the probability of getting a five
(or even another six) on the next roll.
• Standard deviation (or Sigma) A metric for a range of measurements is its standard deviation. This metric shows
how far a measurement is from the mean (i.e., the average) of the measurements in the range. It signifies whether the
range of measurements represents a stable process or output.
If a situation posed in an exam question is looking forward in time, it is most likely a planning function. If it is
TRICKS
OF THE looking back in time at processes and procedures, it is most likely part of a managing function. If it is looking
back in time at results, like a deliverable, it is most likely part of a control function.
Quality Management Methods

Understanding both predictive and adaptive methods for quality management can help you get several questions right on
the exam. The methods used to manage quality have been combined in this section to make it easier for you to understand
them and to distinguish what tools are used in each of the three quality management processes as outlined in the Process
Groups model. Notice that some methods can be used in more than one quality process.
Methods for Planning Quality

The following tools and techniques are used for quality management planning. Note that meetings can be used for
any process.
Interviews, Brainstorming, and Benchmarking

You may recall learning about these techniques in the “Scope” chapter. Interviews and brainstorming can help identify
appropriate ways to measure quality and the metrics or processes to be used. Benchmarking is utilized to review
methodologies used by comparable projects or organizations to establish quality metrics and acceptable variance ranges,
and to measure quality.
Decision-making Methods
Planning key decisions might include selecting the most critical metrics or prioritizing quality requirements. Decision
making tools and techniques for this process include:
• Multicriteria decision analysis (or multicriteria weighted analysis) This method uses a matrix to list and scores
various factors in relation to one another. It may be used in planning quality to measure the cost of quality efforts
versus their benefits.
• Prioritization diagram This matrix is a scatter diagram where effort is shown on the horizontal axis and the value
of that effort is shown on the vertical axis. In quality planning the cost of quality efforts versus their benefits may be
evaluated in this way. Note that PMI uses the term “matrix” instead of “diagram” and you may see the terms used
interchangeably in project management literature. Technically there is a difference but you should know both terms
since we cannot predict which will be used on the exam.
Cost-benefit Analysis
Using this data analysis technique, the project manager analyzes the benefits versus the costs of quality efforts to determine
the appropriate quality level and requirements for the project. A decision-making method may be used as a tool to do this
analysis. The exam will test your knowledge about the effects of quality efforts, or the lack thereof. Note that if you have
poor quality, you might also have increased costs, decreased profits, low morale, low customer satisfaction, increased risk,
and rework. These possibilities make the cost-benefit analysis and cost of quality important tools for consideration.
259
Cost of Quality (CQQ)

Evaluating the cost of quality means making sure the project is not spending too much to achieve a particular level of
quality. It involves balancing the costs of conformance and non-conformance to quality. There are four categories of costs
associated with quality. They are prevention, appraisal, internal failure, and external failure.
• Prevention These are the costs associated with preventing any quality issues from occurring. There is a cost to the
planning and to getting systems in place to avoid having quality issues.
• Appraisal These costs are associated with monitoring and controlling quality. Quality audits, and verification and
validation are in this category.
• Internal failure This involves finding issues before the product reaches the customer. It includes waste (performing
unnecessary work), scrap (defective material that cannot be sold), and rework.
• External failure This occurs after the product has reached the customer. The example given previously about the
truck drivers and the touchscreen technology is an example of an external failure. External failures are the costliest and
the impact goes beyond money to reputation.
The following table provides examples of the costs of conformance and non-conformance to quality.
Cost of Conformance Cost of Non-conformance

- Quality training -Scrap
- Studies - Inventory costs
- Measuring quality of interim deliverables - Rework of deliverables not meeting
quality standards
- Customer satisfaction surveys (and work
to respond to issues raised) -Warranty costs
- Efforts to ensure everyone knows the - Lost business
processes to use to complete their work
Marginal Analysis Office Location

Cost of quality is planned and then monitored and measured throughout the project life
cycle. Marginal analysis is focused on finding the point at which the benefits or revenue to
be received from improving quality equals the cost to achieve it. Added attention to quality
does not produce added value. When that point is reached, the project manager stops trying
to improve quality.
Logical Data Models

A data model represents the types of data an organization needs to use in a particular
application, and the relationships between those data types. Figure 10.3 shows part of a data
model called an entity relationship diagram (ERD). It illustrates the data associated with
“office location” is related to data associated with “worker.” This example shows that a worker
does not need to be assigned to an office location. This is a business rule that is verifiable
and testable.
Mind Mapping
As discussed in the “Scope” chapter, a mind map is a diagram of ideas or notes to help
generate, classify, or record information. It is used here to facilitate the gathering of quality
requirements and illustrate their impacts on other parts of project planning.
Matrix Representations
A matrix is information represented in a row and column format. It visually represents the
relationship between two or more sets of items. In planning, matrix diagrams can be used to
list quality requirements in one column and their characteristics in others, for example, Figure 10.3
labels indicating levels of priority. The list could then be sorted to easily identify those that Logical data model
are most critical. An agile backlog is a good example of data represented as a matrix.
260
Prioritization Matrix (Chart) High

This tool can be used to numerically rank available options. It is useful for decision
analysis about quality management planning. Figure 10.4 is a prioritization matrix Continuous Get design 100%
integration right before build
indicating the project manager should do the top two choices, but probably not do
each unit test more than three times. On the exam you may find the word “matrix,”
“diagram," or “chart” used to refer to this tool.
I
Flowcharts Unit test Unit test more
3 times than 3 times
Also known as process flows or process maps, these can be used in many elements
of project management. They show how a process or system flows from beginning Low
---------- >
to end, how the elements interrelate, and alternative paths the process can take. Low Effort High
Flowcharts can be used to: Figure 10.4

• Define and communicate processes to be used on the project, avoiding errors. Prioritization matrix (diagram)
• Show dependencies in a process to determine where quality problems may
arise in the process.
• Study the steps of a process that is causing a quality defect. This analysis might uncover confusion among the team or
point out ways the process must be adjusted to make it more effective.
Figure 10.5 A generic flowchart
Test and Inspection Planning

Planning quality in includes determining how the team will confirm that the required level of quality has been achieved in
the completed project deliverables, as well as how the deliverables will be evaluated for performance and reliability. Testing
methods, which vary depending upon the type of product, service, or result being created by the project, are used to
control quality. The quality management plan is created to prevent quality issues.
Methods for Managing Quality

The following methods of Manage Quality are leveraged to analyze the processes used to create the product of the project.
Some of the same tools are used in Control Quality to analyze product defects.
Checklists
A checklist (figure 10.6) can be used to confirm that the steps of a process have all been completed. It
may also be used to analyze defects discovered in quality inspections, to look for issues within the
process, and to assess whether a deliverable meets the acceptance criteria.
Cause-and-Effect (Fishbone, Ishikawa, or Why-Why) Diagrams

A team can use cause-and-effect diagrams (see figure 10.7) to confirm that policies and procedures are
being followed and metrics are being used correctly, and that the procedures were adequate to produce
the required level of quality in project deliverables.
Figure 10.6
Checklist
261
In the following example, the defect “system will not install” is shown on the right and then various possible causes
are listed in an effort to find the root cause of the defect.
System
will not
install
FIGURE 10.7 Cause-and-effect diagram
Scatter Diagrams
This diagram tracks two variables to determine their relationship to the quality of the results. Figure 10.8 shows three
examples of scatter diagrams.
A regression line (or trend line) is calculated to show the correlation of variables, which can then be used for estimating
and forecasting. Figure 10.8 depicts the possible resulting patterns: a proportional or positive correlation of paint quantity
to drying time, an inverse or negative correlation of dryer fan speed to drying time, and no correlation between door
weight and drying time.
Door paint spray quantity (mL/sqm) Dryer fan speed (rpm) Door weight (kg)
Positive correlation Negative correlation No correlation
Figure 10.8 Scatter diagram
Histograms
Histograms can be used to analyze the type and frequency of defects
in order to identify where the quality improvements should be
focused. Figure 10.9 is an example of a histogram.
Document Analysis
Document analysis involves reviewing the results of testing and
other quality reports to identify ways in which the quality manage
ment plan and processes may not be supporting the production of
deliverables that meet the project quality requirements.
262
Alternatives Analysis
It is important to consider all the ways to solve an issue or problem. In Manage Quality, alternatives analysis may be used
to evaluate which action would best impact the results of quality management processes. For example, would a new
automated testing tool be more beneficial than redefining the testing process?
Design of Experiments (DOE)

This technique can be used for alternatives analysis and can quickly discover optimal conditions in which to produce a
quality deliverable. Experimentation is done to determine statistically what variables will improve quality. For example,
DOE can be used to look for ways to deliver the same level of quality for less cost. DOE is a fast and accurate technique that
allows the project manager to systematically change the important factors in a process and see which combinations have
an optimal impact on the project deliverables.
Example Designers might use DOE to determine which combination of materials, structure, and construction will
produce the highest-quality product. A caveat is that performing experiments for each variable in a process to assess its
impacts on quality can be time-consuming and can overlook interactions among variables.
Process Analysis
Process analysis is part of the continuous improvement effort and focuses on identifying improvements that might be
needed in project processes. Have you ever worked on a project where some of the activities or work packages were
repeated? This often happens when projects have multiple installations, such as a project to install software onto hundreds
of computers. The lessons learned on the first few installations are used to improve the process for the remaining
installations. Though this often happens naturally, planning it into certain points in the project improves results.
Root Cause Analysis

Root cause analysis in Manage Quality seeks to identify the processes, procedures, and policies within the plan that may
not work or that may need adjustment. Identifying the root cause of a quality problem helps the team to prevent it from
recurring. Cause-and-effect diagrams (as showing in figure 10.7) help in root cause analysis.
Failure Analysis
This is a type of root cause analysis. It analyzes failed processes or failed components of deliverables to determine what led
to failure. Corrective action or change requests are often outcomes of this analysis.
Multicriteria Decision Analysis

The project manager must facilitate quality decisions. A decision-making technique, multicriteria decision analysis is a
complex method of numerically assessing options based on criteria such as time, cost, and quality. It can be used throughout
a project to help the team reach agreement regarding the best way to solve a problem or improve quality. In Manage
Quality, the team may use this technique when considering whether to adjust the quality management plan or specific
processes or procedures. A prioritization matrix (described earlier) is a simpler decision-making technique.
Affinity Diagrams
We first saw this technique in the Collect Requirements process. In Manage Quality, affinity diagrams can help the project
manager organize and group the results of root cause analysis.
Example In Control Quality you may have determined the cause of a deliverable not meeting requirements. You can
use this information in the Manage Quality process to determine whether a change to the standards, policies, or procedures
in the quality management plan would address the root cause of the problem.
Audits
Imagine a team of auditors walking into your office one day to check up on the project. Their job is to see if you are
complying with company standards, policies, and procedures as defined in the quality management plan, and to determine
whether those being used are efficient and effective. This scenario represents a quality audit. Do not think of a quality audit
as a negative event. Instead, a good quality audit will look for new lessons learned and effective practices that your project
can contribute to the performing organization. The work of a project is not only to produce the product of the project; it
could also contribute to the best practices within the organization, making the organization better.
263
If you do not have a team of auditors from the quality department coming to see you on your projects, do you take on
the responsibility of looking for opportunities to identify lessons learned and best practices? Although quality audits are
usually done by the quality department, the project manager can lead this effort if the performing organization does not
have such a department.
If you see the word “audit” on the exam, the question is most likely related to Manage Quality. If you see the
word “inspect” on the exam, the question is most likely related to Control Quality. We audit processes and we
inspect product.
Design
Design for X is another way of analyzing variables to evaluate both the effectiveness of the quality management plan and
the team’s ability to meet objectives. The X in the name can represent an attribute of quality, such as reliability, security, or
serviceability. If the plan is not delivering the intended results in relation to the variable being analyzed, Design for X can
help determine what changes are needed.
Problem-solving
Think of how important this technique might be when encountering quality problems. Gaining a good understanding of
the real problem is the first step towards finding an effective and long-lasting solution. Problem-solving can be used when
considering quality improvements or to determine how best to respond to deficiencies identified in quality audits.
The following are the steps used to analyze a quality (and any) problem:
1. Define the real or root problem. It is often not what is 4. Pick a solution,
presented or what appears to be the problem. 5. Implement a solution.
2. Analyze the problem. 6. Review the solution and confirm that the solution
3. Identify solutions. solved the problem.
Methods for Controlling Quality

The ultimate goal in controlling quality is to test (inspect and verify) that each deliverable meets the metrics and
requirements as stated in the quality management plan, including the customers acceptance criteria, and that the
deliverable is ready to move to the Validate Scope process—which should end in customer acceptance. The following
methods were explained earlier in this chapter:
• Checklists In Control Quality, checklists are used to determine that all required features and functions are included,
and that they meet acceptance criteria. Checklists may be part of the test and evaluation documents created in
Manage Quality. A quality checklist can be a list of items to inspect, a list of steps to be performed, or a picture of the
item to be inspected, with space to note any defects found.
• Root cause analysis This method is used to identify the cause of quality problems, including defects, to determine
how they can be remedied so the problem does not happen again.
• Cause-and-effect diagrams In Manage Quality, we discussed the application of the cause- and-effect diagram to
determine the root cause of quality issues relating to plans, processes, or procedures. In Control Quality, this tool can
be used to lookbackward at what may have contributed to defects that have occurred as well as to analyze the impact
of defects on the quality and acceptability of a deliverable. Look back to figure 10.7 to review this concept.
• Scatter diagrams A scatter diagram can be used to control quality by comparing actual results to what was antici
pated, and to estimate and forecast future outcomes based on this comparison. For review, lookback to figure 10.8 and
its accompanying description in the Manage Quality section.
Example Imagine that our door manufacturer has a project to develop a new painted door product line. Scatter
diagrams may be used to determine the relationship of independent variables, such as paint quantity, dryer fan speed,
and door weight, to the dependent variable of drying time, or to correlate defects to other variables in the process.
• Histograms and Pareto charts The results of measurements taken in Control Quality are displayed on a histogram
to determine the problems that need the most immediate attention or that are most likely to prevent the project from
achieving its quality requirements.
Compare the histograms in figure 10.10 and note that a typical histogram (on the left) presents data in no particular
order. A Pareto Chart, as shown on the right, is a commonly used type of histogram that arranges the results from most
frequent to least frequent to help identify which issues are resulting in the most problems. Also known as the Pareto
Principle, the 80/20 “rule” states that 80 percent of problems are due to 20 percent of the root causes. Addressing the
root cause of the most frequent problems makes the greatest impact on quality.
The following methods are specific to Control Quality. Defect Frequency

Checksheets Too long will
A checksheet is a type of checklist that can be used to keep track of data, such as
quality problems uncovered during inspections, as well as to document how often
Too narrow III
a particular defect occurs, as illustrated in figure 10.11. Too wide Willi
Statistical Sampling Too short II
Let’s think about a project to create a new process for manufacturing doors. There
would be a small allowable variation in the height and width of the doors being Figure 10.11 Checksheet
made. The first efforts at creating the doors must be checked to ensure the doors
meet requirements. But wouldn’t inspecting every door take too much time? Enough doors could be sampled to confidently
check requirements adherence without inspecting every door. It is best to take a sample of a population if the project
manager believes there are not many defects, or if inspecting the entire population would take too long, cost too much, or
be too destructive.
The sample size and frequency of measurements are determined in planning, the process is documented in managing
quality and the sampling is done in control. Experimentation maybe needed to determine a sample size that gives the team
a safe measure of door size accuracy.
Sampling can also be done for project management activities. For example, you may initially check the on-time status
for 5 out of 50 of a group’s activities. If you find issues in those 5, you can assume you’ll need to check for more issues
among the remaining 45 activities.
Questionnaires and Surveys

Questionnaires and surveys may be used in Control Quality to gather data on details of problems or defects, or to confirm
that customers or end users are satisfied with deliverables that have been deployed on the project. The results can be used
to determine whether conformance to quality has been achieved.
Project Performance Reviews

The project manager or quality department may conduct periodic performance reviews to formally assess how the project
is doing in terms of meeting quality requirements. This type of review involves comparing the results of control
measurements to metrics identified in the quality management plan. It may bring to light changes necessary to achieve
265
Inspection
Inspections are used to verify that deliverables meet the requirements. Inspections may be referred to as walk-throughs and
generally include measurement of project deliverables. Checklists and control charts may be used to capture and illustrate
the data, respectively. Inspections are also used to check that previously approved changes have been made correctly, and
that the changes have provided the intended outcomes (validated changes).
Control Charts
The use of control charts and their parameters are established in Manage Control and are used in Control Quality to help
determine if the results of a process are within acceptable limits.
In this section we talk mostly about variances in product quality, but a control chart can also be used to represent and
monitor data on project performance, such as cost and schedule variances. Outside of control charts a project manager can
have control limits for many things. How about for a work package? Is one hour late in its delivery a problem? How about
one day? Control limits help the project manager know when to act.
To better understand the need for control charts, imagine a door manufacturer undertaking a project to create a new
production line. To make sure the production facility will create doors that meet quality standards, it’s essential to monitor
the processes and output so the new production line can become an ongoing business operation. Would each door be the
same exact height? Weight? Not likely. Each door should be within the range of normal and acceptable limits.
Let’s look at some of the related terms you should know for the exam. The following can be indicated on a control
chart. As you study these terms, use figure 10.12 to envision what they mean in practice. Understanding these terms and
how control charts are used can help you get a few more questions right on the exam.
• Plotting the control chart During the Control Quality process, samples are taken and the data are plotted in
software that can render a chart (see the small squares shown on the control chart in figure 10.12). The control chart
shows whether each sample is within acceptable limits. If the data does not fall within the acceptable range, the results
are considered to be “out of control,” which indicates a problem that needs to be fixed.
• Upper and lower control limits Control limits are often shown as two dashed lines and are the acceptable range of
variation of a process or measurement’s results. Control limits indicate what is stable versus unstable (out of control).
Data points within this range are generally thought of as “in control,” excluding the rule of seven (described later in
this section) and are an acceptable range of variation.
• Mean (average) The mean is indicated by a line in the center of the control chart. A normal distribution curve
represents the acceptable range of variance around a mean, and it falls within the boundaries of the control limits. In
figure 10.12, the normal distribution curve is on the right side of the first control chart.
• Specification limits While control limits represent the performing organization’s standards for quality, specification
limits represent the customer’s expectations—or the contractual requirements—for performance and quality on the
project. Specification limits are inputs from the customer. Therefore, they can appear either inside or outside the
control limits. In the first chart of figure 10.12, they are the solid lines above and below the dashed lines (which
represent the upper and lower control limits). To meet the customer’s specification limits, the performing organization’s
standards for quality (control limits) must be stricter than those of the customer. On the exam, assume that
specification limits are outside the upper and lower control limits.
• Out of control The process is out of a state of statistical control under either of two circumstances:
■/ A data point falls outside the upper or lower control limit.
*/ There are nonrandom data points; these may be within the upper and lower control limits, such as the rule of
seven (described next).
Think of “out of control” as a lack of consistency and predictability in the process or a problem with its
results. Also be aware that control limits may be called “tolerances” in agile environments and “out of
control” is sometimes referred to as “out of tolerance.”
• Rule of seven The rule of seven is a general rule (and you may see a general rule described as a “heuristic”). It refers
to a group or series of data points that total seven or more on one side of the mean. The control chart on the right in
figure 10.12 has seven nonrandom data points that fall above the mean. The rule of seven tells the project manager
that, although none of these points are outside the control limits, they are not random, and the process is out of
control. The project manager should investigate this type of situation and find a cause.
266
• Assignable cause/special cause variation An assignable cause or special cause variation signifies that a process is
out of control. (See the data point sitting on the lower control limit in the left chart in figure 10.12.) If there is an
assignable cause or special cause variation, it means a data point, or a series of data points, requires investigation to
determine the cause of the variation. The project manager could use additional tools, such as a cause-and-effect
diagram, to try to uncover the root cause of the variation.
J! 7T
I■ \ R \ f. \ /
■■■\■\■
■■
Figure 10.12 Examples of control charts
Agile Quality Management Concepts

Many of the concepts we have discussed related to the Process Groups model may be applicable to an agile or
hybrid project. The following sections describe tools considered to be specific to agile. These may be used
throughout the life of a project, in both adaptive and hybrid environments. It’s important to understand these
terms and concepts for exam questions that test your knowledge of adaptive quality management practices.
Cost of Change
We discuss in the “Stakeholders” chapter how important
it is to identify and analyze stakeholders as early as
possible and to diligently renew this effort throughout
the project. This is because missed stakeholders with new
requirements later in the project increase the cost of
change. This philosophy applies to quality too. The
sooner quality issues are discovered with project
processes or a product increment being built, the easier
and less costly it is to fix those issues and learn from them.
Agile and hybrid processes call for iterative and
incremental development and short iterations. That
means that small increments of work can be evaluated
and the team can get feedback on the evolving product as
soon as possible. This allows for issues to be found early
and resolved quickly so that added costs to the project
can be avoided. This also means less rework. The cost of Figure 10.13 Cost of change
change curve in figure 10.13, shows that issues found Image copyright ©Scott W. Ambler, www.agilemodeling.com
during a test environment (point l) are much cheaper to
fix than issues found during production (point 2). This is an intuitive concept but visualizing it with this figure is helpful if
you have not encountered it before.
Iterative and Incremental Development

The agile and hybrid use of iterative and incremental development and short iterations, and working closely together in
small teams means the project manager and team are willing participants in a daily feedback loop related to the work of
building the product. This fosters quick and early awareness of quality issues when they are usually still small and minor,
lowering the cost of change.
267
Frequent Verification and Validation

Agile uses regular testing, short timeboxes, and reviews to meet the customer’s needs. Frequent verification and validation
is a way to discover and address human error or the misinterpretation of customer expectations, early and often. This
practice is built into all agile methodologies.
Example Library software is being updated in two-week iterations. The team adds a search capability to find books
by title. At the iteration review the team shows this new search function to the head librarian and staff. One of the staff
suggests that the user should be able to just type the book title without putting the title in quotation marks as the demo
showed. The team agreed to make this improvement.
Agile Meetings (Ceremonies) Are Focused on Quality

These types of meetings provide a way for issues to be found early in the product life cycle. One question in the daily
standup—Are there any impediments to the project work?—can bring up potential issues and problems before there is an
impact on quality or schedule. If a concern is brought up during a daily standup, the project manager must investigate and
resolve that problem once the meeting is over.
Let’s look at the four agile (or Scrum) ceremonies in terms of how they support quality.
Iteration Planning Meeting

The iteration (or sprint) planning meeting happens before each iteration. A lot has happened before this. The team has
participated in the visioning of the product and the project, created a backlog of high-level requirements (as stories),
prioritized with the help of the product owner, and have completed the high-level estimates needed to get this far. In this
meeting further details for the upcoming iteration are worked out and details already documented are verified.
Daily Standup Meetings

Daily standup meetings are designed to keep forward momentum during an iteration and to communicate so that everyone
knows what everyone is doing and what impediments there maybe to getting the iterations work done. No troubleshooting
is done and the project manager investigates identified impediments after the meeting.
Meeting rules are meant to keep the meeting short and focused, and for participants to answer these three questions:
1. What have you done since the last meeting?
2. What are you working on today?
3. Are there any issues or impediments to your progress?
Retrospectives and Meetings

While a retrospective meeting in a plan-driven environment is typically held at the end of the project, in an agile or hybrid
environment retrospectives most often take place at the end of each short, time-boxed iteration. The retrospective is an
opportunity for the members of the development team to inspect and adapt their methods and teamwork. Can you see
how this would be valuable to improve quality and identify issues as the product is being developed?
During the retrospective, the following questions are discussed:
1. What is going well?
2. What areas could use improvement?
3. What should we be doing differently?
Work in Progress (WIP) and Cycle Time

Work in progress (WIP) is the number of unfinished pieces of work going on at one time. Using Kanban boards are a
common method of limiting work in progress. Excessive WIP is associated with several problems:
• It represents money that has been invested but isn’t producing any return yet.
• It hides bottlenecks and masks efficiency issues.
• It carries the risk of potential rework if quality issues are discovered.
Agile and hybrid approaches place emphasis on limiting WIP to address these risks. Here, we’ll look at some concepts
related to WIP and how project managers limit WIP.
268
First, we’ll look at lead time and cycle time. Figure 10.14 is a Kanban board that shows the difference between lead
time and cycle time.
• Lead time This measures the length of time of an entire process. For example, from design to shipping, or from
requirements gathering through development to deployment.
• Cycle time This measures the length of time to go through part of the process. For example, from assembly to
painting, or from coding to testing.
Figure 10.14 Lead time and cycle time illustrated on a Kanban board
Cycle time can be calculated by using a formula that involves WIP and throughput. Throughput is the average time it
takes to complete the work (for example, the entire work of one iteration). Notice that throughput represents a global
average—in this example, for an iteration—not just an average for a particular cycle time.
_ . WIP
Cycle time = -------------------------
Throughput
Example Let’s say the team has 18 points of WIP and is working at a velocity of 27 points per iteration, which is the
throughput. So, 18 divided by 27 equals a cycle time 6.6 points.
Cycle Time = 18/27 = 6.6
(or 6.6 days for a 10-day iteration)
In other words, each of the cycles in question are on average 6.6 points worth of work.
Long cycle times mean there may be too much WIP, which increases risk and quality issues. Agile and hybrid
approaches avoid this by breaking the work down into small batches and focusing on finishing these and getting customer
acceptance as soon as possible.
Defects
Agile and hybrid projects also track the defect cycle time. This is the amount of time between when the defect was
introduced to the time it was fixed. By doing so, the project team can keep the cost of change to a minimum. Some project
teams actively track their average defect cycle time and set goals for the quick resolution of defects. This can minimize the
cost of fixing defects.
Keep Project Environments Open and Safe for People

A student in an RMC class confided in the instructor that they had discovered a defect on an iteration for webpage
development and were afraid to tell their project manager. The project manager, they said, would often call people out in
daily standups and embarrass them. The student was hoping that the defect would be caught later when it was hard to trace
back the work to them.
269
As we’ve said before, defects found later increase the level of risk to the project. Think back to that cost of change
curve. It is less costly for the defect to be fixed as soon as it is known rather than later when the finished product is too
complex to troubleshoot.
It is important for the project manager to create an environment where people feel comfortable to speak up and note
issues as soon as possible. Project managers should take every opportunity to let team members know they can bring up
issues and ask for help. By identifying problems early, the project can stay on track and save time and money.
Quality Management Outcomes: A Summary

Good quality management creates the opportunity to deliver a product with few or no defects, and that is fit for the purpose
as defined by documented definitions of done and acceptance criteria. Product delivery and project closure should be in
line with the approved schedule and budget, and at the agreed levels of quality. The product should meet the organizations
and customer s business goals and objectives for which the project was chartered.
Quality management, in concert with stakeholder engagement efforts, should result in customer satisfaction, and
successful and improved procurements (through good supply chain integration practices). Through teamwork and servant
leadership the team and organization should benefit from continually improved processes, decision-making capabilities,
and productivity. Project team satisfaction and motivation should be maintained or enhanced.
Understanding the Tools and Techniques Used in Quality Management

As you have read through this chapter, have you found yourself asking questions like, “Now, when are all these tools and
techniques used?” or “What are the differences between the three parts of the quality management process again?” People
tend to struggle with these concepts. The following exercise will help.
10.1 Exercise
Take time to research in this book the different methods that are created or used in each of the quality management
processes. Then, in your Exercise Notebook, identify whether the following tools are used in planning, managing,
and/or controlling quality. Remember that some tools and techniques are used in more than one quality
management process. Think about the ways they are used for different purposes in each process.
1. Affinity diagrams 16. Interviews

2. Alternatives analysis 17. Logical data model
3. Benchmarking 18. Matrix diagrams
4. Brainstorming 19. Meetings
5. Cause-and-effect diagrams 20. Mind mapping
6. Checklists 21. Multicriteria decision analysis
7. Checksheets 22. Performance reviews
8. Control charts 23. Problem-solving
9. Cost of quality 24. Process analysis
10. Cost-benefit analysis 25. Questionnaires and surveys
11. Design for X 26. Root cause analysis
12. Document analysis 27. Scatter diagrams
13. Flowcharts 28. Statistical sampling
14. Histograms 29. Test and inspection planning
15. Inspection 30. Testing/product evaluations
270
Answer
Used in Plan Quality Used in Used in

Tool Management Manage Quality Control Quality
1. Affinity diagrams X
2. Alternatives analysis X
3. Benchmarking X
4. Brainstorming X
5. Cause-and-effect diagrams X X
6. Checklists X X
7. Checksheets X
8. Control charts X
9. Cost of quality X
10. Cost-benefit analysis X
11. Design for X X
12. Document analysis X
13. Flowcharts X X
14. Histograms X X
15. Inspection X
16. Interviews X
17. Logical data model X
18. Matrix diagrams X X
19. Meetings X X
20. Mind mapping X
21. Multicriteria decision analysis X X
22. Performance reviews X
23. Problem-solving X
24. Process analysis X
25. Questionnaires and surveys X
26. Root cause analysis X X
27. Scatter diagrams X X
28. Statistical sampling X
29. Test and inspection planning X
30. Testing/product evaluations X

Do you think you understand quality management now? The following exercise will help you review the information you
have learned.
10.2 Exercise
Using our library example, match the work described with the Quality Management process (processes may be
used more than once).
1. Plan Quality Management
2. Manage Quality
3. Control Quality
Work
A. Ask the city council for their expectations about the quality levels of the
library furniture.
B. Coordinate the date and time for the planned city inspection of the foundation.
C. Discuss the one inspection failure with the construction foreman.
D. Ask IT director to report the number of defects found during software testing.
E. Create a change request to the design after a problem is discovered.
F. When choosing a moving company to pack and move the existing books, ask for
insurance claims on their last three moves.
G. Hire a cybersecurity audit for the patron login functionality.
Answer
A. 1
B. 2
C. 3
D. 2
E. 3
F. 1
G. 2
272
QUICKTEST
11 Communications • Communications
Management process
• Meeting management
• Project Reporting
- Status report
- Progress report
- Trend report
- Forecasting report
Introduction - Variance report
- Earned value report
Have you ever sent a message you were certain was very clear but then you got a lot of questions about
- Progress metrics
it after it was received, or you learned later that it was misunderstood? What about times when you’ve
- Retrospective findings
left a voicemail or an email for a particular person only to find out later it would have been received
- Lessons learned
much more quickly if you had texted the person instead? What are your communication preferences? • Knowledge sharing
Maybe you’ve recently received a voicemail in the office when you are now used to checking only your • Information radiators
mobile phone.
When you think about it, communication is involved in almost everything you do as a project
manager. There are so many technologies and methods to choose from, and so many variations in ways
to interpret a given message that issues with communications are inevitable. From sheer volume alone
it is no surprise that project managers identify communication-related issues as the number-one
problem experienced most frequently on projects.
Communications Management Overview

The project manager must plan, manage, and control communications carefully so the best technolo
gies and methods are chosen for a given audience. Then, the project manager has to craft each message
carefully for clarity and the optimal amount and types of detail. Here are just a few examples of factors
affecting project communications:
• Projects often involve virtual teams, requiring complex communication tactics and strategies.
• The rapid rate of change on projects necessitates continually revisiting communication tactics
and strategies, and past communications.
• Stakeholder communication preferences lead to a need to choose communication tactics and
strategies carefully.
Planning and managing communications may also include:

• Assessing stakeholder communication needs (part of stakeholder identification and analysis)
• Determining what methods will be best for the project
• Understanding what communication channels are available
• Deciding on the frequency and level of detail of particular types of project communications
• Ensuring appropriate methods for effective feedback loops are provided and understood
• Considering the richness of available communication channels in choosing communication
technologies and methods
• Revisiting decisions regarding the selected communication tactics and strategies to ensure they
remain effective throughout the project
On the exam, communications questions are frequently combined with other topics. Stakeholder
engagement is an obvious content area that feeds into decisions needed to create well-planned
communication plans and to carry them out. All other knowledge areas are affected as well.
Examples Tools related to scope management—WBS, story backlog, or release—are also used
to communicate with stakeholders.
275
Communications ELEVEN

Hie following table illustrates that the ECO combines communications management activities into a single task called
Manage Communications, while the Process Groups model has communications management activities broken into three
main processes mapped to the planning, executing, and monitoring and controlling process groups.

Domain II Communications Management Domain 2.1
Stakeholder
Task 2 Plan Communications Management — Planning Domain 2.2
Manage communications
Manage Communications — Executing Team
Domain 2.4
Monitor Communications — Monitoring
& Controlling Planning
Domain 2.5
Project work
Domain 2.8
Uncertainty
Think about it. In addition to “Manage communications” from the ECO, many other ECO tasks are connected
to communications management. Review the below tasks in the ECO and think about how they are all holistically
involved in managing communications, and how they in turn depend on communications management. The
following examples are not all-inclusive.
We mapped the Process domain tasks here more directly to project integration management to give you an opportunity
to review these again. As a project manager, integration of everything happening on a project is one of your
primary responsibilities.
Examples
People (Domain I) Process (Domain II)

All People domain tasks are critical to • Execute project with urgency to deliver business value (task 1)
effective project communications. The • Engage stakeholders (task 4)
reverse is true as well: Effective project • Integrate project planning activities (task 9)
communications are integral to success
• Establish project governance structure (task 14)
in all People domain tasks.
274
ELEVEN Communications
Now take some time to review the communications management process according to the Process Groups model.
The Process Groups model perspective gives you an overview of the general process, which can guide you through the rest
of the chapter.

KA: Communications Management
Key
Continuous change control is
' ' consistent with all approaches
Change prompts a process to be
C reiterated through progressive

elaboration or agile methods
-> Changes that cause a return to

Initiating are rare
Monitor
Communicat
FIGURE 11.1 Communications management process
Before delving into the more technical project management aspects of communication management, you may want
to skim through the Communication Skills section of the “Leadership Skills” chapter. Keep this and all the People domain
tasks in mind as you study this chapter.
Desired Outcomes from Successful Communication Management

Assume for the exam that project communications are properly planned and managed unless information in an exam
question indicates otherwise. This means that the following outcomes should be expected as a result of
communication management:
• Communications are planned and executed so that the right information gets to the appropriate stakeholders using
the appropriate technologies, is clear and understandable, and arrives to stakeholders at the right times and in the
appropriate formats.
• The project manager solicits feedback from receivers of communications to ensure a common understanding of all
information conveyed as well as the need, if any, for follow-up actions.
• Communication strategies and tactics are measured and analyzed on a regular basis and appropriate changes are made
as situations or communications needs on the project changes.
• The project communication management strategies and tactics contribute to stakeholder satisfaction because
stakeholders understand what communications to expect and when. They also are confident that they will receive
communications appropriate to their needs on the project.
275
Communications Planning
Planning is about considering the projects overall communications approach for Process Groups Model
the project, and about how the project manager will sort out the fine detail. The plan PG: Planning
should identify what systems and processes are already in place to support commu Process: Plan Communications
nications, as well as what processes and documents must be created. This effort in
cludes planning what information will be communicated to whom, when, using ECO
what methods, and how frequently. The plan will guide the project manager and the Domain II
team in managing and monitoring communications to ensure information is getting Task 2 Manage communications
to where it is needed, is clear and understandable, and allows stakeholders to act as

PMBOK® Guide
necessary. Finally, it should have the flexibility to change as the project progresses
Domain 2.1 Stakeholder
and the information and stakeholders’ needs change.
Domain 2.2 Team
To plan communications, the project manager will refer to the project charter
Domain 2.4 Planning
and other artifacts like requirements documentation, the stakeholder register, and
the stakeholder engagement and resource management plans. The communications Domain 2.8 Uncertainty
plan should explain how project communications will support related areas.
On your projects, do you take the time to ask stakeholders about their communications requirements?
Communications requirements need to be analyzed to determine how they can be met and to make sure that meeting
them will add value to the project and will be worth the effort and cost involved.
Project size, life cycle, and development approach are all factors for consideration in communications planning. The
project manager needs to be equally comfortable with planning communications for projects large and small, using
predictive, adaptive, or hybrid approaches. A large project may have a team of over 100 people in different countries,
speaking different languages, with diverse approaches to communication, possibly influenced by culture. A small project
may be accomplished entirely from one location or may have simpler communication needs. In other words,
communications efforts must be tailored to the project.
In hybrid environments, for example, project leaders communicate some project information through
both predictive and agile methods. Leaders of agile teams in hybrid environments must often update weekly
status reports, Gantt charts, and earned value reports in addition to tracking agile metrics like velocity and
burnup and burndown information.
Think About It. Communication management is important on the exam. Think about everything you have
read so far in this chapter as you look at the following list. Do you do the following?
• Use multiple methods of communicating. • Plan how you will confirm communication is
• Ask people what information they need received and understood.
and when. • Cater to the need for communication to go in
• Tailor communication practices to project multiple directions, at all levels, internal and
size, complexity, life cycle, and approach. external to the organization.
• Plan communications for each stakeholder or • Analyze how location, culture, security,
group based on individual needs and interests. privacy, and language impact communications.
• Have a system for storing, maintaining, and
retrieving project information.
276
11.1 Exercise
Test yourself! Write down in your Exercise Notebook what information needs to be communicated on a project.
Answer
Some possible answers are:
Project charter • Status

Stakeholder contact information • Uncertainties (esp. new risks uncovered)
Types of emails to be sent to each • Problems
stakeholder or group • Successes
Artifacts (plans, release maps, user stories, • Project and product scope changes
backlogs, WBS, network diagram) • Information about when management
Dependencies reviews will be done
Impacts to and from other projects • Updates when plans are changed
When resources will be needed • Change request results
Team norms • Upcoming work (e.g., scheduled WBS
Working agreements components or iteration backlogs)
Definition of done • Delays
Bum charts • Date of next milestone completion
Information radiators • Performance reports
Meeting schedule • Retrospective results; lessons learned
Work assignments • Issue logs
• Configuration management issues
Communications Requirements
Understanding and fulfilling communications requirements helps the project manager maintain stakeholder engagement
by ensuring that communication needs are met. More information about requirements analysis is in the “Scope” chapter.
Use the following information to determine and analyze communication requirements:
• Stakeholder register • Locations of stakeholders
• Stakeholder personas • Number of communication channels
• Stakeholder engagement plan
Artifacts of Communications Planning

As a result of planning communications, the project manager should have a documented description of the communications
needs of stakeholders and a strategy to meet them. Plan components may include:
• What communications to prepare and disseminate • Who has responsibility for sending and receiving
among stakeholders which communications
• How information should be named and stored • Tailored approaches to language and culture
• Who has access to what communications • Tailored approaches to level of detail needed
• Who has the ability to edit what • Information on how communication effectiveness
will be evaluated
277
Because communications are complex, a communications management plan should be in writing for most projects.
Figure 11.2 shows some of the considerations for what you might include in a communications plan.
What Needs to Be Best Method for Responsibility When and

Communicated Why Between Whom Communicating for Sending How Often
FIGURE 11.2 Sample portion of a communications management plan
Managing Effective Communications

During planning, the communications needs of stakeholders are determined and Process Groups Model
documented. Throughout the project, the project manager and team satisfy these PG: Executing
needs through meetings and other in-person communication, as well as through Process: Manage Communications
other communications such as reports, graphics, information radiators, and emails.
ECO
Almost nothing on the project gets done without communicating, so it’s
important that information is flowing back and forth on the project in accordance Domain II
Task 2 Manage communications
with the planned strategy. Communicating effectively is about facilitation and
practicing flexible approaches in dynamic environments. It also includes providing PMBOK* Guide
opportunities for stakeholders to request additional information and clarification.
Domain 2.2 Team

TRICKSWhile reports and other formal written communications are important
OF THEaspects of the project’s historical records, they should not require a Domain 2.5 Project work
TRADE great deal of a project leader’s or team’s time. Domain 2.8 Uncertainty
Often communications are tailored to the audience. In hybrid environments,

a project leader might discuss “points,” "Planning Poker",” “velocity,” and “blockers” with the team, and then
use more traditional terminology like “completed work,” “progress," “estimates,” and “threats” with a more
plan-driven-focused steering committee.
Example With the team, a project leader might say, “I have a stakeholder meeting. I’ll be showing our burndown
rates by iteration.” With the steering committee, they might say, “These are our average feature completion rates as measured
every two weeks.”
It is vital to use the interactive communication model (as shown in figure 5.3 in the “Leadership Skills” chapter) and
appropriate methods and technology planned for the project so everyone knows what to do with the information they
need to convey. The communications management plan, project documents, work performance reports, and everyday
interactions will give the project manager the data and information about what needs to be communicated. Whether it's
information from recent risk reviews, forecasts on project performance, or details about changes that have gone through a
formal integrated change control process, the project leader and team need to follow the communications management plan.
Tailoring is also often needed in response to stakeholder feedback, the culture of the organization (which is always
evolving), and other factors.
Methods for Communication

Communication methods were discussed in the “Leadership Skills” chapter. A large range of communication and
interpersonal and team skills also helps the project manager manage communication choices. These may include but are
not limited to active listening, conflict management, cultural awareness, meetings management, networking, and political
awareness. Developing and delivering presentations and reports are also important competencies, as is tailoring
communications to the audience at a given time on the project.
278
Meeting Management
Meetings are often key elements of the effort to manage communications. We have already said that the project manager
and the team need to decide during planning how information will be shared on the project. Meetings provide a way to
communicate with the team and stakeholders. Having a strategy for meetings is essential to making time spent in meetings
efficient and effective. This includes sticking to the planned strategy for how meetings will be conducted, who needs to
attend, and when they are most appropriate.
Effective meetings may seem easy to plan but they are not easy to conduct consistently. Consider the following
meeting rules:
• Meet regularly as appropriate • Remind attendees of their meeting responsibilities
• Bring the right people together as appropriate
• Schedule recurring meetings in advance • Make all participants responsible to enforce rules
• Have a purpose for each meeting (not just the facilitator)
• Assign deliverables and time limits for assignments
• Cancel an instance of a recurring meeting if it
that result from meetings
is unnecessary
• Set time limits and keep to them • Document and publish meeting minutes,
as appropriate
• Have an agenda and stick to it
• Adhere to inherent rules for particular types of
• Distribute the agenda beforehand
meetings (e.g., daily standups)
• Chair and lead meetings with a set of rules
Hybrid environments may present short-term challenges in relation to meetings. An agile team’s “less
formal” practices may make traditional stakeholders uncomfortable at first. A way to resolve this is to have
stakeholders observe the agile team’s daily standup meeting. This is a great way to learn about team dynamics
and current work activities. And since these meetings are normally held in the team’s work area, there are
likely to be information radiators on the walls to help inform stakeholders.
People unfamiliar with agile worry that reporting is too informal for traditional stakeholders. The fact is, in
TRICKSagile the same things are being tracked even though effort is counted in story points rather than hours or days.
OF THE
TRADE* On a weekly basis the team may be concerned only with the current iterations story points, but over time
this data can easily be turned into an earned value measurement (EVM) report (see figure 11.3).
USD 75,000
co
c
CL
USD 45,000 UD
CD
USD 30,000
USD 15,000
Planned value (Pv) Planned cost/spend Scope built Actual cost/spending
_ Completed features Earned value
Planned features Actual cost
FIGURE 11.3 Agile earned value measurement (EVM)

279
Standup Meetings Standup meetings may be used to learn about progress, opportunities, threats, and issues. They may
also be used to share information between team members and other stakeholders.
Iteration Reviews These are meetings with the specific purpose of the team giving a demo to the customer of newly
developed scope, and either getting acceptance and sign-off on that scope increment or gathering the feedback needed to
do so at a later time.
Retrospective Findings These may also be included on an information radiator. In hybrid environments retrospective
findings can serve as ongoing lessons learned. Then, the requisite lessons learned reports at the end of a project are
constructed from them, contributing to organizational process assets.
Project Reporting
Project reporting involves communicating to stakeholders about how the project is going and how it is projected to go in
the future. Much of that information comes from work performance reports. It also involves asking for feedback from
stakeholders to ensure they have received the information they need and have understood it, and to determine whether
they need more. Outside of daily interactions, meetings, and information radiators, this communication may take the form
of written reports, presentations, and intranet updates as outlined in the communications management plan.
Make sure you remember the following about reports. They should:
• Be designed to fit the needs of the project.
• Provide information and at the level of detail required by stakeholders.
• Include measurements against the performance measurement baseline set for the project, phase, or iteration (for
scope, schedule, cost, and quality).
• Use the most appropriate communication method when sending information.
• Be truthful. This should go without saying but because it is not always the case, there may be exam questions about
reports connected to professional and social responsibility.
• Help team members know when to recommend and implement corrective actions.
In addition, feedback from stakeholders (who receive reports as part of this process) should be analyzed to allow for
tailoring of future communications to continue to or better meet stakeholder needs. A project manager might issue the
following types of reports:
• Status report Describes project performance compared to the performance measurement baseline.
• Progress report Describes what has been accomplished.
• Trend report Examines results over time for performance improvement or decline.
• Forecasting report Predicts future project status and performance.
• Variance report Compares actual results to performance measurement baselines.
• Earned value report Integrates scope, cost, and schedule measurements to assess project performance relative to
baselines and variances.
• Progress metrics Reports such as Cumulative Flow Diagrams and burnup charts are used to assess performance.
• Retrospective findings Used to inspect, adapt, and improve project and team performance.
• Lessons learned Summaries of lessons learned that may be used immediately on the project or used for
future projects.
Knowledge Sharing
Any of the reports listed previously can be used on projects to share information. Discussing this information and what it
means in order to help each other improve individual and project performance is knowledge sharing. This is a key
component of successful project management communications. Information is a basic element of any project so it must be
distributed and shared. Have you managed a project for which the team reported they didn’t have all the necessary
information, or they didn’t know how to use the information they had received?
280
Example Let’s say a team member was unable to complete a task or activity because of missing information or
knowledge. This was due to a team member’s vacation that was not communicated to the whole team. How would that
impact the project? What could have been done differently to avoid such an issue? If the project team properly shared
information and knowledge, that team member would not have trouble completing their work.
Agile projects embrace knowledge sharing using a variety of tools:
• Daily standup meetings • Product demos
• Kanban boards • Information radiators
• Personas • Wireframes (a type of low
• Release and iteration planning fidelity prototyping)
• Retrospectives
Similarly, agile emphasizes collaborative planning, estimating, and retrospectives. This allows the project team to
collectively gather and share project knowledge.
Information Radiators Story Ready Task In Process Task Done Story Done
Task Ready
A Kanban board (see figure 11.4) is a
method for limiting work in progress User User
TaSk T 1/ M Task
StoryJ StoryJ
(WIP), and it is an information radiator Task Task
showing WIP. A Kanban board is a great T3Sk Task

Task Task
Task _ Task
i r __ ” r r
way to track workflow, project progress,
User Task
and to illustrate WIP. Stay Task Task
Task Task Issue
Informal meetings often take place Task
in front of these task boards. Seeing the __ -T
finished work piling up to the right of the
board also provides inspiration for
Figure 11.4 Kanban board
stakeholders and team members alike.
The types of information shown via information radiators may include large charts, graphs, data summaries—or even
a computer screen showing continuous integration results on software projects. Displayed in high-traffic areas, they allow
anyone to see the project progress at any time.
Information displayed using information radiators may include:
• Features delivered to date and features remaining • Who is working on what
to deliver • Velocity metrics
• Features for the current iteration • Defect metrics
• List of issues, threats and opportunities (risks) • Story maps
• Bum charts
Artifacts of Manage Communications

Reports, information radiators, and the individual communications are the artifacts of project communications, usually
kept in writing in the PMIS. Handmade information radiators are often photographed before they are changed in a
significant way. For example, a drawing on a whiteboard may be recorded this way before it is erased and redrawn using new
options. Here are some of the more formal artifacts that are updated on a regular basis:
• Project communications
• Communications management plan
• Stakeholder management plan updates
• Project document updates
Issue log
Lessons learned
Risk register
y Stakeholder register
• Organizational process assets
28
Monitor Communication Effectiveness

Of course, as the project manager is managing (or carrying out) effective communi Process Groups Model
cation on the project, they are at the same time monitoring it to ensure its continued PG: Monitoring and Controlling
efficacy. The project leader should assess and ensure that information is flowing as Process: Monitor Communications
planned—in the right way, to the right people, and at the right time. This effectively
keeps stakeholders and the team informed and maintains the desired levels of stake ECO
holder engagement. The previous section listed types of data and reports with the Domain II
assumption you know what and how to collect data and transform it into informa Task 2 Manage communications
tion.
PMBOK* Guide
If you’re not familiar with data collection and evaluation techniques, think
about how you would use them and how they may differ on different types of
Domain 2.2 Team
projects. This process involves:
Domain 2.5 Project work
• Observing to determine whether the communications management plan is
being followed
• Confirming communications and feedback are understood
• Ensuring that communications are meeting the needs of the stakeholders
• Identifying where communication is breaking down (if needed)
• Adjusting as necessary to meet stakeholder and team needs
How can the project manager tell if communication is breaking down? In addition to the established metrics, they
rely on interpersonal and leadership skills. Some issues may be clearer than others. Project stakeholders may let the project
manager know, for example, if they’re not getting the reports or information they’re meant to receive. Or the project
manager will be informed if the project team isn’t following up on action items established through earlier communications.
Also, project team members should report any communication problems they experience and help to identify ways
communications can be improved on the project. These are the reasons it’s important to encourage all stakeholders to let
the project manager know whether the project communications are meeting their needs. Do you do this on your projects?

Communications is more than technology; it also involves the interpersonal and team skills every project manager needs
to be a successful leader. Make sure you understand the various communication methods and what is in a communications
management plan.
Important concepts can be found on the Quicktest at the beginning of the chapter. Use it to find any gaps in your
knowledge. Review the chapter again to fill those gaps, then complete the following exercise.
11.2 Exercise
Give examples of the communication challenges the project manager may have with each of the stakeholder or
stakeholder groups from our library case study. Suggest ideas for good communication plans.
Stakeholder or What will be the communication How will the PM best communicate with this
group challenges with this stakeholder? stakeholder?
Mayor
City Council
Patrons
Librarian
Construction team
282
Answer
Here are some sample answers. You may have come up with some other ideas.
Stakeholder or What will be the communication How will the PM best communicate with this
group challenges with this stakeholder? stakeholder?
Mayor Mayor is busy and has many other Since the mayor is probably busy, the project
issues to manage. manager will want to get to know the mayor’s
assistant and ask for the best ways to communicate.
City Council Some council members are always up The project manager should communicate the
for re-election and may be using the same messages to all council members.
library as an issue.
Patrons Large group, little direct contact. Public notices in newspapers and magazines.
Surveys.
Librarian The librarian may be comfortable with Keep the librarian engaged in all decisions.
the current library and resist change.
Construction team Managed by another company so the Work with the construction company management
project manager does not have direct to communicate information to the workers.
authority
285
28^1
QUICKTEST
12 Risks and Issues • Definition of risk

management
• Watch list
• Risk owner
• Threats and opportunities
• Risk factors
• Risk appetite
• Risk threshold
Introduction
• Spike
The impact of risk management is integral to a project manager’s daily work and the exam will test your • Architectural spike
• Fast failure
knowledge of risk management at a sophisticated level. For example, you may be given a situation and,
• Risk Management
based on the information provided, need to determine which risk management process is being per
process
formed or what should be done next.
• Risk categories
Before we look at the risk management process in detail, let’s start with a story. An RMC student • Agile project pre-mortems
was a project manager on a hardware and software installation project in an area where hurricanes are • Risk data quality
a relatively frequent occurrence. Then a hurricane struck. Not long after the hurricane was over, the assessment
project manager told people what a great job his team had done and how quickly they had recovered • Risk categorization
• Probability and impact
from the disaster.
matrix
• Risk parameters
Think About It. Would you have been proud of yourself if you were the project manager? As
assessment
you answer, consider the following information:
• Simulations
• The activity the team was working on required three days to complete. • Sensitivity analysis
• The project manager had warning that the hurricane was coming. • Expected monetary value
(EMV)
• They had to recover from the disaster. • Decision tree analysis
• Risk response strategies
Instead of being excited about how quickly his team was able to recover from the hurricane, the - Avoid
project manager—and the sponsor—should have questioned the wisdom of scheduling the - Mitigate
implementation at a time when there was a strong probability of a hurricane. Or, if the scheduling had - Transfer
already been completed, they should have questioned the wisdom of keeping to that schedule. This is - Exploit
the value of risk management. When a hurricane was forecast the team could have responded according - Share
to a plan, such as moving the implementation to another weekend to avoid the danger, damage, and - Enhance
- Accept
rework that was likely to result.
- Escalate
A project manager’s work should focus on preventing problems rather than on dealing with them. • Pure risk
Think about your own projects. How would it feel if you could say, “No problem; we anticipated this, • Secondary risk
and we have a plan in place that will resolve it whenever a problem occurs”? How much time and • Risk register
money would you save that would have otherwise been spent addressing the problem? How much less • Risk report
stress would you have in your life? • Risk-adjusted backlog
• Set-based design
Projects inherently include uncertainty, volatility, complexity, and ambiguity (discussed in the
• Workarounds
Uncertainty Domain in the PMBOKS Guide). Project risk management helps prevent many threats (or
• Risk reassessments
negative risks) and make others less likely or less impactful. And it helps to increase the probability • Risk reviews and audits
and/or impact of opportunities (positive risks). When the project manager eliminates threats and • Reserve analysis
increases opportunities, schedule and cost estimates can be decreased. With that in mind, we’ll look at • Technical performance
some of the basic risk management concepts. analysis
• Risk burndown chart
Definitions Related to Risk Management
Here is some basic vocabulary that will be used in this chapter.
Project Risk
A probable event that, if it occurs, will negatively or positively affect one or more project constraints.
A risk can affect the project team’s ability deliver the value for which the project was chartered and
meet the agreed-upon budget, schedule, and quality requirements.
285
Risks and Issues TWELVE
Project Risk Management

This is the process of identifying, evaluating, and planning responses to uncertain events that might occur during the
course of a project. The project manager identifies risks and begins to manage them in initiating and planning. While the
project is underway the project manager and the team frequently look at what uncertain events have happened or may
soon happen, and reassess the planned risk strategy.
Watch List
This is a list of risks that currently do not warrant planned risks responses, but it is understood that any of these risks
could become more probable and need a planned response.
Risk Owner
An individual who watches out for the occurrence of an assigned risk and leads the implementation of
preplanned responses.
Threats and Opportunities

A risk event can have positive or negative impacts on the project if it happens. We often focus on threats, which are things
that can go wrong. But there can also be opportunities on projects—positive impacts that may allow the project manager
and team to deliver even more value to the organization and customer than planned.
Opportunities can include such things as:
• If we can combine orders for the ZYX equipment, buy more than 20 items at once, we could decrease the cost by
20 percent.
• If we can train the team to improve efficiency, then work package number 3.4 (and possibly others) could be completed
two days faster than expected.
• If we can obtain a more experienced resource with a higher level of productivity, then the critical path activity 4.7.2
could be done 10 percent faster.
Projects have the potential for many opportunities, and the vast majority of identified threats can be mitigated or
eliminated by changing how the work is planned and performed. There are strategies that may reduce threats and even
create opportunities; for example, careful resource optimization, using the most experienced people possible and providing
training as needed.
Even though threats are what we often think about when we hear the word “risk,” for the exam remember there
TRICKS
OF THEis as much likelihood that you’ll see questions related to opportunities. The iterative nature of project
TRADE-management methods also requires a continuous attention to updating the risk management plan. Risk
identification and planning is ongoing throughout a project.
Think About It. The concept of risk is so closely related to value that we can think of negative project risks
(threats) as “anti-value”—factors that have the potential to erode, remove, or reduce value if they occur. Think of
the value you create with your project as money you bring into the household budget. You plan to accrue value
in the budget with work effort (resulting in paychecks). Threats that actually occur like an unexpected expense
remove money from the budget so it now has less value. An unexpected bonus, however, can potentially increase
the value of the budget. To create the most value, you maximize monetary flow into the budget (opportunities)
and minimize unexpected outflow (threats).
Risk Factors
When assessing risk, the project manager needs to determine the:
• Probability that a risk event will occur (how likely)
• Range of possible outcomes (impact or amount at stake)
• Expected timing for it to occur in the project life cycle (when)
• Anticipated frequency of risk events from that source (how often)
286
TWELVE Risks and Issues
Risk Appetites and Thresholds

These terms refer to the level of risk an individual or group is willing to accept.
• Risk appetite Also referred to as risk tolerance, this is a general description of the level of risk acceptable to an
individual or an organization.
Example A sponsor may be willing to accept little risk to the schedule on a project. This may (and should) make
the sponsor more flexible with cost since adding resources can compress the schedule (this is known as “crashing”).
• Risk threshold This refers to the specific point at which risk becomes unacceptable.
Example The sponsor will not accept the risk of a schedule delay of 15 days or longer.
• Risk averse This term describes an individual or organization with a very low appetite for the negative impact
of threats.
Risk appetites and thresholds vary and can include any project constraint (scope, schedule, cost, etc.), as well as risks
to reputation, customer satisfaction, and other intangibles depending on the individual or organization.
Example An organization may have more tolerance for cost-related risks than for risks that affect customer satisfaction
or their reputation in the marketplace.
When answering exam questions related to risk response strategies, look for information about individual and
organizational risk appetites and thresholds.
Risk Definitions Specific to Agile

Adaptive environments are well-suited for projects with a lot of uncertainty, especially where evolving scope
is concerned. You will see as we discuss the Process Groups model for risk management that agile projects
can make use of this predictive-based model to a large extent, since all risk management should be done
repeatedly throughout any project.
Let’s start with the reminder that every well-planned agile backlog is a risk-adjusted backlog. Then, because agile
projects are iterative, teams go through risk identification and analysis, and threat mitigation or elimination for each
iteration. Additionally, agile continuous improvement practices always include looking for opportunities to deliver as
much value as possible. Risks are identified in daily standup meetings as team members report any potential impediments
to their progress.
Agile teams often explore big risks like new processes or technology using special iterations called spikes. A spike is
basically a short iteration dedicated to exploring an issue or an approach. A risk-based spike is done before an associated
increments development begins to attempt risk mitigation or elimination—or, enhancement, if an opportunity is
being explored.
Example As part of the new library, the staffs stored digital files are being migrated from a shared local area network
drive to a cloud environment. The biggest risk here, of course, is the loss of files. So the agile team would schedule a risk
spike to test that the migration will not result in a loss of files. By doing this testing up front, they will uncover issues and
greatly reduce risk by eliminating discoverable issues.
Architectural spike
You may also see this term on the exam. This spike is for proof-of-concept efforts. In our previous example of migrating
files, an architectural spike may be completed prior to any risk-based spikes. During the architectural spike, the team
might install new technology or run through how the processes work with the new technology to ensure everything works
as planned.
287
Fast Failure
Spikes can induce “fast failure,” and this is
actually desirable. The earlier failure occurs the
quicker resources can be diverted to a different
strategy on a project, or even to a different
project. The team is basically trying to cause the
failure if they think there is probability of it
happening anyway. Assuming they can fix the
problem, the cost of the failure may be reduced
if it is fixed early in the project. Figure 12.1
illustrates how fast failure can benefit a project.
Failure gets costlier with time as the built product increases in complexity,
resources are increasingly used; the cost of change is greater
Figure 12.1 Fast failure
Risk Management Overview

As we have in other chapters, we will help you understand the overall Risk Management process by using the Process
Groups model, as well as include information about risk management methods that are unique to adaptive environments.
First let’s take a look at how the Risk Management process in the Examination Content Outline (ECO) maps to the same
process in the Process Groups model.

Think About It. In the ECO, domain II, task 3—assess and manage risks—is closely related to the risk
management process as defined in the Process Groups model. Other tasks that closely align to managing risk
include but are not limited:
• Domain I (People domain), task 7: Address and remove impediments, obstacles, and blockers for the team
• Domain II (Process domain), task 15: Manage project issues

Domain 1 Risk Management Domain 2.7
Task 7 Measurement
Address and remove impediments, Plan Risk Management —
Domain 2.8
obstacles, and blockers for the team
Identify Risks Uncertainty
Domain II Perform Qualitative Risk Analysis Planning

Task 3
Assess and manage risks Perform Quantitative Risk Analysis
Task 15 Plan Risk Responses —

Manage project issues
Implement Risk Responses — Executing
Monitor Risks — Monitoring

& Controlling
288
Take time to review the ECO and note any additional tasks that may be applicable.
Example
• Risk management may rely on work to Ensure knowledge transfer for project continuity (domain II, task 16).
• If there’s conflict on your project, isn’t it a risk to leave it unresolved? The following are also related to risk management:
Manage conflict (domain I, task 1)
\/ Ensure team members/stakeholders are adequately trained (domain I, task 5)
What other tasks can you recognize as possibly impacting risk? Taking time to think about this now will help you
become more familiar with the ECO and be more prepared for the exam.
The Process Groups model for risk has many parts to it and students love to have an acronym when there are
TRICKSmany parts to remember. You can remember the following Process Groups model for risk with the acronym
OF THE
TRADE-“PIP P PIM” (Plan-Identify-Perform-Perform-Plan-Implement-Monitor). Or, if you like: “PIQQRIM”
(Plan-Identify-Qualitative-Quantitative-Responses-Implement-Monitor).
Figure 12.2 is a visualization of risk management at a high level from the Process Groups model perspective. It can
help you visualize where you are in the risk management process as you continue with this chapter, and understanding it
will help you on the exam.

KA: Risk Management
Key
7 is consistent with all
approaches
or agile methods

FIGURE 12.2 Risk management process
289
Desired Outcomes of Risk Management

For the exam, assume that risk management has been properly planned according to the concepts presented in this
chapter unless a question indicates otherwise. This means the following are built into risk planning, and subsequent risk
monitoring and risk response implementation:
• Internal and external environmental factors affecting project risks are considered.
• Risk and responses address the inherent uncertainty and complexity on projects.
• Risk related to all possible variables and constraints are accounted for along with their interdependencies.
• There are no huge “fires” to put out every day—they are eliminated with risk response plans.
• Risks are reviewed in every meeting, triggers are monitored, and risks are addressed before they happen.
• Normally, if a risk event does occur, there is a plan in place to deal with it. Hectic meetings to develop responses are a
rarity and are only needed when an unknown (i.e., unpredictable) risk event occurs and requires the team to develop
a workaround.
• Risk management helps to limit cost, time, and resource investments on the project.
• There are reserves set aside in the budget for risk events.
Risk Management Summary

Remember that the Process Groups model describes how and in what order risk management generally occurs
TRICKS
OF THE but project management is iterative and dynamic. Initiating is repeated on large-scale projects when a phase
TRADE gate system is used. And, of course, on an agile or hybrid project, risk management is considered every time
the backlog is prioritized for a new iteration, when estimates are created, during release and iteration planning,
during iteration reviews and retrospectives.
Plan Risk Management

The project manager, sponsor, team, customer, other stakeholders, and ex Process Groups Model
perts may be involved in planning risk management. Part of planning involves PG: Planning
determining, at a high level, the amount and areas of potential risk on the proj Process: Plan Risk Management
ect. Risk checklists from previous projects can be helpful in planning and
identifying risks, but risk management is tailored to every project. In practice, ECO
risk management efforts will differ depending on the size and complexity of Domain I
the project and the experience and skill of the project team. Even how much Task 7 Address & remove impediments for team
time is spent on risk management is based on the needs of the project. Domain II
Task 3 Assess & manage risks
The project manager and team evaluate the risk appetites of management
Task 15 Manage project issues
and other key stakeholders and identify how the team will go about
performing risk management and who will be involved. Organizational PMBOK® Guide
process assets like documented procedures and templates related to risk, such Domain 2.4 Planning
as standard probability and impact matrices, are identified and adapted. Domain 2.8 Uncertainty
When risk management planning is complete, the risk management plan
may include the following:
• Risk strategy This is an overall approach to managing risk throughout the life of the project.
• Methodology This defines how risk management will be performed to meet the needs of the specific project.
Low-priority or low-risk projects will likely warrant less of a risk management effort than high-priority or high-
risk projects.
• Roles and responsibilities This section of the risk management plan explains who will do what risk management
work. Did you realize that the project manager does not do it all and that stakeholders outside the project team may
have roles and responsibilities regarding risk management?
• Funding There is a cost of doing risk management, but overall risk management saves the project time and money
by avoiding or reducing threats and by taking advantage of opportunities. This section includes a plan for utilizing
reserves in response to risks on the project.
290
• Timing This section specifies when to do risk management depending on estimated timing for the occurrence of
identified risks. Also note that time needs to be allocated in the schedule for risk management activities.
• Risk categories These are discussed next in the Identify Risks section.
• Stakeholder risk appetite/thresholds The risk appetites and thresholds of key stakeholders are documented and
considered in the risk management plan. This information is also considered when ranking risks based on probability
and impacts, and when prioritizing which risks will be addressed in risk response planning.
• Definitions of probability and impact Would everyone who rates the probability of a particular risk a 7 on a
1 -to-10 scale in qualitative risk analysis mean the same thing? A person who is risk averse might think of 7 as very high,
while someone who is risk prone might think of 7 as a low figure. The definitions and the probability and impact
matrix (discussed later in this chapter) help standardize these interpretations and also help compare risks
between projects.
• Reporting This section of the plan describes what risk-related reports will be created, what they will include, and to
whom they will be sent. In addition, the composition of the risk register for the project is defined here.
• Tracking The tracking section describes how the risk management process will be audited and how the results of risk
management efforts will be documented.
Identify Risks
In this process, risks to the project and their characteristics are identified. This Process Groups Model
effort should involve all stakeholders and might include literature reviews, re PG: Planning
search, and communicating with non-stakeholder subject matter experts. Process: Identify Risks
Sometimes the core team will begin the process and then other team mem
bers will become involved, or there could be a special, dedicated risk team—a ECO
part of the project team focused on risk management efforts. Domain I
Task 7 Address & remove impediments for team
When you get a question about who should be involved in risk
TRICKS Domain II
OF THE identification, the best answer is “everyone”! Each type of Task 3 Assess & manage risks
TRADE* stakeholder has a different perspective of the project and can Task 15 Manage project issues
provide thoughts on opportunities and threats.
PMBOK* Guide
Project managers should begin looking for risks as soon as they start on Domain 2.4 Planning
the project. In fact, an assessment of overall project risk is included in the Domain 2.8 Uncertainty
project charter. The project manager will need good facilitation skills for the
identification of as many risks as possible.
It is worth repeating that while risk identification primarily occurs
during planning, risks are identified throughout the project. For the exam, understand that in a predictive
environment risk identification is also done during integrated change control, when working with contracts,
when working with resources, and when dealing with project issues (which are small concerns that may
become problems or risks if not resolved). In an adaptive environment, risk identification takes place in
release planning, iteration planning, and throughout each iteration of building the product.
Risk Categories
A standard list of risk categories can help ensure areas of risk are not forgotten. Risk categories are broad, common areas
or sources of risk that similar projects or other people in the organization have encountered. They can include things like
technology changes, resource shortages, regulatory hurdles, changes within the internal or external environments, or
cultural issues.
Organizations and PMOs should maintain standard lists of risk categories that project managers can use as prompt
lists to help identify and categorize project risks. When leading risk identification efforts, the project manager should make
sure each category is considered.
A risk breakdown structure (RBS) is a hierarchical chart that looks like an organizational chart and can help the
project manager identify and document risk categories. The following breakdown of risk categories is by no means
comprehensive but will give you a good understanding of how risk categories work.
291
General Risk Categories

Research has shown over 300 potential categories of risk, including risks caused by:
• The customer
• Lack of project management effort (yes, a lack of project management effort adds risk)
• Lack of knowledge of project management by the project manager and stakeholders
• The customer s customers
• Suppliers
• Resistance to change
• Cultural differences
• External risks, such as regulatory, environmental, or governmental issues; market shifts; problems with project
sites, etc.
• Internal risks, such as changes to schedule or budget; scope changes; inexperienced team members; issues with
people, staffing, materials, and equipment, etc.
• Technological risks, such as changes in technology, technical processes, or interfaces, etc.
• Commerical risks, such as customer stability, terms and conditions within contracts, sellers, etc.
• Unforeseeable risks, which comprise only about 10 percent of risks
Risks Categories by Project Constraint

The following sources of risk are specific to project constraints. Each is followed by an example.
• Schedule “The hardware may arrive earlier than planned, allowing work package XYZ to start three days earlier.”
• Cost “Because the hardware may arrive later than planned, we may need to extend our lease on the staging area—at
a cost of $20,000.”
• Quality “The concrete may dry to our quality standards before winter weather sets in, allowing us to start successor
work packages earlier than planned.”
• Scope “We might not have correctly defined the scope for the computer installation. If that proves true, we will have
to add work packages at a cost of $20,000.”
• Resources “Our designer may be called away to work on the new project everyone is so excited about. If that occurs,
we will have to use someone else, and our schedule will slip between 100 and 275 hours.”
• Customer satisfaction (stakeholder engagement) “There is a chance the customer will tell us they are unhappy
with the XYZ deliverable, causing at least a 20 percent increase in time to rework the deliverable and test plans.”
Expect the phrases “sources of risk” and “risk categories” to be used interchangeably on the exam.
TRICKS
OF THE
TRADE*
Business and Pure Risk Categories
In addition to risk categories, risks can be classified under two main types:
• Business risk is a risk of a gain or loss for the business
• Pure (i.e., insurable) risk applies only to a risk of loss (such as fire, theft, or personal injury, etc.)
Variability and Ambiguity

You may also see references to risks described as “non-event” risks, which fall into the following categories:
• Variability risks are caused by the inability to predict future changes (e.g., in technology)
• Ambiguity risks are caused by a lack of understanding (e.g., unclear requirements or expectations)
292
Methods for Identifying Risks

The primary methods for this process relate to data gathering and data analysis. They include:
• Brainstorming • Interviewing
• Checklist analysis • SWOT (strengths, weaknesses, opportunities
• Documentation reviews and threats)
• Root cause analysis
Checklist analysis is most often used with risk category prompt lists discussed earlier. Root cause analysis is often
carried out using a cause-and-effect diagram (like a Fishbone diagram, also known as a “Why-why” or Ishikawa diagram).
Root cause analysis leads to reorganizing identified risks by their root causes to help find more risks.
Agile Project Pre-Mortems

A project pre-mortem is a risk identification method commonly used by agile teams. Here, the project
manager asks the team to imagine that the project (or iteration) has failed. The team identifies where and
why the project might have failed and generates a list of potential failure points. They then troubleshoot the
plan to attempt avoidance or mitigation of identified causes for failure. A pre-mortem typically involves
these steps:
1. Imagine the failure
2. Generate reasons for the failure
3. Consolidate the list
4. Revisit the plan
Example Remember our example of files being transferred to the cloud? If the project manager holds a pre-mortem,
the team can identify potential issues that would cause files to be damaged or lost in the transfer process. Once those issues
are identified, they can generate reasons for the failure and try to solve the reasons or mitigate the impact should the ones
they can’t solve occur.
Artifacts of Identify Risks: Risk Register

The risk register is the main artifact resulting from the Identify Risks process. Think of the risk register as the central
document for the entire risk management process that will be continually updated as the risk management processes are
completed and the project continues.
Notice that the risk register is a project document update for several risk management processes. Read exam
questions carefully and remember that the risk register contains different information at different points in the
project management process.
Example If the project has just started and you are in the Identify Risks process, the risk register will contain the
identified risks and potential responses, not selected response plans, which come later.
The risk register at this point in the risk management process includes the list of risks and also may contain potential
risk responses and their potential risk owners responsible to manage assigned risk responses, root causes of risks when they
have already been identified, and updated risk categories. Other information that can be documented in the risk register
includes risk triggers (defined later in this chapter), potential impacts, when each risk could occur, and when each risk will
no longer present a threat or opportunity.
A tricky question on the exam might ask, “When in the risk management process are risk responses
documented?” The answer is both during Identify Risks (as potential responses) and during Plan Risk
Responses (as selected responses).
293
Perform Qualitative Risk Analysis

As the project manager begins this process, they should have a long list of Process Groups Model
risks documented in the risk register from the Identify Risks process. It PG: Planning
would be neither efficient nor effective to plan responses to all of them, so Process: Perform Qualitative Risk Analysis
they need to prioritize those that need planned responses in case they should
occur. Qualitative risk analysis is the first of two steps in deciding which ECO
risks need planned responses. It involves subjectively analyzing all identified Domain I
risks for their probabilities and impacts on the project. Task 7 Address & remove impediments for team
Along with the risk register, the project management plan (including Domain II
the risk management plan), project documents, and organizational
influencing factors are important contributions to the Perform Qualitative
Risk Analysis process. Once we have completed assessing risks qualitatively, PMBOK® Guide
we can decide which of these risks will move on to the second ranking step: Domain 2.4 Planning
quantitative risk analysis. Domain 2.8 Uncertainty
Qualitative versus Quantitative Analysis

Many people confuse these two types of analysis. Remember for the exam that qualitative risk analysis is a subjective
evaluation. In predictive environments the numbers used to rate each risk are usually based on a scale of 1-5 or 1-10. For
example, if a risk has a high probability of happening it will be a 3 or 4 as opposed to the lower probability of 1 or 2. This is
just an example, however. The meaning of the scale is created and agreed upon by the team, making it subjective.
In contrast, quantitative risk analysis is based on a measurable rating like cost and time. The rating of each risk is based
on an estimate of the actual probability and the actual monetary value at stake (impact). For example, the rating for a risk
in qualitative analysis might be established as a probability of 3, multiplied by an impact of 4, equaling 12
(or 3 x 4 = 12). The same risk would be quantified as a probability of 65% times a cost of $40,000 equaling $26,000
(or .65 x $40,000 = $26,000).
Many people forget which risk analysis is done first: qualitative or quantitative. An easy way to remember this
TRICKS
OF THE is by thinking of the order in the alphabet in which the first unique letter of each word occurs. The letter “L”
TRADE comes in the alphabet before the letter “N”: Qualitative comes before quantitative.
Methods for Qualitative Risk Analysis

Data collection and analysis methods specific to this process include a risk data quality assessment, further use of the risk
categorization discussed earlier, a probability and impact matrix, and analyses of other risk parameters.
Risk Data Quality Assessment

With this we assess the information available on a given risk for accuracy and reliability to determine if the risk is valid and
whether more research is needed to understand it.
Example Imagine you receive a short risk description anonymously that doesn’t include a lot of data. You may allow
anonymous contributions during risk identification, but all identified risks must be defined well enough to perform a
qualitative assessment.
Risk Categorization
Assigning risks to categories may be helpful when planning risk responses. It’s also important to know that a risk
breakdown structure allows a project manager to represent risk sources into a chart-like structure, which can help answer
questions like “What will we find if we regroup the risks by category? By source? By work package?”
Using risk categories may also allow a project manager to eliminate several risks at once. Think about how useful it
would be to have not only a subjective assessment of the total amount of risk on a project, but also a breakdown of the risks
that shows which work packages, processes, people, or other potential causes have the most risk associated with them.
Probability and Impact Matrix

This is a data representation method to plot risks visually to help determine which risks to move forward to quantitative
risk analysis. Common subjective analysis scales include Low, Medium, High, and 1 to 5 or 1 to 10 ratings.
Example Risks and their rankings are shown in figure 12.3. The product of probability and impact equals the rank.
As shown in figure 12.4, the probability and impact values can also be plotted on a matrix showing values from higher to
lower along the vertical and horizontal axes.
A diagonal line is then drawn through the center. Risks to the right of the diagonal line call for more attention. Many
or all will be moved forward to Quantitative Risk Analysis.
Note: The numbers in the Rank column of figure 12.3 can be deceiving without further analysis. Risks A and D are
very close in rank and their ranks are relatively low. However, risk As impact is not tolerable. You can see that using a matrix
helps with this type of analysis.
# Risk P1 Rank
□ H
A
B
Hurricane during installation
XYZ system will arrive late causing a two-week

1
2
□ 2
5
8
co
-O
o
■
delay in deliverable Q. £
C Module K won’t work with PC operating system 2 5 10 D

D Project will interfere with Morgan’s daily work 2 2 4 ■ n u
FIGURE 12.3 Risks and their Rankings
■ Impact
FIGURE 12.4 Probability and impact matrix
Because qualitative risk analysis is a subjective evaluation, organizations frequently define a standard rating system to
foster a common understanding of what each risk ranking means, as shown in figure 12.5.
Probability Scale Impact Scale

Rating Interpretation Rating Definition
1 Low 1 No real impact
2 Medium 2 Small to medium reduction of time or cost reserves
3 Medium-High 3 Medium to large reduction of time or cost reserves
4 High 4 Over budget or behind schedule or both (0-15%)
5 Fact 5 Unacceptably over budget or behind schedule or both (over 15%);
possible physical danger or project failure
Figure 12.5 Ranking definitions for probability and impact
Risk Parameters Assessments

In addition to creating a short list of risks, qualitative risk analysis includes identifying risks that should move more
quickly than others through the process due to factors that are referred to as risk parameters. Some examples of risk
parameters include the following:
• Urgency This parameter indicates if the risk is likely to occur soon (requiring the response to be implemented
quickly) or if the risk requires a particularly long time to plan a response. Urgent risks may be moved directly or more
quickly into risk response planning.
• Dormancy This is the anticipated time between when a risk occurs and when its impact is felt.
• Manageability and controllability This parameter indicates the level of difficulty involved in dealing with an
identified risk, should it occur.
• Strategic impact This is the degree to which the occurrence of a risk would affect the strategic goals of the
performing organization.
295
Qualitative risk analysis can be used for project management tailoring to do the following:
TRICKS
OF THE • Compare the risk of the project to the overall risk of other projects.
TRADE • Determine whether the project should be continued or terminated.
• Determine whether to proceed to the Perform Quantitative Risk Analysis or Plan Risk Responses processes
(depending on the needs of the project and the performing organization).
Artifacts of Qualitative Risk Analysis

When this process is complete, there will be updates to the following artifacts:
• Project management plan (including the risk • Risk register (updated with qualitative analysis data)
management plan) • issue iog
• Project documents • Watch list
• Assumptions log
• Risk report
The risk report will include the results of risk prioritization thus far, including a list of the highest-ranking lists to be
moved forward to the Quantitative Risk Analysis process. Those risks that do not move forward to Quantitative Risk
Analysis will moved to a watch list.
Perform Quantitative Risk Analysis

The Perform Quantitative Risk Analysis process involves analyzing the prob Process Groups Model
ability and impact (the amount at stake or the consequences) of risks that PG: Planning
ranked highest in qualitative risk analysis. The numbers used in this case are Process: Perform Quantitative Risk Analysis
based on monetary estimates of the time and costs, should a risk happen.
Quantitative risk analysis also looks at how risks could affect the objectives ECO
of the project. The purpose of quantitative risk analysis is to determine: Domain I
• Which risk events warrant a response plan and which require the
most attention. Domain II
• Overall project risk (risk exposure). Task 15 Manage project issues
• The quantified probability of meeting project objectives.
Examples “We have an 80 percent chance of completing the PMBOK* * Guide
project within the six months required by the customer,” or “We have Domain 2.4 Planning
a 75 percent chance of completing the project within the $800,000 Domain 2.8 Uncertainty
budget.”
• Cost and schedule reserves.
• Realistic and achievable cost, schedule, or scope targets.
For some projects, there may be a subset of risks identified that require quantitative analysis. While the project
manager should always do qualitative risk analysis, they should proceed with quantitative risk analysis only if it is worth the
time and money; otherwise they should move directly to risk response planning.
The Perform Quantitative Risk Analysis process can include a lot of calculation and analysis. Luckily, the details of
these efforts are not a focus of the exam. You need to know that the following actions are part of quantitative risk analysis
but not how to do them beyond what is explained in this chapter:
• Further analyze the highest-ranked risks on the project and other results of qualitative analysis.
• Perform data analysis to determine which risks have the most impact on the project.
• Determine how much quantified risk the project has through data analysis.
296
Methods for Quantitative Risk Analysis

Quantitative probability and impact can be determined in a variety of ways that make use of some or all the following tools:
• Expert judgment from the team and risk specialists • Interpersonal
Interpersonaland
andteam
teamskills
skills
• Data-gathering techniques, such as interviewing ••Cost
Cost
andand
schedule
schedule
estimating
estimating
• Data analysis techniques, such as sensitivity analysis ••Use
Use
of of
historical
historical
records
records
from
from
previous
previous
projects
projects
and decision tree analysis
Simulations
These techniques can be extremely valuable. Monte Carlo analysis is a simulation in which schedule and cost estimates are
used to “perform” the project many times to simulate results. Traditionally, there has been only one or two questions
about Monte Carlo analysis on the exam.
You do not need to have direct experience performing Monte Carlo analysis for the exam. You should just
understand that Monte Carlo analysis:
• Evaluates the overall risk in the project
• Is done with a specialized computer application
• Determines the probability of completing the project on any specific day or for any specific cost
• Determines the probability of any activity actually being on the critical path
• Considers path convergence (points in the network diagram where many paths converge into one activity)
• Translates uncertainties into impacts to the project
• Can be used to assess cost and schedule impacts
• Results in a probability distribution (in the form of a chart)
Sensitivity Analysis
This technique analyzes and compares the potential impacts of identified risks. A tornado diagram may be used to
graphically depict the results of this analysis. Risks are represented by horizontal bars. The longest and uppermost bar
represents the greatest risk, and progressively shorter horizontal bars beneath represent lower-ranked risks. The resulting
graphic resembles a funnel cloud, or tornado, as shown in figure 12.6.
Server installed by November 1

Data security test
User training by January 15 [
Integration testing of code modules
System install on test computers
User acceptance test
User screen requirements
$-30,000 $-20,000 $-10,000 0 $10,000 $20,000 $30,000 $40,000
Figure 12.6 Tornado diagram
Expected Monetary Value (EMV)

This is an important method for quantitative risk analysis. EMV can be used in several ways but is often used to estimate
the impact of a risk by calculating the product of its estimated probability (as a percentage) times its estimated cost (as a
dollar amount, should it occur). The equation for EMV is:
EMV=PxI
Example 65% x $40,000 = $26,000. In other words, a 65% probability of risk that would cost $40,000 if it happened
has an EMV of $26,000.
297
EMV estimates for risks in a quantitative risk analysis are summed to calculate contingency reserves. Questions on
the exam may ask “What is the expected monetary value of the following?” Do the following exercise to give this a try. The
exam could also ask you to calculate the expected monetary value for cost, the expected value (or just “value”) for the
schedule of a path, or the value of your decision.
Note that for opportunities, expected monetary value is presented as a positive amount (e.g., $3,000), while threats
are presented as negative numbers (e.g., -$3,000).
12.1 Exercise
In your Exercise Notebook, calculate the expected monetary value for each of these work packages. The math is
not difficult but completing this exercise will help you remember this calculation for the exam.
Work Expected Monetary

Package Probability Impact Value
A 10% $20,000
B 30% $45,000
c 68% $18,000
Answer
Work Expected Monetary

Package Probability Impact Value
A 10% $20,000 $2,000
B 30% $45,000 $13,500
c 68% $18,000 $12,240
Decision Tree Analysis

There have historically been only one or two questions about decision trees on the exam, but since they are unfamiliar to
many people we will talk about them here. You should know what a decision tree is and be able to calculate a simple one
from data within an exam question.
A decision tree is analyzed by calculating the value of each branch (another way of using EMV). The outcome of this
calculation will show the best option to select. You should also know the following about decision trees:
• They consider future events.
• They calculate the expected value (probability multiplied by impact) in more complex situations. For example, a
project manager could evaluate the costs or schedule impheations and benefits of several risk responses at once to
determine the best option.
• They involve mutual exclusivity.
Some examples of decision trees have the costs occurring only at the end of the project, while others have
TRICKS costs occurring early or in the middle of the project. Because a decision tree models all the possible choices to
OF THE
TRADE resolve an issue, costs can appear anywhere in the diagram, not just at the end. When you are taking the exam,
don’t get confused when you look at examples of decision trees. Pay attention to the data provided in the
question so you can correctly interpret the answer.
298
The following exercise includes a decision tree analysis. The box represents a decision to be made, and the circles
represent what can happen as a result of the decision.
12.2 Exercise
A company is trying to determine if prototyping is worthwhile on a project. They have come up with the following
impacts (see the diagram) of whether the equipment works or fails. Based on the information provided in the
diagram, what is the expected monetary value of each option? Which is the cheaper option—to prototype or not
to prototype? Do the calculations and write the answer in your Exercise Notebook.
Failure: 35% probability

and $120,000 impact
Pass: No impact
Failure: 70% probability and

$450,000 impact
Pass: No impact
Answer
If you just look at the setup cost of prototyping, it would seem like an unwise decision to spend money on
prototyping. However, the analysis proves differently. Taking into account only the one future event of whether the
equipment works or fails, the decision tree reveals that it would be cheaper to do the prototyping. The expected
monetary value of prototyping is $242,000; the expected monetary value of not prototyping is $315,000.
35% x $120,000 = $42,000

Prototype
$42,000 + $200,000 = $242,000
Do Not
70% x $450,000 = $315,000
Prototype
Project management saves time and money on projects. Getting your organizations executives to understand
TRICKS
OF THE that fact can be difficult at times. How beneficial would it be if you could prove the value of project management?
TRADE.
Example Imagine that you have just calculated the EMV of all high-ranking and high-priority risks in
qualitative risk analysis, or that you have completed a Monte Carlo analysis for a project. In either case, you calculate that
you need a $98,000 contingency reserve on the project to adapt for risks. Then, when the team moves on to the Plan Risk
Responses process (discussed next) they eliminate some risks and reduce the probability or impact of others. The EMV
calculation or Monte Carlo analysis is redone, showing a revised need for a $12,000 reserve. You have potentially saved
$86,000 before project work even starts!
299
Artifacts of Perform Quantitative Risk Analysis

The Perform Quantitative Risk Analysis process results in updates to the risk register and other project
documents, including:
• Prioritized list of quantified project risks What risks are most likely to have a negative effect on the critical path?
What risks need the most contingency reserve?
• The quantified probability of meeting project objectives
Examples “We have an 80 percent chance of completing the project within the six months required by the
customer,” or, “We have a 75 percent chance of completing the project within the $800,000 budget.”
• Quantitative risk analysis trends As the project manager repeats quantitative risk analysis in project planning and
when changes are proposed, they can track changes to the overall project risk and see trends.
• Initial contingency time and cost reserves needed (finalized in Plan Risk Responses)
Example “The project requires an additional $50,000 and two months of time to accommodate the project risks.”
• Assessment of overall project risk exposure Use overall project success probability (how likely it is that the
project will achieve all key objectives) and any variables that may still affect the project to fully understand the overall
risk exposure of the project.
• Possible realistic and achievable completion dates and project costs, with confidence levels, versus the time and
cost objectives for the project.
Example “We are 90 percent sure that we can complete this project on May 25th for $989,000.”
• Recommended risk responses After quantitative risk analysis is performed, the risk register may include suggested
responses to overall project risks and individual project risks.
Plan Risk Responses

The Plan Risk Responses process involves figuring out, “What are we going Process Groups Model
to do about each top-ranked risk?” We have and will use the risk register, PG: Planning
which has been updated throughout the risk management process and now Process: Plan Risk Responses
includes the analyzed and prioritized risks. The “Top Risks” are the risks for
which responses will be planned. The project manager will use methods like ECO
alternatives analysis and cost benefit analysis to evaluate the values of vari Domain I
ous response strategies and specific risk response plans relative to their costs. Task 7 Address & remove impediments for team
The cost baseline will describe a contingency reserve that will be used in
addressing these specific risks. See the discussion on reserves later in this Domain II
chapter.
Responses for Top Risks

PMB0K* Guide
The projects risk responses may include doing one or a combination of the
Domain 2.4 Planning
each top risk:
• Do something to eliminate the threats before they happen.
• Do something to make sure the opportunities happen.
• Decrease the probability and/or impact of threats.
• Increase the probability and/or impact of opportunities.
This is what risk management is all about. There are always options to respond to risks. If a change to a team members
availability is a top risk, the project manager can investigate the possibility of replacing that team member with another
resource with similar skills. If a work package is causing a large amount of risk, the project manager might look at:
• Changing the deliverable • Changing the quality requirements
• Modifying the work to produce it • Removing scope from the project
SOO
Responses for Residual Risks

Residual risks are those left in the project that cannot be anticipated or planned for. Every project has them. For the
remaining (residual) threats that cannot be eliminated or exploited:
• Do something if the risk happens (contingency plans). Contingency plans should be measurable so the project
manager can evaluate their effectiveness.
• Do something if contingency plans are not effective or are only partially effective (fallback plans).
The project manager and the team determine what to do about each of the residual risks—those that cannot be
eliminated or exploited. This might mean accepting these residual risks, or planning additional risk responses. The work
involved in all risk responses is then assigned to risk owners.
When taking the exam, assume that all major potential problems and opportunities that could have been
TRICKS anticipated as risks were identified and analyzed before they occurred and that there was a plan for each risk.
OF THE
TRADE- With this in mind, the best answer to a question describing a major problem on the project will be the choice
that talks about implementing a contingency plan, rather than one that involves discussing possible solutions
Ito a problem after it has occurred. Many people have said that these types of questions were the reason they failed the
exam. They simply made the wrong choices in situational questions. Be sure to make the transition to this way of thinking
if it is unfamiliar to you.
However, no matter how much risk analysis and response planning is done, there is usually residual risk on a project.
This is why there is a management reserve as well as a contingency reserve.
Here are a couple more points that can be tricky on the exam:
• Can all threats be eliminated on a project? Remember that threats can be eliminated and opportunities exploited, but
the time and trouble involved in eliminating all the threats and exploiting all the opportunities on a project would
probably not be worthwhile.
• Did you know that qualitative risk analysis, quantitative risk analysis, and risk response planning occur throughout the
life of a project? As noted in other parts of this book, planning is iterative. The project manager needs to review risks
throughout the project, including while the project work is being done or when checking results. Newly identified
risks need to go through the risk planning process.
Risk Response Strategies

When completing risk response planning, a thorough analysis must be done of the potential responses for each risk. Some
of these risk response strategies, also known as risk mitigation strategies or strategies for threats and opportunities, involve
changing the planned approach to completing the project, including changes to the WBS, the quality management plan,
resources, schedule, budget, or communications strategies.
Response Strategies for Threats

The risk response plans the project manager has for specific risks are called contingency plans. The types of response
strategies for threats include:
• Avoid This means eliminating the threat by eliminating the cause. Examples include removing a work package or
changing the person assigned to do work. Avoiding a threat might even involve expanding the scope of the project.
Example Imagine there’s an estimated 75 percent likelihood of a threat occurring, but an additional level of
testing or an additional activity would likely prevent this threat. Expanding the scope of the project in this way could
help avoid the threat.
On an overall project level, if the threat is beyond the organization s risk threshold, the project manager will need to
take action to make the project acceptable. This could include removing pieces of the project that are too risky to avoid or
cancelling the entire project.
• Mitigate This is reducing the probability and/or the impact of threat, thereby making it a smaller risk and possibly
removing it from the list of top risks on the project. Options for reducing the probability are considered separately
from options for reducing the impact. Any reduction will make a difference, but the option with the most probability
and/or impact reduction is often the option selected.
JO
• Transfer (deflect, allocate) Think “insurance.” This is done by purchasing insurance, performance bonds,
warranties, or guarantees, or by outsourcing the work, making an outside party responsible for managing the risk.
There is a strong connection here between risk and procurement (contracts). When proper project management is
done, risk analysis is completed before a contract is signed, and transference of risk is included in the terms and
conditions of the contract.
Avoidance and mitigation are generally used for high-priority, high-impact risks. Transference, along with escalation
and acceptance (discussed next) may be appropriate for low-priority, low-impact risks as well as those with higher impact.
• Pure risk A response to pure risks—such as fire, property damage, or personal injury—is transference, or purchasing
insurance. Insurance exchanges an unknown cost impact of a known risk for a known cost impact.
Example With a risk of fire, the cost impact of the risk is unknown. But when insurance is purchased, the cost
impact of the risk of fire becomes known; it is the cost of the insurance and the deductible. Transferring the risk by
purchasing insurance does not eliminate all impacts. There may still be residual risks. A project could experience
schedule delays due to a fire even if fire insurance was purchased, or the cost of the fire damage could exceed the
amount of insurance purchased.
• Secondary risk In another example, there is a risk that the risk response plan itself could cause a problem. If the third
party (insurance company or seller) has trouble delivering on their end, they could cause a schedule delay. The project
manager still needs to decide what to do about any possible secondary risks.
Response Strategies for Opportunities

The choices of response strategies for opportunities include:
• Exploit (the reverse of avoid) Either add work or change the project to make sure the opportunity occurs. This
could be on the individual project risk level or on the overall project risk level.
• Enhance (the reverse of mitigate) Increase the likelihood (probability) and/or positive impacts of the opportunity
occurring. This could be related to the overall approach to scope and schedule, resources used, or project replanning,
as well as to individual project risks.
• Share Allocate ownership or partial ownership of the individual or overall project opportunity to a third party
(forming a partnership, team, or joint venture) that is best able to achieve the opportunity.
Example It is common in a procurement contract to offer a bonus or incentive to complete the seller’s part of the
project early if it creates an equal or better savings opportunity for the buyer.
Response strategies for both threats and opportunities include:

• Escalate If it is outside the scope of the project or beyond the project manager s authority, a risk should be escalated
within the organization. These risks are typically managed at the program or portfolio level. An escalated risk needs to
be accepted by the program or portfolio manager; the escalation is then documented and the risk is no longer
monitored at the project level.
• Accept Passive acceptance means to do nothing and to essentially say, “If it happens, it happens.” This leaves actions
to be determined as needed (workarounds) if the risk occurs. Active acceptance involves creating contingency plans
to be implemented if the risk occurs and allocating time and cost reserves to the project.
Common Response Strategies for Threats or Opportunities

The following rules and strategies can be used for threats and opportunities:
• Strategies must be timely.
• The effort selected must be appropriate to the severity of the risk. Avoid spending more money to prevent the risk
than the cost of the impact of the risk had it occurred.
• One response can be used to address more than one risk.
• More than one response can be used to address the same risk.
• A response can address the root cause of risk and thereby address more than one risk.
• The team, other stakeholders, and experts should be involved in selecting a strategy.
502
Watch out for questions on the exam about communicating risk-related information! Risk response strategies must
be communicated to the sponsor, management, and stakeholders. These parties will need to know that you are in control
of the project even if there is a problem, and they may need to approve the resources to make the risk response strategies
happen. Communicating about risk is essential for gaining buy-in to the strategy.
12.3 Exercise
Now let’s see if you can apply what you have learned. Identify the type of risk response strategy (avoid, mitigate
the probability, mitigate the impact, transfer, exploit, enhance the probability, enhance the impact, share, escalate,
or accept) being described. Write the answer in your Exercise Notebook for each description.
Risk Response
Description Strategy
1. Remove a work package or activity from the project.
2. Assign a team member to frequently visit the seller s manufacturing
facilities to learn about problems with deliveries as early as possible.
3. Move a work package to a date when a more experienced resource is

available to be assigned to the project.
4. Begin negotiation for the equipment earlier than planned so as to
secure a lower price.
5. Outsource a work package so as to gain an opportunity.
6. Notify management that there could be a cost increase if a risk occurs
because no action is being taken to prevent the risk.
7. Remove a troublesome resource from the project.

8. Provide a team member who has limited experience with additional
training.
9. Train the team on conflict resolution strategies.
10. Outsource difficult work to a more experienced company.
11. Ask the client to handle some of the work.
12. Prototype a risky piece of equipment.
13. Notify the PMO that the testing software needed for the project could
be used by three other IT groups if the enterprise solution is
purchased.
14. The team adds a risk spike to see if a new, less expensive, cloud
provider could support the product.
503
Answer
Risk Response Strategy

Avoid 6 Accept 11 Transfer
Mitigate the impact 7 Avoid 12 Mitigate the probability
Exploit 8 Mitigate the probability 13 Escalate
Enhance the impact 9 Mitigate the impact 14 Exploit
Share 10 Transfer
Potential risk response strategies and contingency plans must be analyzed to determine which strategy or
TRICKS strategies are most cost-effective and most likely to address the risk. Cost-benefit analysis and multicriteria
OF THE
TRADE analysis are techniques to evaluate and rank potential risk responses. You may see a question on the exam
asking you to compare the cost effectiveness of various risk response options.
Artifacts of Plan Risk Responses

Planned risk responses may require changes to management plans that have been drafted in planning—at the overall
project risk level as well as at the individual project risk level. Other artifact updates as a result of planning risk responses
may include:
• Risk register (see below) • Assumptions log
• Cost forecasts • Lessons learned register
• Project schedule • Project team assignments (roles and responsibilities)
• Change requests • Stakeholder engagement strategy
• Quality metrics • Risk report
Risk Report
This is updated to communicate the risks of greatest threat or opportunity, overall project risk exposure, anticipated
changes, and anticipated outcomes of planned risk responses. The concepts defined next relate to the risk register updates
resulting from Plan Risk Responses.
Risk Register Updates

The risk register is updated to add the results of risk response planning, including:
• Residual risks After risks have been avoided, exploited, mitigated, enhanced, transferred, shared, escalated, and
accepted (and related contingency and fallback plans have been created), there will still be risks that remain. The
known residual risks that are passively accepted should be documented and reviewed throughout the project because
their rankings may need to change.
• Contingency plans These plans describe the specific actions that will be taken if the opportunity or threat occurs.
• Fallback plans These plans are specific actions that will be taken if the contingency plans are not effective. Think
how prepared you will feel if you have plans for what to do if a risk occurs and what to do if the original plan does
not work.
• Risk owners Each risk must be assigned to someone who will help lead the development of the risk response and
who will be assigned to lead the risk response or “own” the risk. The risk owner can be a stakeholder other than a team
member. Think about how the application of risk management could change real-world projects. The risk occurs; the
risk owner takes the pre-approved action determined in project planning and informs the project manager. No
meeting is needed—just action! This can be very powerful.
• Secondary risks Any new risks created by the implementation of selected risk responses should also be analyzed as
part of risk response planning. Frequently, a response to one risk will create the possibility of new risks. For example,
if a portion of the project work is outsourced to a seller because the project team does not have the expertise to
complete the work efficiently, there may be a secondary risk of the seller going out of business. The discovery of
secondary risks may require additional risk response planning, including ensuring that the secondary risks are of a
lower severity than the primary risk.
• Risk triggers These are events that trigger the contingency response. The early warning signs for each risk on a
project should be identified so risk owners know when to take action.
• Contracts Before a contract is finalized, the project manager should have completed a risk analysis and included
contract terms and conditions required to mitigate threats and enhance opportunities. Any contracts issued to deal
with risks should be noted in the risk register.
• Reserves (contingency and management) Having reserves for time and cost is a required part of project
management. We explain these further next.
Contingency and Management Reserves

Reserves are covered in the “Budget and Resources” chapter, but let’s look at them again here. Time and cost each have
two types of reserves: contingency reserves and management reserves. Contingency reserves account for “known
unknowns” (or simply “knowns”); these are items identified during risk management. Management reserves account for
“unknown unknowns” (or simply “unknowns”); these are items the project manager did not or could not identify during
risk management.
Projects can have both kinds of reserves. As shown in the diagram in figure 12.7 (also shown in the “Budget and
Resources” chapter), contingency reserves are calculated and become part of the cost baseline. Management reserves are
estimated (for example, 5 percent of the project cost), and these reserves are then added to the cost baseline to get the
project budget. The project manager has control of the cost baseline and can approve use of the contingency reserves, but
management approval is needed to use management reserves. The same applies to reserves in the schedule.
Make sure you understand that reserves are not an additional cost to a project. The risk management process should
result in a decrease to the project s estimated time and cost. As threats are eliminated or their probability or impact reduced,
there should be a reduction to the projects schedule and budget. Contingency reserves are allocated for the contingency
plans and fallback plans to deal with the associated, accepted opportunities and threats that remain after the risk
505
management planning processes have been completed. No matter what the project manager does, risks will remain in the
project, and there should be a time or cost allotment for them, just as time or cost is allotted to work activities on the project.
8. Cost budget
7. Management reserves
6. Cost baseline
5. Contingency reserves
4. Project estimates
3. Control account estimates
2. Work package estimates
A1 A2 A3 A4 A5
1. Activity estimates $25 $25 $25 $25 $45
FIGURE 12.7 Contingency and management reserves create a cost budget
There may be questions on the exam that ask you to calculate the contingency reserve for several risk events, which
may be a combination of opportunities and threats. To do this, you must calculate the value of each risk using the equation
for expected value (P x I). On the exam, you may have to calculate contingency reserves for either schedule (expected
value) or cost (expected monetary value). But think about this a minute. Let’s use the example for cost impacts to projects.
Can you just add all the expected monetary value amounts of the opportunities and threats together and come up with one
grand total for the budget? No! You’ll need to subtract the total expected monetary value of the opportunities from the
total expected monetary value of the threats. Why?
Opportunities will save money and time on the project if they occur. This can reduce the cost or schedule baselines.
Conversely, the threats will add cost and time to the project.
You’re being told to subtract opportunities here, but weren’t you told earlier that expected value is often presented as
a positive amount for opportunities and a negative amount for threats? That’s often true when the values are depicted on
something like a decision tree, so you can easily identify positive and negative outcomes and their overall effect on project
costs or schedule. But this example is specifically looking to determine how much money or time to set aside for the
contingency reserves. Threats will require increasing the amount of contingency reserves, whereas opportunities will
decrease the required reserves.
The next exercise will give you practice on calculating a contingency reserve.
S06
12.4 Exercise
Imagine you are planning the manufacture of modifications to an existing product. Your analysis has come up with
the following information. In your Exercise Notebook, calculate the cost contingency reserve for each of the
following scenarios, and then calculate the total cost contingency reserve for the project.
Project Data
1. There is a 30 percent probability of a delay in the receipt of parts, with a cost to the project of $9,000.
2. There is a 20 percent probability that the parts will cost $10,000 less than expected.
3. There is a 25 percent probability that two parts will not fit together when installed, costing an extra $3,500.
4. There is a 30 percent probability that the manufacture may be simpler than expected, saving $2,500.
5. There is a 5 percent probability of a design defect, causing $5,000 of rework.
Total Cost Contingency Reserve
Answer
You use the expected monetary value calculation (EMV = P x I) to determine the contingency reserve. The answer
is $1,075 for the total cost contingency reserve. See the following table for the detailed calculations.
Cost Contingency Reserve Calculations
1. 30% x $9,000 = $2,700

Add $2,700
2. 20% x $10,000 = $2,000

Subtract $2,000
3. 25% x $3,500 = $875

Add $875
4. 30% x $2,500 = $750

Subtract $750
5. 5% x $5,000 = $250
Add $250
Total Cost Contingency Reserve = $1,075
Think About It. Let’s assume this exercise had examples of threats and opportunities to the schedule. If you
had a 30 percent probability of a 15-day activity delay, the expected value would be 4.5 days, which would be
added to the schedule. And if the probability of an activity taking 10 days less than planned was 20 percent,
the expected value would be -2 days. The resulting contingency for these two risks would be 2.5 days.
If the risk management process is new to you, the following exercise should help you put it all together by looking at
it in a chart form.
507
12.5 Exercise
In your Exercise Notebook, create a flowchart of the risk process from Identify Risks through Plan Risk Responses.
Answer
Creating this chart will help you check whether you have understood what you have read in this chapter. Your
flowchart could be different than the following depiction.
Create short list

actively
of risks
Develop
(through Reduce Go back and
fallback
qualitative and \ probability perform
plans
optional and impact of iterations,
quantitative threats; and update
risk analysis) increase project
probability management
residual
and impact of plan and
and
opportunities project
secondary
documents
\
watch list ot
noncritical
risks
Escalate overall project
risks to program or
portfolio managers
Agile Risk Responses

As we have said before, any of the already discussed concepts and methods can be used in any environment.
In agile and hybrid environments the result of all this this work takes the form of reprioritizing the backlog,
creating risk response stories, updates to iteration and release plans, and updates to iteration roadmaps.
Risk-adjusted Backlog
In an agile environment, a projects backlog is prioritized not just for features but for the risk responses that have been
developed for identified risks. In planning each iteration, agile teams seek to balance delivering the highest-value features
and mitigating the biggest threats that remain on the project. The backlog can now be referred to as a “risk-adjusted
backlog,” as illustrated in figure 12.8.
508
FIGURE 12.8 Risk-adjusted backlog (prioritized feature list)
Set-based Design
Another concept in adaptive environments is set-based design. This is just like doing an extensive what-if analysis. Note
that a tool like decision tree analysis can be used here. Set-based design involves exploring multiple options, or designs,
early in the project and eliminating the ones that won’t work. It creates flexibility and allows teams to develop knowledge
as they work through the different options.
Spend a moment now thinking about how risk response planning might also lead to adjustments to the schedule, cost,
quality, procurement, communications, and resource management plans, as well as to the scope, schedule, and cost
baselines for the project. This concept is critical for understanding the impact risk management has on projects, especially
if you don’t currently do risk management on your projects.
Think about it. You are nearing the end of the Plan Risk Responses section. Let’s examine some important
concepts for the exam in this group of questions and answers. Take a few moments to test yourself.
Question What do you do with noncritical risks?

Answer Document them in a watch list, and revisit them periodically.
Question Would you choose only one risk response strategy for each particular risk? For the project
as a whole?
Answer No, you can select a combination of choices.
Question What risk management activities are done during the execution of the project?
Answer Watching out for watch-listed (noncritical) risks that increase in importance and looking
for new risks; implement contingency plans if triggers indicate the risk is about to occur
or is occurring.
Question What is the most important item to address in project team meetings?
Answer Risk.
Question How would risks be addressed in project meetings?

Answer By asking, “What is the status of risks? Are there any new risks? Is there any change to the
order of importance?”
509
Implement Risk Responses

Implementing risk responses is where the value of proper risk management Process Groups Model
becomes most apparent. When the preliminary work has been done well, PG: Executing
the Implement Risk Responses process can be handled smoothly, since the Process: Implement Risk Responses
previously documented plans allow for timely and effective responses to
risk events. ECO
Throughout the project, the risk register and risk report are reviewed Domain I
regularly, ensuring everyone is aware of potential risks and ready to
implement the planned responses as needed. Information on triggers Domain II
enables the project manager, risk owner, and team to recognize indications
that a risk event is imminent. At that point, the risk owner, supported by
the project manager, leads previously assigned resources in performing PMBOK® Guide
response activities. The consequences of threats are averted, or Domain 2.5 Project work
opportunities are taken advantage of. Risk thresholds are documented in Domain 2.6 Delivery
the plan along with expected outcomes of risk responses—for example, Domain 2.8 Uncertainty
how much should be saved by each planned risk response so the success of
the implementation can be evaluated.
Think about it. At the beginning of this chapter we included the story of a project manager who was managing
a hardware/software installation during a hurricane. Lets revisit that example. If the project manager had
performed proper risk management, he would have had a plan in place to avoid the risk of a hurricane having an
impact on his project.
Example Schedule the project to happen before or after the forecasted hurricane. If the project manager and the
risk owners had actively monitored known risk triggers (such as the results of weather reports including wind speeds
and the projected path of the hurricane) and then implemented a risk response plan before the hurricane reached the
area, they could have avoided the danger, rework, delays, and the costs resulting from the hurricane.
Sometimes carefully developed plans don’t have the expected result.
Example Let’s assume the risk owner or the project manager in the previous story implemented a risk response
plan to reschedule the implementation, causing the schedule to be extended. Although the plan was executed as
intended, the hurricane caused more damage than anticipated, and the schedule had to be extended beyond the
planned number of days. Such unforeseen results are managed through change requests to the cost and schedule
management plans.
Artifacts of Implement Risk Responses

Project documents are updated as a result of the Implement Risk Responses process. The risk register and risk report are
updated with information on responses taken, details on how well the responses addressed the risks, and suggested
changes to future risk response plans. The lessons learned register is updated with what worked and what didn’t work
when risk responses were implemented. The risk report is updated with changes to the project’s risk exposure and changes
to planned risk responses. Ongoing issues, such as confusion or disagreement regarding the response as it was
implemented, are added to the issue log.
510
Monitor Risks
Risk-related questions on the exam assume that the project manager has Process Groups Model
done proper project management, including assigning risk owners, putting PG: Monitoring and Controlling
contingency plans and reserves in place, and taking actions as outlined in Process: Monitor Risks
the plan—unless data in the question indicates otherwise. The exam also
assumes the project is substantially less risky with this planning done. If you ECO
do not have experience using risk management in the real world, spend Domain I
more time in this chapter and practicing with these concepts so you are Task 7 Address Sremove impediments for team
prepared for these exam questions. Domain II

It is during the Monitor Risks process that the project manager will
Task 10 Manage project changes
evaluate the effectiveness of the risk management plan. In predictive and Task 15 Manage project issues
adaptive environments alike, the project manager will make sure that
proper risk management procedures are being followed and will watch for PMBOK8 Guide
unexpected effects or consequences of risk events. Corrective actions may Domain 2.7 Measurement
be needed and change requests will be sent to integrated change control, or Domain 2.8 Uncertainty
on an agile project additional risk adjustments will be made to the backlog.
You will find on the RMC Resources page a checklist of actions a project manager needs to take
https://rmcls.com/rmc-r
in a predictive environment during the Monitor Risks process. Review that checklist to make sure
you understand each of the actions. You can find it by scanning the code to the right or going to rmcls.
com/rmc-resources.
Agile Risk Monitoring

In an agile or hybrid environment, you may update risk burndown charts, review risks in RMC RESOURCES
a retrospective, and ask the project team how plans are going to reduce threats and
maximize opportunities. Do you need to create any new stories to address new or
escalating risks? Do you need to engage the product owner in discussions about
reprioritizing the backlog based on new risk information?
Methods for Monitoring Risk

Other work that is part of the Monitor Risks process is outlined in the following sections.
Workarounds
If the project has deviated from the baselines, the team may take corrective action to bring it back in line. Recommendations
for such corrective actions may include workarounds. Whereas contingency responses are developed in advance,
workarounds are unplanned responses developed to deal with the occurrence of unanticipated events or problems on a
project (or to deal with risks that had been accepted because of the unlikelihood of an occurrence and/or minimal
impact). Project managers who do not perform risk management spend a lot of their time creating workarounds.
Risk Reassessments
Questions always seem to come up on the exam that require you to know that the team needs to periodically review the
risk management plan and risk register and adjust the documentation as required. It is important to determine whether
any changes or adjustments need to be made to what was planned based on information that becomes apparent once
work begins. Reassessing risk is a good topic for a team meeting, a retrospective, or even a separate meeting, as part of
risk reviews.
Risk Reviews and Audits

For the exam, think of status meetings as team meetings in which the project manager can perform risk reviews and
risk audits.
• Risk reviews are held regularly to discuss the effectiveness of planned risk responses that have been implemented on
the project, and may result in the identification of new risks, secondary risks created by risk response plans, and risks
that are no longer applicable. Closing of risks allows the team to focus on managing the risks that are still open. The
closing of a risk should result in the associated risk reserve being returned to the company.
• Audits can be performed during meetings to assess how well risk processes are working for the project. The auditing
process is documented in the risk management plan.
Reserve Analysis
Reserve analysis is a matter of checking to see how much reserve remains and how much might be needed. It is like
checking the balance in your bank account to ensure your monthly budget is on track. Reserves must be protected
throughout the project life cycle.
Now let’s talk about a concept that can be tricky on the exam, especially for those who are not experienced in
systematically managing risk. People wanting to change the project in response to problems that have occurred may suggest
using the reserves instead of adding cost or time to the project. It is important to know that a contingency reserve may only
be used to handle the impact of the specific risk it was set aside for. So, if the change is part of the risk response plan that
was previously accounted for in the budget, the reserve designated for that response may be used. If it is not, the project
manager must take preventive or corrective action, fast track, crash, or otherwise adjust the project to accommodate or
make up for the impact of the problem and its resulting changes, or request new reserve line items.
Under certain circumstances, usually determined by the project sponsor, management reserves may be used for
situations that are within the scope of the project but were not previously identified.
Example Assume that a change to the product order functionality on a website has exposed an unidentified data-
sharing incompatibility with the real-time data on the legacy inventory management system. A workaround needs to be
created to keep the project on track. Management reserves will be used to hire experts to fix the problem and keep the
project close to the current schedule.
If identified risks do not occur, the associated time or cost reserves are returned to the company, rather than used to
address other issues on the project. If you are inexperienced with risk management, make sure you understand how
reserves are used and protected.
Technical Performance Analysis

Technical performance analysis uses project data to compare planned versus actual completion of technical requirements
to determine if there is any variance from what was planned. Any variance could indicate possible risks to the project,
either opportunities or threats.
Agile Retrospectives and Risk Burndown Charts

Retrospectives and risk burndown charts are agile tools that allow for ongoing monitoring and controlling
for risks.
• Retrospectives occur throughout an agile project at the end of iterations. Retrospectives offer a number
of benefits for controlling risk including improved:
>/ Productivity by identifying and applying lessons learned immediately.
>/ Capability by providing a venue for spreading scarce knowledge (or tacit knowledge),
y Quality by finding circumstances that have led to defects and removing the causes.
y Capacity by finding process improvements, which in turn improve a team’s work capacity.
• Risk burndown charts may be used for planning, managing, and controlling risk. These charts allow stakeholders to
easily see a risk profile on a project. Risk burndown charts quickly inform stakeholders whether the threats are moving
in the right direction (downward), or if they are escalating. See the example in figure 12.9 in which the project team is
developing library software for patrons who are looking for jobs. Four risks have been identified.
512
The biggest risk is that the “Resume builder” software is not able to make a nice-looking, professional resume because
it can’t decide where a logical page break should be inserted. The team performs a risk spike in January to try an artificial
intelligence module to find the best place for the page break. When they succeed, the associated risk is eliminated and in
turn the overall project risk was reduced by early February.
Resume builder feature can’t

make a logical page break
Resume builder file isn’t

accepted by hiring companies
Interface with job board

companies is error prone
New features difficult for

patrons to use
Artifacts of Monitor Risks

As with other risk management processes, change requests, updates to any project management plan component, the risk
register, risk report, and other project documents are a result of Monitor Risks, along with additional outputs listed here.
Work Performance Information

This is the analysis of the work performance data gathered as part of project control. Examples include:
• Results of risk reviews and audits
• Performance measurements on schedule progress
• Determinations of which risks can be closed or are likely to close in the near future
• Variance analyses comparing the planned versus actual risk data
• Time and cost of implemented risk responses
In agile and hybrid environments risk response plans are recorded and carried out as stories in the
backlog. Information is exchanged in daily standup meetings about new accomplishments as well as impedi
ments, and is documented through an updated backlog and burnup and burndown charts.
Risk Register Updates

The Monitor Risks process will add the following to the risk and lessons learned registers:
• Outcomes of risk reassessments and risk audits
• Results of implemented risk responses
• Updates to previous parts of risk management, including the identification of new risks
• Closing of risks that are no longer applicable
• Details of what happened when risks occurred
• Lessons learned
513
Carefully read situational questions that describe suggested changes resulting from risk processes to determine
TRICKS
OF THE whether the actual work of the project has begun. You will have to determine what efforts are generating the
TRADE change requests to help you evaluate answer choices. If the work of monitoring risks is being performed, new
risks may be identified, or planned risk responses may need to be adjusted based on project knowledge or an
evaluation of risk processes.
As a result of approved changes, risk planning must again be performed appropriately, and new risks must be evaluated
and ranked, which may result in more risk response planning. This will generate change requests to integrated change
control. The trick here is to remember that the approved project management plan and baselines are not static but changes
to them must go through integrated change control.
Organizational Process Asset Updates

The Monitor Risks process may include the creation or enhancement of risk templates, such as the risk register, checklists,
and risk report, as well as updates to risk management processes and procedures. The project s risk breakdown structure,
backlog, and other data may be added to OPAs as historical records for future projects. Updates to agile project artifacts,
like new backlog and burndown chart versions, as well as records of planned vs. actual iteration velocities are also
organizational process assets.
The exam may describe situations where the wrong thing is being done as a way of testing whether you realize
TRICKS
OF THE it is wrong. Some of the following common risk management mistakes can help you consolidate your
TRADE knowledge of risk management:
• Risk identification is completed without knowing enough about the project and then not iterated.
• Padding of estimates is used instead of the risk management process.
• The processes of Identify Risks through Perform Quantitative Risk Analysis are blended, resulting in risks
that are evaluated or judged as they come to light. This decreases the number of total risks identified and
causes people to end risk identification too soon.
• The risks identified are general rather than specific (for example, “communications” rather than “poor
communication of customer s needs regarding installation of system XYZ could cause two weeks of
rework”).
• Some things considered to be risks are not uncertain; they are facts and are therefore not risks.
• Whole categories of risks (such as technological, cultural, marketplace, etc.) are missed.
• Only one method is used to identify risks (for example, only using a checklist) rather than a combination of
methods. A combination helps ensure that more risks are identified.
• The first risk response strategy identified is selected without looking at other options and finding the best
option or combination of options.
• Risk management is not given enough attention.
• Project managers do not explain the risk management process to their team during project planning.
• Contracts are signed long before risks to the project are discussed.
12.6 Exercise
The Risk Management Process
There may be many questions about the process of risk management on the exam. The following exercise tests if
you understand what you have read. In your Exercise Notebook draw seven columns with headings of the seven
processes. Your table can be organized like the following table. Then recreate the risk management process,
including the outputs. Check your answers against our answers when you are done. You may need to repeat this
after you have iterated your risk study process. Three attempts usually ensures you know the process well enough
for the exam.
JH
Perform Perform Implement

Plan Risk Qualitative Quantitative Plan Risk Risk
Management Identify Risks Risk Analysis Risk Analysis Responses Responses Monitor Risks
Actions
Outputs
Answer
Perform Perform Implement
Plan Risk Qualitative Risk Quantitative Plan Risk Risk
Management Identify Risks Analysis Risk Analysis Responses Responses Monitor Risks
Actions
Answers the • Identify all the Qualitatively • Numerically Use risk • Implement • Respond to risk
following risks on the determine which evaluate the top response strate contingency triggers.
questions: project. risk events warrant risks. gies to decrease and fallback
a response. project threats plans (risk • Monitor residual
- How will you • Use tools such • Quantitatively risks.
and increase owner and
perform risk as brain Assess the quality determine opportunities. resources).
management on storming, root of the risk data. which risks • Create
the project? warrant a Create contin • Answer workarounds.
cause analysis,
- What risk documentation Complete a risk response. gency and fall questions and
urgency • Evaluate effective
management review, check back plans. facilitate ness of plans.
policies or lists, interviews, assessment. • Determine clarification of
SWOT anal initial reserves. Determine plan details. • Look for additional
procedures exist, Subjectively deter
ysis, assump secondary and risks; then qualify,
and what new mine the proba • Create realistic residual risks. • Communicate quantify, and plan
ones are needed? tions and bility and impact time and cost with stake responses for them
- When will the constraints of all risks. objectives. Calculate final
analysis, and holders as necessary.
processes and reserves. according to
procedures of prompt lists to Determine if you • Determine the
the plan. • Revisit the watch
risk management facilitate risk will perform probability of Determine risk
identification. quantitative risk meeting project owners (if not list.
be performed?
analysis or proceed objectives. already done). • Analyze work
- How will risks • Involve and directly to risk
be identified, engage stake Identify risk performance data
response planning. and look for
and what tools holders in the triggers.
will be used? risk manage Find ways to trends.
ment process. represent the Accept or esca
- What are late risks, where • Update plans.
stakeholders' analyzed data from
qualitative risk appropriate. • Communicate risk
roles and respon
sibilities for risk analysis. status.
management? Document the • Close risks.
How will you watch list (noncrit-
budget for risk ical risks). • Recommend
management? changes, including
Determine the corrective and
What are the overall risk ranking preventive actions.
appetites and for the project.
thresholds for • Perform risk audits
risk? and risk reviews.
Perform reserve
analysis.
515
Perform Perform
Plan Risk Qualitative Quantitative Plan Risk Implement Risk
Management Identify Risks Risk Analysis Risk Analysis Responses Responses Monitor Risks
Outputs
Risk manage Risk register Risk register Project docu Change requests Change requests • Work perfor
ment plan updates, updates, ment updates, to project manage mance
including: including: including the Updates to the ment plan, information
following updates project manage including schedule
- List of risks - Risk ranking ment plan and • Updates to the
of the project to the risk report: and cost baselines
■ Potential risk project docu risk register and
owners as compared - Assessment of ments, Updates to project other project
to other overall project including: lessons learned documents,
- List of poten projects risk exposure
tial risk - Assumptions register, including including:
responses - List of priori - Probability of the effectiveness of - Outcomes of
log
tized risks meeting risk responses and risk reviews and
Risk report with objectives - Cost forecasts recommendations
- Risks by audits
summary infor category • Interpreted - Lessons for managing
mation on risk learned register future risks - New risks
- Risks needing quantitative
details and the analysis results, - Project - Closed risks
sources of additional Updates to the
analysis and such as key schedule issue log regarding - Details of risk
overall project sources of occurrences
risk response - Project team areas of :onfusion
overall project assignments or disagreement - Lessons learned
- Watch list risk
Project docu - Risk report - Workarounds
ments updates, - Data on prob - Prioritized list Updates to the risk
such as lessons ability and of individual Updates to the report regarding: • Change requests,
learned in the impact project risks - Overall project
risk register, including recom
identification of analysis including: risk exposure mended correc
- Trends in quan
risks for the - Data on risk titative risk anal - Residual and after imple tive and
project, any urgency ysis results secondary risks menting planned preventive
issues, and new - Assumptions responses actions
or existing - Recommended - Contingency
and risk responses - Changes to
assumption and and fallback • Updates to the
constraints plans planned risk project manage
constraint analysis - Initial reserves responses
information - Risk owners ment plan and
updates in Updates to the organizational
assumptions - Triggers Updates to the risk
risk register on register, including process assets
log the specific - Final reserves data on risk
analysis for • Updates to the
- Contracts response
individual project risk report
implementations
risks - Accepted risks

The responsibilities of risk management are basically the same for both predictive and adaptive environments. But, instead
of doing all the risk management planning up front, agile teams go through risk identification and analysis and threat miti
gation or elimination during release planning and for each iteration. For the exam, make sure you have a clear understand
ing of the risk management process and what happens in each process group.
Don’t forget to review the Quicktest at the beginning of the chapter to identify any gaps in your knowledge.
The following exercise tests your understanding of threats and opportunities and the type of response, using the
library case study as an example.
516
12.7 Exercise
For each risk and response below, indicate if it is a threat or opportunity and note the type of response
being proposed.
Type of response
Threat or (mitigate, avoid,
Risk Opportunity Response enhance, etc.) Probability
1. New mayor or city council Build strong community Medium
members decide to cut spending support to decrease
likelihood.
2. A wealthy benefactor donates to Meet with potential Low
have their name on the library benefactors.
and the city council agrees.
3. Construction is delayed by Plan inside work for rainy Medium
weather and material shortages. days; set aside reserves for
expediating materials if
necessary.
4. A coffee shop could bring in Partner with a coffee shop High
more revenue than expected franchise to run the shop.
(possibly from people who are
not even using the library).
5. A community member forms a Build strong community Low
group to protest the library support.
building costs.
6. A construction worker is injured Make sure all contractor Low
on the job site and requires workers are covered by an
medical care. accident insurance policy
with medical coverage.
517
Answer
Type of response
Threat or (mitigate, avoid,
Risk Opportunity Response enhance, etc.) Probability
1. New mayor or city council Threat Build strong community Mitigate Medium
members decide to cut spending support to decrease
likelihood.
2. A wealthy benefactor donates to Opportunity Meet with potential Enhance Low
have their name on the library benefactors.
and the city council agrees.
3. Construction is delayed by Threat Plan inside work for rainy Mitigate Medium
weather and material shortages. days; set aside reserves for
expediating materials if
necessary.
4. A coffee shop could bring in Opportunity Partner with a coffee shop Share High
more revenue than expected franchise to run the shop.
(possibly from people who are
not even using the library).
5. A community member forms a Threat Build strong community Mitigate Low
group to protest the library support.
building costs.
6. A construction worker is injured Threat Make sure all contractor Transfer Low
on the job site and requires workers are covered by an
medical care. accident insurance policy
with medical coverage.
12.8 Exercise
Now let’s look at the library case study using an adaptive approach. The library software system upgrade also has
some risks. Using the adaptive approach, risks will be planned into iterations as risk spikes or tests.
Indicate the order in which the following risks should be addressed.
Risk Response or spike plan Sequence

The number of users is more A risk spike testing 10,000 concurrent users
than expected and slows the will be conducted.
performance of the software.
Software is not built with The first iteration of the software will include
adequate cybersecurity a virus scanner which will run daily to detect
protections and is hacked. potential problems.
The search capabilities in the The software will collect all terms entered
software are not adequate for into the Search box and analyze them
most patrons of the library monthly.
518
Answer
Risk Response or spike plan Sequence
The number of users is more A risk spike testing 10,000 concurrent users 2
than expected and slows the will be conducted.
performance of the software.
Software is not built with The first iteration of the software will include l
adequate cybersecurity a virus scanner which will run daily to detect
protections and is hacked. potential problems.
The search capabilities in the The software will collect all terms entered 3
software are not adequate for into the Search box and analyze them
most patrons of the library monthly.
5 IQ
520
QUICKTEST
13 Procurement • Contracts vs. agreements

• Buyers and sellers
• Procurement
Management process
• Centralized/decentralized
contracting
• Project manager’s role
• Contract types
Introduction
- Fixed-price
Many project managers have little experience in procurement, yet the exam will test your knowledge - Time and material
- Cost-reimbursable
on the procurement process and on procurement types. Even experienced project managers may stum
- Indefinite Delivery,
ble over the nuances of procurements. For example, an experienced project manager who took an
Indefinite Quantity
RMC class was upset about a situation where he had arranged a meeting with a seller and the seller had
(IDIQ)
not shown up. After he rescheduled the meeting, the seller still did not show up. When the instructor • Risk and contract type
asked what kind of contract he was working with, the student contacted his office and found out it was • Agile Contracts
a fixed-price contract. The instructor then asked where in the contract it said the seller had to attend - Graduated fixed-price
such meetings. The student determined that meetings were not listed in the contract. So, why would a - Fixed-price work
seller attend a meeting if he was not getting paid for it? packages
- Not-to-exceed time and
Think about it. What do you think the project manager’s role is in the procurement process? material
- Early termination
Think about this question as you go through the rest of this chapter. With the project
• Sharing ratio
managers role in mind, think about how the concepts presented apply to your own • Nondisclosure agreement
experience. By “imagining into reality ” those things with which you have no direct experience, • Standard contract
you will be better equipped to answer procurement questions on the exam. • Special provisions
• Terms and conditions
A project manager should have the basic procurement management skills required, including the
• Incentives
ability to help create, read, and manage contracts and any supporting documentation. If you have
• Make-or-buy analysis
worked with contracts before, you might have to fine-tune your knowledge by learning some new • Logistics and supply
terms and by understanding the project manager’s role a little better. chain management
• Source selection analysis
If you have little or no experience working with contracts, you should obtain from your
TRICKS company’s contracts, procurement, or legal department some sample contracts, requests
• Procurement SOW
OF THE • Bid documents
TRADE. for proposals, and the resulting sellers’ proposals. Spend time reviewing them. • Noncompetitive forms of
procurement
• Bidder conference
Definitions Related to Procurement Management • Seller proposal

• Proposal evaluation
Procurement • Weighting system
Simply put, procurement is a formal process to obtain goods and services. From a project manager’s • Independent cost
perspective this is the process of creating and maintaining relationships with parties (sellers) to buy estimates
products and services outside the organization. The project manager also ensures the purchased goods • Presentations
• Negotiations
or services are integrated into a project’s product.
• Selected sellers
Contracts • Closed procurements
Contracts can be written or verbal (although for the exam they should be in writing), are typically • Product validation
created with an external entity, and involve an exchange of goods or services for (usually monetary)
compensation. A contract forms the legal relationship between entities, is mutually binding, and
provides the framework for how a failure by one side will be addressed and remedied, in court
if necessary.
Agreements
The broader term “agreement” includes documents or communications that outline internal or
external relationships and their intentions. A contract is a type of agreement, but an agreement isn’t
necessarily a contract. Imagine that two divisions of a company want to combine resources to achieve
a shared objective. They would create an agreement, but likely not a contract. Examples of agreements
that are not contracts are the project charter and plan documents, internal service level agreements,
memos or letters of intent, letters of agreement, emails, and verbal agreements.
Procurement THIRTEEN
How the project manager communicates, escalates, and solves problems will vary depending on whether their actions
are governed by a contract or an internal agreement. Notifying a seller of a default on a contract term or condition should
be done through formal written communication to create a record and ensure appropriate legal action can be taken if
necessary. In comparison, failure to meet a term of an internal agreement might be handled in a conversation followed up
by an email.
Be prepared to see the terms “contract” and “agreement” on the exam. Understanding whether a situational exam
question describes an internal agreement or a contract might help you select the right answer.
In this chapter, we primarily use the term “contract,” because the procurement process is used to acquire necessary
resources that are outside the project team and involve legal documents between the buyer and seller.
Buyers and Sellers

The company or person who provides goods or services may be called a contractor, subcontractor, supplier, designer, or
seller. The PMBOK* Guide primarily uses the term “seller,” but the exam may use any of these terms. The company or
person who purchases the goods or services is called the buyer. Many companies are a buyer in one procurement and a
seller in another. For the exam, assume you are the buyer.
Procurement Management Overview

There are many Examination Content Outline (ECO) tasks that overlap with procurement. The following chart illustrates
that ECO task 8 in domain I and tasks 8 and 11 in domain II map directly to the procurement management process from
the Process Groups model. For example, part of defining project scope is to determine whether the entire scope can be
completed internally, or if part of it will be outsourced. This analysis results in make-or-buy decisions, which are directly
related to project procurements. Managing procurements is in turn essential to managing scope.
Additionally, efficient communications and stakeholder management, and the effective use of interpersonal and team
skills, along with conflict management all contribute to procurement management.

Think About It. In the ECO, domain II, task 11—Plan and manage procurement—is closely related to the
procurement management process as defined in the Process Groups model. Other tasks that closely align to
managing procurement include but are not limited to:
• Domain I (People domain), task 8: Negotiate project agreements
• Domain II (Process domain), task 8: Plan and manage scope
ECO Process Groups Model PMBOK8 Guide

Domain 1 Procurement Management Domain 2.4
Task 8 Planning
Negotiate project agreements Plan Procurement Management — Planning
Domain 2.5
Conduct Procurements — Executing Project work
Domain II Domain 2.7
Control Procurements — Monitoring
Task 8 Measurement
& Controlling
Domain 2.8
Task 11
Uncertainty
322
THIRTEEN Procurement
Take time to review the ECO and note any additional tasks that may be applicable.
Example
• Execute the project with the urgency required to deliver business value (domain II, task 1)
• Manage communications (domain II, task 2)
• Assess and manage risks (domain II, task 3)
• Support team performance (domain I, task 3)
• Address and remove impediments, obstacles, and blockers for the team (domain 1, task 7)
Can you see how procuring part of the scope of the project can support the team’s performance? Efficient
communication and stakeholder management certainly apply to procurement management. What other tasks can you
recognize as impacting procurements (or that procurements impact)? Really, any of the ECO tasks could be applicable
because as a project manager you are doing all the ECO tasks to plan and manage the project and you are procuring a part
of the project. Procurements must be integrated completely with the rest of your project. Take time with the ECO to
consider this. Doing so will help you become more familiar with the ECO and be more prepared for the exam.
When buying goods or services is part of a project s scope, the project manager facilitates the creation of a plan for
procurement. This includes a strategy for how each contract will be managed and a description of the work to be done by
each seller (a procurement statement of work). Procurement management includes planning, conducting, and controlling
procurements (which may also be summarized as planning and managing procurement), and includes negotiating and
managing contracts.
For some projects, sellers will provide the full solution, rather than just augmenting a project team with
TRICKS
OF THE additional resources.
TRADE
Example You might add contract developers to your internal staff to help code software, or alternatively
outsource all development work to an external resource who would plan and manage developers, testers, etc.
Managing procurements requires legal knowledge and negotiation skills. Project managers in most organizations are
not expected or authorized to lead in legal matters or contract negotiation. You should understand what the procurement
experts need from you, provide them with that information, and work with them throughout the project life cycle.

KA: Procurement Management
Key
approaches
c
or agile methods
Changes that cause a

FIGURE 13.1 Procurement management process
523
Desired Outcomes of Procurement Management

The Process Groups: A Practice Guide explicitly states only one direct outcome of planning and managing procurements and
that is, of course, the effective management of procurements. But there are other outcomes associated with accomplishing
this effective management.
As with all processes you should assume for the exam that procurement management has been properly planned
according to what you learn in this chapter unless a question indicates otherwise. This means the project manager has given
the following considerations in planning and managing procurements on the project:
• On each procurement itself, the contractor performs to the plan with efficient and appropriate processes.
• Procurements are planned and integrated efficiently into other project constraints, requirements, and deliverables.
• Changes related to procurement are efficiently and holistically managed with regard not only to scope but to all
project constraints, through integrated change control and written contract changes as necessary.
• Time spent planning and managing procurements are appropriate to each procurement situation.
Spend a moment reviewing figure 13.1, which shows the procurement management process from the Process Group
model perspective. This will help you to understand the procurement process in general, and where you are in the process
as you read the following sections and prepare for plan-driven exam questions.
Here’s an example of how the procurement process would work.
Example HeartCare Medical has assigned a project manager to develop an instruction manual for a medical device.
As part of the development, the instruction manual needs to be translated into ten languages. The company has never done
translations before.
• The English version of the content can be developed in-house. The project manager and team decide the translations
must be outsourced to a translation company (make-or-buy decision).
• Aprocurement statement of work (SOW) is developed and combined with contract terms to document the scope of
work and legal relationship between the buyer and the seller (or translation company in this case). These are first
known as bid documents that are later sent to prospective translation companies (sellers).
• For the SOW, the procurement department may review the scope of the work for completeness, and the project
manager might add scope related to project management activities such as specific reporting requirements or required
attendance at meetings.
• The type of bid document used is influenced by the contract type selected and the content within the procurement
SOW. As you will see later in this chapter, different types of contracts require project managers to focus on different
areas of management.
• The SOW is sent out to the translation companies (prospective sellers). They will review the bid documents, develop
a full understanding of what the buyer wants, then assess any risks and determine whether they will submit a proposal.
They may have the opportunity to participate in a bidder conference or a pre-proposal meeting, and may be able to
submit questions before the proposal deadline. All questions should be in writing and should relate to the bid
documents. Buyer responses must be shared with all translation companies to ensure that all bids will be based on the
same information.
• If the scope is incomplete or unclear, if a translation company is aware of the buyer having a history of poorly managing
projects, or if any other risks are identified, a translation company may decide not to respond, or may adjust the price
and/or schedule submitted to the buyer to account for these risks.
• Because they are working with a fixed-price contract (a fixed fee is required), the translation companies should
include these risks in the total detailed cost estimate, as well as other costs, such as overhead, and then add profit to
come up with a bid or quote. In any case, the risk of the project is formally or informally assessed before sending the
bid or proposal to the buyer.
• After HeartCare Medical (the buyer) receives competing proposals, they may shorten the candidate list or ask for
presentations from all the candidates. Once presentations are completed, a preferred translation company is selected
and negotiations take place. These negotiations require the involvement of the project manager. The procurement
SOW, terms and conditions, and other components of the bid documents are negotiable. Finally, a translation
company is selected, a contract is signed, and other procurement management artifacts are updated accordingly.
m
• Managing the procurement involves making sure the requirements of a contract are met, controlling the contract, and
making only approved changes. The procurement department helps the project manager resolve questions such as,
“What is and is not in the contract?” or “What does a particular section of the contract really mean?”
• When the procurement s work is complete and after the buyer accepts the final deliverables (the instruction manual
in ten languages), the procurement is closed as soon as possible. This can happen within any phase of the project life
cycle, as the contracted work is completed. For example, the selected translation company (seller) completes the
Spanish and French translations two months earlier than the other eight languages. If there are separate contracts per
language, the Spanish and French contracts can be closed.
• Activities to close out a procurement include an analysis of the procurement process to determine and document
lessons learned (formally called a procurement audit). Final reports are submitted and final payment is made.
Could you now describe the procurement process and relationships to someone else? Be sure you understand this
overview before continuing with the chapter.
Detailed Outcomes
The following outcomes should be assured by appropriate attention to procurement management:
• The project is planned and executed holistically with procured product and service components integrated seamlessly
into the product of the project.
• Procurement audits demonstrate that the procurement processes and procedures used on the project were
appropriate, or progress toward continuous improvements has been made including documenting what needs to be
done differently in the future.
• Project management assures that contract specifications are appropriate to the needs of the project and that sellers on
the project perform according to their contracts.
• Procurements are closed appropriately as the work of each contract is completed, verified by the seller and validated
by the buyer.
Understanding Contracts
This section covers enterprise environmental factors for managing contracts, the project manager s role, types of contracts,
and managing procurements using different types of contracts.
The Contracting Environment

For the exam, assume there is a centralized contracting environment unless otherwise stated. In a centralized contracting
environment there is one procurement department. The procurement manager reports to the head of the procurement
department and they may handle procurements on many projects. The project manager contacts the procurement manager
or department when they need help or to ask questions and knows what authority the procurement manager has in
each situation.
In a decentralized contracting environment, there is no procurement department or procurement manager assigned.
The project manager may be responsible not only for planning and managing procurement but also for conducting all work
on procurements. There may be little standardization of procurement processes and contract language without a
procurement department to regulate standards and improve knowledge in procurement management.
Whether contracting is centralized or decentralized, the project manager is responsible for knowing their required
level of involvement. Use the scenario described in the exam question to determine how involved the project manager
should be.
The Project Manager’s Role in Procurement

You might ask yourself, “If there is a procurement manager, why would a project manager need to be involved in
procurements?” This is an important question, and you must fully understand the answer before you take the exam. Here
are a few tricks to help you.
325
Remember that it is the project manager’s project. The project manager must be fully informed and apply their
expertise for the organization to fully realize the project’s benefits. This trick is important for all processes and
typically a large percentage of the questions on the exam focus on testing whether you know what you
should do.
Here is a quick summary. Do not memorize it; instead, make sure you understand it.
• Know the procurement process so you understand what will happen when and can make the necessary plans.
• Make sure the contract includes all the scope of work and project management requirements, such as attendance
at meetings, reports, actions, and communications deemed necessary to minimize problems and
miscommunications with the seller(s).
• Incorporate allocation and mitigation of risks into the contract to decrease risk.
• Help tailor the contract to the unique needs of the project.
• Ensure sellers have the right information and are set up for success.
• Estimate the time and cost of each procurement, including what is required to complete the process. Include these
estimates in the project schedule and budget.
• Be involved during contract negotiations to protect the relationship with the seller and promote the best interests
of the project.
• Define quality requirements for and check the quality of goods and services from sellers.
• Remove impediments by making sure the procurement process goes as smoothly as possible, investigating any
issues and taking corrective action.
• Understand what contract terms and conditions mean so you can read and understand contracts.
• Beyond the technical scope, ensure all the work in the contract is done, such as reporting legal deliverables,
including the release of liens and ownership of materials.
• Make a formal contract change for anything that is not in the contract.
• Work with the procurement department to manage contract changes.
Project managers should be assigned on both the buyers and sellers sides before a contract is signed! Many
TRICKS
OF THE companies that sell their services make a huge but common mistake by not involving the project manager in
TRADE the bidding and proposal process. Instead, only marketing and sales are involved until after the contract is
signed. The project manager is then handed a project with a contract that may include unrealistic constraints.
The project starts out in trouble.
Involving the project manager early in the procurement process is so important that the exam will test you to see if
you know when the project manager should be involved and why. The project manager and qualified team members are
often uniquely capable of getting answers to many of the technical and project management questions that arise during
bidding processes. If the sellers’ questions are answered incorrectly or incompletely, there may be an inadvertent change
to a specification or the scope of the contract that was never intended by the buyer.
526
Contract Types
Many different types of contracts can be used to acquire goods and services. Boilerplate contracts or agreements used
within an organization are organizational process assets. The procurement manager selects the contract type for each
procurement based on the following considerations:
• What is being purchased (a product or a service)
• The completeness of the statement of work
• The level of effort and expertise the buyer can devote to managing the seller
• Whether the buyer wants to offer the seller incentives
• The marketplace or economy
• Industry standards for the type of contract used
Although the buyer initially proposes the contract type, the final contract type is subject to negotiation with the seller.
The best contract type meets the needs of the procurement, results in reasonable seller risk, and provides the seller with
the greatest incentive for efficient performance.
The three broad categories of contracts are:
• Fixed-price (FP) • Time and material (T&M) • Cost-reimbursable (CR)
Note: Be sure to read about sub-types of contracts within these three broad categories in the free
article “Contract Types Subcategories,” on the RMC Resources web page (www.rmcls.com/
https://rmcls.com/rmc-re
rmc-resources).
Situational questions on the exam may require you to recognize that the project managers
responsibilities and actions will vary depending on the type of contract being used. There may also be
questions that require you to pick the most appropriate contract type based on a particular situation.
RMC RESOURCES
Carefully think through this section!
Fixed-Price Contract (FP)
A fixed-price contract should be used for acquiring goods, products, or services with well-defined requirements or
specifications. In general, with a fixed-price contract, a clearly defined SOW along with competing bids mean you’re likely
to get a fair and reasonable price. This is one of the most common contract types used, though it’s more likely to be used in
construction than in something like information technology.
If the costs are more than the agreed-upon amount, the seller must bear additional costs. Therefore, the buyer has the
least cost risk in this type of contract because the scope is well-defined. Note, however, that when fixed-price contracts are
entered into and the SOW is not sufficiently detailed, claims and disputes over what is in and out of the contract create
higher risk of cost overruns or delay.
The seller is most concerned with the procurement SOW in a fixed-price contract, since this will help them more
accurately estimate time and cost for the work involved and determine a price that includes a fair and reasonable profit. The
amount of profit is not disclosed to the buyer.
For the exam, be aware that even though the buyer may prefer a fixed-price contract to control costs, it is not always
the best choice, and in some cases, it may be inappropriate. Sellers in some industries may not have the detailed accounting
records of past project activities required to accurately estimate future projects. Buyers may not have the expertise to
prepare the clear and complete procurement SOW required for a fixed-price contract.
Because many buyers are not knowledgeable about contracts, they often ask the seller to provide a fixed price even
when the scope of work is not complete and accurate. Think about the following disadvantages if the procurement SOW is
not adequate for the seller to make a reasonable estimate:
• The seller is forced to accept a high level of risk.
• The seller needs to add significant reserves to their price to cover risk; therefore, the buyer pays more than they
otherwise might have.
• The seller can more easily try to increase profits by cutting scope or claiming that work the buyer wants is outside the
contract and thus requires a change order, and the buyer will not be able to state with certainty if it is within the scope
of work or needs a change order. If the seller realizes they will not be able to make a profit they may try to take their
best people off the project, cut out work that is specifically mentioned in the contract, cut out work that is not
mentioned in the contract but is needed, decrease quality, or take other actions to save money.
327
Fixed-price (FP) In a FP contract, a fixed total price is set Example: Fixed-Price Contract
for the project, all requirements have been clearly described, Contract = $1,100,000.
and changes to scope should not occur.
Purchase Order A purchase order is the simplest type of

Example: Purchase Order
fixed-price contract. This type of contract is normally
unilateral (signed by one party) instead of bilateral (signed by Contract = 30 linear meters of wood at
both parties). However, some buyers require the seller’s $9 per meter.
signature on a purchase order before considering it official. In
that case, the signature forms the acceptance needed for
a contract.
Note: A purchase order is usually used for simple commodity procurements. They become contracts when the buyer
accepts the terms. The seller then performs or delivers according to those terms (for example, equipment or products).
Time and Material (T&M)

In this type of contract, the buyer pays on a per-hour or per-item basis. These contracts are frequently used for service
efforts in which the level of effort cannot be defined when the contract is awarded. It has elements of a fixed-price contract
(in the fixed price per hour) and a cost-reimbursable contract (in the material costs and the fact that the total cost is
unknown). Compared to other types of contracts, time and material contracts typically have terms and conditions that are
simpler to allow for quick negotiations so that work can begin sooner.
If you were going to have to pay someone on a contract basis for every hour they worked, no matter how productive
they were and no matter what they were doing, would you want to do this for a long period of time? Remember, the seller’s
profit is built into the rate, so they have no incentive to get the work done quickly or efficiently. For this reason, a time and
material contract is best used for work valued at small dollar amounts and lasting a short amount of time. Knowing when
it’s best to use time and material contracts can help you get situational questions right on the exam.
To make sure the costs do not become higher than
Example: Time and Material Contract
budgeted, the buyer may add a “Not to Exceed” clause to the
contract and thus limit the total amount they are required to Contract = $100 per hour plus expenses
pay. With a time and material contract, the buyer has a or materials at cost.
medium amount of cost risk as compared to cost-reimbursable Or
Contract = $100 per hour plus materials
and fixed-price contracts.
at $5 per linear meter of wood.
Cost-reimbursable (CR)
A cost-reimbursable contract is used when the exact scope of work is uncertain and, therefore, costs cannot be estimated
accurately enough to effectively use a fixed-price contract. This type of contract provides for the buyer to pay the seller
allowable incurred costs to the extent prescribed in the contract. Such contracts also typically include an additional fee or
award amount added to the cost to allow for seller profit.
A cost-reimbursable contract requires the seller to have an accounting system that can track costs by project. With a
cost-reimbursable contract, the buyer has the most cost risk because the total costs are unknown. The seller provides an
estimate to the buyer; the buyer can use the estimate for planning and cost management purposes, but it is not binding.
What is binding is the buyer’s responsibility to compensate the seller for legitimate costs for work and materials as described
in the contract. Research and development or information technology projects in which the scope is unknown are typical
examples of cost-reimbursable contracts.
Types of cost-reimbursable contracts include cost, cost plus fixed fee, cost plus incentive fee, cost
plus award fee, cost plus fee, and cost plus percentage of costs. Here is one of the most common cost- https://rmcls.com/
reimbursable contracts. You can read about the others at the RMC Resources page at rmcls.com/
rmc-resources.
RMC RESOURCES
328
Cost Contract A cost contract is one in which the seller

Example: Cost Contract
receives no fee (profit). It is appropriate for work performed
Contract = Cost for work and materials.
by nonprofit organizations.
There is no profit. The seller is reimbursed
but does not make a profit.
Indefinite Delivery, Indefinite Quantity (IDIQ) Contract

This type of contact provides for an indefinite number of goods and services within a fixed time frame and within a certain
cost range. For example, an architect may be hired for a period of one year to be available for any issues that arise as an office
building is being built. The amount of service needed is undefined, but the contact length is set. Even if no services are
needed, the seller will be paid the minimum amount stated in the contract. This contract type is used most often in
engineering or information technology.
The risk on this type of contract is equally split. If the
Example: Indefinite Delivery Indefinite Quantity
sellers goods or services are not needed in the allotted
timeframe, then the buyer accepts the risk (they have to pay Contract = One-year contract for a minimum of
out the minimum amount anyway). If the seller provides $ 10,000 and a maximum of $ 18,000.
more goods and services than anticipated, they will accept
the risk since their fee is capped.
Risk and Contract Type

Here is an overview of who takes on risk for the contract types.
• Fixed-price contract The seller takes on most or all the risk.
• Cost-based contract The buyer is assuming the risk in this type of contract.
• Time and material contract Risk is shared between the seller and buyer.
Advantages and Disadvantages of Each Contract Type

Do you understand what you just read? Can you answer the following questions?
• You do not have a finalized scope. Which contract type is best?
• You do not have a complete scope of work, but you have a fixed-price contract. What problems can you expect to
run into?
13.1 Exercise
In your Exercise Notebook, write the advantages and disadvantages of each form of contract from the perspective
of the buyer. The forms are:
• Fixed-price
• Time and Material
• Cost-reimbursable
Answer
There can be more answers than listed here. Did you identify and understand these?
Fixed Price Contract

— This requires less work for the buyer to manage. — If the seller underprices the work, they may try to
make up profits by charging more than is necessary
— The seller has a strong incentive to control costs.
on change orders.
— Companies usually have experience with this type
— The seller may try to not complete some of the
of contract.
procurement statement of work if they begin to
— The buyer knows the total price before the lose money.
work begins.
- This contract type requires more work for the buyer
to write the procurement statement of work.
- This can be more expensive than a cost reimbursable
contract if the procurement statement of work is
incomplete. The seller also needs to add to the price
of this contract to account for the increased risk.
Time and Material Contract

- This type of contract can be created quickly because — There is profit for the seller in every hour or
the statement of work may be less detailed. unit billed.
- The contract duration is brief. — The seller has no incentive to control costs.
- This is a good choice when you are contracting — This contract type is appropriate only for work
people to augment your staff. involving a small level of effort.
— This contract type requires a great deal of day-to-day
oversight from the buyer.
Cost-Reimburseable Contract
— This contract type allows for a simpler procurement
— This contract type requires auditing the sell
statement of work. er s invoices.
— This contract type usually requires less work to — This contract type requires more work for the buyer
define the scope than a fixed-price contract. to manage.
- This is generally less costly than a fixed-price contract - The seller has only a moderate incentive to
because the seller does not have to add as much control costs.
for risk.
- The total price is unknown.
330
A trick for the exam is to realize that buyers must select the appropriate type of contract for what they are
TRICKS
OF THE buying.
TRADE. Remembering the following general rules for situational questions involving contracts can help you get
more questions right on the exam.
• Contracts require formality. Correspondence, clarification, and notifications related to contracts should be formal
written communication. If issues develop requiring arbitration, mediation, or litigation, formal written
communications are more enforceable and supportable than are verbal communications.
• All product and project management requirements for procurement work should be specifically stated in
the contract.
• If it is not in the contract a formal change order to the contract is needed for the work to be done.
• If it is in the contract it must be done or a formal contract change order to remove it is needed.
• Change requests to contracts must be submitted in writing.
• Contracts are legally binding; the seller must perform as agreed in the contract or they are in breach of contract.
• Contracts should help diminish project risk.
• Most governments back contracts within their jurisdiction through a court system for dispute resolution.
Agile Procurement and Contracts

Procurement on agile projects is additionally challenging since scope is emerging. It may be difficult to
sufficiently determine requirements up front for many contractors proposing for the work. The agile manifesto
promotes “customer collaboration over contract negotiation” (see “Agile Methodologies” chapter). So agile
contracting is built on relationships and ensuring that contracts are fair and equal. However, that doesn’t
mean that a handshake is enough; the traditional fixed-price contract especially has its limits for an agile project. Here are
a few example contracts tailored to agile:
• Graduated fixed-price This contract has a fixed price based on completion by a certain date. If the work is completed
before the target date, the seller is paid a higher fee, basically the fixed price plus a bonus. If the work is completed after
the target date, the seller is paid at a fee lower than the fixed price. This incentivizes early delivery.
• Fixed-price work packages The contract can be paid in increments when work packages are delivered, rather than
paid as one lump sum at the end of the contract.
• Not-to-exceed time and material This is a time and materials contract that has a ceiling price for the work. It
cannot go over this amount.
• Early termination This allows the buyer to cancel the contract early, for a cancellation fee, if it is discovered they no
longer need the deliverable from the seller.
On agile projects it is ideal to partner with a seller who also operates agile teams, because the contractor will
understand the project better and be better able to deliver iteratively and incrementally if that is what is needed from them.
They will at least understand the way the project will operate. In any case, project managers on agile projects should
promote agile principles and practices to the extent possible with partners providing goods or services. When working
with an agile contract, sellers may be involved in providing feedback on increment deliverables, prioritizing the backlog,
and ranking the value of change requests on work.
That said, many lessons from the Process Groups model for procurement can be used in agile environments. A
contract professional, like a lawyer or contract officer within the organization should be involved in contracting, for
example. In agile and predictive environments alike, organizations usually have strict policies and procedures related to
contracts. In a hybrid environment, there can be a master contract for most of the contracted work and a supplement for
any adaptive parts of the contract. This allows the flexibility needed for the adaptive work packages.
551
Additional Contracting Terms to Know

Here are some contracting terms you might see on the exam. You can find more contracting terms https://rmcls.com/rm
that are good for a project manager to know on the RMC Resources page at rmcls.com/rmc-resources.
• Sharing ratio Incentives are usually expressed as a ratio, such as 80/20. This sharing ratio
describes how the cost savings or cost overrun will be shared; the first number represents the
buyer portion and the second number represents the seller portion (buyer/seller).
• Nondisclosure agreement For many procurements, there is a great need for confidentiality. rmc RESOURCES
Such a written agreement between the buyer and prospective sellers identifies the information
or documents they will control and hold confidential; it also details who in the organization will have access to the
confidential information. With a nondisclosure agreement in place, the buyer can talk more openly about their needs
without fear that the public or one of the buyer’s competitors will gain access to the information.
• Standard contract Commonly created by the buyer, standard contracts are usually drafted—or at least reviewed—
by lawyers and generally do not require additional review if used for the purpose for which they were intended. You
should understand standard contracts, but also realize the project manager’s role in special provisions (described
next).
• Special provisions (special conditions) The project manager must understand standard terms and conditions but
also determine when additions, changes, or deletions from the standard provisions are required. By facilitating
necessary adjustments, the project manager can make sure the resulting contract addresses the needs of the project.
The project manager (remember when taking the exam that you are the buyer’s project manager, unless a question
states otherwise) meets with the procurement manager (if there is one) to discuss the needs of the project and to
determine the final contract terms and conditions.
Additions, changes, or deletions are sometimes called special provisions and can simply pertain to the type of
project and project requirements, risk analysis and administrative, legal, or business needs.
• Privity This simply means a contractual relationship. The following explains privity and shows how questions on
this topic may be asked.
Question:
Think About It. Company A hires company B to do some work. Company B subcontracts to company C. The
project manager for company A is at the job site and tells company C to stop work. Generally, does company C
have to listen?
Answer:
No. Companies C and A have no contractual relationship. Company A needs to talk to company B, who needs to talk
to company C.
Can you see how this would be important to understand? Any directive that the project manager from company A
may give to company C can cause liability for company A. For example, company A may have to pay delay claims to
company B, plus the costs of delay to company C if company C stopped work at company As direction.
Terms and Conditions

There are many terms and conditions associated with procurements that may be considered. Let’s start out with a story to
better understand some of these terms and conditions.
Think About It. A project manager (the buyer) needed their team members trained on some equipment. They
contacted a seller to do the work and then had their procurement department send the seller a contract.
Meanwhile, the project manager arranged for team members to travel for the training. There were terms and
conditions in the contract that said the buyer would have rights to create derivative works and copy handouts
from class. The handouts were proprietary and already copyrighted. The seller could not and would not sign the
contract. The class had to be cancelled when many people were already on planes to attend the training.
Whose fault was this? The project manager should have made sure the procurement department understood what
they were buying and also should have looked at the contract before it was sent to make sure its language was accurate.
352
Creating a contract requires the involvement of both the project manager and the procurement manager. Do you
work with a procurement manager to review contracts on your projects?
The following are categories of terms and conditions that can make up standard or special provisions. You can find
more of these on the RMC Resources page at rmcls.com/rmc-resources. Be familiar with these concepts and what impacts
they would have on a contract. The exam will often simply use these terms in sentences such as, “There was a force majeure,”
and you’ll need to understand what that means (force of nature, like a flood or a fire). Conversely, you need to know that
“There was a flood that made the seller unable to perform,” describes a force majeure.
• Assignment This refers to the circumstances under which one party can assign its rights or obligations under the
contract to another.
• Breach/default This occurs when any obligation of the contract is not met. Watch out—a breach on the seller’s part
cannot be fixed by a breach on the buyer s part. For example, failure to complete an item in the procurement statement
of work (seller’s breach) cannot be handled by the buyer stopping all payments (buyer’s breach).
A breach is an extremely serious event. The exam may present situations in which seemingly little things in the
contract are not done. The response to a breach must always be to issue a letter formally notifying the other party of
the breach. The project manager must understand the legal impheations of their actions. If they do not watch out for
and send an official notice of breach, the project managers company could lose its right to claim breach later.
• Force majeure This refers to a situation that could be considered an “act of nature,” such as a fire or freak electrical
storm, and it is an allowable excuse for either party not meeting contract requirements. If a force majeure occurs, it is
considered to be neither party’s fault. It is usually resolved by the seller receiving an extension of time on the project.
Who pays for the cost of the items destroyed in a fire or other force majeure? Usually the risk of loss is borne by the
seller and is hopefully covered by insurance. (See also “Risk of loss” below.)
• Indemnification (liability) Who is Hable for personal injury, damage, or accidents?
• Intellectual property Who owns the intellectual property (for example: patents, trademarks, copyrights, processes,
source code, or books) used in connection with or developed as part of the contract? This may include warranties of
the right to use certain intellectual property in performance of the contract.
• Management requirements Examples of management requirements include attendance at meetings and approval
of staff assigned to the project.
• Material breach This breach is so large that it may not be possible to complete the work under the contract.
• Retainage This is an amount of money, usually 5 percent or 10 percent, withheld from each payment. This money is
paid when the final work is complete. It helps ensure completion.
• Risk of loss This allocates the risk between the parties to a contract in the event goods or services are lost or
destroyed during the performance of a contract.
• Waivers These are statements saying that rights under the contract may not be waived or modified other than by
express agreement of the parties. A project manager must realize that they can intentionally or unintentionally give up
a right in the contract through conduct, inadvertent failure to enforce, or lack of oversight. Therefore, a project
manager must understand and enforce all aspects of the contract, even if a procurement manager is involved in
administering the contract.
Incentives
Sellers are usually focused on the profits, while buyers are focused on cost, performance, schedule, or a combination of
these. Incentives are used to bring the seller’s objectives in line with the buyer’s and to motivate the seller towards efficiency.
Think of an incentive as a bonus for the seller. The buyer will provide an additional fee if the seller meets some cost,
performance, or schedule objectives.
Can you see how incentives can change the focus of the seller’s work? If there is an incentive for cost savings, then the
work is to complete the project and to look for cost savings. If the incentive is for some increased level of performance (for
example, the system can handle more capacity than contracted for), then the work is to complete the project and to look
for ways to increase performance. The seller gains profit from both activities.
Ill
13.2 Exercise
Answer the following questions for each of the contract types (cost-reimbursable, time and material, and fixed-
price). Write the answers in your Exercise Notebook. (This is the most challenging exercise in this chapter. The
questions are meant to be very difficult in order to further test your knowledge.)
Question
1. Generally, what is being bought? (Product or service)

2. How might the costs to the buyer be stated in the contract?
3. How might the profit be stated in the contract?
4. What is the cost risk to the buyer? (High, medium, low, none)
5. How important is a detailed procurement statement of work? (High, medium, low, none)
6. What industry uses this contract type most frequently?
7. How much negotiation is usually required to sign the contract after receipt of the sellers price? (High,
medium, low, none)
8. What level of effort and expertise will the buyer need to devote to managing the seller? (High, medium,
low, none)
9. How are costs billed to the buyer?
10. How much auditing of the sellers costs will the buyer need to do? (High, medium, low, none)
Answer
Compare the answers in the following table to your answers.
Cost- Reimbursable Time and Material Fixed-Price
1. Service (some products may be Service Product

included)
2. Costs are variable, but the fee/ Hourly rate or price per unit As a set currency amount
profit is fixed (as a set amount or a (e.g., $ 1 million)
percentage)
3. Listed separately, and known to Included in the hourly rate, and Included in the price, and
the buyer may be unknown to the buyer unknown to the buyer
4. High; increases in costs are Medium; although the costs are Low; increases in costs are borne
reimbursed by the buyer not fixed, they are known per by the seller
unit, and this contract type is
used for small purchases for a
limited time
5. Low; the procurement statement Low; this type traditionally has High; the procurement statement
of work only needs to describe very little scope, and may only of work must be complete so the
the performance or functional describe skill sets required seller knows exactly what work
requirements, since the seller needs to be done in order to come
provides the expertise on how to up with an accurate price to
do the work; the buyer pays all complete the work
costs, so there is less need to
finalize the scope
Cost- Reimbursable Time and Material Fixed-Price
IT, research and development,

and knowledge work; when the
When hiring people for an hourly
work has never been done before Complete scope of work is most
rate, you are usually hiring
6. (as is often the case in these common in the construction
services, such as legal, plumbing,
industries), the seller cannot fix a industry
or programming
price; therefore, this is the best
form to use
High; all estimated costs are
7. looked at to calculate the fee to Low or none None
be paid
8. High Medium Low
Actual costs as incurred; profit at Fixed price (which includes
project completion, or Hourly or per unit rate (which profit) according to a payment
9.
apportioned as allowed in the includes all costs and profit) schedule as work is completed
contract and as allowed in the contract
Low; since the overall contract
None; there may be an audit of
High; all costs must be audited, costs are fixed, auditing usually
work hours completed against
10. and there will be a large number focuses on making sure work is
those billed, but that will take
of invoices completed, not looking at
little effort
detailed costs and receipts
Plan Procurements
The Plan Procurement Management process answers these questions: “How Process Groups Model
will make-or-buy analysis be performed?” “What goods and services do we PG: Planning
need to buy for this project?” “How will we purchase them?” “Who are poten- Process: Plan Procurement Management
tial sellers to consider?”
Planning involves putting together the bid documents that will be sent ECO
to prospective sellers describing the buyers need, how to respond, and the Domain II
Task 11 Plan & manage procurement
criteria the buyer will use to select a seller. Planning the procurement process
includes the following:
PMBOK* Guide
• Performing make-or-buy analysis Domain 2.4 Planning
• Creating a procurement management plan Domain 2.5 Project Work
• Creating a procurement strategy for each procurement

• Creating a procurement statement of work for each procurement
• Selecting the appropriate contract type for each procurement
• Creating the bid documents
• Determining the source selection criteria
What are the things you need to plan for procurements? When planning procurement management, it is important to
consider business documents like the benefits management plan and the business case. You also need the project charter;
components of the project management plan like the scope and schedule baselines and scope, quality, and resource
planning documents; project documents; and any relevant enterprise environmental factors and organizational
process assets.
555
The project charter provides any preapproved financial resources, while other project documents provide
the following:
• Milestone list • Resource requirements
• Project team assignments • Risk register
• Requirements documentation (including a • Stakeholder register
requirements traceability matrix) • Procurements already in place
Enterprise environmental factors for procurement include marketplace conditions, the services that are available to
be purchased, and the existing culture and structures surrounding the organization’s approach to procurements. Relevant
organizational process assets can include procurement procedures and documents, standard contract types used by the
organization, statement of work templates, lessons learned from past procurements and projects. A preapproved (or
prequalified) seller list and master service agreements, if they exist, are also useful.
A preapproved seller list speeds up the process by helping ensure the sellers’ qualifications are well researched. The
procurement documents are sent only to the preapproved sellers. Master service agreements are contracts between two
parties including standard terms that will govern future transactions—a time-saving approach when a buyer frequently
works with the same seller because overall terms of working together are already agreed to and signed by both buyer
and seller.
Methods for Planning Procurement Management

Make-or-Buy Analysis
During planning, you must decide whether the scope and work of the project will be completed within the organization or
if some of it will be outsourced. It’s important to ask questions such as, “How are resources currently distributed?” and
“What are the capabilities of our resources?” Make-or-buy analysis is done early in the planning phase of the project, and
results in a make-or-buy decision.
Logistics and Supply Chain Management

An important consideration in make-or-buy analysis is the required lead time for materials and equipment to be purchased.
Specialty items, custom products, and items ordered internationally will take more time, which must be built into the
project schedule.
Economic Measures
Economic measures similar to those used in project selection and defined in the “Project Management Foundations”
chapter may support make-or-buy decisions. Examples include payback period, ROI, IRR, discounted cash flow, and NPV.
Expect to see questions on the exam that refer to make-or-buy analysis, or even questions that require you to calculate
buy-or-lease situations, like the following question.
Think About It. You are trying to decide whether to lease or buy an item. The daily lease cost is $ 120. To purchase
the item, the investment cost is $ 1,000; the daily maintenance cost is $20. How long will it take for the lease cost
to equal the purchase cost?
Answer:
Let D equal the number of days when the purchase and lease costs are equal.
$120D = $1,000 + $20D
$120D-$20D = $1,000
$100D = $1,000
D = 10
The calculation says that the costs are the same after 10 days. Therefore, if you are planning to use the item for fewer
than 10 days, you should lease. Otherwise it would be cheaper to buy the item.
lib
Source Selection Analysis

Project constraints are factors in seller (or source) selection. For example, is schedule the most important criteria or is cost
the critical factor? You may want to review the project constraints in the “Project Management Foundations” chapter.
Other source selection criteria are used and, as in project constraints, some are often weighed more heavily over
others. If the buyer is purchasing a commodity, such as linear meters of wood, the source selection criteria may just be the
lowest price. If the buyer is procuring construction services, the source selection criteria may be price plus experience. If
the buyer is purchasing services, the source selection analysis criteria may include:
• Number of years in business • Technical expertise
• Financial stability • Quality of past performance
• Understanding of need • Ability to complete the work on time
• Price or life cycle cost
If the organization has a preferred seller list, or a master services agreement with an outside source, that information
is also considered when analyzing source selection options.
Artifacts of Plan Procurement

The artifacts of planning for procurement include a procurement management plan. This plan documents or references
governance for procurements. It provides guidelines and available tools for make-or-buy and source selection analyses,
phase and transition management, and tailoring considerations.
Conducting and controlling procurements are supported by planning, so these aspects are also covered in the plan.
Rules and guidelines for procurement roles and responsibilities, bidder conferences, and negotiations are included. The
control portion of the plan indicates how contract requirements will be managed, and it provides metrics and information
on when and how measurements will be taken, guidelines for resolving disputes, the process for accepting deliverables, and
the payments to be made.
Make-or-buy decisions come out of the make-or-buy analysis, as does the procurement strategy. This strategy has
three basic elements:
• How goods or services will be delivered to the buyer (for example, will the procurement include subcontractors or an
outside service provider)
• Contract selection (for example, will the contract be fixed-price or cost plus; will it include incentives or award fees)
• How the procurement will be carried out for each phase.
Other artifacts of planning procurement include the:

• Procurement statement of work (SOW) • Independent cost estimates
• Source selection criteria • Selected types of bid documents
For independent cost estimates the buyer prepares an internal estimate, often using expert judgment to get a
benchmark against which to validate the bids received from prospective sellers. The procurement SOW and bid documents
were introduced earlier but let’s look at them in further detail.
Procurement Statement of Work (SOW)

The complete scope of a procurement is described in a procurement SOW. The project manager uses the same skills for the
same outcomes that are expected from the work on the project s scope baseline, since each procurement represents a part
of the overall project scope.
Each SOW must be as clear, complete, and concise as possible, yet it must describe all the work and activities the
seller is required to complete. This includes all meetings, reports, and communications. It must also detail the acceptance
criteria and the process of gaining acceptance. The cost of adding activities later is typically more than the cost of adding
them at the beginning of the procurement. Does this make you think about the work required to create a complete
procurement SOW?
Remember that the level of detail required for the SOW will influence the selection of the contract type and the
creation of the bid documents. It may include drawings, specifications, and technical and descriptive wording.
JJ7
What does “complete scope of procurement” mean? It depends on what you are buying. Here are some examples:
• Expertise (e.g., software design or legal services) The procurement SOW includes functional and/or
performance requirements, a timeline, evaluation criteria, and required meetings, reports, and communications.
• The construction of a building Specific requirements, outlining things such as the materials to be used, the process
that must be followed, and work schedule.
• Augmenting staff The project manager will direct these human resources so will need details of what the person
will be assigned to create or achieve.
Note: If the procurement is for services rather than products, the procurement SOW may be referred to as terms of
reference (TOR). It includes the work the seller will perform, standards the seller is expected to achieve, and the data and
services that will be provided to the buyer.
The procurement statement of work may be revised during contract negotiation, but it should be finalized by the time
the contract is signed as it is part of the contract. If the procurement SOW is not complete, the seller may frequently need
to request clarification or ask for change orders, which can get expensive, and the project manager and/or the procurement
manager may find themselves constantly dealing with questions about whether a specific piece of work is included in the
original cost or time estimates.
Think about change orders in the context of the procurement strategy and the project plan. In general, contract
change orders cost money or cause delay. Bad procurement SOWs can result in overspending and delayed or failed projects.
Bid Documents
After the contract type is selected and the procurement statement of work has been created, the buyer can put together the
bid document, which describes the buyer’s needs to sellers. The following are types of bid documents.
• Request for proposal (RFP) An RFP (sometimes called a request for tender) requests a detailed proposal that
includes information on price, how the work will be accomplished, who will do it (along with resumes, in some
cases), and company experience.
• Invitation for bid (1FB) An IFB, sometimes called a request for bid (RFB), usually requests a total price to do all
the work. Think of an IFB as a form of RFP where the work described in the procurement statement of work is
detailed enough for bidders to determine a total price.
• Request for quotation (RFQ) RFQs request a price quote per item, hour, meter, or other unit of measure.
• Request for information (RFI) An RFI might be used before bid documents are created. Responses to the RFI
help the buyer identify which companies are qualified to handle the procurement. Buyers can also use RFIs to collect
information on what work is possible, for later inclusion in RFPs or IFBs. Remember that the purpose of an RFI is to
get information, whereas the purpose of an RFP or RFQjs to buy something.
To provide the seller with as clear a picture as possible of what needs to be done to win the work and what the work
involves, bid documents may include the following information for sellers:
• Background information about why the buyer wants the work done
• Procedures for trying to win the work (such as whether there will be a bidder conference, when the responses are due,
and how the winner will be selected)
• Guidelines for preparing the response (such as maximum length and topics to address in the response)
• The exact format the response should be in (such as which forms must be filled out and whether email submissions
are allowed)
• Source selection criteria—the criteria the buyer will use to evaluate responses from the sellers (such as number of
years in business, quality of the response, or price)
• Pricing forms (forms to adequately describe the price to the buyer)
• Procurement statement of work
• Proposed terms and conditions of the contract (legal and business)
338
Think About It. Proposed contracts are included in the procurement documents. Do you know why? The
terms and conditions of the contract represent work that needs to be done, and there are costs associated
with that work, including warranties, ownership, indemnification, and insurance requirements. The seller
must be aware of all the work that needs to be completed to adequately understand and price the project.
Well-designed bid documents can have the following effects on a project:
• Easier comparison of sellers’ responses
• More complete responses
• More accurate pricing
• Decreased number of changes to the project
Sellers may make suggestions for changes to the procurement documents, including the procurement SOW and the
project management requirements included in the documents, before the contract is signed. When approved, these
changes are issued by the buyer as addenda to the bid documents and will ultimately become part of the final contract.
Noncompetitive Forms of Procurement

Public organizations are generally required by law to follow certain practices regarding competitive procurements and to
select a seller in a certain way. Although they might have internal policies to follow, private companies may bypass
competitive procurement by using master service agreements or preferred seller lists, in which case they could simply issue
a purchase order to obtain goods or services from an approved or preferred seller.
If the project manager does not use a competitive process, they enter one of the following types of
noncompetitive procurements:
• Sole source In this type of procurement, there is only one seller who can provide the goods or services. They may
own a particular patent.
• Single source Here, the project manager contracts directly with the preferred seller without going through the full
procurement process. The project manager may have worked with this company before, and, for various reasons, they
do not want to look for another seller. In some cases, there may be a master service agreement in place between an
organization and this seller: an established, ongoing contract.
Other reasons for working with a company as a single source are:

• The project is under extreme schedule pressure.
• A seller has unique qualifications.
• Other mechanisms exist to ensure the seller’s prices are reasonable.
• The procurement is for a small amount of money.
If the project manager is entering a noncompetitive procurement, they may save time by eliminating part of the
process that comes before bidding but will still have to negotiate to finalize the contract.
Once the make-or-buy analysis and procurement strategy are complete, the contract type has been selected, and a
statement of work and bid documents are completed, the project manager is prepared to engage with prospective sellers.
The bid documents and supporting documentation are sent, the project manager answers the sellers’ questions, possibly
holds a bidder conference, and evaluates sellers’ responses. The project manager selects a seller using source selection
criteria and then negotiates a contract.
359
Conduct Procurements
Managing procurements includes carrying out the final strategy for finding a Process Groups Model
seller and negotiating and finalizing a contract with them. Information from PG: Executing
the project management plan, including to-date baselines and other planning Process: Conduct Procurements
documentation, will assist in this process with prospective sellers and in mak
ing a final decision for each procurement. Because the process to finalize pro ECO
curements is ongoing throughout the project, you and the team may be able Domain I
to make use of lessons learned from prior procurements on the current proj Task 8 Negotiate project agreements
Domain II
ect or previous projects, which can provide insight into the organizations ex
Task 11 Plan & manage procurement
periences with sellers. This information can often streamline the process con
siderably. PMBOK8 Guide
Methods for Conduct Procurements
You may use tools and techniques such as advertising to find possible sellers
or may send the bid documents to a select list of sellers preapproved by the
organization (an organizational process asset). The organization may already have an existing agreement with a particular
seller. In this case, you could work with that seller to negotiate terms to add new work to the contract.
Note: The US government and many state and local agencies are required to advertise most of their procurements.
Bidder Conference
For a bidder conference the buyers side carefully controls communications with prospective sellers to ensure legal
integrity, fairness, and consistency in the process. All prospective sellers’ questions are documented and sent to all
prospective bidders—along with subsequent responses—to make sure everyone has the same information.
Getting answers to questions can be important because many bid documents will include a provision saying that by
submitting a bid or proposal, the seller warrants the bid covers all the work. The bidder conference is also an opportunity
for the buyer to discover anything missing in the bid documents.
A bidder conference can be key to making sure the pricing in the seller s response matches the work that needs to be
done and is, therefore, the lowest price. Bidder conferences benefit both the buyer and seller. It is a good practice for the
project manager to attend the bidder conference. The exam often asks what things the project manager must watch out for
in a bidder conference. The answers include:
• Collusion
• Sellers not asking questions in front of the competition
• Making sure all questions and answers are put in writing and issued to all potential sellers by the buyer as addenda to
the bid documents (ensuring that all sellers are responding to the same procurement statement of work)
Seller Proposal (or Price Quote or Bid)

A proposal is usually the response to a request for proposal (RFP), a quote is usually the response to a request for quote
(RFQ), and a bid is usually the response to an invitation for bid (IFB). The proposal (or price quote or bid) represents an
official offer from the seller. RFP and RFQ,responses describe how the seller will meet the buyers request. A potential
sellers response to an RFI provides information to help the buyer better define their procurement need. Responses to a
request for information may trigger the buyer’s creation of an RFP or RFQ. Keep in mind that sellers may have many RFPs,
RFQs, and IFBs sent to them. They need time to review them and determine which they are interested in responding to.
To ensure the best sellers will be interested, the bid documents should be as complete and straightforward as possible.
The buyers project manager should allow for this time—and the time required for the bidder conference and
responses to that as well as the rest of the procurement process—in the project schedule.
Proposal Evaluation
A buyer proposal evaluation committee uses the source selection criteria to assess the ability and willingness to provide the
requested products or services. This data analysis technique provides a basis to quantitatively evaluate proposals and
minimize the influence of personal prejudices.
5*10
To select a seller the buyer may:

• Simply select a seller and ask them to sign a standard contract.
• Ask a seller to make a presentation, and then, if all goes well, move on to negotiations.
• Narrow down (“short-list”) the list of sellers to a few.
• Ask the short-listed sellers to make presentations, and then ask the selected seller(s) to go on to negotiations.
• Negotiate with more than one seller.
• Use some combination of presentations and negotiations.
The choice of methods depends on the importance of the procurement, the number of interested sellers, and the type
of work to be performed. The sellers’ proposals are usually reviewed and compared by the evaluation committee using one
or a combination of the formal, structured processes discussed next.
Weighting System
When the responses from sellers have been received, the buyers evaluation committee will analyze the responses and
select a seller to award the contract to or to negotiate with. If the buyer is a public entity and the response is to an invitation
to bid, the answer is simple. The work goes to the lowest responsive, responsible bidder. In the case of a proposal, the
selection decision is more complicated. The buyer will apply the selection criteria chosen in planning. But which is more
important? Price? Competence? Availability? Selection criteria are assigned values based on their relative importance to
the procurement. For example, if price is more important, it will be given a higher rating and weight. The buyer’s evaluation
committee then analyzes seller responses using the weighted source selection criteria.
Example There are no calculations on the exam regarding weighting systems, but the following example should help you
better understand the concept.
Seller A
AB C
Rating for this category (1 Category score (column A

Criteria Weight to 100) times B)
Number of years in business 5 percent 50 2.5
Understanding of need 25 percent 80 20

Price or life cycle cost 10 percent 90 9
Technical ability 25 percent 40 10
Ability to complete the work
20 percent 30 6
on time
Project management ability 15 percent 30 4.5
Total score for this seller 52
Past Performance History

The buyer may consider both their history with the prospective sellers and feedback from other organizations who have
done business with the sellers when determining which seller to award the procurement to.
Independent Cost Estimates

The buyer should compare the seller’s proposed cost with an estimate created in-house or with outside assistance during
procurement planning efforts. This allows the buyer to discover significant differences between what the buyer and seller
intend in the procurement statement of work. Responses that are significantly different from what is expected may indicate
an issue with the sellers’ understanding of the procurement statement of work.
I
Presentations
In many cases, some of the sellers will be asked to make presentations of their proposals. This is often a formal meeting of
the buyers and seller’s teams. It provides the seller with an opportunity to present their proposal, team, and approach to
completing the work. The buyer has an opportunity to see the team they may hire and to ask questions to assess the team’s
competency. Presentations are used most often for procurements that have cost-reimbursable contracts, but they can be
used whenever there is a lot to assess.
Negotiations
The exam typically has a question or two related to contract negotiations and the project manager’s involvement. You do
not have to be an expert negotiator to pass the exam. But, as you have seen in other chapters of this book, the ability to
negotiate is an important interpersonal skill for a project manager. Although the procurement manager or officer generally
leads negotiations, the project manager is typically involved. Without the project managers’ involvement in negotiations,
it is common for a contract to be signed that the project manager later discovers cannot be completed.
It is important for everyone involved in negotiations to understand that the objectives of the negotiations are to:
• Obtain a fair and reasonable price
• Develop a good relationship between the buyer and the seller
A procurement should be a win-win situation. The buyer gets the work completed and the seller makes a reasonable
profit. Projects can go bad without this win-win result of negotiation. Negotiation tactics are sometimes represented in
situational questions on the exam. Be aware that buyers and sellers may use negotiation tactics such as delaying or
withdrawal to get what they want. These are undesirable, of course, and you should have the skills to overcome these tactics.
The main items to address while negotiating a contract can be different depending on what is being purchased. Scope,
schedule, and cost are usually negotiated, in that order, although it always depends on project priorities. The clearer the
scope definition, the easier it will be for the buyer and seller to come to a realistic agreement on the other items. Other
items to be negotiated include risk, risk responsibilities, authority, applicable law (laws from a different state, country, or
region should be reflected in the contract), project management process, payment schedule, and quality.
When negotiations are complete, the contract is awarded to the selected seller.
What Do You Need in Order to Have a Legal Contract?

• An offer
• Acceptance
• Consideration (a transfer of something of value, but not necessarily money)
• Legal capacity (separate legal parties that are all legally competent)
• Legal purpose (there is not a legal, enforceable contract for the sale of illegal goods or services)
A contract, offer, or acceptance may be verbal or written, though written is preferred since verbal agreements are
difficult to enforce in a court of law.
Artifacts and Results of Conduct Procurements

The key result of the Conduct Procurements process are selected sellers and change requests.
Selected Sellers
After all the work of evaluating responses and negotiating with one or more prospective sellers is complete, a seller is
chosen for each procurement. This means the buyer and seller have agreed and signed off on all terms and conditions of the
contract, and they will move forward to create the product or service during the Control Procurements process.
Change Requests
The procurement management plan is likely to be iterated. Changes to any plan components, baselines, and other project
artifacts are possible. Sometimes during project executing, problems that arise related to the procurement process (for
example, a seller who isn’t performing) or to other areas of the project (such as risk, quality, schedule, or scope management)
require reevaluation of the procurement management plan and make-or-buy decisions. Such planning changes need to be
submitted through integrated change control, where they are evaluated against the entire project, and approved, rejected,
or deferred.
342
It is important enough to restate that contracts may be finalized after other project plans are completed and approved.
This could trigger the need for changes to any artifact of the overall project, potentially including the scope, schedule, or
cost baselines or any other planning documents such as quality, resources, communications, or risk plan components. The
preapproved seller list may also be updated based on work done in Conduct Procurements.
Control Procurements
Controlling a procurement once the contract is signed involves managing the Process Groups Model
legal relationship between the buyer and seller, ensuring that both parties per PG: Monitoring and Controlling
form as required by the contract, and that each contract is closed when the Process: Control Procurements
contract work is completed. The Process Groups model calls this Control
Procurements but note again that the ECO considers the entire procurement ECO
process be included within the Plan and Manage Procurement task. The work Domain II
is the same regardless of what each resource calls it. The seller is focused on Task 11 Plan & manage procurement
completing the work while the buyer is focused on measuring the perfor
PMBOK* * Guide
mance of the seller and comparing actual performance to the contract, other Domain 2.7 Measurement
procurement documents, and management plans. The exam tends to ask situ
ational questions focusing on what happens after the contract is signed, so
this process is an important area on the exam.
You should understand what problems and issues might affect the management of the project under each contract
type. You will need to ensure that all work and legal requirements in the contract are accomplished, however small and
seemingly unimportant.
The project manager is continually measuring and assessing project progress as compared to the contract and
procurement documentation and management plans. The tools and techniques described later in this section include
many ways in which this is accomplished. When variances are identified, they are analyzed and may need to be managed
using the integrated change control system. Approved changes will be integrated into the management plans or the
contract. Contract changes are handled using the organizations contract change control system, which is an enterprise
environmental factor. This system includes change procedures, forms, dispute resolution processes, and tracking systems,
and is described in the contract. These procedures must be followed, and all changes should be made formally (in writing).
TRICKS Sometimes exam questions ask how project control is different in a procurement, although it will often not be
OF THE asked in exactly these terms. These types of questions can be particularly difficult for those with little
TRADE procurement experience. Getting to a correct answer may include knowing that:
• The seller’s and buyer’s organizations have different cultures and procedures.
• The sellers objective is to generate revenue while the buyer’s objective is to complete the work.
• It is not as easy to see problems on the project when the contracted work is being done in a different location.
• There is a greater reliance on reports to determine if a problem exists.
• There is a greater reliance on the relationship between the buyers and seller’s project managers in terms of resolving
issues not covered in the wording of the contract.
Here are some other specific actions the project manager should be doing during this process:
• Interpret what is and what is not in the contract
• Interpret what the contract means
• Resolve disputes
• Make sure only authorized people are communicating with the seller
• Hold procurement performance review meetings with your team and the seller
• Understand the legal implications of actions taken
• Control quality according to what is required in the contract
• Authorize the seller’s work to start at the appropriate time, coordinating the seller’s work with the work of the project
as a whole
• Manage interfaces among all the sellers on the project
5*15
The procurement management plan includes the actions the project manager and the team will take to oversee
procurements, and the project manager may also review lessons learned to avoid the recurrence of issues experienced in
the past. Approved change requests from integrated change control are also implemented in this process.
The milestone list and schedule, scope, and cost baselines are used to confirm that the project is progressing as
planned. Also:
• Requirements documentation This describes technical and other requirements the procurement is expected
to meet.
• Quality reports These indicate whether the work of the procurement is within the established quality metrics.
• Work performance data This comes from the Direct and Manage Project Work process (in “Integration”) and
gives the project manager information on costs and the status of project activities, and is used to evaluate
seller performance.
In the contracts section we listed advantages and disadvantages of different contract types. The exam will require you
to know that management efforts, issues, and potential trouble spots are different under each type of contract, meaning
there will be different things the project manager needs to do depending on the type of contract. So with the following
exercise, review these concepts and how they affect managing a procurement once the contract is signed.
13.3 Exercise
Hopefully, you have built a strong working relationship with the seller. But what if the seller has financial troubles,
changes owners, or did not include pieces of the work in their estimate? In your Exercise Notebook, describe
specific things you must watch out for and spend your time managing for these main types of contracts: fixed-price,
time and material, and cost-reimbursable.
is not a complete list! Think of what other actions may be taken.
Time and Material Cost-Reimbursable

• The seller cutting scope. Day-to-day direction to the seller. • Audit every invoice.
• The seller cutting quality. Get concrete deliverables. • Reestimate costs.
• Overpriced change orders. Ensure project length is • Monitor to confirm the seller’s
• Scope misunderstandings. not extended. work is progressing efficiently.
• Ensure costs are real, incurred Confirm the number of hours • Ensure all costs are applicable
costs (not future or potential spent on work is reasonable. and chargeable to your project.
costs)—unless there is an Watch for the need to switch to a • Watch for the seller adding
agreement stating otherwise. different form of contract (e.g., resources that do not add value
you determined a design SOW or perform real work.
under a T&M contract and • Look for resources being shifted
switch to a fixed-price contract from what was promised.
for completion of the work).
Methods for Control Procurements

Methods that can be used to manage procurements include performance reviews, inspections and audits, earned value
analysis, and trend analysis.
• Performance reviews These include analyzing all available data to verify that the seller is performing as they should.
Often, the seller is present to review the data and to discuss what the buyer can do to help advance the work. Together
they determine if changes are needed to improve the buyer-seller relationship, the processes being used, and how the
work is progressing compared to the plan. Any changes must be agreed upon in writing.
• Inspections and audits These may involve walkthroughs of the work site or deliverables reviews to verify
compliance with the procurement statement of work. Do deliverables meet specifications? Variances or deviations
may trigger change requests. An audit is performed by a team that includes representatives of both the buyer and the
seller. The audit is to confirm that the sellers activities comply with approved procurement policies and processes.
Variances are identified, formal adjustments are made accordingly, and lessons learned are captured. Note that in
agreement with what we say in the “Quality of Deliverables and Products” chapter, inspections are related to
deliverables while audits are related to processes, policies, and procedures.
• Earned value analysis Measurements identify scope, schedule, or cost variances from the performance
measurement baseline. Variances are analyzed to determine their impact on the project. The results may be used to
generate reports, forecast future performance, and predict actual completion dates and costs. Change requests may be
made based on these results.
• Trend analysis This can determine whether performance is getting better or worse. It can be used to determine if
preventive actions can prevent significant variances in the future and to develop forecast estimates and estimate
at completion.
Contract Interpretation and Managing Conflict

Contract interpretation is never easy and frequently requires a lawyers assistance. However, the exam may describe a
simple situation about a conflict over interpretation of a contract and then ask you to determine the correct answer.
Think About It. Conflict is an important topic that may be addressed in tricky procurement questions. In many
cases the procurement manager (or contract administrator) is the only one with authority to change the contract.
We have also said that the contract includes the procurement SOW. Think about the needed give and take
between the project manager and procurement manager:
• The buyers project manager may want to initiate a change to the scope or sequence of work identified in the
procurement SOW (an area seemingly under the project manager s control).
• They cannot do so without the procurement manager s approval. This adds another layer to the project manager s
management activities that you may not have seen if you do not work with procurements.
• Can you see the potential for conflict between the procurement manager and the project manager?
Think About It. Conflict can also occur between the buyer and the seller and may result in the seller submitting
a claim against the buyer. A claim is an assertion that the buyer did something that has hurt the seller. The seller
is now asking for compensation.
• Another way of looking at this is that a claim is a type of seller-initiated change request.
• Claims can get contentious.
• Imagine a seller that is not making as much profit as they had hoped issuing claims for every action taken by the buyer.
• Imagine the number of claims that can arise if the project manager is working with a fixed-price contract and an
incomplete procurement statement of work.
• Claims are usually addressed through the contract change control system. The best way to settle them is through
negotiation or the use of the dispute-resolution process specified in the contract.
• Many claims are not resolved until after the work is completed.
5*15
Contract interpretation is based on analyzing the intent of the parties, as reflected in the language of the
TRICKS
OF THE contract, along with a few guidelines for interpreting that language. One such guideline is that the contract
TRADE supersedes any memos, conversations, or discussions that may have occurred prior to the contract signing.
Therefore, if a requirement is not in the contract, it does not have to be met, even if it was agreed upon prior to
signing the contract. The following is an exercise on intent.
13.4 Exercise
Select which choice wins in a contract dispute.
CHOICE A CHOICE B
L
Contract language Or A memo drafted by one of the parties describing proposed
changes after the contract is signed
2. Contract language Or A memo signed by both parties before the contract is signed
that describes what was agreed to during negotiations
3. Contract terms and conditions Or Procurement statement of work
4. Common definition Or The intended meaning (without supplying a definition)
5. Industry use of the term Or Common use of the term
6. Special provisions Or General provisions
7. Typed-over wording on the contract Or A handwritten comment on the contract that is also initialed
8. Numbers Or Words
9. Detailed terms Or General terms
Answer
Check the answers below. Note: The answer to number 3 depends on the Order of Precedence Clause in the
contract that describes which terms and conditions take precedence over the others in the event of a conflict
between them.
1. A 4. A 7. B
2. A 5. A 8. B
3. AorB 6. A 9. A
Artifacts of Control Procurement

The artifacts resulting from conducting procurements are change requests, procurement document updates, and
closed procurements.
Change requests Changes to a contract result when the buyer s needs change while the work is underway, the impacts of
the contract changes having been negotiated by the two parties. Contract changes may be requested throughout the
procurement process and are handled as part of the project’s integrated change control efforts, along with all other project
changes. Like other project changes, contract changes need to be analyzed for their impacts on all project constraints.
Constructive changes You should be aware of the concept of constructive changes, which do not result from formal
change requests. Rather, constructive changes occur when the buyer, through actions or inactions, limits the seller’s ability
to perform the work according to the contract. This can include over-inspection or failure to hold up their end of the
contract (e.g., failing to review documents or inspect deliverables on time). A simple direction to the seller to perform
certain work that may seem minor can result in a constructive change that adds costs if that change is outside the scope of
the contract.
5*16
Records management system Throughout the process of managing an active procurement, data on the contract and
contract performance by both the buyer and the seller is gathered and analyzed. Because a contract is a formal, legal
document, thorough records must be kept. Arecords management system maybe used to keep procurement documentation
complete, organized, and accessible. Record keeping can be critical if procurement-related actions are questioned after the
procurement is completed, such as in the case of unresolved claims or legal actions. Records may also be necessary to
satisfy insurance requirements.
For many projects, every email, every payment, and every written and verbal communication must be recorded and
stored. On other projects, information about the weather and the number of people on the buyer’s property each day may
be recorded. On large or complex projects, a records management system can be quite extensive and can require a person
just to update it, including indexing, archiving, and information retrieval systems.
Closed procurements Finally, procurements are closed as they are completed or terminated. All procurements must be
closed out, no matter the circumstances under which they stop, are terminated, or are completed. Closure is a way to
accumulate some added benefits, such as lessons learned. Closing a procurement consists of tying up all the loose ends,
verifying that all work and deliverables are accepted, finalizing open claims, and financial closure (ensuring payment). The
buyer formally notifies the seller the contract has been completed. There may be some obligations, such as warranties, that
will continue after the procurement is closed.
Many people who are new to procurement do not realize a contract can be terminated before the work is complete.
The contract should have provisions for termination, which can be done for cause or for convenience. When too many
changes are required the project manager should see if the existing contract no longer serves the purposes of defining all
the work, roles, and responsibilities. It may be best to terminate the contract. The buyer may terminate a contract for cause
if the seller breaches the contract (does not perform according to the contract), or simply terminate a contract for
convenience if they no longer want the work done.
A seller is rarely allowed to terminate a contract, but it could be appropriate on some projects. In any case, termination
can result in extensive negotiations on what costs the buyer will pay. This is controlled by the language of the contract. In a
termination for convenience, the seller is usually paid for work completed and work in process. If the contract is terminated
for cause due to a default, the seller is generally paid for completed work but not for work in progress. The seller may also
be subject to claims from the buyer for damages. Termination is a serious issue, and one that has lasting effects on the
project. Termination negotiations can be drawn out long after the work has stopped—highlighting yet another reason why
details of the project must be documented.
Some people mistakenly think that the process of closing procurements is part of closing a project or phase.
TRICKS This comes up on the exam. Think of project closure as closing out a project or phase and procurement closure
OF THE
TRADE- as completing only that particular part of scope that you have procured through a third party. Keep the
following tricks in mind:
• There may be many procurements in one project, so there can be many procurement closures, but closing a project
or phase only happens at the end of the project or phase.
• Upon completion of the contract for each procurement, the project manager performs a process audit on the
contract and the sellers performance before closing out the procurement. When the project as a whole is
completed later, the project manager performs the final administrative and financial closure along with other
processes required to close out the project.
• Read questions carefully. There may be questions that ask about the frequency of project closure or procurement
closure. The way the questions are written will help you select the right answer. For projects that are managed in
phases, closing the project or phase occurs at the end of each project phase as well as at the end of the project as a
whole. In contrast, procurement closure is done at the completion of each contract.
• To protect the legal interests of both parties, procurement closure requires detailed record keeping and must be
done more formally than is generally required for project closure.
Now let’s think about the real world. What do you think needs to be done at the end of the procurement in order to
say the procurement is indeed finished? Wouldn’t it be substantially similar to what needs to be done when you close out
a project in the Close Project or Phase process? Be careful on an exam question to be sure whether it is talking about
closing a procurement or a project or phase.
13.5 Exercise
In your Exercise Notebook, describe what work must be done during procurement closure.
Answer
As you read the answer, think about how similar closing procurements is to the Close Project or Phase process
(although it is not the same process). Procurement closure includes all the following:
• Product validation This involves the buyer validating and formally accepting (signing off on) the portion of
project scope the seller is providing. It includes checking to see if all the work and documentation was
completed correctly and satisfactorily.
• Procurement negotiation The final settlement of all claims, invoices, and other issues may be handled
through negotiations or a dispute resolution process established in the contract.
• Financial closure Financial closure includes final payments and cost records.
• Procurement process audit This is a review of the procurement process and capturing lessons learned.
Normally this is done by the procurement manager and project manager, but companies that want to improve
their processes may also involve the seller.
• Updates to records This involves making sure all records of the procurement are complete and accessible.
These records will become part of the procurement file (described later in this discussion).
• Final contract performance reporting Think of this as creating a final report reflecting the success and
effectiveness of the procurement and the seller.
• Procurement file Finalizing the procurement file involves putting all emails, letters, conversation records,
payment receipts, reports, and anything else related to the procurement into an organized file. This file will be
stored for use as historical records. The project manager, with the help of the procurement manager, decides
what documents need to be kept.
Expect questions on the exam that describe a situation and require you to determine whether the procurement is
closed. In gaining formal acceptance from (you) the buyer, the seller is also working to measure customer satisfaction.

That is the procurement process! Was a lot of this new to you? If you are inexperienced in working with procurements, re
read this chapter, and try to visualize how the different topics apply to a large project. Then visualize how it might work on
other types of projects. This will help you understand the process better.
Test your knowledge by completing the following exercise. Notice the word “actions” within this exercise. For the
exam, you need to know what needs to be done during each step as well as what you have when you are done with a process
(outputs or outcomes). This is an important exercise for ensuring that you can successfully answer procurement questions
on the exam.
13.6 Exercise
Recreate the procurement management process by making a list in your Exercise Notebook of the key actions and
of the artifacts resulting from Plan Procurement Management, Conduct Procurements, and Control Procurements.
The answers to this exercise are listed after the next Trick of the Trade®. If you have missed many of the answers, do
this exercise a second time after reviewing the material.
5*18
Here is a trick for understanding the process without memorizing the whole thing—know only the
TRICKS
OF THE artifacts! If a question describes some activity and that activity occurs after the procurement
TRADE documents are created and before the contract is signed, then it must be taking place as part of the
Conduct Procurements process. If it is taking place during the time after the contract is signed
through when the work is substantially done, it must be occurring during the Control Procurements process.
Answer
The following actions and outputs are the ones you should give the most attention to when preparing for the exam.
Key Actions For Each Procurement
Plan Procurement Management Conduct Procurements Control Procurements

• Perform make-or-buy analysis. • Find potential sellers through • Understand the legal implications of
• Create a procurement advertising, a preapproved your actions.
management plan. seller list, or other means. • Hold procurement performance reviews.
• Create a procurement strategy. • Send • Request changes.
• Create a procurement procurement documents. • Administer claims.
statement of work. • Hold a bidder conference. • Manage interfaces among sellers.
• Select the appropriate • Answer sellers’ questions. • Monitor, analyze, and report on performance
contract type. • Receive the seller responses. against the contract.
• Create terms and conditions, • Compare the proposals to • Review cost submittals, and make payments.
including standard and the source selection criteria • Perform inspections and audits.
special conditions. using a weighting or
• Maintain records of everything.
• Create bid documents. screening system to pick/
shortlist the sellers. • Manage relationships.
• Determine source
• Accept verified deliverables.
selection criteria. • Receive presentations from
seller(s). • Perform procurement audits.
• Gather and analyze data on
• Compare to • Negotiate settlements.
prospective sellers, the market,
and market price. independent estimates. • Create lessons learned.
• Estimate time and cost for • Hold negotiations. • Complete final contract
contract and work. • Use interpersonal and team performance reporting.
• Make-or-buy decisions. skills, such as negotiation. • Validate the product.
• Procurement • Allocate risk to sellers • Issue formal acceptance.
management plan. when appropriate. • Update records.
• Procurement statements • Selected sellers. • Create a procurement file.
of work. • Signed contracts. • Perform financial closure.
• Resource calendars. • Substantial completion of contract
• Change requests. requirements and deliverables.
• Project management • Work performance information.
plan updates. • Change requests.
• Project documents updates. • Project management plan updates
• Recommendations and • Project documents updates (including
updates to the processes and updates to procurement documents).
procedures for organizational • Organizational process assets updates.
procurement practices.
• Formal acceptance.
• Organizational process
• Closed procurements.
assets updates.
• Lessons learned and records updates.
13.7 Exercise
Here is another exercise to review what was discussed in this chapter. To pass the exam, you must understand the
project managers role in procurements. After reading this chapter, describe the project manager s role. Write the
answer in your Exercise Notebook.
Answer
As the project manager, you should:

• Know the procurement process so you integrate all procurements into your project.
• Understand what contract terms and conditions mean so you can read and understand contracts.
• Make sure the contract contains all the scope of work and all the project management requirements, such as
attendance at meetings, reports, actions, and communications deemed necessary to minimize problems and
miscommunications with the seller(s).
• Identify risks and incorporate mitigation and allocation of risks into the contracts to decrease project risk.
• Help tailor the contract to the unique needs of the project while it is being written.
• Include adequate time in the project schedule to complete the procurement process.
• Be involved during contract negotiations to protect the relationship with the seller.
• Protect the integrity of the project and the ability to get the work done by making sure the procurement
process goes as smoothly as possible.
• Help make sure all the work in the contract is done—including reporting, inspections, and legal deliverables,
such as the release of liens and ownership of materials—not just the technical scope.
• Do not ask for something that is not in the contract without making a corresponding change to the contract.
• Work with the procurement manager to manage changes to the contract.
550
QUICKTEST
14 Stakeholders • Cost of change

• Stakeholder definition
• Stakeholder Management
process
• Stakeholder analysis
• Stakeholder expectations
• Stakes
• Personas
Introduction
• Stakeholder register
A student came into a class at RMC after having failed the exam. When talking with the student, Rita • Stakeholder engagement
• Stakeholder engagement
learned that he always worked with the same four people; his role was to simply tell them what to do.
assessment chart
On many of his projects he was both a project manager and subject matter expert.
• Assumptions and
For the exam you should assume your role is solely that of project manager, and you have a team constraints
who does the product development work. You are a leader on the project but you work collaboratively • Root cause analysis
with other team members who manage how to do their own assigned work. • Project elevator statement
Rita discovered that this student had only applied his own limited experience when he had • Kanban boards
• Agile modeling
studied for the exam. As a result, he failed to understand more broadly project management best
- Wireframes
practices. As a result, he was unable to tailor those practices to the wide variety of scenarios he
encountered on the exam.
As you read this and all chapters of this book, keep trying to increase your understanding of the
practices presented so you can tailor them to any scenario. This will help you both in your career and
on the exam.
Definitions Related to Stakeholder Engagement
The Cost of Change
The most critical reason for diligence in our
stakeholder engagement efforts is that the closer
we work with the customer on the product design
and development, the fewer costly changes will
come later. This means diligence in making sure
we have identified all the stakeholders and begun
to engage with them as early on the project as
possible, and then work with them continually so
there are no costly surprises down the road. The
goal is always to fulfill project requirements and
achieve customer satisfaction. FIGURE 14.1 Cost of change and
influence on a design
Why is it important to understand the
importance of good, stable relationships with stakeholders?
Early and consistent communication with stakeholders is critical because the cost of change rises
over time, while the ability to influence a design falls. Changes made later in the project (when the
product has already been gradually built) are harder to add than those made earlier on the project.
This is illustrated in figure 14.1.
Stakeholder
A project stakeholder is one who is positively or negatively affected by or can positively or negatively
affect the project or the product of the project.
Planning, leading, and continuously evaluating stakeholder engagement will have an impact on
your understanding of project management and your ability to pass the exam. Review this chapters
Quicktest before you continue. Note which topics you are less familiar with and spend more time
studying them. In this chapter, we discuss the stakeholder engagement process. We also cover methods
and artifacts most often seen on the exam related to stakeholder engagement, from both plan-based
and agile perspectives.
Stakeholders FOURTEEN
Think About It. Imagine you’re assigned as the project manager for a new project. Your department director
gives you a charter and scope of work and tells you to get started. As the project manager, what do you do next?
Often on the exam you will be asked what the project manager should do next. As you read the previous
question, did you think that you should get started on the scope of work? Can the project manager accept a
charter and scope of work without understanding the stakeholders and their requirements?
Once the project manager has a signed charter (authorizing the project) and scope of work, the next steps for the
project manager are to:
• Identify all stakeholders • Develop strategies and tactics for
• Analyze their power, interest, and level of stakeholder engagement
engagement • Evaluate and incorporate stakeholder
• Elicit their requirements and expectations requirements as known into the project’s scope
Engaging stakeholders and reassessing stakeholder engagement strategies and tactics should take place throughout
the life of the project. The project manager and the team need to build and maintain relationships with stakeholders and
make sure they are continuously involved in the project at the level necessary to make it a success. The project manager
routinely looks for additional stakeholders that are new or have been missed, assesses whether the strategy is producing the
needed results, and change strategies and tactics as necessary.
Agile approaches include a member of the team as a key stakeholder, most often called the product
owner. One of their main roles is to prioritize and maintain the backlog. It is also common to have frequent
demos for stakeholders of small portions of working product while it is still evolving. Predictive approaches
typically, in contrast, have stakeholders review more fully developed interim deliverables or work packages.
Stakeholder Engagement Overview

The Stakeholder Engagement process, regardless of the project’s approach and life cycle, requires a good understanding of
the interpersonal and team skills that are covered in the People domain section of this book. Be sure to understand every
thing about the People domain before you read this chapter. People domain skills will help you to not only get those ques
tions right on the exam, but will also help you with the stakeholder engagement process skills covered in this chapter.

The following illustrates that Examination Content Outline (ECO) tasks 4,9, 10, and 13 in domain I, and task 4 in domain
II can map directly to the stakeholder management process in the Process Groups model. Take time now with the ECO to
think this through.
552
FOURTEEN Stakeholders
Think About It. As you study this remember that stakeholder engagement doesn’t only relate to the ECO tasks listed
in the previous table. Can you see how other People domain ECO tasks lend support to these tasks? You would not
... successfully Engage Stakeholders (domain II, task 4), for example, if you can’t apply all or most of the skills in
I domain I (People).
Examples Manage Conflict (task l) supports Build Shared Understanding (task 10). Engage & Support
Virtual Teams (task 11) aids Empower Team Members and Stakeholders (task 4).
Figure 14.2 shows the Stakeholder Engagement process from the Process Groups model perspective. Some activities
related to this process fall within the communications area because communications is so closely related to
stakeholder engagement.

KA: Stakeholder Engagement
Key
' 7 is consistent with all
approaches

v progressive elaboration
or agile methods

FIGURE 14.2 Stakeholder engagement process
Using the Process Groups model as a starting point, you can see that the stakeholder engagement process consists of
four sub-processes: Identify Stakeholders (which includes stakeholder analysis), Plan Stakeholder Engagement, Manage
Stakeholder Engagement, and Monitor Stakeholder Engagement.
The stakeholder engagement process can be summarized as follows:
• Identify all stakeholders Do this as early as possible. The later stakeholders are discovered, the greater is the cost of
the changes their new requirements involve. Determine requirements, expectations, interest, influence, level of
authority, and values.
>/ Requirements Obtain as many requirements as possible before work begins. The level of detail may differ
at different stages depending on the project life cycle either because of progressive elaboration or
development approach. Do you try to do this on your real-world projects?
On a plan-based project the project manager tries to capture all project requirements as early
in planning as possible. On an agile project only high-level requirements are captured up front and
detailed requirements are gathered for each product feature as the iteration is planned.
Expectations What are expectations? They are mental pictures of the future. They include what
stakeholders think will happen to them, their department, and the company as a result of the project, and
what they want from the project that has not been articulated or made into requirements.
553
Why not prevent as many issues as possible by walking stakeholders through what will occur and asking
them what they expect? Evaluate these expectations, clarify some of them to foster a common understanding,
and convert others to defined requirements.
y Interest This means concern about the project. Determine the level of interest for each stakeholder. Are
they likely to be engaged? How much of their attention and support do you need, and when do you need it?
>/ Level of influence Each stakeholder will be able to impact a project negatively or positively to some degree.
Identify and manage the level of influence for each stakeholder, even if informally.
y Level of authority Each stakeholder’s level of authority (or ability to enforce decisions) will impact their
effect on the work and outcome of the project.
y Values Do project priorities align with the stakeholders’ standards that are also authorized within the
project charter? Project managers should not plan or initiate work that the stakeholders do not support
or value.
• Plan Stakeholder Engagement Project management focuses on planning before doing. How will you engage
stakeholders? How will you keep them involved in the project and include them in decision making? This engagement
is tailored to the project and development approach. Communication is critical and is related to stakeholder
engagement. Careful communication planning and implementation helps keep stakeholders at the appropriate level
of engagement.
y Communicate and engage Cultivate relationships with stakeholders and keep them well informed. Involve
them in project presentations and information exchanges, including progress reports, the project
management plan, and other artifact updates, as appropriate.
y Manage expectations, influence, and engagement Work with stakeholders and manage relationships
throughout the life of the project.
• Monitor Stakeholder Engagement Throughout the project, determine if and where communications are breaking
down, where engagement tactics and strategies are not working as needed, and adjust the approach as required to
ensure that engagement is at the right level.
A key to your success as a project leader is how you handle stakeholder relationships. Stakeholder involvement
TRICKS
OF THE must be appropriately influenced by the project manager. That involvement may range from minor to extensive
TRADE depending on the needs of the project, the team, the stakeholders, and the organization.
Now we’ll look more closely at each of these processes.
Desired Outcomes from Successful Stakeholder Engagement

Assume for the exam that stakeholder engagement is properly planned and managed unless information in an exam
question indicates otherwise. This means that the following outcomes should be expected as a result of successful
stakeholder engagement:
• The project manager is able to establish and maintain a common understanding of the project, its objectives,
constraints, and how they all are interacting to deliver the desired value the stakeholders will have from
project deliverables.
• The project manager and team have good working relationships with the other project stakeholders, and the
stakeholders are engaged at the desired level so as to help facilitate desired outcomes.
• The project manager knows what to do to adjust stakeholder engagement to desired levels as changes are needed
because they have analyzed and planned for each stakeholder or stakeholder group’s needs.
• Stakeholders who do not support the project will not affect it or its outcomes adversely because the project manager
communicates with them as needed to help them accept the project and its outcomes.
• The project manager achieves customer satisfaction with the key stakeholders who will be the beneficiaries of the
product of the project. This is achieved through good working relationships, appropriate levels of communication
and expectation management.
Stakeholder Identification (and Analysis)

The first stakeholders are likely those who identify the problem or need. They Process Groups Model
may have been involved in developing business documents for the project. The PG: Initiating
business case and benefits management plan, created before project initiating, Process: Identify Stakeholders
may include fists of stakeholders who will benefit from or be affected by the
project. Other sources to identify stakeholders include contracts, agreements, ECO
and the project charter. Domain I
Task 9 Collaborate with stakeholders
Remember that any stakeholders who are missed will likely be found
Domain II
later, and their new requirements could cause costly changes and delays or loss Task 4 Engage stakeholders
of benefits and value. Project managers need to help create a project that
considers all the interests, influences, and interdependencies of all stakeholders PMBOK® Guide
as early as possible. Domain 2.1 Stakeholder
Domain 2.4 Planning
At the same time, this is hard to do perfectly. Why do you think that is?
Changes within a project or organization

may introduce new stakeholders
A project manager and team may miss

stakeholders initially
Adaptive approaches include an evolving

scope, which may mean an evolving
stakeholder list
Even on predictive projects the stakeholder

list evolves to some degree
Throughout the project the project manager reassesses the stakeholder register and revisits the engagement strategy
for existing stakeholders to determine whether new ones should be added and, if so, what that means for the project.
Many project managers fail to consider the broad range of potential stakeholders.
TRICKS
OF THE
TRADE* Sponsor, team, product owner, senior management
Subject matter experts, customers, product end users
Other departments or groups within the organization;

functional or operational managers
Sellers, consultants, regulatory agencies, financial firms
Government agencies
If the project includes procurement, parties to contract(s)
As agile practitioners know, this is a team process so be sure you are collaborating with the team on
stakeholder identification and analysis. Also consult other stakeholders: subject matter experts, project
managers in the organization who have worked on similar projects, and professional associations. Any
stakeholder may suggest other stakeholders to add to the list.
Methods for Stakeholder Identification and Analysis

Following are the methods for stakeholder identification and analysis that could appear on the exam. Remember this
process includes a complete stakeholder analysis.
Surveys, Interviews, and Focus Groups

These tools provide different ways to exchange information with team members and other stakeholders. They can be used
to identify other potential stakeholders and provide input about management of different types of stakeholders or
stakeholder groups.
555
Brainstorming
Ibis method of shared idea generation can help identify stakeholders.
Individual Stakeholder Analysis

Every stakeholder has expectations and attitudes toward the project that need to be uncovered. How interested are they in
the project, and what is at stake for them? Examples of stakes include the following:
• Ownership The stakeholder may have to sell property for a proposed freeway expansion.
• Knowledge The stakeholder may be the expert who designed a legacy inventory management system that is being
upgraded or replaced.
• Rights The stakeholder may be concerned that a new housing development will endanger the community by
destroying the watershed.
• Rights A government official may be responsible for ensuring that the safety practices on a construction site comply
with state and federal laws.
• Interest The community may be concerned that additional traffic will come into their residential neighborhood if a
new commuter rail stop does not have adequate parking.
• Contribution The resource manager may be concerned that resource team members assigned to the project will not
be able to complete their normal operational work with the addition of project work.
Document Analysis
This technique assesses current and historical project documents, like lessons learned and other information from past
projects (organizational process assets). The analysis can help the project manager identify stakeholders and their stakes in
the project.
Stakeholder Mapping
This is a data representation method that maps stakeholder attributes into categories. Project managers use this method to
analyze and plan how the project team will prioritize efforts to build relationships and engage stakeholders on the project.
Stakeholder mapping examples include the power/interest grid, stakeholder cube, and salience model. Stakeholders
can also be grouped by directions of influence (upward, downward, outward, and sideward).
Power/Interest Grid This grid, shown in figure 14.3, is used to group stakeholders based on their level of power over the
project and its outcomes relative to their interest in the project. It can inform the project manager about how to engage
with a stakeholder based on these attributes.
Variations of this tool emphasize other stakeholder attributes, such as power/influence or impact/influence.
Stakeholder Cube This three-dimensional model is used to represent dimensions or aspects of a stakeholder group. An
example is shown in figure 14.4.
Salience Model This model is used to group stakeholders based on the appropriateness of their involvement (Legitimacy),
their authority or ability to influence outcomes (Power), and their need for immediate attention (Urgency). An example
of this model is shown in figure 14.5.
Urgency
Figure 14.5 Salience model

Figure 14.3 Power/Interest grid
556
Personas
A persona is a concise description of a real or imagined stakeholder model. Figure 14.6 is a sample persona
for the new library building project. Personas are created for agile projects to better imagine how each type of
stakeholder will use the end product. A persona may be based on a real person or a combination of
characteristics from several types of product users.
When personas are used as a product design method, they should:
• Anchor team understanding in real types of people who will use the product
• Provide focus for design and creation of specific and relevant product features
• Help make team members aware of design choice implications for product users
Jemelia Job Seeker

V
Description Values
• Looking for new job after completing • Free access to computer with easy apps
bachelor’s degree in nursing • Free internet access
• Working as a home health aide • Easy instructions on the application
• Does not have a computer for finding jobs process and how to access job boards
• Needs access to job resources at odd
hours during time off
FIGURE 14.6 Sample persona
Look again at the card describing Jemelia Job Seeker as a persona. The goal is to make the best decisions regarding the
creation of the product’s features and functions. By seeing through the eyes of a particular persona, it’s easier to imagine
what the represented stakeholder group needs from the product. For example, the team can ask about a particular feature
they are designing: What would Jemelia want from this feature?
Artifacts of Stakeholder Identification and Analysis

The Identify Stakeholders process results in a stakeholder register (and/or personas if it is an agile project), change requests,
and updates to the project management plan and project documents such as the:
• Assumption log • Risk register
• Issue log • Personas (an agile method)
Stakeholder Register
Information about stakeholders is compiled in the stakeholder register, a key output of the Identify Stakeholders process.
The stakeholder register (figure 14.7) may include each stakeholder’s detailed information. This register may include:
• Name & title
• Supervisor
• Project role
• Contact information
• Major requirements and expectations
• Assessment information, impact, and influence
• Attitude (regarding the project)
• Stakeholder classification (grouped by similar attributes)
• ... other relevant information
Figure 14.7 Sample stakeholder register
557
The stakeholder register is an important input to the Plan Stakeholder Engagement process as well as to several other
planning processes, including Plan Communications Management. Remember that the stakeholder register will be
updated throughout the project.
Plan Stakeholder Engagement

Stakeholders can be an asset or a problem, and this process is about establishing and Process Groups Model
documenting the optimal engagement level for each stakeholder (or stakeholder PG: Planning
group). The project manager also needs to establish when each stakeholders’ en Process: Plan Stakeholder Engagement
gagement is needed, based on the stakeholder identification and analysis already
done, and when engagement levels and strategies should be reassessed for each ECO
stakeholder or group. Domain I
Task 9 Collaborate with Stakeholders
TRICKS On the exam, assume there is a plan in place about how the project Task 10 Build Shared Understanding
OF THE manager, the team, and the project outcomes will impact stakeholders, Domain II
TRADE interact with them, manage their expectations, involve them in Task 4 Engage Stakeholders
decision-making, and keep them satisfied to ensure they are an asset.
PMBOK® Guide
Knowing stakeholders well leads to better confidence and success for the Domain 2.4 Planning
project manager and the team. Requirements will be delivered and, because all
expectations have been managed (even those that do not rise to the level of being a
requirement), customer satisfaction will be achieved.
As a project manager, the closer you are to stakeholders, the more comfortable they will be to come to you with their
concerns, and the easier it will be for you to pick up on nonverbal cues that can tell you something might be wrong. This
can be an early warning system for problems on your project. But you may wonder how you build positive and powerful
relationships with your stakeholders. The same way you have built them with your friends and family: By spending time
getting to know them and allowing them to know you. Draw on your experience with your family, friends, coworkers, and
others. You’ll be better able to determine your stakeholders’ needs, concerns, values, and expectations.
Make sure you are comfortable with these concepts in a project management context so they will be easy to bring to
mind when reading exam questions. Take a few minutes to think about the characteristics of a good relationship. You may
think of different or additional qualities, but here are a few you want to nurture in your relationships:
• Trust • Respect
• Honesty • Concern
• Interest • Empathy
• Sincerity • Good communication
As you plan stakeholder engagement, you will need to:

• Use your experience on other projects
• Get the details of what has already been planned or documented including:
V Information from the stakeholder register
Resource and communications management information and plans

>/ Relevant information from past, similar projects (historical records)
• Consider how much and what type of engagement you need from different stakeholders during each project stage.
Talk to them so they can contribute ideas that will help them stay engaged as needed.
Example You require some stakeholders to be more involved during planning, while others will have a more
prominent role during executing.
• Meet with your key stakeholders as soon as possible to initiate these important relationships.
• Think about each stakeholder’s role, the environment in which they operate, and the specific needs of your project.
558
• Think about each stakeholder s attitude and interest in the project.

• Determine which stakeholders will require most of your time and effort.
• For stakeholders you don’t know very well, talk to another project manager or team member who has worked with
them in the past.
• Make sure stakeholders understand how important it is for the project to meet their needs, and encourage them to
communicate frequently as the planning and project work proceed.
• Meet with professional organizations, consultants, and subject matter experts to hear insights on working with various
stakeholders and stakeholder groups.
• If there are any procurements in place, coordinate with the procurement department to plan efforts related to parties
of the contract.
• Plan review meetings to get feedback on progress.
• Decide how adjustments to engagement levels will be achieved, based on current knowledge of the project and
its stakeholders.
• Plan for how and with what frequency you will identify and analyze variances between current and desired levels of
engagement. Work with the team to identify ways to achieve the right engagement levels.
Not every stakeholder will be as engaged in the project as you need, and some might be more engaged than
you would wish. Stakeholder engagement can range from unaware of or resistant to the project to neutral to
supportive or even interested in taking a leading role on the project.
14.1 Exercise
Let’s consider an example. Imagine you are managing a project to replace the online employee application process
for your company. Your sponsor wants to streamline the process and encourage candidates with advanced technical
experience to apply for jobs. Here is a preliminary stakeholder list.
Key Stakeholders
Stakeholders (With whom you’ll spend the most time)
Sponsor: HR director Sponsor

Potential candidates (possibly millions!) Hiring managers
Hiring managers within the company
Is anyone missing from the key stakeholder list? Write it down before reading on.
Answer
You will want to receive frequent feedback from key stakeholders about how the design meets their requirements
and expectations. If you haven’t done so already, add to that list a few newly hired employees who could help the
team understand problems with the existing application process, as well as website administrators and human
resource administrators (and there maybe more!).
559
Methods for Stakeholder Engagement Planning

As the project manager you will need to choose tools to plan stakeholder engagement that are appropriate for the project.
The following is not an exhaustive list but is a good representation of what is needed.
Stakeholder Engagement Assessment Chart

This is a data representation tool (and an artifact) used to compare stakeholders’ current and desired level of engagement.
The stakeholder engagement plan documents what action will be taken to achieve optimal engagement. This chart (figure
14.8) is used for establishing strategies and tactics for ongoing stakeholder engagement. It is also used in the
monitoring process.
Figure 14.8 Stakeholder engagement assessment chart
Assumptions and Constraints

Analysis evaluating assumptions about stakeholders’ attitudes toward the project enables the team to determine actions
needed to adjust levels of engagement to benefit the project. Analysis of project constraints can provide insight into
determining strategies to adjust stakeholders’ levels of engagement.
Root Cause Analysis
This is a way for the project manager and team to analyze the cause of the current level of stakeholder support and
engagement. Doing so will help them determine how best to facilitate a change to bring the stakeholders’ engagement to
the desired level.
Project Elevator Statement (Product Vision Statement)

These are short descriptions of the project goals and benefits that allow the project manager to explain the
project in the span of an elevator ride. Stakeholders could be involved in creating the project elevator statement
(also known as “elevator pitch”) to help everyone understand the project and convey it to others. Following
is a popular format for elevator statements:
For: Target customers

EXAMPLE:
Who: Need (opportunity or problem)
For people who want to stream video
The: Product/service name
content the Viking Ultimate service is a
Is a: Product category streaming service that is fester, cheaper, and
That: Key benefits/reason to buy better, unlike ABC services we have no
lengthy contracts.
Unlike: Primary competitive alternative(s)
We: Primary differentiation
On the exam, “elevator statement” or “elevator pitch” will likely signal the question is about an agile (or agile
portion of a hybrid) project, influencing your answer. However, look for other clues to ensure this is a correct
assumption. The “elevator statement” or “elevator pitch” is a common business concept that dates back to
long before agile and is used in many contexts, including traditional project management. On agile projects
this may also be called a Product Vision Statement.
360
14.2 Exercise
If you’ve never planned stakeholder engagement, it can be difficult to imagine how you would go about doing this
on an individual stakeholder (or group) level. Think about the various stakeholders involved on a project. The
following table describes a few stakeholder descriptions based on collections of attributes that can be identified
and analyzed.
In your Exercise Notebook, write down how you would plan to manage the involvement of each of these
stakeholders based on the given descriptions. On your projects, you will want to think about this in planning so
that as you are working with the processes of managing and monitoring stakeholder engagement you will know
what to do.
Stakeholder Description
1. High interest, low influence, shows high expertise on high-risk areas
2. Low interest, the source of major requirements (high influence), not very responsive to communications
3. High interest, high influence, doesn’t support the project
4. High interest, high influence, supports the project
5. Moderate interest, high influence because they have identified many potential risks, supports the project
6. Moderate interest, nervous about completing assigned activities
Answer
Listed here are suggestions for how you might plan to manage stakeholder engagement based on the descriptions
in the previous table. These are general descriptions and answers, but will help you better understand the work
needed for stakeholder engagement planning and management depending on different stakeholder attributes.
Options for planned engagement strategies and tactics based on stakeholder descriptions.
1. Invite the stakeholder to participate in analyzing the risks on the project.
2. They may be overscheduled. Identify ways to elicit requirements as efficiently as possible.
a. Determine why responsiveness is low. Ask them about how they would like to be involved with the
project, and with what communication methods (email, phone calls, meetings, etc.).
b. Make sure requirements are clearly captured and approved by the stakeholder as accurate.
c. Send reports to ensure they have the information they need even if you do not get feedback.
3. Use emotional intelligence. Ask the stakeholder what is important to them relative to the project. Ask
them how you can gain their support for the project.
4. Involve them in team meetings, report project performance to them, and, as appropriate, include
information as the stakeholder requests.
5. Plan to meet with them periodically throughout the project to potentially identify other risks. Keep them
informed about the effectiveness of risk efforts; involve them in risk reviews and audits.
6. Plan to find and forward relevant literature to help them, and arrange for training as necessary.
S6I
Artifacts of Stakeholder Engagement Planning

The main artifact of Plan Stakeholder Engagement is a stakeholder engagement plan that aids the project manager in the
planning, managing, and monitoring of stakeholder engagement.
The Stakeholder Engagement Plan includes:
• Existing and desired engagement levels for all stakeholders, including plans to achieve desired levels.
• Details about ways in which stakeholders will be involved in the project
• Guidelines and metrics for monitoring and evaluating how well the plan is meeting the needs of stakeholders and
the project.
Often, less formal stakeholder engagement plans are needed in adaptive environments.
Example Scrum (a specific agile approach) builds frequent stakeholder interactions into the build-and-
review cycle. A sprint (iteration) is for building a product increment. Following the sprint, a sprint review
involves demonstrating the newly built product increment to the customer. Then, a sprint retrospective
includes time set aside for the team to review what went right, what went wrong, and what they could do
differently. You can see that frequent stakeholder engagement is built into this approach.
We use Scrum as an example here but other types of agile teams work similarly to build and review product increments
and to then review their processes and ways of working. With an agile approach the product owner participates in all parts
of the build-and-review cycle, representing value delivery for the customer. Since a predictive environment has longer time
horizons between when deliverables are completed to when they are shown to the customer, a more formal stakeholder
management plan is often used.
Stakeholder and communications management plans may have similar information about stakeholder and
TRICKS communication requirements. Each plan has a different focus and portions of them are created together. The
OF THE
TRADE stakeholder engagement plan explains the importance of which stakeholders need to receive which
information. The communications management plan contains details about communications technology and
methods—for example to generally state when using email is best versus making a phone call.
Be careful about what is documented in a stakeholder register or other related documentation, and with
J] whom you share it. Consider sensitive information learned about attitudes and personalities, or about
IljvVj-fl challenges. It could be damaging for someone to find this type of information. A good leader is encouraging
and supportive of everyone, even those who are resistant to supporting the project or spending time working
I with you. As you discover a stakeholder-related challenge, you may decide not to share it (or not to document it).
Manage Stakeholder Engagement

At this point, the project manager has identified and analyzed the stake Process Groups Model
holders and stakeholder groups on the project, and planned for optimal PG: Executing
engagement with them. In this process the project manager carries out that Process: Manage Stakeholder Engagement
plan based on what is known. Throughout the project the project manager
will communicate and work with stakeholders to meet their project re ECO
quirements and manage their expectations—whether or not all their ex Domain I
pectations are actual product or project requirements. Although it is asso Task 4 Empower team members & stakeholders
Task 9 Collaborate with stakeholders
ciated with the executing process group in the Process Groups model,
Task 10 Build shared understanding
managing stakeholder engagement is inherent in everything the project
manager does on a project. Domain II
As the project manager, are you concerned you don’t have time to Task 4 Engage stakeholders
keep up with communications, or encourage stakeholder support while
PMBOK® Guide
collecting their input and concerns? These efforts actually help you be
more efficient by reducing the time spent dealing with problems. When Domain 2.6 Delivery Performance
taking the exam assume that these good stakeholder management Domain 2.8 Uncertainty
562
practices are followed—unless the question or answer choices indicate otherwise. This work also requires good
interpersonal and team skills such as political and cultural awareness, negotiation, and conflict management.
During executing, the project manager:
• Implements the stakeholder engagement plan
• Consults the communications management plan and implements strategies and tactics from there
• Reviews other management plans and project artifacts, such as the:
Stakeholder register -/ Change log
Issue log y Risk register
Think About it. Hopefully you are thinking holistically as you read this book. For example, the previous list
had, “Consults the communications management plan and implements strategies and tactics from there.” If you
were thinking holistically then you would have continued the thought with “and change these strategies and
tactics as needed.” If you did this, then you are on the right track to not only integrating all your technical project
management skills, but to also tailoring your project management strategies and tactics to the current situation
on the current project. This is the type of holistic thinking you want to take to everything you read in this book
and all your exam preparation.
The things you have seen in the list so far relate to technical project management skills. What about those People
domain skills covered earlier in this book and in the Stakeholder Engagement Overview section of this chapter? They are
worth repeating here and include but are not limited to:
• Consult the team when working to address issues
• Collaborate with stakeholders (including the team) to build (and maintain) trust, and to influence them to help
accomplish project objectives (domain I task 9)
• Manage stakeholder expectations to balance these with project and product requirements and objectives (domain I
task 9)
• Continue to build and ensure a common understanding, avoiding as many misunderstandings as possible (domain I
task 10)
Think About It. What other ECO task may relate to this process? Quickly scan the People domain of the ECO,
and also think about how its People (domain I) tasks are related not just to this “Manage” process of the Process
Groups model, but also the “Monitor” process we discuss in the next section of this book. The same People skills
are used for both Manage and Monitor, and in fact for all Stakeholder Engagement (and other project manage
ment process) needs.
363
Methods for Managing Stakeholder Engagement

We will not provide explanations here for each of the following methods for Manage Stakeholder Engagement because
they have already been or will be discussed in this book in many different contexts. Take a moment to review the most
common methods for Manage Stakeholder Engagement, and for the overall Engage Stakeholders processes. Do understand
that because something appears in one column does not mean it is not applicable to any environment along the spectrum
from predictive-to-adaptive and hybrids in between.
Common Methods Associated with Predictive Environments Methods Associated with Adaptive Environments
- Bidder conferences (procurement) - Backlog refinement
- Change control board (integration) - Using timeboxes (e.g., a 2-week iteration)
- Kickoff (integration) - Daily standup
— Lessons learned (integration) - Release planning
- Closeout (integration; closing process group) - Iteration planning
— Project review - Iteration review
— Risk review - Retrospective
— Status - Project review (e.gs., review/refinement of velocity;
— Steering committee flexible scope for change control)
- Project review (e.g., review of project results against baselines,
also known as EVM or earned value measurement or earned
value management)
Artifacts of Manage Stakeholder Engagement

Managing stakeholder engagement may bring changes to:
• Stakeholder engagement plan
• Other project artifact updates, such as the:
y Change log y Issue log
Stakeholder register y Lessons learned
Taking another look at the Methods Associated with Adaptive Environments column in the previous
table, you would probably agree that artifacts from the types of meetings on agile projects (also called
ceremonies) are sometimes intangible, like good relationships with stakeholders (a desired outcome of
stakeholder engagement), and sometimes very tangible. Consider the following:
• Continuous improvement in stakeholder relationships This happens as a natural result of the rituals through
which agile practitioners work. Reviewing the list, just think about how many opportunities each team member and
stakeholder has to promote a common understanding.
• Gulf of execution and evaluation This gulf is bridged through short iterations (using timeboxes) followed by
iteration reviews. The customer gets to see small product increments and discuss them with the team, and in this way
clarify their own understanding of their requirements of the product and how to convey those requirements to the
team. The team in turn gets better at understanding and building what the customer needs.
• Better product integration By planning and building iteratively and incrementally, each product increment can be
right and “done” before it is integrated with the larger product being built. This should result in fewer problems with
continuous integration of product increments and with the evolving, working product.
• Can you think of other artifacts of these practices?
14.3 Exercise
The exam will present scenarios for which you will have to choose the best answer. You can practice gathering
information from these scenarios by doing this exercise. Read the following scenarios and write down your own
analysis. What evidence do you see of where you are in the project management process or about what has already
taken place before this scenario? Quick observation of what is taking place as you read a given scenario will help
you answer exam questions.
1. Scenario. A stakeholder is dissatisfied because their request was not included in the product scope. All other
stakeholders agreed on the scope but the project manager anticipates this person will continue pressing to add
their request. The project manager meets with the stakeholder to talk about why this request was not included
and to suggest they build a business case to include it in a new project.
2. Scenario. A stakeholder expressed concern about how much the project would impact their department’s
work. The project manager tells them, “I have your concern in mind. There is little probability we could
implement this without impacting your department but here is an assessment of the expected impacts, when
impacts are likely to occur, and how the team may mitigate the effects. Would you like to discuss it after reading
it?”
Answer
Here are some example analyses. Your analyses may not match these exactly, so be sure that you understand and are
confident about your and these analyses of the given scenarios.
1. Analysis. From the words “was not included,” we see the Create Scope Statement process (in the Planning
column of Rita’s Process Chart) is already complete. The project manager is anticipating “this person will
continue...” so the project managers strategy is about the future. A business case for another project is the
stakeholder’s best option. The project could be in planning or executing, but the project manager has monitored
stakeholder engagement to make this observation and is looking ahead for good expectation management.
2. Analysis. The project manager has anticipated the stakeholders concerns and has planned for mitigation
while the project is ongoing. This is good stakeholder engagement practice, which is also taking risk into
account. When reading questions, keep project integration in mind.
Monitor Stakeholder Engagement

What we learn from managing and maintaining stakeholder relationships helps Process Groups Model
ensure the planned strategies and tactics are working as intended. Monitoring PG: Monitoring and Controlling
stakeholder engagement helps the project manager know when adjustments are Process: Monitor Stakeholder Engagement
needed and when to make those adjustments. Along with fulfilling project re
quirements, the project manager needs to do the following: ECO
• Understand stakeholder perceptions of project progress Domain 1

Task 4 Empower team members
• Review and evaluate stakeholder engagement during the project to & stakeholders
enhance stakeholder collaboration Task 9 Collaborate with Stakeholders
• Adjust strategies and tactics to ensure continuous stakeholder satisfaction Task 10 Build Shared Understanding
• Update the stakeholder register to:

Domain II
Add stakeholders as appropriate Task 4 Engage stakeholders
Adjust stakeholders’ noted involvement as necessary PMBOIC Guide

y Note when a stakeholder’s involvement is no longer necessary Domain 2.1 Stakeholder
565
Artifacts that feed into (or are inputs) to this process include the stakeholder engagement plan, the communications
management plan, the resource management plan, the issue log, and the lessons learned and risk registers. Does this sound
familiar from the previous process of Manage Stakeholder Engagement? Outputs from one process are often inputs to the
next process.
Methods for Monitoring Stakeholder Engagement

Monitoring stakeholder engagement requires the project manager to collect and analyze data. When engagement strategies
and tactics are not working they need to analyze why those strategies are not returning the intended results. The stakeholder
engagement plan should specify how this analysis and evaluation will be accomplished, who should be involved, how the
results should be documented and presented, and how changes will be handled. If a large change will affect the performance
measurement baseline in any way then a more formal change request is needed; but the project manager can and often
does make many small changes to stakeholder engagement strategies and tactics without formal change requests.
Utilizing Data
Look at figure 14.9. When using data to compare actual to planned engagement levels, there may be variances that need a
response to bring stakeholder engagement to the desired level.
FIGURE 14.9 Utilizing work performance data to compare actual to planned engagement
How do you analyze the work performance data related to relationships? You should have established in your
stakeholder engagement plan some measurable performance metrics regarding stakeholder engagement. You might, for
example, use one of the following data analysis techniques to help you figure out if adjustments need to be made to maintain
stakeholder engagement:
• Root cause analysis
• Alternatives analysis
• Stakeholder engagement assessment chart
Work performance data and metrics are useful for analyzing the quality of relationships, but keep in mind that some
of this assessment will also be subjective.
Think About It. Here’s a scenario: An activity is behind schedule because a stakeholder hasn’t provided a needed
component. This delay might point to a problem with stakeholder engagement or a different issue. You should
analyze and work to address the problem and improve the situation, as in the following example.
Figure 14.10 Analysis of stakeholder engagement issue 366

In figure 14.10, the conclusion is that the strategy and time estimates are fine but the work assignment has to be
re-evaluated. We do these types of evaluations informally all the time. Just be sure you are not forgetting any artifacts that
need to be updated. If the person wasn’t answering their phone because they are never at their desk, for example, you may
need to change the strategy in the stakeholder engagement plan for working with this type of stakeholder in the future.
14.4 Exercise
Read the following scenario and write down an analysis of the information that would be useful in answering an
exam question based on this scenario. For example where are we in the project management process (initiating,
planning, executing, or monitoring and closing)? What other information can you gather from the scenario?
Your analysis may not match ours exactly but make sure you feel comfortable with your answer and ours. The goal
is to practice quick critical thinking. By practicing analyzing scenarios, you will be better prepared to do it quickly
and confidently during the exam.
Scenario. A project manager notices someone has become less involved in the project. The stakeholder gave
helpful opinions on the earliest deliverables, but now they are less involved in the project. The project manager
contacts the stakeholder to say, “I miss your feedback and always appreciate it. Is there a reason for less input from
you? Is there anything I can do to support your further involvement?”
Answer
Analysis. We are in executing (since there have already been deliverables produced). With more information we
might determine we are in monitoring and controlling. We could be using a predictive, adaptive, or hybrid approach.
Communications should be personal (a phone call or visit versus email, for example). Wording and tone of voice
should be carefully considered since we want to encourage the stakeholder and not offend them.
Communication
Communication plays a large part in helping the project manager discover and correct engagement problems. To maintain
strong engagement and relationships with project stakeholders, the project manager needs to use whatever methods are
best to work with stakeholders. They need to use the appropriate communication method that works best for each
stakeholder. Some like texts, others like calls, still others prefer face-to-face communications.
Interpersonal and Team Skills

The project manager can of course ask questions like, “How are things on the project going?” But assessing the strength of
relationships with stakeholders and of their engagement with the project often requires more complex communication.
Interpersonal skills will help identify issues or concerns that need attention. To further understand how stakeholders feel,
use skills in these areas:
• Asking questions and active listening • Facilitation
• Attention to tone of voice and body language • Mentoring
• Emotional intelligence • Negotiating
• Leadership
567
Artifacts of Monitor Stakeholder Engagement

The purpose of monitoring stakeholder engagement is to ensure that the implementation of stakeholder strategy is
happening as planned and is meeting stakeholder requirements. The project manager and the team will have work
performance information with which to decide if a change is needed to stakeholder engagement strategies and tactics. As
changes occur there will likely be a change to project artifacts. Monitoring stakeholder engagement results in:
• Work performance information—an analysis of work performance and validating data about individual and
group engagement
• Change to improve engagement of some stakeholders through different or revised strategies and tactics
• Updates to the project management plan
• Other project artifact updates, such as:
Stakeholder register 4 Issue log
y Risk register y Lessons learned
Stakeholder Engagement in Agile Environments

Predictive and adaptive environments have many stakeholder engagement philosophies and practices in com
mon, although they manifest differently in agile versus plan-based approaches. So far in this chapter we have
put a particular focus on the following agile practices in the context of the Process Groups model. Here we’ll
elaborate on each a bit more:
• The product owner The product owner is an agile team member whose specialty is prioritizing the backlog. The
product owner represents value management for the project. They collaborate with the development team to prepare
prioritized backlogs sufficient to develop small increments of product with each iteration. This process ensures the
continuous delivery of value to stakeholders. During an iteration the product owner answers questions for the
development team and prepares the backlog for the next iteration. As an integral team member, they participate in
planning meetings, iteration reviews, and retrospectives.
• Personas This concept was described earlier in this chapter. Personas amount to an understanding of the old adage
that “walking in someone else’s shoes” helps us understand them a lot better. In this way team members can get a
better feel for and understanding of what each stakeholder (or stakeholder group) needs from the product.
• Stakeholder engagement planning We said previously that stakeholder engagement plans are often informal on
agile projects. This is because stakeholder engagement strategies and tactics are built into the iterations cycle. The
project manager and team design, build, review, and deliver in constant collaboration with the customer.
Also mentioned in this chapter are the following concepts related to the ECO’s People domain. The following skills
are completely relevant along the spectrum of plan-based to agile and hybrid approaches, and are covered in more detail in
the People domain section of this book.
• Conflict management • Facilitation
• Emotional intelligence • Negotiation
Also from the People domain, the following are described as more particular to agile practices.
• Knowledge sharing and knowledge transfer • Participatory decision making
Agile Information Radiators

Information radiators are large visible displays of project information, typically appearing in the team’s work area. The
purpose is to make it easy for the team to work together and give easy access to the information to other stakeholders.
Some of the examples below are illustrated in this chapter and others are explained in more detail in other chapters.
• Kanban boards (storyboards) • Continuous integration views
• Release maps • Burndown/bumup charts
568
Kanban Boards
“Kanban” is a Japanese word meaning “signboard” or Story Task Task In Task Story
“billboard.” Kanban boards can be used for many things in Ready Ready Progress Done Done
agile, and they are perfect for sharing information with

s^
stakeholders. Figure 14.11 illustrates a board showing s Task Task I Task Task | Task Task
work in progress that uses sticky notes to describe stories | Task | ~| Ta*fTiak |
sa
to be built. It is low tech and easy for a co-located team. As Ta*^Ta*j~Ta8(i |
the stories move through production from start to finish Task Task f 1
J-----V Task
the sticky notes are being moved from a “Waiting” column
to “Design,” “Develop,” “Unit Testing,” “Integrated
Testing,” and “Completed.” How the columns are named is Figure 14.11 Kanban board (story board)
tailored by team and project, but the board displays the showing work in progress (co-located team)
status of all work currently in progress. This makes it easy
for any stakeholder to see how work is progressing.
There are electronic tools that serve this function. Digital Kanban boards are becoming more common since teams
are more geographically distributed.
Agile Definition of Done

Agile’s careful attention to the “definition of done” is related to scope management. In stakeholder engagement it is
important because it ensures a common understanding of “done” for each story, for all stakeholders—team and customer
alike. Each story on an agile project must have a definition of done, often talked about as being “on the back of the story
card.” To better understand this, take a look at the following example of the definition of done for a book chapter.
Example product increment: The Introduction chapter of a book, draft 1 (of 2).
Definition of done for Draft 1:
• Draft complete • Line-edited
• Reviewed for content (team and customer) • Post-edit review complete (team and customer)
• Revised for content
Agile Modeling
You have already seen an example of agile modeling. What is a persona if not a model of a particular type of user of the
product? Other types of agile modeling focus on the product. Product modeling includes but is not limited to the following,
which are commonly used with predictive approaches too:
• Use case modeling • Wireframes
• Process models • High-fidelity prototypes
• Low-fidelity prototypes
With the exception of high-fidelity prototypes the emphasis is not on the exactness of the model but on the
communication between the team and customer as they create the model together. In communicating to create a model
together the customer gets a better idea of what their needs are and the team understands better how to build it. Following
are examples of the models just mentioned.
369
Figure 14.12 shows a use case diagram for a workforce tracking system. This type of model shows the product (a
system) in the middle and actors (users of the system) on each side. The lines indicate parts of the system a particular user
will interact with. Can you imagine how much better this model would be if the team worked on it with the users of the
system rather than if they had just created it themselves using their own assumptions?
Workforce Tracking
Union Management
Figure 14.12 Workforce tracking system use case diagram
Figure 14.13 is an example of a low-fidelity prototype of a website for the patient account information on a clinics
patient portal site. It acts to help envision process flow for using the page too.
Account Info
Homepage
Accept Left Nav.

Changes
Log Out
FIGURE 14.13 Process flow for using a page on a clinic's web page portal
570
The following process flow diagram illustrates a process flow for a clinics payment process (figure 14.14).
Figure 14.15 shows a low-fidelity prototype for the home page of the clinics web page client portal. You can imagine
a friendly exercise with a whiteboard and the customer here.
Welcome [First Name]

1 Home My Health Info Logout
V My Health Info Health Summary Home
Test Results
Preferences
^■Communications Medications List
Help
Appointments Communications
$ Billing Inbox
Request Prescription Renewals
£! Library
Appointments
Search
IP 1 Schedule an Appointment
Cancel an Appointment
FIGURE 14.15 Low-fidelity prototype for a patient portal

Wireframes can be created with software to mock up what a software product will look like. Figure 14.16 illustrates a
wireframe. These are especially helpful because it is difficult for customers to picture how a computer program might be
laid out.
FiGIIRF 14.1 6 Wireframe nf a tnavie rental nite screen

For the exam, keep in mind that stakeholders are important throughout the project. You need to identify all of them (or as
many as possible), as early as possible, and plan how to manage their requirements, expectations, influence on and engage
ment with the project. You also need to periodically update the stakeholder register as you learn new things about your
stakeholders and perhaps uncover new stakeholders. You need to cultivate good relationships and communications with
them, and most of all, ensure that the project delivers their approved requirements and that the features and functions of
the product and service are easy to use and satisfactory.
Please revisit the Quicktest at the beginning of this chapter. Have you been able to fill the gaps you identified when
you began the chapter? Most people still have gaps remaining at this point. Go through the chapter again to review the
areas you are still unsure about. Then complete the following chapter review.
Here is an example of working with stakeholders for the construction of a new library. Pay attention to the stakeholders
involved and how the project manager keeps them engaged.
Case Study to Build a New Library

The project manager assigned to build a new library in a small city identifies hundreds of stakeholders, including the
citizens of the community, town council members, the head librarian and staff, and the mayor of the city. The project
manager s research reveals that the mayor s term is three years and historically, few mayors are elected for more than one
term. The head librarian has run the existing library for twenty-five years and grew up in this city. She knows everyone! City
council members represent various groups and at least two of them are always running for re-election. About half of them
campaign on cutting city taxes. Although the funding has been approved, keeping the council members engaged will be
important.
Many of the requirements have been identified in the project scope statement but the project manager meets with the
head librarian to ask how they can best support the needs of her and her staff for serving their customers. She reports that
retired folks, children, and job seekers are the most common visitors to the library, and that there is a need for new
technology options to support the traditional resources of books and periodicals. The project manager asks the head
librarian if they can meet weekly during the construction process to stay on top of progress.
The project manager also meets with several city council members who want to lower taxes to ask their thoughts on
the current library and its importance to the community. The project manager offers to attend city council meetings every
three months to report progress. The project manager identifies a local newspaper reporter and asks for space in the paper,
quarterly, to share progress on the library with the community. The project manager promises to keep the reporter updated
monthly on news related to the library. vr
14.5 Exercise
Answer the following questions about stakeholders in the library case study. After you have finished answering the
questions, look to the next section for a good possible answer to each question.
Question
1. What additional stakeholders might be considered ?
2. How important is the mayor as a stakeholder?
3. How important is the head librarian?
4. Why did the project manager meet with the city council members in favor of tax cuts?
5. Why did the project manager contact a newspaper reporter?
6. How will the project manager monitor stakeholder engagement?
7. How did the project manager demonstrate servant leadership?
Answer
The answers to the questions in the following table may not match exactly what you came up with but the one thing
you should ask yourself is “Have I answered the question adequately in relation to the sample answers given?”
Sample Answers
1. Additional stakeholders could include:
• Book publishing companies
• Technology and equipment suppliers
• School admins, PTA (Parent Teacher Association) groups
2. Moderate, short term but high influence through public visibility.
3. High, she is a long-term community member and the expert on the library’s value to
the community.
4. They will probably be most resistant out of fear that the new library will raise taxes or keep
them the same. The project manager needs to work hard to get resistant stakeholder to
support the project.
5. Engaging the community will be important and the newspaper is a good way to give
information and get feedback (letters to editor).
6. City council meetings, feedback from newspaper articles, weekly meetings with
head librarian.
7. Meeting with head librarian to ask for help. Community outreach through local newspaper.
573
Section V
Domain III: Business Environment
The Examination Content Outline (ECO) specifies that Domain III covers 8% of the exam. The presentation of the business
environment as a separate ECO domain helps you focus on understanding the organization in which you work and the
environment in which it does business. Understanding the business and environmental factors are critical to accomplishing
project objectives for the betterment of your organization and its stakeholders.
In this section, we discuss delivering benefits and value in the business environment. Do not underestimate the
importance of this section. Understanding the business environment within which a project operates allows a project
manager to respond appropriately in order to deliver the benefits and value for which the project was undertaken.
575
576
QUICKTEST
15 Compliance and • Value chain

• System
• Complexity
• Compliance
Delivering Value -
-
-
Governmental
Societal
Organizational
governance
- Project management
• Systems thinking
Introduction • Value delivery
• Stewardship
As we prepare this chapter for publication, the first snow of the winter season falls here in the US state • Minimally marketable
of Minnesota, where RMC is headquartered. We have been getting used to the cold again, and calibrat feature (MMF)
ing our heating units to warm our homes while using as little energy as possible. Our coats have been • Organizational culture
pulled from the closets and our winter wardrobes are, hopefully, ready. Now for the first time this sea • Transitional change
son many of us are thinking about the immediate commute home or the snow removal chores, or both.
Many are lamenting fall chores that remain incomplete. There is an endless cycle of changes to the en
vironments in which we live and of people adjusting to those changes. We and the environment in
which we live are inseparable. This is a good metaphor for the project and the business environment.
Understanding the business environment within which a project operates allows a project
manager to respond appropriately, in order to deliver the benefits and value for which the project was
undertaken. It is important to have a sophisticated understanding of the business environment because
the business environment influences the project. The project and its outcomes also have an influence
on the business environment. They are integrated and inseparable. Do you consider the business
environment when managing a project? Do you understand how business environments, internal and
external to the organization, may impact and are impacted by your project?
The term “business environment” can mean many things. The first task of domain III in the ECO
addresses project compliance as it relates to security, health and safety, regulatory, and other policy-
related requirements internal or external to the organization. It’s important for a project manager to
elicit all compliance-related requirements. Its also important for the project manager to ensure all
project-related work remains in compliance with those requirements. The second task of domain III is
specifically for delivering the project’s benefits and value.
The last two tasks in this domain involve managing change. The third task is about addressing
external business environment changes as they may impact scope, and the fourth is about supporting
(internal) organizational change.
PMI states that this domain makes up only approximately 8% of exam questions, but do not
underestimate its importance. It has, after all, an entire domain devoted to it. An exam question may
be on any project management-related topic, including the Business Environment domain.
Understanding business environmental factors will likely help you on the exam just as they will help
you in your real-world experience.
Definitions Related to Compliance and Value Delivery

Following is some basic vocabulary that is used throughout discussions of general management,
project management, and in this case the business environment. These terms may not be used often in
this book but for the exam it is assumed you know and understand them.
577
Compliance and Delivering Value FIFTEEN
Compliance
In a project management context, compliance can mean adherence to:
• Delivering product scope in accordance with the • Project constraints
strategic objectives the product is meant to meet or • Project and product requirements
help meet for the organization and its stakeholders • Guidance from the PMO regarding project
• Organizational rules and guidance related to health management practices within the organization
and safety, human resources requirements, and other (tailored to a specific projects needs)
internal operational needs • External regulatory rules and guidance
Value Chain
A systematic series of steps that go into the creation of a delivered product is called a value chain. The value chain identifies
each step in the process from inception to delivery. This is an important concept because everyone’s purpose on a project
is to seek to deliver value at every step along the value chain.
Example The product is a homemade apple pie made from fresh local apples. Here’s how the value chain may
be expressed.
- Serve
- Sell
- Deliver
To orchard Get apples To grocery Get other To home Prep kitchen Prep Bake pie Cool pie - Eat
ingredients ingredients
Figure 15.1 Value chain for pie product
Value Stream Mapping

This is a lean concept (more about lean in the “Agile Methodologies” chapter). In value stream mapping a team (in our case
the project team) visualizes, discusses, and analyzes all steps in a product delivery process in order to eliminate waste and
gain efficiencies in that process.
System
A continually interacting and interdependent group of items or activities. Some parts of a system may work alone or jointly
with other parts in a system, while other parts work only within the system and have no independent use.
Complexity
Projects are inherently complex; they are composed of many interrelated parts. These many interrelated parts stem from
the characteristics of the project itself and also from interrelated systems that project managers work with on projects,
which belong to organizations, which belong to society as a whole. This will be explained in more detail later in this chapter.
Overview of the Examination Content Outline Business Environment Domain

Before we discuss the tasks in this domain, take some time studying figure 15.2 along with the ECO. Figure 15.2 illustrates
that people and processes exist within the business environment. For projects and for the exam, thinking holistically about
everything that is in the ECO is important.
578
FIFTEEN Compliance and Delivering Value
Business Environment
• Project compliance
• Deliver benefits and value
• External business environment changes—impact scope
• Support (internal) organizational change
Process Domain - Planning and managing
• Integration: Methodology & practices, planning,
executing with urgency, changes and artifacts, ensuring
knowledge transfer for continuity, closure/transitions.
• Constraints: Scope, schedule, cost, quality, and resources.
Procurement is related in that with it we acquire and
integrate part of the project's scope from externally.
• Uncertainty: Risk
• Relationships: Stakeholder engagement and
communications. These are at the intersection of people and
processes. (See "Relationships” under People.)
People Domain - Leadership and Performance
• Leadership Skills: The backbone of all people Figure 15.2 All domains: people and
domain capabilities. processes exist within the business environment
• Build Performance: Build a high-performance team;

engage stakeholders.
• Support Performance: Support performance for all stakeholders.
• Relationships: Stakeholder engagement and communications. Use People domain skills. Provide servant leadership to
establish/ensure a common understanding and get work done through others.
Think About It. Take out your ECO and compare the tasks in its three domains to the information presented
in figure 15.2. In this figure we have incorporated the three ECO domains and summarized them. Can you plot
the corresponding ECO tasks within this figure? Can you naturally think holistically about ECO tasks so that
thinking about any one task makes you consider others as well? Cultivate that capability for the exam.
Figure 15.2 encompasses all tasks but also implies relationships between the tasks in the three domains:
• The business environment is the larger of the three circles because people and processes exist within it. A project exists
within this environment as well. A holistic view of projects and the environment in which they exist is essential to
success as a project manager.
• The Process domain contains tasks that describe the work enabled by the technical project management skills and
processes. It includes tasks related to planning and managing integration and a projects constraints. Remember that
all project constraints must be balanced on a project. This means prioritizing them against one another to resolve
competing constraints.
• The Process domain includes planning and managing uncertainty, meaning the risks (both opportunities and threats)
are inherently part of any project (and any business environment).
• Stakeholder engagement and communication on projects each have processes and therefore have associated technical
project management skills, but like everything else on a project they do not stand alone. The skills needed from the
People domain underpin the relationships necessary to be successful in these areas.
• The People domain is about acquiring and using skillful servant leadership capacities in order to build and support
performance for the team and also for all other stakeholders associated with a project. We are all in it together.
• Again, even with the best process and technical management skills, there can be no success without the skills described
in the People domain. People domain skills enable the successful relationships needed throughout project work and
throughout projects, to be successful.
579
Now let’s take a closer look at each of the four Business Environment domain tasks. These tasks encompass all
processes in the Process Groups model and all domains in the PMBOK* Guide.

Domain III All processes All domains
Taskl
Plan and manage project compliance Also see sections 2 and 3 of the
Standard for Project Management
Task 2
Evaluate and deliver project benefits and value
Task 3
Evaluate and address external business
environment changes for impact on scope
Task 4
Support organizational change
Planning and Managing Project Compliance

Like the term “business environment,” the term “compliance” can mean many things. Process Groups Model
Compliance regulations, rules, and guidelines can come from many places: a govern All processes
mental regulatory body, an organization’s management structure, a particular manager or
director, a project manager, a project charter, or a team charter. Here are some compli ECO
ance categories: Domain II

Task 1 Plan & manage
project compliance
Business Environment (Organization) Project (Manage & Control)
• Health and safety • Project and team charters PMBOK? Guide
• Security • Project constraints (scope, schedule, All domains
• Financial cost, quality, resources)

• Regulatory • Quality
• Environmental • Procurement
• Social • Agile processes and methods
• PMO policies, procedures, etc. • Performance measurement baseline
The above table is just an example of categories in which compliance requirements may fit. These categories are not
mutually exclusive. For example “PMO policies, procedures, etc.” could easily fit into either of the columns in this table.
Example The PMO exists to support project management and so provides project management guidelines to follow,
such as monthly project status reporting to the executive committee. PMO policies and procedures, many of which are just
guidelines, are related to a particular business environment within an organization. The project manager handles compliance
with the PMO s guidelines as necessary on their project. But these guidelines are developed within an organization in the
context of the larger external business environment, with its market and societal forces affecting the organization and
its projects.
Next, we’ll discuss compliance as it relates to the business environment. These are the compliance concepts that can
be most closely mapped to domain III, task 1 of the ECO (plan and manage project compliance).
Business Environment Compliance Requirements

As we’ve said before, it’s important for project managers to elicit all compliance requirements. Compliance requirements
from the business environment generally belong to one of two subcategories: compliance requirements related to
government regulations and societal norms (which are external to the organization), and compliance requirements related
to the performing organization’s internal structure and governance.
580
Governmental Regulations and Societal Norm Compliance

There is no doubt that regulatory compliance is mandatory. Regulatory compliance is the sole impetus for many projects,
and it is at least a component of many more. Examples include:
• Existing organizations of any type must research legal and regulatory aspects of any project selected by the organization.
• New regulations mean all organizations of a certain type must comply and this may require projects to implement
product, process, or service changes.
• Changes to existing regulations mean compliant organizations must charter projects to undertake the work to remain
in compliance.
• A new organization must include regulatory research and compliance projects along with other start-up-
related projects.
• An organization that has been found to be noncompliant by a regulatory body must comply by a certain date.
Regulatory compliance often includes significant work to study and interpret the relevant regulations, research and
determine their impact to the organization and/or its projects, further work toward validating what has been learned
before business requirements can be elicited, and a solution can be designed and implemented. The following practical
examples of regulatory compliance situations can help you understand regulatory requirements in various
organizational contexts.
Examples
• A healthcare organization that must ensure an upcoming technology upgrade project for their patient portal includes
requirements for compliance with HIPPA (Health Insurance Portability and Accountability Act) regulations.
• Abank that wants to change a key business process must include in their project a compliance analysis and requirements
elicitation phase. The resulting deliverables include compliance requirements for each related project in the program.
• A US state must prepare an annual report on violations of the national primary drinking water regulations incurred by
public water systems.
• A new school that is opening must research, elicit, and implement regulatory requirements associated with their
responsibilities related to civil rights compliance in child nutrition programs.
In addition to regulatory requirements, organizations must seek to understand and comply with acceptable societal
norms. These could include things as seemingly obvious as a dress code in a particular industry—compare working at a
bank versus planting trees for a landscaping company; think of constructing a building and immediately a hardhat comes
to mind for many. Norms also include things that we may think should be taken for granted, but this is not always true. This
includes the “norm” of a safe and friendly workplace environment. Everyone would agree with this expectation, yet the
news is replete with stories about violations of this “norm.”
Societal norms change and are always evolving. An example affecting the organization and society at large is evolving
environmental practices related to everything from recycling to green building and wildlife-friendly landscaping, to
creating product development, manufacturing, and support practices that are more environmentally sustainable.
Can you see that no one practice fits neatly into a single governance category? For example, your organizations
governance may be ahead of the larger society in developing more environmentally sustainable product development
practices, which will in turn affect how new product development projects are governed within your organization.
Eventually your organization s practices or similar ones may become regulatory in nature as new environmental regulations
are passed. Everything is connected.
Organizational Governance Compliance

Some types of compliance are related to internal organizational rules and guidance already in place. Such rules and guidance
may be related to internal human resources and health and safety policies and procedures, for example—some or all of
which will be tied to regulatory governance. Other organizational governance may be based on the hierarchy, culture, and
operations of the organization itself. These will include all the policies and procedures set up by the PMO to help portfolio,
program, and project managers. Examples of organizational governance practices and artifacts include the following:
• Tools, templates, and procedures set up by the PMO for project management, for example:
>/ Project charter and scope definition templates
•/ The PMIS (project management information system) to be used for saving project artifacts and project
knowledge sharing
y Guidance on functional and project managers managing resources on projects
y Documented practices specific to the types of project life cycles and development approaches used by the
organization, from predictive to agile or hybrid
• Management organizational governance relates to:
y Procedures and communication guidance for taking PTO (paid time off)
y Guidance and established practices ensuring employees fair and equitable treatment
y Guidance on how to lodge a complaint against management
y Suggestion for the company’s continuous improvement in any area of the business
Project Management Compliance

The organizational practices and tools supplied by the PMO are taken into consideration by the project manager as they
tailor governance to their specific project, starting in initiating and planning. The following list gives examples of compli
ance requirements specific to a project. Some of these compliance requirements come from the organizational environ
ment while others are specific to skillfully managing a particular project.
• Project governance must stem from organizational governance. A project’s governance must be created with awareness
of and in compliance with organizational guidelines and rules applicable on the project.
Example A project manager needs to understand and use company policies and procedures regarding the hiring
of new employees or contract employees for the project.
• The project manager needs to integrate regulatory compliance requirements into project activities.
• Following procedures for working with the procurement department for help with project procurements is usually
necessary. There may be approved suppliers and subcontractors the project manager will need to use on their project.
• Integrated change control procedures and change request templates are typically tailored to a project but necessary to
change management efforts on plan-driven projects.
• On agile projects the product owner typically presides over change requests related to scope, while the team works
together on changes to methods of building the product and the project manager ensures that the agile methods in
play are understood and being followed.
• Project managers must exercise conscientious stewardship over the project so it can meet its requirements and
objectives while remaining in compliance with project constraints (scope, schedule, cost, quality, risk, resources). To
do this, balancing competing constraints is often necessary.
Delivering Value
When you are handed a new project to manage, do you automatically say to Process Groups Model
yourself “let me see what value this project is meant to deliver to the organi All processes
zation and our stakeholders?” Probably not in those words, but you may do
the equivalent of this. You quickly look for the reasons your organization ECO
selected the project (the business case), and what deliverables and outcomes Domain III
Task 2 Evaluate & deliver project benefits & value
the project needs to deliver (project goals, objectives, and value). You are
also thinking about how you can do your best and inspire others to do theirs
PMBOK8 Guide
so that the project will be successful.
All domains
Also see sections 2 and 3 of the Standard for

Project Management
382
fifteen Compliance and Delivering Value
Systems Thinking
Project managers need to understand and practice systems
thinking. Organizations exist as systems of value delivery for
Stakeholders/
their stakeholders. To that end any organization—company, Customers
non-profit, or governmental agency—exists within the
context of many systems working together for mutual benefit.
Figure 15.3 illustrates some of the many systems within
Economy
which an organization exists and interacts, to deliver value to
its stakeholders.
As discussed earlier in this chapter, organizations
support compliance based on the regulatory environment.
Organizations also interact within a variety of contexts: the
location in which it operates, markets and competition, avail
able technologies, and current economic and regula
Technology
tory forces.
Competition Landscape
Now, you probably already know why projects exist.
Think About It. Projects exist to create and deliver

very specifically defined value to the performing Regulation
organization and its stakeholders. Like an
organization, a project is a system of value delivery.
Each project is undertaken to deliver a subset of the total
Figure 15.3 Organization and external
value the organization seeks over time to deliver to its systems it interacts with
stakeholders.
Figure 15.4 shows an organization as a system with

other internal systems that act alone and jointly with the
organization.
Examples are:
• The PMO
• Portfolios, programs, and other projects
• Operations
• Governance (organizational a project)
Subsystems of the organization help it deliver its
intended value to its stakeholders (and society at large).
FIGURE 15.4 Organization and internal systems

that interact with it
383
ORGANIZATIONS are complex systems that exist to deliver value to their stakeholders
(and greater society) and thus achieve their own strategic and tactical goals.
Organizational governance is a system within the organization that exists to support the delivery of value to
stakeholders. Governance is made manifest through its established framework of policies, procedures,
practices, and other guidance relevant to the organizations sustainability.
Subsystems within an organization deliver value: PMO provides a project gover

• Projects, programs, portfolios and the PMO that governs them nance framework (based on
• Products and services (results of portfolios, programs, and organizational governance) to
projects) standardize on:
• Operations (support of products and services; sustaining functions • Tools, methods, templates, etc.
like human resources, finance, and other functional groups) • Guidelines for compliance
These must work alone and jointly. • Guidance, resources
Project governance guides Program governance helps direct Portfolio governance directs
project management activities guidance among allied projects guidance among allied programs
toward the goal to create the and operations work. and operations.
product of the project. • Based on organizational and • Based on organizational and
• Based on organizational and PMO governance and guidance operations governance
PMO governance and guidance • Tailored to the program and its • Tailored to a portfolio’s current
• Tailored to the project projects context
The Project As a Value Delivery System

We have established the project as a value delivery mechanism that as a project manager you have to see through systems
thinking. We have also established that a project as a system is a subset of multiple other systems, not least of which is the
organization in which it is undertaken. Let’s focus now on the project as a system of value delivery. A project creates
deliverables meant to both produce outcomes and be sustainable.
Example
• Product Scope A new library service is needed to help unemployed people use the internet to apply for jobs.
• Deliverables Computer lab upgrade, special training for library staff who will coach patrons who need help with
the technology.
• Outcome The number of people getting help with job applications will increase by X%, as measured by library staff
and quick patron exit surveys. The library has data analysis results showing the current number of people getting help
with job applications. This information can be compared to a similar analysis, monthly after project completion.
• Benefits management plan This includes the number of people benefiting from the computer lab, the number of
books checked out, and community survey results, to name a few. The service will be re-evaluated in six months and
then a year to evaluate success and assess additional needs of the computer lab or service.
15.1 Exercise
Delivering value to a large number of stakeholders is difficult. One technique often used is a survey or questionnaire.
Imagine the library project team wants to send out a questionnaire to the citizens who will have access to the new
library, to determine the potential value. What questions would you ask of these “users” of the library? Write your
answers in your Exercise Notebook before reading the possible answers below.
58^1
Answer
Here are some examples of questions you may have come up with.
• How often do you visit a public library?
• What are the services you look for in a library?
• What type of equipment do you expect to use in the library (e.g., computers, tablets, printers) ?
• How much time do you normally spend in the library during a visit?
• What types of books are you most interested in (e.g., fiction, childrens, history)?
• Do you prefer hard cover or paperback books?
• Do you enjoy working with a librarian for book recommendations?
• Would you enjoy refreshments being available in the library (e.g. coffee, sodas) ?
• Do you prefer a large reading room or smaller nooks?
Process Analysis
Think About It. At the start of this chapter we defined the term value stream. Lets look at the value stream from
figure 15.1 again, for making a pie from fresh, gathered ingredients. We’ll analyze it in terms of value delivery. The
following can serve as an example of how you go through planning and managing any project in order to deliver
the promised value as efficiently and effectively as possible. How might we make this process more efficient?
- Serve
- Sell
- Deliver
- Eat
ingredients ingredients
In the following discussion, people are shown in italics and activities are shown in bold.
• There seems to be a lot of extra driving involved if Pie Maker is doing all this. That’s a lot of Pie Maker's time plus
possibly wasted energy. Is there anyone else who can help more efficiently?
-/ Yes. Team member Grocery Getter says they can go to the grocery every day and can stop for Get other
ingredients on the way To home, since they are going there anyway for activities related to another project.
-/ Grocery Getter will stop on their way To home.
y That removes waste from two activities. It makes To grocery less resource intensive and eliminates To home
since that car trip was going to happen as part of operations anyway.
>/ It also saves some of Pie Maker’s time, plus saves other resources (gas, car wear and tear).
• What about the Get apples activity? Can we eliminate that activity and just combine Get apples and Get other
ingredients?
y No. There is a lot more value in Get apples if they are picked fresh from the orchard. That value may not be
easily measurable, but that activity is worth its value.
y Our customers will be more satisfied with this choice.
• Because Grocery Getter is saving Pie Maker time, Pie Maker concentrates more on continuous improvement to the
Prep kitchen and Prep ingredients activities.
• What about Grocery Getters time? Why don’t we just order groceries online and save more time?
y Grocery Getter can pick the ingredients they know are the best.
y It will cost more for delivery.
y We market our products as containing fresh ingredients, gathered ourselves. Let’s be true to that promise
to customers.
585
A true value stream mapping effort would have decomposed every activity in more detail than shown here.
Nevertheless, in this scenario the project manager and team were respectful and conscientious stewards of the time and
other resources needed in the “make fresh apple pie” process. They were aware of how another project could affect theirs
and used that information. Team members contributed ideas to eliminate waste and gain efficiencies in resource use and
adding value. They acted with integrity in keeping with their assurances to customers and practiced continuous
improvement as part of the process.
How We Deliver Value on Projects

People are assigned to projects largely for their technical skill, but technical skill alone does not make anyone successful.
The project manager and the team must work together to deliver the promised value of the project and product scope, and
that takes interpersonal and team skills. A knowledgeable, talented, and conscientious project manager works to deliver
value on projects in everything they do, and the same can be said of the team. All work together to deliver the product of
the project and to set up its transition to operations so that the product has the best chance of providing the continued
benefits for which it was created. This book discusses in detail the many ways in which the project—as a system—does
this. Let’s turn to the principles that can guide these behaviors for the project manager and team.
Think About It. Project management and delivery behaviors are informed by People and Process domain skills,
but they should also be informed by a set of principles. As a connection to the business environment, and to the
working environment and your place in it, think about the principles that may guide the behaviors of the project
manager and team as they work avidly to deliver value through project and product scope. PMI has suggested
twelve project management principles in the current Standard for Project Management that is published with the
PMBOK* Guide, Seventh Edition. You will find most or all of them familiar.
Project Management Principles

Stewardship This is about acting with care and integrity, and establishing and maintaining trust. In managing projects for
the organization and the larger business environment, working together is easier on everyone when a trusting and caring
environment is created. This is also about the careful use of resources entrusted to the project manager by the organization
and the stakeholders.
This principle can be practiced within the organization by ensuring the projects’ alignment with the organization’s
strategic objectives. Project managers can also be careful stewards of the organization’s finances; they can simply treat other
team members well and use their authority with care.
Even though long-term product sustainability is typically technically part of a particular projects scope, project
managers should understand the entire product life cycle and can always look to contribute to it through smooth and
forward-looking project transitions. Beyond the organization project managers can be careful stewards of environmental
resources. They can also improve the professions they practice as part of the larger social community.
Team As servant leaders, creating and ensuring a collaborative and safe team environment fulfils the spirit of this principle.
Safety and the resulting trust allows each team member to contribute their unique talents and skills, single and jointly with
the team. Other factors supporting safe and collaborative team environments include team agreements (for example, a
team charter), organizational structures, and processes servant leaders can help put into place.
Stakeholders This is all about how stakeholder engagement is managed. Project managers can engage stakeholders
proactively to the degree needed for success of the project and of all project stakeholders (including the team and project
manager).
Value We have already talked about a project as a system of value delivery. Project managers can continue throughout the
project to ensure that it and its product are aligned with the organization’s business objectives.
Systems Thinking Your understanding of systems and systems thinking can now help you to understand that this prin
ciple is about the project manager’s constant proactive response to a system’s dynamic and changing circumstances.
Leadership Practicing servant leadership, fostering a collaborative team environment, and carefully balancing the needs
of individuals with that of the group is the spirit of this principle.
586
Tailoring Everything you have read of the previous principles speaks to the need to tailor the approach to the project,
project management practices, and leadership to each specific project and its needs. Yes, the project manager will settle on
a specific development approach, be that plan-driven, agile, or hybrid. However, within that context all specific practices
used on a project should be subject to review to ensure it is useful to the project at-hand.
Quality A focus on quality will ensure that the product of the project meets project requirements as agreed to with key
stakeholders. Categories of quality requirements may include:
• Performance Meeting these requirements ensures the product (or service) functions as intended.
• Conformity This answers the question about the product: “Does it meet specifications and is it fit for use?”
• Reliability means consistency of performance to requirements.
• Satisfaction means the functioning, useability, and user experience of the product is to the
customer s satisfaction.
• Uniformity Are the deliverables uniform with others produced in the same manner?
• Efficiency means can the project manager and team, and does the project manager and team, achieve best
product performance with the least inputs and efforts?
• Sustainability means creating products with positive impacts on socioeconomic factors and with
environmental sustainability.
Navigate complexity Related to tailoring, the project manager should continually evaluate their approaches, methods,
and plans on the project to ensure they are in line with project (and organizational and societal) complexity. This also
includes enabling a successful project (and arguably, product) life cycle.
Risk This principle is about continually evaluating risk and the risk response plans and executions, to ensure that they are
still a good fit for the actual project risks and their impacts.
Adaptability and resiliency As a project manager, you need to build adaptability and resiliency into your own project
management practice and help enable adaptability and resiliency in the team and the organization.
Enable change to achieve the envisioned future state Every project begins with a current state. Every project is meant
to end with a desired future state brought about (at least in part) by the product of the project. Project managers enable
change to achieve that envisioned future state by preparing the stakeholders impacted by the project. They can only do this
by building effective transitions, to be carried out as part of the phase and project closing activities.
Have you noticed that two of these principles are about navigating complexity and enabling change? These are aspects
of project management that are not often given much explicit attention but which project managers focus on implicitly
throughout a project. The next two sections of this chapter address the Business Environment domain tasks that give
complexity and change the needed attention.
Evaluate and Address External Business Environment Changes for Impact on Scope
We have discussed in some detail the environments external to a project and their potential impacts. What happens as
changes occur to the external environment after the project has begun? In a predictive environment the challenge is to
continually ensure that the benefits agreed to during initiating and planning remain valid, and that the developing solution
will deliver those benefits. Small changes to the business environment may simply prompt small, approved changes as they
arise. On the other hand, changes maybe more involved and require reprioritization or reassessment and redefinition of the
projects defined scope. A scope change will also often necessitate changes to the schedule, budget, or other project con
straints.
587
For the types of projects that can use an agile approach, adaptive environments are set up from the start
to adjust relatively easily to scope changes. It is a benefit of planning a project and building a product iteratively
and incrementally. The concepts of building Minimally Marketable Features (MMFs) and delivering a
Minimally Viable Product (MVP) summarize these benefits:
• MMF (minimally marketable feature) Think of an MMF as the smallest feature that can be released into the
marketplace, which stakeholders need or will find useful.
Example What if the US decided to no longer use Daylight Savings time? All computerized clocks (like those in
smartphones) would have to have a feature update pushed to them at the appropriate time so they will remain accurate.
• MVP (minimally viable product) An MVP is a version of a product with just enough features to make it useful.
The most critical features can be used by early customers.
Example Many new cars now have adaptive cruise control, which helps the driver stay far enough away from the
car in front of them. This can decrease the likelihood of crashes. While this is a full-fledged (not minimally viable)
feature on new cars with drivers, it has capabilities that are in the “minimally viable” stage of the driverless car product,
which is still generally thought to be only experimental.
MMFs are delivered on a regular basis as updates to already existing consumer products—especially those that utilize
software. This allows the project team to learn the most about the customer and business environment with the least
possible effort, incrementally. The MVP allows the project manager and team to see how the increment of the product
appeals to the customer and how the customer uses the product. The team then uses feedback to update the product to
increase its capabilities or even cancel the project entirely as necessary.
One of the many benefits of building products incrementally and iteratively is that as the external environment
changes, agile project managers and teams can more easily change the scope of their projects to adjust to these changes.
Nevertheless, any type of project has to be managed carefully with the external business environment in mind to ensure
that the project s scope remains valid and will have the value to the customer of the product represented at the beginning
of the project. If the product scopes value changes, then project and product scope must also change.
The industry you are working in, technology, regulations, geopolitical factors, and marketplace sectors can all
experience changes that will impact your project.
Think About It. Consider these examples of environmental change:
• Your major project is to develop battery technology for electric cars. A competitor releases a battery to the
market with a capacity marginally exceeding the one you are set to achieve with your project. You will need to
lead a project change effort within your organization.
• A natural disaster affecting the region from which your project is being managed will affect your project. Risk
management planning has to take this into account.
• A regulation governing your product has expired so that your project can begin closing sooner than expected,
having accomplished all work that still aligns with the project charter. You can transition the product as-is to
the marketplace.
How do you handle environmental changes? Regardless of the type of changes taking place on your project or in your
environment, the process is the same!
1. Have a high level of sophistication about your products and services, your organization, and your environment.
2. Maintain awareness and monitor the possibility of change of any kind.
3. As potential changes are identified, evaluate the changes and their impacts.
4. Plan your response.
5. Lead the team in operating within the organization and the project to support your planned response.
588
15.2 Exercise
Part I: Review the graphic below with some of the external organizations or systems within which the new library
will exist. Can you think of one change that might impact the project from each of these?
Government Publishing
regulations companies
Local
neighborhood Patrons
and roadways
New Library
Competition Technology
City economy
External Potential change

Patrons
Technology
City economy
Competition
Local neighborhood and roadways
Government regulations
Publishing companies
Answer
Here are some possible answers. You may have come up with some additional potential changes.
External Potential change

More patrons driving to library than expected, resulting in parking
Patrons
problems and complaints.
New social media site becomes available, patrons want to use it on library
Technology
equipment, but it has some offensive content.
The city does not have enough funds to support the library maintenance
City economy
costs.
Competition A new bookstore opens near the library.
Crime in the area of the library has increased.
Local neighborhood and roadways
Traffic problems.
A new mask mandate is put into place for all government and public
Government regulations
buildings.
Publishing companies Books will begin to only be available on tablets or mobile devices.
189
Compliance and Delivering Value
15.3 Exercise
Part II: Think again about the graphic in the previous exercise, with some of the external organizations or systems
within which the new library will exist. While managing the new library project, what should the project manager
be doing to monitor the external environment for changes? Write your in your Exercise Notebook before looking
at the possible answers below.
Answer
Possible answers:
• Contact library directors in other communities to learn about their successes and challenges
• Make contacts with publishing companies and check in with them every couple of months.
• Post articles in local newspapers and websites with status reports for the project, offering an email address for
patron questions.
• Respond to questions from patrons, city council members, the mayor, etc.
• Attend city council meetings, neighborhood community meetings, and city planning meetings.
• Read the local news, looking for other projects nearby that may conflict with the library.
• Check with the construction company on current building regulations and compliance procedures
Support Organizational Change

This ECO task is about supporting changes to a project that may result from changes within the performing organization,
and changes within the organization that may result from a project or its product. Organizational culture is as important to
consider as the type and magnitude of a potential change to the project, the organization, or both.
Organizational Culture
Projects are impacted by and have an impact on internal cultural norms and organizational management policies and
procedures. These factors are increasingly important in global organizations in which team members are often working
from different and sometimes remote offices, each with its own culture. Employees of any organization must be part of the
organizations culture and comply with its policies and procedures. At the same time project managers must be respectful
of everyone on the project and the multiple cultures in which the people assigned to the project must operate. Project
managers should be able to adapt their leadership approach by understanding as much about the team and stakeholders’
cultures as possible.
Internal organizational changes may require changes to the project team, rework, schedule changes, project scope, or
even cancellation of the project. Understanding organizational culture, politics, and governance will enable the project
manager to make needed changes within their projects in ways that minimize negative effects and keep the project moving
forward. In the case of a cancelled project the project manager must be able to lead the transition smoothly.
Think About It. It is important to consider organizational culture not only when initiating a project, but
throughout its life cycle. Why? Imagine you’ve planned a project and uncovered key requirements the supporting
organization didn’t initially disclose. The plan will most certainly need to change to meet the new requirements.
But why were these requirements undisclosed? Was it an oversight or was there another specific reason the
requirements remained unexposed? How will the organizational culture be affected by these changes? Likewise,
how will these changes affect organizational culture? Will the team support the necessary changes to the project?
Will the customer support the changes? The project manager has to answer all these questions and more in order
to lead the team toward the right changes.
390
As a project manager, the more you know and understand your organizations culture, the easier it will be to answer
these questions and provide appropriate leadership to the team in the best interests of the project. Following are additional
examples of organizational changes that would affect a project:
• Your organization has merged with another company and you will lead efforts to evaluate the continued viability of
your project within the new organization.
• Your organization has changed directions and your product has become more critical to the success of the new
organizational direction. You will be given more resources to work with but need to replan the project to finish six
months earlier than the original plan called for.
• A key team member is leaving the company. You will need to negotiate for a new resource that best fits in with the
current projects progress point and the current project team’s skills.
• Your organization is closing three of the eighteen offices to which you were planning to roll out a new desktop software
build. One of the offices being closed was to have the pilot group for the product of your project. You will have to
replan the project without these offices and plan for and obtain a new pilot group.
Project Change
Project change management is discussed in further detail in the “Integration” chapter, but the following is a list of examples
of good project management practices that will help manage project changes that affect the organization.
• In traditional project management, the progression from rough order of magnitude (ROM) estimating done for
project selection is re-evaluated during initiation with the development of the project charter. This is followed by
more definitive estimating using tools like scope decomposition, network diagramming, and three-point estimating
during detailed planning. Checking detailed estimates against the project charter is important to ensure that
organizational management s assumptions about the project’s viability remain valid.
• Phase-gate systems for projects allow the team and stakeholders to pause, evaluate, and approve what has happened
so far on the project and then decide to move on to the next phase. Changes may be made to policies and procedures
at these milestones that represent updates to the organizations process assets.
• Something is discovered on a project that does not affect the project but may affect another project in the program to
which the project belongs. Escalating to the other project manager or the program manager will ensure that the issue
is taken into account for benefit of the organization.
• Integrated change control is the process of managing changes within the project, ensuring that changes to the project
are necessary and carried out systematically. If change is not managed properly on projects, it will have negative effects
on the project and thus on the organization.
• Agile project management supports a continual state of project change through iterative and incremental planning
and product development. This could mean the continual delivery of value to the customer.
Transitional Change
Why do we do projects in the first place? A project is undertaken for the express purpose of filling a business need to bring
about change of a specific nature, to the organization and its stakeholders. Before a project starts, an organization or its
customers are in an environment called a current state. The project is meant to bring the stakeholders to a future state
defined by the project objectives and encapsulated in the project’s scope and requirements. Project management is geared
toward building the product of the project. Implicit in the work of a project manager is to ensure that stakeholders can
make the transition from current to future state with as little disruption to their current operations as possible. By their
very nature, projects are about creating and managing change.
391
Think About It. However valuable a new solution is, people need help making the transition to it. Following are
some examples of how that might be managed:
• A simple change to an already existing software product is built to automatically download on stakeholder
devices and a pop-up summarizes the changes.
• A new software rollout will completely change the way processes are completed in the affected department
within the organization. The project is part of a program that includes a communications director managing a
carefully planned communications project while a training director manages an implementation and
training project.
• An already excellent product is being updated with more modem technology. Included in the new product
rollout is a trade-in and rebate program that gives customers incentives to buy the new product.
Historically projects in organizations did not give enough attention to transitions between the current state and the
future state. How would people find value in changes to the way they work without help in transitioning to the future state.
Today, projects and programs appropriately give more attention to managing transitions than was the case in the past.
For the exam you will need to understand that the changes brought to users at the end of new product or service
development projects need to be managed, either as part of the Close Project or Phase process (of Integration Management),
or as part of a separate project, depending upon the size and complexity of the change.
Change Models
PMI has published a framework for change in its Managing Change in Organizations: A Practice Guide (2013). This
framework is based on five common elements of many change models along with a series of feedback loops.
• Formulate the change • Manage transition
• Plan for the change • Sustain the change
• Implement the change
Understanding how people react to and adopt change allows organizations to better plan and incorporate changes.
Impacted stakeholders are internal and external people who need to be made aware of how and why changes affect them.
A few useful change models are described next. You may see one of these model names as an answer choice in an exam
question.
AD KAR Model
ADKAR stands for Awareness, Desire, Knowledge, Ability, and Reinforcement, which are the five steps that an individual
goes through to adapt to change. This model was developed by Jeff Hiatt in 2006 when he studied changes in over 700
organizations. The model helps change management professionals to develop communications and activities for impacted
stakeholders undergoing change at each stage of their journey.
8-Step Process for Leading Change

The 8-Step Process for Leading Change focuses on a top-down approach for the management of medium- to large-sized
organizations. John Kotter published his framework in 1995 and encourages leaders to generate enthusiasm for the change
by communicating the vision and identifying company change leaders to influence impacted stakeholders.
Virginia Satir Change Model

The Satir Model, first published in 1991, was designed to improve relationships and communication within family units
and explains how people experience change. It is also used by organizations to plan changes by anticipating expected
impacts on stakeholders. The Satir Model acknowledges that things often get worse before they get better, but they will
eventually get better with clear communication and support. Virginia Satir was a psychotherapist working in family
systems.
Transition Model
William Bridges’ Transition Model provides an understanding of how people transition through a change. Transition is a
psychological process where people gradually accept their new situation after the change. It includes stages of 1. ending,
losing, and letting go; 2. the neutral zone, and 3. the new beginning. Bridges’ model was first published in 1980 in his book,
Transitions: Making Sense of Life's Changes.
592
Section VI
Pulling It All Together
This section covers three very different but important topics. Here, we provide some important tips and tricks for passing
the PMP* exam on your first try. While these tips have evolved over the years, Rita Mulcahy provided them based on her
vast knowledge of the exam experience and they have helped thousands of our students ever since. We recommend that
you revisit these tips the day before your exam because the information they provide is invaluable.
This section will also give you a deeper dive into agile methodologies. Knowing the principles behind agile will help
you understand it better.
Finally, we give you more information about PMIs A Guide to the Project Management Body of Knowledge (PMBOK*
Guide). This important reference has gone through a transformation in the past few years and here we take a closer look at
the current PMBOK" Guide.
593
QUICKTEST
16 Tips for Passing the • Planning, predictive vs

adaptive
• Contexts for formulas
• Tips for exam preparation
• Preparing for the exam
PMP® Exam the First Time environment
Introduction
This chapter serves as a review of some of the key things you need to understand as you prepare for the
exam. Now that you’ve studied each topic individually, let’s put your knowledge and understanding all
together. Ritas Process Chartand Rita’s Agile Process Chart’" can help you connect the concepts
found in this book. By now, you should understand the overall project management process, including
all the efforts involved in it. You should also know the commonly occurring terms and concepts cov
ered in the “Foundations” chapter. Understanding these terms and concepts will help you understand
how each of these things relate to the overall project management process.
As you work through this chapter, take this as an opportunity to find remaining gaps in your
knowledge so you can review content related to your gaps and are prepared to pass the exam on your
first try.
Review of Core Concepts

Over the next several pages, we review some of the frequently occurring terms and concepts you need
to understand for the exam. This section reviews planning, working, and delivery concepts and arti
facts. There is also a section on formulas and calculations, tips for preparing for the exam itself and for
the exam environment, common project management errors and pitfalls, and several exercises to give
you more interaction with the material.
Planning, Working, Measuring, and Delivering

Planning is a key step in addressing the areas of requirements and scope, schedule, cost, quality,
resource, communications, risk, procurement, and stakeholders, as well as plans for configuration
management (or artifact version control), and change management. It is a crucial part of a project
manager s job in a predictive environment.
These areas of planning occur within agile and hybrid environments but may be less formal or
take different forms. Planning addresses the majority of questions and concerns that might come up
throughout the life of a project, and it allows the project manager and team to spend more of their time
completing the work of the project and less time dealing with issues and problems.
595
Tips for Passing the PMP® Exam the First Time SIXTEEN
Review some of the forms that planning and artifacts take in predictive and adaptive environments:
Predictive Environment Plans and Artifacts Adaptive Environment Plans and Artifacts
• Project management plan (a plan for • Release map, release plan, iteration
scope, schedule, cost, quality and plan, product roadmap
other constraints as well as other • Product and project backlogs
important project management (risk-adjusted backlog)
aspects like communications and
• Features, stories, definition of done
stakeholder relationships)
• Personas
• Assumption log, change and issue
logs, stakeholder and risk registers, • Meetings: Release planning, iteration
lessons learned planning, iteration review, iteration
retrospective
• Project life cycle and development
approach, tailored to the project • Information radiators: e.g., product
roadmap, Kanban board
• Requirements documentation
• Scope, schedule, and cost baselines
(the performance measurement • Burnup charts, burndown charts,
baseline—part of the project team velocity
management plan) • Reprioritizing the backlog
• Reporting templates and reports: • Negotiating change; expecting
Risk reports, EVM (earned value frequent change
measurement), forecasts, quality • Negotiating scope while keeping
reports schedule and cost fixed
• Project and team charters
• Procurement statement(s) of work
• Agreements and contracts
• Quality control metrics
• Assumptions and constraints analysis
SIXTEEN Tips for Passing the PMP® Exam the First Time
16.1 Exercise
Here is a way to get more familiar with the project management processes from the Process Groups model
perspective. In your Exercise Notebook, draw a chart with a header as shown here. For each process listed, fill in the
appropriate information in each column. Do not worry if you do not get it perfectly correct. It is in the practice that
you will be better at understanding these components on their own, and holistically.
What Does It What Process What Process

Project Management Process Process Group Include? Comes Before? Comes After?
Define Activities
Plan Procurement Management
Monitor and Control Project Work
Sequence Activities
Collect Requirements
Develop Project Management Plan
Develop Schedule
Validate Scope
Perform Qualitative Risk Analysis
Identify Stakeholders
Conduct Procurements
Define Scope
Perform Integrated Change Control
Answer
The answers to this exercise provide a description and the associated actions to the given process. These descriptions
align with the required interpersonal skills as well as the project management and technical activity needed.
Project
Management Process What Process What Process Comes
Process Group What Does It Include? Comes Before? After?
Define Planning Creating an activity list from each Plan Schedule Sequence Activities
Activities work package Management
Plan Planning Creating the procurement statements None Conduct Procurements

Procurement of work, bid documents, and the
Management procurement management plan
Monitor and Monitoring Measuring and analyzing Manage Project Perform Integrated
Control and performance against the project Knowledge Change Control
Project Work controlling management plan and baselines
597
Sequence Planning Creating a network diagram Define Estimate Activity

Activities Activities Durations
Collect Planning Documenting detailed requirements Plan Scope Define Scope

Requirements and creating the requirements Management
traceability matrix
Direct and Executing Facilitating and producing work Develop Manage Project
Manage according to the project management Project Knowledge
Project Work plan Management
Plan
Develop Planning Integrating all the individual Develop Direct and Manage
Project management plans and baselines, and Project Charter Project Work
Management creating a project management plan
Plan that is bought into, approved,
realistic, and formal
Develop Planning Creating a bought into, approved, Estimate Control Schedule

Schedule realistic, and formal schedule and Activity
schedule baseline Durations
Validate Scope Monitoring Meeting with the customer to gain Create WBS Control Scope
and formal acceptance of interim deliverables
controlling
Perform Planning Analyzing the probability and impact of Identify Risks Perform Quantitative Risk
Qualitative potential risks to determine which risks Analysis (don’t forget,
Risk Analysis might warrant a response or further however, that some
analysis projects, or individual
project risks, may skip this
process and go straight to
Plan Risk Responses)
Identify Initiating Identifying, documenting, and analyzing None Plan Stakeholder

Stakeholders information about stakeholders on the Engagement
project
Conduct Executing Selecting a seller and obtaining a signed Plan Control Procurements
Procurements contract Procurement
Management
Define Scope Planning Creating the project scope statement Collect Create WBS
Requirements
Perform Monitoring Evaluating the impact of requested Monitor and Close Project or Phase
Integrated and changes to the project and approving or Control Project
Change controlling rejecting change requests Work
Control
598
16.2 Exercise
If you found this exercise helpful, you may want to continue to test yourself on other processes not listed here, and
review your answers against the process descriptions in this book. In this exercise for plan-driven projects, read
each scenario and write down what process you are in when you are doing the activity.
Scenario
1. When meeting with the customer to obtain acceptance of interim deliverables
2. When measuring project performance against the performance measurement baseline
3. When making sure people are using the correct processes
4. When evaluating whether performance reports are meeting stakeholders’ needs
5. When working with the project team
6. When assessing stakeholder relationships
7. When you notice that there are many unidentified risks occurring
8. When evaluating a seller’s performance
9. When evaluating team members’ performance
10. When making sure deliverables meet quality standards
11. When communicating with stakeholders to resolve issues and manage their perceptions about the project
Answer
Processes Being Described (on Plan-driven projects)

1. Validate Scope
2. Control Scope, Control Schedule, Control Costs
3. Manage Quality
4. Monitor Communications
5. Manage Team
6. Monitor Stakeholder Engagement
7. Monitor Risks
8. Control Procurements
9. Manage Team
10. Control Quality
11. Manage Stakeholder Engagement
599
16.3 Exercise
Now let’s switch it up for agile. For agile projects, read each scenario and write down what activity you are engaged
in for the given scenario, or what tools or methods you would use to perform the activity. A variety of activities may
fit the description for any one scenario.
Scenario
1. When meeting with the customer to obtain acceptance of interim deliverables (from the iteration)
2. When performance is measured against the performance metrics
3. When making sure people are using the correct processes and how do they do it
4. When and where teams evaluate whether project performance is meeting stakeholders’ needs
5. When working with the project team; helping the team
6. When assessing and ensuring good stakeholder relationships
7. When there are unidentified risks occurring (What to do?)
8. When evaluating a seller’s performance
9. When evaluating and helping improve team members’ performance
10. When making sure deliverables meet quality standards
11. When communicating with stakeholders to resolve issues and manage their perceptions about the project
Answer
Processes Being Described (on Plan-driven projects)
1. Product owner works with stakeholders to prioritize backlog items; iteration (or Sprint) review meeting
2. Average team velocity, burnup charts, burndown charts; retrospectives where team reflects on their
own performance
3. The project manager (agile coach, team lead, Scrum Master) uses servant leadership to help the self
organized team to refine and follow their agreed-upon processes
4. Iteration review (Sprint review); communication on a daily basis with the product owner (customer);
retrospective; face-to-face communication
5. Servant leadership; ensure teams are adequately trained; remove impediments
6. Face-to-face and other communication methods; product owner (customer representative) as integral
team member; continuous delivery of value; iteration review meeting
7. Re-evaluate risk frequently; reprioritize the risk-adjusted backlog
8. Agile contract; control procurements; iteration reviews
9. Servant leadership; ensure adequate training; remove impediments; team retrospectives
10. Team organizes their own work; team controls quality, works with product owner; team checks their own
work; avoid errors and ensure better design through paired programming
11. Working with product owner to assure stakeholder priorities are considered; ensure a common
understanding; manage stakeholder engagement
400
The Significance of Quantitative Measures on the Exam

Hie exam will not include a lot of questions requiring you to perform calculations. However, it is important to understand
the contexts in which formulas are used in project management.
Think About It. There are few formula questions on the exam. You must choose whether or not to memorize all
or some of these formulas for the few exam questions you may see that use calculations. Regardless, you should
use figure 16.1 to review the chapters in this book in which the formulas appear. Knowing the contexts in which
the formulas are used will help you get questions right. For instance, even if you are not asked to calculate SPI
(schedule performance index) or CPI (cost performance index), or to calculate EMV (expected monetary value
of a risk), you should know the answer. Here are two example questions to try.
Example 1 The project manager is working for a pharmaceuticals company that is very cost conscious and is only slightly
more flexible on schedule. The project manager prepares a monthly report and notices that the SPI is 1.3 and the CPI is .89.
What should the project manager do?
Even before you look at the answer choices, you should know what these numbers mean for the project. Here is a
possible multiple-choice answer set:
A. Prepare options for getting the schedule in control.
B. Nothing; schedule and cost are both under control.
C. Prepare options for getting the schedule and cost in control.
D. Prepare options for getting cost in control.
Example 2 The project manager and team are analyzing new risks on a multimillion-dollar construction project. There are
no safety issues involved. Which risk has the highest priority? Risk Z is that a supply item will be late, has an EMV of
$4500, and the least expensive contingency plan will cost $4600. Risk X is that an activity along the critical path may finish
early and the EMV for it is $38,000. Risk Y is that an activity will be late, has an EMV of $770, and the least expensive
response will cost $650. Risk W is that an activity will finish early, the EMV is $2200 and it is not along the critical path.
A. Risks Z and X have equal priority

B. Risk W has the highest priority
C. Risk X has the highest priority
D. Risk Z has the highest priority
Answers:
Examplel The answer is D. Explanation: For an SPI or a CPI, you should know that greater than one is good and less
than one is bad. So you can see from these numbers that we are ahead of schedule (1.3 is greater than one) but over budget
(.89 is less than one). This fact eliminates the other options.
Example2 The answer is C. Explanation: If we can finish an activity early along the critical path and save $38,000, we
should prioritize this contingency plan. Why? Risk Z has a least expensive contingency option with a slightly greater cost
than the EMV if the risk were to occur. We can leave that contingency plan in place but there’s not much more we can do
there. Risk Y would not be a priority on a multimillion-dollar project, especially with so little difference between EMV of
the risk and the contingency plan cost. Risk W would be good to do if we could save $2000, but it is not worth much
savings and is not along the critical path so would not have the highest priority.
Formulas to Understand for the Exam
PMP8> Exam Prep

Name Formula Chapter Reference
FV Project Management
Present value (PV)
(1 + r)" Foundations
Expected activity duration (triangular P+M+O Schedule
distribution)* 3
Expected activity duration P + 4M + O
Schedule
(beta distribution)* 6
Total float LS-ES orLF-EF Schedule
Cost variance (CV) EV-AC Budget and Resources
Schedule variance (SV) EV-PV Budget and Resources

EV
Cost performance index (CPI) Budget and Resources
AC
EV
Schedule performance index (SPI) Budget and Resources
PV
Estimate at completion (EAC) AC + Bottom-up ETC Budget and Resources
BAC
Estimate at completion (EAC) Budget and Resources
CPIc
Estimate at completion (EAC) AC + (BAC - EV) Budget and Resources
y., (BAC-EV)
Estimate at completion (EAC) Budget and Resources
(CPIc x SPIC)
To-complete performance index (BAC - EV)

Budget and Resources
(TCPI) (BAC-AC)
Estimate to complete (ETC) EAC - AC Budget and Resources
Variance at completion (VAC) BAC - EAC Budget and Resources
n(n-l)
Communication channels Communications
2
Expected monetary value
Pxl Risks and Issues
(EMV—Cost)
Expected value (EV—Schedule) Pxl Risks and Issues
★Remember that these formulas can be used for costs as well as activity durations.
FIGURE 16.1 Formulas that may appear on the exam
https://rmcls.co
If you decide you want additional practice with earned value measurement (EVM) concepts and formulas,
return to the Earned Value Management section of the “Budget and Resources” chapter. You could do the
Fence exercise again to help you feel more comfortable with the concepts. Also remember that we have
additional exercise on EVM as well as on other topics, on the RMC Resources page.
RMC RESOURCES
More Tips for Exam Preparation

Many people fail the exam because they do not properly prepare. You can avoid that mistake. Read the following tips slow
ly, and honestly assess how each item applies to you:
□ Know the material thoroughly, but do not approach the exam assuming it tests facts that you must memorize. The
exam also tests application and analysis. Be prepared to apply the concepts and methods in a variety of scenarios,
including how they work in combination with each other.
□ Have real-world experience using the major project management methods. Try to gain experience with methods
with which you have gaps. Where gaps remain in your experience (we all have them), practice making the methods a
reality for you by applying them and creating the associated artifacts using a case study from your job or the library
case study used in this book.
□ Make sure you can quickly visualize how tools and processes would be used on a project. Practice visualization
especially with tools and methods you were most unfamiliar with when you started this course of study. This
visualization will help you prepare for situational questions on the exam.
□ When answering predictive questions on the exam, think in terms of large projects. This will help you remember the
importance of processes and methods that you may not be using in your real-world project management. It is easier
to scale down than to scale up.
□ When answering adaptive questions on the exam, remember that scope is evolving as project work takes place and
that change is common.
□ When answering hybrid questions on the exam, look for clues as to whether the specific answer requires methods
from an adaptive or predictive approach. Hybrid projects use both.
□ Understand the areas that PMI emphasizes (PMI-isms, explained in chapter 1 and in the “Quality of Deliverables
and Products” chapter).
□ Be familiar with the types of questions you can expect on the exam, but do not be alarmed if you see new types of
questions when you take the exam.
□ Be prepared to see situations on the exam that may be ambiguous or wordy. Practice interpreting these types of
questions using RMC Chapter Quizzes or FASTrack" (if you have it). Practice using analysis to select the best
answer from what appears to be two or more “right” answers.
□ Deal with stress before you take the exam. If you are a nervous test taker, using PM FASTrack* can give you an
opportunity to practice stress control.
□ Plan and use a strategy for taking the exam. This may mean you will take a mental break after every 50 questions, or
that you will answer all exam questions as quickly as possible and then take a break before you review, and
potentially adjust, your answers.
□ Expect that there will be questions you cannot answer or even understand. This happens to everyone. Be prepared
so you do not get anxious or doubt your abilities during the exam.
□ If you go to an exam testing site, do not expect it to be quiet. Use FASTrack® to practice answering questions in an
environment that is not 100 percent quiet.
□ If you take an online proctored exam, make sure you have a testing area that is free of interruptions (including pets).
Set up your space so that it is comfortable, but make sure you carefully read the instructions PMI sends regarding
taking the online exam. Don’t let taking the exam in your home or office become an additional stressor.
□ Do not overstudy. You cannot get an A on this exam. Getting completely comfortable with all the material in this
book is just not possible. It is not worth studying for hundreds of hours. It is a waste of time and will not guarantee
you’ll pass the exam.
□ Do not study the night before you are scheduled to take the exam. Instead, do something relaxing and get extra
sleep. You want to be fresh and well rested.
*105
Preparing for the Exam Environment

This book has presented what you should do and know before you take the exam. Now, let’s prepare you for the big day. The
following are some tips for taking—and passing—the exam (at a testing center).
1. You must bring your authorization email from PM1 to the test site, as well as two forms of ID with exactly the
same name you entered on the exam application.
2. Make sure you are comfortable during the exam. Wear layered clothing so you can remove outer layers if you
become too warm. (Note, however, that you may encounter specific requirements regarding removed clothing
while taking the exam.)
3. Have something to eat or drink available in case you need either during the exam. You will not be able to access
these items while taking the exam but you will be able to take a break, and you may be thirsty or hungry and you’ll
want to get rid of that distraction.
4. You will be given something on which to make notes during the exam. This may be something physical, such as
paper and a pencil or a small white board, or it maybe electronic. (Note: If you are taking the online exam, you will
not be allowed to have a physical white board or paper and pencil. You will have access to the electronic white
board.)
5. After you start your exam, consider taking no more than five to seven minutes of your test time to create your
“download sheet,” which is where you write down anything you have trouble remembering. It will free up your
mind to handle exam questions once the information you are most concerned about is written down.
6. You will likely have one or two technology and/or computer tutorials (general testing tutorial and PMP test
specific) to complete prior to the start of the exam. This will help you become familiar with the computer-based
test functionality. You need to start and complete those tutorials within their allotted time. Then you can start your
four-hour exam.
7. You will have access to a calculator during the exam. The computer will have a calculator function and the tutorial
will show you how to use it.
8. The exam does not adapt to your answers. This means 180 questions are selected when your exam starts, and
those 180 questions will not change.
9. Use deep-breathing techniques to help you relax and focus. This is particularly helpful if you are very nervous
before or during the exam and when you notice yourself reading the same question two or three times. Breathing
techniques can be as simple as breathing deeply five times, to provide more oxygen to your brain. Many people also
find it helpful to close their eyes when they do this.
10. Smile when taking the exam. This may sound hard to do when you are stressed and taking an exam for four hours,
but studies show that smiling relieves stress and makes you feel more confident.
11. Use all the exam time. Do not submit your exam early unless you have reviewed every question you skipped or
marked for review.
12. Everyone has their own unique test-taking quirks and style. When you work through the exam simulation in PM
FASTrack*, pay attention to your quirks. You may have to create a plan to work through any that may negatively
impact you while taking the exam.
13. Control the exam; do not let it control you. How would you feel if you read the first question and didn’t know
the answer? And then the same thing happened after you read the second and third questions as well? This may
happen because your level of stress is not allowing you to think. So what do you do? If you do not immediately
know the answer to a question, leave it blank, or use the Mark for Review function and come back to it later.
14. Control frustration and maintain focus on each question. You might dislike or disagree with some of the
questions on this exam. You might also be surprised at how many questions you mark for review. Make sure you
stay focused on the current question. If you are still thinking about question 20 when you reach question 120,
there will have been 100 questions not given your full attention.
15. Answer each question using your knowledge of project management good practices. Be prepared to separate
your experience from PMI’s perspective (which often matches “textbook” practices more than real-life). Many
people who fail the exam try to answer questions from their real-world experience. Your experience will help you
but don’t forget to rely on your training.
16. First, identify the actual question in the words provided (it is often the last sentence), and then read the rest of
the text. Note the topics discussed in the question and in the descriptors. This should help you understand what
the question is asking.
17. Carefully consider each answer choice listed and choose the best one of the choices given. Don’t read too much
into the answers. We often make mistakes when we make automatic assumptions because as adults our experience
leads to assumptions. Take the questions and answer choices literally.
18. Do not make this mistake. One common reason people answer questions incorrectly is they do not read all four
answer choices. Make sure you read each question and all four choices. This will help you select the best answer.
If you find yourself forgetting to read all answer options, start reading the choices backwards (choice D first, then
C, etc.).
19. There may be more than one seemingly correct answer to each question. But there will only be one “best”
answer. Make sure you are looking for the best answer.
20. There will be answer choices that are meant to distract you from the correct answer. They present more than one
plausible choice. Such choices make it appear as though some questions have two or more right answers. It often
seems there are only shades of difference between the choices. As noted earlier, make sure you look for the best
answer, and think about the situation in terms of project management good practices.
21. Be aware that questions may also include irrelevant information.
22. Look for words and phrases such as “still,” “yet,” “first,” “last,” “next,” “except,” “not,” “most likely,” “less likely,”
“primary,” “initial,” and “most.” Make certain you clearly read the question and take note of these words so you
will answer the question correctly.
23. Watch for choices that are true statements but do not answer the question.
24. Watch for choices that contain common project management errors. They are intentionally there to determine
ifyou really know project management. You can combat this by looking for errors in your knowledge and correcting
those errors as you go through this book and work with RMC Chapter Quizzes and/or FASTrack*. (See the
“Common Project Management Errors and Pitfalls” section in this chapter.)
25. Options that represent broad, sweeping generalizations tend to be incorrect, so be alert for words such as
“always,” “never,” “must,” “completely,” “all,” and so forth. Alternatively, choices that represent carefully qualified
statements tend to be correct, so be alert for words such as “often,” “sometimes,” “perhaps,” “may,” and “generally.”
26. You may see some poorly worded or grammatically incorrect questions or answer choices on the exam; don’t let
this distract you.
27. Look for answers that support the value of project management and that proper project management has
been done unless evidence in the question tells you otherwise.
The exam will not be scored until you indicate you are ready, or after four hours have passed. You will also be asked if
you are certain you want to score your exam after you submit it. You will receive a summary of your test results. If you do
not pass, PM1 will send you information on retaking the exam. You will have to pay an additional fee to retake the exam.
*105
Are you ready for some very important tricks to keep in mind when you take the exam? Pay careful attention:
• Recognize that “rules” (what we think should be best) are meant to be broken. Rules, such as what to do
when there is a conflict, can change depending on the situation. This drives some people crazy—especially
those who expect the exam to just test facts. You need to be able to read and understand the situations on
the exam and then be able to figure out the best thing to do in that situation.
• Unless stated otherwise, assume proper project management was done. If you answer a question thinking
about real-world projects that do not use proper project management, you might miss the correct answer. If
the question makes it clear that proper project management has not been done, you’ll likely need to think
about what is missing, how to solve the root cause of the problem, and how to make sure proper project
management is carried out going forward on the project.
• For each question notice which part of the project the scenario is occurring in. If the situation described is
taking place in planning, your answer may be different than if it was occurring during executing.
• Be prepared for questions with multiple problems. A question may describe a situation with various
problems and ask you to determine which one to address first. Here is an example:
Two stakeholders are disagreeing via a series of emails as to whether a deliverable meets the acceptance criteria. The
cost-benefit analysis done in planning did not support delivering a higher level of performance, and the stakeholders
agreed. A team member has just informed you that a problem with his work has occurred. The deliverable he is
working on must be shipped today or there will be a project breach. One of the stakeholders having the email
disagreement comes to you to complain about the other. What should you do?
The following tips will help you focus on the most important problem in order to select the best answer. It is important
to note that all these tips will not apply all the time, and they do not have an order of importance.
• Determine the immediate problem to address.
• Deal with the root cause first.
• Deal with the problem with the greatest negative impact first.
• Solve the problem that occurred the earliest.
• Look for a proactive solution.
Common Project Management Errors and Pitfalls

As mentioned at other points in this book, the exam often includes common errors in project management as possible an
swers. Read the following summary of some of the major errors even highly experienced project managers make, and make
sure you understand why these are errors.
Common project management errors include the following:
• Focusing primarily for activity status on percent complete
• Holding “go around the room” status meetings
• Spending most of your time micromanaging team members by constantly checking on them
• Asking team members to cut 10 percent off their estimates
• Thinking a bar (Gantt) chart from scheduling software is a project management plan
• Not attempting to obtain finalized requirements
• Not getting real resource commitments
• Not having a rewards and recognition system
• Not focusing on quality
• Not having a change control system
• Not having management plans (in a predictive environment)
406
• Not measuring against the project management plan (in a predictive environment)
• Not creating metrics to measure and evaluate performance
• Not spending time finding and eliminating root causes of problems or deviations
• Not implementing corrective actions to keep the project in line with the project management plan
• Not reevaluating the effectiveness of the project management plan
• Not reevaluating the accuracy or completeness of scope, schedule, or cost
• Not keeping the project management plan and project documents updated to reflect changes and revised information
about the project
• Ignoring resource managers’ responsibilities to manage ongoing business operations in addition to responding to
project needs (team and physical resources)
• Not realizing the project can affect the reputation of team members
• Not realizing the project manager has resource responsibilities; these can include responsibilities to the project team
(such as creating project job descriptions, evaluating individual and team performance on the project, and adding
letters of recommendation to team members’ human resource files) as well as responsibilities related to
physical resources
• Blaming unrealistic schedules on management instead of realizing that developing a realistic schedule is the project
manager s responsibility
A Day-in-the-Life
The following exercise provides one last opportunity to test yourself to see if you really understand what a project manager
does.
16.4 Exercise
Many people do not practice the breadth of project management practices described in the ECO and other PMI
references on their real-world projects. This exercise is designed to help you uncover what you might be doing that
represent differences between your real-world experience and project management practices from the
PMI perspective.
In your Exercise Notebook, list which activities a project manager should spend the most time doing, on average
during a typical day, and what they should spend the least amount of time doing. This would be after planning is
complete (to the degree needed for the current phase, iteration, etc.) and the team is working on building
the product.
407
Answer
There are a number of ways this question can be answered correctly. Let’s review some of the items that should not
be taking up most of your time, and what should typically be included during the course of a day. Think through
the items listed here and identify whether you have any misconceptions about what you should be doing as a
project manager. If you do, clarify and fix these misconceptions before you take the exam.
How you should NOT be spending most of your time What should typically be included in your day
- Dealing with problems and unexpected changes - Using artifacts like a WBS or product backlog, and a
(rather than preventing them and having risk project management plan
contingency plans)
- Measuring and evaluating
- Schedule and other items related to
- Being of service to the team
schedule management
- Removing impediments to team progress
- Meetings
- Recommending and taking corrective and preven
- Micromanaging
tive actions
- Completing work activities
- Implementing risk responses or communicating
- Dealing with problems that arise from with risk owners about them
unhappy stakeholders
- Coaching, mentoring, and team building
- Clearing up communications issues
- Continually communicating the vision with the
- Managing team member conflict that they could team and stakeholders
manage on their own - Communicating and using active listening
- Managing by exception to the plan
- Interacting with stakeholders to maintain and
improve stakeholder engagement
- Looking for possible changes
408
QUICKTEST
17 Common Agile • Lean

• Kanban
• Scrum
- Scrum and agile terms
• Product backlog
Methodologies • Project backlog

• Sprint backlog
• Daily Scrum
• XP
• Spike
• Architectural spike
Introduction • Crystal
• DSDM
We have discussed agile practices throughout this book. In this chapter, we will look closer at the foun • SAFe®
dation for agile through the Agile Manifesto and examine some of the different methodologies. These • FDD
methodologies include: • Agile values
• Agile principles
• Lean • DSDM (Dynamic Systems
• Agile mindset key
• Kanban Development Method concepts
• Scrum * FDD (Feature Driven Development) • Agile constraints
• XP (extreme Programming) • SAFe* (Scaled Agile Framework)

• Crystal Family of Methodologies
Although agile seems new to many people, it actually has been around a long time, and the ideas
used by agile practices are certainly not new. What we call “agile” is a compilation of practices people
have experimented with and then taken what has worked. This collection of good practices has
become systematic.
Practitioners often use the terms agile and adaptive interchangeably. In reality, agile is a practice
and adaptive is a more general term. To review, in adaptive environments scope cannot sufficiently be
defined at the beginning of a project and will remain largely unstable throughout the project. Scope
is emerging.
Before continuing, review the following sections of the “PMPK Exam References in
Context” chapter:
• Agile Process Overview
• Rita’s Agile Process Chart " Game You should have played this game once when you first read
that chapter. It is a good time to play this game again for review.
Overview
Following are the common agile methodologies that have given agile practitioners a set of practices to
combine and customize, depending on the needs of the organization, its products and projects, its
teams, and its stakeholders. We discuss Lean and Kanban first since they are not agile methodologies.
Instead, both Lean and Kanban are independent methodologies (originally related to manufacturing)
from which agile has integrated many ideas.
As you read you will also find a bias toward software development. This is because it was among
software developers that various methodologies were synthesized and the agile philosophy was
organized and spread. If you are not in the software development field, think about how these methods
can be applied in your organization. As we have mentioned before in this book, agile methods are now
used with a variety of projects that are a good fit for an adaptive development approach.
The last sections of this chapter describe the common agile influences and agile philosophy, also
known as agile’s four values and twelve principles (found at agilemanifesto.org).
409
Common Agile Methodologies SEVENTEEN
Lean
Lean product development is an approach that has its history in manufacturing but has been adapted over time to many
areas of business, including agile project management. For the exam know that agile methods ascribe to Lean principles.
Here are the fundamentals of Lean’s seven principles:
• Eliminate waste Examples of waste in product development include wait time (and motion, or the time required to
take action), incomplete work, extra processes or features, task switching, and defects. A helpful Lean tool for
eliminating waste concerns the value chain and value stream mapping. As discussed in the “Complaince and Delivering
Value” chapter, value stream mapping maps out and analyzes all steps in a product (build and) delivery process to see
where the team can eliminate waste.
• Amplify learning Examples of this Lean principle show up in agile’s constant feedback loop facilitated by iterative
planning (e.g., product visioning, release and iteration planning). The daily standup meeting, iteration reviews, and
retrospectives are additional examples of built-in opportunities to amplify learning.
• Decide as late as possible Since in adaptive environments so much information is not available at the beginning of
a project, agile teams make decisions about each next stage or each next iteration (or sprint). However, in contrast to
predictive environments where there is “big planning up front” and many decisions are made early, agile teams defer
decisions about anything beyond the next stage (be it the release plan, the iteration plan, etc.) to the “last responsible
moment.”
• Deliver as fast as possible The iterative and incremental delivery of agile means that teams are delivering value
continually and as quickly as possible. This is a Lean concept and all agile methodologies use it.
Example While doing value stream mapping, if the team uncovers a process that is no longer needed, it can be
eliminated immediately.
• Empower the team Built into agile—and into the ECO—are the principles of using people skills, trusting in team
members’ skills, providing training where needed, and trusting the team to make the decisions about their own work.
Examples A belief in employee self-determination and an understanding ofhow motivation enables good servant
leadership for empowering the team.
• Build integrity in This refers to product integrity, which includes not only a product that works well for its intended
use but is also easily usable by the customer.
Example Agile teams use personas to make customers real people in their minds. For example, if they are building
an online movie rental site, personas allow them to ask: “Is this going to be quick and easy for ‘Harried Henry’ to use?”
These kinds of questions can lead the team to remove suboptimal usability factors from the product, streamlining it
for the end user.
• See the whole Do you remember when we discussed systems thinking? Look to the “Compliance and Delivering
Value” chapter to review this information as needed. Think about a product as a system with interacting parts that are
also interdependent. You must think holistically about the product, and agile teams are encouraged to do this with this
principle, as with others related to systems thinking.
Think about it. Do you ever find yourself doing something while thinking “This is a waste of my time”? Do you
think about how you could streamline the process or eliminate it? If so, you are thinking Lean.
Kanban
Derived from Lean, Kanban is a Japanese word meaning “signboard” (think sidewalk signs outside cafes advertising the
daily specials). There are two things you need to know about Kanban for the exam. First, a Kanban board is an information
radiator, or highly visible and graphic display of project information. In agile, Kanban boards were meant to be low-tech and
high-touch. They were created with sticky notes on white boards or flip charts. Now, there are many electronic tools that
allow teams to share Kanban boards collaboratively from dispersed locations.
*110
SEVENTEEN Common Agile Methodologies
In the Communications chapter, we showed the following example of a Kanban board:
Story Ready Task Ready Task In Process Task Done Story Done
User Task User

Story J Task Task Storyl
Task ■ i Task
Task Task Ta Task
Task Task
1--- 1_Lr
User Task _
Story Task Task
Task Task Issue
Task
Figure 17.1 Kanban board
The second thing to know about Kanban for the exam is that there are five core principles. Looking at figure 17.1, can
you see how the Kanban board supports the first three principles listed below?
Kanbans five core principles are:
• Visualize the workflow The team and any other project stakeholder can see the status of tasks in progress, at
any time.
• Limit WIP (work in progress) Iteration backlogs are an example of limiting work in progress. On a Kanban board,
tasks are coded or colored for the person responsible for completing them. In the example given in figure 17.1, a new
task will not be added to the Task in Process column for a team member until their current task moves to the Task
Done column.
• Manage flow By doing the first two principles and by focusing on the unfinished task before another task is added,
the project manager is managing flow.
• Make process policies explicit The entire team must know the entire product and process at least at a high-level
and not just the component they are building. This way they can understand their own contribution holistically and
practice systems thinking.
• Improve collaboratively Collaborative work and continuous improvement are critical for agile teams. Improving
collaboration is encouraged in Kanban and facilitated by the Kanban board as an information radiator that is discussed
regularly among the team.
Think About It. Look again at the Kanban board example in figure 17.1. Can you see why Kanban, if used as a
product development method, is called a pull system?
• A team member pulls a task from Task in Process and moves it into Task Done when it is completed.
• Only then will they pull a task from the Task Ready column and move it into Task in Process.
• Limiting how many stories (which are broken into tasks) go into the Story Ready column helps control flow
and limits work in progress.
• This distinguishes Kanban from other agile methods that use iteration cycles to control work in progress.
Note: Importantly, there is a difference between agile methodologies that use Kanban ideas and Kanban as a
methodology. Kanban is a distinct methodology and can be used to manage a project. Kanban as a methodology
doesn’t require iterations. However, Kanban boards (i.e., signboards) are used in many agile methodologies that are not
using the previously described pull system. Kanban boards are often, in fact, used in combination with iteration cycles.
Scrum
Scrum started with software developers and has the distinction of being the most well-known and popular agile methodol
ogy, and is therefore the most influential for many agile teams. Many people use agile and Scrum terms interchangeably. In
fact, on the exam, in agile and hybrid questions, you are likely to sometimes see Scrum terms used interchangeably with
so-called generic agile terms. For example, many people recognize “iteration” as a generic agile term (even though it came
from XP) but if they hear the term “sprint” they think specifically of Scrum. The terms mean the same thing—a time-boxed
period of building the product—and are used similarly and often interchangeably.
Scrum and Agile Generic Terms

The below table shows the generic agile terminology and its Scrum equivalent:
Category Scrum Term Generic Agile Term

Activities • Sprint • Iteration
• Sprint planning • Iteration planning
• Daily scrum (ceremony) • Daily standup (meeting)
• Sprint review (ceremony) • Iteration review (meeting)
• Sprint retrospective (ceremony) • Iteration retrospective (meeting)
• Backlog refinement • Backlog prioritization
Team Roles • Product owner • Product owner (or customer)

• Scrum Master • Agile coach, team lead
• Development team • Development team
Artifacts • Product backlog • Product (or project) backlog

• Sprint backlog • Iteration backlog
• Potentially shippable product • Minimally viable product (MVP)
(increment) (increment)
Note the following about the terms in the table above:

• You can see from the number of analogous terms here that generic agile has borrowed a lot of practices, like the
concept of the backlog, from Scrum.
• Generic agile teams may adhere to a custom mixture of these practices, depending upon organizational and PMO
governance. Organizations using a generic form of agile may have a customized approach to team training.
• Organizations that have implemented Scrum adhere more strictly to specific Scrum practices and Scrum teams.
Scrum teams are likely to have to be trained specifically in Scrum by certified Scrum trainers contracted from outside
the organization.
• There are several different backlogs, be careful when reading exam questions.
•J The product backlog represents all the known product scope. Features are continuously added and removed
as the customer makes decisions about product scope.
•/ A project backlog—if the term is used—refers to all the known product scope that will be built during a
particular project.
/ The terms product backlog and project backlog are not mutually exclusive, and many teams just use the term
product backlog. We include the term project backlog in case you encounter it on the exam.
•/ The sprint (or iteration) backlog is the specific increment or increments of product that are currently at the
top of the prioritized backlog and are selected for the next (or current) sprint. You may recall from earlier in
this book that a project consists of a series of sprints (or iterations) leading up to one or more product releases.
412
• The product backlog is a perpetual artifact as long as the products life cycle continues.
>/ For new product development the backlog contains the features needed for at least the first product release.
It may include enough features for more than one product release in a single project. The scope of a single
project (including how many releases) is as always defined and negotiated with the customer or key internal
stakeholders (represented by the product owner), depending on the resources available for the project.
</ For ongoing development on an existing product, the backlog is a combination of new features, fixes for
defects (bug fixes, for software), and upgrades to existing features.
Think About It. Scrum and generic agile terms are commonly used interchangeably in exam questions, so do
not be distracted by semantics while taking the exam. If you are well prepared, you will understand a particular
question from the context of the given scenario.
Scrum Core Concepts

The following are considered to be Scrum core concepts:
• Iterative and incremental development Scrum practitioners deliver increments of the product, which they build
in sprints.
• Dedicated team The Scrum team is dedicated to the project and it is stable, meaning the same people stay on the
team and projects are brought to them. This contrasts with predictive environments where different teams may be
assembled and broken up on a per-project basis.
• Cross-functional team Scrum team members are “jacks of all trades, masters of a few.” This means that in contrast
to traditional teams where members are specialists in a field or two, a Scrum team member can fill in for another team
member as needed. For example, a computer programmer may also do testing.
• Pillars The pillars are essential Scrum core concepts. They are transparency, inspection, and adaptation.
y Transparency This means creating a common understanding among all responsible parties. Creating a
project or product vision, a team charter, and a definition of done for a story or a product increment are all
examples of transparency.
y Inspection This is about examination of how the work is going on a regular basis, assessing how the team is
progressing, and what may need to change to continuously improve alignment of team performance and
project (or product, or iteration) goals.
y Adaptation This is making changes appropriate to the findings from inspection. Examples of practices
facilitating (inspection and) adaptation are the sprint planning, daily scrum, sprint retrospective, and sprint
review meetings.
Think about it. How often do team members change in your organization? The concept of a dedicated team
allows team members to stay together for the long term, learning to work together well and become very
\ productive. Can you see how this would increase the speed at which a team could get work done?
Daily Scrum
The team’s daily scrum is designed to be short, informative, and to keep work moving forward while wasting no time. This
meeting is also called the daily standup meeting. All projects can benefit from this type of meeting, at which team members
are asked and then answer three questions:
• What have 1 completed since the last meeting?
• What am 1 working on today?
• Are there any impediments to progress?
*11 5
Rules for this meeting are:

• If you have something to report you must attend.
• If you have nothing to report, you shouldn’t speak at the meeting.
• Talk is restricted to addressing the three questions.
• If you have identified an impediment, it will be taken up after the meeting by the Scrum Master (or anyone else who
may be able to help remove the impediment). It is not to be elaborated during the meeting.
XP (extreme Programming)
XP or eXtreme Programming was one of the early agile (software development) methodologies to gain popularity. From
XP we get these terms, already used in this book: user stories, release planning, iteration, product increment, release, along
with the concept of small releases.
XP and Similar Terminology

XP uses the term “coach” as we have used “team lead” or “agile coach” in this book. The role is analogous to Scrum Master.
Other XP team members are programmers and testers. XP uses the term “customer” the way that Scrum uses “product
owner.”
We also get the terms spike and architectural spike from XP.
• Spike Also known as a “risk spike,” this is an iteration specifically planned to explore risks to understand them better
and thus reduce them. Unlike other iterations, a product increment is not produced.
• Architectural spike Like a risk spike, this type of iteration doesn’t require that a product increment be delivered at
the end. Architectural spikes explore new technological approaches to show they will work for the product and
the project.
XP has activities, values, and practices.
XP Values
The following values are meant to guide XP teams. The concepts have been integrated into generic agile.
1. Simplicity This means not adding unnecessary design or functional features, keeping complexity at a minimum.
Associate “find the simplest thing that could possibly work” with XP.
2. Communication This ensures all team members know what others are working on and also understand the
big picture.
3. Feedback “Fast failure” is a commonly used agile cliche that comes from XP. Delivering prototypes and other
possible solutions fast means the team finds out quickly what works and what is pleasing to the customer.
4. Courage XP encourages collaboration through practices where people work closely together and remain
transparent about their work. See for example, pair programming and collective code ownership in the XP Practices
section.
5. Respect This should be self-explanatory in any team environment where everyone is collectively responsible for
results, are experts in their field, and yet are working on something new on a daily basis. Teamwork cannot work
without mutual respect.
XP Practices
As a programming methodology, XP is mainly concerned with software engineering practices. Thirteen core practices
underlie the XP methodology.
1. Whole team This is the agile concept that the team has all skills needed to build the product and that team works
together on the project. This is similar to the SCRUM concepts of dedicated and cross-functional teams.
2. Planning games Release planning and iteration planning are called planning games.
3. Small releases Like other agile methodologies, small releases allow XP teams to deliver small sets of prioritized
features frequently, thus providing a continuous delivery of value.
4. Simple design Keeping the design as simple as possible helps enable frequent small releases and provides a more
easily maintained product in the long run.
5. Metaphor XP practitioners use metaphors and analogies to make technical concepts understandable to customers.
6. Sustainable pace This is the same as saying that having the team do overtime to make a deadline is not a viable
scheduling strategy on projects. Product developers should be able to work at a pace that is sustainable in the
long term.
7. Customer tests These are tests driven by customer descriptions of how the software should behave to indicate
that it is working as intended.
Example “When I click the ‘Menu’ option, options X, Y, and Z should appear.”
8. Test-driven development This means the team creates the tests before they develop the code (or product
increment). The code has to be built to pass the tests.
9. Pair programming This is the practice of two developers working together, taking turns developing code while
the other watches. It increases quality because “another set of eyes” on the product as it is being developed is better
than the active developer working alone.
10. Collective code ownership No one on the team owns the product; the team as a whole owns the product. This
means that any programmer pair can change code when they find they can improve it, regardless of who originated
the code.
11. Code standards XP teams follow a stringent coding standard. This keeps pair programming and collective code
ownership from resulting in a product with an inconsistent design.
12. Continuous integration How do you know that when a new product increment is created it won’t break the
product? Continuous integration means integrating all new code into the product (once unit testing is done) on a
regular basis to ensure the product continues to work as planned, as new code is added.
13. Refactoring There is always more than one way to accomplish something. As a product is built, more and less
efficient components can wind up as a part of it. Think of refactoring as doing cleanup. Refactoring is not changing
the way the product works but making the code more efficient by removing duplicate or unnecessary code and
implementing design simplification and other improvements.
Example Imagine the software development team who built your favorite mobile app. They had an idea and
worked together to build features they hoped you would like. The first release of the app was probably small and
simple, with just a few features. They received feedback and continued to add more features based on customer
responses. Some new releases are fixing problems (refactoring) and every change is integrated with the existing app
(continuous integration).
*11 5
Crystal Family of Methodologies

Crystal is a group of methods that the project manager and team tailor to find a situation-specific solution. For the exam,
you are most likely to see questions that link Crystal with tailoring. Figure 17.2 looks complicated, but we provide it just to
show you that with Crystal methodologies, you choose a specific set of practices based on the criticality of the project.
The colors are just names for different approaches. Of course, larger teams require more structure and governance.
Criticality categorizes projects by their potential risks and impacts. For example, a “C6” project has a low level of criticality,
so practices can be relatively lightweight. By contrast, the other extreme is Magenta (L200), a set of practices for any
project with a risk to Life (L), like building a medical device, regardless of team size. A criticality of “Life” indicates the
most formal and stringent use of processes and methods.
Clear Yellow Orange Red Magenta

Criticality
Lz/e (L) L6 L20 L40 L80 L200
Essential E200
E6 E20 E40 E80
money (E)
Discretionary D200
D6 D20 D40 D80
money (D)
Comfort (C) C6 C20 C40 C80 C200
1-6 7-20 21-40 41-80 81-200
Team Size
FIGURE 17.2 Crystal methodology considerations based on criticality
DSDM
Dynamic Systems Development Method (DSDM) is an early agile method that still has influence within generic agile. As
a stand-alone method it is more prevalent in the UK. We display the DSDM eight core principles’ life cycle alongside figure
17.3, just to help you be aware of it and give you an idea of its similarities to other agile methods that influence agile.
DSDM Core Principles

• Focus on business need
• Deliver on time
• Collaborate
• Never compromise quality
• Build incrementally
• Develop iteratively
• Communicate continuously and clearly
• Demonstrate control
Figure 17.3 DSDM life cycle
^116
Scaled Agile Framework® (SAFe®)

We’ve been talking about small agile teams—self-organizing, cross-functional groups of people who work together to build
a product. These small teams work well for building a mobile app or a video game. But how would a small team build a large
system like an enterprise management system or inventory control system? And how would a portfolio or program be
managed using agile practices? “Scaled agile" refers to using the agile mindset in a larger context.
The Scaled Agile Framework’, first released in 2011, is a set of management practices and processes that guide a
group of agile teams to work towards a common, often longer-term, goal. This framework uses small agile teams, working
in concert with each other, each producing a part of a larger product or solution. SAFe promotes alignment, collaboration,
and delivery across a large number of agile teams. SAFE is based on three of the bodies of knowledge you have been
learning: agile development, lean product development, and systems thinking.
In SAFe, agile teams may use Scrum or another agile approach at the team level. Their work is coordinated under the
SAFe Framework. A “team of teams” oversees the work of the individual teams (usually 5-12 teams) and is called the Agile
Release Train (ART). SAFe also has unique roles like the Release Train Engineer (RTE).
Think About It. SAFe uses a train analogy, with each train car being an agile team. Train cars each have a specific
purpose: some carry grain, some are refrigerated to carry food that would spoil in heat, some carry vehicles, and
they can link together with any other car because they are all the same size and have the same connection
mechanism. In an enterprise using the SAFe framework, each team is assigned a specific component or aspect of
the product to build, and then links it together with other teams who are working on other components of the
same product. Ideally, work is timed so that all the pieces come together at the same time and the product is
delivered as scheduled.
Here are the four core values of SAFe:

• Alignment The alignment value refers to making sure all teams are aligned to organization strategy, goals, and each
other. When several agile teams are working on the same product it is critical that their work is clearly aligned.
• Built-in quality Built-in quality refers to the importance of building quality product components and increments of
the solution. Since components built by different teams will need to “fit together,” they all must be built to the same
quality standard. The value of built-in quality comes from the lean principle of “build integrity in.” The bigger the
product, the more important that quality is built in. Without this value, rework and lower velocities are guaranteed.
• Transparency Transparency means openness, honesty, and decision making based on facts. Transparency requires
trusting relationships between team members and teams. Transparency also refers to the behaviors of making sure
that everyone involved with the product and project understands the goals and vision.
• Program execution Nothing will be accomplished if teams don’t execute according to the plans and the framework.
Teams must be well-trained, coached, and understand their role within the entire framework.
SAFe defines levels of work, each larger and more strategic than the prior.
• Team This is the agile team using Scrum or another agile approach.
• Program As defined in the “Project Management Foundations” chapter, a program is a group of projects that are
coordinated to support a related organizational goal.
• Essential SAFe The team and program levels are combined into Essential SAFe.
• Large Solution A large, organization-wide solution.
• Portfolio As defined in the “Project Management Foundations” chapter a portfolio includes programs, projects, and
related operational work supporting a strategic business goal. Most organizations have just a few portfolios.
fll7
Leadership for SAFe

Leadership is important for success with the SAFe framework. Roles like the portfolio managers and product managers all
have specific responsibilities for their part of the framework. They are responsible for prioritizing work, communicating
about stakeholder needs, reviewing completed work, and providing feedback to the development teams. It requires strong,
clear leadership to make sure that each train car gets linked to other cars going to the same place, gets on the right tracks,
avoids collisions with other trains, and delivers as promised. Be prepared to answer exam questions about scaling agile for
large solutions using SAFe.
Feature Driven Development (FDD)

Feature Driven Development (FDD) also originated from software engineering. In looking at figure 17.4, can you see the
similarities between FDD and agile practices you have learned about in this book? FDD is focused on feature delivery,
starting from an overall model. Then, the feature list (analogous to a backlog) contains client-valued increments of func
tionality from the high-level model. The product is then planned by feature and work from there moves into designing and
building.
Feature-Driven Development is the agile methodology that popularized cumulative flow diagrams and parking lot
diagrams, which are one-page summaries of project progress. Both are useful tracking and diagnostic tools that are now
used by other agile approaches.
Agile Values and Principles

A group of software development professionals wrote agile’s four values and twelve principles called the Agile Manifesto.
It is not necessary to memorize this for the exam, but as you read the Agile Manifesto it should make good sense to you
considering what you know about how agile works as a tailored set of practices.
We suggest you substitute “product" or “service" for “software,” depending on your profession.
Agile Values
As you look over these four values, you will recognize that the items on the right are directly related to a plan-driven
project. The bolded items on the left are at the core of agile projects. The manifesto states that “while there is value in the
items on the right, we value the items on the left more.”
Individuals and interactions over processes and tools

Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
The format of the four values—A over B (“Individuals and interactions over processes and tools”)—addresses
intention, focus, and effort. This isn’t as black and white as just saying, “Do A instead of B.” Instead, it acknowledges that
both A and B will be components of projects, but that we should apply more of our focus, emphasis, and intention to A
than to B.
fll8
Agile Principles
In addition to the four agile values, the authors of the Manifesto (Agilemanifesto.org) created twelve guiding principles for
agile methods:
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcoming changing requirements, even late in development. Agile processes harness change for the customer s
competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the
shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need and trust them to
get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-
face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain
a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity—the art of maximizing the amount of work not done—is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its
behavior accordingly.
17.1 Exercise
Think about these principles. In your own words, describe what each principle means to you. Can you see how
some of these might apply to your projects?
Principle What does this mean to you?

Our highest priority is to satisfy the customer through
early and continuous delivery of valuable software.
Welcome changing requirements, even late in

development. Agile processes harness change for the
customer s competitive advantage.
Deliver working software frequently, from a couple of

weeks to a couple of months, with a preference to the
shorter timescale.
Business people and developers work together daily

throughout the project.
Build projects around motivated individuals. Give them

the environment and support they need and trust them
to get the job done.
The most efficient and effective method of conveying

information to and within a development team is
face-to-face conversation.
Working software is the primary measure of progress.
919
Agile processes promote sustainable development. The

sponsors, developers, and users should be able to
maintain a constant pace indefinitely.
Continuous attention to technical excellence and good

design enhances agility.
Simplicity—the art of maximizing the amount of work

not done—is essential.
The best architectures, requirements, and designs

emerge from self-organizing teams.
At regular intervals, the team reflects on how to become

more effective, then tunes and adjusts its behavior
accordingly.
The Agile Mindset

You may see the phrase Agile Mindset on the exam. This phrase refers to the idea that you don’t just memorize the values
and principles and join an agile team. To be agile, you must change your thinking to adopt these principles and ways of
working. It takes time to learn and adopt an agile mindset and it will change the way you view much of your work. Agile
approaches are less prescriptive than plan-based approaches and rely more on the team members operating with an agile
mindset.
Key Concepts
Here are a few concepts, derived from the values and principles, that you may see on the exam.
Welcoming Change
A major difference between predictive and adaptive environments is the project managers (and teams) response to
customer requests for change. In plan-driven life cycles, changes are considered “necessary evils” requiring a process—
Integrated Change Control—to include the change into a project that is already underway. Agile approaches welcome
change. When you see exam questions about changes to the project, be sure to notice if the project manager is using a
plan-driven or agile approach before you answer.
Working in Small Value-added Increments

Exam questions about plan-driven projects assume large projects with hundreds of stakeholders and long timelines. Exam
questions about agile projects refer to smaller teams, building small increments of a product, delivered to customers as
soon as possible. This is not to say that large projects would not use an agile approach, but remember that products are built
in small, valuable increments that can be delivered to the customer faster than the entire product.
Using Build and Feedback Loops

Customers or their representatives (e.g., product owners) are closely involved with agile teams and give frequent feedback.
At the end of every iteration customers are shown demonstrations of the product component most recently built, and they
can request any changes they want. These frequent feedback loops prevent the team from going too far down a path that
the customer would not like.
Learning through Discovery

Experimentation or discovery is important for new, innovative products to emerge. As new technologies become available,
teams may need time to learn how best to use them. Agile teams recognize the need to plan time for learning and
experimentation. Prototypes are often built early in the project to test out ideas. This ties into the prior principle of build
and feedback loops. Prototypes are viewed by customers who provide early feedback. Once the team has successfully
tested a new technology, product development progresses more smoothly.
Failing Fast with Learning

Related to learning through discovery, the concept of fast failure results in additional learning. Agile methods recognize
that some experiments fail and the team should find out as soon as possible if a new technology or architecture is going to
work. If not, they can stop and redesign. Human nature often leads teams to do the easy work first, putting off the hard tasks
until the end. But, finding out that new technology won’t support the new product at the end of the project can be
devastating and will have wasted many hours of time.
Value-driven Development
Agile leaders and their teams are always focused on providing value to their customers. Analysis of existing software
products reveals that 80% of many application features are rarely used (remember the Pareto 80-20 rule?). Organizations
have realized they need to focus on the most valuable product features first, delivering to the customer as early as possible.
Continuous Delivery
Another important concept of agile approaches is continuous delivery. When possible, teams build products in increments
and deliver them as soon as they are usable for the customer. Think about your mobile phone updates. Your phone provider
is continuously delivering new features, updates to existing features, corrections and enhancements to your phones
operating system. They are creating a minimally viable product.
Continuous Improvement
Finally, the concept of continuous improvement is used throughout project execution. Continuous improvement processes
and techniques have been around for a long time. Agile approaches build on existing tools like Lean and Kanban to
encourage continuous improvement. Plan-driven project life cycles use lessons learned to improve future projects. Agile
life cycles use retrospectives. Regardless of the approach used, all teams should be constantly learning and finding better
ways of working.
The Agile Triangle

In project management, understanding the project constraints is one of the most important tasks of the project manager.
In traditional, plan-driven life cycle approaches the scope is considered a key constraint. Once the scope is approved by the
customer, changes to the scope are discouraged because the entire project management plan is built around accomplishing
the agreed-upon scope. The cost and time constraints of the project are impacted if scope is changed.
In agile life cycle approaches, these constraints are turned upside down. (The inverted triangle model was first
published in the DSDM Manual in 1994.) As you can see in figure 17.5, agile approaches start with the time and cost
constraints, agreed upon by the customer or sponsor and the scope is allowed to change during the project. There are
several benefits to this approach. One is the sponsor or customer knows the labor cost at the beginning of the project.
Rather than just an estimate, the labor cost agreed to will be the actual amount of money to be spent because the agile team
has a fixed number of members and fixed amount of time. For example, if a project manager has asked for 5 team members
for 3 months, the actual cost of the team is known at the beginning of the project.
Another customer benefit of an agile approach is the flexibility to change the desired scope as the project moves
along. The product is built in small increments and the customer reviews and approves each increment. After seeing an
early version of the product, the customer may choose to move the product in a different design direction than was
originally planned, with no negative impact to the time or cost. Imagine a project to publish a digital book where each
chapter is released online as it is completed. As chapters become available to readers, they can provide feedback, and
revisions to these early chapters can be made at any time. Later chapters will build on the early chapters incorporating in
feedback (e.g., “more illustrations please”) increasing the quality and usefulness of the entire book.
An advantage of the inverted triangle, to the agile team, is they don’t spend hours trying to document every detailed
requirement in a document and/or spend hours trying to estimate the time it will take to build the product. Many project
teams struggle with both requirements and estimating complex knowledge products, so an agile approach decreases time
spent doing things that humans are not very good at anyway.
Traditional Agile
Triangle of Constraints Triangle of Constraints
Time
variable
Scope
Inverted triangle model
17.2 Exercise
Think about it. As you approach your next project, will you consider an agile approach? What would be the
reasons you should consider one? Write your answer in your Exercise Notebook.
Answer
Here are some examples of what you might have come up with. You may have come up with some other ideas
as well.
• New unique or complex knowledge product

• The sponsor is looking for cost savings in a complex process
• Unclear scope or unknown requirements
• The product could be delivered in increments
• The product will use a new, untried technology
• Early delivery of value to a market would generate early revenue or beat a competitor to market
QUICKTEST
18 PMBOK Guide and • Performance Domains

• Principles in the Project
Management Standard
the PM Standard
Principles and Domains
Introduction
After reading this book you will have already learned a great deal of what you need to know for the exam
from the PMBOK* * Guide, Seventh Edition. We weaved PMBOK* Guide information into the content of
this book although we have not always identified it specifically as PMBOK* Guide content. It was
enough for you to concentrate until now on the Examination Content Outline (ECO), the Process
Groups model, and the spectrum of project management approaches including agile, plan-driven, and
hybrid approaches.
Now it is time to fill in a few gaps so you have a more comprehensive understanding of how the
content of the exam and the PMI publications fit together.
Think About It. Before you continue reading this chapter you should review the concepts
you’ve been learning. Think about how all the pieces fit together as you review the following
sections of the “PMP* Exam References in Context” chapter:
• Examination Content Outline (ECO) Overview.
• The Process Groups Model Overview.
• Rita’s Process Chart'" Game You should have played this game once when you first
read that chapter. Now that you have read more about predictive project management
processes in this book, it is a good time to play this game again for review.
• Rita’s Agile Process Chart” Game You may want to practice playing this game again
for review.
Reviewing this information will prime your memory so you are more comfortable with these
concepts as we now pull in the additional information from PMI’s PMBOK* Guide and The Standard
for Project Management.
As you read about the PMBOK* Guides performance domains in the next section of this chapter,
we will point out parallels between these performance domain concepts and the ECO and Process
Groups model to which you were already introduced.
To start, know that the PMBOK* Guide is neither process-based nor prescriptive. It is based on
performance domains. A performance domain is a group of related activities that interact and are
interdependent. Keep in mind that while it is useful to group critical project management activities
together into distinct domains, project management needs to be looked at holistically.
The PMBOK® Guide, the ECO, and Process Groups

In each of the ECO Process (domain II) chapters we mapped three sets of concepts:
• ECO tasks most applicable to the content of that chapter
• Process Groups model processes applicable and most closely aligned to the content of the chapter
• PMBOK* Guide performance domains most closely associated with the ECO tasks and Process
Groups model processes we identified for that chapter
PMBOK® Guide and the PM Standard EIGHTEEN
In this chapter, we look at these charts again with attention to the PMBOK* Guide domains. The concepts are not new
so you will easily be able to relate them to what you already know about the ECO processes, the Process Groups model
processes, and agile and hybrid methods. The PMBOK* Guide’s performance domains will no doubt sound familiar because
the PMBOK* Guide is looking at the same concepts through a different lens.
The PMBOK* Guide’s performance domains are as follows:
• Stakeholders • Project Work
• Team • Delivery
• Development Approach and Life Cycle • Measurement
• Planning • Uncertainty
We will ask you to look at these performance domains and think about the following figure from the standpoint of
integration management. Integration management is related to and affects all these performance domains.
ECO Process Groups Model PMBOK1' Guide

Domain II Integration Management
Task 1 Domain 2.1
Execute project with the urgency required to Develop Project Charter Initiating Stakeholders
deliver business value
Develop Project Management Plan — Domain 2.2
Planning
Task 9 Team
Integrate project planning activities
Task 10
Manage project changes
Manage Project Knowledge □ Executing
Monitor and Control Project Work —> Monitoring

Domain 2.3
Development Approach and Life Cycle
Domain 2.4
Task 12 Planning
Manage project artifacts Perform Integrated Change Control —' & Controlling
Domain 2.5
Task 13 Close Project or Phase Closing Project Work
Determine appropriate project
Domain 2.6
methodology/methods and practices
Delivery
Task 16
Domain 2.7
Ensure knowledge transfer for project continuity
Measurement
Task 17
Domain 2.8
Plan and manage project/phase closure
Uncertainty
or transitions
Figure 18.1 Mapping of integration management
With integration management, the project manager is creating a cohesive, holistic system of organization for just
about everything they, the team, and other stakeholders do on a project. This is to ensure that all project stakeholders have
a common understanding, the project proceeds in an orderly and predictable manner, and the organization and its
stakeholders receive the desired requirements and outcomes for which the project was undertaken. High performance is
required of the project manager and the team in all the PMBOK* Guide’s performance domains.
With that in mind, let’s look at each of the PMBOK* Guide performance domains.
Stakeholders
This domain is about doing the work needed to ensure the desired stakeholder outcomes during and as a result of the
project and its deliverables. These outcomes include good and productive working relationships and communications with
all stakeholders on the project, and a common understanding about and agreement with the project’s goals and objectives.
These outcomes help ensure customer satisfaction with the project and its deliverables. Another desired outcome of high
performance in this domain is that opposition to the project does not lead to negative impacts on the project or its
stakeholders.
Think about it. Can you see how this domain relates to the associated ECO tasks and Process Groups model
integration processes in the integration figure (figure 18.1)?
424
EIGHTEEN PMBOK® Guide and the PM Standard
Team
We discussed high-performing teams in the People domain section of this book. High-performing teams can be achieved
and maintained not only with skilled and motivated people but with good servant leadership. High-performing teams will
take shared organization and ownership of their work. Team members will apply emotional intelligence, leadership, and
other interpersonal and team skills in relationships and work on the project.
integration processes in figure 18.1? Can you see how all these tasks and processes depend upon team performance ?
Development Approach and Life Cycle

High performance in this domain can achieve the desired outcomes of using a development approach and life cycle for
each project that is consistent with organizational governance but also tailored to the specific characteristics and needs of
each project.
A properly selected and executed development approach and life cycle will also result in using phases (and/or
iterations) to deliver the desired business value to project stakeholders at a pace consistent with the needs of the project,
the building of its deliverables, and the maintenance of the project’s benefits beyond project closing.
processes in the integration figure (figure 18.1)? The development approach and project life cycle is carefully
selected at the beginning of planning (or earlier in initiating) and is carefully tailored throughout the project in
accordance with the project’s needs.
Planning
How can you have a successful project without planning? You can’t. Planning, of course, is related to all ECO process
domain tasks and depends on good outcomes from the ECO People and Business Environment domain tasks. Project
planning (and this performance domain) is about achieving the following desired outcomes:
• Planning is tailored to the needs of the project so that stakeholder engagement and each phase, iteration, and
deliverable are planned with rigor but just enough detail, and no more than is needed.
• The project progresses in an orderly fashion with few or no risks that have not been accounted for with risk response
plans in the backlog (or WBS) and schedule, and contingency reserves in the budget.
• As new information becomes available, iterative planning and progressive elaboration on project management plans
continue to evolve, as well as work and measurement strategies, to achieve the defined project outcomes.
processes in the integration figure (figure 18.1)? This performance domain summarizes why planning is so
important to every aspect of project management and product delivery to stakeholders.
Project Work
Just as the executing process group dovetails with the planning process group, the Planning and Project Work performance
domains come together. The desired outcomes from this domain are efficient and effective project performance from all
involved stakeholders, not least of which are the project manager and team.
Good project management work means the following produce results appropriate to the needs of the project and
ongoing process improvements for the organization:
• Project processes • Stakeholder engagement and communications
• Effective management of physical resources • Continuous improvement and learning for the team
and procurements and processes
425
Think about it. Review the integration figure (figure 18.1). Can you see how this domain relates to the
associated ECO tasks and Process Groups model processes in the figure? Think ahead about how the work and
outcomes of this Project Work domain will also dovetail with those of the Delivery and Measurement domains.
Delivery
This domain is about delivering the scope for which the project was undertaken, at the appropriate quality according to
product and quality requirements. Remember the connections of the scope and quality processes:
• The measurement (or monitoring and controlling) process of Control Quality while the team is building a deliverable
leads to...
• The ability of the team and project manager to present the deliverable to the stakeholders (or customer) for acceptance.
This process is called Validate Scope.
Successfully carrying out planning, project work (along with doing measurement along the way) leads to the desired
outcomes of delivery. The project manager and team’s understanding of and ability to execute against a clear understanding
of project requirements should lead to the following desired outcomes. They are the achievement of:
• Projects goals and objectives • The project’s completion on schedule
• The project’s contribution to the organizations • Stakeholder’s acceptance of and satisfaction with
business goals and objectives (tied to advancement project deliverables
of its business strategy)
Think about it. Review the integration figure (figure 18.1). Think holistically about the domains discussed so
far and their associated ECO tasks and project management processes. Doing so should give you a comfortable
overview of project processes and the people skills that support them. You should understand that knowledge of
and interaction with the business environment ensures that projects are governed appropriately and to the
benefit of the organization and its stakeholders. If you are not comfortable yet with how all these concepts come
together, that just means you need more time reviewing this book and its interactions and exercises.
Let’s now look at the final two PMBOK* Guide performance domains.
Measurement
Remember the Monitoring and Controlling process group within the Process Groups model? Measurement is about
monitoring and controlling; observing and measuring from when the project starts until it is completed. Measurement’s
purpose is to be able to see when changes need to be made to improve project performance. Measurement outcomes
include being able to take the data observed about the project and create reliable forecasts throughout the project life cycle.
The outcomes from measurement should be continual and there should be a common understanding of the project’s status
among all stakeholders. This outcome should in turn lead to timely changes within the project as needed to keep project
performance on track and achieve the planned targets and business value.
Uncertainty
PMI defines uncertainty as a lack of understanding or awareness of issues, events, paths to follow, or solutions to pursue.
Uncertainty results from a combination of risk, ambiguity, complexity, and volatility. Let’s look at these concepts, a
combination of which helps explain why uncertainty warrants a performance domain of its own:
• Ambiguity is when events, conditions, and their causes could have more than one interpretation and choice
of solution.
• Complexity means having many related and interdependent factors that need to be considered simultaneously.
Ambiguity contributes to complexity and with complexity there often seems to be contradictory facts or conditions
that are true at the same time. These seemingly contradictory factors or conditions cannot be reconciled so instead the
best choice needs to be made even though all information may not be available with which to make it.
• Risks are uncertain events that may or may not happen on the project. They exist in two basic forms: threats and
opportunities. Threats will cause problems with achieving the balance of project constraints if they occur while
opportunities may allow us to achieve project objectives with even better performance than planned.
446
While PM I teases out these various meanings and summarizes them as uncertainty, what we know without all this is
that projects are about achieving things for organizations and their stakeholders that have never been done before, under
conditions for which all the information cannot be available for the precise reason that it has never been done before.
Outcomes of successfully navigating uncertainty include an awareness and a comfort with one’s ability to manage an
uncertain environment and complex projects that carry risks. Being able to proactively manage uncertainty means the
capacity to plan, measure, and control the project while anticipating and planning for risks so that threats deliver little or
no negative impact on project goals and objectives. We also can add to this that navigating uncertainty successfully means
achieving the outcome of delivering the value for which the project was undertaken on schedule, within budget, and at the
appropriate level of quality. In this way projects also contribute to the organization’s long-term business objectives.
Mapping the PMBOK® Guide to the ECO and Process Groups Processes
The integration management responsibilities of the project manager were a perfect fit for discussing the PMBOK* Guide's
domains because integration is all-encompassing. Now, spending additional time reviewing the remainder of the ECO
Process (domain II) tasks and their associated processes through the lens of PMBOK* Guide domains will help you contin
ue to review this material.
Think about it. We have reproduced all the figures from the Process domain chapters here, for your convenience.
For each one, we have given you key phrases to help stimulate your thinking. Study them now to review the ECO
tasks alongside the Process Groups model processes, but most importantly, relate them to the PMBOK* Guide
performance domains listed.
Scope: Planned, measured, delivered through uncertainty, tailoring

Domain II Schedule Management Domain 2.4
Planning
Task 6 Plan Schedule Management — Domain 2.7
Plan and Manage Schedule Measurement
Define Activities
Planning Domain 2.8
Sequence Activities
Uncertainty
Estimate Activity Durations
Develop Schedule —
Monitoring
Control Schedule —
& Controlling
Schedule: Planning and executing the proper timeline through uncertainty, tailoring

Domain II Cost Management Domain 2.4
Planning
Task 5 Plan Cost Management — Domain 2.6
Plan and manage budget and resources
Planning Delivery
Estimate Costs
Domain 2.7
Determine Budget —
Measurement
Control Costs —| Monitoring
Domain 2.8
Control Resources —> » Controlling Uncertainty
Cost: Staying within planned and agreed spending parameters through uncertainty, tailoring

Domain II Quality Management Domain 2.4
Planning
Task 7 Plan Quality Management — Planning
Plan and manage quality of products/deliverables Delivery
Manage Quality — Executing
Control Quality — Monitoring Domain 2.7

& Controlling Measurement
Domain 2.8
Uncertainty
Quality: Scope, schedule, and cost managed to requirements through uncertainty, tailoring
Resources: Servant leadership requires all People domain skills; tailoring
428

Domain II Communications Management Domain 2.1
Stakeholder
Task 2 Plan Communications Management — Planning
Domain 2.2
Manage communications
Manage Communications — Executing Team
Domain 2.4
Monitor Communications — Monitoring
& Controlling Planning
Domain 2.5
Project work
Domain 2.8
Uncertainty
Communications: Closely tied to all good stakeholder relationships; tailoring

Domain I Risk Management Domain 2.7
Task 7 Measurement
Address and remove impediments, Plan Risk Management —
Domain 2.8
obstacles, and blockers for the team
Identify Risks Uncertainty
Domain II Perform Qualitative Risk Analysis Planning

Task 3
Assess and manage risks Perform Quantitative Risk Analysis
Task 15 Plan Risk Responses —

Manage project issues
Implement Risk Responses — Executing
Monitor Risks — Monitoring

& Controlling
Risk: Embodiment of uncertainty; plan, navigate, measure, tailor
ECO Process Groups Model PMBOK1 Guide

Domain I Procurement Management Domain 2.4
Task 8 Planning
Negotiate project agreements Plan Procurement Management — Planning
Domain 2.5
Conduct Procurements — Executing Project work
Domain II Domain 2.7
Control Procurements — Monitoring
Task 8 Measurement
& Controlling
Domain 2.8
Task 11
Uncertainty
Procurement: Achieve part of scope through partners; plan, execute, measure through uncertainty
Stakeholders: For whom we do it all; tied to communications; tailor through uncertainty
The Standard and the PMBOK® Guide

PMI’s The Standard for Project Management (Standard) and the PMBOK* Guide complement each other and they both
speak to the same purposes and outcomes. But the PMBOK* Guide is organized into performance domains, while the Stan
dard is principle-based.
Both the PMBOK* Guide and the Standard speak of projects as a system for value delivery, a concept discussed earlier
in this book that has run through all our discussions of project management. The purpose of the Standard is to provide an
understanding of how project management enables intended outcomes. The principles in the Standard then, enable the
successful achievement within the performance domains.
First, the most basic principles outlined in the Standard are responsibility, respect, fairness, and honesty, in keeping
with the original principles underpinning the PMI Code of Ethics and Professional Conduct. You should spend a bit of
time observing Figure 18.2, which illustrates the Standards principles alongside the PMBOK* Guide’s performance
domains. As you study this figure, keep in mind that the principles of the standard support and enable the domains and
outcomes described in the PMBOK* Guide.
Principles
Stewardship (financial, social, technical, environmental)
Team (create a safe, collaborative environment)
Stakeholders (proactively, effectively engage, influence)
Value (continually evaluate and adjust project alignment)

Domains
Systems Thinking (holistic view)
Leadership (support individual and team needs)
Tailoring (continuously; each project is unique)
Quality (maintain focus on meeting acceptance criteria)
Complexity (continual navigation through project life cycle)
Risk (maximize opportunity impacts; minimize threat impacts)
and Resiliency (enable change and recovery setbacks)
Change (ease adaptation to new processes and behaviors)
Figure 18.2 The Standard's Principles support the PMBOK" Guide’s Performance Domains
Conclusion
You have reached the end of this book! Congratulations!

As noted in chapter 1, we recommend that you review the information in this book several times to really retain what
you learned. So read through this book again, focusing on the areas where you have identified gaps in your knowledge. In
a second pass through this book you will find that you understand some topics differently than you did the first time, and
other concepts will stand out to you that you previously missed.
Make sure you utilize the tools we have provided to help you pass the exam. Revisit the
Quicktests at the beginning of each chapter to make sure you know each of the items presented. If you https://rmcls.com/rmc-
don’t know something, note it as a gap and revisit that section to familiarize yourself with that topic.
Play the Rita’s Process Chart™ and Rita’s Agile Process Chart™ games on our RMC Resources page.
Go back to any exercises you struggled with and try them again. And, utilize the RMC Interactive
Chapter Quizzes to gain experience answering questions similar to the ones you’ll find on the exam.
Having a solid understanding of the project management process and the material presented in
RMC RESOURCES
this book will not only help you pass the exam (you can use logic instead of having to memorize
information), it will also enable you to apply what you have learned to your real-world projects.
Thank you for taking this journey with us. We hope you will come back to RMC Learning Solutions after you have
earned your PMP. We can help you continue your training and earn PDUs to maintain your certification through our
advanced instructor-led and eLearning courses and products. So good luck, and we look forward to seeing you after you
pass the exam!
Index
risk definitions 287-288

Symbols risk monitoring 311
8-step process for leading change 392 scope planning 158-160
80/20 rule 265 values 418
agile ceremonies 184-185,268
daily standup 268
A iteration planning meeting 268
retrospective 268
AC. See actual cost (AC)
agile coach 69
accept 302
agile generic terms
acceptance criteria 169, 264
and Scrum 412
acceptance test-driven development (ATDD) 181
agile manifesto 331
accepted deliverables 185
agile methodologies 409-422
Acquired needs theory 116
overview 409
Acquire Resources 136-139
Agile Mindset 420-421
agile 137
agile modeling 369-372
artifacts of 139
agile release planning 47, 219
hybrid 137
agile schedule development 219
methods 138
activity attributes 133,198 agile story decomposition
activity estimates 198 methods 181-182
agile team leader. See also agile coach; See also Scrum Master
activity list 198
responsibilities list 72
activity standard deviation 202-203
role of 69
actual cost (AC) 240
agile teams 137
adaptive 7
agile team structure 137
ADKAR model 392
agile triangle 421-422
affinity diagram 165,263
agreements 162
affinity estimating 203,235
definition 321-322
agile 69,166,409-422
alternatives analysis 192, 205,234, 263, 366
and stakeholder engagement 368-373
ambiguity 426
closing a project 99
ambiguity risk 292
development approach 7
analogous estimating 199
executing approach 35
initiating 45 appraisal 260
iterations 48 architectural spike 287,414
plan resources 129 archive 82
principles 419 assignable cause 267
process overview 44-49, 51-52 assumption log 65, 80,162,198, 256
closing 48 assumptions 65
feasibility 45 high-level 83
initiation 45-47 assumptions and constraints 360
release planning 47 audit 263-264,311
project charter 45 autonomy 114
project pre-mortem 293 avoid 301
quality management 267-270
*155
BAC. See budget at completion (BAC) case study 100-102, 146-147,186-187,224-227,247-248,
backlog 69,153,158,171,185,194,197,219,220,229,239, 272,282-283,317-319,372-373
313,368. See also product backlog cause-and-effect diagram 261-262, 263,264
and roadmap 159 centralized contracting 325
prioritizing 47,87 centralized vs. distributed management and leadership 107
risk-adjusted 308-309 CFDs. See cumulative flow diagrams (CFDs)
stories 159-160 change 312
backward pass 210-211 managing 238
balanced matrix 56 models 392
bar chart 207,222 project management practices 391
baselines 86. See also cost baseline; schedule baseline, transitional 391-392
scope baseline change control board (CCB) 96
basis of estimates 206,235 change-driven development approach 7
benchmarking 163,259 change management
benefits management plan 234 agile 98
beta distribution 201 change management plan 85, 87
bid 340 change request 239
bidder conference 340 change requests 90,93-94,143,185,222,342-343,346
bid documents 338-339 corrective action 94
Blanchard, Ken 118 defect repair 94
bottom-up estimating 199 preventive action 94
brainstorming 162, 259, 356 changes 66,192
budget 241 adaptive environment 95
constructive 346
agile project 229
plan-driven projects
defintions related to 229-230
detailed process 97-98
preparing 236
summary process 96-97
budget and resource management 229-248
chartering 171
desired outcomes 23 L
checklist 261,264
budget at completion (BAC) 240
checksheet 255, 265
budget estimate 234
closed procurements 347
build and support team performance 125-150
Close Project or Phase 99-100,185
overview 125-128
burndown chart 144,221,224 closing 44, 84
risk burndown chart 312-313 reasons for entering 35
burn rate 237 coaching 121
burnup chart 144 Collect Requirements 161-162
business case 64,65,82,153 artifacts needed 162
colocation 141
business environment 19,377
common understanding 354
Business Environment domain
communication 367
overview 378-380
business risk 292 blockers 112
channels 114,277
buyers and sellers
five Cs 110
definition 322
flow 108
gap 111-112
methods 67,113
models 110-111
communication (continued) contract types 327-329
skills 108-114 advantages and disadvantages of 329
strategies 275 and risk 329
technology 112-113 control account 175
types 108 control chart 266-267
communications management Control Costs 237-246
desired outcomes 275 control limits 266
overview 273-275 Control Procurement 343-348
communications management plan 19, 278,362 artifacts of 346-347
communication strategies 275 methods 345
company culture 130,193 Control Quality 254-255, 258-259
complexity 285, 378,426 artifacts 258
of information 112-113 methods 264-267
compliance. See also project compliance relationship to Validate Scope 185-186
definition 378 terminology 258
definitions related to 377-378 Control Schedule 223-224
organizational governance 381-382 artifacts 224
project management 382 methods 224
requirements 59, 380-382 Control Scope 182-186,184-185
compliance and delivering value 377-392 agile 184
Conduct Procurements 340-343 artifacts 185-186
artifacts of 342-343 definition 182
methods 340 COQ^See cost of quality (COQ)
configuration management plan 85, 87 core concepts 395-399
conflict 71,345 corrective action 94
management 81,122-123 cost
managing contract interpretation 345 and quality 260
model 123 of conformance 260
resolution 106, 144 of non-conformance 260
source of 123 cost aggregation 236
conformance, cost of 260 cost baseline 133,136,129,232,234-237, 239,300,305-306
constraints 65-66, 167 cost-benefit analysis 61-62,255,259, 304
high-level 83 cost contract 329
project schedule 241
cost estimates 133, 235, 237
constructive changes 346
cost management
context diagram 164-165
process 230-231
context level data flow diagram 164 cost management plan 232
contingency plans 305
cost of change 267
contingency reserves 197, 205, 236, 239,305-307 definition 351
continuous improvement 184,364 cost of change curve 267
definition 251 cost of conformance 260
contract 305. See also contract types cost of non-conformance 260
agile procurement 331
cost of quality (COQ) 260
definition 321
cost performance index (CPI)
interpretation 345-346
formula 241
negotiations 326
cost-reimbursable (CR) contract 328-329
termination 347
cost variance (CV)
terms and conditions 332-333
understanding 325-335 formula 241
contracting, terms to know 332 CR. See cost-reimbursable contract (CR) 71 * C
crashing 215 dependencies 194,221
Create, Read, Update, Delete (CRUD) 181-182 definition 189
Create WBS 173-182 types of 195
critical path 208 depreciation 63-64
activities 223 accelerated 64
definition 189 straight-line 63
method 208-214 design for X 264
critical thinking 106 design of experiments (DOE) 263
Crystal 416 Determine Budget 234-237
cumulative flow diagrams (CFDs) 219-220 outputs 237
customer satisfaction 354 development approach 7, 84, 86,193, 276,425
customer-valued prioritization 185 development approach and life cycle (domain)
cycle time 268-269 PMBOK” Guide 425
Develop Project Charter 80-84
Develop Project Management Plan 84-89,193
D Develop Schedule 207-223
daily feedback loop 267 outputs 221-222
daily scrum 413-414 Develop Team 139-143
daily standup 48, 268, 279,281, 413. See also standup artifacts of 143
methods 140
data analysis 184,192,259
Direct and Manage Project Work 90-91
methods 66
direct costs 233
data gathering 81
discretionary dependency 195
methods 66
data representation 295,356 document analysis 262,356
methods 66 DOE. See design of experiments (DOE)
decentralized contracting 325 Drexler/Sibbet Team Performance Model 120
decision making 184, 234 Dreyfus Model of Adult Skill Acquisition 117
methods 206 DSDM. See dynamic systems development method (DSDM)
decision-making dynamic systems development method (DSDM) 416
methods 67,259
decision tree analysis 298-299
decomposition 194
E
agile 158 EAC. See estimate at completion (EAC)
example 180 earned value analysis (EVA) 142
scope 173-182 definition 230
dedicated team 137 formulas 240-242
defect cycle time 269 earned value (EV) 240
defect repair 94 definition 229
defects 265,269 inaction 243
Define Activities 193-194 reports 276
Define Scope 171-172 terminology, understanding 242
artifacts 172 earned value management (EVM) 60,229, 239-240
definition of done 169, 369 definition 230
definition 250 earned value measurement 142,144,157,196
definitive estimate 234 agile project 279
economic measures 336
deliverable 264
deliverables 157,192, 261. See also accepted deliverables economic value added (EVA) 63
delivering value 382-387 EEFs. See enterprise environmental factors (EEFs)
delivery (domain), PMBOK* Guide 426 effective listening 111
fl56
elevator pitch. See elevator statement and scope management 155
eliminate waste 378 and team performance 125-127
emotional intelligence 106-107,144 and budget and resources 230-231
EMV. See expected monetary value (EMV) and Business Environment domain 378-380
domain III: business environment 31
enhance 302
domain II: process 30
enterprise environmental factors (EEFs) 53, 65-66,130
domain I: people 30
entity relationship diagram (ERD) 260
and procurement management 322
environmental changes and risk management 288
process for managing 388 and stakeholder engagement 352-353
epics 180 executing 42
ERD. See entity relationship diagram (ERD) reasons for entering 35
errors and pitfalls, common 406-407 Exercise Notebook 9
escalate 302 expectations, stakeholder 353-354
Estimate Activity Durations 197-206 expected monetary value (EMV) 297-298
artifacts 206 expected value (EV) 306
data analysis expert judgment 67, 192, 199
methods 205
explicit knowledge 91
estimate at completion exploit 302
formula 241
external dependency 195
estimate at completion (EAC) 240
external failure 260
formula 241
eXtreme programming (XP) 414-416. See also XP
Estimate Costs 197,231-234
artifacts needed 233
estimate ranges 234 F
Estimate Resource Requirements 133-136
face-to-face communication 113
artifacts needed 133
artifacts of 134 facilitation 163
methods 134 failure 260
estimate to complete (ETC) 197,240 failure analysis 263
formula 241 fallback plans 305
estimating fast failure 288
adaptive 203-205 fast tracking 214—215
methods 67 FDD. See Feature Driven Development (FDD)
predictive 199-203 feasibility 45
things to know for the exam 197 feature backlog 47
estimating methods Feature Driven Development (FDD) 418
adaptive 235 features 180
advantages and disadvantages 233-234 feedback 113,275
ETC. See estimate to complete (ETC)
finish formula 209
EV. See earned value (EV)
finish-to-finish (FF) 195
EVA. See economic value added (EVA)
finish-to-start (FS) 195
evaluate and address external business environment changes
fishbone diagram. See cause-and-effect diagram
for impact on scope 387-390
fist of five 206
EVM. See earned value management (EVM)
fixed costs 232
exam environment, preparing for 404-406
fixed-price contract (FP) 327
Examination Content Outline (ECO) 30-31,55
float 209
and communications management 274
definition 189
and integration 78-79
flowchart 261
and quality 252
focus groups 163,355
and schedule 190-191
457
force majeure 333 I
forecasts 192,426
formulas 402 Identify Risks 291-293
earned value 240-242 artifacts of 293
forward pass 210-211 methods 293
Identify Stakeholders 355-358
FP. See fixed-price contract (FP)
artifacts of 357-358
free float 209
methods 355-357
frequent verification and validation 268
1DIQ. See indefinite delivery, indefinite quantity (1DIQ)
functional manager
contract
IFB. See invitation for bid (IFB)
role of 71
Implement Risk Responses 310
funding 290
artifacts of 310
funding requirements 237
incentives 333
incremental product delivery 185
G indefinite delivery, indefinite quantity (1D1Q) contract 329
independent cost estimates 341
Gantt chart 175,195,276
indirect costs 233
gold plating 19,153
individual and team assessments 141-142
definition 251
influencing 121
governance
information density 112-113
organizational 19, 55
information radiators 281, 368-372
project 55-56
initiating 39
grade 250-251
reasons for entering 34
ground rules 129,133
initiation 176
gulf of evaluation 111-112,364
initiator, role of 70
gulf of execution 111-112, 364
inspection 184, 266
integrated change control 179, 391
H integration 77-102
management, overview 78-80
halo effect 138
interactive communication 113
Herzberg s Two-Factor Theory of Motivation 116
model 278
high-performing team 116,119,425 interactivity 112-113
histogram 262, 264 internal dependency 195
resource 134
internal failure 260
historical data 199
internal rate of return (IRR) 61
historical information 64-65,197,199
interpersonal and team skills 71,105,144,367
historical records 278
Herzberg s Two-Factor Theory of Motivation 116
human and material resource cost rates 234 Maslow’s Hierarchy of Needs 115
human resources (team) management plan 132 McClelland’s Theory of Needs 116
hybrid 48-49 McGregor s Theory of X and Y 115
acquiring resources 137 methods 67
assessments 142 teambuilding 116
dependencies 195-196 interviews 162,259,355
planning 160-161 intrinsic vs. extrinsic motivation 114-115
development approach 7 invitation for bid (IFB) 338,340
hygiene factors 116
IRR. See internal rate of return (IRR)
I-shaped skills 117
ishikawa diagram. See cause-and-effect diagram
issue log 90,144,145-146 Lean 132,410
issues 268 seven principles 410
iteration 47,219,220,267. See also agile, iterations learning curve 200
cycles 99 legal contract 342
definition of 154 lessons learned 65,90,92-93,231,239, 340
planning 160 final 99
planning meeting 268 technical 92
review 48,169,280 lessons learned register 198,313
iterative and incremental development 267 life cycle 7,84,276,425. See also project life cycle
logical data model 260
logical relationships 195
J
logistics and supply chain management 336
JAD. See joint application design (JAD) low-fidelity prototype 370-371
JIT. See just in time (JIT)
joint application design (JAD) 164
just in time (JIT) 132,180 M
definition 251 make-or-buy analysis 335,336,339
make-or-buy decisions 337
K Manage Communications 278-281
artifacts of 281
Kaizen 132,251 hybrid project 278
Kanban 410-411 methods 278-280
core principles 411 management
Kanban board 268,281,369,411 vs. leadership 105
virtual 141 management plans 84-85. See also change management plan;
Key Performance Indicators (KPIs) 142 See also configuration management plan; See also re
kickoff meeting 89 quirements management plan
agile 89 agile 85
knowledge management 91-92 hybrid 85
knowledge sharing 280-281 management reserves 205,236,239, 305-306
agile projects 281 management reviews 86
KPIs. See Key Performance Indicators (KPIs) Manage Project Knowledge 91-93
Manage Quality 254-255,257-258
and Control Quality 257
L artifacts 258
law of diminishing returns 63 methods 261-264
Manage Schedule
leadership
definitions related to 189-190
agile project 127-128
Manage Stakeholder Engagement 362-366
concepts 121
artifacts of 364
definitions related to 106
overview 105-107 methods 364
project managment principle 386 Manage Team 144-146
responsibilities 127-128 artifacts needed 144
vs. management 105 artifacts of 145-146
leadership skills 105-124 methods 144
leads and lags 196,198 mandatory dependency 195
definition 189 marginal analysis 260
lead time 269 Maslows Hierarchy of Needs 115
material breach 333
matrix 260
matrix representations 260 N
McClelland’s Theory of Needs 116
McGregors Theory of X and Y 115 near-critical path 209
mean 266 negative float 214,215
measurement 224 negotiation 121,342
domain, PMBOK” Guide 426 net present value (NPV) 60-61
meeting management 81 network diagram 133, 194,196, 207, 214,218. See also proj
meetings 67,90,279 ect schedule network diagram
agile 184-185,268 noise 110
hybrid projects 279 nominal group technique 163
rules 279 nonconformance, cost of 260
methods, frequently used 66-68 nondisclosure agreement 332
metrics 254 normal distribution 259
milestone chart 207,222 NPV. See net present value (NPV)
milestone list 336, 344
milestones 86,90
definition 190
0
mind map 164, 260 observation 163
minimally marketable feature (MMF) 185, 388 one-point estimating 200
minimally viable product (MVP) 388 OPAs. See organizational process assets (OPAs)
definition 154 operational work 53
mitigate 301 opportunities 286
model, definition of 50 risk response strategies 302
Monitor and Control Project Work 93-94 opportunity cost 63
artifacts of 93-94 organizational breakdown structure 131
Monitor Communications 282 organizational change 166
monitoring and controlling 32, 34,43 organizational culture 390-391
reasons for entering 35-36 organizational governance 19,55
Monitor Risks 311-314 compliance 381-382
artifacts of 313-314 organizational knowledge repositories 53,64
methods 311-313 organizational process assets (OPAs) 53,64-65, 130, 133,
Monitor Stakeholder Engagement 365-368 162,175,193, 231,249, 290, 314
artifacts 366 organizational project management (OPM) 55
artifacts of 368 organizational structure 56,71
methods 366-367
functional organizations 56
Monte Carlo analysis 218, 297
project-oriented organizations 56
MoSCoW analysis 181 organizational theory 132
motivating agents 116 OSCAR model 118
motivation osmotic communication 92
intrinsic vs. extrinsic 114-115 Ouchi 115
models 114-116
out of control 266
multicriteria decision analysis 163,259, 263,304
output 177
multicriteria weighted analysis 259
mutual exclusivity 258
p Plan Risk Responses 300-309
padding 197, 198 Plan Schedule Management 192-193
parametric estimating 199-200 Plan Stakeholder Engagement 358-362
Pareto chart 264-265 artifacts of 362
partnership 137 methods 360-361
part-time team 137 platform-based breakdown 181
past performance history 341 PMBOK* Guide
path convergence 196, 218 and the Standard 423-430
path divergence 196 mapping to ECO and Process Group Model 427
payback period 61 overview 49-50
PDM. See precedence diagramming method (PDM) performance domains 424
performance assessments 144 PM FASTrack" Cloud Exam Simulator
performance measurement 179, 235 using this book with 10
performance measurement baseline 86, 224, 229 PMI-isms 18-22,198
performance reviews 265 quality-related 252
PMIS. See project management information system (PMIS)
Perform Integrated Change Control 86, 94,95-98,186
PMO. See project management office (PMO)
Perform Qualitative Risk Analysis 294-296
PMP® exam
artifacts of 296
methods 294-296 applying for 4
Perform Quantitative Risk Analysis 296-300 how to study for 22-25
preparedness 5
artifacts of 300
qualifications 3-4
methods 297-299
question examples 12-17
personas 46,277, 281,357,368
study plans 22-25
phase gate 33,391
What is it like? 11-12
Pink, Daniel 114
portfolio
plan-based development approach 7
definition of 55
Plan Communications 276-278 portfolio management 54-55
artifacts 277-278 portfolio manager
Plan Cost Management 231-232
plan-driven 69 role of 71
planned value (PV) 60, 240 power/interest grid 356
planning 40, 176 preapproved seller list 336
domain, PMBOK* Guide 425 pre-assigned team members 137
reasons for entering 34 pre-assignment 138
Planning Poker 204-205,235
precedence diagramming method (PDM) 194-196
Plan Procurement Management 335-339
presentations 342
artifacts needed for 335-336
present value (PV) 60
prevention 260
methods 336-337
prevention over inspection
Plan Quality Management 254-255, 256-257
definition 251
artifacts 257
preventive action 94
methods 259-261
Plan Resource Management 129-133 price quote 340
artifacts needed (inputs) 130 prioritization diagram 259
artifacts of 132-133 prioritization matrix 261,263
plan resources privity 332
agile project 129 probability 258
Plan Risk Management 290-291
probability and impact program management 54
definitions of 291 program manager
matrix 295 responsibilities list 75
problem-solving 264 role of 71
process analysis 263,385-386 progressive elaboration 29,41, 88
process-based breakdown 181 progress reporting 239
process flows. See flowchart project
Process Groups model 31-36,69,274-275 characteristics of 54
and budget and resources 230-231 definition of 53-54
and integration 78-79 project agreements 129
and procurement management 322-323 project approach 7. See also development approach
and quality 253-255 project artifacts 91
and risk management 288-289 project backlog 412. See also backlog
and schedule 190-191 project charter 19,45,65,80-84,89,162,237, 380
and scope management 155 agile 80
and stakeholder engagement 352-354 creating 80-81
and team p erformance 125-126 example 82-84
process map. See flowchart project compliance 166. See also compliance
procurement 321-350 planning and managing 380-382
definition 321 project coordinator 56
non-competitive forms 339 project documents 89,130
project manager s role 325
project elevator statement 360
procurement management
project environment 7
project expediter 56
desired outcomes 324-325
project float 209
detailed uutcome 325
overview 322-325 project governance 55-56
procurement management plan 130, 337,344 project life cycle 7,86,193. See also life cycle
procurement process, example 324-325 project management approach 7
procurement statement of work (SOW) 337-338. See project management information system (PMIS) 67,90, 196,
also statement of work (SOW) 207,223,234
product analysis 172 project management office (PMO) 18,58-59
product backlog 46,159-160,193. See also backlog controlling 58
example 160 directive 58
product demos 169,281 supportive 58
project management plan 19, 20,21, 84, 85-88,193
product life cycle 268
agile 87
product manager
approval 89
role of 70
hybrid 87
product owner 18,19,47,71,80, 87,159, 185,194,195,368
updates 185
project management principles 386-387
role of 69
project manager
product release 185
on agile project 127
product roadmap 46,47,87,158-159. See also release map;
See also story map
role
product scope
adaptive environment 69
agile project 157
predictive environment 68
definition 154
role of 68-69
Product Vision Statement 360
project performance appraisals 142
professional responsibility 122
project pre-mortem 293
program, definition of 54
project reporting 280 project managment principle 387
project risk, definition 285 requirements 256
project risk management, definition 286 quality functional deployment (QFD) 164
project roles 68-76 quality management 256-257
agile team leader 69 agile 267-270
functional manager 71 desired outcomes 255
portfolio manager 71 methods 259
product manager 70 overview 252-255
product owner 69 quality management plan 130,264
program manager 71 quality metrics 257
project manager 68-69 quality of deliverables and products 249-272
project sponsor 70 quantitative analysis
project team 70 vs. qualitative 294
resource manager 71 quantitative risk analysis 294
responsibilities lists 72 questionnaires 265
stakeholders 70-71 and surveys 163
project schedule 175, 221. See also schedule Quicktest 29,53,77,105,153,189, 229,249,273,321,351,
project schedule network diagram 194,196. See also network 409,423
diagram
project scope, definition 154
project scope statement 172 R
project selection 59-64,176
RACI chart 131
concepts 64 RAM. See responsibility assignment matrix (RAM)
economic measures for 60
RBS. See resource breakdown structure (RBS)
methods 64
recognition and rewards 121
project sponsor
recognition plan 132
responsibilities list 73-74
role 70 records management system 347
project team reestimating 224
responsibilities list 74 regression analysis 200
role 70 regulatory compliance 381
project team assignments 144,198 regulatory requirements 59
project work (domain), PMBOK® Guide 425-426 relative sizing 204
proposal evaluation 340-341 release 250
prototype 163 and iteration planning 87, 281
pull communication 113 release map 47. See also product roadmap
purchase order 328 release plan 171
pure risk 292, 302 reports, types 280
push communication 113 request for information (RFI) 338
PV. See planned value (PV); See present value (PV) request for proposal (RFP) 338, 340
request for quotation (RFQ) 338
request for quote (RFQ) 340
Q requirements 134, 155
QFD. See quality functional deployment (QFD) agile projects 162
qualitative analysis analyzing 161-170
methods 162-165
vs. quantitative 294
quality balancing 166
categories 161
definition of 249-250
communications 276, "LT1
compliance 380-382
requirements (continued) risk definitions
conflicting 167 agile 287-288
detailed 171 risk event 286
documentation 162,169-170 risk factors 286
elicitation 153, 161-170 risk management 86,197
methods 162-165 common mistakes 314
missed 267 definitions related to 285-286
regulatory 381 desired outcomes 290
resource 198 overview 288-289
stakeholder 353 risk monitoring
verifying 169 agile 311
requirements management plan 85, 87, 158 risk owner 301,305
requirements traceability matrix 162, 170,256 risk parameters assessments 295-296
reserve analysis 205,234,239,312 risk reassessments 311
reserves 305-306 risk register 198, 237,293
residual risks 301 updates 305,313-314
resource assignments 139 risk report 304
resource availability 136 risk reserves 236
resource breakdown structure (RBS) 131, 134, 198 risk responses
resource calendar 133, 139, 198 agile 308-309
resource histogram 134 risk response strategies 301-304
resource leveling 134, 218 for opportunities 302
Resource Management 128 for threats 301-302
resource management plan 130,132, 133 risk reviews 311
resource manager risks 426
responsibilities list 74 residual 305
role of 71 risks and issues 285-320
resource optimization 218 risk spike 414
resources, negotiating for 138 risk strategy 290
resource smoothing 218 risk threshold 287
responsibility 116 risk triggers 305
responsibility assignment matrix (RAM) 131 Rita’s Agile Process Chart 44-48
retrospective findings 280 Ritas Process Chart 37-44, 87,99
retrospectives 235,268,281,312 game 44
return on investment (ROI) 55, 60, 234 how to use 37
rework 267 RMC Interactive Chapter Quizzes 10
RF1. See request for information (RF1) RMC Resources 9,189
RFP. See request for proposal (RFP) ROI. See return on investment (ROI)
RFQ. See request for quotation (RFQ) roles and responsibilities 68-75,116,129
risk 230 rolling wave planning 29,41
residual 301 ROM. See rough order of magnitude (ROM) estimate
risk-adjusted backlog 308-309 root cause analysis 263,264, 360, 366
risk appetite 287 rough order of magnitude (ROM) estimate 234, 391
risk averse 287 risk owner
risk breakdown structure (RBS) 291 definition 286
risk burndown chart 312-313 rule of seven 266
risk categories 291-292,294
risk data quality assessment 294
s Scrum 412-414
and agile generic terms 412-413
SAFe. See also scaled agile framework (SAFe) core concepts 413
core values 417 Scrum Master 18,69
leadership 418 secondary risk 30, 305
salience model 356 selected sellers 342
scaled agile framework (SAFe) 417 self-actualization 115
scatter diagram 200,259,262, 264 self-evaluation checklist 6
schedule 241-243 self-managing team 114
planning seller proposal 340
agile projects 192
sensitivity analysis 297
Sequence Activities 194-196
hybrid projects 192
servant leadership 19,107, 231
schedule baseline 86,192-193,214,222,223, 306 set-based design 309
schedule compression
share 302
methods for 214-217
shu-ha-ri model 116
summary 217
sigma 259. See also six sigma
schedule data 222
definition 251
schedule management
simulations 297
desired outcomes 191-192
single-point estimating. See one-point estimating
process overview 190-192
situational leadership models 118
schedule management plan 193, 224
Situational Leadership II 118
schedule model, definition 190
six sigma 132. See also sigma
schedule network analysis 208, 214
definition 251
schedule performance index (SPI)
skill mastery
formula 241
models 116-117
schedule variance (SV)
slice stories 47, 171
formula 241
source selection analysis 337
scope 153-188
source selection criteria 337,339
defining
adaptive 171 SOW. See statement of work (SOW)
special cause variation 267
predictive 171
special provisions 332
on agile projects 95,153
scope baseline 98,130,133,178-179,182,186,193, specification limits 266
235,256 SPI. See schedule performance index (SPI)
scope decomposition spike 287,414
agile 179-182 sponsor. See also project sponsor
scope management sprint backlog 412
agile 157 stakeholder 19,351-374
definitions related to 154 and requirements 161-167
desired outcomes 157 agile project 352
overview 155-157 definition 351-352
plan-driven 156 domain, PMBOK* Guide 424
planning 158-161 engagement plan 19
things to know (for exam) 153-154 project managment principle 386
scope management plan 158 responsibilities list 74
scope planning role of 70-71
agile 158-160 stakeholder analysis 356
stakeholder cube 356
stakeholder engagement team charter 133,144,380
and agile 368-373 team configurations
definitions related to 351 types 137-138
desired outcomes 354 team culture 140-141
overview 352-354 team development
process 353-354 models 119-120
stakeholder engagement assessment chart 360 team lead 69
stakeholder engagement plan 130,277,362, 368 team performance 125-150
stakeholder expectations 162 domain, PMBOK* Guide 425
stakeholder mapping 356 technical performance analysis 312
stakeholder register 130,162,277,355,357-358 terminology
standard deviation 259 how it is used 7
standup 181,280. See also daily standup terms and conditions 332-333, 339
start formula 209 terms of reference (TOR) 338
start-to-finish (SF) 195 test and inspection planning 261
start-to-start (SS) 195 theories of X, Y, and Z 115
statement of work (SOW) 327 threats 286
statistical independence 259 and risk response strategies 301-302
statistical sampling 265 threats and opportunities
stewardship definition 286
project managment principle 386 three-point estimating 200-201
story 47,159-160,197,250 throughput 269
story cards 193 time and material (T&M) 328
story map 46, 235 timebox 172
story points 220 definition 154
strong matrix 56 time-boxed iteration 268
subject matter experts 355 tips for exam preparation 403
subject matter expert (SME) 70 to-complete performance index (TCPI)
sunk costs 63 formula 241
support organizational change 390-392 top-down estimating. See analogous estimating
support performance 129 TOR. See terms of reference (TOR)
surveys 265,355 tornado diagram 297
SV. See schedule variance (SV) total float 209
system 378 total quality management (TQM) 251
systems thinking 383-384 TQM. See total quality management (TQM)
project managment principle 386 training 121
transfer (deflect, allocate) 302
transition 100,392
T transitional change 391-392
T&M. See time and material (T&M) Transition Model 392
tacit knowledge 91-92 triangular distribution 200-202
tailoring 86 trust 121
project managment principle 387 T-shaped skills 117
TCPI. See to-complete performance index (TCPI) t-shirt sizing 203-204, 235
team Tuckman s Ladder Model of Team Formation 119-120
project managment principle 386 types of cost 232-233
team assessments 141-142
teambuilding 140 446
uncertainty 285,427 watch list
domain, PMBOK* Guide 426-427 definition 286
user-based breakdown 181 waterfall 7
user stories 163-164,204 WBS. See work breakdown structure (WBS)
utilizing data 366-367 WBS dictionary 19,177-178
weak matrix 56
weighting system 341
V whole team 415
VAC. See variance at completion (VAC) why-why diagram. See cause-and-effect diagram
Validate Scope 182-186,426 W1P. See work in progress (W1P)
agile 184-185 wireframe 281,372
artifacts 185-186 workarounds 311
definition 182 work authorization system 90, 193
methods 184-185 work breakdown structure (WBS) 19,131,133,153,156,
process 169 173-179,193
relationship to Control Quality 185-186 guidelines 174-175
value work data information 93
project managment principle 386 workforce tracking system 370
value chain working capital 63
definition 378 working relationships 354
value delivery
work in progress (W1P) 268-269, 281
work package 175,177
system 49
activities 194
value delivery office (VDO) 58
work performance data 67-68,90,313
value delivery system 384
work performance information 67-68,185, 313,368
value-driven delivery 230
work performance reports 67-68, 144, 278
value management team 71
value stream 385
mapping 378,386 X
variability risk 292
XP. See also eXtreme programming (XP)
variable costs 232
core practices 415
variance at completion (VAC) 240
values 414
formula 241
VDO. See value delivery office (VDO)
velocity 47,220,237
Virginia Satir Change Model 392
virtual team 137,141
visioning 158, 171
volatility 285,426
voting 163
Roman 206

PMP Exam Prep - 2023 11th Edition (Rita Mulcahy, PMP With Margo Kirwin)

Uploaded by

PMP Exam Prep - 2023 11th Edition (Rita Mulcahy, PMP With Margo Kirwin)

Uploaded by

The International Best-Selling PMP® Exam Prep Book for 30+ Years

Proven study method

Exclusive exam prep tips and tricks

Interactive chapter quizzes with scoring

Essential info on plan-driven and agile approaches

By Rita Mulcahy, PMP

with Margo Kirwin, CPLP, PMP, PMI-ACP, PMI-PBA

Section I Studying for the PMP® Exam 1

Chapter 3 Project Management Foundations 53

Chapter 5 Leadership Skills 105

Chapter 6 Build and Support Team Performance 125

Section IV Domain II: Process 151

Chapter 8 Schedule 189

Chapter 10 Quality of Deliverables and Products 249

Chapter 11 Communications 273

Chapter 12 Risks and Issues 285

Chapter 14 Stakeholders 351

Section V Domain III: Business Environment 375

Section VI Pulling It All Together 393

Tricks of the Trade for the beginning of each

Studying for the PMP® Exam Use the Quicktest to test

Qualifying to Take the Exam

Educational Background Project Management Work Experience

Applying to Take the Exam

Are You Ready for the PMP Exam?

The following are examples of projects or programs using a hybrid approach:

How to Use This Book

How Terminology Is Used

Project Environments and Project Management Approaches

Project Life Cycle

How This Book Is Organized

Section III: The ECO People Domain

Book Chapter Organization

Each of chapters four through nineteen contains:

RMC Resources Web Page

RMC Interactive Chapter Quizzes

Examination Content Outline (ECO) Domains Percentage of Questions

Additional Important Aspects of the Exam

A. Replan the project to accommodate this delay.

A. Go to the team, go to management, go to resources managers

Questions in Different Format Types

Action Order in which to perform

Recurring Themes—PMI-isms to Know for the PMP Exam

Planning the Project

While the Project Work Is Being Done

with a risk-adjusted backlog that includes risk response plans.

Closing the Project

How to Study for the PMP Exam

Your Step-by-Step Study Plan

Plan B: Using This Book As a Stand-Alone

How to Use This Book in a Study Group

• Predictive and agile approach overviews

PMP® Exam References • Progressive elaboration

Definitions Related to Planning

Rolling Wave Planning and Progressive Elaboration

Examination Content Outline (ECO) Overview

• Conflict resolution • Participatory decision making • Team performance evaluation

Domain II: Process

Domain III: Business Environment

The Process Groups Model Overview

FIGURE 2.1 Project management process

The five process groups interact with the selected

FIGURE 2.4 Large project with an agile approach

Start Here: Take time to fully understand figure 2.5

Project Constraints and Other Management Areas

ECO Process Tasks (Domain II) Process Groups Model

Plan and manage scope

Plan and manage schedule

Plan and manage quality

Assess and manage risks &

Plan and manage procurement

Rita’s Process Chart™: A Vital Study Tool

How to Use Rita’s Process Chart™

Rita’s Process Chart™

INITIATING PLANNING EXECUTING MONITORING & CLOSING

Create change and Hold meetings Manage, evaluate, and close

- Branding/style schemes - UID - Manage own insur