PMBOK®

Guide: Part 1
Current Reality

Mounir A. Ajam
Mounir Ajam

PMBOK® Guide
Part 1 – Current Reality

2
PMBOK® Guide: Part 1 – Current Reality
1st edition
© 2015 Mounir Ajam & bookboon.com
ISBN 978-87-403-1188-4

3
PMBOK® Guide: Part 1 – Current Reality Contents

Contents

Table of Figures 10

This publication 11

Author Message 12

The author and PMI / PMBOK® Guide 13

Section I: Setting the Scene 14

1 Introduction 15
1.1 Standard, framework, methodology? 15
1.2 What should organizations use? 18
1.3 Closing comments 21

ANYTIME, ANYWHERE
LEARNING ABOUT
SAP SOFTWARE HAS
NEVER BEEN EASIER.
SAP Learning Hub – the choice of
when, where, and what to learn

4
PMBOK® Guide: Part 1 – Current Reality Contents

2 PMBOK® Guide Overview 22

2.1 Introduction 22
2.2 The main sections 22
2.3 The project management framework 22
2.4 Process groups 23
2.5 Knowledge areas 23
2.6 The processes 24
2.7 Generic standard document 24

3 PMBOK® Guide: Historical Perspectives 25

3.1 Introduction 25
3.2 History of the guide 25
3.3 Summary and closing remarks 27

4 PMBOK® Guide: Value And Growth 29

4.1 Introduction 29
4.2 Good parts 29
4.3 Terminology 29
4.4 Acceptance 29
4.5 PMI power 30

ANYTIME, ANYWHERE
NO-LIMITS LEARNING
LEVERAGE
LEARNING ABOUT SOCIAL LEARNING,
COLLABORATION,
SAP SOFTWARE HAS QUALITY
CONTENT,
NEVER BEEN AND HANDS-ON
EASIER.
PRACTICE.
SAP Learning Hub – the choice of
when, where, and what to learn

5
PMBOK® Guide: Part 1 – Current Reality Contents

4.6 Number of certificates holders 30

4.7 What is good about the PMBOK® Guide? 30
4.8 Chapter Summary 31

Section II: Gaps and Challenges 32

5 Is The PMBOK® Guide Good Enough? 33

5.1 Introduction 33
5.2 What is the PMBOK® Guide? 33
5.3 So is it enough? 33
5.4 Why is the guide not enough? 34
5.5 Closing remarks 35

6 The Four Myths About The PMBOK® Guide 36

6.1 Introduction 36
6.2 The project management standard 36
6.3 Best practices 38
6.4 Methodology 38
6.5 PMBOK® Guide and the real world 39

THE ANSWER
ANYTIME,
NO-LIMITS ANYWHERE
LEARNING
TO
YOUR LEARNING NEEDS
LEVERAGE
LEARNING ABOUT SOCIAL LEARNING,
GET
SAP QUALITY,
COLLABORATION,
SOFTWARE FLEXIBLE, AND
QUALITY
HAS
ECONOMICAL
CONTENT,
NEVER BEEN AND TRAINING WHEN
HANDS-ON
EASIER.
AND
PRACTICE.WHERE
SAP Learning IT’S
Hub – the choice
when, where, and what to learn
of NEEDED.

6
PMBOK® Guide: Part 1 – Current Reality Contents

7 What Is Missing? 40
7.1 Introduction 40
7.2 A methodology 40
7.3 Organizational system 41
7.4 Tailoring and customization 41
7.5 Project classification 41
7.6 Templates and forms 41
7.7 Project life cycle 41
7.8 Benefits realization 42
7.9 References and External Resources 42
7.10 Suggestion for improvement 42

8 What Is Not Emphasized Enough? 43

8.1 Introduction 43
8.2 Planning 43
8.3 Project change management 44
8.4 Scope management and scope creep 44
8.5 Differentiating changes from variances 44
8.6 Project success 45

MAXIMIZE
ANYTIME,
NO-LIMITS
THE ANSWER ANYWHERE
PRODUCTIVITY
LEARNING
TO
YOUR LEARNING NEEDS
LEVERAGE
LEARNING
HELP YOURABOUT SOCIAL
ENTIRELEARNING,
GET
SAP QUALITY,
COLLABORATION,
ORGANIZATION
SOFTWARE FLEXIBLE, AND
QUALITY
HAS
ECONOMICAL
CONTENT,
BUILD
NEVEREXPERTISE BEEN AND TRAINING WHEN
HANDS-ON
EASIER.
AND
PRACTICE.
IN SAP WHERE
SAP Learning
SOFTWARE. IT’S
Hub – the choice
when, where, and what to learn
of NEEDED.

7
PMBOK® Guide: Part 1 – Current Reality Contents

8.7 Project management team 45

8.8 Organizational context 45
8.9 Professional responsibility 45
8.10 Closing 45

9 What Are The Inconsistencies? 46

9.1 Introduction 46
9.2 Terminology – 1 46
9.3 Terminology – 2 47
9.4 Audit 47
9.5 Quality assurance 48
9.6 Pre-project 49
9.7 Project life cycle and project success 49
9.8 Manage the team: where is control? 50
9.9 Acquire the team 51
9.10 Scope and executing 52
9.11 Where is the control reference? 53
9.12 Monitor and control 53
9.13 Conclusion and recommendations 55

Section III: Process Groups Confusion 56

10 The Project Life Cycle 57

10.1 Introduction 57
10.2 Project life cycle definition 57
10.3 Project life cycle is a variable 58
10.4 Whose perspective 58
10.5 Project owner perspective 59
10.6 Service provider perspective 60
10.7 Closing remarks 61

11 Project Phases and Stages 62

11.1 Introduction 62
11.2 Phase or stage 62
11.3 Phases 62
11.4 Stages 63
11.5 Closing comments 64

8
PMBOK® Guide: Part 1 – Current Reality Contents

12 The Process Groups 65

12.1 Introduction and overview 65
12.2 How do we use the process groups? 65

13 The Confusion 66
13.1 Introduction 66
13.2 Opinion or fact? 67
13.3 So Why the confusion? 68

14 Clearing the Confusion 69

14.1 Introduction 69
14.2 Phase perspective 69
14.3 Project Perspective 70
14.4 Project and stage perspectives 74
14.5 Can we combine? 75
14.6 Can we consider as a program? 75
14.7 Conclusion 77

End Sections 78

References 79

Author Biography: Mounir A. Ajam 81

About the Publisher 82

SUKAD 82
SUKAD Multimedia 83

Endnotes 84

9
PMBOK® Guide: Part 1 – Current Reality Table of Figures

Table of Figures
Figure 1: The Seven Elements of Project Management Maturity™ | by SUKAD 20
Figure 2: The Plan – Do – Check – Act Quality Cycle 54
Figure 3: The PDCA Cycle with Initiating and Closing 54
Figure 4: The Customizable and Adaptable Methodology for Managing Projects™ (CAM2P™) 59
Figure 5: Project Life Cycle (Span) for Service Provider – for a Service Project 61
Figure 6: Typical Project Life Cycle with Phases 62
Figure 7: Project Phases according to CAM2P™ model 62
Figure 8: Project Phases and Stages according to the CAM2P™ Standard Model 63
Figure 9: How Some Practitioners of Project Management Understand the Project Life Cycle 66
Figure 10: The Process Groups within a Typical Project Stage 70
Figure 11: The Project Life Cycle with Initiating Process Group 71
Figure 12: The Project Life Cycle with the Planning Process Group 71
Figure 13: The Project Life Cycle with the Executing Process Group 73
Figure 14: The Project Life Cycle; Adding the Monitoring & Controlling Process Group 73
Figure 15: The Project Life Cycle and Repeating Process Groups 74
Figure 16: Mapping the Process Groups to a Generic Project Life Cycle 77

10
PMBOK® Guide: Part 1 – Current Reality This publication

This publication
This e-book is Part 1 of a two-part series on the PMBOK® Guide, A Guide to the Project Management
Body of Knowledge®. The guide is a globally recognized standard document on project management.

Part 1 of the series focuses on the current reality – the status of the guide as it stands today. This Part
includes a historical perspective, an overview, gaps, inconsistencies, and the good things about it.

Part 2 shift to the author perspective on how to improve the guide – the desired outcome that would
help this guide better and clearer for the project management professional community.

11
PMBOK® Guide: Part 1 – Current Reality Author Message

Author Message
We have been hesitant in publishing this work for two main reasons:

1. We have published some of its content through blog posts (http://blog.sukad.com) and
as chapters and partial chapters in our books, such as ‘Redefining the Basics of Project
Management  ’1.
2. Whenever we discuss some of the topics that we cover in this book (in conferences, events,
articles, or classes), some project management practitioners do not like what we raise. Further,
some can get defensive and even offensive. It is also common for them to accuse us of criticizing
or attacking the PMBOK® Guide, or of having a hidden agenda.

Here, we will provide our history with the PMBOK® Guide and the Project Management Institute (PMI2)
that will counter the hidden agenda accusations. We will show that we had been contributing to PMI
and PMBOK® Guide for many years; since 1998 to be exact. Further, in this book, we offer suggestions
for improving the PMBOK® Guide. Therefore, our only agenda is the growth of the project management
domain with a focus on applying the principles of project management on real projects in the real world.
Our ultimate objective is to help the practitioners increase their contributions and their organizations’
project performance.

Growth and continual improvement of any system cannot happen without being open in addressing
weaknesses, gaps, and challenges.

12
PMBOK® Guide: Part 1 – Current Reality The author and PMI / PMBOK® Guide

The author and PMI /

PMBOK® Guide
We do realize that what we offer here is a different perspective, and it can be controversial. In some cases,
this book might challenge the conventional wisdom for some readers. These readers might consider part
of the content as critique, or even criticism of the PMBOK® Guide. We ask them to read the content
carefully and reconsider their positions.

What we offer here is a professional (subject matter expert) opinion based on close to two decades of using
this guide in real world practice on small, medium, large, and mega projects. We have used its concepts on
industrial projects, and on day-to-day internal projects. Projects such as writing and publishing a book,
launching a new office, launching a business, developing a web portal, and many other types of projects.

Further, the author is a contributor to the earlier versions of the guide.

We also ask you to recognize that the PMBOK® Guide is at the heart of the SUKAD Seven Elements of
Project Management Maturity™ model3, which we mention in Chapter 1 of this e-book.

Finally, if a reader still thinks that what we offer here is a critique or uninformed opinion, we refer you
to the PMBOK® Guide notice page4 and even re-read Chapters 1 and 2 of the guide5. You will notice
what we offer here is indeed a professional opinion and a review; not critique or criticism.

We must close by saying that what we cover here is in line with the intent of the Guide and the volunteers
contributing to the guide, which is a core factor in ‘continual improvement’!

13
 Section I:
Setting the Scene

14
PMBOK® Guide: Part 1 – Current Reality Introduction

1 Introduction
1.1 Standard, framework, methodology?
Is A Guide to the Project Management Body of Knowledge®, the PMBOK® Guide, a standard, a method
or methodology, a framework, or something else6? The elaborated answers to these questions are in a
later chapter, The Four Myths About The PMBOK® Guide.

For now, here are a few relevant definitions.

1.1.1 Standard

In practice, the word ‘standard’ could means many things.

Dictionary definition: “something used as a measure, norm, or model in comparative evaluations”7.

Further clarifications:

• A standard can be anything that an organization establishes for their internal work, as a
standard, for their staff to follow. In this scenario, the organization usually mandates the use
of the standard; although optional standards could exist; however if something is optional, we
typically refer to it as a guide or guideline.
• A common use of the term ‘standard’ usually refers to something (documents) a professional
organization, or authority, publishes for others to use. For example, there are engineering
standards, programming standards, and standards for numerous areas of practice.
• It is also common that some countries have standards’ issuing authorities, which publish their
standards, or sanction the standards that others publish.
• It is also possible that some standards are adopted by the government, in this context, a standard
would become a regulation (or code); mandated by law.

1.1.2 Standard document

In the context of this book, we distinguish between a standard and a standard document; although many
organizations use the terms interchangeably. The differences are:

• A standard can be a standalone reference or resource, for example, ISO 21500 is a standalone
project management standard published by ISO.
• A standard document is a resource, such as a book, which includes a standard and other
non-standard information. In our view, the PMBOK® Guide is a standard document and not
a standard.

15
PMBOK® Guide: Part 1 – Current Reality Introduction

1.1.3 ‘De facto standard’

The De facto standard is a term that refer to a certain reference (standard, standard document, guide)
that is commonly accepted, or highly popular, by practitioners of that domain. This is a marketing term
and just because such a term is used that does not make the ‘reference’ a standard, or even officially
accepted. Some organizations and practitioners of project management refer to the PMBOK® Guide as
a “project management de facto standard”.

1.1.4 Framework

Dictionary definition: “basic structure underlying a system, concept, or text”8.

It is common to use the words ‘framework’ and ‘guide’ interchangeably, but that is not 100% accurate.
In the context of this chapter, assume they are the same.

A ‘framework’ is a general guideline, or an approach that an organization can adopt. The framework
could include many components. For example, the PMBOK® Guide offers guidelines on how to develop
a scope statement, a work breakdown structure, an estimate, a communication plan. PMI labels the
PMBOK® Guide as “a framework for managing a single project” (The Project Management Institute, 2013).

FASTANSWER
ANYTIME,
NO-LIMITS
THE
MAXIMIZE ADOPTION, ANYWHERE
PRODUCTIVITY
LEARNING
TO FAST ROI
YOUR LEARNING NEEDS
LEVERAGE
LEARNING
HELP
EQUIP YOUR
BUSINESS SOCIAL
ENTIRELEARNING,
ABOUT
GET
SAP QUALITY,
COLLABORATION,
USERS
ORGANIZATION
SOFTWARE
TO ADOPT FLEXIBLE, AND
QUALITY
HAS
ECONOMICAL
CONTENT,
SAP
BUILD
NEVER SOLUTIONS. AND
EXPERTISE
BEEN TRAINING
EASIER. WHEN
HANDS-ON
AND
PRACTICE.
IN SAP WHERE
SAP Learning
SOFTWARE.
Hub –user
Hub, IT’S
the edition
choice
when, where, and what to learn
of NEEDED.
SAP
SAP Learning
Learning Hub
Hub

16
PMBOK® Guide: Part 1 – Current Reality Introduction

Other examples:

• ISO 21500 offers a framework for managing projects. However, because a standard organization
issues this document, many also refer to ISO 21500 as a standard; although the official title is
‘Guidance on Project Management’.
• IPMA offers a competence framework. “The IPMA Competence Baseline is the common
framework document that all IPMA Member Associations and Certification Bodies abide by
to ensure that consistent and harmonised standards are applied” (ICB: IPMA Competence
Baseline, 2015).

To summarize, a project management framework offer suggestions for organizations on how to manage
projects. These guides can be used to support a standard, and they can also be the foundation for building
an organizational project management system.

1.1.5 Method and methodology

It is common that some practitioners confuses the meaning of these two terms, method, and methodology
and use them interchangeably.

In general, a method is “a particular procedure for accomplishing or approaching something”9, whereas a

methodology is “a system of methods used in a particular area of study or activity.”10 In other words, a
method is a specific way that is set or fixed, whereas a methodology is a wider term, “a system of methods”.

Further, a method is different from a framework since a method means there is a certain way of doing
something; like systematic process, a step by step approach. Whereas a framework is a general guideline
as defined earlier.

A common project management method may follow a project life cycle or a similar approach. The
following are two examples of this point.

• PRINCE2®  is a method; “PRINCE2 (Projects IN Controlled Environments) is a structured

project management method” (What is PRINCE2®, 2015). Notice the use of the terms ‘structured’
and ‘method.’
• SUKAD developed a methodological approach that is based on a project life cycle, which is
CAM2P™ (The Customizable and Adaptable Methodology for Managing Projects™). Notice the
use of the term ‘methodology’ and not ‘method’ this is because CAM2P™ offer an approach that
has to be customized and adapted to the organizational and project context. The customized
and adapted output is a method. In other words, CAM2P™ is “a system of methods.”11

17
PMBOK® Guide: Part 1 – Current Reality Introduction

CAM2P™ is not a set method – it is an approach

we use to generate various customized and adapted
methods for given projects’ environments,
domains, or classes.

It is not common to hear about project management methods since methods are often custom built for
an organization12; they are internal resources making them proprietary information.

1.1.6 Is a method (methodology) also a standard?

It can be.

If an organization officially adopts a methodological approach (“systems of methods”) or a specific method,

it become their standard. For example, in  SUKAD we use the CAM2P™ approach, it is our standard.
Some organizations have adopted PRINCE2® or Agile/Scrum as their methods; or built their methods.
However, ‘method’ and ‘standard’ means different things, as we have explained.

1.2 What should organizations use?

Should organizations use a method, a framework, a guide, or what?

This is a wide open question.

A leading practice would be for the organizations to develop their organizational project management
system (OPM System). A system, in the context of this e-book, is about the various components and
elements of managing projects. In other words, the OPM System must have an organizational focus
rather than a single project or program focus.

CAM2P™ is not a set method – it is an approach

we use to generate various customized and adapted
methods for given projects’ environments,
domains, or classes.

The OPM System can be limited to projects or can be wider to cover the whole spectrum of project
management, including program and portfolio management, strategic project management, project
management maturity and other relevant components.

18
PMBOK® Guide: Part 1 – Current Reality Introduction

Therefore, to manage the organization’s projects effectively13, one standard or method is not enough.
OPM must adopt a system thinking approach.

In line with the above, for managing projects within an organization, use the term organizational project
management system (OPM System). This ‘system’ must consist of (a) policies, (b) methods, (c) processes,
(d) competence framework, among other things.

Figure 1 is a product of the SUKAD research and development work, and it represents a project
management maturity model, which is also a framework for building and sustaining the organizational
project management system14.

JUMP-START
ANYTIME,
NO-LIMITS
THE
MAXIMIZE
FAST ANSWER
ADOPTION, ANYWHERE
PRODUCTIVITY
LEARNING
CAREERS
TO FAST ROI
YOUR LEARNING NEEDS
LEVERAGE
LEARNING
HELP
EQUIP
GIVE STUDENTS
YOUR
BUSINESS SOCIAL
ABOUT
ENTIRE LEARNING,
ONLINE
GET
SAP QUALITY,
COLLABORATION,
USERS
ORGANIZATION
ACCESS SOFTWARE
TOTOADOPT FLEXIBLE,
A VAST BODYAND
QUALITY
HAS
ECONOMICAL
CONTENT,
SAP
OF
BUILD
NEVER KNOWLEDGE
SOLUTIONS. AND
EXPERTISE
BEEN TRAINING
ABOUT WHEN
HANDS-ON
EASIER.
AND
PRACTICE.
SAP
IN SAP WHERE
SOLUTIONS.
SAP Learning
SOFTWARE.
Hub –user
Hub, IT’S
the edition
choice
when, where, and what to learn
of NEEDED.
SAP
SAP Learning
SAP Learning Hub
Learning Hub
Hub, student edition

19
PMBOK® Guide: Part 1 – Current Reality Introduction

The fundamental elements (the core) of this OPM System are:

13
Project in this context refer to the wider perspective
perspective, including programs and portfolios
Figure 1: The Seven Elements of Project Management Maturity™ | by SUKAD

• Method,
• Processes and Functions,
• Tools and Technology, and
• Professional Development.

The differentiating elements (the circles) are:

• Knowledge Management and Organizational Learning,

• Leadership and Competence Framework, and

The strategic element (the outer circle) is:

• Strategic and Organizational Aspects.

Please refer to the image for a brief overview of each element15.

20
PMBOK® Guide: Part 1 – Current Reality Introduction

1.3 Closing comments

What we are suggesting is that a standard document, a guide, a set of processes, or a method – taken
independently – are not enough to manage projects effectively. Once again, organizations need a
system approach.

Unfortunately, most project management professional associations’ focus on one area or another but not
the full system. We realize many have addressed the organizational system, however, their energy and
market focus is on certifications.

Consequently, the proposed model is attempting to provide an integrated approach from the various
resources of the project management domain. Therefore, the OPM System includes a method (like
PRINCE2®, CAM2P™, or others), a set of processes (like from PMBOK® Guide), and competence elements
(like from ICB16; IPMA17).

LEARN
ANYTIME,
NO-LIMITS
THE
MAXIMIZE
FAST
JUMP-START
ANSWER
ADOPTION,
BY ANYWHERE
DOING
PRODUCTIVITY
LEARNING
CAREERS
TO FAST ROI
YOUR LEARNING NEEDS
LEVERAGE
LEARNING
HELP
EQUIP
GIVE
DEVELOP STUDENTS
YOUR
BUSINESS SOCIAL
EXPERTISE
ABOUT
ENTIRE LEARNING,
ONLINE
GET QUALITY,
COLLABORATION,
USERS
SAP
ORGANIZATION
ACCESS
IN SAP SOFTWARE
TO
SOLUTIONS
TOADOPT FLEXIBLE,
A VAST BODYAND
QUALITY
HAS
ECONOMICAL
CONTENT,
SAP
OF
BUILD
NEVER
THROUGH
KNOWLEDGE
SOLUTIONS. AND
EXPERTISE
BEEN TRAINING
EXPLORATION ABOUT WHEN
HANDS-ON
EASIER.
AND
PRACTICE.
SAP
IN SAP WHERE
SOLUTIONS.
PRACTICE.
SAP Learning
SOFTWARE.
Hub –user
Hub, IT’S
the edition
choice
when, where, and what to learn
of NEEDED.
SAP
SAP Learning
SAP Learning
Learning
Live Hub
Hub
Hub, student edition
Access

21
PMBOK® Guide: Part 1 – Current Reality PMBOK® Guide Overview

2 PMBOK® Guide Overview

2.1 Introduction
The author assumption is that readers of this e-book are familiar with the PMBOK® Guide. Therefore, it
is not our intention to re-explain the guide but to offer a brief overview of the key components, especially
those that would be relevant to this book’s upcoming chapters. What we present here is per the latest
edition of the guide, the fifth edition, published in January 2013.

2.2 The main sections

In general, we observe two distinct sections in the guide, and they are:

• Section 1 is the first three chapters that are general, the project management framework.
• Section 2, which is the remainder of the guide from Chapter 4 to 13; each chapter covers a
knowledge area.
• With the fifth edition, there is an annex dedicated to the ANSI18 approved project management
standard.
The Guide

Project Management Framework

Knowledge Areas

2.3 The project management framework

The general part (project management framework) is the first three chapters.

• Chapter 1 is mostly about definitions, and general information about project management,
program management, portfolio management, and their inter-relations. The chapter also
includes the relations between projects and operations, the role of the project manager, and a
brief definition of the PMBOK® Guide.
• Chapter 2 is crucial but often forgotten (in part or wholly) by practitioners who focus on the
process groups and processes. The chapter is about the organizational context and influences,
governance, project life cycle, project success and the project team. In the current edition, the
guide introduces different types of project life cycles and a new definition of project success.
• Chapter 3 is about the process groups and processes, which are discussed next.

22
PMBOK® Guide: Part 1 – Current Reality PMBOK® Guide Overview

2.4 Process groups

The following are the key notes about the process groups and processes.

There are five process groups, consisting of 47 processes

• The guide includes five process groups.

• Each process group consists of two or more processes.
• In total there are forty-seven (47) processes, per the fifth edition of the PMBOK® Guide.
• Over the years, with the different editions, the number of process groups has not changed
whereas the number of processes typically changes from one edition to another.
• The five process groups are about initiating19, planning, executing, monitoring and controlling,
and closing a project or a phase.

2.5 Knowledge areas

The forty-seven processes are distributed across the various knowledge areas based on their focus.

• In the current edition, there are ten knowledge areas.

• These are integration, scope, time, cost, quality, human resource, communication, stakeholder,
risk, and procurement.

There are ten knowledge areas

• The number of knowledge areas has not changed over time until the fifth edition (the current
one). The number changed from nine to ten, adding a chapter on stakeholders.
• The content of this new knowledge area (chapter) was mostly extracted from the communication
and integration’s knowledge areas of the previous editions.
• Each knowledge area, except integration, refers to what most practitioners and some project
management literature label a project management function or area of focus.
• Integration is about integrating all of the knowledge areas and processes.
• Integration also includes a few general processes that are not specific to a knowledge area.
• Each knowledge area consists of a few processes.
• Therefore, every process belongs to a knowledge area and a process group. A table showing
this integration is available in the PMBOK® Guide, and a similar one is presented in part 2 of
this work (the second e-book).

23
PMBOK® Guide: Part 1 – Current Reality PMBOK® Guide Overview

2.6 The processes

Here are a few key points to note:

• To emphasize the last point from the previous section, each of the forty-seven processes belongs
to a process group and a knowledge area. For example, the “Develop Project Charter” process
is in the integration area, and it is an initiating process. “Create WBS” is in the scope area, and
it is a planning process.
• With the various editions, some of the processes have moved from one knowledge area to
another; for example “Identify Stakeholders” moved from communication to the stakeholders’
knowledge area.
• Similarly, some of the processes have moved from one process group to another. Such as “Manage
Project Team” moving from monitoring and controlling to executing in a previous edition.
• Some processes are common to more than one knowledge area but due to the restrictive
structure of the guide they have to be listed in one of the ten knowledge areas. An example
of this is estimating resources, which is common to cost and time. Earned value management
(EVM) is not an independent process, it is part of cost control, but EVM is about the integration
of scope, cost, and time and not limited to cost.

2.7 Generic standard document

The PMBOK® Guide is generic in nature and is useful for “most projects, most of the time” (The Project
Management Institute, 2013). It is not tailored or customized to a particular sector, industry, domain,
or project type.

Because of the generic nature of the Guide, PMI has published a few industry specific extensions
(supplements) to the PMBOK® Guide such as a construction supplement for projects that include
constructing a facility. This supplementary standard document adds four knowledge areas that are not
in the PMBOK® Guide and numerous additional processes but keeps the same process groups structure.
There are also extensions for government projects and software projects.

In addition to the industry/sector extensions, there are numerous standard documents for special
topics like work breakdown structure, estimating, scheduling, and risk management. These are “practice
standards” as PMI have labeled them.

Furthermore, there are standards for program and portfolio management and organizational project
management.

Other organizations may have similar things but discussing them is outside the scope of this book.

24
PMBOK® Guide: Part 1 – Current Reality PMBOK® Guide: Historical Perspectives

3 PMBOK® Guide:
Historical Perspectives
3.1 Introduction
The historical details are not core to the purpose of this e-book. However, it would be useful to touch
on certain aspects and the nature of the changes to date. The topics that we address would be relevant
to understanding the overall context and the need to improving the PMBOK® Guide.

3.2 History of the guide

3.2.1 1996

The first official consolidated copy of the guide was published in 1996.

• It was about 180 pages,

• It had 37 processes, nine knowledge areas, and five process groups.

This first edition was not labeled as an ANSI standard.

HANDS-ON PRACTICE
ANYTIME,
NO-LIMITS
THE
MAXIMIZE
FAST
JUMP-START
LEARN ANSWER
ADOPTION,
BY ANYWHERE
DOING
PRODUCTIVITY
LEARNING
CAREERS
TO FAST ROI
FOR EFFECTIVE LEARNING
YOUR LEARNING NEEDS
LEVERAGE
LEARNING
HELP
EQUIP
GIVE
DEVELOP
EXPERIENCESTUDENTS
YOUR
BUSINESS SOCIAL
EXPERTISE
ABOUT
ENTIRE LEARNING,
SAPONLINE
GET
USERS
SAP
IN SAPQUALITY,
COLLABORATION,
ORGANIZATION
ACCESS SOFTWARE
TO
SOLUTIONS
TO ADOPT
A FLEXIBLE,
VAST HAS
BODYAND
QUALITY
SOFTWARE FIRSTHAND
ECONOMICAL
CONTENT,
SAP
OF
BUILD
NEVER
THROUGH
KNOWLEDGE
SOLUTIONS. AND
EXPERTISE
BEEN TRAINING
EXPLORATION ABOUT WHEN
HANDS-ON
EASIER.
TO BUILD KNOWLEDGE
AND
PRACTICE.
SAP
IN SAP WHERE
SOLUTIONS.
PRACTICE.
SAP Learning
SOFTWARE.
Hub –user
Hub, IT’S
the edition
choice of NEEDED.
AND
SAP
ENHANCE
when, where,
SAP Learning
Learning
and what to learn SKILLS.
Hub
Hub
SAP Learning
SAP Live
Live Hub, student edition
Access
Access

25
PMBOK® Guide: Part 1 – Current Reality PMBOK® Guide Overview

3.2.2 2000

Next, the 2000 Edition was published. With this edition,

• The number of processes increased to 39,

• The number of pages increased to about 210,
• The two additional processes were in the risk knowledge area, and
• With this edition, there were some changes to the names of the processes.

This second edition was still not labeled as an ANSI standard.

3.2.3 Third edition

With the 2004 edition,

• PMI started to number the editions and calling this version the Third Edition instead of the
2004 edition.
• Chapter 3 was split from the first section of the book and listed on its own under the title ‘The
Standard for Project Management of a Project’. This change was likely20 due to ANSI approval.
• Although this edition was labeled as an ANSI standard, to our knowledge, only part of Chapter 3
was ‘the ANSI standard’ and not the whole chapter, nor the whole guide.
• Other changes in this edition were the increase in the number of processes from 39 to 44. Most
of them were in the integration chapter with the addition of four processes.
• Further, some processes moved from one knowledge area to another.
• The number of pages reached about 400 pages.

3.2.4 Fourth edition

With this edition,

• There were no changes to the sections or knowledge areas,

• The number of processes dropped to 42 by consolidating the six procurement processes
into four,
• There were other changes in the names of processes and movement from one knowledge area
or process groups to another, and
• Some processes were also dropped, and other added.

26
PMBOK® Guide: Part 1 – Current Reality PMBOK® Guide: Historical Perspectives

3.2.5 Fifth edition

The fifth edition is the current edition21.

• With this edition, the number of pages jumped to more than 600,
• A new knowledge area was added, and
• The number of processes increased from 42 to 47.22

The above changes appears substantial but they were not significant. Our opinion is that most of the
content of the additional processes were there before, incorporated into other processes. For example,
the management plan processes for scope, time, and cost were part of the project management plan
process in the integration chapter but with this edition they become independent processes, each in its
respective knowledge area23. This change resulted in three of the five additional processes, but it was
mostly relocating the action from one place to another.

Year Edition KA22 Processes Pages

1996 1996 9 37 ~ 180
2000 2000 9 39 ~ 210
2004 Third 9 44 ~ 400
2008 Fourth 9 42 ~ 460
2013 Fifth 10 47 ~ 620

This table summarizes the general changes. Once again, there were other changes, such as the one we
discussed here; and still more changes that we have not discussed.

3.2.6 Core and facilitating processes

The first two editions split the processes in three of the process groups (planning, executing, and
controlling) into core processes and facilitating processes. Initiating and closing groups do not have
more than two processes each, so a split was not logical.

The core processes were related to integration, scope, time, and cost and the facilitating processes the
other knowledge areas. The split was interesting and related to the concepts of the triple constraints of
time, cost, and scope.

3.3 Summary and closing remarks

Except the stakeholder chapter addition in the latest edition, there have been no major structural changes
to the guide. Yes, the number of processes increased and decreased, other processes changed names or
location and even added content here and there. Certain things were deemphasized in the third and
fourth editions but reemphasized in the fifth, like project life cycle. Further, the introduction of new
standard documents by PMI24 have resulted in additional content, mostly in Chapter 2, but also some
terminology changes in other sections.

27
PMBOK® Guide: Part 1 – Current Reality PMBOK® Guide: Historical Perspectives

A significant change to highlight here was the guide (or part of the guide) becoming an official ANSI
standard with the third edition.

Finally,

From numerous online discussions, some practitioners consider the PMBOK® Guide as the holy book,
while others think it needs improvement for better understanding, and a few prefer to dismiss it. This
e-book series is our humble approach to offers suggestions for transforming the guide into an efficient
resource for applying project management. Our attempt is to counter the common conventional view
that it is NOT real life, and it is not practical.

Whether PMI and PMBOK® Guide’s volunteers consider our work or not, is not our decision or within
our circle of influence. What we control is sharing our thoughts and reviews with the professional
community. Further, whether the information presented in these two e-books is incorporated into the
PMBOK® Guide or not, we are using these concepts in our workshops, methodology, organizational
project management systems, and is what we suggest to our clients.

ANYTIME, ANYWHERE
LEARNING ABOUT
SAP SOFTWARE HAS
NEVER BEEN EASIER.
SAP Learning Hub – the choice of
when, where, and what to learn

28
PMBOK® Guide: Part 1 – Current Reality PMBOK® Guide: Value And Growth

4 PMBOK® Guide: Value

And Growth
4.1 Introduction
There is no doubt, that the PMBOK® Guide has reached millions all over the world. Hundreds of volunteers
have contributed to its various editions and continued to do so. The content of the guide is excellent and
necessary for any project, regardless of the domain or project classification. Some professionals criticize
the guide as not practical, but this is not reality, more on this in a later chapter.

4.2 Good parts

The guide structure is good, and it addresses the various knowledge areas, process groups, and processes.
It addresses the strategic context, project life cycles, and relations to program and portfolio management.
Concepts like the enterprise environmental factors and organizational process assets are of high value.

4.3 Terminology
The PMBOK® Guide terminology is not standard for all organizations around the world, and this is normal
and acceptable since even the same language have numerous variations. However, the PMBOK® Guide
has contributed significantly to the project management language where professionals now know terms
like scope statement, charter, project management plan, and numerous other terms. Unfortunately, some
practitioners can recite the definitions of these terms but do not know how to apply them to real projects.

4.4 Acceptance
The PMBOK® Guide is widely accepted as already stated.

One reason for the wide acceptance is that it is generic and not specific to an industry; “most projects
most of the time”. The generic nature allows the guide and project management domain to reach people
outside the traditional users of project management like engineering and construction.

Another reason for its wide acceptance is due to the PMI various certificates requiring the guide as an
essential knowledge reference. If one considers PMI members only, there are more than 450,000 active
members around the world, each one has the latest copy of the guide. This not including those who
have it and are no longer members.

29
PMBOK® Guide: Part 1 – Current Reality PMBOK® Guide: Value And Growth

4.5 PMI power

PMI is a centralized organization with branch structure, through the chapters. Further, due to the
PMI certification, there are numerous training providers that subscribe to PMI, and the popularity of
certain certificates have contributed to making the Project Management Institute a rich and powerful
organization. This power helps in the spread of project management and its growth.

4.6 Number of certificates holders

PMI launched the Project Management Professional certificate (PMP®) in 1984. Between 1984 and 2004
the number of PMPs grew to about 100,000 certificate holders. Membership reached about 150,000 at
that time. Notice the number of PMP is less than members, which is logical.

In the last ten years, the number of PMPs has reached more than 650,000 whereas the membership is
much lower at around 450,00025. These figures show that the number of PMPs has grown more than
six folds whereas the membership growth is only three folds. In our opinion, this is an indication that
professionals are finding value in certification but not in the organization offering these certificates. In
other words, once people achieve their desired certification they do not maintain their membership.

The total number of all PMI active certificates’ holders is about 700,00026 as of June 2015.

4.7 What is good about the PMBOK® Guide?

In addition to the points discussed already, the PMBOK® Guide has many good points:

1. It does an excellent job of covering the various processes related to managing a single project.
There are 47 processes combined into five process groups that interact throughout the project
and repeat from phase to phase.
2. As a standard document, the regular updates keep it current. With the part of the guide
recognized as a standard, every four years there is a new update reflecting changes based on
the present state of practice and other factors.
3. It has the input of a vast number of volunteers. With every edition, a large number of volunteers
come together from around the world to work on its update. This is important since this practice
promote a culture of contribution and knowledge sharing across cultures.
4. It is flexible. As a guide, it is not set in stone. Which means  project managers, with good
experience and a good understanding of the guide can determine which processes apply to
their particular project, which are necessary, and which are missing.
5. Although the guide put a lot of emphases on processes, it does cover the general areas related to
project management, such as the project life cycle, the different types of project organizations,
the importance of stakeholders management. Some of this coverage might not be elaborate.
Nonetheless, it is there.

30
PMBOK® Guide: Part 1 – Current Reality PMBOK® Guide: Value And Growth

4.8 Chapter Summary

In previous points, it was clear that certification growth has been significant, and membership growth
is good, but far from matching the growth in certification. The relevance of this point to this book is
that numerous project management experts and practitioners, including the author, do not believe PMI
is doing enough to strengthen the domain of project management. They are not doing enough even in
enhancing standard documents like the PMBOK® Guide. It is clear that numerous readers will not agree
with this statement, yet it is important to note here.

As highlighted earlier, the guide grew from less than 200 pages to more than 600 pages. However, there
are no major structural changes or new substantial content, even with the addition of the stakeholder
chapter. Another controversial statement is that many (if not most) of the changes have been cosmetics.
It is not uncommon to hear some professionals see as much value in the first 200-page edition as in the
recent ‘600+page’ edition.

Therefore, and although the PMBOK® Guide has significant value, it requires some re-writing and a
serious re-look at how to make it more valuable than it is today. In this e-book series, we will address
gaps, inconsistencies, errors but will also suggest improvements. The second e-book is dedicated to how
to transform the guide from being good to being great!

ANYTIME, ANYWHERE
NO-LIMITS LEARNING
LEVERAGE
LEARNING ABOUT SOCIAL LEARNING,
COLLABORATION,
SAP SOFTWARE HAS QUALITY
CONTENT,
NEVER BEEN AND HANDS-ON
EASIER.
PRACTICE.
SAP Learning Hub – the choice of
when, where, and what to learn

31
 Section II:
Gaps and Challenges

32
PMBOK® Guide: Part 1 – Current Reality Is The PMBOK® Guide Good Enough?

5 Is The PMBOK® Guide

Good Enough?
5.1 Introduction
This question, is the PMBOK® Guide good enough to manage projects effectively, has been on our mind
for a long time. We have been debating whether to write about it or not. As expected when we wrote
about it via our blog site, we had quite a bit of discussion. Therefore, it is important to address this
question here since it is one of the main reasons we are publishing this work.

5.2 What is the PMBOK® Guide?

Summarizing the earlier chapters, the PMBOK® Guide is a guide, a framework that discusses the processes
and knowledge required to manage a single project. The guide includes the ANSI (American National
Standards Institute) approved Standard for Project Management.

Many project management practitioners and experts would agree that standards, PMBOK® Guide or
anything else, cannot and should not cover everything. They are not inclusive and certainly they are not
a full body of knowledge.

5.3 So is it enough?
The professional opinion of numerous project management professionals is that the PMBOK® Guide
is not enough to manage projects. This view is also by the volunteers who update the guide and is the
official PMI position, believe it or not; although the message is implicit rather than explicit. Let us clarify
this statement further.

Once, I was presenting in a conference, and in a response to a question I said “PMI is not the only authority on project
management”; a few were offended and one person tried to disrupt the presentation. There are other similar stories
that demonstrate this point.

On its own, the guide is not enough, since it is not inclusive, it is “a subset of the body of knowledge”
(The Project Management Institute, 2013). If someone, or an organization, learn the PMBOK® Guide and
nothing else then it is not enough. Some might say, this is common sense, and people are professionals
enough to consider other sources. That is in an ideal world. In the real world, some thinks that PMI is
the only authority in project management and the guide is THE STANDARD.

33
PMBOK® Guide: Part 1 – Current Reality Is The PMBOK® Guide Good Enough?

One should treat the PMBOK® Guide as part of a holistic system, which is (by the way) how the PMBOK®
Guide is designed. The guide advocates the need to supplement it with other aspects of the project
management body of knowledge, whether internally developed and/or from other sources. This is what the
author is attempting to do with the Seven Elements model discussed in Chapter 1, supplement the guide.

5.4 Why is the guide not enough?

Here are a few more statements supporting the position stated earlier; some do repeat for emphasis.

The PMBOK® Guide is a guide to the project management body of

knowledge – NOT – the body of knowledge

• The original author and volunteers27 wrote in the PMBOK® Guide that it is a “subset” of the
project management body of knowledge (The Project Management Institute, 2013). “Subset”
means it is only a piece of what one needs to manage projects.

THE ANSWER
ANYTIME,
NO-LIMITS ANYWHERE
LEARNING
TO
YOUR LEARNING NEEDS
LEVERAGE
LEARNING ABOUT SOCIAL LEARNING,
GET
SAP QUALITY,
COLLABORATION,
SOFTWARE FLEXIBLE, AND
QUALITY
HAS
ECONOMICAL
CONTENT,
NEVER BEEN AND TRAINING WHEN
HANDS-ON
EASIER.
AND
PRACTICE.WHERE
SAP Learning IT’S
Hub – the choice
when, where, and what to learn
of NEEDED.

34
PMBOK® Guide: Part 1 – Current Reality Is The PMBOK® Guide Good Enough?

• One rule from PMI copyright guidelines is that PMI insists on people and organizations to
use ‘PMBOK® Guide’ and not ‘PMBOK’ alone. This requirement is due to PMBOK = Project
Management  Body of Knowledge. However, PMI is clear that its flagship ‘standard’ is only a
guide to the project management body of knowledge and is NOT the body of knowledge. For
some, this might seem a minor point but it is not.
• The PMBOK® Guide emphasizes the need for “Organizational Process Assets” (OPA), which
implies that there has to be an organizational system that the guide links to. It is important
to stress here that almost every process in the PMBOK® Guide has an input that is from the
OPA. In other words, the guide does not offer the full system; rather, it should be part of a
comprehensive system.
• PMBOK® Guide clearly states that it is a framework, a guide, and NOT a methodology; and invite
the practitioners to use any methodology to go with it. In other words, we need more than what
the guide offers. Here, it is worth noting that many refer to the “PMI Methodology” but PMI
tells us “the PMBOK® Guide is not a methodology” (The Project Management Institute, 2013).
• PMI has published supplements to the PMBOK® Guide. In other words, PMI (the organization
that publishes and owns the guide) recognizes that the PMBOK® Guide is not enough for all
projects and is publishing other standards to supplement it.
• There is also numerous ‘knowledge area related’ practice standards to complement the PMBOK®
Guide; like estimating, scheduling, WBS, risk, and all other topics. Why PMI does sponsor
these supplemental standards, if the PMBOK® Guide is enough?

5.5 Closing remarks

If the reader noticed, most of our comments above are from PMI and the PMBOK® Guide itself, and they
are not personal opinions. Here we must restate that if these volunteers and PMI itself are saying we need
a methodology; we need industry-specific knowledge; we need supplements; we need the organizational
process assets – then is not this the same thing as saying the PMBOK® Guide is not enough? 

To close, we repeat what we said more than once – the PMBOK® Guide is good and an excellent standard.
We28 use it in our company; we use it in our daily life; we conduct training on it; we developed a
methodology to align to it; and we built a maturity model with the PMBOK® Guide processes at its core.
Therefore, when we say it is not enough that is not meant as criticism, or putting it down, or we have
hidden agendas. We say so, to clarify that to manage the organizational projects effectively the PMBOK®
Guide is not enough and for organizational excellence, there is a critical need for more.

35
PMBOK® Guide: Part 1 – Current Reality The Four Myths About The PMBOK® Guide

6 The Four Myths About The

PMBOK® Guide
6.1 Introduction
In this chapter, the focus is on myths about the guide.

PMBOK® Guide is a standard

PMBOK® Guide is about best practices

PMBOK® Guide is a methodology

PMBOK® Guide is not real world

There are many, but we discuss the leading four myths listed in the image.

It is vital to stress that some of these myths have deep roots. Consequently, some of the content of this
chapter might be a shock to the conventional wisdom of a few project management practitioners.

6.2 The project management standard

The PMBOK® Guide is a framework, as explained in the first chapter. However, most practitioners also
label it as a standard, but this is not accurate. Unfortunately, the ANSI stamp and the “Global Standard”
phrase on the cover of the guide, are direct contributors to this confusion.

Let’s start with the ANSI stamp.

What most people do not know is that the PMBOK® Guide (the whole guide) is not a standard, even
though PMI put ANSI29 stamp on its cover. The only part of the guide, an Annex, is the ANSI standard.
In other words, the ANSI approved ‘Project Management Standard for Managing a Project’ is only
about 40 pages out of the guide 616 pages; that is less than 7% of the content. In short, the PMBOK®
Guide includes the standard that ANSI approves, but the other sections are developed by the volunteers
and not officially recognized as a standard. “Chapter 3 is the standard for project management.”30 (Project
Management Institute, 2008).

36
PMBOK® Guide: Part 1 – Current Reality The Four Myths About The PMBOK® Guide

Here is another the quotation from the 5th edition: “The PMBOK® Guide contains the standard for managing
most projects most of the time across many types of industries. The standard, included in Annex A1,
describes the project management processes used to manage a project toward a more successful outcome.”
(The Project Management Institute, 2013)31.

Global Standard

Another misleading item that is contributing to this confusion is the phrase “Global Standard” that is on
the top left corner of the cover below the PMI logo. Who – which authority – which global organization –
has recognized this guide as a Global Standard?

The answer is not readily available and will leave this point open.

What is the relevance of this point?

Our aim is to help minimize the myth that the guide is THE STANDARD for project management.
Thinking that it is, lead un-experienced professionals to over-depend on it. In other words, the ultimate
purpose is improving organizational performance, which is the core purpose of this work.

MAXIMIZE
ANYTIME,
NO-LIMITS
THE ANSWER ANYWHERE
PRODUCTIVITY
LEARNING
TO
YOUR LEARNING NEEDS
LEVERAGE
LEARNING
HELP YOURABOUT SOCIAL
ENTIRELEARNING,
GET
SAP QUALITY,
COLLABORATION,
ORGANIZATION
SOFTWARE FLEXIBLE, AND
QUALITY
HAS
ECONOMICAL
CONTENT,
BUILD
NEVEREXPERTISE BEEN AND TRAINING WHEN
HANDS-ON
EASIER.
AND
PRACTICE.
IN SAP WHERE
SAP Learning
SOFTWARE. IT’S
Hub – the choice
when, where, and what to learn
of NEEDED.

37
PMBOK® Guide: Part 1 – Current Reality The Four Myths About The PMBOK® Guide

6.3 Best practices

Another common myth is driven by marketing of PMI and associated organizations, such as PMI chapters
and training providers that have made a business from certification preparation courses, for some, the
only source of income. This myth is about the PMBOK® Guide promoting the project management
best practices.

The PMBOK® Guide is about good practice; it does not

offer project management best practices!

A search of the PMBOK® Guide of the phrase ‘best practices’ brings back a few hits but most are in
relations to industry best practices that could be used; practices from outside the guide. Nowhere this
term ‘best practices’ was used to refer to the PMBOK® Guide itself. On the contrary, the definition and
purpose of the PMBOK® Guide, as stated in chapter one mentions “good practice.”

Once again, what is the relevance?

If the guide is THE BEST PRACTICES then why look elsewhere? Can anything top the best?

6.4 Methodology
The first myth was primarily due to PMI and its marketing, the second one is a combination of PMI
and other parties but also driven by marketing. This third myth is also driven by marketing, but its root
cause is primarily due to a genuine misunderstanding of the PMBOK® Guide; including by those who
deliver classes about it. It is also unfortunate that some of those who do not understand this fact are
approved by PMI as Registered Education Providers.

It is quite common to see advertisements for courses, or request for proposals, or online discussions
referring to the PMI, PMP, or PMBOK® Guide Methodology. Well, one does not exist. The PMP is a
certificate, the PMBOK® Guide is a framework, and PMI does not offer nor promote a methodology.

It is vital to repeat something covered earlier, the guide is generic, its popularity is in being generic
and “for most projects most of the time” (The Project Management Institute, 2013). On the other
hands, a methodology or method has to be tailored, custom-fit to organizational needs and the project
environment. Therefore, the PMBOK® Guide is not and cannot be a methodology.

Do not take our words for it, refer to Chapter 1 of the PMBOK® Guide.

Consequently, because the guide is not a method, the recommended practice is for organizations to
develop their methodologies, which can align to the guide. This is what SUKAD did in 2007, when we
developed The Customizable and Adaptable Methodology for Managing Projects™ (CAM2P™)32.

38
PMBOK® Guide: Part 1 – Current Reality The Four Myths About The PMBOK® Guide

Once again, what is the relevance?

Help the project management practitioners understand that the PMBOK® Guide, on its own, is not
enough to manage projects; there is a need for a method to supplement it. Without a method or a
well-defined project life cycle, the management of projects is deficient. A critical point, related to this
myth, the confusion between process groups and project phases33.

6.5 PMBOK® Guide and the real world

Like the previous myth, this one is also driven by a misunderstanding of the PMBOK® Guide; including
by those who deliver classes about it, unfortunately.

It is common to hear things like “the guide is not practical”; “it is too theoretical”; “some of the content is
not applicable”; and “it is not for the real world.” Statements like these are partially triggered by statements
like “the project manager can select what processes apply to their projects.”

Is this real?

Why such statements?

Because, some professionals expect the PMBOK® Guide to be a Manual. They expect it to be a step by
step approach and include templates and flowcharts. They do not understand that the guide is not a
methodology nor it is the organizational project management system. The guide assumes that an OPM
system exists in the organization and refer to it via the organizational process assets (OPA) that were
mentioned earlier.

It is also common to hear, “Do you, really, want me to apply the 47 processes? It takes an army to do this
work”. We usually smile when we hear this statement and say “Yes, you have to use them, and not only
once, but repeat for each phase.” One can only imagine the reaction.

In closing, the PMBOK® Guide is REAL WORLD.

The author has been in project management for three decades and cannot remember working a project
without these processes or variations of them. The author experience includes working on small projects,
medium projects, large projects, and mega projects. Regardless of the size or complexity, the repeated
project management processes and project life cycle are necessary34.

Yes, the guide is not a manual but it is not intended to be. It cannot be a manual since there are numerous
variations of industries and project types, and one-size does not fit all. This is why it is a guide and need
to align it with a method and other elements.

39
PMBOK® Guide: Part 1 – Current Reality What Is Missing?

7 What Is Missing?
7.1 Introduction
What is missing from the PMBOK® Guide?

At the start of this short chapter, it is important to stress that what we include here does not mean that
they are shortcomings or errors. These missing items, at least most of them, are missing by design.
Meaning, the intentions from the beginning is not to have them in the guide, and we agree, their details
do not belong in the guide.

To clarify, these items have no place in the guide but  they must be part of a project management
organizational system. Therefore, what we are advocating is that the PMBOK® Guide should still mention
them to clarify the boundaries.

7.2 A methodology
As explained earlier, since the PMBOK® Guide design is to be a generic guide – not industry or application
area specific – it does not offer a methodology. The guide advises the readers that they can use other
standards or internally developed methodologies to supplement it.

FASTANSWER
ANYTIME,
NO-LIMITS
THE
MAXIMIZE ADOPTION, ANYWHERE
PRODUCTIVITY
LEARNING
TO FAST ROI
YOUR LEARNING NEEDS
LEVERAGE
LEARNING
HELP
EQUIP YOUR
BUSINESS SOCIAL
ENTIRELEARNING,
ABOUT
GET
SAP QUALITY,
COLLABORATION,
USERS
ORGANIZATION
SOFTWARE
TO ADOPT FLEXIBLE, AND
QUALITY
HAS
ECONOMICAL
CONTENT,
SAP
BUILD
NEVER SOLUTIONS. AND
EXPERTISE
BEEN TRAINING
EASIER. WHEN
HANDS-ON
AND
PRACTICE.
IN SAP WHERE
SAP Learning
SOFTWARE.
Hub –user
Hub, IT’S
the edition
choice
when, where, and what to learn
of NEEDED.
SAP
SAP Learning
Learning Hub
Hub

40
PMBOK® Guide: Part 1 – Current Reality What Is Missing?

7.3 Organizational system

The guide assumes that a project management organizational system already exists. The OPM system
includes tools and templates, organizational assets, processes and procedures, governance and control
policies, and many other elements that are necessary for effective management of projects.

7.4 Tailoring and customization

The PMBOK® Guide does not include industry/application area specific processes or knowledge areas.
The lack of tailoring the guide to an application area is one of the reasons there are a few supplements
to the PMBOK® Guide that are industry specific, such as for government projects, software projects, or
construction projects.

7.5 Project classification

How to rank projects or classify them in term of size, complexity, or other factors is outside the guide.
Also outside the guide is how to manage projects from different classification.

Project classification is important since one should treat small projects differently than large projects;
simple projects are also different from complex projects. Even within the same organization, project
management can vary depending on the project class. The PMBOK® Guide does not address the topic
directly. It does address it implicitly and indirectly by saying that the project manager can select from
the processes but we believe this is not the appropriate way to handle this important topic.

7.6 Templates and forms

The guide is not a manual and cannot be and should not be.

Projects are not one-size-fits-all, and the way to manage them is not set in stone. Therefore, the guide
cannot offer fixed or set templates that would be applicable to all types of projects. As for a method,
these have to be custom-fit to the organizational context.

7.7 Project life cycle

Since the guide is not industry or domain specific and is not a method, it cannot offer a fixed project
life cycle.

It is important to note here that in the earlier editions, the PMBOK® Guide used to show sample project
life cycles from different industries. That was helpful and should be reinstated.

41
PMBOK® Guide: Part 1 – Current Reality What Is Missing?

7.8 Benefits realization

The definition of a project in the guide focuses on the output – the output being a product, service,
or result. Whereas the project success definition should consider the outcome. Therefore, we must
distinguish between output and outcome.

The output is the project end product but outcome focuses on result and benefits realization. Consequently,
at least from the project owner perspective, limiting project success definition to scope, time, cost, and
quality is not enough. Project success must include the success of the objectives and realizing the expected
benefits. This dimension of success cannot be measured at completion or acceptance of the product.
Completion and acceptance do not necessarily means success!

The topic of benefits realization is usually left to program, rather than project management.

7.9 References and External Resources

This might be a political point, related to copyrights and PMI claims for ownership of the content of the
PMBOK® Guide. There are three points to stress here:

Some asks me, “Mounir, did you submit these suggestions and this work to PMI?”

My answer is no.

It is likely that PMI will not accept this work for inclusion into the PMBOK® Guide without SUKAD and me assigning
the copyrights to PMI, which is not something we are willing to do.

a) A good part of the content of the guide is from other sources, but nothing is referenced or
credited as the source. This practice is unfortunate.
b) Another challenge and one of the issues that led some volunteers to stop contributing to the
PMBOK® Guide is PMI position on copyrights. PMI mandates that the volunteers assign their
copyright to PMI for any content that they submit.
In other words, the volunteers have to give up their copyright and are not credited for their
contributions35.
c) In the guide, it clearly states that it is a “subset of the body of knowledge.” Consequently, why
is not there a reference to the other sources and external resources that can help completing
the picture; as much as possible36?

