Project Management Plan: Not What You Might Think

From the pmStudent Blog
Ranting and raving about project management and systems engineering.

About this Blog


Recent Posts

The Problem with Project Management

The Problem with Project Management

The Problem with Project Management

LinkedIn Recommendations Are Easy

The Catch-22 of Project Management Certification and Experience

Categories: Documentation, Methodology

The concept of a Project Management Plan has been defined and implemented in various ways.

For example, I've heard project managers refer to their MS Project file as their "Project Management Plan".  (I'm not even going to go there....if I start on that, I'll go on a rant about how that's so bad, it's not even wrong.)

I have also seen it implemented in such a way that it attempts to capture all of the scope, cost, and schedule and other related artifacts.

It turned out to be a huge pile of paperwork, with lots of effort to compile it, only to never be seen again.

It was useless.  Why?

It Didn't Add Value

The only reason for a document to exist on your project is to add value.  If it's not dynamic enough to be modified quickly by a lean change management process, it's going to die and go to artifact heaven (or hell).

One of the best ways to ensure something doesn't add value is to make it a redundant copy of something else that already exists.  In this case, there were already all of the artifacts outside of this "Project Management Plan" that were the REAL documentation, the real baseline for the project.

So What Should a Project Management Plan Be Then?

I'm glad you asked.

A Project Management Plan should be the defining document for HOW the project will be managed.  No more, no less.

It's the documentation of your project management methodology.  You can hand it to a stakeholder or customer and they will be able to read it and understand how the project is run.  When processes need to change, they should be updated in the plan.  A new employee joins the project?  Reading the Project Mangement Plan will orient them to "how things work around here."  Not WHAT we're doing, but HOW we are going about it.

Here are some critical areas to be sure your Project Management Plan covers:

  • How are Changes managed?
  • How is Scope planned and managed?
  • How is Cost estimated and how are Budgets set?
  • How is Schedule set, managed, and reported?
  • How are Staffing considerations handled?
  • How will Communication be effectively facilitated?
  • How will Risks be identified and managed?
  • How are Procurements to be handled?

You'll notice these line up pretty well with the PMBOK Knowledge Areas.  I tend to call out change/configuration management as it's own knowledge area, because it's so important and so poorly done on many projects.

So, that's my experience of what a Project Management Plan should be in order to add value to your projects.  I found this article here on Gantthead which agrees with my take on the plan.  Some of you may disagree with my approach.  I'd love to hear your arguments for alternative approaches in the comments.

Posted on: May 29, 2011 01:00 AM | Permalink

Comments (4)

Please login or join to subscribe to this item
Great article. Should we also include how quality is being controlled and managed?

That's a great point. My preferred implementation is to include quality with configuration management. The two disciplines are very much intertwined. In my course on the PM Plan, that's where I include the parts regarding quality management.

Thanks for pointing that out!

Completely agree with this article. Where can I find a Project Management Plan template that already incorporates best practices and discusses the process (How) for all of these areas? When I look on this site, all I find are project schedule templates (MS plans). This is not what I''m looking for. Thanks in advance!

Great article! Today I was trying to explain my PMO the difference between the SOW and the PMP and is this goes straight to the point. Great thinking Josh!

Please Login/Register to leave a comment.


Denial ain't just a river in Egypt.

- Stuart Smalley