Certified

Associate in
Project
Management
(CAPM)
®

Exam
Official Cert Guide

VIJAY KANABAR
ARTHUR P. THOMAS
THOMAS LECHLER
ii Certified Associate in Project Management (CAPM)® Exam Official Cert Guide

Certified Associate in Project Management

(CAPM)® Exam Official Cert Guide
Copyright © 2023 by Pearson Education, Inc.

All rights reserved. No part of this book shall be reproduced, stored in a retrieval system, or transmitted
by any means, electronic, mechanical, photocopying, recording, or otherwise, without written permission
from the publisher. No patent liability is assumed with respect to the use of the information contained
herein. Although every precaution has been taken in the preparation of this book, the publisher and
author assume no responsibility for errors or omissions. Nor is any liability assumed for damages
resulting from the use of the information contained herein.

ISBN-13: 978-0-13-791809-6

ISBN-10: 0-13-791809-7

Library of Congress Control Number: 2023930980

ScoutAutomatedPrintCode

Trademarks
All terms mentioned in this book that are known to be trademarks or service marks have
been appropriately capitalized. Pearson IT Certification cannot attest to the accuracy of this
information. Use of a term in this book should not be regarded as affecting the
validity of any trademark or service mark.

PMI, Certified Associate in Project Management (CAPM), CAPM, the CAPM and Badge
Design, and PMBOK are marks of Project Management Institute, Inc.

Warning and Disclaimer

Every effort has been made to make this book as complete and as accurate as possible, but no
warranty or fitness is implied. The information provided is on an “as is” basis. The authors and
the publisher shall have neither liability nor responsibility to any person or entity with respect
to any loss or damages arising from the information contained in this book.
 iii

Special Sales
For information about buying this title in bulk quantities, or for special sales opportunities
(which may include electronic versions; custom cover designs; and content particular to your
business, training goals, marketing focus, or branding interests), please contact our corporate
sales department at [email protected] or (800) 382-3419.

For government sales inquiries, please contact [email protected].

For questions about sales outside the U.S., please contact [email protected].
Vice President, IT Professional: Mark Taub Product Line Manager: Brett Bartow

Executive Editor: Laura Norman Development Editor: Ellie C. Bru

Managing Editor: Sandra Schroeder Senior Project Editor: Tonya Simpson

Indexer: Timothy Wright Proofreader: Donna E. Mulder

Technical Editor: Dr. Roger Warburton Publishing Coordinator: Cindy Teeters

Cover Designer: Chuti Prasertsith Compositor: codeMantra

iv Certified Associate in Project Management (CAPM)® Exam Official Cert Guide

Pearson’s Commitment to Diversity, Equity, and

Inclusion
Pearson is dedicated to creating bias-free content that reflects the diversity of all
learners. We embrace the many dimensions of diversity, including but not limited to race,
ethnicity, gender, socioeconomic status, ability, age, sexual orientation, and religious or
political beliefs.

Education is a powerful force for equity and change in our world. It has the potential
to deliver opportunities that improve lives and enable economic mobility. As we work
with authors to create content for every product and service, we acknowledge our
responsibility to demonstrate inclusivity and incorporate diverse scholarship so that
everyone can achieve their potential through learning. As the world’s leading learning
company, we have a duty to help drive change and live up to our purpose to help more
people create a better life for themselves and to create a better world.

Our ambition is to purposefully contribute to a world where

■ Everyone has an equitable and lifelong opportunity to succeed through learning

■ Our educational products and services are inclusive and represent the rich diversity
of learners

■ Our educational content accurately reflects the histories and experiences of the
learners we serve

■ Our educational content prompts deeper discussions with learners and motivates
them to expand their own learning (and worldview)

While we work hard to present unbiased content, we want to hear from you about any
concerns or needs with this Pearson product so that we can investigate and address them.

Please contact us with concerns about any potential bias at

https://www.pearson.com/report-bias.html.
 v

Contents at a Glance
Introduction xxi

Part I Project Management Fundamentals

Chapter 1 Becoming a Certified Associate in Project Management (CAPM) ® 2

Chapter 2 Projects and Project Management 16

Chapter 3 Organizing for Project Performance 44

Chapter 4 Development Approach and Life Cycle Performance Domain 92

Part II Predictive Approach

Chapter 5 Planning, Project Work, and Delivery: Predictive Methodologies 120

Chapter 6 Project Work and Delivery 172

Part III Adaptive Approach

Chapter 7 Planning, Project Work, and Delivery: Adaptive Approaches 212

Chapter 8 Overview of Adaptive Frameworks 256

Chapter 9 Measurement, Tracking, and Managing Uncertainty 290

Part IV Business Analysis

Chapter 10 Business Analysis Frameworks 324

Chapter 11 Business Analysis Domains 350

Chapter 12 Tailoring and Final Preparation 414

Part V Appendixes
Appendix A Answers to the “Do I Know This Already?” Quizzes 430

Appendix B PMI Project Management Process Groups and Processes 436

Appendix C PMBOK 7 Project Performance Domains and Project Management

Principles 438
vi Certified Associate in Project Management (CAPM)® Exam Official Cert Guide

Appendix D PMI Certified Associate in Project Management (CAPM) ® Exam Official

Cert Guide Updates 442

Appendix E Business Analysis Models and Their Usages 444

Glossary 451

Index 468

Online Elements:

Appendix F Study Planner

Glossary
 vii

Contents
Introduction xxi

Part I Project Management Fundamentals

Chapter 1 Becoming a Certified Associate in Project Management (CAPM)® 2

Foundation Topics 3
Understanding Project Management 3
Certified Associate in Project Management (CAPM)® 3
Scope of the CAPM Exam 4
How This Book Is Organized 8
Part I: Project Management Fundamentals 9
Part II: Predictive Approach 9
Part III: Adaptive Approach 10
Part IV: Business Analysis 10
Part V: Appendixes 11
Steps to Becoming a Certified Associate in Project Management (CAPM)® 11
Study and Exam-Taking Strategies 13
Suggested Reading and Resources 13

Chapter 2 Projects and Project Management 16

“Do I Know This Already?” Quiz 17
Foundation Topics 20
What Is a Project? 20
A Project 21
Project Manager 22
Understanding Project Management 22
Projects vs. Operational Work 23
The Role of Projects in Operations 24
Project-Based Operations 24
Programs and Portfolios 25
Creating Value Through Project Management 26
Project Management Process Groups 35
Project Management Challenges 36
Challenges with Issues, Risks, Assumptions, and Constraints 37
Project Management Trends 41
Business Analysis 41
Adaptive Project Management 41
Principles of Project Management 42
viii Certified Associate in Project Management (CAPM)® Exam Official Cert Guide

Summary 42
Exam Preparation Tasks 42
Review All Key Topics 42
Define Key Terms 43
Suggested Reading and Resources 43

Chapter 3 Organizing for Project Performance 44

“Do I Know This Already?” Quiz 45
Foundation Topics 50
Project Performance Domains 50
The Stakeholder Performance Domain 52
Identifying Stakeholders 52
Types of Stakeholders in a Project 53
Stakeholder Analysis 54
Types of Stakeholder Communication 55
Stakeholder Performance Domain Successful Outcomes 56
The Project Manager’s Role 56
Roles of the Project Manager in a Project 58
The Project Manager’s Required Skills 58
Project Organization Structures 70
Project Structure Concepts 70
Functional Project Organization Structures 70
Matrix Project Organization Structures 72
Projectized Project Organization Structures 73
The Power of Project Managers in Different Organization Structures 73
Project Management Office (PMO) and Steering Committees 74
The Project Management Office 75
The Steering Committee 75
The Team Performance Domain 76
Effective Execution of Projects 78
High-Performing Teams 78
Leadership and Interpersonal Skills Affecting All Team Members 78
Project Team Development Models 79
Conducting Meetings 80
Responsibility Assignment Matrix 83
Project Team Culture 84
Expectations for the Team Performance Domain 86
Applying the PMI Code of Ethics and Professional Conduct 86
 Contents ix

Summary 88
Exam Preparation Tasks 88
Review All Key Topics 89
Define Key Terms 90
Suggested Reading and Resources 90

Chapter 4 Development Approach and Life Cycle Performance Domain 92

“Do I Know This Already?” Quiz 93
Foundation Topics 97
Fundamentals of the Project Life Cycle 97
The Concept of a Project Life Cycle 97
Visualizing a Project Life Cycle 98
Stage Gates 99
Project Life Cycle vs. Project Management Process Groups 100
Project Life Cycle vs. Product Life Cycle 103
Development Approach and Life Cycle Performance Domain Concepts 103
Terms Relevant to the Development Approach and Life Cycle Performance
Domain 104
Choosing the Predictive Approach 105
Choosing the Adaptive Approach 105
Choosing a Hybrid Approach 106
Life Cycles in Practice 107
Industry Application: Predictive Life Cycle 107
Industry Application: Adaptive Life Cycle 110
Industry Application: Hybrid Life Cycle 111
Considerations for Selecting a Development Approach 112
Product, Service, or Result 113
Project 114
Organization 114
Project Activity, Deliverables, and Milestones 115
Project Activities 115
Deliverables 115
Measuring Deliverables 116
Milestones 116
Summary 118
Exam Preparation Tasks 118
Review All Key Topics 119
Define Key Terms 119
Suggested Reading and Resources 119
x Certified Associate in Project Management (CAPM)® Exam Official Cert Guide

Part II Predictive Approach

Chapter 5 Planning, Project Work, and Delivery: Predictive Methodologies 120

“Do I Know This Already?” Quiz 122
Foundation Topics 127
Choosing the Predictive, Plan-Based Methodology 127
Process Groups of the Predictive, Plan-Based Approach 128
Initiating Processes 128
Planning Processes 129
Executing Processes 129
Monitoring and Controlling Processes 129
Closing Processes 129
Creating a Tailored Predictive Life Cycle 130
Performance Domains 130
Develop Project Charter 134
Develop Project Team 136
Develop Project Management Plan 137
Collect Requirements and Define Scope Statement 139
Create Work Breakdown Structure (WBS) 141
Define and Sequence Activities 144
Estimate Time and Resources 149
Identify Critical Path 151
Develop Schedule 156
Direct and Manage Project Work 157
Monitor and Control Project Work 159
Issues Management 159
Change Requests and Control 160
Monitoring and Controlling Project Cost and Schedule 162
Close Project or Phase 163
Foundations of Earned Value Analysis 165
Planned Value (PV) 166
Earned Value (EV) 166
Actual Cost (AC) 166
Cost Variance (CV) 166
Schedule Variance (SV) 166
Cost Performance Index (CPI) 166
Forecasting Final Project Costs 167
More Information About Earned Value Analysis 167
 Contents xi

The Planning Performance Domain 167

Schedule Compression Factors and Techniques 168
Scaling 169
Summary 169
Exam Preparation Tasks 170
Review All Key Topics 170
Define Key Terms 171
Suggested Reading and Resources 171

Chapter 6 Project Work and Delivery 172

“Do I Know This Already?” Quiz 173
Foundation Topics 177
Project Work Performance Domain 177
Planning and Managing Procurement 178
Bidding: Soliciting and Entering Bids 180
Control Procurements 181
Engaging Stakeholders 182
Managing Project Communications 184
Managing Risk 189
Threats 190
Opportunities 191
Project Delivery Performance Domain 192
Delivery of Value 193
Quality Management 194
Quality Management Tools 197
Six Sigma 203
Project Controls and Forecasting 203
Project Integration 207
Components of Project Integration 208
Achieving Project Integration 209
Summary 209
Exam Preparation Tasks 210
Review All Key Topics 210
Define Key Terms 211
Suggested Reading and Resources 211
xii Certified Associate in Project Management (CAPM)® Exam Official Cert Guide

Part III Adaptive Approach

Chapter 7 Planning, Project Work, and Delivery: Adaptive Approaches 212

“Do I Know This Already?” Quiz 213
Foundation Topics 217
When to Use an Adaptive Approach 217
Team Structure in Adaptive Projects 221
Requirements for the Adaptive Project Environment 222
Adaptive Mindset 222
Servant Leadership 224
The Structure and Culture of Adaptive Teams 225
Value-Driven Delivery 227
Factors That Facilitate Adaptive Approaches: OPA and EEF 228
Apparent Stages of Adaptive Projects 229
Stage 1: Concept 231
Stage 2: Construct and Deliver 233
Stage 3: Close 237
Work Groups for Adaptive Project Stages 238
Agile Life Cycles 238
Case Study 7-1: Building a Website for a Conference 239
Hybrid Project Approaches 251
Hybrid Approach Scenario 1: Revisiting the APC Conference 251
Hybrid Approach Scenario 2: Virtual Restaurant Business 252
Hybrid Approach Scenario 3: Specification for Tax Software 253
Summary 254
Exam Preparation Tasks 254
Review All Key Topics 254
Define Key Terms 255
Suggested Reading and Resources 255

Chapter 8 Overview of Adaptive Frameworks 256

“Do I Know This Already?” Quiz 259
Foundation Topics 262
Lean 262
Eliminating Waste 263
Value Streaming Using the Lean Approach 264
Case Study 8-1: Getting a Book from the Library 264
Iteration-Based Agile 267
Flow-Based Agile 267
 Contents xiii

Scrum 268
Roles 268
Processes and Artifacts 269
Scrum Core Values 270
Timeboxing 271
Challenges with Scrum 272
Kanban 272
Suitability of the Kanban Method 272
Limiting Work in Progress (WIP) 273
Workflow Focus 273
Comparing Kanban and Scrum 274
ScrumBan 274
Extreme Programming 275
Roles 275
Core Practices of XP 275
What Can We Learn from XP? 276
FDD, DSDM, and Crystal 277
Feature-Driven Development 277
Dynamic Systems Development Method 278
Crystal 279
Frameworks for Scale 279
Summary 283
Scrum of Scrums 284
Disciplined Agile® 284
Which Approach for Scale? 286
Summary 288
Exam Preparation Tasks 288
Review All Key Topics 288
Define Key Terms 289
Suggested Reading and Resources 289

Chapter 9 Measurement, Tracking, and Managing Uncertainty 290

“Do I Know This Already?” Quiz 291
Foundation Topics 294
Problem Detection and Resolution 294
The Measurement Performance Domain 295
Prioritization Techniques 295
What Gets Prioritized 298
xiv Certified Associate in Project Management (CAPM)® Exam Official Cert Guide

Key Performance Indicators (KPIs) for Project Control 300

Progress Tracking 301
Decision Making 301
Communication of Adaptive Project KPIs 301
Who Makes the Estimates? 306
Throughput, Cycle Time, and Lead Time 306
The Uncertainty Performance Domain 311
Uncertainty 312
Strategies to Address Project Uncertainty 313
Risk 315
Strategies to Reduce the Likelihood of Uncertainty 316
Opportunities 316
Threats 316
Tracking and Managing Risk in Adaptive Projects 317
Team Workspace Design 318
Tracking Progress to Manage Risk in Adaptive Approaches 318
Summary 321
Exam Preparation Tasks 321
Review All Key Topics 322
Define Key Terms 322
Suggested Reading and Resources 322

Part IV Business Analysis

Chapter 10 Business Analysis Frameworks 324

“Do I Know This Already?” Quiz 325
Foundation Topics 328
The Importance of Business Analysis 328
The Role of a Business Analyst 329
Skills Needed to Perform Business Analysis 330
Comparing Business Analysis with Project Management 331
Requirements: The Focus of Business Analysis 332
Requirement Types 332
Case Study 10-1: Requirements for a Toll Collection System 333
Requirements Documentation 337
Requirements Management Plan 337
Stakeholders and the Business Analyst 338
Identify Stakeholders 338
Stakeholder Analysis 341
 Contents xv