There are other items that could be missing; however these are the main points to discuss at this time.

7.10 Suggestion for improvement

Should the guide address these points?

We are dedicating the second e-book in the series to address improvements.

42
PMBOK® Guide: Part 1 – Current Reality What Is Not Emphasized Enough

8 What Is Not
Emphasized Enough?
8.1 Introduction
What has not been emphasized enough in the PMBOK® Guide is the subject of another short chapter.
There are various topics that are not missing from the guide but they are not emphasized enough, and
we think they should be. The recommendation is to put more effort in elaborating on these topics.

It is important to stress here that not all subjects can be addressed adequately in the PMBOK® Guide.
However, the guide can address what is possible and reference external resources where a topic requires
significant coverage.

8.2 Planning
We realize that half of the processes in the guide are planning related. However, the author believes that
there is a flaw. There is a hidden confusion between project management planning and project detailed
planning. Some knowledge areas split the two types (indirectly) others do not.

JUMP-START
ANYTIME,
NO-LIMITS
THE
MAXIMIZE
FAST ANSWER
ADOPTION, ANYWHERE
PRODUCTIVITY
LEARNING
CAREERS
TO FAST ROI
YOUR LEARNING NEEDS
LEVERAGE
LEARNING
HELP
EQUIP
GIVE STUDENTS
YOUR
BUSINESS SOCIAL
ABOUT
ENTIRE LEARNING,
ONLINE
GET
SAP QUALITY,
COLLABORATION,
USERS
ORGANIZATION
ACCESS SOFTWARE
TOTOADOPT FLEXIBLE,
A VAST BODYAND
QUALITY
HAS
ECONOMICAL
CONTENT,
SAP
OF
BUILD
NEVER KNOWLEDGE
SOLUTIONS. AND
EXPERTISE
BEEN TRAINING
ABOUT WHEN
HANDS-ON
EASIER.
AND
PRACTICE.
SAP
IN SAP WHERE
SOLUTIONS.
SAP Learning
SOFTWARE.
Hub –user
Hub, IT’S
the edition
choice
when, where, and what to learn
of NEEDED.
SAP
SAP Learning
SAP Learning Hub
Learning Hub
Hub, student edition

