Managing Projects With PMBOK 7

Managing Projects With PMBOK 7

Connecting New Principles With Old Standards

James W. Marion and Tracey Richardson

Managing Projects With PMBOK 7:
Connecting New Principles With Old Standards

Copyright © Business Expert Press, LLC, 2023.

Cover design by Charlene Kronstedt

Interior design by Exeter Premedia Services Private Ltd., Chennai, India

All rights reserved. No part of this publication may be reproduced,

stored in a retrieval system, or transmitted in any form or by any
means—electronic, mechanical, photocopy, recording, or any other
except for brief quotations, not to exceed 400 words, without the prior
permission of the publisher.

First published in 2022 by

Business Expert Press, LLC
222 East 46th Street, New York, NY 10017
www.businessexpertpress.com

ISBN-13: 978-1-63742-298-4 (hardback)

ISBN-13: 978-1-63742-294-6 (paperback)
ISBN-13: 978-1-63742-295-3 (e-book)

Business Expert Press Portfolio and Project Management Collection

First edition: 2022

10 9 8 7 6 5 4 3 2 1
 Description
The Guide to the Project Management Body of Knowledge (PMBOK)
published by the Project Management Institute provides a roadmap of
performance domains designed to support project managers in all phases
of project management. The sheer number of models, methods, and arti-
facts may leave project managers in a quandary about where to start and
how to apply the many components. This book provides a simple explan-
atory guide for the layman that clarifies the “big picture” of the PMBOK.

Keywords
project management; PMBOK; uncertainty; project performance domains
 Contents
Chapter 1 Introduction��������������������������������������������������������������������1
Chapter 2 Stakeholder Performance Domain���������������������������������25
Chapter 3 Team Performance Domain�������������������������������������������31
Chapter 4 Development Approach and the
Life Cycle Performance Domain������������������������������������45
Chapter 5 Planning Performance Domain��������������������������������������49
Chapter 6 Project Work Performance Domain�����������������������������137
Chapter 7 Delivery Performance Domain������������������������������������165
Chapter 8 Measurement Performance Domain����������������������������195
Chapter 9 Uncertainty Performance Domain�������������������������������225
Chapter 10 Tailoring����������������������������������������������������������������������239

References�������������������������������������������������������������������������������������������245
About the Authors�������������������������������������������������������������������������������247
Index�������������������������������������������������������������������������������������������������249
 CHAPTER 1

♥Introduction
The seventh edition of the Guide to the Project Management Body of
Knowledge (PMBOK) (PMBOK  Guide 2021) ushered in a new era for
the practice of project management. The traditional focus of the PMBOK
was on processes and process guidance: project manager’s approach to
work—be it project phases or entire projects using the sequential elements
of the five process groups (initiating, planning, executing, monitoring,
and controlling, and closing). Also, traditionally, the ten knowledge areas
included guidance for creating and managing all the subplans which together
formed an overall project plan. PMBOK 7 approaches the challenges
associated with managing projects with a different way of thinking. The
first noticeable change is the integration of The Project Management
Standard (2021) into the PMBOK. Instead of dictating processes to
follow, The Project Management Standard emphasizes eleven principles
to consider when managing projects: Stewardship, Team, Stakeholders,
Value, Systems Thinking, Leadership, Tailoring, Quality, Complexity,
Risk, Adaptability and Resiliency, and Change. PMBOK 7 includes eight
performance domains that describe elements which are considered essential
for successfully managing a project. The principles are said to guide the
behavior of project managers as they carry out the project performance
domains. The eight performance domains are Stakeholders, Team,
Development Approach and Life Cycle, Planning, Project Work, Delivery,
Measurement, and Uncertainty. Finally, in addition to performance
domains, PMBOK 7 provides an encyclopedic list of “Models, Methods,
and Artifacts” that are employed to manage projects and manage within the
given performance domains.
The advantage to taking a “principle” versus a “process” approach is
that The Project Management Standard and The PMBOK Guide are no
longer prescriptive in its guidance. This is considered important in an
era where many methodologies and approaches to managing projects
2 Managing Projects With PMBOK 7

are employed. In this way, projects managers can feel free to draw
upon guidance that works for them as they tailor project management
to their individual organization and culture. On the other hand, there
is a disadvantage to this approach. While it may be beneficial to learn
“about” project management and draw upon general principles to
inform practice—the novice may lack a clear understanding about where
to begin and exactly what to do to get started. Learning about project
management is not the same as being provided specific guidance on how
to do it and where to begin. Regardless of principle and the specific way
in which organizations carry out projects, the work itself needs to get
done—and the work typically encountered in projects was effectively
modeling in the sixth edition of the PMBOK.
The PMI “Standards +” (www.pmi.org/pmbok-guide-standards/
standards-plus) initiative helps in this regard by maintaining a database of
standards, guides, articles, and general advice that is accessible by project
managers. While useful though—it is challenging to form a big picture view
regarding how the practices of previous standards relate to the new material.
The purpose of this text is to clarify how to manage projects by drawing
upon both PMBOK 7 as well as previously published process guidance.
When used together in a big picture view, project managers can not only
grasp foundational concepts, but can also follow step-by-step guidance for
managing projects.

Where to Begin? The Principles

