Part Three of AgileProject Management vs. PMBOK® Guide and EVM- “Revolution or Evolution?”

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.

About the Author

Mark Tolbert

Mark has over 30 years of experience in I.T., including 27 years at Hewlett-Packard. He successfully managed support programs and projects within HP Services from 1994 through 2007. The programs and projects included a large E-Selling program, a multi-vendor support program for a large telecommunications company, data center relocation projects, and MDM (Mobile Device Management) programs.

Since leaving HP in June of 2007, Mark has been teaching PMP Prep classes. Mark has taught for several leading education companies including Velociteach and Edwel programs. Mark has also taught classes for the Washington, DC PMI Chapter for the past eight years. In 2010, Mark also started his own training company - ‘Best Practices PMP Training’ –adding to and building on core ideas learned from these other programs. Over the past four years, Mark has assisted hundreds of students pass the PMP!

Mark earned his PMP in 1995, and has been very active in the Washington, DC PMI chapter for the past 15 years. He has served on a number of board positions for the chapter, and is currently serving on the board as the trustee for the chapter.

Mark is very passionate about project management, and believes adopting the best project management practices and skills is crucial to the success of enterprises today.

Mark is a long time resident of Northern Virginia, and currently lives in Annandale with his wife Linda.

Printer Friendly, PDF & Email

Thank you to Our Sponsors

Diamond

Platinum

Gold

Bronze

Friend