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.

We all know documentation can be useful and is an important part of project management.

But all too often, we go too far.

Here are just a few ways your own project documentation can run amok.  Seek out and destroy them.

Relying on Documentation for Communication

It's always so strange to me when I hear someone justify a lack of communication by saying they assumed everyone knew about it, because it was on page 734 of the software design document.

Really?

My first question is why the hell we have a software design document with 734 or more pages?

Second, exactly what mechanism do you think is at play that would allow all stakeholders and team members to be aware of every update to all the documentation on your project?  Did I miss the memo about the new matrix-style jacks so we can all plug in and download information directly into our brains?

When I talk about communication, face-to-face is always preferred, followed by phone, then email.  Communicating via documentation is not even on my list because it's not a method for communicating.  It's for documenting.

Ask yourself...is this information best used as a book is used?  Is it something that needs to be documented so it can be learned by someone new, years down the road?  Are you trying to shove a bunch of stuff into it that could best be communicated in another way?

Producing Documentation that Provides No Value

When it seems you are putting more time and effort into writing documentation than actually producing a product, it's time to ask yourself what value that documentation is providing.

Every section of every document should have a purpose.  It should have a user.  If there is no user, there is no purpose.  Who is going to read this thing?

User stories can be wonderful for identifying the value for documentation, and specific sections within documents.  If you're not familiar with user stories, they are simple.  Use the following syntax.

"As a [user] I want [something] so that [benefit]."

I encourage you to create a set of user stories for every document you have.  Go show them to the users and validate you actually know what the [bleep] this is being used for.  It  will be an enlightening experience.  I have gone through this activity and cut 60-page management plans down to 8 pages in length, without losing any value.  In reality, the organization actually gained value because someone might actually read an 8-page document.

I have come into organizations and found documents that have taken on lives of their own.  When I ask why a particular activity is being performed because I don't see what it's used for, I am told "it's for the TPS report".  When I ask who reads the TPS report the answer is "I don't know."

Hmm.  Let's stop doing it, and see if we get any phone calls.

Producing Documentation as an Alternative to Trust

Do you ever get the feeling some things are documented just so someone can point a finger and say "I told you so!" or "You should have known better!"

Documentation (and process) is no alternative to trusting people to do the right thing.  A classic example is the case where a simple point-to-point communication step in a process is turned into a frankenstein monster.  I once was on a project where an update to configuration-controlled artifacts was implemented by a specific individual.  After changes to the project were formally approved, this person would update the baseline.

The 'trigger' to have this person look for the completed change request and update the baseline could be as simple as "give Jasmine the CCR number and ask her to update the baseline."  Instead, a whole new tool was set up so that timestamps could be saved and requests would be formally documented.  Mind you, this is completely separate from the system used to actually run the change control process.

In the end, this insanity resulted in pages upon pages of documentation about the new system and all of the scenarios that could possibly every happen.  There was no trust in the people running the process in the first place; and no trust that people on the project had enough brain power and common sense to fiture out what to do in case things didn't go smoothly.

Trying to document every 'what if' scenario is as futile and worthless as trying to manage every risk.  Only a handful of scenarios are worth the time and effort to plan for.  Like the one that mud people will emerge from the bay and raid our server rooms, frying server after server with their muddy slime and killing our project.

Damn mud people.

images by A.K. Photography and ChernobylBob

Share this with your network