Previous editions of the PMBOK begin with a discussion of strategy and
the context of project management. The apparent main point of the new
material is to consider how the culture, processes, strategy, and structure
relate to what projects are selected for resulting planning and execution.
The principles of The Project Management Standard are illustrated by
combining them within a framework that includes the PMBOK 6 pro-
cess framework and the project performance domains. In Figure 1.1, the
principles are highlighted while the performance domains are greyed out
for ease of viewing. From inspection of the comprehensive framework,
the principles succinctly depict the strategic view of project management
that is captured more generally in the early chapters of PMBOK 6. The
 ♥Introduction 3

Stewardship
Value
System for value delivery
Systems thinking
Leadership
Tailoring Adaptability Resiliency Change Complexity
Development approach/life cycle
Initiating Planning Executing M&C Closing
Integration Planning Project work Measurement Delivery
Scope Planning
Schedule Planning
Cost Planning
Quality Quality Planning
Resources Team Planning Team
Communications Planning
Risk Risk Planning Uncertainty
Procurement Planning
Stakeholders Stakeholders Planning Stakeholders
Methods/models/artifacts

Figure 1.1  The principles

principles can be organized into three sections and committed to memory

using mnemonic devices so that the principles are always on the minds of
the project managers and team members assigned to projects.

Principles Section #1—“ARCC”: Adaptability,

Resiliency, Change, and Complexity
The fundamental context of the principles is on the “system for value deliv-
ery.” Projects cost money and are organized to produce specific deliverables.
The deliverables are expected to add value by advancing the strategy and
competitive advantage of the company. Projects add value—and the sys-
tems and frameworks supporting project management are in effect a sys-
tem for delivering value. What produces value however is a moving target.
The market can change rapidly. New competitors and standards arise—
and economies and businesses rise and fall. Meeting this challenge requires
that companies be “fleet of foot” and very nimble. This is where the adapt-
ability, resiliency, change, and complexity guidance associated with The
Project Management Standard principles’ guidance comes into play. The
governance and oversight of project management thereby requires focus
on producing even in the case of dramatic change. Furthermore, projects
4 Managing Projects With PMBOK 7

themselves may be chartered to develop a strategy or to carry our strategic

initiatives and change management efforts. The value delivery system of
project management is therefore a mechanism for meeting the challenge of
change and responding to it in an effective manner.

Principles Section #2—“SVSL”: Stewardship, Value,

Systems Thinking, and Leadership
Individuals assigned to manage projects are in many ways like mini-
general managers or CEOs. They lead project teams and influence and
engage stakeholders. Ideally, when such leaders act, they understand how
the pieces of the project fit together and can trace out causal linkages
between effort and result as well as risk and impact. Project managers
are expected to take ownership of the endeavor and stay focused on the
goal—even when the path is difficult. The Project Management Institute’s
(PMI) “Talent Triangle,” Figure 1.2, depicts these qualities in the ideal
characteristics of a project manager.
The triangle includes Business Acumen, Power Skills, and Ways of
Working. The first two legs of the triangle that incorporate strategic and
leadership abilities are a key focus of project management principles. This
rings true as over the last 50 years, project management has emerged as a
formal profession and the importance of business, strategic, and soft skills
has risen to prominence.
ing
ork
fw

Pow
ys o

er s
Wa

kill
s

Business acumen
TM
 Business acumen Ways of working Power skills
Benefits management and Agile and hyper agile Leadership
realization Hybrid Active listening
Business models and Design thinking Communication
structures
Transformation Adaptability
Competitive analysis
Data gathering and modeling Brainstorming
Customer relationships and
satisfaction Earned value management Coaching and mentoring
Industry domain knowledge Governance Conflict manegement
Legal and regulatory Performance management Emotional intelligence
compliance Requirements management Influencing
Market awareness and traceability Interpersonal skills
Function-specific knowledge Risk manegement Negotiation
Strategic planning, analysis, Schedule manegement Problem solving
alignment Scope manegement Teamvvork
Time, budget and cost
estimation

Figure 1.2  PMI talent triangle

♥Introduction 5

Source: https://www.pmi.org/-/media/pmi/documents/public/pdf/certifications/talent-triangle-flyer.pdf
6 Managing Projects With PMBOK 7

Principles Section #3—“QTRS”: Quality,

Team, Risk, and Stakeholders
Ultimately, the project management principles return from the strategic
and leadership arena to more of the nuts and bolts of project management.
Project management as a system of value delivery pays close attention to
the performance of the deliverables it produces as it seeks to satisfy cli-
ent requirements. Principles from quality management inform this activ-
ity. These principles are understood by project managers—but, it is not
the project manager in isolation that performs the work of the project.
Projects are systems that involve stakeholders—be they team members,
clients, suppliers, or members of the industry and community. Finally,
projects always operate in an environment of uncertainty. Estimates and
plans are developed—but things happen—and often initial assumptions
do not pan out. Risk management principles inform project managers as
they navigate through uncertainty and carefully manage value delivery
through to completion.

Tying Principles to Actual Project Work

The project management principles associated with value delivery are

compelling. However, they are not necessarily actionable until these prin-
ciples are married to the initial strategic steps of project management.
Where does strategy reside in traditional project management? Typi-
cally, it resides in the activities of portfolio management and governance.
These principles are put into practice prior to the start of the project
and the result of which is the choice of project that the organization will
undertake.

Project Management—And Its Evolution: Why Study

Previous Versions of the PMBOK?
Completing a project plan as described by the PMI is different today than
it was 10 to 20 years ago. The processes associated with the development
of a project plan have been updated over the years since the first PMBOK
guide was published. Understanding how to develop a project plan today
 ♥Introduction 7

requires an understanding of the current PMBOK framework. In 2017, the