43
PMBOK® Guide: Part 1 – Current Reality What Is Not Emphasized Enough

How to improve?

Our approach is to split planning into two process groups, one for management planning, and the other
for detailed planning. Refer to the second e-book.

8.3 Project change management

There is only one process on project change management, “Perform Integrated Change Control”, which
is part of the project integration management area. This process does not provide enough coverage of
this critical topic. For example,

• There is no noticeable mention of the different types of changes on a project,

• There is no clarity on what is the control reference,
• It is not clear if there is one baseline or more along the project life cycle,
• There is no clarity on how to fund changes and whether all approved changes will change the
baseline or not.

On capital intensive projects (industrials, utilities, and real estate development) frequent changes can be
a significant factor and maybe the leading cause of project failure.

8.4 Scope management and scope creep

It is common for many practitioners to link scope management to change management. Although they
are related, they are not the same. On one aspect, changes could be related to non-scope items so not
every change is a scope change.

On the other side, scope management is not limited to “delivering the scope – no more – no less”. In other
words, we have what we call design development (progressive elaboration) items and we have scope
creep. What do these terms mean? How to differentiate them? How to handle them? Are they changes
or not? Are they covered by contingency or not? Does the guide provide clarity on these questions?

We realize that we are adding questions without answers since the objective is to highlight areas for
improvement rather than explain all aspects of project management. Further, the author does not have
all the answers.