Business Analysis Planning 342

Transition to a Future State 343
Influence of Project Approaches on Business Analysis 343
Business Analysis in the Predictive Approach 343
Business Analysis in the Adaptive Approach 344
Summary 347
Exam Preparation Tasks 347
Review All Key Topics 347
Define Key Terms 348
Suggested Reading and Resources 348

Chapter 11 Business Analysis Domains 350

“Do I Know This Already?” Quiz 351
Foundation Topics 354
Domain 1: Needs Assessment 354
Why Perform Needs Assessments? 355
When Do Needs Assessments Occur? 355
Who Is Involved in Needs Assessment? 356
What Are the Key Business Analysis Tasks During Needs
Assessment? 356
What Are the Needs Assessment Processes? 357
Domain Summary 365
Domain 2: Business Analysis Planning 366
Domain 3: Requirements Elicitation and Analysis 368
Elicit Requirements 369
Analyze Requirements 377
Document the Solution Requirements 398
Domain 4: Traceability and Monitoring 398
Trace Requirements 399
Monitor Requirements 401
Update Requirements and Communicate Requirements Status 402
Manage Changes to Requirements 403
Domain Summary 404
Domain 5: Solution Evaluation 405
Evaluate Solution Performance 406
Determine Solution Evaluation Approach 407
Evaluate Acceptance Results and Address Defects 409
Obtain Solution Acceptance for Release 410
xvi Certified Associate in Project Management (CAPM)® Exam Official Cert Guide

Evaluate Deployed Solution 410

Domain Summary 410
Summary 411
Exam Preparation Tasks 411
Review All Key Topics 411
Define Key Terms 412
Suggested Reading and Resources 412

Chapter 12 Tailoring and Final Preparation 414

“Do I Know This Already?” Quiz: Tailoring Section 415
Foundation Topics 417
Tailoring 417
The Tailoring Process 418
Aspects of Projects That Can Be Tailored 419
How to Tailor the Project Approach 420
Case Study 12-1: Design and Introduction of Portable CT Scanner
Products 421
Summary: Project Tailoring Concepts 422
Final Preparation 422
Scope and Key Concepts 422
Suggested Plan for Final Review and Study 427
Summary 428
Exam Preparation Tasks 428
Review All Key Topics 428
Define Key Terms: Tailoring Section 429
Suggested Reading and Resources 429

Part V Appendixes
Appendix A Answers to the “Do I Know This Already?” Quizzes 430
Appendix B PMI Project Management Process Groups and Processes 436
Appendix C PMBOK 7 Project Performance Domains and Project
Management Principles 438
Appendix D PMI Certified Associate in Project Management (CAPM)®
Exam Official Cert Guide Updates 442
Appendix E Business Analysis Models and Their Usages 444
Glossary 451
Index 468

Online Elements:
Appendix F Study Planner
Glossary
 xvii

About the Authors

Vijay Kanabar, Ph.D., is the director and associate professor of Project Management
programs at Boston University, Metropolitan College. He is one of the earliest PMP-
credentialed practitioners from the Project Management Institute. He created one of the
earliest PMP exam corporate training materials three decades ago and has introduced sev-
eral thousand students and practitioners to the core exam concepts of both the CAPM®
and Project Management Professional (PMP)® exams. Vijay also is an agile practitioner
and has earned the PMI-ACP credential. He has authored several books and more than
75 research papers in IT and project management. He received the prestigious PMI Linn
Stuckenbruck Teaching Excellence Award in 2017 for his commitment to teaching and
enhancing the project management discipline in higher education.

Arthur P. Thomas, Ed.M., Ph.D., is the executive director for the Office of Professional
Acceleration and Microcredentials in the College of Professional Studies at Syracuse
University, where he is also the program director for the Master of Professional Studies
in Project Management. He has been teaching at SU since 2001 and has been a profes-
sor of practice since 2009, focusing his academic work on developing and administering
project management courses and degree programs. Art is also the director of the iConsult
Collaborative at Syracuse University, an experiential learning program he began leading
in 2012 in which university students are engaged with client organizations in a diverse
portfolio of information-related projects. Art was formerly the associate dean for Career
Services and Experiential Learning, the associate dean for Academic Affairs, and the
director of two information technology master’s degree programs, all at Syracuse Uni-
versity’s School of Information Studies (the iSchool). Positions on the corporate side of
his career have ranged from programmer to chief information officer, and from trainer to
chief learning officer. With his more than 30 years of added consulting experience, his
contracts have taken him from the United States to Europe and the Middle East, where he
led two projects for the Ministry of Education in the Sultanate of Oman.

Thomas G. Lechler, Ph.D., is an associate professor at the School of Business, Stevens

Institute of Technology in Hoboken, New Jersey. His doctorate is from the University of
Karlsruhe, Germany. He teaches project management and entrepreneurship. His research
focuses on value creation in projects under situations of risk and uncertainty. Thomas
has published his research in leading international research journals, including Research
Policy, R&D Management, IEEE Transactions on Engineering Management, Small
Business Economics, International Journal of Project Management, and Project
Management Journal, and he has authored several books in the fields of project manage-
ment and entrepreneurship. He was awarded the Project Management Journal Paper of
the Year, has received several research grants from PMI, and was a NASA research fellow.
xviii Certified Associate in Project Management (CAPM)® Exam Official Cert Guide

Dedications
I want to dedicate this book to practitioners pursuing additional credentials, such as the
CAPM®. It made a difference for me academically and professionally, and I am confident
that it will accomplish the same for them. I would also like to dedicate this book to my
wife, Dina; my father, Kalyandas; and my father-in-law, Prabhudas, who passed away
recently but certainly cheered this project in spirit to its full successful completion.

—Vijay Kanabar

This book is dedicated to the people who have most influenced my work in project
management over the years: my elite students, who helped me to shape my teaching and
then went on to become project professionals in their own right; my faculty colleagues,
who first influenced me to pursue this topic as a personal specialty; and my wife, Helen,
who has instilled in me the personal confidence to make it all happen.

—Art Thomas

This book is dedicated to all my current and future students who are pursuing a career
in managing projects. I hope it will make a difference to them and help them to better
understand and address the many challenges in leading teams and managing projects. I
would also like to dedicate this book to my wife, Ulrike, and my mother, who passed
away just before the book was completed.

—Thomas Lechler
 xix

Acknowledgments
This book was made possible by Executive Editor Laura Norman, who spent substan-
tial time sprinting with us weekly to keep the project on schedule, and who relentlessly
removed all administrative obstacles that occurred. Our high praise also goes out to the
editing team, Ellie Bru, Tonya Simpson, and Kitty Wilson, who were persistent, patient,
and professional every step of the way.

Roger Warburton provided perspectives from his vast experience in project management,
and we are truly grateful for his many suggestions and contributions.

The editing team at PMI was an excellent bridge between the official PMI standards and
the visions we had for this book as authors. We appreciate not only their consistent nudges,
but also their assistance in finding the best ways for our visions to become reality.

About the Technical Reviewer

Roger Warburton taught Project Management (PM) at Boston University’s Metropolitan
College for more than a decade. He has taught both undergraduate and graduate students
in the classroom as well as online. He designed and taught the primary graduate PM
course, which was required for all master’s degree students. MET College students were
midcareer professionals pursuing career advancement or seeking a change to a project
management career. Roger’s course was one of MET College’s highest rated by students.
The online version won an award for its innovative content. Roger also designed and
taught both classroom and online versions of the graduate Project Management Costs
and Risks course.

We Want to Hear from You!

As the reader of this book, you are our most important critic and commentator. We value
your opinion and want to know what we’re doing right, what we could do better, what
areas you’d like to see us publish in, and any other words of wisdom you’re willing to pass
our way.

We welcome your comments. You can email or write to let us know what you did or
didn’t like about this book—as well as what we can do to make our books better.

Please note that we cannot help you with technical problems related to the topic of
this book.

When you write, please be sure to include this book’s title and author as well as your
name and email address. We will carefully review your comments and share them with the
author and editors who worked on the book.

Email: [email protected]
xx Certified Associate in Project Management (CAPM)® Exam Official Cert Guide

Reader Services
Register your copy of Certified Associate in Project Management (CAPM)® Exam
Official Cert Guide at www.pearsonitcertification.com for convenient access to down-
loads, updates, and corrections as they become available. To start the registration process,
go to www.pearsonitcertification.com/register and log in or create an account.* Enter the
product ISBN 9780137918096 and click Submit. When the process is complete, you will
find any available bonus content under Registered Products.

*Be sure to check the box that you would like to hear from us to receive exclusive
discounts on future editions of this product.
 xxi

Introduction
Thank you for choosing this book. The Certified Associate in Project Management
(CAPM)® is a professional certification offered by the Project Management Institute
(PMI)®. The CAPM exam addresses the needs of professionals who want to understand
the fundamental knowledge, terminology, and practice of effective project management.
A CAPM® candidate must be familiar with concepts involving three areas of expertise:

■ Traditional project management fundamentals, including the roles of project team

members in planning, organizing, and executing projects

■ Project life cycles and approaches to delivering project value using adaptive,
predictive, and hybrid approaches

■ The role of business analysis in project management, especially as it pertains to

requirements definition and implementation

The CAPM® credential and this guide specifically address the needs of project
management students and practitioners with up to 3 years of project work experience.
Note that project work experience covers a range of backgrounds, from work as a project
leader or team member on a traditional project to work experience in change management
and operations management.

Students at colleges and universities are increasingly taking courses in project man-
agement. You may be pursuing a credential to differentiate yourself as you enter the
workforce. The CAPM® curriculum is a good choice for you because it provides a well-
rounded body of knowledge in project management. Mastering the content introduced
in this guide will enable you to answer critical job interview questions, such as, “We need
to implement a new project. Which project management approach method do you think
is appropriate for the project? Agile? Waterfall? Why?” or “We need a team member to
show leadership on this project. How would you lead? What competencies do you bring
to the table?” After reading this book, you will be comfortable responding to such ques-
tions. You will be able to contrast the predictive approach with the adaptive approach.
You also will be able to explain the importance of identifying and engaging stakeholders,
motivating team members, and communicating effectively with the project team, and you
will be able to describe the various tools and approaches for doing so.

Additionally, this book is a reference resource for foundational project management,

including agile practice and business analysis. You can apply the knowledge gained here
to on-the-job experiences and build your competence. For professionals keen to explore
the discipline of project management and earn advanced credentials, this certification
guide is a gateway to a complete range of certifications from PMI. Following the
CAPM® certification and obtaining 3 years of professional experience, PMI offers three
additional and relevant professional levels of certification:

■ The Project Management Professional (PMP)® certification is a widely recognized

and respected credential in project management. The PMP ® certification is a natural
follow-on to the CAPM® and is designed to recognize the knowledge and skills of
project management professionals. It addresses traditional and adaptive approaches
xxii Certified Associate in Project Management (CAPM)® Exam Official Cert Guide

to developing projects. To be eligible for the PMP certification, individuals must

have completed a certain amount of education and training in project management,
as well as have a certain amount of experience leading and directing projects.

■ The PMI-ACP ® is the Project Management Institute Agile Certified Practitioner

certification. This certification is designed to recognize the knowledge and skills of
professionals who use agile practices in their projects.

■ PMI-PBA® is the Project Management Institute Business Analysis certification,

which is designed to recognize the knowledge and skills of business analysis profes-
sionals, including identifying business needs and determining solutions to business
problems.

These certifications will each validate your advanced standing in the field of project
management. In addition, they provide an opportunity to dive deeply into specialty areas
such as the agile approach and business analysis.

Book Features
To help you customize your study time using this book, the core chapters have several
features that help you make the best use of your time:

■ Foundation Topics: These are the core sections of each chapter. They explain the
concepts for the topics in that chapter.

■ Exam Preparation Tasks: This section lists a series of study activities that you
should do at the end of the chapter:

■ Review All Key Topics: The Key Topic icon appears next to the most important
items in the “Foundation Topics” section of the chapter. The Review All Key
Topics activity lists the key topics from the chapter, along with their page
numbers. Although the contents of the entire chapter could be on the exam,
you should definitely know the information listed in each key topic.

■ Define Key Terms: This section lists the most important terms from the chapter,
asking you to write a short definition and compare your answer to the glossary at
the end of the book.

■ Web-based practice exam: The companion website includes the Pearson Cert
Practice Test engine, which allows you to take practice exam questions. Use it to
prepare with a sample exam and to pinpoint topics where you need more study.

The Companion Website for Online Content Review

All the electronic review elements, as well as other electronic components of the book,
exist on this book’s companion website.

To access the companion website, which gives you access to the electronic content with
this book, start by establishing a login at www.pearsonITcertificiation.com and register
your book.
 Introduction xxiii

To do so, simply go to www.pearsonITcertificiation.com/register and enter the ISBN

of the print book: 9780137918096. After you have registered your book, go to your
account page and click the Registered Products tab. From there, click the Access Bonus
Content link to get access to the book’s companion website.

Note that if you buy the Premium Edition eBook and Practice Test version of this book
from Pearson, your book will automatically be registered on your account page. Simply
go to your account page, click the Registered Products tab, and select Access Bonus
Content to access the book’s companion website.

Please note that many of our companion content files can be very large, especially image
and video files.

If you are unable to locate the files for this title by following the steps, please visit
www.pearsonITcertification.com/contact and select the nature of your query from the
drop-down box. Our customer service representatives will assist you.

How to Access the Pearson Test Prep (PTP) App

You have two options for installing and using the Pearson Test Prep application: a web
app and a desktop app. To use the Pearson Test Prep application, start by finding the
access code that comes with the book. You can find the code in these ways:

■ Print book: Look in the cardboard sleeve in the back of the book for a piece of
paper with your book’s unique access code.

■ Premium edition: If you purchase the Premium Edition eBook and Practice Test
directly from the Pearson IT Certification website, the code will be populated on
your account page after purchase. Just log in at www.pearsonITcertification.com,
click Account to see the details of your account, and click the Digital Purchases tab.

■ Amazon Kindle: For those who purchase a Kindle edition from Amazon, the access
code will be supplied directly by Amazon.

■ Other bookseller eBooks: Note that if you purchase an eBook version from any
other source, the practice test is not included because other vendors to date have not
chosen to vend the required unique access code.

NOTE Do not lose the access code; it is the only means with which you can access the
QA content with the book.

Once you have the access code, to find instructions about both the PTP web app and the
desktop app, follow these steps:

Step 1. Open this book’s companion website, as described earlier in this Introduction,
in the section “The Companion Website for Online Content Review.”
Step 2. Click the Practice Exams button.
xxiv Certified Associate in Project Management (CAPM)® Exam Official Cert Guide

Step 3. Follow the instructions listed there both for installing the desktop app and for
using the web app.

If you want to use the web app only at this point, navigate to www.pearsontestprep.com,
establish a free login if you do not already have one, and register this book’s practice tests
using the access code you just found. The process should take only a couple minutes.

NOTE Amazon eBook (Kindle) customers: It is easy to miss Amazon’s email that lists
your PTP access code. Soon after you purchase the Kindle eBook, Amazon should send an
email. However, the email uses very generic text and makes no specific mention of PTP or
practice exams. To find your code, read every email from Amazon after you purchase the
book. Also do the usual checks for ensuring that your email arrives, such as checking your
spam folder.

NOTE Other eBook customers: As of the time of publication, only the publisher and
Amazon supply PTP access codes when you purchase their eBook editions of this book.

Customizing Your Exams

From the exam settings screen, you can choose to take exams in one of three modes:

■ Study mode: This mode allows you to fully customize your exams and review
answers as you are taking the exam. This is typically the mode you use first to assess
your knowledge and identify information gaps.

■ Practice Exam mode: This mode locks certain customization options to present a
realistic exam experience. Use this mode when you are preparing to test your exam
readiness.

■ Flash Card mode: This mode strips out the answers and presents you with only the
question stem. This mode is great for late-stage preparation, when you really want to
challenge yourself to provide answers without the benefit of seeing multiple-choice
options. This mode does not provide the detailed score reports that the other two
modes do, so you should not use it if you are trying to identify knowledge gaps.

In addition to these three modes, you can select the source of your questions. You can
choose to take exams that cover all the chapters, or you can narrow your selection to just
a single chapter or the chapters that make up specific parts in the book. All chapters are
selected by default. If you want to narrow your focus to individual chapters, simply dese-
lect all the chapters and then select only those you want to focus on in the Objectives
area.
 Introduction xxv

You can also select the exam banks to focus on. Each exam bank comes complete with
a full exam of questions that cover topics in every chapter. You can have the test engine
serve up exams from all banks or just from one individual bank by selecting the desired
banks in the exam bank area.

You can make several other customizations to your exam from the exam settings screen,
such as the time allowed for taking the exam, the number of questions served up,
whether to randomize questions and answers, whether to show the number of correct
answers for multiple-answer questions, and whether to serve up only specific types of
questions. You can also create custom test banks by selecting only questions that you
have marked or questions on which you have added notes.

Updating Your Exams

If you are using the online version of the Pearson Test Prep software, you should always
have access to the latest version of the software and the exam data. If you are using the
Windows desktop version, every time you launch the software while connected to the
Internet, it checks for any updates to your exam data and automatically downloads any
changes made since the last time you used the software.

Sometimes, for many factors, the exam data may not fully download when you activate
your exam. If you find that figures or exhibits are missing, you may need to manually
update your exams. To update a particular exam that you have already activated and
downloaded, simply click the Tools tab and click the Update Products button. Again,
this is an issue only with the desktop Windows application.

If you want to check for updates to the Pearson Test Prep exam engine software,
Windows desktop version, simply click the Tools tab and click the Update Application
button. This ensures that you are running the latest version of the software engine.
xxvi Certified Associate in Project Management (CAPM)® Exam Official Cert Guide

Figure Credits
Figure 2-1 Ganzaless/Shutterstock

Figure 2-9 Rawpixel.com/Shutterstock

Figure 4-14 Jos Reyes/123RF

Figure 5-2 CPbackpacker/Shutterstock

Figure 5-4 Wittayayut/Shutterstock

Figure 5-13 Tamara Kulikova/Shutterstock

Figure 5-15 wanchai waewsra/Shutterstock

Figure 6-3 GrAl/Shutterstock

Figure 6-13 Andriy Solovyov/Shutterstock

Figure 7-6 JKstock/Shutterstock

Figure 7-16 elen1/123RF

Figure 7-17 arek_malang/Shutterstock

Figure 7-18 ryanking999/123RF

Figure 7-23 ferli/123RF

Figure 7-26 Dragon Images/Shutterstock

Figure 7-27 wrangler/Shutterstock

Figure 8-12 Vladimir Cosic/123RF

Figure 9-9 Zoltan Major/Shutterstock

Figure 10-3 iscatel/123RF

Figure 11-8 insta_photos/Shutterstock

CHAPTER 4

Development Approach and Life

Cycle Performance Domain

This chapter covers the following topics:

■ Fundamentals of the Project Life Cycle: This section covers basic life cycle concepts
and provides an introduction to how life cycles work.

■ Project Life Cycle vs. Product Life Cycle: This section describes how products are
managed and how the various components of a product’s market life cycle can be simi-
lar to those of the project life cycle.

■ Development Approach and Life Cycle Performance Domain: This section covers
the typical activities associated with the Development Approach and Life Cycle
Performance Domain.

■ Life Cycles in Practice: This section provides examples of how practitioners think of
life cycles in various contexts.

■ Considerations for Selecting a Development Approach: This section describes key

factors that help in making a decision about what development approach to use.

■ Project Activity, Deliverables, and Milestones: This section describes some of the
activities involved in various types of life cycles, defines what deliverables and mile-
stones are, and explains why it is important to define what deliverables are in projects.

This chapter introduces the fundamental concepts involved in the Development Approach
and Life Cycle Performance Domain. This domain involves the choices a project manager
makes in terms of the order in which certain required tasks are done, to what extent the
team can take different paths through those required steps, and how these factors influence
the life cycle of the project. Several types of life cycles are described, including the typical
considerations for choosing which type of life cycle is best for a given situation and project
context. Finally, this chapter covers the important concepts related to deliverables and mile-
stones to ensure that you know how to define them and use them in the planning and execu-
tion of a project.

CAUTION The project management information, templates, tools, and techniques in this
chapter are provided for your education only. Use this knowledge prudently when applying
it to projects at work. Also, while we have aligned the material with the Project Management
Institute’s (PMI’s) Exam Content Outline, there is no assurance that successfully complet-
ing this book will result in students passing the Certified Associate in Project Management
(CAPM)® exam.
 By the time you reach the end of this chapter, within the context of the following domains
and tasks, you should be able to:

■ Domain 1: Project Management Fundamentals and Core Concepts

■ Task 1-1: Demonstrate an understanding of the various project life cycles and
process groups.

Distinguish between predictive and adaptive approaches.

■ Task 1-2: Demonstrate an understanding of project management planning.

Distinguish between the different deliverables of a project plan vs. a product plan.

Distinguish the difference between a milestone and a task duration.

■ Task 1-4: Determine how to follow and execute planned strategies or frame-
works (e.g., communication, risks, etc.).

Give examples of how it is appropriate to respond to a planned strategy or frame-

work (e.g., communication, risk).

■ Domain 2: Predictive Plan-Based Methodologies

■ Task 2-1. Explain when it is appropriate to use a predictive plan-based approach.

Identify the suitability of a predictive, plan-based approach for a particular organi-

zational structure (e.g., virtual, co-location, matrix structure, hierarchical).

Determine the activities within each process.

Give examples of typical activities within each process.

Distinguish among various project components.

■ Domain 3: Adaptive Frameworks/Methodologies

■ Task 3-1: Explain when it is appropriate to use an adaptive approach.

Compare the pros and cons of adaptive and predictive plan-based projects.

Identify organizational process assets and environmental factors that facilitate adap-
tive approaches.

“Do I Know This Already?” Quiz

The “Do I Know This Already?” quiz allows you to assess whether you should read this
entire chapter thoroughly or jump to the “Exam Preparation Tasks” section. If you are in
doubt about your answers to these questions or your own assessment of your knowledge
of the topics, read the entire chapter. Table 4-1 lists the major headings in this chapter and
their corresponding “Do I Know This Already?” quiz questions. You can find the answers in
Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes.”
94 Certified Associate in Project Management (CAPM)® Exam Official Cert Guide

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

Foundation Topics Section Questions
Fundamentals of the Project Life Cycle 2, 13
Project Life Cycle vs. Product Life Cycle 5
Development Approach and Life Cycle Performance Domain Concepts 3, 8, 10
Life Cycles in Practice 1, 7, 12
Considerations for Selecting a Development Approach 9, 11, 14
Project Activity, Deliverables, and Milestones 4, 6, 15

CAUTION The goal of self-assessment is to gauge your mastery of the topics in this
chapter. If you do not know the answer to a question or are only partially sure of the answer,
you should mark that question as wrong for purposes of the self-assessment. Giving yourself
credit for an answer you correctly guess skews your self-assessment results and might
provide you with a false sense of security.

1. If the requirements for software change in a minor way due to customer feedback
or testing failure, the project team can revisit these minor changes through revised
design, coding, and testing. The idea is to discover these issues as early as possible
because the cost of changing the system can be greater as more of it is developed
through the life cycle of the project. When you have this viewpoint, you are viewing
software development as a(n) _____.
a. predictive approach
b. product approach
c. adaptive approach
d. hybrid approach
2. Which of the following is the term for a temporary endeavor to develop a unique out-
come through a series of interrelated steps from initial concept to a completed state?
a. Phase
b. Product life cycle
c. Activity
d. Project life cycle
3. Your operations manager has tasked you with defining a development approach for the
construction of a tool shed next to your manufacturing facility. The scope, schedule,
cost, resource needs, and risks can be well defined in the early phases of the project
life cycle, and they are relatively stable. Which approach should you take in this case?
a. Predictive
b. Product
c. Adaptive
d. Hybrid
 Chapter 4: Development Approach and Life Cycle Performance Domain 95

4. Which of the following is the term for a scheduled step in a project plan that has a dis-
tinct beginning and end and may consist of several substeps?
a. Phase
b. Deliverable
c. Activity
d. Milestone
5. ABC Company has determined that its Widget 452 model is selling less briskly than it
has during the past two years. Executives of the company determine that it is time to
phase out Widget 452 and bring Widget 673 into production and sales. These factors
would lead you to believe that the executives are discussing a(n) _____.
a. phase
b. product life cycle
c. activity 4
d. project life cycle
6. Which of the following is a tangible or intangible measurable output of one or more
project activities?
a. Milestone
b. Deliverable
c. Phase
d. Objective
7. You are managing a software development project and have planned that the final
deliverable will be brought into existence in successively refined stages at prototype,
pilot, testing, and deployment stages. In this case, you are viewing software develop-
ment as a(n) _____.
a. predictive approach
b. adaptive approach
c. hybrid approach
d. product approach
8. The product owner for a clothing manufacturer/retailer has tasked you with defining a
development approach for a new line of children’s clothing. This organization has never
sold clothing for children, and no one on the team has had any experience with this
type of product. One very rigid consideration is that this particular company wants a
line of children’s clothing that is unique in the market, so you cannot just import a line
from another company and rebrand it. Which development approach should you use in
this case?
a. Predictive
b. Product
c. Adaptive
d. Hybrid
96 Certified Associate in Project Management (CAPM)® Exam Official Cert Guide

9. Scheduling constraints, the availability of funding, and the nature of the involved
stakeholders are all factors that are part of which aspect of the model of consider-
ations for selecting a development approach?
a. Product, service, or result
b. Project
c. Organization
d. Competition
10. You are the project manager for information systems in a major banking firm. This par-
ticular company has not had its own mobile application. The senior vice president for
operations has asked you, along with others in the IT and operations groups, to define
a project that will produce an initial mobile application. The vice president has been
particularly emphatic about the fact that this application must meet all compliance
requirements for consumer use; other than that, your teams have freedom in the design
and operation of the app. These factors suggest that you probably want to use which
development approach?
a. Predictive
b. Product
c. Adaptive
d. Hybrid
11. The project team size and location, the overall culture, and capability are all factors
that are part of which aspect of the model of considerations for selecting a develop-
ment approach?
a. Product, service, or result
b. Project
c. Organization
d. Competition
12. Certain aspects of your retail store project allow you to plan for a known outcome of
the construction of your retail store location. Other aspects of the market develop-
ment and product testing are less stable at the early stages because you want to estab-
lish a more unique approach to your store. To bring about the final operating store in
your chosen location, which approach might you want to adopt?
a. Predictive
b. Adaptive
c. Hybrid
d. Product
13. A(n) _____ is a collection of logically related project activities that culminates in the
completion of one or more deliverables.
a. phase
b. product life cycle
c. activity
d. project life cycle
 Chapter 4: Development Approach and Life Cycle Performance Domain 97

14. Degree of innovation, ease of change, requirements, and regulations are all factors that
are part of which aspect of the model of considerations for selecting a development
approach?
a. Product, service, or result
b. Project
c. Organization
d. Competition
15. Although a(n) ______ is scheduled in a project plan, it has no estimated duration and is
used to provide information about progress through the major segments.
a. milestone
b. deliverable
c. phase
d. activity 4

Foundation Topics
Fundamentals of the Project Life Cycle
Life cycle is a term we use to describe the overall time of existence of something. We know
that stars such as our sun have a certain predictable life cycle, from the time they form to
the last point of their existence. Trees have a life cycle, from a seed, to a towering adult, to
a fallen trunk on the ground in the forest. In fact, if you look around in a forest, you can
usually see trees in many phases of their life cycle. The fact that these phases are similar for
different kinds of trees suggests that the phases within a life cycle are true on a very broad,
or high-level, basis for everything we might classify as a tree. Therefore, if we can recognize
where a tree is in its life cycle, we can predict what will likely come next.
In fact, it was a typical forest that inspired early astronomers to realize that all the objects
they were seeing through their telescopes out there in the universe were not different objects
at all; instead, they began to realize that many of them were similar objects at varying phases
of existence along their individual life cycles.

The Concept of a Project Life Cycle

Like stars and trees, all projects have noticeable high-level phases as they evolve from initial
ideas to completion. People think of projects also evolving in a somewhat sequential fashion,
although we know it is common for changes in project requirements or other issues to result
in a need to repeat previous sequential steps to include revisions. In general, when we think
of this high-level progression from an initial state to a completed state, we can refer to it as
a project life cycle. We can see many types of projects go through this sort of progression,
even though the end goals, deliverables, or even application domains of the project (such as
construction, software, or event management) might be very different from one another.
98 Certified Associate in Project Management (CAPM)® Exam Official Cert Guide

People use various terms when discussing the overall life cycle of a project, including stage,
step, and phase. The various points in the life cycles of projects are described using terms
such as prototype and final rollout. In Section 2.3 of the PMBOK® Guide – Seventh
Edition, PMI has formalized two terms that are important foundational concepts for this
chapter:

■ Project phase: A collection of logically related project activities that culminates in

the completion of one or more deliverables.

■ Project life cycle: The series of phases that a project passes through, from its start to
its completion.

You can think of a project phase as a “chunk” of the project—a lower-level concept that
involves logically related activities and the completion of specific deliverables or types of
deliverables. These chunks make up the general project life cycle, which is an overall arc of
existence for a project as it takes various shapes while evolving from start to finish.

Visualizing a Project Life Cycle

Figure 4-1 shows a project life cycle going through six phases:

1. Aspire
(Project Ideas Align
with Strategy)

5. Execute
$ ROI
Project Plan
2. Business Case 3. Create Charter

6. Finish Project

4. Develop Project Plan

Monitor and Control

Figure 4-1 A Typical Project Life Cycle

1. Aspire: This is the project aspiration and ideation phase, the origin for projects. Here
a project portfolio is created to address problems or opportunities in an organization.
In this pre-project phase, you need to ensure that any proposed project idea is aligned
with the organization’s mission.
2. Business case analysis: The proposed project idea needs to be justified based on
evidence and details; this is where the business case comes into play. The objective of
the business case is to assess the project benefit and value that the proposed project
brings to stakeholders. This life cycle phase involves documenting, among other things,
a profit-and-loss investment analysis.
 Chapter 4: Development Approach and Life Cycle Performance Domain 99