PMI published PMBOK 6. When encountering this process framework
for the first time, the 49 different processes, including five process groups
in 10 knowledge areas, will likely seem difficult to wade through and apply
at first. However, if the rationale behind the framework as well as how the
framework has evolved over time is better understood, developing a project
plan using the PMBOK will likely make more sense. This is made espe-
cially clear when the current PMBOK is compared to the fourth edition
launched 25 years ago. Examining the PMBOK  from the fourth through
sixth edition will aid in understanding what the framework does, and why
it does what it does as well as its underlying intent so you can best under-
stand the leap to the seventh edition and the usefulness of the Standards+.

What Is It?
What is the project management framework anyway? It is a process-ori-
ented series of guidelines for project managers. One of the reasons that
the PMBOK framework started out being process oriented is that the
management of projects occurs outside the normal ebb and flow of ongo-
ing operations. It therefore requires policies, procedures, and processes
to govern it. The fact that projects are different than ongoing operations
becomes obvious when examining the framework beginning at the top
left-hand corner of the framework (Table 1.1) at the intersection of the
“Project Integration Knowledge Area” and the “Initiating Process Group.”
Integration implies “summing up” or tying things together—and this is
exactly what is done when the project charter is created. The project char-
ter authorizes the project using formal documentation that advises all
project team members (as well as all who have an interest in the outcome
of the project) of the authority granted to the project team to carry out its
mission. In an ongoing operation, the head of the department may ver-
bally assign work to individuals or teams without a documented charter.
The department and hierarchy of leadership are already authorized to do
their ongoing work—so only in the project context is such an authoriza-
tion truly necessary. The project team once assigned may draw people from
different functional groups and interact with different departments—and
8 Managing Projects With PMBOK 7

the charter enables this. This one simple example helps explain the need
for a project management framework that governs the sequence of events
from starting a project, planning it, carrying it out, finishing it, as well
as listing the subject areas project managers need to know within these
processes. The framework is not only useful—it is a necessity for planning
and executing project work.

The Starting Point for Using Project Management

The project charter example implicitly illustrates how to go about using
the framework. Rather than thinking of it as “49 processes,” think in
terms of the five process groups. Every project must be started, planned,
carried out, followed-through, and finished. This commonsense series
of steps for completing any type of work is captured in the five process
groups that are labeled “Initiating, Planning, Executing, Monitoring
and Controlling, and Closing.” The five process groups did not change
between the fourth and sixth editions of the PMBOK (Table 1.2). But
the processes that exist in the sixth edition within each of the process
groups have evolved considerably. The process changes are found within
the knowledge areas of the PMBOK 6.
Knowledge areas are those specific skills, knowledge, or domain
expertise that must be applied in the process groups to get the work of
the project accomplished. While the process groups clarify the order of
events or the steps in the process, the knowledge areas provide a content
view—or what needs to be done at each step. The flow of PMBOK pro-
cesses remains very similar when comparing PMBOK 5 and 6; but as the
PMBOK has evolved, more direction is provided in knowledge areas and,
in some cases, additional knowledge areas are given to support project
activities. This is a consequence of the evolution of the field of project
management over time. To fully understand the framework, it helps to
understand what came before. The examination of the sixth edition there-
fore begins with understanding what changed between versions.
Table 1.1  The sixth edition of the PMBOK
Project Management Process Groups
Knowledge Initiating Planning Process Executing Monitoring and Closing
Areas Process Group Process Group Controlling Process Process
Group Group Group
Project Integration Develop Project Develop Project Management Direct and Manage Monitor and Control Project Work Close Project or
Management Charter Plan Project Work Perform Integrated Change Control Phase
Project Scope Plan Scope Management Collect Validate Scope
Management Requirements Control Scope
Define Scope
Create WBS
Project Schedule Plan Schedule Management Control Schedule
Management Define Activities
Sequence Activities
Estimate Activity Durations
Develop Schedule
Project Cost Plan Cost Management Estimate Control Costs
Management Costs
Determine Budget
Project Quality Plan Quality Management Manage Quality Control Quality
Management
Project Human Plan Resource Management Acquire Resources Control Resources
Resource Management Estimate Activity Resources Develop Team
♥Introduction 9

Manage Team

(Continued)
 10

Table 1.1  (Continued)

Project Management Process Groups
Knowledge Initiating Planning Process Executing Monitoring and Closing
Areas Process Group Process Group Controlling Process Process
Group Group Group
Project Plan Communications Manage Monitor
Communications Management Communications Communications
Management
Project Risk Plan Risk Management Identify Monitor Risks
Management Risks
Perform Qualitative Risk
Managing Projects With PMBOK 7

Analysis
Plan Risk Responses
Project Procurement Plan Procurement Conduct Control Procurements
Management Management Procurements

Project Stakeholder Identify Plan Stakeholder Manage Stakeholder Monitor Stakeholder

Management Stakeholders Engagement Engagement Engagement
Table 1.2  The fourth edition of the PMBOK
Project Management Process Groups
Knowledge Initiating Planning Process Executing Process Monitoring Closing
Areas Process Group Group and Controlling Process
group Process Group
Group
Project Integration Develop Develop Project Management Direct and Manage Monitor and Control Close Project
Management Project Plan Project Work Project Work Phase
Charter Perform
Integrated Change Control
Project Scope Collect Requirements Validate Scope
Management Define Scope Control Scope
Create WBS
Project Time Define Activities Control Schedule
Management Sequence Activities
Estimate Activity Durations
Develop Schedule
Project Cost Estimate Costs Control Costs
Management Determine Budget
Project Quality Plan Quality Management Perform Quality Perform Quality Control
Management Assurance
Project Develop Human Resource Acquire Project Team
Human Resource Plan Develop Project Team
♥Introduction 11