8.5 Differentiating changes from variances

Similar to the previous point, there is no absolute clarity on the differences between variances, which
are deviations from plan and are performance related, versus changes, which are conscious decisions to
change an approved plan.

44
PMBOK® Guide: Part 1 – Current Reality What Is Not Emphasized Enough

8.6 Project success

If we are not mistaken, project success was not a dedicated topic in past editions of the PMBOK® Guide.
In the fifth edition, a brief definition was included but it is far from adequate.

The reason for our opinion is that project success varies depending on the context of the project, and
it must reflect the position of the organization interested in this question. For example, for a service
provider, success could mean profit and customer satisfaction. Whereas for a project owner, project
success can have multiple dimensions.

SUKAD has a four dimensions model for measuring project success that consider technical success,
project management success, project delivery success, and business objective success37.

8.7 Project management team

The guide presents information on project stakeholders and the team. The guide includes an image
showing those stakeholders who are involved (the team) and all others. The image clearly shows that the
team consists of the project manager, project management team members, and ‘other team members’.
The ‘other team members’ are those who will perform the work (executing).

Still, we often find quite a bit of misunderstanding in the project management community on the project
management team (PMT), and they do not understand what the PMT is. They think of one team that is
doing all the work, and this team includes the project manager. These practitioners do not understand
the roles of the different people on the project management team and the difference between ‘PMT
members’ and ‘other team members.’

8.8 Organizational context

The guide mentions the need to understand the project and organization environmental factors. It also
addresses the organizational process assets. It does not provide enough guidance on the link between
the two; using functional language to enhance the visualization.

8.9 Professional responsibility

It is interesting to see a topic like professional responsibility included in the certification exams but a
topic worth mentioning in the guide. Should it be in the guide or left to the code of conducts outside
the guide is enough? We leave this as an open question.

8.10 Closing
What do you think?

What do you agree with and what are the point of disagreement?

Do you have items to add to what we list here?

45
PMBOK® Guide: Part 1 – Current Reality What Are The Inconsistencies?

9 What Are The Inconsistencies?

9.1 Introduction
In the previous two chapters, we addressed what is missing and what is not emphasized enough in
the PMBOK® Guide. In this chapter, the focus is what the author believe are inconsistencies (some are
deficiencies or errors) in the guide.

9.2 Terminology – 138

The PMBOK® Guide is clear on that the process groups and processes repeat in every project phase.
This concept means that the initiating process group and its processes repeat and the same applies to
all other process groups. Most practitioners state that they understand this concept. However, some (or
many) do not understand what that means or how to apply the concept on a real project.

What does the Develop Project Charter process mean? How about Develop Project Management Plan and
other similar processes? Are these processes applicable to the phase or the project?

LEARN
ANYTIME,
NO-LIMITS
THE
MAXIMIZE
FAST
JUMP-START
ANSWER
ADOPTION,
BY ANYWHERE
DOING
PRODUCTIVITY
LEARNING
CAREERS
TO FAST ROI
YOUR LEARNING NEEDS
LEVERAGE
LEARNING
HELP
EQUIP
GIVE
DEVELOP STUDENTS
YOUR
BUSINESS SOCIAL
EXPERTISE
ABOUT
ENTIRE LEARNING,
ONLINE
GET QUALITY,
COLLABORATION,
USERS
SAP
ORGANIZATION
ACCESS
IN SAP SOFTWARE
TO
SOLUTIONS
TOADOPT FLEXIBLE,
A VAST BODYAND
QUALITY
HAS
ECONOMICAL
CONTENT,
SAP
OF
BUILD
NEVER
THROUGH
KNOWLEDGE
SOLUTIONS. AND
EXPERTISE
BEEN TRAINING
EXPLORATION ABOUT WHEN
HANDS-ON
EASIER.
AND
PRACTICE.
SAP
IN SAP WHERE
SOLUTIONS.
PRACTICE.
SAP Learning
SOFTWARE.
Hub –user
Hub, IT’S
the edition
choice
when, where, and what to learn
of NEEDED.
SAP
SAP Learning
SAP Learning
Learning
Live Hub
Hub
Hub, student edition
Access

46
PMBOK® Guide: Part 1 – Current Reality What Are The Inconsistencies?

If these processes are for the project or phase, as is often repeated in the guide, then why the names of
these processes include the word ‘project’? When some professionals read Develop Project Management
Plan, they think ‘project’ not ‘phase.’ When they read Direct and Manage Project Work, they think ‘project’
and not ‘phase.’

This naming nomenclature is contributing to creating significant confusion since some practitioners
even believe that projects are single phase. Even if they believe a project is multi-phase they think the
process groups apply once and they are the project phases. They think there is one charter that is fixed
and never change. They also believe that there is one management plan with subsidiary plans from the
knowledge areas; there is one estimate, one schedule, one procurement, one team, and everything else
that goes with it.

9.3 Terminology – 2
In every new edition of the PMBOK® Guide there are changes to the names of some processes. The
changes are due to an attempt to unify the naming nomenclature.

In the current edition, it uses direct action words like “plan”, “define”, “create”. However, in some cases
the name of a process reflects the output and other times, it is not as clear.

For example, “Create WBS” gives an indication that the output is a WBS. However, the output of Define
Scope is what? Is it scope defined, as some of our students’ joke? The output is a scope statement. Similarly,
the output of define activities is not the definition of the activities; rather it is an activities list. This point
is not a major issue, just a suggestion. Alternatively, maybe the process names should be Develop Scope
Statement or Create Activities List.

The same approach could apply to other processes, where applicable.

9.4 Audit
When you hear the word “audit,” what comes to mind?

Let us clarify the question: When you hear the word “audit,” which PMBOK® Guide process group
comes to mind?

A refresher: the PMBOK® Guide process groups are initiating, planning, executing, monitoring and
controlling, and closing.

So which one did you decide on?

Do you have a clear idea?

47
PMBOK® Guide: Part 1 – Current Reality What Are The Inconsistencies?

Are you confident with your answer?

Is the word “audit” mentioned consistently in one process group, in the PMBOK® Guide?

Let us see:

• Quality Audit is part of Perform Quality Assurance process, which is part of the executing
process group.
• Risk Audit is in monitoring and controlling process group; maybe because there is no executing
process for the risk knowledge area.
• Based on the above, the procurement audit must be executing or monitoring and controlling
but it is not. It is part of the closing process group.
• Scope Audit: we could not find a direct reference that is clearly labeled scope audit, but there is
something called validate scope and validate the product. So what do you think? Is the audit to
verify scope fulfillment part of validate scope (monitoring and controlling) or validate product
that is in the closing process group (not as an independent process).

Why is this inconsistency?

Is it possibly because a different team does each chapter?

Alternatively, there could be justification for these inconsistencies that the author is missing or maybe
this is the way they should be and there is no inconsistency.

Finally, if the audit is about verifying that the team is following procedures, complying with
standards, etc. is not this is a monitoring and controlling function?

9.5 Quality assurance

Quality assurance is listed as an executing process.

If one thinks about this process and what it is all about, it includes assessment, audit, and reviews; are
not these controlling activities? We realize that part of quality assurance is a management action but it
is mostly about control, do not you agree?

Further, if the executing process group does not include time or cost related processes, then why it
does include quality? The reference here is that quality, time, and cost are constraints and related to the
delivery of the scope and work.

48
PMBOK® Guide: Part 1 – Current Reality What Are The Inconsistencies?

9.6 Pre-project
Per the PMBOK® Guide, the project concept phase, which covers the time span from idea to decision
on authorizing the project is called pre-project and is outside the project life cycle.

Why is this?

Is not the pre-project work (pre project charter) a phase like any other phase of the project?

Remember, the PMBOK® Guide focuses on the processes to manage a phase or a project; therefore, by
excluding this early phase from the project life cycle, is the PMBOK® Guide telling us that the process
groups do not apply in this phase?

9.7 Project life cycle and project success

We touched on this in the earlier chapter but expand on it here.

The definition of a project is that it is temporary, primarily because it is not about the operation.

HANDS-ON PRACTICE
ANYTIME,
NO-LIMITS
THE
MAXIMIZE
FAST
JUMP-START
LEARN ANSWER
ADOPTION,
BY ANYWHERE
DOING
PRODUCTIVITY
LEARNING
CAREERS
TO FAST ROI
FOR EFFECTIVE LEARNING
YOUR LEARNING NEEDS
LEVERAGE
LEARNING
HELP
EQUIP
GIVE
DEVELOP
EXPERIENCESTUDENTS
YOUR
BUSINESS SOCIAL
EXPERTISE
ABOUT
ENTIRE LEARNING,
SAPONLINE
GET
USERS
SAP
IN SAPQUALITY,
COLLABORATION,
ORGANIZATION
ACCESS SOFTWARE
TO
SOLUTIONS
TO ADOPT
A FLEXIBLE,
VAST HAS
BODYAND
QUALITY
SOFTWARE FIRSTHAND
ECONOMICAL
CONTENT,
SAP
OF
BUILD
NEVER
THROUGH
KNOWLEDGE
SOLUTIONS. AND
EXPERTISE
BEEN TRAINING
EXPLORATION ABOUT WHEN
HANDS-ON
EASIER.
TO BUILD KNOWLEDGE
AND
PRACTICE.
SAP
IN SAP WHERE
SOLUTIONS.
PRACTICE.
SAP Learning
SOFTWARE.
Hub –user
Hub, IT’S
the edition
choice of NEEDED.
AND
SAP
ENHANCE
when, where,
SAP Learning
Learning
and what to learn SKILLS.
Hub
Hub
SAP Learning
SAP Live
Live Hub, student edition
Access
Access

49
PMBOK® Guide: Part 1 – Current Reality What Are The Inconsistencies?

In the fifth edition of the guide there is a definition for project success. The definition states the possible
inclusion of an operation (test) period to determine project success. “To ensure realization of benefits for
the undertaken project, a test period (such as soft launch in services) can be part of the total project time
before handing it over to the permanent operations.” (The Project Management Institute, 2013)39

Here, it is important to note that in the project life cycle of the CAM2P™ Model, we do have what we call
Project Operation Readiness Stage, which include a pilot or initial operations, what PMI is calling a test
period. Therefore, we agree with this PMBOK® Guide position on including a test period for measuring
project success; it is one of the SUKAD four dimensions; mentioned in an earlier chapter.

However, from PMBOK® Guide consistency perspective, we think there an issue. Let us dissect that
definition:

• The operation is not part of a project life cycle per the guide. If a test period is necessary then
is not this change in the definition of a project and the project life cycle?40
Some colleagues think the trial period can be part of the project life cycle (again we agree) but
is it part of the definition of a project? Remember, the definition of a project in the guide is to
deliver output, as a product. In this case, is the output the facility for example or a comissioned
facility? The difference can be huge and a function of the project domain. For example, testing
a software product is completely different from operating a power plant. Again – our point is
consistency among the different parts of the guide.
• “To ensure benefits realization…” is this something that can be assessed within a trial period?
Benefits realization may require significant time after testing and acceptance before the
organization can assess effectively. By including this in the definition, then the project and
project life could extend for years.
• “Part of the total project time before handing it over to the permanent operations,” does this means
the project team will operate the project during this test period? Do they have the right level
of expertise? In the CAM2P™ Model, operations resources will manage this stage of the project.

9.8 Manage the team: where is control?

In the third edition of the PMBOK® Guide, there was a process called, “Manage Project Team” in the
monitoring and controlling process group. In the fourth edition, this process moved to executing process
group, and it is still there per the fifth edition. We are assuming because of the word “manage” the process
was moved since the intention is any process with the word “manage” must be an executing process41.

50
PMBOK® Guide: Part 1 – Current Reality What Are The Inconsistencies?

This change creates a question; does not the project team (human resource knowledge area) needs
monitoring and controlling process? Every knowledge area has a control process, even communication
and stakeholder but human resource now (in the fourth and fifth editions) is the only area without a
controlling process. This implies that we only manage the team, but we do not control the team. ‘Manage’
and ‘Monitor & Control’ are related concepts but throughout the guide and in business are treated as
separate types of actions so why not in the human resource area?

Let us visualize the situation.

• If the project manager discovers a team member, that is not performing. Is not this a monitoring
function? Then the project manager takes action (act) to replace this team member, is not this
a controlling action?
• While working on a project, the team realizes that they do not have enough people, or too
many, or not the right skills, and there are needs for adjustments. Are not these monitoring
and controlling actions?

What should have been done is splitting this process into manage the team, which would be about
directing and coordinating the teamwork, and control human resource (or control project team) to
handle any control aspects.

9.9 Acquire the team

Another area of confusion, we often notice among our workshop participants is the process “Acquire the
Team,” which is an executing process. When professionals see questions related to this process, or hear
the term “acquire” they think initiating process group. What is implied in the guide is the following:

• The project manager, which is part of the team, is acquired in the initiating process group, or
early in the project life cycle.
• The project management team, which is also part of the team, is acquired at the start of the
planning process group to work with the project manager in developing the project plans.
• The rest of the project team, which is the “doers”, the technical people that will do the work,
will be acquired at the start of the executing process group. It is noted that in term of numbers,
this part of the team is largest but should a process exist only for this part of the team and not
the other parts?

On small projects, this might be acceptable since it is possible that there is no planning team and the
project manager, and the whole team could be a few people. However, on larger and more complex
projects, selecting the right project manager and project management team is an extensive and time-
consuming process, so why is it only implied in the PMBOK® Guide and not explicitly stated through
dedicated processes?

51
PMBOK® Guide: Part 1 – Current Reality What Are The Inconsistencies?

9.10 Scope and executing

In our workshops, we are often asked a question, “how come there is no executing process for the scope
chapter?” We do not have an answer, and this is a justified question.

If one thinks about the process:

• The team defines the scope and creates the WBS (work packages) in scope planning.
• Then the team validates and controls scope (the work packages) in scope controlling.
• Where is the completion of (executing) the work packages?

