A Project Management Article by Mark Tolbert
In January 2012, Mark Tolbert presentated a popular PM Tools Workshop "Agile Project Management versus the PMBOK Guide and Earned Value Management". This article is Part Three of a seven part series that he wrote on the topic. To read parts one and two, please visit www.pmiwdc.org/articles. Be on the look out for the June - September Newsletters for the remaining four sections. You can also access a print friendly version of the article.
Defending the PMBOK® Guide
Defending the PMBOK® Guide Against This Attack on “Traditional Project Management”
But the PMBOK® Guide also allows that projects could be planned in a very iterative fashion: we often use “rolling wave planning.” This means we will plan in detail things that are occurring right away in the project, and only sketch-in at a high level things that will occur farther out in the future. (We will include “planning packages” in our WBS for these “sketched-in” items.)
Later, as we approach the time the planning packages are needed, we will come back – in our second wave of planning or third wave of planning – and fill in the details. So, PMI does not have any problem within an iterative approach to project management. Prototyping is also specifically mentioned as an important “tool and technique” in the process: Collect Requirements.
We can see that much of the Agile practitioner’s criticism of traditional project management is really a criticism of the waterfall method of project management, and is not a criticism of the approach defined in the PMBOK® Guide.
Therefore, one could definitely make the argument that in APM and Scrum, iterations (or Sprints) can be viewed as a special case of Rolling-Wave Planning.
For Both Agile and PMI, Processes From Different Process Groups Are Used in Both Iterations (or Sprints) and Phases.
In Agile, it is understood that within every iteration (or Sprint) a variety of different processes will be used: the team will be allowed a lot of freedom in planning how to do the Sprint, then the team will execute to create the product backlog defined for the Sprint: (the products, deliverables or services), adjustments will be made during the end, and also at the end. This type of activity is very much like doing Monitoring and Controlling processes described in the PMBOK® Guide.
In the PMBOK® Guide the five process groups are also used iteratively in all phases of a project in a very a similar way. (One of the most common mistakes about the PMBOK® Guide is to confuse the five process groups with sequential phases of a project! This is completely incorrect! See page 41 in Version Four of the PMBOK® Guide.) Part of the formal standard is that we should use processes from all five process groups in each phase. Yes, all projects are initiated formally in Develop Charter, but also, all phases must be initiated too.
Likewise, just as the project should be formally closed, all phases are also formally closed (as part of Close Project or Phase of Project). We must execute in every phase, since we are creating deliverables in every phase. (In the early planning phases, the deliverables are documents or plans.) And, of course, monitoring and controlling checks on the activities of the other four process groups, so it is always being used: from the very beginning to the very end.
Planning is perhaps the most difficult to see being used in all phases. It’s easy to see that it would be used up front in the early planning phases, but why would we still be using planning processes at the end of the project? There are actually two good reasons for this: (1) we are always looking for ways to make improvements, to do continual improvement (Kaizen), and improve our products, plans, baselines or processes; and (2) Rolling-Wave Planning. We may purposefully save some planning for the very end: the “punch list” or “walk through plan.” So, normally, there are even updates to be done to plans and documents at the very end of the project in closing.
Note: this article reflects the viewpoint of the author, Mark Tolbert, and does not necessarily represent the views of PMIWDC. If you disagree with or object to the views expressed here, please let us know