Management Manage Project Team

(Continued)
Table 1.2  (Continued)
12

Project Management Process Groups

Knowledge Initiating Planning Process Executing Process Monitoring Closing
Areas Process Group Group and Controlling Process
group Process Group
Group
Project Communi- Identify Plan Communications Distribute Information Report Performance
cations Stakeholders Management Manage Stakeholder
Management Expectations
Project Risk Plan Risk Management Monitor and Control Risks
Management Identify Risks
Perform Qualitative Risk
Analysis
Managing Projects With PMBOK 7

Plan Risk Responses

Project Procurement Plan Procurement Conduct Procurements Administer Close
Management Management Procurements Procurements
 ♥Introduction 13

Why Study Previous Versions of the PMBOK?

The fifth edition of the PMBOK is where a leap forward in terms of
changes and increased structure is observed. What then changed between
versions four and five of the PMBOK? There is a simple answer and then
a complicated answer.
For the simple answer, there was an additional knowledge area added
to the fifth edition (Table 1.3). Although the five process groups are the
same, the communications knowledge area was divided into two: one
knowledge area for project communications management, and then one
referred to as project stakeholder management.
Why were project communications and project stakeholder ­management
separated? Originally, communications and stakeholder management and
engagement were closely related and therefore treated as a single aspect of
managing a project. Because of the apparent similarity and the thinking
at the time, the knowledge areas were therefore combined. However, in
the PMBOK 5, it became evident from experience that communication
is quite a bit different from the identification and in-depth engagement
and management of stakeholders. Because of the complexity and level of
effort required, it was determined that stakeholder management deserved
its own sequence of processes to support the activity. It was therefore sepa-
rated out from communications management for emphasis and attention
to detail required in collaborating with managing the stakeholders who
are always a critical part of managing a project.
The addition of the stakeholder management knowledge area within
PMBOK 5 added five additional processes—bringing the total number of
processes from 42 to 47. This number seems significant and not a simple
matter for a project manager to keep up with. However, it is interesting
to note that it is the planning process group where most project manage-
ment processes—including many of the new processes—are found. It is
within this process group where additional changes were made to the fifth
edition. Approaching the understanding of the new processes in a step-
by-step manner using the process groups as a guide can aid in making the
framework more manageable and easier to digest.
 14

Table 1.3  The fifth edition of the PMBOK

Project Management Process Groups
Knowledge Initiating Planning Process Executing Monitoring and Closing
Areas Process group Group Process Controlling Process
Group Process Group Group
Project Integration Develop Project Develop Project Direct and Manage Monitor and Control Close Project
Management Charter Management Plan Project Work Project Work Phase
Perform
Integrated Change Control
Project Scope Collect Requirements Verify Scope
Management Define Scope Control Scope
Managing Projects With PMBOK 7

Create WBS
Project Time Define Activities Control Schedule
Management Sequence Activities
Estimate Activity Durations
Develop Schedule
Project Cost Estimate Costs Control Costs
Management Determine Budget
Project Quality Plan Quality Management Perform Quality Perform Quality Control
Management Assurance
 Project Management Process Groups
Knowledge Initiating Planning Process Planning Monitoring and Closing
Areas Process group Group Process Group Controlling Process
Process Group Group
Project Human Develop Human Resource Acquire Project
Resource Management Plan Team
Develop Project
Team
Manage Project
Team
Project Communica- Plan Communications Distribute Informa- Report Performance
tions Management Management tion
Manage Stakeholder
Expectations
Project Risk Plan Risk Management Monitor and Control Risks
Management Identify Risks
Perform Qualitative Risk
Analysis
Plan Risk Responses
Project Procurement Plan Procurement Conduct Procure- Administer Close Procurements
Management Management ments Procurements
♥Introduction 15
16 Managing Projects With PMBOK 7

Changes to Planning in PMBOK 5

“Plan first, then do” is a central principle with project management prac-
tice. Most knowledge areas from PMBOK 4 and earlier did focus on
planning prior to doing. But—noticing in the planning process group in
PMBOK 4 (Table 1.2), starting from the top with the project integration
management knowledge area and moving from top to bottom—it can be
observed that some knowledge areas begin with a plan, whereas others
do not. For example, quality begins with plan quality, communications
begin with plan communications, and risk begins with plan risk man-
agement; however, others do not. Scope, time, and cost—considered the
most important aspects of managing a project since they relate to “How
much?” and “When?” and “What?” is to be delivered—do not begin with
a “plan” step. There is therefore an inconsistency observed in the plan-
ning process group with respect to several important knowledge areas.
In the PMBOK 5 (Table 1.3), it can be noticed now that scope, time,
cost, quality, human resources, communications, and risk begin with the
development of a plan. What this suggests is that every process in project
management is going to be approached in the same way. Project managers
can therefore follow a rhythm of planning what is going to be done first
before doing it. Once the plan for the activities is done, the project man-
ager follows up to confirm its completion.

A Plan for a Plan?

Beginning each knowledge area with a plan begs the question, “The
planning process group inherently involves plan—so what in addition
needs to be planned at the beginning of each knowledge area within the
planning process group?” The rationale behind beginning with a plan in
PMBOK 5 is that it is important for project manager to clearly think
through and lay out the basic approach to managing each knowledge
area. For example, scope, schedule, cost, quality, resource, communica-
tions, procurement, and stakeholder management begin with a plan as
outlined in Table 1.4.
In short, PMBOK 5 now guides project managers to determine
the basic approach or strategy to be taken as they carry out each of the
 ♥Introduction 17

