PMI and the meta-planning process, or why software development planning is different
In the previous post I said I’d talk about Project Integration Management. Of that knowledge area from the PMBOK, I’ll focus on one specific Project Management Process within the Project Integration Management (this is how PMBOK calls the different components for each Knowledge Area).The process I’ll focus on is “Develop Project Management Plan”. There’s an …
In the previous post I said I’d talk about Project Integration Management. Of that knowledge area from the PMBOK, I’ll focus on one specific Project Management Process within the Project Integration Management (this is how PMBOK calls the different components for each Knowledge Area).The process I’ll focus on is “Develop Project Management Plan”.
There’s an important distinction between what PMBOK suggests and what I’ve seen in the field (in software development organizations). The PMBOK talks about the project manager having to build a project “management” plan. Note the difference: not a project plan, but a project “management” plan.
The reason for that is, according to PMBOK: This process is needed
for defining, preparing, integrating and coordinating all subsidiary plans into a project management plan. The project management plan becomes the primary source of information for how the project will be planned, executed, monitored and controlled, and closed.[1]
In plain English this means that before you start the project you need a “meta-plan”, i.e. a plan on how you plan to plan & manage the project (read that sentence again, it makes sense…)
In many (but not all) software organizations this particular process makes no sense. Why? Because it is very likely that you are involved in developing the next dot-version or major version of an existing software product/service. This is a major difference to what PMBOK and the PMI certification/approach is about.
In software, a lot of what we do is very much akin to what PMBOK calls “operations”, i.e., a time-limited development effort within a context/organization that is pre-existing and has processes in place to deal with this (ongoing work vs. temporary and unique work). For the majority of the software organizations and projects out there this process is simply not useful.
It is important, of course, to be aware of this “meta-plan” or processes. For that reason alone it would be beneficial for many to read books like Alistair Cockburn’s Agile Software Development or Jim Highsmith’s Agile Project Management or even PMBOK (less entertaining as it may be).
Being aware of this “meta-plan” or process is very useful, but not enough. In other words software project managers can still benefit from what PMBOK describes: PMBOK is useful, but not enough for software development endeavors. This will be, as we shall see, a running theme in this series of posts.
Tomorrow we will talk about the Project Scope Management Knowledge Area and why the Scope Planning process in PMBOK is out of synch with today’s (agile) methods for developing products in a software organization.
[1] PMBOK Guide, 3rd edition, 2004
Keep the conversation going
The essays work best in company. Join the community to keep the questions coming.