3. Create charter: The project sponsor formally authorizes the existence of a project
after considering the business case and organizational needs. The project charter is
an official document that identifies the project manager and grants authority to apply
organizational resources to project activities.
4. Develop the project management plan: This phase looks at the activities that need to
be completed to deliver the project successfully. It considers both project- and prod-
uct-related activities. From a project manager’s perspective, this is a very important
phase, and much effort is expended to plan and organize the project in detail.
5. Execute the project management plan: In this phase, the project management plan
is executed. The project team must be motivated and led successfully to produce the
project deliverables. There is also a monitoring and controlling aspect to the execu-
tion phase; milestones must be attained within the targeted project schedule, cost, and
quality constraints.
4
6. Finish: Here the project is completed and closed. The project manager handles admin-
istrative closure and lessons learned, and communicates project results.
The aspire and business case phases are often considered to be pre-project phases. Most
project management practice and foundational project management standards focus on the
remaining phases—from developing the charter to closing the project.
One of the reasons for this focus on the last four phases is that different vendors and organizations
have unique proprietary activities for the pre-project phases: aspire and business case analysis.
For example, a life cycle could have just the phases of analysis, design, development, accep-
tance, and implementation. These five phases outline a methodical, step-by-step process for
managing any project. With this approach, phases before analysis are considered pre-project
activities; any phases after implementation are considered post-implementation phases. Post-
implementation work might include such activities as project benefits tracking, in which the
original concepts of the business case are measured and validated as being either achieved
or not. The separations of pre- and post-implementation phases in these organizations can
sometimes be due to the fact that other teams besides the “performing organization” (that is,
the project team) are given charge of these front- and back-end phases. In contrast, the proj-
ect team concentrates only on the five phases of work in between.

Stage Gates
Progressive elaboration takes place as a project progresses from one phase to another.
The increasing amount of detail available as a project moves along provides opportunities to
review whether there is any value in continuing to invest in the project. As illustrated in
Figure 4-2, a stage gate is a point for deciding whether a project should be continued or
terminated. Stopping a project early on can result in substantial cost savings. Steering com-
mittee members review the project progress, value, and business environment and decide
whether to continue, suspend, or cancel the project completely. In other words, a stage gate
is a gate that blocks further progress down the path of the project until some authority
allows it to be opened after an appropriate review of the progress to this point. Stage gates
are also known as phase review points or kill points.
100 Certified Associate in Project Management (CAPM)® Exam Official Cert Guide

Aspire
Project
Ideation Phase

Stage Gate
Business Case

Stage Gate
Create Charter

Stage Gate
Develop Plan

Figure 4-2 Life Cycle Phases with Stage Gate Checkpoints

Project Life Cycle vs. Project Management Process Groups

How do the Project Management Process Groups, a hallmark of previous editions of the
PMBOK® Guide, relate to a project life cycle? This is a common question and concern even
among experienced practitioners. The PMIstandards+™ online guide defines 49 processes
that are associated with project management process groups. While references to the Process
Groups can be found in the current edition, details of project processes can be found now
in Process Groups: A Practice Guide. We have also reproduced them in summary form for
your reference in Appendix B, “PMBOK® Guide Process Groups and Processes.”
The five Project Management Process Groups—Initiating, Planning, Executing, Monitor-
ing and Controlling, and Closing—are illustrated in Figure 4-3. There is some symmetry
between a project life cycle and the Project Management Process Groups. The Initiating
Process Group consists of processes such as Identify Stakeholders, Develop Project Char-
ter; the Planning Process Group consists of processes such as Collect Requirements, Define
Scope, and Create a Work Breakdown Structure (WBS). Similar processes are associated
with Executing, Monitoring and Controlling, and Closing. We provide details of these pro-
cesses in Chapter 5, “Planning, Project Work, and Delivery: Predictive Methodologies.”
 Chapter 4: Development Approach and Life Cycle Performance Domain 101

1. Aspire & Align

(Project Ideas Align
with Strategy)

EXECUTING
PROCESS GROUP

5. Execute
$ ROI Project Plan
INITIATING PROCESS GROUP
2. Business Case 3. Create Charter
6. Finish Project

CLOSING PROCESS GROUP

PLANNING PROCESS GROUP

4. Develop Project Plan

4

MONITORING AND CONTROLLING PROCESS GROUP

Figure 4-3 Life Cycle Phases vs. PMBOK® Process Groups

Whereas a life cycle is more like a linear flow, the Project Management Process Groups
can iterate at each life cycle phase. For example, consider a project that involves creating
a charter document for the Olympics, as illustrated in Figure 4-4. The Olympics is such a
massive event that creating a charter and getting all stakeholders onboard is a significant
undertaking. This single complex project would involve all five process groups.

Create Charter
for Olympics
INITIATING PROCESS

PLANNING PROCESS

EXECUTING PROCESS Olympics

Charter

MONITORING AND CONTROLLING PROCESS CLOSING PROCESS

Figure 4-4 PMBOK Process Groups Can Apply at Each Phase of the Life Cycle

Figure 4-5 illustrates how the Project Management Process Groups iterate in large projects
in each phase. Notice that it is possible to implement some or all of the processes associated
with the project during each iteration.
 102

Phase 1

INITIATING
PROCESSES
PLANNING
PROCESSES
EXECUTING
PROCESSES
Deliverable 1
CLOSING
MONITORING AND CONTROLLING PROCESSES
PROCESSES

Phase 2 INITIATING
PROCESSES
PLANNING
PROCESSES
EXECUTING
PROCESSES Deliverable 2
CLOSING
MONITORING AND PROCESSES
CONTROLLING PROCESSES INITIATING
Phase 3 PROCESSES
PLANNING
PROCESSES

EXECUTING
PROCESSES Deliverable 3
CLOSING
Certified Associate in Project Management (CAPM)® Exam Official Cert Guide

MONITORING AND CONTROLLING PROCESSES

PROCESSES

Figure 4-5 Repeating Project Process Groups in a Project

 Chapter 4: Development Approach and Life Cycle Performance Domain 103

Project Life Cycle vs. Product Life Cycle

The Standard for Project Management defines a product as an artifact that is produced,
is quantifiable, and is either an end item or a component item. A product life cycle begins
when a product is conceived and development is started. It is then introduced to the market.
This is followed by a growth in sales, a sales peak, and often a gradual decline, after which
the product is typically withdrawn from the market. At this point, a new version or a new
product concept takes its place in another product cycle. Figure 4-6 illustrates a typical
product life cycle. After development, a product typically goes through the introduction,
growth, maturity, and decline phases.
Project Usage, Sales, Impact

Project 3
(Additions) Project 4
(Revisions)

Project 5
4
(Revisions)
Project 2
(More Features) Project 6
(Revisions)
Project 1
(Initial Creation) Project 7
(Retirement)

Time
Product
Life Cycle Introduction Growth Maturity Decline/Retirement
Phases
Figure 4-6 Product Management Life Cycle

Profits follow a different curve. There is an early investment when the product is in develop-
ment, so profits do not accrue instantly with the first sales; they are offset in time until the
product has been in the marketplace long enough to have paid back the investments of devel-
opment and for sales to have scaled up sufficiently for the product to become profitable. If
the product is successful, there is a reasonable period of profitability during the product’s
maturity stage. Inevitably, product yields decline in sales or interest and are superseded by
newer or better product versions, or they are withdrawn from the marketplace.
Consider the case of a smartphone. After Release 1, a newer product version emerges as
Release 2. If you consider each release as a project, you have multiple projects, as illustrated
in Figure 4-6.

NOTE When a product or service is introduced to the market, it is no longer a project.

Product management is a complex discipline, but this chapter’s introduction to product
management should give you sufficient knowledge to pass the CAPM® exam.

Development Approach and Life Cycle

Performance Domain Concepts
Different approaches can be used for deployment, depending on the project goals and
desired outcomes, as well as the risk or uncertainty associated with a project’s environment.
104 Certified Associate in Project Management (CAPM)® Exam Official Cert Guide

The PMBOK® Guide – Seventh Edition considers this an important topic and has articu-
lated this as a performance domain in Section 2.3, Figure 2-6. Figure 4-7 shows the key out-
comes that should result from the successful execution of this domain.

Figure 4-7 Development Approach and Life Cycle Performance Domain

(Source: Figure 2-6, PMBOK® Guide – Seventh Edition)

Terms Relevant to the Development Approach and

Life Cycle Performance Domain
In addition to the terms project phase and project life cycle, this performance domain
focuses on some other key terms:

■ Deliverable: Any unique and verifiable product, result, or capability to perform a ser-
vice that is required to be produced to complete a process, phase, or project.

■ Development approach: A method used to create and evolve a product, service, or

result during the project life cycle, such as a predictive, adaptive, or hybrid method.
The development approach can demonstrate specific characteristics, such as being
iterative or incremental.

Development approaches can be broadly seen as two extremes in terms of goals and imple-
mentation. Figure 4-8 shows the predictive and adaptive extremes, as well as a blended devel-
opment approach that uses some of both, known as a hybrid approach.

Predictive Hybrid Adaptive

Figure 4-8 Types of Development Approaches

The hybrid development approach combines two or more predictive and adaptive elements.
For example, within a generally linear step-by-step project flow, you could have one of the
steps refer to the development of a mobile app. This particular step might be adaptive until
its completion, to account for the need to carefully iterate user input until a final, finished
 Chapter 4: Development Approach and Life Cycle Performance Domain 105

app has been delivered. After its completion, the remaining linear steps of the predictive
approach take over until the completion of the project. Therefore, the hybrid development
approach is seen as applying the best of both extremes in a combination that is most appro-
priate for the specific project outcomes that are needed.
Terms used to describe these approaches have varied over the years. Table 4-2 shows some
different expressions related to predictive and adaptive approaches that are available in the
literature and used in practice.

Table 4-2 Terms in Use Referring to the Predictive and Adaptive Approaches
Approach Alternative Terms
Predictive Waterfall, linear, structured, plan based, stable, traditional
Adaptive Agile, iterative, incremental, spiral, extreme, evolutionary

4
Choosing the Predictive Approach
A predictive development approach can be considered when the project and product require-
ments can be defined, collected, and analyzed at the start of the project. This approach is
widely referred to as a “waterfall” or “traditional” approach to project management. With
the predictive development approach, you design and implement a project in a life cycle
sequenced in distinct phases, from the initial conceptual and feasibility phase to the deploy-
ment of the final product or service. The predictive approach is more structured, predictable,
and stable than the adaptive approach. Next, we review additional aspects of the predictive
approach, as you will be tested extensively on this topic on the CAPM® exam.
The PMBOK® Guide – Seventh Edition, Section 2.3.3 indicates that the predictive approach
is best used in the following situations:

■ When there is a significant investment involved and a high level of risk that may
require frequent reviews and replanning between development phases

■ When the scope, schedule, cost, resource needs, and risks can be well defined in the
early phases of the project life cycle and are relatively stable

■ When the project team wants to reduce the level of uncertainty early in the project
and do much of the planning up front

■ When the project work can follow plans that were developed near the start of the
project

■ When templates from previous similar projects are available

Choosing the Adaptive Approach

An adaptive development approach is practical when requirements are subject to a high
level of uncertainty and volatility and are likely to change throughout the project. In such an
environment, you can proceed with an adaptive life cycle for project implementation. This
life cycle is designed around iterations that repeat project phases. The project can move to
the next phase only after customer or product stakeholder feedback is available. It suggests
that a particular stage of development has reached a point at which it is appropriate to move
on. Different expressions related to the adaptive approach can be found in the literature, but
the most common terms are iterative, incremental, and agile.
106 Certified Associate in Project Management (CAPM)® Exam Official Cert Guide

The PMBOK® Guide – Seventh Edition, Section 2.3.3 indicates that the adaptive approach
is best used in the following situations:

■ When a clear vision of an end state is available at the start of the project but very little
is known about the details of the requirements that make up that end state

■ When there is flexibility to refine, change, and replace requirements

■ When there is an opportunity to receive frequent user and product owner feedback

■ When there is uncertainty or when high risks are associated with the project or busi-
ness environment (In other words, the final deliverables have to be right, but all factors
may not be fully articulated in advance.)

■ When an empowered team is given a prioritized backlog of desired deliverables, as

well as the freedom to determine what scope is achievable within a given iteration, and
the team is permitted to work through the backlog over multiple iterations until the
requirements are fully delivered

Choosing a Hybrid Approach

A hybrid development approach is a combination of adaptive and predictive approaches.
This means that some elements from a predictive approach are used along with some ele-
ments from an adaptive approach. The project professionals must determine which elements
are best for a particular aspect of a project and how to blend the different elements into an
overall plan of action.
The PMBOK® Guide – Seventh Edition, Section 2.3.3 indicates that the hybrid approach is
best used in the following situations:

■ When an organization has both an opportunity and a need to leverage the strengths of
the adaptive and predictive approaches. (For example, when very little might be known
about a product or service, a front-end adaptive approach might be used to gather
requirements and prototype a solution for feedback. Subsequently, when the general
approach has been learned through the iterative prototyping steps and a final solu-
tion is clear, a known project implementation template is more appropriate; the project
could be completed using the predictive model to deliver that solution.)

■ When compliance requirements indicate that certain aspects of the deliverable must be
implemented in a very predictable way, but the core nature of the solution may need to
be entirely determined through iteration in a simulated environment

■ When there is project management maturity in the organization and the project team
is familiar with both approaches and can thus fuse together the two approaches to
develop a new model for project delivery that is suitable for the organizational needs

NOTE The Agile Practice Guide (see Appendix X3) introduces an Agile Suitability
Filter tool to help project professionals evaluate criteria, facilitate discussions, and make
an informed selection of recommended development approaches. Please review the various
attributes of this useful tool.
 Chapter 4: Development Approach and Life Cycle Performance Domain 107

Life Cycles in Practice

Summarizing the relevant definitions so far:

■ Predictive life cycle: A project life cycle that is structured to execute sequentially
along a linear path

■ Adaptive life cycle: A project life cycle that is iterative or incremental as it provides
for proving less understood concepts or requirements over a series of repeated steps

■ Hybrid life cycle: A project life cycle that contains elements of both predictive and
adaptive approaches in which each is used to achieve greater overall effectiveness than
could be achieved by using either approach alone

The project management development approach and delivery cadence can impact the phases
of a project life cycle. If a project team adopts a predictive life cycle, then the project life 4
cycle will likely be a traditional waterfall-like linear sequence of phases. However, if the team
selects an adaptive development approach, the project life cycle will be made up of cyclical
loops. These loops gradually produce the needed project outcomes as the deliverables of
each loop are subjected to stakeholder feedback.
To aid in learning these often subtle differences, it is appropriate to take a look at some
sample life cycles in practice from industry applications.

Industry Application: Predictive Life Cycle

Predictive life cycles are associated with clear phases; the project is constrained to develop
requirements early and to stay with the original requirements and design plans that were
created at the start of the project. The PMBOK® Guide – Sixth Edition, now part of the
PMIstandards+™ online guide, states the following in Appendix X-3:

■ Define requirements up front, before development begins.

■ Deliver plans to develop the eventual deliverable, and then deliver only a single final
product at the end of the project timeline.

■ Constrain change as much as possible and as early as possible.

■ Involve key stakeholders at specific milestones and stage gate reviews.

■ Control risk and cost through detailed planning of mostly knowable considerations.

Each sector has its own typical version of a predictive project life cycle. Because both the
terminology and importance of deliverables are different across domains, each sector has
naturally evolved its own detailed approach.

Predictive Life Cycle Example 1

For this example, we consider the construction industry. This example leverages a predictive
life cycle, as shown in Figure 4-9.

Framing &
Feasibility Design Permit Site Work Foundation Sheathing Finishing Acceptance
Utilities

Figure 4-9 Construction Example Using a Predictive Life Cycle

108 Certified Associate in Project Management (CAPM)® Exam Official Cert Guide

The key phases in a construction life cycle could be:

■ Feasibility: Evaluating the feasibility of the construction project

■ Design: Involving architects and designing a schematic definition of the project

■ Permits: Ensuring that the project is approved by the jurisdictional authorities either
before or after construction, as appropriate

■ Site work: Clearing the ground, installing temporary power and utilities, and
inspecting

■ Foundation: Excavating, pouring concrete, creating basement walls, waterproofing,

and insulating

■ Framing and utilities: Installing joists, framing walls, and installing plumbing,
electrical, HVAC

