Design by Steven Goeman | © 2021 GAPS BV

PROJECT MANAGEMENT MENTOR

PROJECT MANAGEMENT

MENTOR

WATCH OUT WITH PMI’s PROCESS GROUPS

DO NOT USE THEM AS YOUR PROJECT MANAGEMENT LIFE CYCLE

A PROCESS GROUP ACCORDING TO THE PROJECT MANAGEMENT

INSTITUTE

The concept process group is introduced early in the sixth edition of the Project Management Body of Knowledge (PMBOK) guide. More specifically in chapter 1 on page 23. It states that a process group is:

"a logical grouping of project management processes to achieve specific project objectives.”

PMI also adds to it, that process groups should be seen independently of project phases. That is already a first warning why process groups should not be mingled with the principles of a project life cycle!

WHICH PROCESS GROUPS HAVE BEEN DEFINED ?

The PMBOK actually defines five very specific process groups:

1. Initiating Process Group:

It is the logical grouping of project management processes that allow the project manager to organize the work that is needed to define and mandate a new project, or a new project phase. The management processes, belonging to this Initiating process group are focussed on obtaining the formal authorization to start the project or the project phase.

2. Planning Process Group:

It is actually the largest process group of the five, with not less than 24 processes. That already indicates the importance of the planning activity as part of the project management discipline. The planning process group contains all management processes that contribute to the creation of management plans and strategies. But these processes are also intended to shape the project itself. Just think about processes, like collect requirements, define scope, which actually conceptualizes the project.

3. Executing Process Group:

Executing management processes are those processes that the project manager performs to get things done. It are the processes that allows to organize all the work that experts need to undertake to deliver the specific project results and deliverables. Often misunderstood, PMI does not describe the actual processes of development! It only defines how a project manager should organize the project so these development processes can be executed.

4. Monitoring & Controlling Process Group:

This process group contains 12 processes, making it the second largest, after the Planning process group. So, we can already conclude that the job of the project manager should be focussed on planning, monitoring and controlling a project. The Monitoring & Controlling process group lists and explains all the management processes that a project manager can use to monitor the progress of the project and to control, as much as possible, the agreed boundaries of the project.

5. Closing Process Group:

Last but not least, and unfortunately often neglected in practice, the Closing process group. It is the collection of processes that helps the project manager to orderly close a project phase, or the project itself. Note that closing processes, but also initiating processes relate not only to the project but also the project phases! The latter implies (amongts others) that the closing processes of the prior project phase are linked with the initiating processes of the following process groups. Therefore, project management processes are to be considered cyclic on the project.

HOW DO I USE THESE PROCESS GROUPS IN PRACTICE ?

Well, the answer is quite simple... I don't! I use the processes contained in these process groups to translate them into practical tasks and activities, which I, as a project manager, can perform. And I use the list of processes (contained within these process groups) as a kind of checklist to identify which processes are important and which are less important for the project at hand. This selection of processes is different per project as every project and project situation is unique. But, I do not use the process groups themselves! And that is even quite logic, because process groups do not serve a practical project management purpose. The objective and real value of process groups is to structure the project management discipline. It is used to structure the explanation of what project management really is. They facilitate the discussion and learning of project management, because the structure makes it more easy to explain and makes the subject matter more insightful. So, the process groups are especially a great value for: project management educators, those writing books on project management, and those that still have to prepare for the PMP-exam. It will allow them to bring structure in all that project management knowledge. But on the field however, the process groups bring, at least for me, not a lot of value.

DO NOT MIS-USE THEM AS A PROJECT LIFECYCLE !

