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 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

6 thoughts on “PMI and the meta-planning process, or why software development planning is different

  1. Two jewels of organizational thinking in A. Ward: Lean Product and Process Development.

    Main sources of knowledge waste are Wishful Thinking, Scatter and Handover.

    Whenever you separate Knowledge, Responsibility, Action and Feedback, there will be knowledge waste.

    A separate project organization easily causes Scatter in time and space. Vasco pointed out, that PMI explicitly recommends this.

    A bit more in my blog entry

  2. Vasco,

    I agree with the post. Doing software development in a product management organization for a release is different than project management. In PMI-speak they might call this a program. The Program Management standard would talk about how to coordinate multiple projects that should be managed together.

    Also, if I come to a team and say, We are going to use Scrum as our project management approach. Here are the processes we follow, here is the organization of the team, here is how we need to interface with the business. We will figure the rest out as we learn.” You have just established your project management plan. It is important that we make distinctions where necessary but not arbitrarily.

    In Agile, we establish a “project management plan” – a strategy for managing the project – and we share it with the team, are very disciplined about it, and we adapt it as we go along. There is nothing contrary here. Actually, there is a lot of discipline and structure in an Agile Team around how we will do project management. PMBoK does not describe “how” the process is to be implemented. They describe “what” you need to be addressing.

    The other thing to keep in mind is that software development is likely not the entire effort. There are marketing, sales, accounting, support, implementation, customer, and strategic planning aspects that need to be coordinated around the software development effort. Agreeing on how we will manage these is also important – and for a large part – not in the typical implementation of Scrum.


    If you could please point me to the PMBoK 4th Edition reference that says you need a separate project organization I would appreciate it. My research shows that PMBoK describes multiple forms of organization including a projectized organization, a matrix organization, and a functional organization. I don’t see a recommendation to create a silo organization anywhere in the PMBoK.


  3. @Dennis

    Yes, we need to be structured about how we coordinate/synch multiple projects in a product development organization. I agree with that.

    However, in PMBOK there’s a clear emphasis on the project management plan. In product development organizations that is an activity that is not needed because those processes will be in place already (how to start projects, how to synch them, how to terminate them, how to interface with other aspects of the business, etc.).

    Strictly speaking we could therefore say that we don’t do project management in product development organization. That is not the case however, because as you also point out there are many things that need to be thought about (like ramping up production, for example which is likely to include unique activities that are not “operations” as such).

    To sum up, what I call the “meta-planning” process comes from the assumption that everything is done as a project in an organization (project organization for which there’s even an org chart in the 3rd edition of PMBOK), which in turn assumes a purely functional organization (that’s why we need projects).

    In my experience that’s a very idealized view of reality (even if partially true).

  4. Hi Dennis,

    thank you for correcting my expression.

    Already based in your comment I bet that PMBOK does not recommend silo organization. I doubt any recent guide does. I am familiar only with the earlier versions of PMBOK, unfortunately.

    Vasco’s post about a separate project management plan touched the frustration that I have shared in the vast majority of software projects I have seen.

    I try to reformulate my point:

    People have a great tendency to fix organizational challenge by adding yet another separate role, task, or person. There are reasons for this – managers (not PM) avoiding work supervision and some basic assumptions, for example excessive belief in predictability, externalized resource management, command and control leadership. These assumptions happen to work especially badly with SW development. How much are these discussed in PMI circles (sincere question)? Agile tradition is trying to work with those.

    I am questioning, how productive is to have a heavy focus on project management as a separate coordinating dimension or discipline. For example in product development, focusing on knowledge creation and sharing will solve resourcing problems in long term, but not vice versa (personal opinion). What is said about Toyota’s chief designers, the almighty project managers, is that they have deep substance competence, the coordinator role is not emphasized.

    So I can not point an error in the standard. I would like to share my frustration how and where it is applied.


Comments are closed.