Let’s just say it: The PMBOK® has loops among the inputs and outputs. For all those who have reviewed even a few of the input and output diagrams in the PMBOK®, this was probably a realization that came quickly. This makes it impossible to take a linear path through all the documented PMBOK® activities to get to a set of instructions which says, “do these things in this order and eventually you will be done.”
The point of this blog series is to review what is in the PMBOK® and then explain how it applies to Agile methods. It would have been nice if the project management activities came in a sequential order. I could just run through the order and there would be a nice map of activities, no matter what the development method. Unfortunately, that is not how the PMBOK® authors constructed the PMBOK®. And this discontinuity is what happens in real life. You start defining one thing only to find out a piece is missing. You work on the missing piece enough to go back and finish the first item, but the missing piece is not done and that needs to be finished later. Is this not how work gets done in Agile environments? Just enough work gets done here and there to make a complete system, but the ultimate features are not all there, and different pieces of the system must be augmented to add a new function. Think of the project planning activities in just that sense and the anxiety of not having complete plans diminishes. In a sense, the plan may not be complete until the project is complete (or nearly so).
So, I’m going to proceed through the activities the best as I can. I will not try to reconcile when an input to one activity seems to follow the output of a later activity or situations like that. That depth of analysis will need to be “an exercise for the student” (which is something a professor or book says when they don’t want to delve into a solution).
Here is a specific example of what I am calling a loop. After my last post, Agile Project Management #08 – Risk Management Plan, I was going to move on to write about the Quality Management Plan. One of the inputs to Plan Quality Management is the project management plan. The project management plan is really a composite of many other plans which are inputs to it, so it is already assumed this is a built-in loop which will never unwind. But, the part of the project management plan needed for Plan Quality Management is the requirements management plan. Wait, isn’t the requirements management plan part of scope management, which needs the risk management plan and quality management plan as inputs? So around and around we go. Take a deep breath, and now let it go…. All better.
This is like watching a science fiction show. Once you buy into time travel, easily hackable computer systems, etc., it makes the show so much more enjoyable. That’s like the PMBOK®. Live with the input and output loops, assume that you will revisit activities more than once, and it’s much better.
For the next post, we’ll take a look at the Quality Management Plan and how it works with agile methods. And yes, I did not address requirements management yet.