Table 1.4  Each knowledge area begins with a “plan”

Planning Process Group Initial
Knowledge Area
Activity
Project Scope Management Plan Scope Management
Project Time Management Plan Schedule Management
Project Cost Management Plan Cost Management
Project Quality Management Plan Quality Management
Project Human Resource Management Plan Human Resource Management
Project Communications Management Plan Communications Management
Project Risk Management Plan Risk Management
Project Procurement Management Plan Procurement Management
Project Stakeholder Management Plan Stakeholder Management

knowledge areas found in the planning process group. To give an exam-

ple, the direction “Plan scope management” does not infer the actual
planning and managing scope—but rather, how scope management will
be approached. This is a strategy—or a “plan for a plan.” This encourages
project managers to think before doing and avoid ad hoc actions and
decision making. This process-focused approach to getting work done is a
mark of mature, disciplined organizations.
As previously mentioned, the stakeholder management knowledge
area was separated from communications management. With this change
in knowledge areas, more process support and details on stakeholder man-
agement including management engagement and controlling stakeholder
engagement are now found in the newly created stakeholder management
group. These supporting processes go far beyond the communications knowl-
edge area. For example, presenting reports, holding meetings, and carrying
out activities other than simple communication are needed to keep stake-
holders involved in the project and be supportive. The project stakeholder
management knowledge area therefore illustrates the degree to which project
teams collaborate with stakeholders while carrying out the work of the project.

Complex Changes in PMBOK 5

There are additional and more complicated differences between PMBOK
4 and PMBOK 5 beyond planning processes and the addition of a single
18 Managing Projects With PMBOK 7

knowledge area. One of these differences is involved in determining how

the project ensures that it is meeting the requirements of the customer.
PMBOK 4 accomplishes this through the verification of scope. This
means that the scope, or WHAT the project delivers, is checked against
the project specifications. In verification, it is assumed that the project
specifications for the customer deliverables are correct. Verification under
this scheme is an indirect method of confirming that the project deliv-
erables meet the requirements of the client. The PMBOK 5 uses scope
validation instead of verification.
What is the difference and why is this new term used? While veri-
fication is used to confirm that the deliverables meet the specifications,
validation ensures that the specification itself is correct. This is a stronger
form of confirming the project scope. To clarify the difference between
the two terms, it could be argued that validation is equated to “doing
the right things” whereas verification equates to “doing things right.”
In PMBOK 4, the focus on scope was on verification, or “doing things
right.” In PMBOK 5, it is proposed that validation or “doing the right
thing” is more important in terms of process emphasis. Put another way,
it does no good to simply focus on producing deliverables that match the
specifications developed by the project. Instead, it is more important that
the project specification matches what the client wanted in the first place.
This is validation and it is found in the scope management knowledge
area beginning with PMBOK 5.

Consistency in Process Flow

The changes to the planning process group have consistency with other
fields within operations management. For example, Deming’s plan, do,
check, and act cycle is closely mirrored in the PMBOK as initiate, plan,
execute, control, and close. The idea being expressed is to develop a con-
sistent management rhythm and do the same things in the same way
each time (Table 1.5). When processes are approached in the same way
each time, the steps are not forgotten or left out. It is important in “the
thick of battle” in the midst of a project when things get difficult to
have a process flow that, to the project manager, may act as an “internal
compass.”
 ♥Introduction 19

Table 1.5  The Deming cycle and the process groups

Plan Do Check Act
Initiate/plan Execute Control Close

The DIKW Model

PMBOK 5 provides a model for managing data produced by the project.
Data that comes from managing work and collecting information on the
progress of project work is used for analysis in project monitoring and
control. How data becomes information and knowledge after the analysis
of such data is described in the data model introduced in the PMBOK 5.
This model is known as the DIKW model, or data, information, knowl-
edge, and wisdom model (Figure 1.3). This model illustrates that data
becomes information when work is applied to it. Once the information
is used and incorporated repeatedly in projects, it becomes knowledge.
Finally, the application and refinement of knowledge over time eventu-
ally becomes wisdom. This model sets the stage for managing knowledge
within a project, capturing the data that the project produces, and then
refining it, applying it in future projects, storing it, and retaining it. The
introduction and clarification of the DIKW model led to the incorpora-
tion of knowledge management in the subsequent PMBOK 6.

The DIKW model

Data Information Knowledge Wisdom

Work Effort Practice

Figure 1.3  The DIKW model

20 Managing Projects With PMBOK 7

Table 1.6  Planning as the largest process group

Process Group Processes Percentage (%)
Initiating 2 4.08
Planning 24 48.98
Executing 10 20.41
Monitoring and Controlling 12 24.49
Closing 1 2.04
Total 49 100

PMBOK 6 and the Planning Process Group

A simple count of processes within the PMBOK 6 illustrates that the plann­‑
ing process group includes more processes than any other (Table 1.6).
This is followed by monitoring and controlling, executing, and finally
initiating and closing.
When PMBOK 5 changed over to PMBOK 6 in 2017, several changes
were made to the planning process group. The changes included some
changes in nomenclature to reflect more accurately what was being man-
aged. Instead of referring to “time,” the process group previously labeled
as “Project Time Management” is now referred to as “Project Schedule
Management.” This makes sense as, although time is certainly involved,
what results from these activities within this knowledge area within the
project planning process group is a schedule. Further, the estimation of
activity resources process is moved from “Project Schedule Management”
to “Project Resource Management.” Although resources and resource
constraints impact a schedule, the activities of estimating and planning
resources are a natural fit within the newly named “Project Resource Man-
agement” knowledge area. Why the change from “Human Resources” to
“Resources”? Because resources used on a project do not have to be human
resources. Resources could be machines, equipment, and even funding.

