Process Groups Are Not Phases

This is something of a rant. If you don't like rants, stop reading.

Go out to Amazon and download a couple of project management books to your Kindle app. I did this not too long ago. Probably spent US$4–8 per book. Maybe $100 total. I was looking for a book that I could use as a reference for my PM Fundamentals course, Mastering Modern Project Management.

I didn't find one to use. Not. A. Single. One. Why? Because they all used the PMBoK Guide's process groups as project lifecycle phases. I've been railing against this for something over 20 years now, but the practice continues. It's gotten so bad that the EU has even incorporated process groups as phases into a recent standard (PM2) intended to be used throughout the EU. The UK may have dodged a bullet with Brexit.

Earlier today, someone asked me to explain what's wrong with this practice. I've explained it so many times to so many people in so many threads, I just assumed that I had written about it for LinkedIn as well. Apparently not. So here goes ...

The current PMBoK Guide identifies five process groups: initiating, planning, executing, monitoring and control, and closing. In the original (1996) PMBoK Guide, we called the fourth one "controlling," so I'll abbreviate the five to IPECC.

Let's start with some logic. Most people who use the process groups as phases use only four: initiating, planning, executing, and closing (IPEC). What happened to the fifth one? If the process groups are phases, why would you arbitrarily delete one? If you trust in the PMBoK Guide, why substitute your judgment for its judgment on this one topic?

Next, move on to what the PMBoK Guide says. My understanding is that current version says explicitly that the process groups are not phases. I can't confirm that since I don't have a copy of any of the recent editions, but I do know the original version devoted a page-and-a-half of text (section 3.2) and 2 diagrams to explaining and illustrating the relationship between phases and process groups. If the PMBoK Guide has, from the start, recognized that process groups are not phases, why would you ignore that?

If you're smarter than the PMBoK Guide, why use it at all?

But the real killer is the impact on the practice of project management: using the process groups as phases destroys your ability to use the project-management-oriented processes described in the PMBoK Guide to effectively manage the product-oriented processes that will produce the expected benefits. Let's use a software development project as an example. In what phase are requirements gathered? If it's in initiation, then where do you do planning for the requirements gathering activities? Once you have the requirements, you need to create a design based on those requirements. Where does the planning for the design activities go? If it's in the Planning Phase, then the "planning" phase requires that you initiate the design work, plan the design work, execute the design work, (monitor and) control the design work, close the design work ... and then do some more planning to support development and testing during the "execution phase."

I'm getting confused just typing that! I can't imagine actually trying to manage it ... or trying to convince my boss that it makes sense.

If, instead, your software development project lifecycle phases were requirements, design, development, and testing, and you recognized that the process groups repeat within each phase, you can actually do what the PMBoK Guide says you should do and you can IPECC the requirements phase, IPECC the design phase and so on. Very smooth. Very simple to do and explain.

There are other benefits. Using product-oriented phases and phase names makes the decision gates clear. It also makes it easier to cancel a project whose business case is no longer valid. It even eliminates most of the alleged weaknesses of "waterfall" by allowing you to do incremental development. By the way ... if you're using an "agile" software development process, you'll find that IPECC repeats within each iteration.

Finally, if you insist on a standard project lifecycle for all your projects, try the one at the top of this article: discovery, design, and delivery. You can even subdivide those 3 if you want more review points. If you insist on four phases, try customer needs, solution design, implementation, and turnover. But whatever you do, stop using the process groups as phases.

PMBoK is a registered trademark of the Project Management Institute, Inc. It is used here only for identification and explanation without intent to infringe. The author of this article has no connection to PMI, Inc.