One of the first things I have those who attend my online PMP study group do is to memorize the names of the 5 process groups and 10 knowledge areas from the PMBOK Guide–there are 5 process groups and 10 knowledge areas. This is a prelude for them to learn the 47 PM processes and where they go on the Traditional PM Processes Grid. This grid is formed when you put the 5 process groups across in columns and the 10 knowledge areas down in rows. Memorizing this grid is part of the initiation ritual for those who want to pass the PMP exam. Why? Knowing the names of the processes and their proper order to the extent that you can reproduce on a piece of paper in 10 minutes or less is a key skill to learn for preparing for the exam. It helps you in many ways, for example, in situational questions involving “what do you next?”, it is important to identify what process you are in now and then realize from the grid what process you are heading towards next. Putting this in an external form like a piece of paper allows your mind to use that processing space to focus on the details of the question, as if you were clearing RAM on your computer.
As I study Agile Project Management using John Stenbeck’s book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference,” I see that there is an Agile PM Processes Grid at the end of the 2nd chapter. This immediately caught my eye and i wanted to compare this grid with the Traditional PM Processes Grid as found in the PMBOK Guide.
Here are the five process groups in Traditional and Agile PM.
TRADITIONAL | Initiating | Planning | Executing | Monitoring & Controlling |
Closing |
AGILE | Initiate | Plan | Iterate | Control | Close |
Notice how the Initiating, Planning, and Closing are the same between the three (using the normal verb form in Agile rather than gerund or noun form used in Traditional). Monitoring & Controlling is shortened to Control, and then Executing is replaced by Iterate. In reality traditional PM also goes back and forth between Executing (doing the project work) and Monitoring & Controlling (checking the project work), but this “back and forth” pattern is emphasized in Agile with the word “Iterate”. So far so good; these two sets of process groups correlate pretty clearly. Now let’s go on to the knowledge areas.
TRADITIONAL | AGILE |
Integration | External Stakeholders Engagement |
Scope | Value-Driven Delivery |
Time | Adaptive Planning |
Cost | Team Performance |
Quality | Risk Management |
Human Resources | Communication |
Communications | Continuous Improvement |
Risk | |
Procurements | |
Stakeholders |
Note that this is just the order that the knowledge areas are listed in. There are 10 knowledge areas for Traditional PM, and 7 knowledge areas for Agile. How do these knowledge areas correlate? Well, here’s my best attempt to put those knowledge areas in Traditional PM next to their Agile counterparts.
TRADITIONAL | AGILE |
Integration | (various knowledge areas) |
Scope | Value-Driven Delivery |
Time | Adaptive Planning |
Cost | Adaptive Planning |
Quality | Value-Driven Delivery,
Continuous Improvement |
Human Resources | Team Performance |
Communications | Communication |
Risk | Risk Management |
Procurements | N/A |
Stakeholders | External Stakeholders Engagement |
You can see it’s not a neat, one-to-one mapping as with the process groups, mainly for the reason that there are 10 knowledge areas in Traditional PM and 7 knowledge areas in Agile PM.
Let’s take the Agile knowledge areas as they appear in the original order and discuss how they correlate.
- External Stakeholders Engagement–this obviously correlates with Stakeholder Management in Traditional PM, but notice that it is the first knowledge area rather than the last one as in Traditional PM, which shows the priority that Agile places on feedback to and from the customer throughout the entire set of Agile Processes
- Value-Driven Delivery–This covers Scope Management in traditional PM. In that quality is considered creating a product whose technical characteristics fulfill the functional requirements gathered from the customer, this covers the quality control portion of the Quality Management knowledge area in Traditional PM
- Adaptive Planning–This covers the Time and Cost Management knowledge areas in Traditional PM
- Team Performance–This covers the Human Resources Management knowledge area in Traditional PM
- Risk Management—This covers the Risk Management knowledge area in Traditional PM
- Communication–This covers the Communication Management knowledge area in Traditional PM
- Continuous Improvement–This covers the quality assurance portion of the Quality Management knowledge area in Traditional PM, rather than the quality control portion which falls more under Value-Driven Delivery knowledge area in the Agile PM Processes Grid.
One additional comparison needs to be made, and that is the difference between the Agile PM Processes Grid and the domains listed by PMI that are covered by its PMI-ACP exam. This comparison is below.
AGILE KNOWLEDGE AREAS | PMI-ACP DOMAINS |
1. Agile Principles and Mindset | |
2. Value-Driven Delivery | 2. Value-Driven Delivery |
1. External Stakeholders Engagement | 3. Stakeholder Engagement |
4. Team Performance | 4. Team Performance |
3. Adaptive Planning | 5. Adaptive Planning |
5. Risk Management | 6. Problem Detection and Resolution |
7. Continuous Improvement | 7. Continuous Improvement |
6. Communication | (included in 4, 5) |
How do these compare? Well, the PMI-ACP Domain of “Agile Principles and Mindset” is kind of like the first three chapters of the PMBOK that explain the concepts behind Traditional Project Management. The other PMI-ACP Domains map pretty well to the Agile Knowledge Areas in the “Agile PM Processes Grid” with two notable exceptions.
Risk Management is a part of problem detection and resolution, but the “resolution” portion of the PMI-ACP Domain also includes the implementation of continuous improvements that are proposed in domain 7. And Communication is a VERY important Agile Knowledge Area. The reason why it is not included in the PMI-ACP list of domains is not because PMI doesn’t consider communication important for Agile, rather it is SO important it is hard to confine it to one domain. It shows up in tasks that are in domains 4 (Team Performance) and domain 5 (Adaptive Planning) for the most part, but to a lesser extent in other domains as well. It is “omnipresent” within all of the other domains, let’s put in that way.
I hope this post is helpful, and if any readers have any suggestions or questions on these comparisons, please let me know. After I go through the remaining material in chapter 2, “Introducing Agile Project Management” (part of the “Agile Principles and Mindset” domain on the PMI-ACP exam), I will list the actual processes in the grid.
Filed under: Uncategorized |
Leave a Reply