Very regular, as part of my business, I perform project audits, in which I assess the project health and its performance. It is each time a kind of photo or snapshot that is taken at a specific point in the timeline of the project and that serves as an inspiration to the project manager to take corrective actions to increase the success rate of the project. I also regularly perform project audits on my own running projects as it will help me to steer the project to successful heights. I actually believe that every project manager should underdstand the art of auditing a project, as it proves a valuable tool in managing projects. It is a technique that would belong to the monitoring & controlling processes. It proves ultimately useful to identify the weaknesses of the project, and provide at the same time indications on which corrective actions that could be implemented. A project audit also provides good insights whether the current project approach is still a valid one for the (new) situation where the project is in. During such project management audits, I regularly see that there are still quite some fellow project managers that make use of PMI’s process groups as a kind of project life cycle. It seems they didn't saw the word "IN" when reading the PMBOK's statement that process groups are INdependent from the project life cycle... Now, don't understand me wrong... There is nothing and nobody that prevents you to use the process groups as a project life cycle. As project managers, we are free to define our project life cycles and their phases as we want to. But for the sake of the example, let's assume that we should use the process groups as our project life cycle... We know that a project lifecycle is a set of sequential project phases that contain logically related activities. Typically, we can limit the project management lifecycle to a generic set of five phases. First, we have to start a project. Then we have to define/study about the project and the project’s desired outcome. When the project is defined, it is time to actually create the desired project deliverable, and once created, we have to transfer the project deliverable to the operations. If all goes well, we can finally bring the project to a formal ending. Clearly, we can note some similarities with the process groups: The initiating process group is about starting the project, The planning process group is about conceptualizing, defining the project, Executing is about getting things done And closing is about properly ending the project. So, we can argue that our project life cycle would become:

Initiating > Planning > Executing and Closing

But what about the Monitoring and controlling? It seems a bit odd to include that into the lifecycle, as into my opinion, you monitor and control throughout the complete project. You would do monitoring and controlling activities in all the phases of the life cycle. And given that the Initiating process group is about all processes needed to start a project, but also to start a project phase, then Initiating is actually also valid in all project phases. The Project Management Institute claims that project management processes are iterative. When the mangement processes are iterative, so are the process groups and that means that all process groups will occurr in all phases of your project life cycle. This iterative character makes that process groups are not intended to be used in a linear sequential way. So, it should be clear that if you use the process groups and their terminology in your linear project management lifecycle, it might become confusing. We can turn this discussion around to find out why process groups should not be used a kind of project management lifecycle. Is the purpose of a project lifecycle to offer a structure for a field of study like project management, or is its purpose rather something you can use to structure the timeline of a project? We all agree that the correct answer is the second option, making the process groups not likely the best solution to use as the phases of a project life cycle.

IS THERE NO PRACTICAL USE AT ALL ?

Of course not! There is always a practical use to be found in our daily project management practices. Actually, I make extensive use of the process groups and process group principles when managing agile projects. Project management processes, and thus process groups, are according to PMI... iterative. As already stated above. When defining my project management approach, which I have to describe in a brief project management plan, often followed by a presentation to senior management (or a steering group, or a project sponsor), especially in agile environments, I tend to use the process groups. As they are iterative, they nicely make the link with cyclic approaches, and cyclic or iterative reasoning. So to help people in agile organizations understand my project management approach, I have to talk their language, in this case "iterations", "cycles", etcetera. The process groups, because of their iterative character, actually offer me that kind of language and structure! Therefore, using the process groups, makes that my project staheolders understand me better! It is a great way to structure my project management plan or the presentations to management about my project management approach in the agile environment. Whilst in a traditional, linear organized project, I will make use of the PMBOK's knowledge area as my outline or table of contents of the overall project management plan, in the agile environment, I will organize my table of contents of the project plan making use of PMBOK's process groups. The Project Mangement Institute (PMI) and the Project Management Body of Knowledge (PMBOK) - guide are registered trademarks and copyrighted. You can find more information on the website: www.pmi.org.

ABOUT THE AUTHOR