PMBOK 6 and the Executing Process Group

The executing process group in PMBOK 6 places formal emphasis on knowl-
edge management. This is the first time that knowledge management has
 ♥Introduction 21

appeared within the PMBOK framework. Knowledge in the context of a proj-

ect involves the retention of lessons learned in such a way that it is organized and
made available for use in future projects. While lessons learned have appeared
within earlier versions of the PMBOK, knowledge management infers a more
active development and application of project lessons learned. Note that the
DIKW model infers that work must be performed on data to create knowl-
edge. The creation and management of knowledge developed, suggested by
the new “Manage Project Knowledge” processes, assumes the transition of data
through information and knowledge and uses the DIKW model as its foun-
dation. Notably, these are placed within the executing process group so that
emphasis on lessons learned is placed throughout the project while the work of
the project is getting done and problems are encountered and solved.

Risk And Quality Processes

The executing process group has also been expanded in PMBOK 6 to
include additional processes in risk and quality. Quality is now managed
in the executing process group. Quality management contrasts with “Per-
form Quality Assurance” as given in PMBOK 5. Managing the quality
of project deliverables is now considered a more all-encompassing effort
that goes beyond the narrower focus on quality assurance alone. Finally,
an additional process is added to the project risk management knowledge
area within PMBOK 6. The PMBOK 5 emphasized risk identification,
assessment, and the planning of risk responses. PMBOK 6 includes the
“Implement Risk Responses” process that supports escalating and man-
aging risks that become issues. This process guidance for risks adds exe-
cution focus beyond the heavy emphasis on risk planning observed in
both PMBOK 5 and 6. This is a bit of a “gray area” in risk management.
Technically, when a risk is realized (i.e., occurs), then it is no longer a
risk—but an issue. Despite this technicality, the resulting issues linked to
risks will naturally map to the risk response plans.

PMBOK 6 Tools and Techniques Summary

PMBOK 6 includes a comprehensive listing of tools and techniques that
are mapped to each of the knowledge areas. This mapping of 132 tools and
22 Managing Projects With PMBOK 7

techniques is illustrated in a series of tables located in Appendix X6 of the

sixth edition of the PMBOK. This reference tool allows project managers
to briefly see the tools and processes associated with each knowledge area.
Project managers are advised to bookmark this comprehensive reference
when dealing with challenging situations in which unique approaches
may be required. Further, this final toolset summary can act as an index
to save time in locating the right tool or process when needed. Project
teams, even after significant exposure to the PMBOK framework through
training and application, can still at times become a bit overwhelmed by
project events. When in doubt and need some immediate project advice,
jump to Appendix X6.

PMBOK 6 and Agile

PMBOK 6 emphasizes agile methodologies throughout. The sixth edition
combines both project management and agile guidance within a single
publication. The reason for this is that agile is becoming increasingly uti-
lized throughout industry. The idea behind agile is to produce tangible
deliverables quickly that the customers can evaluate, and break larger
projects into smaller pieces, so that the larger project deliverables may
be built up using an iterative sequence of smaller deliverable subprojects
or “sprints.” Agile is therefore focused on simplifying processes, moving
quickly to produce tangible outcomes, and breaking larger projects into
smaller pieces. This methodology is become more widely used beyond
its origins in software development. Agile methods are incorporated
throughout PMBOK 6 to give better visibility to project managers that
this is an important way that projects are being managed today. Finally,
it bears remembering that the process groups may be applied not only to
the overall project but also to project subdeliverables and any complex
deliverables. The process groups may be used iteratively and therefore fit
well with the agile methodology.
What is the difference between Agile methods and traditional project
management processes? To begin with, it is important to recognize that
Agile is a methodology born out of software development processes.
In software development, requirements often change quickly. Further,
when traditional project management methods are used, the result of
 ♥Introduction 23

the software development is not obvious until the very end. For this
reason, it is not uncommon to end up with a final “big bang” software
integration that does not initially work and is riddled with significant
defects. By way of contrast, Agile methodology focuses on completing a
project in small increments that are characterized by tangible deliverables
that the client can evaluate. One of the benefits of Agile is the ability to
incorporate changes in requirements and to react to technical difficulties
and scope changes as they arise. Further, progress measurement is
considerably improved when the project produces deliverables along the
road to completion. Agile represents a significant change in culture. Its
very name evokes the ability to move quickly and flexibly with minimal
process overhead. The inclusion of Agile methods in the PMBOK
reflects the significant incorporation and popularity of this methodology.
Project managers are advised to be aware of Agile nomenclature and to
understand its fundamental operating principles. Finally, note that no
matter what overall processes are employed, they all must be initiated,
planned, executed, monitored, and controlled, and closed.
 Index

acceptable duration, 100–101 communications

