pmStudent

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.

I am in the process of a paradigm change for a project team I was recently assigned to.

I have discovered (once again) that methodology matters, but perhaps not in the way you are thinking right now as you read this.

What I Don't Mean

No, I'm not saying that Scrum or CCPM or Waterfall are "the" best method of managing projects.  When people start talking about how one methodology is better than all the rest, their perspective is often clouded with ideology.

What I Mean Is...

The processes you use to manage projects does matter.  Mostly, the project environment, team(s), and stakeholders will lead you towards a way of managing projects that is a hybrid of the well-known models out there plus lots of organization-specific pieces that you won't find in any manefesto or "how-to" book on project management.

My Example

For my example, I am working on a large federal contract with a small team who is responsible for 2 of the 8 or so subsystems within one segment of the project.  The project as a whole, and the individual contractors are using traditional waterfall methods and EVM, with multiple releases of the subsystems (a.k.a progressive elaboration).

My team has had experience with Agile methods in the past, and they love working that way.  So do I.  So.....

We have collaborated on a hybrid approach that uses some of the aspects of Agile (Scrum in particular) that we can gain clear value from while throwing aside some of the other aspects that just won't work well in our environment.

For process, we will be doing 2-week sprints with the standard major releases, product backlog, and sprint backlog.  We did our first sprint planning session today which went awesome, and we'll do informal retrospectives too.  We will have daily tag-ups for 15 minutes each morning to ask and answer the following questions:

1. What did you do yesterday and how much is left on those tasks?
2. What will you do today?
3. What worries or obstacles can you see currently or on the horizon?

For tools, I started with a Scrum template from Petri Heiramo from Digia and modified it heavily to fit our unique needs.  I added resource-loading capabilities to the template and other key pieces of functionality, including a tab which translates the Scrum-ish progress updates into a format I can easily update our main project schedule with.

Not Throwing Out the Baby, But Some of the Bathwater Must Go

We are not doing the standard software development you might see with Scrum. 

We won't have discrete releases at the end of each sprint, so we've thrown that part of the Scrum methodology out.  Instead, each sprint gets us closer to a major release with clarity of planning and the ability to respond to the changes we enjoy on a daily basis.  Our subsystems are almost entirely database systems, but they support and integrate with all of the other subsystems and so many changes in those subsystems impact us directly.

Which is why I'm also throwing out the idea of a sprint baseline (sort of).

We've decided that after the initial sprint plan is finished for a given sprint, I'll save it as a baseline but then a working copy of the tool will be modified on the fly, daily.  We'll remove and add tasks, adjust estimates, whatever it takes to respond to the constant changes around us.  We'll get better at estimating as time goes on, anticipating potential changes and rework coming from outside the team, etc.

So Agilists will say we're not doing "real" Agile.  And Waterfall enthusiasts may glare at us.  So what?  I've ensured I can meet or exceed expectations for advanced and short-term planning, and excellent status reporting.

We've worked out a promising process that meets all our needs and my team and I are jazzed about.

And I couldn't be happier.

Image:  Cookie cutters by G & A Sattler via Flickr

What do you think?  Got a comment on what I'm doing, or a story of your own to share?