■ Sheathing: Installing roof decking, shingles, doors, and windows

■ Finishing: Installing insulation, drywall, paint and wallpaper, cabinets, tile, and
appliances

■ Acceptance: Conducting a walk-through and inspection, developing and complet-

ing the final punch list, obtaining final acceptance, and getting local government final
approval for occupancy

Predictive Life Cycle Example 2

Software development is increasingly associated with an adaptive approach because software
is more often delivered through modules of code that accomplish a specific task. However,
not all software can or should be delivered this way. Historically, many well-known systems
development life cycles have used a sequential, phased approach to deliver software. There-
fore, it is very important to show how a software project might use the predictive life cycle.
Representative key phases in a software development life cycle (also known as a systems
development life cycle, or SDLC), as illustrated in Figure 4-10, are:

■ Feasibility: During this phase, the customer’s problems are defined and a business
analyst elicits high-level requirements. Feasibility and preliminary project scope are
completed.

■ Analysis: The business analyst works with the software development team to design
an acceptable solution for the customer. The deliverable is the design document.
Additionally, the project manager finalizes the baseline cost and schedule, secures
resources, and establishes a timeline and budget.

■ Requirements gathering: The business or systems analyst conducts a detailed needs

analysis and documents software and functional specifications.

■ Design: Software designers use the documentation to establish the initial concepts of
the system architecture, including interfaces between modules and where certain func-
tions will take place.
 Chapter 4: Development Approach and Life Cycle Performance Domain 109

■ Detailed design: The technical team creates a complete detailed design to meet all
requirements, obtain approval, and hand over documentation to programmers for
coding.

■ Coding: Programmers code software and conduct some unit testing. They hand over
the software to the quality assurance department for testing.

■ Testing: The quality assurance staff conducts comprehensive unit testing.

■ System integration: The team assembles the entire set of modules so that they can be
tested according to how they perform with each other and integrate with other related
systems.

■ Acceptance testing: The team conducts final testing of the completed system in an
environment that matches the production environment as closely as possible. The
customer analyzes the acceptance test results and, if satisfactory, signs the acceptance 4
agreement.

■ Deployment: The operation phase begins after customer acceptance. The project man-
ager and appropriate team members determine a deployment strategy, complete docu-
mentation, train staff, and deploy the software.

Requirements Detailed System Acceptance

Feasibility Analysis Design Coding Testing Deployment
Gathering Design Integration Testing

Figure 4-10 Software/Systems Development Life Cycle Example Using a Predictive

Life Cycle

The process shown in Figure 4-10 is characterized as a predictive life cycle because the
completed steps are generally not revisited again. For example, when the requirements are
firmed up, they are not changed during the detailed design, coding, and testing steps. If the
software development life cycle shown in Figure 4-10 is to succeed using this predictive life
cycle approach, the business/system analysts must have fully complete requirements. Like-
wise, the coding team must have the final software architecture and detailed design docu-
mentation before software construction begins. A wide array of specialized staff is involved
in this predictive life cycle.
The sequential nature of the SDLC approach does not preclude some level of iteration. If
the requirements change in a minor way based on customer feedback or testing failure, the
project team can certainly revisit these minor changes through revised design, coding, and
testing. The idea is to discover these issues as early as possible because the cost of changing
a system can increase as more of it is developed through the project’s life cycle.
However, if significant changes tend to be required frequently, or even if new requirements
are injected into the project at later stages, this can have a significant impact on the prior
design or coding stages, making it necessary to revisit these stages; in such situations, the
predictive software development life cycle is not appropriate. Because modern software
development projects tend to accommodate changes that have greater impact regularly, soft-
ware development project teams are likely to consider an adaptive life cycle today for many
such projects.
110 Certified Associate in Project Management (CAPM)® Exam Official Cert Guide

Industry Application: Adaptive Life Cycle

Adaptive life cycles are associated with the iteration and gradual delivery of working com-
ponents over several iterations. As such, a project is less constrained to develop requirements
early and, therefore, allows modifications as the deliverables are finally reviewed; this often
makes the end product very different from what might have been articulated at the start of
the project. The PMBOK® Guide – Sixth Edition, now part of the PMIstandards+™ online
guide, states the following in Appendix X-3:

■ Requirements can be elaborated during delivery.

■ Key users or stakeholders are regularly involved in the life cycle to improve the
outcome.

■ Input from stakeholders often requires repetition of the previous phase.

According to the PMBOK® Guide – Seventh Edition, adaptive life cycles have some
distinct characteristics:

■ Iterative life cycle: An adaptive life cycle in which development occurs through
continuous refinement over the life of the project

■ Incremental life cycle: An adaptive life cycle in which development occurs in small
increments, gradually forming the end deliverable through segments

■ Cadence: A rhythm of activities conducted throughout a project

■ Delivery cadence: The timing and frequency of project deliverables

Adaptive Life Cycle Example: Adaptive Software Development

Figure 4-11 illustrates a software life cycle example as an adaptive life cycle. It includes some
typical elements of an iterative adaptive software development life cycle. When the business
analysis step is complete and requirements are captured (generally in writing), a prototype is
implemented to demonstrate to the end user the product’s overall features. This prototype is
not necessarily fully functional but is developed to give the stakeholders a concept of
how the requirements can be implemented. You can see that a fully functional pilot is being
demonstrated to the stakeholders at the end of the coding step. In each step, the goal is to
gather insights and rework the outcomes of the previous step in the life cycle.

Requirements Detailed System Acceptance

Feasibility Analysis Design Coding Testing Deployment
Gathering Design Integration Testing

Show Prototype Show Pilot

Figure 4-11 Iterative Adaptive Software Development Life Cycle

 Chapter 4: Development Approach and Life Cycle Performance Domain 111

This life cycle derives benefits from stakeholder feedback and team insights. Critical risks are
mitigated in this approach. The requirements might not have been clear in the beginning, but
a prototype can clarify the requirements. Where complexity is high, you can see that a fully
functional pilot can likely ensure that the deployment will be successful. A vital characteris-
tic of the adaptive life cycle is cadence—how often a prototype, pilot, or deliverable is ready
for review. In adaptive software development, the project is understood to involve a frequent
cadence of incorporating stakeholder feedback early. Therefore, Figure 4-11 shows that the
final deliverable appears in successively refined stages at the prototype, pilot, testing, and
deployment stages.

Industry Application: Hybrid Life Cycle

As mentioned earlier in this chapter, in a hybrid development approach, some elements of a
predictive approach are used along with some elements of an adaptive approach. Consider
the following characteristics of a hybrid life cycle:
4
■ There is both an opportunity and a need to leverage the strengths of both approaches.

■ This approach is practical when compliance requirements demand that certain aspects
of the deliverable be implemented in a very predictable way. Still, the core nature of
the solution may need to be determined entirely through iteration in a simulated
environment.

■ This approach is practical when there is project management maturity in the organiza-
tion and when the project team is familiar with both approaches. The team then can
bring together the two approaches to develop a new model for project delivery that is
suitable for the organizational needs.

It is helpful at this point to look at an industry example of the implementation of a hybrid

life cycle.

Hybrid Life Cycle Example: Small Restaurant Business

Sam and Mary Oduwa are talented chefs. Recent changes in the restaurant business environ-
ment and their professional careers prompted them to consider starting a restaurant. Working
with their daughter, Myra, who is adept in technical matters, they focused on a two-step
process: First, they want to create a virtual restaurant to understand their customers bet-
ter and refine their menu. Second, they want to move to a physical restaurant near their
hometown.
Due to the relatively stable technology and flexible options for food delivery, Sam and Mary
believe they can get going quickly. Their supportive local bank successfully approved their
business proposal for funding to start their virtual restaurant business, and they obtained the
needed permits from their local government office.
Sam and Mary visualized three stages through which their business could progress and
created a timeline consisting of a one-month period for each stage (see Figure 4-12).
112 Certified Associate in Project Management (CAPM)® Exam Official Cert Guide

Adaptive Incremental Approach Predictive Approach

Phase 1 Phase 2 Phase 3

Physical
Cook at Home Rent a Kitchen
Restaurant

Construct Construct
Concept
and Deliver
Close Concept
and Deliver
Close 1. Confirm funding.
2. Determine the location.
3. Get all the required permits.
4. Confirm vendors and suppliers.
5. Install technology.
Explore restaurant options Train additional chefs 6. Get the workforce needed to launch.
Set the menu Confirm business viability 7. Market and promote the restaurant.
8. Open the restaurant
Figure 4-12 A Hybrid Project to Open a Small Restaurant

In an adaptive life cycle, these short, repetitive timelines can be referred to as sprints. Each
sprint typically lasts one to four weeks. Sam and Mary considered the following phases as
incremental approaches toward their final restaurant opening:

1. Cook at home.
2. Rent a kitchen near their home.
3. Open a restaurant in a single location.
Sam and Mary also recognized that, although they could be very flexible with the first two
phases, the third phase would require a more detailed plan, and the physical restaurant would
need to be fully functional upon opening. Therefore, although they could use an adaptive
approach for the first two phases (involving concept, construct/deliver, and close steps for
each phase), they would need to develop a sequential plan to successfully implement the
final restaurant location. Food menus and customer reputation could be iteratively built
through the adaptive phases so they would be ready to implement in phase 3. However, the
physical location would require a step-by-step development approach to be ready to serve
customers.
Knowing that the third phase would likely take longer than the previous two phases, and
knowing that it would have very defined dependencies, Sam and Mary started the predictive
plan for phase 3 in parallel with the first two adaptive phases. This allowed them to select
the location, get permits, design the renovation, sign construction contracts, and procure
the necessary equipment and furniture, all while perfecting their menus at home and serv-
ing their first customers using equipment in their rented kitchen. When all these preliminary
steps were complete, they could quickly move into their new location and be ready for their
restaurant’s grand opening.
This restaurant business development example demonstrates combined characteristics of
adaptive and predictive approaches—a hybrid life cycle.

Considerations for Selecting a Development Approach

Several factors influence the selection of a development approach. The PMBOK® Guide –
Seventh Edition, Section 2.3.4 outlines these factors, as shown in Figure 4-13. The criteria
can be divided into three categories: product, service, or result; project; and organization. It
is important to review the meanings of each of these components.
 Chapter 4: Development Approach and Life Cycle Performance Domain 113

Product, Service,
Project Organization
or Result

Degree of Stakeholders Organizational

Innovation Schedule Structure
Requirements Constraints Culture
Uncertainty Funding Organizational
Scope Stability Availability Capability
Ease of Change Project Team
Delivery Options Size and
Location
Risk
Requirements
and Regulations

Figure 4-13 Considerations for Selecting a Development Approach

4
Product, Service, or Result
The factors influencing the product, service, or result consideration all have to do with the
nature of a project’s outcome, whether it is a product, a service, or another type of result.

Degree of Innovation
Deliverables that have a well-understood scope and requirements, that the project team has
worked with before, and that allow for planning up front are well suited to the predictive
approach. Deliverables involving a high degree of innovation or those with which the project
team does not have experience are better suited to a more adaptive approach.

Requirements Certainty
A predictive approach works well when the requirements are well known and easy to define.
When requirements are uncertain, volatile, or complex and are expected to evolve through-
out the project, a more adaptive approach is a better fit.

Scope Stability
If the scope of the deliverable is stable and not likely to change, a predictive approach is
practical. If the scope is expected to undergo many changes, an approach that is closer to the
spectrum’s adaptive side can be helpful.

Ease of Change
Related to requirements certainty and scope stability, if the nature of the deliverable makes it
challenging to manage and incorporate changes, then a predictive approach is best. Deliver-
ables that can quickly adapt to change can use an adaptive approach.

Delivery Options and Cadence

The nature of the deliverable, such as whether it can be delivered in components, influences
the development approach. Products, services, or results that can be developed and delivered
in pieces are aligned with incremental, iterative, or adaptive approaches.

Risk
You can reduce risk by building products modularly and adapting the design and develop-
ment based on learning to take advantage of emerging opportunities or reduce the exposure
to threats. Adaptive approaches frequently mitigate high-risk requirements by addressing
their viability first.
114 Certified Associate in Project Management (CAPM)® Exam Official Cert Guide

Safety Requirements and Regulations

Products that have rigorous safety requirements often use a predictive approach because
significant up-front planning is needed to ensure that all the safety requirements are identi-
fied, planned for, created, integrated, and tested. Likewise, environments that are subject to
significant regulatory oversight may need a predictive approach due to the required process,
documentation, and demonstration needs.

Project
The factors in the project consideration column all have to do with aspects of the project,
such as how it is structured, constrained, and funded.

Stakeholders
Specific stakeholders, such as product owners, play a substantial role in establishing require-
ments from the customer’s perspective and prioritizing work. If such dedicated project team
staff are available to support project work, adaptive methods are preferred.

Schedule Constraints
If there is a need to deliver something early, even if it is not a finished product, an adaptive
approach is beneficial.

Funding Availability
Projects that work in an environment of funding uncertainty can benefit from an adaptive
approach. A minimum viable product can be released with less investment than an elaborate
product. This allows for market testing or market capture with minimum investment.

Organization
The factors in the organization consideration column all have to do with the organizational
environment of the project, including the culture, structure, and complexity.

Organizational Structure
An organizational structure with many levels, a rigid reporting structure, and substantial
bureaucracy is likely to use a predictive approach. In contrast, projects that use adaptive
techniques are associated with a flat structure.

Culture
A predictive approach fits better in an organization with a culture of managing and direct-
ing. Here the work is planned out and progress is measured against baselines. Adaptive
approaches fit better within an organization that emphasizes project team self-management.

Organizational Capability
If organizational policies embrace attitudes and beliefs that support an agile mindset, then
adaptive methods are likely to succeed.

Project Team Size and Location

Adaptive approaches often work best with project teams of five to nine individuals. Adaptive
approaches also favor project teams that are located in the same physical space.
 Chapter 4: Development Approach and Life Cycle Performance Domain 115

Project Activity, Deliverables, and Milestones

Now that you have an understanding of project phases and life cycles, you are ready for a
description of some common elements that are present in all types of approaches. In this
final section, we introduce project activities, deliverables (including their measurement), and
project milestones.

Project Activities
An activity—or task, story, work package, or use case—is a scheduled step in a project plan
that has a distinct beginning and end. An activity usually involves several substeps; when
those substeps are completed, the whole activity can be regarded as completed. Several
related activities can be combined to form a summary activity.
Let’s work through an example of a party where food, games, and entertainment are being
planned. We might list several activities, such as these:
4
■ Prepare a proposal for the party and a budget.

■ Identify potential locations.

■ Obtain permission for a venue.

■ Arrange logistics and notify the security personnel and custodians.

■ Identify the food vendor and the menu.

■ Identify the music entertainment vendor.

■ Finalize contracts with vendors.

■ Create the party event committee.

■ Design invitations.

■ Email the invitations and personally invite stakeholders.

■ Conduct a dry run before the event.

■ Execute the party.

■ Come to administrative closure and list lessons learned.

■ Send out a survey.

Deliverables
Project deliverables are measurable outputs of activities. They can be tangible or intangible.
You can imagine handing off (delivering) something to the project sponsor or stakeholders at
the conclusion of an activity. For the party project example, the following sample list shows
activities and the deliverable associated with each activity:

■ Prepare a proposal for the party and a budget: Statement of work or charter

■ Plan for the party and select a final party location: Approved permit or reservation
with location, day, date, and time

■ Select the food vendor: Signed contract with the food vendor

■ Collect survey responses: Post-party survey results from participants

116 Certified Associate in Project Management (CAPM)® Exam Official Cert Guide