acceptance criteria, 153–154 digital vs. analog, 242–244
activity list, 71–72 elements of, 163
Activity on Node (AON) method, and project plan, 156–157
69–71 competitive advantage, 166
activity precedence, 72 compounding, 173
actual cost (AC), 214 conflict, 41–42
adaptability, resiliency, change, and healthy, 42–43
complexity (ARCC), 3–4 conflict resolution, 43, 112, 114, 116,
affinity diagram, 187 117, 119
agile, 22–23 consistency, 18–19
alignment, 168 constraints, 52
analogies, 57 contract negotiation, 152–153
authorization signatures, 52 contracts and risk, 154–155
avoid strategy, 236–237 contract scope, 153–154
control charts, 186
backward pass, 76–79, 82, 83, 86, 87, core team, 52
121, 135 cost parameters, 52
balanced matrix, 38 cost performance index (CPI), 216
balance of power, 35–36 cost-plus contract, 154–155
Bayesian analysis, 199, 233, 235–236 costs, 122
Bayes’ theorem, 231–234 call center project, 125–128
bottleneck, 105, 110, 111, 113, 117 capital, 123
bottom-up approach, 55–56 direct and variable, 122–123
brainstorming, 26, 60, 187, 199, 205, direct fixed, 124
206, 226, 228, 231 indirect, 124
budget plot, 129 with project resources, 125
business case/rationale, 52 crashing, 120
crash point, 120
call center project, 71–74, 94–95, 97, critical chain, 111–115
99, 102, 105, 111, 125–128 Critical Chain Project Management
“Can we do this?”, 144 (CCPM), 117
capability, 144 critical path, 79–81
Capability Maturity Model (CMM), Critical Path Method (CPM), 69,
150 71–74, 81–86, 95, 104, 105,
cause-and-effect diagram, 184 121, 136
check sheets, 184–185 cross-functional teams, 32–34, 36, 42
Chief Financial Officer (CFO), 175
closing procurements, 155–156 deliverables, 62–63
coffee-brewing project, 66–69, 72 Deming cycle, 18–19
comments/notes, 52 digital vs. analog, 242–244
250 Index

DIKW model, 19–21 identify stakeholders, 26

discounting, 172, 173, 178 incremental development approach,
46–47
earned value (EV), 214 integration, 180–182
controlling, 219–220 interest ranking, 26
curves, 216, 217 Internal Rate of Return (IRR), 179
indexes, 216 interrelationship diagraph, 188
metrics, 218–219 interval numbers, 230
and progress reporting, 212–214
variances, 215 lawnmowing project, 138–139
work packages, 214–215 learning curve, 57–59
Earned Value Management (EVM), legacy process framework, 240–241
129 leveling resources, 141–142
engagement, 29–30 lifecycle costs, 146
Enterprise Environmental Factors
(EEF), 239 McGregor, D., 40–41
estimates, 54 make or buy analysis, 144, 145
executing process group, 20–21 make vs. buy equation, 145–146
existing location, 223 management by walking around
expertise, 56 (MBWA), 220–221
manage stakeholder engagement, 211
fast-tracking, 109 marble distribution normal curve, 90
50 percent rule, 94, 96, 99 Maslow, A. H., 40–41
financial selection techniques, 180 matrix diagrams, 189
first time, 145–146 matrix organizations, 35–38
“5 W’s,” communications plan and, maturity models, 150
156–157 mitigate, avoid, retain, and transfer
“how,” 160–162 (MART), 210, 236–238
“what,” 157–158 mitigation strategy, 236
“when,” 158–160 Monte Carlo analysis, 103–105, 231
“where,” 160, 161 motivation, 40–41
“why,” 162–163
flowchart, 184 negative NPV, 177
Forward and Backward pass Net Present Value (NPV), 176–179
algorithm, 69 network diagrams, 69–76, 81–83, 86,
forward pass, 74–76, 86, 87, 121, 135 131, 188–189
fully-loaded costs, 202 new location, 223
functional decision making, 32 95 percent probability, 100–101
functional organization, 32–36, 39, nominal numbers, 230
51, 142, 143 normal curve, 89–91, 93, 94

Gantt chart, 129–133 office relocation project plan,

Gersick, C., 44 195–196
closing phase, 221–223
Herzberg, F., 40–41 communications plan, 204
hierarchical, 62 cost plan, 202
histograms, 185 deployment phase, 207–208
 Index 251

Design Phase, 196–200 principles, 2–3, 68

duration, 200–206 prioritization matrices, 188
earned value (See earned value) probability
MBWA, 220–221 approximating, 92–94
performance measurement, normal curve and, 89–91
211–212 units of time and, 91
projections, 217–218 probability-impact matrix, 229
project procurement plan, 206 problem-solving process, 190–192
reeling in, 216–217 Process Decision Program Chart
schedule, 207 (PDPC), 187–188
stakeholder management, 206 process maturity, 150
tribal knowledge, 209–211 product approval committee (PAC),
work packages, 214–215 192
1.65 value, 101–102 Program Evaluation and Review
ordinal numbers, 230 Technique (PERT) method,
Organizational Process Assets, 239 82–84, 121, 131, 136, 201,
Organizational Project Management 231–233
Maturity Model (OPM3), benefits of, 89
150 call center schedule scenario, 94–95
outsourcing, 39–40 critical path, 88
quote, 146 estimating process, 84–86
network diagram, 86–89, 106
parametric estimation, 57 practical use, 99–101
Pareto diagrams, 185 probability, 89–91
payback analysis, 174 sequence, 102–103
peak resources, 140–141 vs. Monte Carlo analysis, 103–105
performance track record, 151 project activities, 199–200
plan for a plan approach, 16–17, 60 project charter, 51–53, 142, 181,
planned value (PV), 129, 214 195–196
planning, 54 project communication management,
process group, 20 203–204, 210
resources, 138–140, 142–143 project cost management, 201–202
PMBOK 5, 13–15, 19–21 project crashing, 120, 220
complex changes in, 17–18 project critical path, 201
planning in, 16–17 project deliverables, 65
risk and quality, 21 project duration, 200–201
PMBOK 6, 2, 8–10, 60, 65, 191, project life cycle, 45–46, 191
207, 239, 240 project management, 1–4, 6–16, 22,
and agile, 22–23 31, 36, 46, 58, 59, 69, 70,
and executing process group, 20–21 82, 91, 92, 97, 103–105, 113,
and planning process group, 20 117, 122, 145, 150, 158–160,
risk and quality, 21 180, 183, 185–190, 208, 210,
tools and techniques, 21–22 221, 225, 226, 240, 242–244
PMI “Standards +”, 2 Project Management Body of
Porter, M., 166 Knowledge (PMBOK), 1, 2,
positive NPV, 176 6–15, 45, 54, 143, 181, 240,
power ranking, 26 241
Precedence Diagramming Method PMBOK 4, 11–12, 16–18
(PDM), 69 PMBOK 7, 1, 2, 60, 239, 240
252 Index