Do we just plan for them and validate their completion but there is no process for completing them?
Alternatively, is the ‘Direct and Manage Project Work’ the intended process to cover the work packages
completion? It should not be.

What we have now is that we plan and control scope (work packages) in the scope chapter but we
perform the work and complete these work packages in integration, or is missing. We would love to
hear the logic behind this.

We think there is a need for direct and manage project work in integration and complete work packages
in executing in the scope chapter.

ANYTIME, ANYWHERE
LEARNING ABOUT
SAP SOFTWARE HAS
NEVER BEEN EASIER.
SAP Learning Hub – the choice of
when, where, and what to learn

52
PMBOK® Guide: Part 1 – Current Reality What Are The Inconsistencies?

9.11 Where is the control reference?

In numerous sections of the PMBOK® Guide, there are numerous mentions of management plans and
baselines. The guide also emphasizes that control must be against the baselines. The plural is to reflect
that there is more than one baseline such as cost, scope, time, and others.

Okay, Control is against the approved plans (baselines) but is this totally correct?

Are the baselines fixed at the time of project management plan approval?

When we ask the above questions, the common answer is that the baselines are the approved plans at
the end of the planning process groups and control starts once we start executing; in parallel.

The above scenario is not 100% accurate.

• If we consider the process groups, then control starts as soon as the team starts the initiating
process group with the control reference being the statement of work. Further, control continues
during planning in comparison to a charter. Finally, control will shift and use the project
management plan as the control reference, once a plan is approved.
This concept is implied in the guide but not clearly stated. To repeat and emphasize, the first
control reference is in comparison to the statement of work, the second control reference is
the charter, and then the management plan.
• If we consider the project life cycle, then control starts with the idea statement then move
along the project life cycle with the control reference moving along the project life cycle with
every new project deliverables.
• Control is at two levels (like everything else), project level following the project life cycle and
stage level following the process groups.

9.12 Monitor and control

The origin of the process groups build on the Total Quality Management principle of Plan – Do – Check –
Act (PDCA Cycle)42. The PDCA cycle is transformed into the process groups where:

• The planning process group replaces “plan”,

• The executing process group instead of “do”, and
• The monitoring and controlling process group is replacing “check” and “act”.

53
PMBOK® Guide: Part 1 – Current Reality What Are The Inconsistencies?

Figure 2: The Plan – Do – Check – Act Quality Cycle

Since projects are temporary and not ongoing, the PMBOK® Guide added initiating and closing to
the PDCA cycle. It is worth noting that the PDCA cycle originated in the operating, manufacturing
environment, where operation is ongoing.

What can one notice here?

Figure 3: The PDCA Cycle with Initiating and Closing

The PMBOK® Guide combined the “Check” and “Act” into one process group, “Monitoring and
Controlling.” To emphasize: instead of two separate types of actions – checking (monitoring) and acting
(controlling) now we have monitoring and controlling as one group.

Is this an issue?

Is there justification for splitting monitoring from controlling?

In general, monitoring is usually a role for the project management team members who handle monitoring
the performance and to compare actual versus plan. Whereas control is a project manager or sponsor
action, depend on the nature of the action.

54
PMBOK® Guide: Part 1 – Current Reality What Are The Inconsistencies?

Next, we will elaborate on the previous point and the difference between monitoring and controlling.
In Section 9.8 we stated that there is often confusion on the project management team and who are its
members. On capital projects, there is often a position that might be titled ‘project control specialist
(or engineer)’. The title is misleading since the person holding this position is typically responsible for
monitoring performance, comparing actual against the plan, and reporting any variances. In some cases,
this position can also recommend corrective or preventive action but cannot make the decision. The
decision is with the project manager, sponsor, or even other management personnel.

Therefore, it is our preference to split monitoring from controlling, in line with the original PDCA
concept. However, we are not making a strong case for recommending a split at this time. Maybe a
future discussion.

9.13 Conclusion and recommendations

How do we decide if these inconsistencies are valid?

How do we identify other inconsistencies?

These and similar questions are necessary to improve the PMBOK® Guide rather than just update it –
often cosmetically. The recommendations will be in the second e-book.

ANYTIME, ANYWHERE
NO-LIMITS LEARNING
LEVERAGE
LEARNING ABOUT SOCIAL LEARNING,
COLLABORATION,
SAP SOFTWARE HAS QUALITY
CONTENT,
NEVER BEEN AND HANDS-ON
EASIER.
PRACTICE.
SAP Learning Hub – the choice of
when, where, and what to learn

55
 Section III:
Process Groups Confusion

56
PMBOK® Guide: Part 1 – Current Reality The Project Life Cycle

10 The Project Life Cycle

10.1 Introduction
The chapters in this section of the e-book are included here to highlight a major area of confusion in the
project management community today. There have been numerous discussions and debates on online
communities on this subject yet the confusion remains. The confusion is related to many practitioners
and even PMI certificates holders thinking that the process groups are project phases and the project
life cycle consists of the process groups as its phases. The chapters in this section build on each other.

10.2 Project life cycle definition

What is the project life cycle?

Here are a few points to define it:

• The simple answer is the project life cycle is a span of time from start to the end of a given
project. However, where the beginning and end are, is not as simple as it sounds.
• Some project management practitioners use the term project life span for this concept.
• A typical project life cycle consists of a few phases or stages43.

THE ANSWER
ANYTIME,
NO-LIMITS ANYWHERE
LEARNING
TO
YOUR LEARNING NEEDS
LEVERAGE
LEARNING ABOUT SOCIAL LEARNING,
GET
SAP QUALITY,
COLLABORATION,
SOFTWARE FLEXIBLE, AND
QUALITY
HAS
ECONOMICAL
CONTENT,
NEVER BEEN AND TRAINING WHEN
HANDS-ON
EASIER.
AND
PRACTICE.WHERE
SAP Learning IT’S
Hub – the choice
when, where, and what to learn
of NEEDED.

57
PMBOK® Guide: Part 1 – Current Reality

At this point, it is critical to distinguish between project life cycle and other ‘life cycles’ such as product
life cycle and program life cycle.

• A product life cycle is the life of a product (building, hospital, software, medicine) which
starts with the concept for the product and go through phases – including operation and
maintenance – and ends with taking the product of the market. During the product life, there
can be numerous projects and programs and each with its own life cycle.
• A program life cycle is about the span of time – start to finish – of a program. A program
typically includes numerous projects that can be in sequence or with some overlaps. Therefore,
during the program life there are many projects and each project with its own project life cycle.
• There could be other concepts that include the term “life cycle” but they are not directly
relevant here.

Further, a project life cycle must be specific to a given project and not a sub-project, a program, nor a
product. Finally, it is also important to recognize that a project could be part of a program or independent
of one. However, all projects are part of the organizational portfolio.

10.3 Project life cycle is a variable

In project management, the project life cycle is a variable. This means that the project life cycle is highly
dependent on the industry and project domain. Therefore, the number of phases, their names, and other
life cycle elements vary from one domain to another. Consequently, there is no fixed project life cycle
for all projects. Nonetheless, within the same domain the project life cycle could be similar from one
company to another; at least the main phases.

However, we also need to consider the perspective of the organization when we discuss life cycles, and
this is next.

10.4 Whose perspective

The earlier definition is generic and can lead to different opinions. Therefore, the question ‘what is the
project life cycle’ cannot be fully answered until we know more about the scenario.

For example, who wants to know?

From whose perspective is the question?

What is the background of the person asking or what type of organization does she represents?

This point is important since the word project and the phrase project life cycle can mean different things
to different people; it all depends on how you relate to the scenario. As a result, before one can answer
the life cycle question, one needs to determine if the questioner is a service provider or a project owner.

58
PMBOK® Guide: Part 1 – Current Reality The Project Life Cycle

10.5 Project owner perspective

Who is the project owner?

The term ‘project owner’ refers to the organization that is launching the project, who will develop it,
operate its product, and own it.

Project owners’ launch projects in response to business threats or opportunities44. They do so because there
is a business case for the project, and they expect benefits from the product, the output of the project.

A given project life cycle depends on the domain of the project; consequently, the number of project
phases and their names will vary from one domain to another. From the project owner perspective, the
project life cycle consists of many phases.

Figure 4 is an image representing a project life cycle model developed by SUKAD, which is The
Customizable and Adaptable Methodology for Managing Projects™, CAM2P™.

This image represents the standard model but as the name indicate, this model must be customized
and adapted to fit the organizational environment and the project type. Explaining this model is
outside the scope of the book, and the reader can refer to SUKAD website or other publications for
in-depth understanding.

Figure 4: The Customizable and Adaptable Methodology for Managing Projects™ (CAM2P™)

59
PMBOK® Guide: Part 1 – Current Reality The Project Life Cycle

10.6 Service provider perspective

A service provider is any organization providing services to a project owner, such as vendors, consultants,
contractors, and even freelancers.

The project from the perspective of a service provider could only

be a phase from the project owner perspective.

From a service provider perspective, the project life cycle will be different, depending on many factors.
Part of the factors might be specific to the service provider internal organizational project management
system. Other factors are related to the work the service provider is doing for a client, the project owner.

For example, if the supplier is an organization specializing in market research and feasibility studies,
then they could be involved in the project concept phase (the first phase in the standard model). If the
provider is a construction company, they would be participating in the project delivery phase. In other
words, the project from the perspective of the service provider could only be a phase from the project
owner’s perspective.

MAXIMIZE
ANYTIME,
NO-LIMITS
THE ANSWER ANYWHERE
PRODUCTIVITY
LEARNING
TO
YOUR LEARNING NEEDS
LEVERAGE
LEARNING
HELP YOURABOUT SOCIAL
ENTIRELEARNING,
GET
SAP QUALITY,
COLLABORATION,
ORGANIZATION
SOFTWARE FLEXIBLE, AND
QUALITY
HAS
ECONOMICAL
CONTENT,
BUILD
NEVEREXPERTISE BEEN AND TRAINING WHEN
HANDS-ON
EASIER.
AND
PRACTICE.
IN SAP WHERE
SAP Learning
SOFTWARE. IT’S
Hub – the choice
when, where, and what to learn
of NEEDED.

60
PMBOK® Guide: Part 1 – Current Reality The Project Life Cycle

It is also possible that the provider’s services can be end-to-end; almost matching the project owner’s
project life cycle. The following image is one possibility for a service provider’s project life cycle for work
done for a client.

Figure 5: Project Life Cycle (Span) for Service Provider – for a Service Project

It is important to note before closing this section; if a project is internal to the service provider, then in
this scenario the service provider is the project owner, and the standard model will apply.

10.7 Closing remarks

This chapter covered more than we need for the context of the book since it touched on the different
types of life cycles and from different perspectives. However, this coverage serves as the foundation for
what comes next.

61
PMBOK® Guide: Part 1 – Current Reality Project Phases and Stages

11 Project Phases and Stages

11.1 Introduction
In most of this e-book, we treated phases and stages as interchangeable terms since they are often treated
like that they are equivalent. In this chapter, we split them and address the differences here.

11.2 Phase or stage

For better control, it is common to divide the project life cycle into time segments that may resemble
the figure below. While it is common to refer to these time segments as phases, others refer to these
time segments as stages.

Figure 6: Typical Project Life Cycle with Phases

11.3 Phases
In the SUKAD CAM2P™ Model45, we use phase and stage as two separate items. The main reason for
this is to fix one (phases) across project domains while keeping the others as variable (stages). There are
other reasons that will become clearer later on. In any case – the users can decide whether they want to
follow our approach or keep using one term.

Figure 7: Project Phases according to CAM2P™ model

In CAM2P™ we use the term phase to refer to three major time segments that span the project from start
to finish., and we believe that they are universal and transverse industries and types of projects. However,
the names of phases might be different about industries and application areas.

These CAM2P™ phases are:

• The Project Concept Phase,

• The Project Development Phase, and
• The Project Delivery Phase.

In this chapter, and the following chapters, we are referring to the SUKAD CAM2P™ Model since it is a methodological
approach that we developed to supplement the PMBOK® Guide and would help demonstrate how to apply the
PMBOK® Guide concepts via a project life cycle method.

62
PMBOK® Guide: Part 1 – Current Reality Project Phases and Stages

11.4 Stages
In the CAM2P™ Model, we also use the term stage to refer to six-time segments that span the project
from start to finish. These stages are sub-phases, and they can significantly overlap.

These stages could be adjusted (merged, expanded, split) to reflect better the specific industry or
application area of the project. In other words, they can be adjusted through ‘customizing and adapting
the model’.

Figure 8: Project Phases and Stages according to the CAM2P™ Standard Model

FASTANSWER
ANYTIME,
NO-LIMITS
THE
MAXIMIZE ADOPTION, ANYWHERE
PRODUCTIVITY
LEARNING
TO FAST ROI
YOUR LEARNING NEEDS
LEVERAGE
LEARNING
HELP
EQUIP YOUR
BUSINESS SOCIAL
ENTIRELEARNING,
ABOUT
GET
SAP QUALITY,
COLLABORATION,
USERS
ORGANIZATION
SOFTWARE
TO ADOPT FLEXIBLE, AND
QUALITY
HAS
ECONOMICAL
CONTENT,
SAP
BUILD
NEVER SOLUTIONS. AND
EXPERTISE
BEEN TRAINING
EASIER. WHEN
HANDS-ON
AND
PRACTICE.
IN SAP WHERE
SAP Learning
SOFTWARE.
Hub –user
Hub, IT’S
the edition
choice
when, where, and what to learn
of NEEDED.
SAP
SAP Learning
Learning Hub
Hub

63
PMBOK® Guide: Part 1 – Current Reality Project Phases and Stages

The stages of the CAM2P™ standard model are:

• The Project Pre-Launch Stage,

• The Project Launch Stage,
• The Project Definition Stage,
• The Project Implementation Stage,
• The Project Operation Readiness Stage, and
• The Project Close Stage.

It is worth noting – that in cases where one term is used (phase), they would refer to these stages as
phases. In those situations, the SUKAD three phases are eliminated. We strongly recommend using
both concepts and if you like the term phase then call them phases and sub-phases, or sub-projects and
phases, whatever is more logical or acceptable to your organization.

11.5 Closing comments

The CAM2P™ Model, is not unique; many other organizations have their internal project management
methods that are similar to what we present here, although they may use different terms for the phases
and/or stages.

With this chapter and the previous one, we have defined a project life cycle model that we will use for
comparison with the PMBOK® Guide process groups; in an upcoming chapter. First, let us revisit the
process groups.

64
PMBOK® Guide: Part 1 – Current Reality The Process Groups

12 The Process Groups