It is important to recognize that the overall project itself is associated with a deliverable. The
overall product or service being delivered by the project as a whole can be regarded as an
end deliverable.
Intermediary deliverables also are present, such as the design and delivery of various project
components. The project management process results in specific process deliverables, such as
documentation and managerial reports. Examples of intermediary deliverables include:

■ Scope: This might consist of several separate deliverables as the project proceeds,
including preliminary requirements, conceptual design, and detailed design.

■ Cost and schedule estimates: These are required at major milestones to report on the
status of the project.

■ Intermediate project components: These might include early prototypes and partial
project deliverables.

■ Project management reports: These include monthly reports, containing cost and
schedule data, project status, risk updates, stakeholder issues, and so on.

Measuring Deliverables
Every deliverable must be checked for compliance with the scope, schedule, and budget. The
outcomes hinge on assessing or measuring the quality and acceptability of the deliverable.
Therefore, when the deliverables are proposed, the project manager must consider how they
are to be assessed and measured; this is a necessary step in defining a deliverable. Examples
of measurable deliverables include miles of roadway completed, pages of document com-
pleted, and square meters of wall painted. Even deliverables such as software can be mea-
surable if they are described correctly according to their functions (for example, “A new
customer can register a new account successfully by using the customer account registration
function”).
Let’s get into a bit more detail. When you propose a document as a deliverable, for example,
someone knowledgeable about the deliverable should be able to provide an expected outline
and maybe even an expected page count. Besides helping to better describe the deliverable,
these measures are essential because they provide a foundation for cost and schedule esti-
mation, especially if the organization has a good idea of how many units per hour, day, or
week a typical employee can produce. If a road construction crew can pave 3 kilometers of
roadway per day, and the total crew typically is paid a certain overall set of wages per day,
then knowing the total length of roadway defined by the end deliverable will assist the proj-
ect manager in estimating the time to completion and the total labor cost estimate for this
deliverable.
When a deliverable is defined and then assigned to a given resource, these measures can
communicate what level of effort is expected. At any given elapsed point in time, you can
then reasonably measure the progress against expectations estimated for that elapsed time.
If actual deliverables are only half of what was expected, for example, then you immediately
know that you have a problem and should investigate how to get the progress back on track.

Milestones
A milestone is a significant point or event in the project. The term originated from the
ancient Roman Empire. The Romans were famous for building roadways across thousands
 Chapter 4: Development Approach and Life Cycle Performance Domain 117

of miles, and many of them remain visible today. Figure 4-14 shows an example of a Roman
milestone—a marker made of stone that was placed along a roadway and engraved with the
distance from the milestone to specific destinations in the Roman Empire. These milestones
enabled the Roman army generals to calculate how long it would take to move troops from
one area of the empire to another. Merchants and travelers also used these milestones to
determine where they were on a given roadway that could be correlated to a map. In other
words, the milestones were markers providing specific geolocation information that could be
used to predict the time and cost in getting from one place to another. Highway construction
engineers use similar markers on our roads today, although they are no longer made of stone;
they are usually small signposts set at regular intervals along a highway, each with a code
that corresponds to the distance from the start of the highway.

Figure 4-14 A Milestone from the Ancient Roman Empire

118 Certified Associate in Project Management (CAPM)® Exam Official Cert Guide

Just as milestones informed the ancient Romans—and still inform today’s land travelers—
milestones are used in project management to allow a project manager to track progress
along the timeline of a project. Milestones can be used to designate the completion of cer-
tain segments or deliverables for a project. Complex projects may have many milestones in
the timeline, and they are helpful in determining how much work has been completed and
how much remains to be done.
Like the markers of stone in ancient Rome, a project milestone is an event that marks either
the beginning or the end of activities. A milestone has no duration or resources assigned; it
is simply a marker for reference. Project software tools can typically show views of milestone
completion, comparisons of estimates with actual progress, and so on.
At the point of project planning and estimating, each milestone should have a target date
associated with it that shows the expected point at which all the activities before that mile-
stone will be completed. During project planning, the date associated with the milestone is
the planned milestone completion date; after successful execution, it becomes the actual
milestone completion date.
For example, completing the definition of project scope is typically a major milestone for
projects. Completing project planning is another major milestone; it marks the completion
of the project management plan deliverable and the customer’s acceptance of the plan. This
type of milestone might be called Project Planning Complete and is first given a planned
date of completion and then given the actual date when the customer accepts the plan.
In this final section, we have introduced the idea of using project activities as a way to define
the steps needed for project completion; project deliverables (including their measurement) as
the means through which we can determine that a project has met its expectations of scope;
and project milestones, which provide markers along the project timeline that can be used to
measure estimated and actual progress. These concepts are universal with regard to project
approach: They are integral in helping a project manager ensure successful project comple-
tion, no matter which development approach is chosen.

Summary
This chapter addresses the basics of project life cycles and project phases. It compares
project life cycles with product life cycles, showing common concepts as well as differences
in the management of each type of life cycle. It also explores the foundational concepts
of predictive, adaptive, and hybrid approaches and illustrates sample industry life cycles.
Finally, this chapter addresses the nature of project activities, deliverables, and milestones, all
of which can be found in any type of project life cycle approach. This chapter is intended to
give you foundational information that will be helpful as you explore more detailed consider-
ations of these approaches in future chapters.

Exam Preparation Tasks

As mentioned in the section “How This Book Is Organized” in Chapter 1, you have a couple
choices for exam preparation: the exercises here; Chapter 12, “Tailoring and Final Prepara-
tion”; and the exam simulation questions in the Pearson Test Prep Software Online.
 Chapter 4: Development Approach and Life Cycle Performance Domain 119

Review All Key Topics

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

Table 4-3 Key Topics for Chapter 4

Key Topic Description Page
Element Number
Figure 4-1 A Typical Project Life Cycle 98
Paragraph Stage gates 99
Paragraph Life cycle phases vs. Process Groups 101
Figure 4-6 Product Management Life Cycle 103
Figure 4-7 Development Approach and Life Cycle Performance Domain 104 4
Paragraph The hybrid development approach 104
List Choosing the predictive approach 105
List Choosing the adaptive approach 106
List Choosing the hybrid approach 106
Figure 4-13 Considerations for Selecting a Development Approach 113
Paragraph Project activities 115
Paragraph Deliverables 115
Paragraph Measuring deliverables 116
Paragraphs Milestones 118

Define Key Terms

Define the following key terms from this chapter and check your answers in the glossary:

project phase, project life cycle, progressive elaboration, stage gate, product, deliverable,
development approach, predictive development approach, adaptive development approach,
hybrid development approach, iterative, incremental, milestone

Suggested Reading and Resources

Project Management Institute. PMIstandards+™ (online repository). https://
standardsplus.pmi.org/home#.
Project Management Institute. (2023). Process Groups: A Practice Guide.
Project Management Institute. A Guide to the Project Management Body of Knowledge
(PMBOK® Guide) – Sixth Edition, 2017. (PMBOK® Guide – Sixth Edition is approved by
ANSI.)
Project Management Institute. A Guide to the Project Management Body of Knowl-
edge (PMBOK Guide) – Seventh Edition, 2021. (PMBOK® Guide – Seventh Edition is
approved by ANSI.)
Index

A work package, 144–146

adaptive development approach, 10,
105–106, 110, 451
absolute estimation, 235, 451
agile
AC (actual cost), 166, 451
Disciplined, 284–286
acceptance
flow-based, 267–268
criteria, 407–408
iteration-based, 267
test-driven development, 407
Scrum, 268–272
testing, 109
building a website for a conference,
accountabilities, 267
239–240
activity/ies, 115, 144–149
business analysis, 344–347
backward pass, 154–155
Close stage, 237, 251
business analysis, 355–356, 367
Concept stage, 231, 241
deliverables, 115–116
exiting, 233
dependencies, 146
product roadmap, 232–233,
float, 155–156 244–245
forward pass, 152–153 vision statement, 231–232,
merge, 153 241–242
milestone, 116–118 Construct and Deliver stage, 233–234,
network diagram, 151, 451 247–249, 250
Planning performance domain, 234 collect and decompose
requirements, 245–247
collect and decompose
requirements, 234 create release plan, 247
create a product backlog, 235 delivery of release 1, 250
develop a release plan, 234–235 exiting, 237
estimate effort with story Planning performance domain,
points, 235 234–236
plan iterations, 236–237 Project Work and Delivery
performance domains,
Project Work and Delivery
236–237
performance domains, 236–237
release plan, 249
sequencing, 148–149
Crystal, 279
value- and non-value-adding, 265, 266
DSDM (Dynamic Systems Development working software over com-
Method), 278 prehensive documentation,
constraint-driven delivery, 223–224
278–279 when to use, 217–221
principles, 278 work groups, 238
FDD (Feature-Driven Development), 277 XP (Extreme Programming), 275
advantages, 278 core practices, 275–276
project life cycle, 277–278 roles, 275
frameworks, 10 takeaways, 276–277
Kanban, 272 adjournment, team, 80
limiting work in progress, 273 affinity diagram, 203, 451
versus Scrum, 274 agenda, meeting, 81
suitability for an agile, 451. See also Kanban; SAFe®
organization, 272 (Scaled Agile Framework); Scrum
workflow focus, 273 Disciplined, 284–286, 454
Lean, 262, 263 flow-based, 267–268, 456
eliminating waste, 263 iteration-based, 267
features, 262 KPIs (key performance indicators),
value streaming, 264–267 301–304
progress tracking, 318–321 life cycle, 238–239
project management, 41 project scaling competencies, 280–282
requirements, 222 Scrum, 268
risk and risk management, 317 events and artifacts, 269–270
SAFe® (Scaled Agile Framework), versus Kanban, 274
282–283 roles, 268–269
Scrum of Scrums, 284, 287–288 of Scrums, 284
ScrumBan, 274 sprint, 267
software development, 110–111 ScrumBan, 274
stages, 229–231 Agile Manifesto, 222–223, 257
team culture, 225–227 Agile Practice Guide, 219
team/s, 221 agriculture, project management, 34–35
uncertainty factors, 220 alignment model, 360, 451
value/s, 194 ambiguity, 313
customer collaboration over analogous estimation, 149, 451
contract negotiation, 224 analysis
individuals and interactions over business. See business analysis
processes and tools, 223
cost-benefit, 362
responding to change, 224
document, 359, 371–372, 455
470 analysis

earned value, 165–166 assumption, 37, 39–40, 451

gap, 361 attitude, stakeholder, 54. See also
impact, 403, 457 mindset
job, 341 authority, project manager, 73–74
Pareto, 198–199
persona, 341 B
requirements, 377
backlog, 452
stakeholder, 54–55, 341–342
prioritization, 298–299
applications, CAPM exam, 12
product, 235, 269, 299
appraisal costs, 195, 451
sprint, 299
approval, 402–403
task, 250
ART (Agile Release Team), 280, 451
backward pass, 154–155
artifact, 128, 269–270, 425–426, 451.
See also documentation baseline, 137
aspire phase, life cycle, 98 requirements, 403
assessment scope, 162
matrix, 183–184 behavior-driven development, 407
needs, 354–355 belief, stakeholder, 54
assemble the business case, benchmarking, 358, 362, 452
364–365 bid
assess current state and deter- conference, 181, 452
mine future state, 359–361 submission, 180–181, 452
determine viable options and walk-through, 181, 452
recommend solution, 361–362
brainstorming, 371
drafting a situation statement,
budget, limit, 38
358–359
building, team, 66, 242–244
facilitate product roadmap
development, 363–364 burndown chart, 301–304, 321, 452,
464
identify problem or opportunity,
358 burnup chart, 304, 452
reasons for performing, 355 business acumen, 61–63
seek approval from stakeholders, business analysis, 10–11, 41, 350–351,
359 452. See also model/s; requirement/s
support charter development, cadence, 347
365 feasibility study results, 362
tasks, 356–357 importance of, 328–329
when they occur, 355–356 life cycle phase, 98
who is involved, 356 models, 377–380
performance, 407–408 data, 391–395
interface, 396–398
 Business Analysis for Practitioners: A Practical Guide 471

process, 384–390, 445–446 considerations for adaptive

rule, 390–393 and predictive approaches,
374–375
scope, 380–384, 444–445
document analysis, 371–372
needs assessment, 354–355
focus groups, 372
assemble the business case,
364–365 interviews, 372
assess current state and deter- observation, 372–373
mine future state, 359–361 prototyping, 373–374
conduct and confirm elicitation results, 377
results, 340 surveys, 373
determine viable options and telemedicine app, 375–376
recommend solution, 361–362
workshops, 372
drafting a situation statement,
role of the business analyst, 329–330
358–359
situation statement, 340
examine enterprise organization,
340 skills, 330–331
facilitate product roadmap solution evaluation, 405–406, 409
development, 363–364 determine approach, 407–408
identify problem or opportunity, evaluate acceptance results and
358 address defects, 409–410
reasons for performing, 355 evaluate deployed solution, 410
seek approval from stakeholders, identify who will conduct, 409
359 obtain solution acceptance for
support charter development, release, 410
365 performance evaluation,
tasks, 356–357 406–407
when they occur, 355–356 performance measurement,
who is involved, 356 407–408
planning, 342, 366–368 stakeholder/s, 338
project approaches, 343 identifying, 338–340
adaptive, 344–347 register, 340
predictive, 343–344 traceability and monitoring, 398–399,
404–405
versus project management, 328,
331–332, 365–366 monitor requirements, 401–402
requirement types, 332–333 trace requirements, 399–401
requirements analysis, 377 update requirements and
communicate requirements
requirements elicitation, 368–371
status, 402–403
brainstorming, 371
Business Analysis for Practitioners:
A Practical Guide, 367, 400
472 cadence

C control, 199–200, 202, 307, 453

CL (centerline), 200
cadence, 110, 111, 113, 227, 347, 454 rules, 201–202
CAPM (Certified Associate in Project UCL (upper control limit), 200
Management)® Gantt, 138, 156, 458
eligibility, 11–12 Pareto, 199, 459
exam, 3–4, 10–11. See also final charter, 454
preparation development, 365
applications, 12 life cycle phase, 98
domain/task breakdown, 4–8 project, 35, 134–136
mapping exam content outline to CL (centerline), 200
chapters in this book, 8–9
claims management, 181–182, 452
preparation, 13
closing, 36
scheduling, 12–13
processes, 453
scope and key concepts,
projects, 163–165, 237, 251
422–423
code of ethics, PMI (Project
updates, 442–443
Management Institute), 86–88
cause-and-effect diagram, 197–198
coding, 109
CFD (cumulative flow diagram),
collaboration
308–310
co-location, 133
challenges
customer, 224
project management, 36–37
collective code ownership, 277
assumptions, 37
co-location, 133, 453
constraints, 37–38
communication/s
issues, 37
barrier, 186, 453
risk, 37
blocker, 186, 453
Scrum, 272
channel, 186–187, 453
change and change management, 41
filter, 186, 453
approval, 402–403
management plan, 138, 188–189, 453
control board, 76
methods, 187–188
cost of, 196–197
model, 185–186, 453
ease of, 113
stakeholder, 55
requests, 160–162
verbal, 55
requirements, 403–404
written, 55
responding to, 224
team, 76
chart
complexity, 182, 313
burndown, 301–304, 321, 452, 464
compression, schedule, 168–169
burnup, 304, 452
 Crystal 473

Concept stage, 231, 241 RFQ (request for quotation),