Steven GOEMAN is a certified project management professional and a licensed Master of Neurolinguistic Programming with more than 20 years of project (management) experience. He is the creative mind behind the renowed brand “The Project Management Mentor”, enabling him to share his expertise on portfolio management, program management and project management as an empathic project management coach and project management mentor. Steven founded GAPS BV (https://www.gaps.be) in 2005 from which he successfully assisted many individuals and organizations with project management related mentoring, coaching and consulting services.

PROJECT MANAGEMENT MENTOR

PROJECT MANAGEMENT

MENTOR

Design by Steven Goeman | © 2021 GAPS BV

WATCH OUT WITH

PMI’s PROCESS

GROUPS

DO NOT USE THEM AS YOUR PROJECT MANAGEMENT

LIFE CYCLE

A PROCESS GROUP ACCORDING TO

THE PROJECT MANAGEMENT

INSTITUTE

The concept process group is introduced early in the sixth edition of the Project Management Body of Knowledge (PMBOK) guide. More specifically in chapter 1 on page 23. It states that a process group is:

"a logical grouping of project management

processes to achieve specific project objectives.”

PMI also adds to it, that process groups should be seen independently of project phases. That is already a first warning why process groups should not be mingled with the principles of a project life cycle!

WHICH PROCESS GROUPS HAVE

BEEN DEFINED ?

The PMBOK actually defines five very specific process groups:

1. Initiating Process Group:

It is the logical grouping of project management processes that allow the project manager to organize the work that is needed to define and mandate a new project, or a new project phase. The management processes, belonging to this Initiating process group are focussed on obtaining the formal authorization to start the project or the project phase.

2. Planning Process Group:

It is actually the largest process group of the five, with not less than 24 processes. That already indicates the importance of the planning activity as part of the project management discipline. The planning process group contains all management processes that contribute to the creation of management plans and strategies. But these processes are also intended to shape the project itself. Just think about processes, like collect requirements, define scope, which actually conceptualizes the project.

3. Executing Process Group:

Executing management processes are those processes that the project manager performs to get things done. It are the processes that allows to organize all the work that experts need to undertake to deliver the specific project results and deliverables. Often misunderstood, PMI does not describe the actual processes of development! It only defines how a project manager should organize the project so these development processes can be executed.

4. Monitoring & Controlling Process Group:

This process group contains 12 processes, making it the second largest, after the Planning process group. So, we can already conclude that the job of the project manager should be focussed on planning, monitoring and controlling a project. The Monitoring & Controlling process group lists and explains all the management processes that a project manager can use to monitor the progress of the project and to control, as much as possible, the agreed boundaries of the project.

5. Closing Process Group:

Last but not least, and unfortunately often neglected in practice, the Closing process group. It is the collection of processes that helps the project manager to orderly close a project phase, or the project itself. Note that closing processes, but also initiating processes relate not only to the project but also the project phases! The latter implies (amongts others) that the closing processes of the prior project phase are linked with the initiating processes of the following process groups. Therefore, project management processes are to be considered cyclic on the project.

HOW DO I USE THESE PROCESS

GROUPS IN PRACTICE ?

Well, the answer is quite simple... I don't! I use the processes contained in these process groups to translate them into practical tasks and activities, which I, as a project manager, can perform. And I use the list of processes (contained within these process groups) as a kind of checklist to identify which processes are important and which are less important for the project at hand. This selection of processes is different per project as every project and project situation is unique. But, I do not use the process groups themselves! And that is even quite logic, because process groups do not serve a practical project management purpose. The objective and real value of process groups is to structure the project management discipline. It is used to structure the explanation of what project management really is. They facilitate the discussion and learning of project management, because the structure makes it more easy to explain and makes the subject matter more insightful. So, the process groups are especially a great value for: project management educators, those writing books on project management, and those that still have to prepare for the PMP- exam. It will allow them to bring structure in all that project management knowledge. But on the field however, the process groups bring, at least for me, not a lot of value.

DO NOT MIS-USE THEM AS A

PROJECT LIFECYCLE !

Very regular, as part of my business, I perform project audits, in which I assess the project health and its performance. It is each time a kind of photo or snapshot that is taken at a specific point in the timeline of the project and that serves as an inspiration to the project manager to take corrective actions to increase the success rate of the project. I also regularly perform project audits on my own running projects as it will help me to steer the project to successful heights. I actually believe that every project manager should underdstand the art of auditing a project, as it proves a valuable tool in managing projects. It is a technique that would belong to the monitoring & controlling processes. It proves ultimately useful to identify the weaknesses of the project, and provide at the same time indications on which corrective actions that could be implemented. A project audit also provides good insights whether the current project approach is still a valid one for the (new) situation where the project is in. During such project management audits, I regularly see that there are still quite some fellow project managers that make use of PMI’s process groups as a kind of project life cycle. It seems they didn't saw the word "IN" when reading the PMBOK's statement that process groups are INdependent from the project life cycle... Now, don't understand me wrong... There is nothing and nobody that prevents you to use the process groups as a project life cycle. As project managers, we are free to define our project life cycles and their phases as we want to. But for the sake of the example, let's assume that we should use the process groups as our project life cycle... We know that a project lifecycle is a set of sequential project phases that contain logically related activities. Typically, we can limit the project management lifecycle to a generic set of five phases. First, we have to start a project. Then we have to define/study about the project and the project’s desired outcome. When the project is defined, it is time to actually create the desired project deliverable, and once created, we have to transfer the project deliverable to the operations. If all goes well, we can finally bring the project to a formal ending. Clearly, we can note some similarities with the process groups: The initiating process group is about starting the project, The planning process group is about conceptualizing, defining the project, Executing is about getting things done And closing is about properly ending the project. So, we can argue that our project life cycle would become:

Initiating > Planning >

Executing and Closing

But what about the Monitoring and controlling? It seems a bit odd to include that into the lifecycle, as into my opinion, you monitor and control throughout the complete project. You would do monitoring and controlling activities in all the phases of the life cycle. And given that the Initiating process group is about all processes needed to start a project, but also to start a project phase, then Initiating is actually also valid in all project phases. The Project Management Institute claims that project management processes are iterative. When the mangement processes are iterative, so are the process groups and that means that all process groups will occurr in all phases of your project life cycle. This iterative character makes that process groups are not intended to be used in a linear sequential way. So, it should be clear that if you use the process groups and their terminology in your linear project management lifecycle, it might become confusing. We can turn this discussion around to find out why process groups should not be used a kind of project management lifecycle. Is the purpose of a project lifecycle to offer a structure for a field of study like project management, or is its purpose rather something you can use to structure the timeline of a project? We all agree that the correct answer is the second option, making the process groups not likely the best solution to use as the phases of a project life cycle.

IS THERE NO PRACTICAL USE AT

ALL ?

Of course not! There is always a practical use to be found in our daily project management practices. Actually, I make extensive use of the process groups and process group principles when managing agile projects. Project management processes, and thus process groups, are according to PMI... iterative. As already stated above. When defining my project management approach, which I have to describe in a brief project management plan, often followed by a presentation to senior management (or a steering group, or a project sponsor), especially in agile environments, I tend to use the process groups. As they are iterative, they nicely make the link with cyclic approaches, and cyclic or iterative reasoning. So to help people in agile organizations understand my project management approach, I have to talk their language, in this case "iterations", "cycles", etcetera. The process groups, because of their iterative character, actually offer me that kind of language and structure! Therefore, using the process groups, makes that my project staheolders understand me better! It is a great way to structure my project management plan or the presentations to management about my project management approach in the agile environment. Whilst in a traditional, linear organized project, I will make use of the PMBOK's knowledge area as my outline or table of contents of the overall project management plan, in the agile environment, I will organize my table of contents of the project plan making use of PMBOK's process groups. The Project Mangement Institute (PMI) and the Project Management Body of Knowledge (PMBOK) - guide are registered trademarks and copyrighted. You can find more information on the website: www.pmi.org.

ABOUT THE AUTHOR

Steven GOEMAN is a certified project management professional and a licensed Master of Neurolinguistic Programming with more than 20 years of project (management) experience. He is the creative mind behind the renowed brand “The Project Management Mentor”, enabling him to share his expertise on portfolio management, program management and project management as an empathic project management coach and project management mentor. Steven founded GAPS BV (https://www.gaps.be) in 2005 from which he successfully assisted many individuals and organizations with project management related mentoring, coaching and consulting services.