12.1 Introduction and overview
In the minds of many students, project management professionals (PMP), and practitioners following
the PMI framework, the process groups are a prominent part of the PMBOK® Guide. The following are
the main points relating to process groups; some are repeated from earlier chapters.

• The term process groups is made popular by the PMI® since it is an essential part of the
PMI framework; as described in PMBOK® Guide.
• Process groups refer to a particular group of processes, each group consisting of two or more
processes that are used to help practitioners manage a project or a phase of a project.
• These process groups are called: Initiating, Planning, Executing, Monitoring & Controlling,
and Closing (The Project Management Institute, 2013).
• Together, these process groups encompass 47 processes.
• The five process groups have been around since the original PMBOK® Guide was published in
1996. In other words, there is no change in the number or names of the groups.
• However, the number of processes within these groups does change from one edition to another;
as highlighted earlier.
• It is also possible that some specific processes shift from one process group to another or one
knowledge area to another with every update of the guide.

12.2 How do we use the process groups?

We apply phase initiating, phase planning, phase executing, and phase closing, as well as phase monitoring
and controlling throughout each phase46. Once we conclude a phase, we move to the next phase, and
we repeat the applicable processes.

The process groups and their processes repeat in every phase of the project.

The unfortunate situation is: many practitioners do not understand, or have forgotten, the above ritual.
These practitioners think that “we initiate the project, plan the project, execute the project, monitor and
control the project, and close the project.”

In an earlier chapter, we had stated that the use of the word ‘project’ in the name of some of the processes
contributes to this confusion. Therefore, this practice indirectly lead project management practitioners
to think that these process groups are project phases, with the initiating phase, planning phase and so
on. Keep reading.

65
PMBOK® Guide: Part 1 – Current Reality The Confusion

13 The Confusion
13.1 Introduction
This chapter continues to build the case and presents the confusion between the PMBOK® Guide Process
Groups and a typical project life cycle.

Many practitioners and students of project management  misunderstand  the PMBOK® Guide. When
we ask them to name the stages of the project life cycle they provide the name of the process groups as
stages; per the figures below.

Figure 9: How Some Practitioners of Project Management Understand the Project Life Cycle

JUMP-START
ANYTIME,
NO-LIMITS
THE
MAXIMIZE
FAST ANSWER
ADOPTION, ANYWHERE
PRODUCTIVITY
LEARNING
CAREERS
TO FAST ROI
YOUR LEARNING NEEDS
LEVERAGE
LEARNING
HELP
EQUIP
GIVE STUDENTS
YOUR
BUSINESS SOCIAL
ABOUT
ENTIRE LEARNING,
ONLINE
GET
SAP QUALITY,
COLLABORATION,
USERS
ORGANIZATION
ACCESS SOFTWARE
TOTOADOPT FLEXIBLE,
A VAST BODYAND
QUALITY
HAS
ECONOMICAL
CONTENT,
SAP
OF
BUILD
NEVER KNOWLEDGE
SOLUTIONS. AND
EXPERTISE
BEEN TRAINING
ABOUT WHEN
HANDS-ON
EASIER.
AND
PRACTICE.
SAP
IN SAP WHERE
SOLUTIONS.
SAP Learning
SOFTWARE.
Hub –user
Hub, IT’S
the edition
choice
when, where, and what to learn
of NEEDED.
SAP
SAP Learning
SAP Learning Hub
Learning Hub
Hub, student edition

66
PMBOK® Guide: Part 1 – Current Reality The Confusion

The difference between the top and bottom part of the figure is the addition of “Monitoring & Controlling”
in the lower part. In the top part, it is not showing the monitoring and controlling processes are
active across the whole project life cycle and is not a phase. However, some practitioners even refer to
Monitoring & Controlling as a separate phase, and they add it to the picture (per the bottom part). In
other words, these practitioners think the project life cycle – for all types of projects – consist of four
or five fixed phases.

What they do not recognize is that:

• The process groups ARE NOT project phases or stages, and

• These process groups repeat in every phase or stage.

The situation is not limited to individuals since some organizations are starting to name their project
phases after the process groups. Therefore, it is not uncommon today to see organizations that have an
initiating, planning, executing phases.

It is not a problem with whatever names individuals and organizations use for their project phases, as
long as they understand that a planning phase is different from the planning processes, and the execution
phase is not the same as executing processes. For example, a planning phase might be a small span of
the overall project time span while the planning processes will span most of the project life cycle as the
work progress from one phase to another.

As we said, names are not critical as long as we differentiate phases from process groups. The reality is
that we find these individuals and organizations using the process groups as project phases, and this is
critical since it will have direct negative consequences on projects’ performance.

In other words, the confusion is not limited to terminology but it is even in the practice. Organizations
and individuals do believe that planning processes are the same as the planning phase, and closing
processes are the same as the closing phase.

13.2 Opinion or fact?

In case, there is still some doubt {that the process groups are not phases} what we present here is not
an opinion, it is a fact. It is clearly stated in the PMBOK® Guide, and here are references to prove it:

• The PMBOK® Guide is clear that the project life cycle consists of phases (not process groups);
chapter 2, section 2.4, starting on page 38 (The Project Management Institute, 2013).
• The guide is also clear that the process groups repeat in every phase; Chapter  2, page  43,
Figures 2-11 and 2-12; and Chapter 3, page 52, Section 3.2. Same reference.

67
PMBOK® Guide: Part 1 – Current Reality The Confusion

13.3 So Why the confusion?

We are sure that some readers are thinking at this time “we know this” and yes, many do know this.
However, when it comes to applying some of them stumble and fall back into thinking the process
groups are phases.

If the PMBOK® Guide is clear on this, then why do so many practitioners and project management
professionals (PMP certificate holders and even program managers) miss this point?

Why are even organizations confusing project phases with process groups?

We suggest that the following are possible explanations:

• Many do not carefully read the PMBOK® Guide, and if they do, they focus on processes, inputs,
tools & techniques, and outputs, which repeat in the guide 47 times.
• The focus on the processes, process groups and knowledge areas often lead a person away from
the first chapters of the guide where the guide presents the project life cycle.
• The terminology inconsistency that was discussed earlier, which is using the word ‘project’ in
the name of processes that are about the project or phase.

There are many other reasons but maybe not politically correct to state them here. The unfortunate
thing is that there are many publications and posts on PMI owned or associated websites and by PMI
approved educational providers that help in spreading this confusion instead of taking a proactive role
to clarify it and mitigate its effect.

68
PMBOK® Guide: Part 1 – Current Reality Clearing the Confusion

14 Clearing the Confusion

14.1 Introduction
In this chapter, will attempt to clear the confusion by mapping the PMBOK® Guide Process Groups to
a project life cycle.

Just a reminder of a few important concepts:

• The project life cycle, in general, is a variable – it changes from one domain to another and
even for the same type of projects it could vary.
• The project life cycle consists of phases and stages.
• The process groups are “fixed” and applicable regardless of the type of project or domain.
• The process groups repeat for every phase, per the PMBOK® Guide.

14.2 Phase perspective

The PMBOK® Guide clearly states that the process groups occur in every phase, and they are not phases
themselves. This statement is worth repeating because of its importance.

LEARN
ANYTIME,
NO-LIMITS
THE
MAXIMIZE
FAST
JUMP-START
ANSWER
ADOPTION,
BY ANYWHERE
DOING
PRODUCTIVITY
LEARNING
CAREERS
TO FAST ROI
YOUR LEARNING NEEDS
LEVERAGE
LEARNING
HELP
EQUIP
GIVE
DEVELOP STUDENTS
YOUR
BUSINESS SOCIAL
EXPERTISE
ABOUT
ENTIRE LEARNING,
ONLINE
GET QUALITY,
COLLABORATION,
USERS
SAP
ORGANIZATION
ACCESS
IN SAP SOFTWARE
TO
SOLUTIONS
TOADOPT FLEXIBLE,
A VAST BODYAND
QUALITY
HAS
ECONOMICAL
CONTENT,
SAP
OF
BUILD
NEVER
THROUGH
KNOWLEDGE
SOLUTIONS. AND
EXPERTISE
BEEN TRAINING
EXPLORATION ABOUT WHEN
HANDS-ON
EASIER.
AND
PRACTICE.
SAP
IN SAP WHERE
SOLUTIONS.
PRACTICE.
SAP Learning
SOFTWARE.
Hub –user
Hub, IT’S
the edition
choice
when, where, and what to learn
of NEEDED.
SAP
SAP Learning
SAP Learning
Learning
Live Hub
Hub
Hub, student edition
Access

69
PMBOK® Guide: Part 1 – Current Reality Clearing the Confusion

The process groups are happening within a phase, as we explain here. Figure 10 presents the process
groups for a typical project stage47 and the following is a brief explanation:

Figure 10: The Process Groups within a Typical Project Stage

• Notice the ‘I’ in the oval at the start of the stage, which indicates initiating the stage.
• Then, there is an arch and the letter ‘P’, indicating planning the stage. The reason it is an arch
is to indicate the overall perspective and that the plan should cover the stage work, end-to-end.
To be clear, the plan should be completed shortly after initiating the stage.
• Further, there is a horizontal arrow with the letter ‘E’, indicating executing the stage. The start
of executing starts once the plan is approved and ends just before closure.
• Then another horizontal arrow for monitoring and controlling during the stage. Notice, this
arrow is longer than the executing arrow; it starts before the beginning of executing and ends
after it. The length of the arrow is to reflect that monitoring and control touch all process groups
and begins with initiating and ends with closing. This is important since some practitioners
think that control is parallel to executing.
• Finally, there is the ‘C’ on the right showing the closure of the stage.

14.3 Project Perspective

It is time to review the process groups in comparison to the project life cycle. Imagine the project as
one phase as you read the next few paragraphs.

14.3.1 Initiating

Figure 11 shows the project stages per the CAM2P™ standard model. The six stages are shown linearly
here48. This illustration shows an ‘I’ in the oval near the left side of the Project Pre-Launch Stage indicating
project initiation, this is per the CAM2P™ Model. It might be useful to refer to figure 4, from earlier in
the e-book, as you read the next few sentences.

70
PMBOK® Guide: Part 1 – Current Reality Clearing the Confusion

Figure 11: The Project Life Cycle with Initiating Process Group

• Per CAM2P™, projects are initiated once the Idea Statement is approved at Stage Gate 1; this is
why the “I” is close to the left edge of the Project Pre-Launch Stage.
• On the other hands, the project charter, of the PMBOK® Guide, would be on the right side of
the Project Pre-Launch Stage.
• The PMBOK® Guide basis is that the pre-project work has been completed before the charter
(The Project Management Institute, 2013)49.

14.3.2 Planning

After initiating the project, it is time to plan the project, the whole project.

Figure 12: The Project Life Cycle with the Planning Process Group

Planning the entire project is represented by the arch and the letter ‘P’ as shown in Figure 12.

71
PMBOK® Guide: Part 1 – Current Reality Clearing the Confusion

This plan is a general, high-level plan with a limited amount of details. Let us emphasize the points
and elaborate:

• First, this is the plan for the whole project; not a stage.
• It is high-level because there are not enough details at this time on the project life cycle; at
least for the subsequent stages.
• Each of the next stages will have its own stage management plan this would use the project
management plan as a starting point.
• In CAM2P™, this project management plan is produced in the project launch stage.
• Since the project management plan takes the perspective of the whole project, notice the arch
stretches to the very end of the project life cycle.

HANDS-ON PRACTICE
ANYTIME,
NO-LIMITS
THE
MAXIMIZE
FAST
JUMP-START
LEARN ANSWER
ADOPTION,
BY ANYWHERE
DOING
PRODUCTIVITY
LEARNING
CAREERS
TO FAST ROI
FOR EFFECTIVE LEARNING
YOUR LEARNING NEEDS
LEVERAGE
LEARNING
HELP
EQUIP
GIVE
DEVELOP
EXPERIENCESTUDENTS
YOUR
BUSINESS SOCIAL
EXPERTISE
ABOUT
ENTIRE LEARNING,
SAPONLINE
GET
USERS
SAP
IN SAPQUALITY,
COLLABORATION,
ORGANIZATION
ACCESS SOFTWARE
TO
SOLUTIONS
TO ADOPT
A FLEXIBLE,
VAST HAS
BODYAND
QUALITY
SOFTWARE FIRSTHAND
ECONOMICAL
CONTENT,
SAP
OF
BUILD
NEVER
THROUGH
KNOWLEDGE
SOLUTIONS. AND
EXPERTISE
BEEN TRAINING
EXPLORATION ABOUT WHEN
HANDS-ON
EASIER.
TO BUILD KNOWLEDGE
AND
PRACTICE.
SAP
IN SAP WHERE
SOLUTIONS.
PRACTICE.
SAP Learning
SOFTWARE.
Hub –user
Hub, IT’S
the edition
choice of NEEDED.
AND
SAP
ENHANCE
when, where,
SAP Learning
Learning
and what to learn SKILLS.
Hub
Hub
SAP Learning
SAP Live
Live Hub, student edition
Access
Access

72
PMBOK® Guide: Part 1 – Current Reality Clearing the Confusion

14.3.3 Executing

In Figure 13, the executing process group is added, which is presented via the horizontal arrow with the
letter ‘E’. Here are a few points to highlight:

Figure 13: The Project Life Cycle with the Executing Process Group

• Notice ‘execute the project’ in this graphic goes through most of the stages; this is the horizontal
arrow spanning to the end.
• Per CAM2P™ executing the project is going through all stages.
• Therefore, executing the project starts after initial planning (the project management plan in
this case) and stops just before final closure.

What this means is that executing the project is going through the stages; Definition, Implementation,
Operation Readiness, and even part of Project Close Stage.

14.3.4 Monitoring & controlling

In Figure 14, the monitoring and controlling process group is added, which is presented via the horizontal
arrow with the letters ‘M&C.’ Here are the highlights for monitoring and controlling:

N
o

c
e

h
Figure 14: The Project Life Cycle; Adding the Monitoring & Controlling Process Group

73
PMBOK® Guide: Part 1 – Current Reality Clearing the Confusion

• Notice that the ‘M&C’ arrow goes through all the other stages spanning to the end and is
longer than the executing arrow.
• What this means is that monitoring and controlling processes start as soon as the project is
initiated and does not end until just before the project close-out report.
• In other words, monitoring and controlling processes are not only in comparison to the Project
Management Plan; the project is also managed as compared to the idea statement and the
project feasibility.

14.3.5 Closing

The closing processes are at the end of the project life span and is represented by the letter ‘C’.