See also PMBOK 5; PMBOK 6 tools, 183–186

project management information quality plan, 192–193
system (PMIS), 158, 161 quality, team, risk, and stakeholders
Project Management Institute (PMI), (QTRS), 6
4, 190–191 quantitative selection tools, 170
Project Management Standard, 1–3
project mean, 95–97 ratio numbers, 230
project opportunity screening, relocation management personnel,
165–166 223
project organization, 38–39 request for information (RFI), 147,
project performance domains, 1, 2, 148
240 request for proposal (RFP), 149
project plan “layer cake,” 181–182 request for quotation (RFQ),
project procurement, 143–144, 205 147–148
project quality management, resource conflict, 116–117
189–190, 202 resource leveling, 141–142
project resource management, 20, resources, 39–40
202–203, 209–210 increasing, 108
project schedule, 65, 66, 82, 84, 86, managing and developing, 40
135 utilizing, 108
implicitly, 134 responsibility assignment matrix
integration, 181–182 (RAM), 203
management, 20, 198–199 retain strategy, 237–238
plan for a plan approach, 60 return on investment (ROI), 175, 176
probability, 94, 96 ripple effect, 111–112
ROM estimate, 49–50 risk
vs. project plan, 207 avoid strategy, 236–237
project scope, 59, 196–197 identification methods, 226–227
in stages, 60–61 mitigation strategy, 236
project selection numbers in, 229–230
questions and analysis techniques, qualitative vs. quantitative,
170–171 228–229
risk and reward, 175–177 register, 228
project stakeholder identification, 196 retain strategy, 237–238
project stakeholder management, simulation, 231
205–206 transfer strategy, 238
project standard deviation, 97 risk breakdown structure (RBS),
projects vs. ongoing operations, 241 226–227
Project Time Management, 20 Rough Order of Magnitude (ROM)
project uncertainty/risk management, estimate, 49–50, 54
204–205, 210–211
Punctuated Equilibrium Model scatter diagrams, 186
(Gersick), 44 schedule delay, 110–111
schedule management plan, 199
qualitative selection tools, 168–170 schedule optimization, 117–121
quality assurance, 187–189 schedule performance index (SPI),
quality management, 182, 209 216
plan outline, 203 schedule precedence impact, 121–122
in projects, 182–183 scope, 51, 59
 Index 253

baseline, 198 transfer strategy, 238

control, 60 transition plan, 222
identification, 60 tree diagrams, 188
management plan, 197 tribal knowledge, 209–211
reduction, 110 Tuckman, B., 43–44
statement, 61–62, 71, 197, 198 two-boss problem, 34–36
“S” curve, 129
second lowest bid, 154 uncertainty, 225
sensitivity, 81, 89 avoidance, 236–237
Seven Quality Control Tools, Bayes’ theorem, 231–234
183–187 elements of, 238
“Should we do this?”, 145–147 mitigation, 236
Six Sigma, 91 numbers, 229–230
68–95–99 rule of thumb, 94 qualitative vs. quantitative risk
slack, 79–81 analysis, 228–229
sponsor, 52 retain strategy, 237–238
stakeholders, 25–26 and risk identification methods,
analysis of, 26–28 226–227
engagement, 29–30 risk planning, 231–233
impact, 28–29 and risks, 226–228, 235–236
management, 30 risk simulation, 231
power-interest grid, 27, 28 transfer, 238
register, 27
visual aids, 234–235
standard deviations, 91–92
Statement of Work (SOW), 51, 61
stewardship, value, systems thinking, variance calculations, 97–99
and leadership (SVSL), 4–5 vendor quality management,
storming, 44 149–150
strategic alignment, 168 vendor selection, 147
strategic positions, strong and weak, visual aids, 234–235
166–167
strategic project selection checklist, weak matrix, 37–38
169–170 Weighted Average Cost of Capital
strong matrix, 37–38 (WACC), 175
supplier financial health, 151–152 weighted project selection checklist,
170
Talent Triangle (PMI), 4–5 work breakdown structure (WBS),
team, 52 62–65, 71, 83, 197–199, 203,
team development life cycle, 43–44 208, 221, 222
time value of money (TVM), work package, 208
171–176 budget reporting, 213
timing parameters, 51
top-down approach, 54–56 zero NPV, 176–177
trade-offs, 57 Z table, 91–93, 100–101