exiting, 233 180–181
product roadmap, 232–233, 244–245 SOW (statement of work), 178
stakeholders performance control account, 143
domain, 233 control chart, 199–200, 202, 307, 453
team performance domain, 233 CL (centerline), 200
vision statement, 231–232, 241–242 rules, 201–202
conduct procurements, 182 UCL (upper control limit), 200
conflict management, 69–70 control procurements process, 181–182
constraint/s, 34, 37–38, 221, 453 core values, Scrum, 270–271
-driven delivery, 278–279 cost/s, 163
event planning, 39–40 actual, 166, 451
Construct and Deliver stage, 233–234, appraisal, 195, 451
245, 247–249, 250 -benefit analysis, 362
collect and decompose requirements, external failure, 196, 456
245–247
internal failure, 195–196
create release plan, 247, 249
management plan, 138, 453
delivery of release 1, 250
performance index, 166–167, 453
exiting, 237
-plus contract, 179, 453
Planning performance domain, 234–236
prevention, 195, 460
Project Work and Delivery
of quality, 195–196, 453
performance domains, 236–237
variance, 166, 453
construction industry
COVID-19 pandemic, 26
predictive development approach,
107–108 CPI (cost performance index), 166–167
WBS (work breakdown structure), crashing, 168, 453
164–165 creating
consulting, 24 project management plan
context diagram, 444 activities, 144–149
continuous integration, 277 collect requirements and define
contract scope statement, 139–141
fixed-price, 456 WBS (work breakdown
structure), 141–144
procurement, 178, 460
value, 26–28, 454
cost-plus, 179
critical path, 151, 454
fixed-price, 179
backward pass, 154–155
time and materials, 179–180
float, 155–156
solicitation document, 180, 181
forward pass, 152–153
RFI (request for information), 180
Crystal, 279, 454
RFP (request for proposal), 180
474 culture

culture defects, 196–197

adaptive team, 225–227 addressing, 409–410
continuous learning, 282 software, 200–202
organization, 114 definition
team, 77, 84–85 of done, 236, 270, 303, 388, 454
cumulative flow diagram, 454 of ready, 388
current state, 359, 454 deliverables and delivery, 51, 104,
customer, 246 115–116, 250, 454. See also agile;
Construct and Deliver stage
collaboration, 224
cadence, 110, 113, 227, 454
-valued prioritization, 296
innovation, 113
CV (cost variance), 166
intermediary, 116
cycle time, 306–308, 454
measurement, 116

D value, 193–194, 425

value-driven, 227
DA (Disciplined Agile®), 284–286, 454 dependency, 112
daily scrum, 270, 455 activity, 146
DAR (display-action-response) model, discretionary, 169, 454
396–397 external, 169, 456
dashboard, 310, 454 finish-to-finish, 147
data finish-to-start, 147
collection, 359 internal, 169
dictionary, 395 mandatory, 169, 459
flow diagram, 395 start-to-finish, 147
model start-to-start, 147
data dictionary, 447 team, 77
data flow diagram, 447 developers, 268–269
ERD (entity relationship development approach, 9, 51, 92,
diagram), 393–395 103–104, 107, 454. See also adap-
state table, 447 tive development approach; hybrid
development approach; predictive
decision table, 446
development approach
decision tree, 392, 446
adaptive, 10, 105–106, 110, 451
decision-making, 69
business analysis, 344–347
criteria for choosing development
requirements, 222
approach, 217–221
software development, 110–111
KPIs (key performance indicators), 301
team culture, 225–227
real options, 362
hybrid, 104–105, 106, 111–112
team, 69
incremental, 234–235
value-based, 193–194
 elicitation techniques 475

iterative, 234–235 project management plan, 137–139

predictive, 3–4, 9–10, 105 requirements, 337
business analysis, 343–344 solution requirements, 398
construction industry, 107–108 vision statement, 231–232
life cycle, 107–109 domain, 9. See also performance
selecting, 127 business analysis. See business analysis
software development, 108–109 knowledge, 61–62
tailoring, 132–134 dot voting scheme, 297
selecting, 112–114, 217–221 drafting a situation statement, 358–359
organizational consideration, Drexler and Sibbet model, 80
114 DSDM (Dynamic Systems Development
project considerations, 114 Method), 278, 455
tailoring, 130, 131 constraint-driven delivery, 278–279
DevOps, 283, 286 principles, 278
diagram duration, 150–151, 455
activity network, 151, 451
affinity, 203, 451 E
cause-and-effect, 197–198
context, 444 EAC (estimate at completion), 167,
203, 455
cumulative flow, 308–310, 454
ECO (Exam Content Outline), 3
data flow, 447
EEF (enterprise environmental factors),
entity relationship, 393–395, 446–447
228, 455
flowchart, 203
external environment, 228–229
Ishikawa, 198, 456
internal environment, 228
RACI, 83–84
efficiency, 29, 32, 265, 266
scatter, 203
effort, 150, 455
state, 447
EI (emotional intelligence), 67–68, 455
use case, 383–384, 385–386, 445
elapsed time, 150–151, 455
Direct and Manage Project Work,
elevator statement, 232
157–159
elicitation techniques, 362, 371
discretionary dependency, 169, 454
brainstorming, 371
display-action-response model, 448
choosing, 374
DITL (day-in-the-life) testing, 410
considerations for adaptive and
diverge/converge pattern, 69
predictive approaches, 374–375
document analysis, 371–372, 455
document analysis, 371–372
documentation, 223–224. See also
focus groups, 372
contract; management plan
interviews, 372
business case, 194
observation, 372–373
project charter, 134–136
476 elicitation techniques

prototyping, 373–374 expectations, stakeholder, 54

surveys, 373 experimentation, 314
workshops, 372 expertise, 62, 243
eligibility, CAPM exam, 11–12 external dependency, 169, 456
empiricism, 270 external environment factors, 228–229
endeavor, 21, 23, 57 external failure costs, 196, 456
engagement extrinsic motivation, 64, 456
assessment matrix, 183–184
stakeholder, 182–183 F
tailoring, 421, 455
enterprise solution, 281 fast prototyping, 314
epic, 234, 387, 455 fast tracking, 168, 456
ERD (entity relationship diagram), FDD (Feature-Driven Development),
393–395, 446–447 277, 456
estimation. See also forecasting advantages, 278
absolute, 235, 451 project life cycle, 277–278
analogous, 149, 451 feasibility study results, 362
parametric, 149 feature/s, 234, 236. See also FDD
(Feature-Driven Development)
relative, 235, 463
injection, 362
resource, 149–151
Lean, 262
story points, 305–306
mind map, 382–383
three-point, 149–150
model, 360, 363, 445, 456
time, 149–151
MVP (minimum viable product),
ETC (estimate to complete), 167, 203,
234–235
455
product, 232, 233, 249–250
ethics, project management, 87–88
Fibonacci series, 247
EV (earned value), 166, 456
final preparation, 422
evaluation, 405, 455
scope and key concepts, 422–423
evaporation, 30–31
artifacts, methods, and models,
event/s
425–426
management, 40–41
principles of project
planning, 39–40 management, 423–425
Scrum, 269–270 process groups and processes,
EVM (earned value management), 162, 426–427
165–166, 203–207 project performance domains,
evolutionary prototype, 373 425
execution, 36 value delivery, 425
phase, 157 suggest plan for final review and study,
process, 129, 455 427–428
 hybrid development approach 477

final project costs, forecasting Kanban, 272

EAC (estimate at completion), 167 limiting work in progress, 273
ETC (estimate to complete), 167 suitability for an organization,
final report, 163–164 272
finish-to-finish dependency, 147 workflow focus, 273
finish-to-start dependency, 147 Lean, 262, 263
fishbone diagram, 456 eliminating waste, 263
fishbowl window, 318 features, 262
float, 155–156 value streaming, 264–267
flow-based agile, 267–268, 456 SAFe® (Scaled Agile Framework),
282–283
flowchart, 203
Scrum of Scrums, 284, 287–288
focus groups, 372
ScrumBan, 274
forecasting
XP (Extreme Programming), 275
EVM (earned value management),
203–207 core practices, 275–276
final project costs roles, 275
EAC (estimate at completion), 167 takeaways, 276–277
ETC (estimate to complete), 167 free float, 155
iterations needed, 306 functional manager, 57, 72
formal communication, 55 functional project organization, 70–71,
456
forward pass, 152–153
functional requirements, 335, 456
FP (fixed-price) contract, 179, 456
funding, 114
framework/s
future state, 343, 359, 456
adaptive, 10
agile, 451
Disciplined, 284–286 G
flow-based, 267–268
Gantt chart, 138, 156, 458
iteration-based, 267
gap analysis, 360, 361, 457
Scrum, 268–272
generalizing specialist, 243
Crystal, 279
DSDM (Dynamic Systems
Development Method), 278 H
constraint-driven delivery,
Herzerg’s two-factor theory, 66–67, 457
278–279
high-fidelity prototype, 373
principles, 278
high-performing teams, 78, 226–227
FDD (Feature-Driven Development),
277 hybrid development approach,
104–105, 106, 111, 457
advantages, 278
small restaurant business, 111–112
project life cycle, 277–278
478 hybrid development approach

specification for tax software, 253 IRR (internal rate of return), 362
virtual restaurant business, 252 Ishikawa diagram, 198, 456
website delivery, 251–252 issue/s, 37, 38, 457
management, 159–160
I resolving, 294
IT (information technology), 24
identifying, stakeholders, 52–53, iteration, 457–458
338–340
-based agile, 267
impact
planning, 236–237
analysis, 403, 457
review, 236
stakeholder, 54
iterative
impediments list, 318–319, 457
development, 234–235
incremental development, 234–235, 457
life cycle, 110
incremental life cycle, 110
ITTO (inputs, outputs, tools, and
influence, stakeholder, 55 techniques), 128
informal communication, 55
information radiator, 310, 457
initiation, process, 36, 128–129
J
innovation, 113 job
inspection, 33, 197, 409 analysis, 341
integrity, 85 satisfaction, 66–67
intelligence, emotional, 67–68 security, 66
interest, stakeholder, 55
interface model K
display-action-response, 448
report table, 397–398 Kanban, 267, 458
state table, 447 board, 310
system interface table, 448 limiting work in progress, 273
user interface flow, 397, 448 versus Scrum, 274
wireframe, 396–397, 448 suitability for an organization, 272
intermediary deliverables, 116 workflow focus, 273
internal dependency, 169, 457 Kano model, 298, 360, 458
internal environment factors, 228 Knight, H. F., Risk, Uncertainty, and
Profit, 315
internal failure costs, 195–196, 457
knowledge
interpersonal skills, 63–64
area, 461
interview, 372, 457
business analysis, requirements,
intrinsic motivation, 64–65, 457
330–331
INVEST (independent, negotiable, valu-
domain, 61–62
able, estimable, small, testable), 387
 maple syrup production 479

known-unknowns, 315 project, 97–98

KPA (key process area), 286 progressive elaboration, 99–100
KPI (key performance indicator), stage gate, 99–100
300–301, 458. See also metric tailoring, 131
burndown chart, 301–304, 321 low-fidelity prototype, 373
burnup chart, 304
CFD (cumulative flow diagram),
308–310
M
dashboard, 310 management
decision-making, 301 conflict, 69–70
information radiator, 310 issues, 159–160
progress tracking, 301 matrix, 73
review, 197
L self-, 68
skills, 64
lagging indicator, 300, 458
management plan
land claim, 52
change, 403
lead time, 306–307, 458
communications, 188–189, 453
leadership, 282
cost, 453
interpersonal skills, 63–64
procurement, 460
servant, 224–225, 465
project, 137–139
skills, 64
activities, 144–149
team building, 66
communications, 461
leading indicator, 300
critical path, 151–156
Lean, 262, 263, 458
requirements and scope, 139–141
eliminating waste, 263
time and resource estimation,
features, 262 149–151
value streaming, 264–267 WBS (work breakdown
lessons learned, 163 structure), 141–144
life cycle, 9, 22, 51, 92, 107. See also requirements, 337
development approach resource, 463
adaptive, 110 risk, 464
agile, 238–239 mandatory dependency, 169, 459
FDD project, 277–278 manufacturing, 23
incremental, 110 maple syrup production, 28–35
iterative, 110 evaporation, 30–31
phase, 98–99 RO (reverse osmosis) filtering, 28–29
predictive, 107–109, 130 tapping, 34
product, 103
480 Maslow’s hierarchy of needs

Maslow’s hierarchy of needs, responding to change, 224

65–66, 458 working software over com-
matrix prehensive documentation,
assessment, 183–184 223–224
organization, 72–73 agile, 238
project organization structure, 458 minutes, meeting, 82
RACI, 341–342 MMF (minimum marketable features),
389
responsibility assignment, 83–84
model/s, 425–426, 459
solution capability, 360
alignment, 360, 451
traceability, 400, 401–402, 466
business analysis, 377–380
measurement, 10
communication, 185–186, 453
deliverable, 116
DAR (display-action-response),
KPI. See KPI (key performance
396–397
indicator)
data
metric, 300
data dictionary, 447
performance domain, 295
data flow diagram, 447
progress tracking, 301
ERD (entity relationship dia-
solution performance, 408
gram), 393–395, 446–447
meeting/s
state diagram, 447
agenda, 81
state table, 447
bid conference, 181, 452
feature, 360, 363, 456
conducting, 80
interface
managing distractions, 82–83
display-action-response, 448
minutes, 82
report table, 397–398, 447
planning, 80, 81–82
system interface table, 448
remote pairing, 318
user interface flow, 397, 448
tips for effective, 83
wireframe, 396–397, 448
types, 81
Kano, 298, 360
merge activity, 153
process
metric, 27, 300, 459
process flow, 384–385
throughput, 306
use case diagram depicting
velocity, 304–306 process flow, 385–386
milestone, 116–118, 139, 459 rule
mindset business rules catalog, 391, 446
adaptive, 222–223, 451 decision table, 392–393, 446
customer collaboration over decision tree, 392, 446
contract negotiation, 224
scope, 380–381
individuals and interactions over
processes and tools, 223
 outcomes 481

feature mind map, 382–383 seek approval from stakeholders,

use case diagram, 383–384 359
monitoring and controlling, 34, 36, support charter development, 365
459 tasks, 356–357
processes, 129 when they occur, 355–356
project who is involved, 356
cost and schedule, 162–163 Maslow’s hierarchy of, 65–66
work, 159 nonfunctional requirements, 336, 459
requirements, 401–402 norming, 79
Monopoly money scheme, 298 NPV (net present value), 362
MoSCoW prioritization scheme,
296–297
motivation
O
extrinsic, 64, 456 observation, 359, 372–373, 459
Herzerg’s two-factor theory, 66–67 OPA (organizational process assets),
intrinsic, 64–65, 457 228, 459
Maslow’s hierarchy of needs, 65–66 operations, 27, 459
multivoting scheme, 297 manager, 57
MVP (minimum viable product), maple syrup production, 28–35
234–235, 389, 459 project-based, 24–25
versus projects, 23–24
N role of projects in, 24
opportunity, 191–192, 315, 316
needs identifying, 358
assessment, 354–355 situation statement, 358–359
assemble the business case, organization
364–365
culture, 114
assess current state and deter-
development approach, selecting, 114
mine future state, 359–361
PMO (project management office),
determine viable options and
74–75
recommend solution, 361–362
project, 70
drafting a situation statement,
358–359 functional, 70–71
facilitate product roadmap matrix, 72–73
development, 363–364 projectized, 73, 462
identify problem or opportunity, steering committee, 75–76
358 outcomes
reasons for performing, 355 stakeholder performance domain, 56
team performance domain, 78, 86
482 pair programming

P planning, 36, 51, 167–168, 460