The key point to mention here is that what has been discussed is about the project, not individual stages.
In other words, this presentation matches the concepts of the PMBOK® Guide process groups where one
can initiate, plan, execute, monitor & control, and close the project.

14.4 Project and stage perspectives

Figure 15 combines the project and stage perspectives, which have been discussed.

Figure 15: The Project Life Cycle and Repeating Process Groups

The items represented by the smaller images (red) and text reflect the stage view, whereas the large image
(green) and font represents the project perspective.

74
PMBOK® Guide: Part 1 – Current Reality Clearing the Confusion

Please note, for clarity,

• The process groups are not shown for every stage although they do exist.
• The executing and monitoring & controlling arrows for the project perspective are also not
shown in order not to clutter the graphic.

14.5 Can we combine?

Can a single set of process groups be used?

In other words, can one merge the two perspectives, project, and stage, and treat them as one?

In theoretical terms, this merger cannot take place unless there is a single-stage project, which is rare.
However, in practice, it is possible to combine them for simple projects.

14.6 Can we consider as a program?

Some professionals continue to struggle with this concept (the repeated process groups), even when it
is explained like has been done here. They ask, “Can one considers the project as a program with multiple
projects; each stage being a project?” In other words, they still think of the process groups as phases.
Their view (a way to rationalize their understanding) is that to apply the process groups we must have
a project, not a phase (used once).

ANYTIME, ANYWHERE
LEARNING ABOUT
SAP SOFTWARE HAS
NEVER BEEN EASIER.
SAP Learning Hub – the choice of
when, where, and what to learn

75
PMBOK® Guide: Part 1 – Current Reality Clearing the Confusion

An easy answer would be “Sure, why not” but that would not be correct. To explain one must go back
to the definition of a project (see box).

However, by our definition, a project must produce output (product, service, result) and an outcome
(benefits) to the organization. The benefits must be tangible.

PMBOK® Guide Project’s Definition

The PMBOK® Guide definition of a project

is: “A project is a temporary endeavor to
create a unique product, service, or result.”
(The Project Management Institute, 2013).
In other words, the focus seems on output,
not outcome. Is outcome missed, implied, or
not part of this definition?

In this regard, let us consider the engineering stage of a power plant project. One can say the engineering
design package is output, and we agree. Because it is output (unique result), some may consider the
engineering phase as a project; we do not agree50. Here we must ask, what is the outcome of the engineering
design to the organization? Does engineering on its own deliver benefits to the project owner? On its
own, there is no benefit. Unless the organization uses the design to construct the power plant and the
power plant produces power, and the company can sell that power, there are NO benefits.

In other words, the deliverables of the various stages of a project are of limited value on their own and
do not contribute to the realization of benefits. Unless these deliverables are all integrated to deliver the
ultimate product (of the project) and achieve the expected benefits.

Back to the question, let us summarize. Can we consider a program with multiple projects?

• If your definition of a project is limited to an output, then yes because each stage does
produce output.
• However, if your definition includes the outcome – the benefits to realize, then a project must
consist of all the steps, deliverables, stages that deliver the ultimate product and outcome.

In closing, we cannot consider the project as a program; that is our professional opinion. This is
why we have a project and stages. Otherwise, every project is a program.

76
PMBOK® Guide: Part 1 – Current Reality Clearing the Confusion

14.7 Conclusion
Figure 16 includes another representative illustration comparing a generic project life cycle with the
process groups and PMBOK® Guide processes.

The following is an explanation of this figure.

• The top layer shows a generic project life cycle with four phases,
• The middle layer presents the repeating process groups, and
• The bottom layer displays the process groups – knowledge area matrix; which is to display
the repeating processes (most or all processes) from the various knowledge areas (The Project
Management Institute, 2013).

In the matrix of the bottom layer, the columns represent the five process groups, and the rows are for
the ten knowledge area of the fifth edition of the PMBOK® Guide.

Figure 16: Mapping the Process Groups to a Generic Project Life Cycle

77
End Sections

78
PMBOK® Guide: Part 1 – Current Reality References

References
(n.d.). Retrieved April 26, 2014, from Investopedia:
http://www.investopedia.com/terms/p/peter-principle.asp

Ajam, M.A. (2006). Awakening the Giant Within. PMI Europe-Middle East-Africa Congress (EMEA)
2006. Madrid: The Project Management Institute.

Ajam, M.A. (2010). The Inheritance. Dubai, United Arab Emirates: SUKAD.

Ajam, M.A. (2014). Project Management Foundation. Amioun, Al-Koura, Lebanon: SUKAD Multimedia.

Ajam, M.A. (2014). Redefining the Basics of Project Management. Amioun, Al-Koura, Lebanon: SUKAD
Multimedia.

ICB: IPMA Competence Baseline. (2015, August 21). Retrieved from International Project Management
Association: http://ipma.ch/resources/ipma-publications/ipma-competence-baseline/

ANYTIME, ANYWHERE
NO-LIMITS LEARNING
LEVERAGE
LEARNING ABOUT SOCIAL LEARNING,
COLLABORATION,
SAP SOFTWARE HAS QUALITY
CONTENT,
NEVER BEEN AND HANDS-ON
EASIER.
PRACTICE.
SAP Learning Hub – the choice of
when, where, and what to learn

79
PMBOK® Guide: Part 1 – Current Reality References

Mounir A. Ajam and SUKAD Group. (2012–2014). SUKAD Group Blog Site. Retrieved from Redefining
Project Management: http://blog.sukad.com

Project Management Institute. (2008). A Guide to the Project Management Body of Knowledge (Fourth
ed.). Pennsylvenia, United States: The Project Management Institute, Inc.

The Project Management Institute. (2013). A Guide to the Project Management Body of Knowledge (Fifth
Edition ed.). The Project Management Institute, Inc.

The Project Management Institute. (2013). A Guide to the Project Management Body of Knowledge (Fifth
Edition ed.). The Project Management Institute, Inc.

What is PRINCE2®. (2015, August 21). Retrieved from Axelos Global Best Practice:
https://www.axelos.com/best-practice-solutions/prince2/what-is-prince2

80
PMBOK® Guide: Part 1 – Current Reality Author Biography: Mounir A. Ajam

Author Biography: Mounir A. Ajam

Mr. Mounir A. Ajam is an entrepreneur, author, speaker, coach, advisor, consultant, volunteer leader,
and project management thought leader.

He is the author of ‘The Inheritance, a Story of Friendship, Community, and Project Management’; Project
Management Foundation; Redefining the Basics of Project Management; Applied Project Management;
CAM2P™ for Mega Projects (not published yet), and a series of e-books; all on project management.

He is a senior executive with three decades of outstanding global and practical experience in capital project
industries such as engineering, construction, petroleum, utilities, project management, and management
consultancy. He has worked on projects worth billions of United States dollars in North America, Europe,
South East Asia, and West Asia. His experience included working small and multiple projects and large
and complex projects, including two mega projects one in the United States and one in South East Asia.

Mr. Ajam is a co-founder and the Chief Executive Officer of SUKAD Group, a leading project management
provider with offices in Lebanon and the United Arab Emirates.

Mr. Ajam and SUKAD play quite an active role in the project management community through various
professional activities that are open to community members at no cost. He is a real volunteer servant
leader. He is heavily involved with the project management community at the regional and global levels.
Globally, he has served in different roles and capacities. These roles include serving on the Global Advisory
Group to the Project Management Institute (PMI®) Registered Education Provider program and as a
judge for various PMI® educational awards. He served on the 2008 PMI® EMEA (Europe-Middle East-
Africa) Congress Project Action Team. He is also a graduate of the PMI Leadership Institute Master
Class (Class of 2007).

In West Asia, Mr. Ajam served on the board of directors for the PMI chapter in the Arabian Gulf.
He led the effort to establish a PMI chapter in the United Arab Emirates. He also led the effort and
established the Global Project and Process Management Association (GPPMA). He served as GPPMA
board chairperson for three years.

Mr. Ajam is an advocate of project management and recognizes its strategic value. He contributes to
project management growth by publishing professional papers and articles on numerous platforms.
These platforms include PMI Congresses, Construction Week Magazine, Dubai Quality Group, DKV
Experts Channel, PMForum.com, Wamda.com, and other publications. He is the principal author of the
SUKAD blog site (http://blog.sukad.com), in addition to a personal blog. The SUKAD blog has more
than 200 articles.

For more information about Mr. Ajam, please refer to his personal page at www.mounirajam.com.

81
PMBOK® Guide: Part 1 – Current Reality About the Publisher

About the Publisher

SUKAD
SUKAD Vision is Project Management for All Aspects of Life!

SUKAD Mission is Be an Agent of Change and a Catalyst for Development!

SUKAD was established in Dubai, United Arab Emirates, in 2004. In 2012, SUKAD opened another
office in Lebanon. From these two offices, SUKAD has been providing services to West Asia and Africa.
SUKAD is highly recognized as a leader in project management services; with a large percent of revenues
acquired through repeat business and referrals from leading organizations.

SUKAD has an extensive project management research and development program. Under the label
and trademark The SUKAD Way™, the R&D effort has led to the development of proprietary products.
These include The Customizable and Adaptable Methodology for Managing Projects™ (CAM2P™) and
The Seven Elements of Project Management Maturity™ (The 7Es™).

THE ANSWER
ANYTIME,
NO-LIMITS ANYWHERE
LEARNING
TO
YOUR LEARNING NEEDS
LEVERAGE
LEARNING ABOUT SOCIAL LEARNING,
GET
SAP QUALITY,
COLLABORATION,
SOFTWARE FLEXIBLE, AND
QUALITY
HAS
ECONOMICAL
CONTENT,
NEVER BEEN AND TRAINING WHEN
HANDS-ON
EASIER.
AND
PRACTICE.WHERE
SAP Learning IT’S
Hub – the choice
when, where, and what to learn
of NEEDED.

82
PMBOK® Guide: Part 1 – Current Reality About the Publisher

In addition to the PM Methodology and PM Maturity Model, SUKAD has developed numerous advanced
courses and master certificates in project management. SUKAD has been publishing a series of books,
booklets, and sample projects in Arabic and English.

SUKAD is a corporate citizen and business with a heart. Over the years, SUKAD has provided numerous
complimentary learning events to thousands of professionals either on our own (under our 2SPI™
program) or through partnerships with various organizations and universities.

In recognition of our business and community successes, in 2011/2012 SUKAD was recognized and
ranked in the Dubai SME 100 ranking and the AllWorld Network Arabia 500 ranking.

SUKAD Multimedia
SUKAD Multimedia is a division of SUKAD Group with a focus on publishing project management
related work. This book is a product of the SUKAD Multimedia Division.

83
PMBOK® Guide: Part 1 – Current Reality Endnotes

Endnotes
1. Published by the author and SUKAD Multimedia in April 2014 (http://multimedia.sukad.com).
2. PMI = the Project Management Institute, the largest not-for-profit organization in the project management
domain.
3. http://sukadway.sukad.com.
4. The Notice Page is just inside the cover in the PMBOK® Guide.
5. We will often use the term ‘guide’ to refer to the PMBOK® Guide.
6. Thanks to a colleague and friend (Nelly Khnaizer) for asking this question and triggering the topic.
7. http://oxforddictionaries.com/definition/english/standard
8. http://oxforddictionaries.com/definition/english/framework?q=framework
9. Oxford Online Dictionaries (http://oxforddictionaries.com/)
10. Same reference
11. For a brief overview of CAM2P™ please refer to http://sukadway.sukad.com and for more in depth coverage
refer to Redefining the Basics of Project Management book.
12. Tailored is another common term.
13. Project in this context refer to the wider perspective, including programs and portfolios
14. Refer to http://sukadway.sukad.com for brief overview.
15. More information via this link: http://sukadway.sukad.com/introduction-to-the-sukad-maturity-model
16. IPMA Competence Baseline.
17. IPMA is the International Project Management Association
18. American National Standards Institute.
19. In general, we will not use the full names of the process groups, processes, or knowledge area; except where
it is necessary. Whenever we mention these names, all rights are reserved to the Project Management
Institute (PMI).
20. This is a view point and we cannot verify it as the actual reason.
21. At the time of writing this book; September–November 2015.
22. Knowledge Areas
23. Refer to this blog article by the author on the changes from 4th to 5th editions
http://blog.sukad.com/20130716/are-the-changes-from-pmbok-4-to-pmbok-5-significant/.
24. Like program and portfolio management standards
25. These numbers are generally accurate (approximate) but not precise; they are as of June 2015.
26. Today PMI offers eight certifications.
27. Who are involved in developing the PMBOK® Guide and its updates.
28. ‘We’ refers to the author and SUKAD Group, the company he co-founded and is managing
29. ANSI = American National Standards Institute; it is the United States of America standards authority.
30. PMBOK® Guide, Fourth Edition, 2008, Chapter 1, Introduction, p. 3.
31. The bold emphasis is by the author.
32. The subject of other books by the author.
33. This is the subject of the next section in this e-book.
34. Refer to Section III of this e-book.

84
PMBOK® Guide: Part 1 – Current Reality Endnotes

35. They are only listed in one of the appendices along with everyone else. Therefore, there is no way to tell
the difference between those who contributed one sentence and others who offered major suggestions.
36. Comment added per an input from a reviewer, Mr. Trevor K. Nelson.
37. For more discussions on this topic refer to http://sukadway.sukad.com/
38. Maybe the reader should consider coming back to this point after going through Section III.
39. PMBOK® Guide Section 2.2.3, page 35.
40. http://blog.sukad.com/20130225/project-successpmbok-guide-creates-confusion/
41. Our understanding.
42. When we see origin – we are not saying the PMBOK® Guide copied this – but rather the concept of the
process groups align to the concept of the PDCA, which is much older. In other words, the PDCA principle
applies to all actions, including projects. We realize, that some might not agree with this statement and
that the process group concept is original and has nothing to do with the PDCA concept.
43. In this chapter we use the terms phases and stages interchangeably.
44. This is for commercial work – although there are projects in response to social and community needs.
45. The Customizable and Adaptable Methodology for Managing Projects™ (CAM2P™).
46. Again – phase in the context of this chapter can also mean stage.
47. Using stage or phase interchangeably.
48. Initial Ops (Initial Operations) that is shown here after implementation is only part of the Project Operation
Readiness Stage; not a stage by itself. Some of Project Operation Readiness Stage works happen before
Initial Operations; in parallel to implementation but this is not shown to simplify the presentation.
49. Refer to Section 9.6.
50. For the engineering company that is doing the engineering for the project, this work (engineering) can
be considered a project. The service provider’s project is to produce the engineering design packages.

85
 To see Part II download:
PMBOK® Guide Part II: Improvements