I’ll try to explain it in detail in this article.

The History of the Knowledge Areas

The main content of the standard is processes. The fourth edition of the standard contains 42 processes, which cover every aspect of the project management and are supposed to help you become more successful in your projects as long as you do not forget to tailor the standard to your needs.

The processes are different activities you should do. The standard provides you with a number of sample techniques for some processes (technics like the CPM, the EVM, etc.), but providing the techniques is not the main purpose of the standard. The main purpose is to present you a list of high-level activities you should do, and more important, providing you with a model which explains the minimum relationships you should have between them.

Anyway, it is not easy to understand a large number of things (processes in this topic), without grouping and organizing them. That’s why the PMBOK Guide has provided you with two methods of organizing and grouping for the processes:

Either of them is using a specific basis for grouping and you gain a better understanding of the processes through each of them.

There are five process groups. It has always been the same, since the first edition, and it is unlikely to increase or decrease in number in the future.

There were always nine knowledge areas in the standard, and it’s the first time we are facing a change in this grouping/organization concept: the introduction of a new one, called the Project Stakeholder Management Knowledge Area.

The Building Blocks

Let’s take a look at the organization and the number of the processes in different editions of the standard:

The number of the processes has changed in every edition; some processes might have been deleted and some new ones added to each new edition. This number is not a good measure of the maturity of the standard, as you can see a reduction from 44 processes into 42 processes in the fourth edition.

So, what happens here? Did PMI realize that a task should not be included in the project management profession and deleted it? Or did they realize that they have missed some tasks and added them to the standard? The answer is usually no to both questions.

Processes seem like the quantum elements of the PMBOK Guide, but the truth is that they are collections of tasks; the project management tasks. Underlying tasks of each process are usually a number of tasks that are similar in nature, are usually done by a single group of professionals, done in more or less the same time(s), and have almost similar predecessors and successors. They are combined and presented as a “process”.

Thinking of processes as an organizing concept is the key to understand the changes in the number of the processes in the PMBOK Guide. We have a large collection of project management tasks that do not change so much, and are the main source of creating the processes (as the first organizing concept), and then the knowledge areas and process groups (as the second organizing concept).

What has happened in the draft of the fifth edition of the PMBOK Guide is that the same old tasks are organized in a new way, creating new processes, and the processes are also organized in a new way, creating a new knowledge area.

Tasks Included in the New Knowledge Area

So, we can review the processes in the new knowledge area, determine the embedded tasks and determine where they come from; in other words, where they were in the fourth edition.

To make a long story short, the old Communications knowledge area is divided into two knowledge areas: the new Communications knowledge area and the Stakeholder knowledge area.

If you are interested in knowing about the details, a quick look at the following diagram will reveal it all.

The following are the processes in the Stakeholder Management of the draft of the fifth edition, a little description, and the mention of their counterparts in the previous edition:

This process is dedicated to identifying the people and organizations that have some level of interest in the project and have the potential to influence it.

The same process existed in the fourth edition, under the communications knowledge area; it has just moved from there to here; to the new knowledge area.

How are we going to plan for, execute, monitor and control the stakeholder management area? These questions are answered in this process by creating a document named “Stakeholder Management Plan”.

There was no such process in the previous edition, but the tasks underlying this process were all included in the Plan Communications process of the fourth edition.

So, we have planned how to manage the knowledge area; now it’s time to do it! Manage Stakeholder Engagement does most of the work, by communicating with them, addressing their issues, and meeting their needs and expectations by directing our decisions and activities.

This process is almost the same thing we used to call “Manage Stakeholder Expectations” in the previous edition. The title has changed a little to better reflect the real nature of the process.

We are managing the stakeholder engagement, but are we gaining the results we expected? We should evaluate our efforts and improve our actions according to the plans or even improve our plans if they are not as effective as they are supposed to be. These will be done in the Control Stakeholder Engagement process.

This new process is a set of tasks that were previously organized under the Report Performance process.

What Happens with Different Ways of Organizing?

So, if the tasks do not change that much, what difference does it make to change the organization?

It is similar to questioning the difference of two valid work breakdown structures. When we change the organization, we are changing the way we see the same thing (tasks in this topic), or the way we want to treat them.

The PMBOK Guide says that project managers should spend most of their time communicating. Some PMP exam questions direct you to choose the “90% of time” as the correct answer. Dividing this area into two new areas will automatically attract more attention to the underlying tasks. It is also a good way of simplifying the matter. We are supposed to spend most of our time on a knowledge area which had 5 processes; is it clear enough what to do? Well, it’s now clearer how to spend that 90% by organizing those tasks into 7 processes (instead of 5) which are grouped under two titles.

The last word is that some people wonder why we have to worry about the other knowledge areas when we are expected to spend 90% of our time on one of them. The answer is simple: the processes in the PMBOK Guide are interlocked in a way that you cannot have a certain one in an effective way, unless you pay enough attention to all of them. The other knowledge areas are important as well; they are necessary tasks and the communications area is their fruit. This fruit in the draft of the fifth edition is divided between two knowledge areas.

Summary

This article tried to explain the structure of the PMBOK Guide in a concise and a minimal way, needed for understanding the new knowledge area better. The aim is understanding the real change behind this. You always need this kind of understanding in order to be able to tailor the standard to your needs, which is indispensable for success in implementing the standard.