Skip to the essays
All essays

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.

The #NoEstimates book and its companion volumes

Chapter 1 · Free PDF

What if better planning started with a different question?

The first chapter of #NoEstimates argues that the “deliver on time” challenge is answered by a different question. Read it, and see whether it changes how you plan the next piece of work.

Free PDF of chapter 1. No purchase, no library access. How we handle your details