business analysis, 342, 366–368
pair programming, 277 event, 39
parametric estimation, 149, 462 assumptions and constraints,
39–40
Pareto analysis, 198–199
iteration, 236–237
pattern, diverge/converge, 69
meeting, 80, 81–82
PBP (payback period), 362
processes, 129
peer review, 409
PMBOK® Guide, 9, 98, 100
performance, 9, 10
PMI (Project Management Institute), 3
domain, 132, 438. See also deliver-
ables and delivery; development Agile Practice Guide, 319
approach; life cycle; planning; Code of Ethics and Professional
project/s; stakeholder/s; team/s; Conduct, 86–88, 460
uncertainty GPA (global practice analysis), 8
Close Project or Phase, 163–165 JTA (job task analysis), 8
Create Project Plan, 137–139 The Standard for Project
Develop Project Team, 136 Management, 3, 21, 22, 27, 228
Direct and Manage Project Talent Triangle®, 9, 59, 460
Work, 157–159 Task Force on Project Management
measurement, 295 Curricula, 60
Monitor and Control Project PMIstandards+, 100
Work, 159 PMO (project management office), 56,
Planning, 167–169, 234–236 74–75, 461
Project Delivery, 192–193 portfolio, 25, 27, 280
Project Work, 177–178 power
Uncertainty, 311–312 project manager, 73–74
KPI, 300–301 skills, 63–67
solution, 406–407, 408 stakeholder, 54
team, 76–77 predictive development approach, 3–4,
persona analysis, 341 9–10, 105, 460
PERT (program evaluation and review business analysis, 343–344
technique), 149–150 choosing, 127
phase/s. See also stage construction industry, 107–108
closing, 163–165 life cycle, 107–109
execution, 157 process groups, 128
life cycle, 98–99 project value, 194
predictive development approach, 107 software development, 108–109
project, 98 tailoring, 130, 131, 132–134
software development, 108–109 uncertainty factors, 220
 program 483

press release vision statement, 232 planning, 129

prevention, costs, 195, 460 risk management, 35
principles tailoring, 420
Agile Manifesto, 257–258 procurement, 178, 460
DA (Disciplined Agile®), 285 bid conference, 181
project management, 22, 42, 423–425, conduct, 182
438–440 contract, 178
value-driven, 227 cost-plus, 179
prioritization, 295 fixed-price, 179
customer-valued, 296 SOW (statement of work), 178
dot voting, 297 time and materials, 179–180
Kano model, 298 control, 181–182, 453
Monopoly money scheme, 298 management plan, 138
MoSCoW, 296–297 solicitation document, 180, 181
multivoting, 297 RFI (request for information),
owners, 300 180
product backlog, 299 RFP (request for proposal), 180
simple scheme, 296 RFQ (request for quotation),
stack scheme, 297 180–181
problem solving, 294 product/s, 27, 460
procedures, 76 backlog, 235, 269, 299, 460
Process Groups: A Practical Guide, CT scanner, 421–422
128 defects, 196–197
process/es, 460 feature, 249
blade, 286 features, 233, 249–250
closing, 129 life cycle, versus project life cycle, 103
cycle efficiency, 265, 266 minimum viable, 234–235, 389
executing, 129 owner, 223, 246, 269, 461
flow, 360, 384–385 roadmap, 232–233, 244–245,
groups, 35–36, 128, 129, 426–427 363–364, 461
versus project life cycle, 100–102 stakeholders performance
domain, 233
project management, 35–36
team performance domain, 233
initiating, 128–129
vision board, 232
model, 445
visioning, 363, 461
process flow, 445
profit, 103
use case, 385–386, 445–446
program, 25, 27, 461
monitoring and controlling, 129
increment, 280–281
needs assessment, 357
portfolio, 25
484 progress tracking

progress tracking, 301, 318–321 projectized organization, 73, 462

progressive elaboration, 99–100, 404, project/s, 3, 9, 20–21, 51, 461
461 activity, 115
project management, 3, 22, 461 adaptive. See also adaptive
adaptive, 41, 451 development approach
agriculture, 34–35 closing, 237
benefits, 26 requirements, 222
versus business analysis, 328, team structure, 221
331–332, 365–366 -based operations, 24–25
business analysis, 41 baseline, 137
challenges, 36–37 charter, 35, 134–136
assumptions, 37 closing, 163–165
constraints, 37–38 communications, 184–185. See also
issues, 37 communication/s
risk, 37 cost, 162–163
definition, 22 definition, 21
event, 40–41 deliverables, 115–116
knowledge area, 461 delivery, 461
principles, 22, 42, 423–425, 438–440 integration, 57, 207, 461
process groups, 35–36 achieving, 209
program, 25 components, 208–209
roles and responsibilities, 58 lessons learned, 163
skills, 67–68 life cycle, 97–98, 461
team, 77, 462 phase, 98–99
value, creating, 26–28 versus product life cycle, 103
Project Management Curriculum and progressive elaboration,
Resources, 60 99–100
project manager, 22, 66–67, 462 versus project management
organizational authority, 73–74 process groups, 100–102
roles and responsibilities, 56–58 stage gate, 99–100
servant leadership, 224–225 management plan, 137–139
skills, 57–59 activities, 144–149
business acumen, 61–63 critical path, 151–156
conflict management, 69–70 requirements and scope,
139–141
decision-making, 69
time and resource estimation,
motivation, 64–67
149–151
power, 63–64
WBS (work breakdown
social, 68 structure), 141–144
ways of working, 60
 report 485

milestone, 116–118, 139

model, user story, 446
Q
versus operations, 23–24 quality and quality management,
organization, 70 194–195, 462
functional, 70–71 cause-and-effect diagram, 197–198
matrix, 72–73 control chart, 199–202
projectized, 73 cost of, 195–196, 453
performance domain, 4–8, 50–51. defects, 196–197
See also deliverables and delivery; diagrams, 203
development approach; life cycle;
inspection, 197
planning; stakeholder/s; team/s;
uncertainty management plan, 138, 462
phase, 98, 462 Pareto analysis, 198–199
portfolio, 25, 462 requirements, 336–337, 462
program, 25 Six Sigma, 203, 466
requirements, 336–337 walk-throughs, 197
risk, 315 questionnaire, 359, 462
role in operations, 24 questions, CAPM exam, 4
scaling, 169
schedule, 156–157, 162–163 R
services-sector, 132
RACI
stakeholder/s. See stakeholder/s
diagram, 83–84, 464
tailoring, 130, 131, 132–134, 347,
414–415, 417–420 matrix, 341–342
engagement, 421 RAM (responsibility assignment
matrix), 83–84, 463
process, 420
ready, definition of, 388
team, 77, 462
real options, 362
culture, 84–85
reducing, uncertainty, 316
high-performing, 78, 226–227
refactoring, 277
time, 150
relative estimation, 235, 463
uncertainty, 313–315
release
value, 193, 462
obtain solution acceptance, 410
prototyping, 110–111, 373–374
plan, 234–235, 247, 249
pull, 55
roadmap, 390
purchase order, 179
remote pairing, 318
push, 55
report
PV (planned value), 166, 460
analyst, 246–247
final, 163–164
486 report

status, 75 traceability matrix, 140

table, 397–398 transition, 336
report table, 447 types, 332–333
requirement/s, 113, 332, 463 updating and communicating status,
adaptive project, 222 402–403
analysis, 377 validation, 409
approval, 402–403 resource/s, 34
baseline, 403 estimating, 149–151
business, 334, 452 management plan, 138, 463
collecting, 245–247 response
documentation, 337 opportunity, 191–192
elicitation, 368–371 threat, 190–191
brainstorming, 371 RFI (request for information), 180, 463
considerations for adaptive RFP (request for proposal), 180, 463
and predictive approaches, RFQ (request for quotation), 180–181,
374–375 463
document analysis, 371–372 risk and risk management, 34, 35,
focus groups, 372 37, 113, 189–191, 315. See also
uncertainty
interviews, 372
in adaptive projects, 317–318
observation, 372–373
burndown chart, 321, 464
prototyping, 373–374
management plan, 138, 464
results, 377
opportunities, 191–192
selecting the best method, 374
threats, 190–191, 316–317
surveys, 373
tracking, 320
telemedicine app, 375–376
RO (reverse osmosis) filtering, 28–29
workshops, 372
ROI (return on investment), 362
functional, 335, 456
role/s
management plan, 337
business analyst, 329–330
managing changes, 403–404
ECO (Exam Content Outline), 3
monitoring, 401–402
project manager, 56–58
nonfunctional, 336
Scrum, 268–269
project, 336–337
XP (Extreme Programming), 275
project management plan, 139–141
rule/s
quality, 336–337
control chart, 201–202
safety, 114
models
solution, 335, 398
business rules catalog, 391, 446
stakeholder, 335
decision table, 392–393, 446
toll collection, 333–334
decision tree, 392, 446
trace, 399–401
 SME (subject matter expert) 487

S ScrumBan, 274, 464

security, job, 66
SAFe® (Scaled Agile Framework), selection, development approach,
282–283, 465 112–114
safety, requirements, 114 organizational consideration, 114
scaling predictive, 127
agile projects, competencies, 280–282 project considerations, 114
choosing the best framework, self
286–287 -awareness, 67–68
projects, 169 -management, 68
scatter diagram, 203, 464 sequencing, activity, 148–149
schedule, 464 servant leadership, 224–225, 465
compression, 168–169 services-sector project, 132
developing, 146–147, 148 set-based design, 314
project, 142–143, 156–157 simple scheme, 296
variance, 166 situation statement, 340, 358–359
scheduling, CAPM exam, 12–13 Six Sigma, 203, 466
Schwaber, K., Scrum Guide, 268 skill/s
scope agile project scaling, 280–282
baseline, 162, 464 business analysis, 330–331
creep, 139, 140, 272 EI (emotional intelligence), 67–68
management plan, 138 generalizing specialist, 243
models, 380–381 interpersonal, 63–64
feature mind map, 382–383 leadership, 64
use case diagram, 383–384 management, 64
project management plan, 139–141 project manager, 57–59
stability, 113 business acumen, 61–63
Scrum, 268, 464 conflict management, 69–70
burndown chart, 303 decision-making, 69
challenges, 272 motivation, 64–67
core values, 270–271 power, 63–64
daily, 455 ways of working, 60
events and artifacts, 269–270 social, 68
versus Kanban, 274 team, 77
master, 60, 269 SMART (specific, measurable, action
roles, 268–269 oriented, realistic, time limited), 135,
300, 465
of Scrums, 284, 287–288
SME (subject matter expert), 62
timeboxing, 271
488 social awareness

social awareness, 68 stakeholder/s, 27, 41, 52, 114

social skill, 68 analysis, 54–55, 341–342, 465
software development business analysis and, 338
adaptive development approach, communication, 55
110–111 push, 55
predictive development approach, verbal, 55
108–109
written, 55
testing, 200–202
engagement, 182–183
solicitation document, 180, 181
assessment matrix, 183–184
RFI (request for information), 180
levels, 183
RFP (request for proposal), 180
identifying, 52–53, 338–340
RFQ (request for quotation), 180–181
land claim, 52
solution
register, 340
capability matrix, 360
requirements, 335
evaluation, 405–406
seeking approval, 359
determine approach, 407–408
types, 53–54
identify who will conduct, 409
Standard for Project Management, The,
performance evaluation, 3, 21, 22, 27, 228. See also PMI
406–407 (Project Management Institute)
performance measurement, start
407–408
-to-finish dependency, 147
performance, 406–407
-to-start dependency, 147
requirements, 335, 398
state diagram, 447
SOW (statement of work), 178, 466
state table, 447
sprint, 112, 267, 465. See also Scrum
status report, 75
backlog, 299
steering committee, 75–76, 466
planning, 270
storming, 79
retrospective, 270
story mapping, 363, 389, 466
review, 270
story point, 235, 305–306, 466
stack scheme, 297
storyboarding, 374
stage
strategy, implementing, 62–63
adaptive project, 229–231
success, celebrating, 85
Close, 237
supply chain, 27
Concept, 231–233
survey, 373, 462
Construct and Deliver, 233–237
sustainability, 34
gate, 99–100, 465
Sutherland, J., Scrum Guide, 268
system interface table, 448
 transition requirements 489

T template
final report, 163–164
T&M (time and materials) contract, project charter, 135–136
179–180, 466 test-driven development, 407, 466
Taiichi, O., 263 testing, 109
tailoring, 130, 131, 132–134, 347, DITL (day-in-the-life), 410
414–415, 422, 467 software, 200–202
aspects of projects that can be theory
tailored, 419–420
Herzerg’s two-factor, 66–67
CT scanner products, 421–422
Maslow’s hierarchy of needs, 65–66
engagement, 421, 455
threat, 190–191, 316–317, 466
process, 420
three-point estimation, 149–150, 466
Talent Triangle®, 59. See also skill/s
throughput, 306, 466
tasks, 466
throwaway prototype, 373
CAPM exam, 4–8
time
needs assessment, 356–357
boxing, 227, 271, 466
team/s, 50
cycle, 306–308, 454
adaptive, culture, 225–227
elapsed, 150–151, 455
adjourning, 80
estimating, 149–151
building, 66, 242–244
lead, 306–307, 458
culture, 77, 84–85, 462
project, 150
decision-making, 69
work, 150, 455
development, 136, 246
tools
forming, 79
quality management
high-performing, 78, 226–227
cause-and-effect diagram,
norming, 79 197–198
performance, 76–77 control chart, 199–200
performing, 79 Pareto analysis, 198–199
project management, 77 walk-throughs, 197
RAM (responsibility assignment state assessment, 359–360
matrix), 83–84
Toyota Production System, 263
storming, 79
traceability, 399–402, 466
T-shaped, 221, 243
tracking
workspace, 318
progress, 301, 318–319
technology, 41
risk, 320
telemedicine app, requirements
transition requirements, 336
elicitation, 375–376
490 transparency

transparency, 85 responding to change, 224

T-shaped teams, 221, 243 working software over com-
Tuckman, B., 79 prehensive documentation,
223–224

U core, 270–271
creating, 26–28, 454
UCL (upper control limit), 200 delivery, 193–194, 425
uncertainty, 10, 51, 312, 467 -driven delivery, 227
ambiguity, 313 earned, 162, 165–166, 204–207, 456
complexity, 313 net present, 362
factors associated with adaptive and planned, 166
predictive approaches, 220 project, 193
opportunity, 315, 316 streaming, 264–267, 286, 467
project, 313–315 variance
reducing, 316 at completion, 203, 467
threats, 316–317 cost, 166, 453
volatility, 313 schedule, 166
unilateral decision, 69 velocity, 304–306, 467
use case diagram, 383–384, 385–386, verbal communication, 55
445 verification, 409
user interface flow, 397, 448 vision statement, 231–232, 241–242
user story, 234, 246–247, 386–390, volatility, 313
467, 446
voting, dot/multi, 297
assigning points, 247–249
epic, 387
story map, 389
W
task backlog, 250 walk-throughs, 197
waste, eliminating, 263
V ways of working skills, 60
WBS (work breakdown structure), 40,
VAC (variance at completion), 203, 467 137–138, 141–144, 467
validation, 409, 467 codes, 142
value/s, 362 construction industry, 164–165
adaptive development process, 142
customer collaboration over work package, 141, 144
contract negotiation, 224
WIP (work in progress), 262, 307, 467
individuals and interactions over
wireframe, 396–397, 448
processes and tools, 223
 XP (Extreme Programming) 491

work
groups, 238
X-Y-Z
milestone, 116–118 XP (Extreme Programming),
package, 141, 144–146, 467 275, 456
in progress, 262, 273, 307 core practices, 275–276
time, 150, 455 roles, 275
workshop, 372 takeaways, 276–277
written communication, 55