Why Shelving Your Project Plan is a Bad Idea

ProjectManager.com

Watch the following video with Jennifer Bridges, PMP and discover why you should never leave your plan gathering dust on a shelf…

In Review: Why Project Plans Should Not Sit on the Shelf

Jennifer noted that once project plans are created they’re not “done.” Rather, plans are living documents that are necessary to continue and access for the success of the project. Why put in all that front-end work if you’re not going to utilize it in the heat of the project?

She noted that components of a project plan:

  • Outline the processes
  • Detail how processes will be communicated
  • Configure and manage changes
  • Direct costs
  • Control procurement, quality, risk, baselines, schedule and scope

So with this knowledge, how can you keep the project plan relevant? Jennifer offered these three questions a project manager must ask:

  • What should I update weekly?
  • How do I monitor?
  • How do I communicate?

A project plan is in flux as your project evolves, and has to reflect those changes and clearly communicate them to team and board members, as well as stakeholders.

Everyone must be involved. No dust allowed.

Pro-Tip: In terms of updating your project plan while in the midst of a project, it’s recommended to do this in real time. While weekly updates can work, with online software tools that give project team members access, real-time updates are not only feasible but easy to integrate.

Thanks for watching!

Transcription

Hello, I’m Jennifer Bridges, Director of ProjectManager.com.

Welcome to our whiteboard session today on Why Project Plans Should Not Sit on the Shelf. Well, back in the day, I spent quite a few years working with organizations on process improvement initiatives and specifically the Carnegie Mellon Capability Maturity Model.

So one thing that I got to do is go into organizations and work with different project teams to look at their project management processes. So a lot was uncovered, and more importantly I uncovered some of my own sneaky tricks. One thing I found had to do with project plans, and it had to do with once a project developed or a project manager developed a project plan, many times I would find that it was sitting on the shelf. No one was really referencing it. Sometimes people or the project managers thought, once the project plan was developed, they could just sit it on the shelf and then their work was done.

Well, it doesn’t really work that way, and it’s very important not to let the project plan sit on the shelf and here’s why, because the project plan, I’m going to reference a couple of things. Number one you can reference what a project plan is. There are many sources out there you can Google. There are different methodologies out there. I’m going to reference the “Project Management Body of Knowledge” specifically by PMI and outline what they include in a project plan.

So what PMI includes in a project plan are these components. The project plan outlines the processes or how a project manager and how a project is going to handle different aspects of the projects. Specifically, things like change management, how are we going to manage the changes that occur on the project? Communications, how are we going to handle communications? Who needs to know what, when, and where, and how? Configuration management, if anything changes in the configuration or design of the product to be delivered, how is that going to be managed? The cost management, cost performance, human resources, process improvement, specifically if we had the project management processes for this project outlined, then what is the process that we go through in order to modify our process to make it better, more efficient? Also the procurement management, quality requirements, risk schedule, baselines, schedule management, scope, the baseline which includes the WBS, the work break down structure or the statement of work, and the scope management.

So, as you can see, the project plan includes every important piece of the project and how these are going to be managed, and each one of these pieces of the project plan indicates, monitors, tracks, manages different documents or deliverables for the project. So, as you can see, these are very important. Once you get these defined, that’s why they don’t need to sit on the shelf.

So a lot of people ask different questions about this. They want to know what to update weekly. So if you’ve watched some of our other whiteboard sessions, I subscribe to the fact that I feel like project managers need to be updating these things real time, and with now software tools and being able to give project team members access to the software so things can be updated real time, I subscribe to that, but for sure if not real time, updating things weekly. That is defined in the project manager’s project plan for that project.

The process is dictate what gets updated weekly, but certain things like risk, issues, changes, different things that are happening with your scope, your resources, so everything associated with each one of these plans, again these plans manage different documents, different deliverables being produced for the project. So in essence, each one of these need to be monitored, tracked, updated weekly, and it should be defined in your project plan. Your project plan should say which one of these are going to be updated, how often, who knows, who is responsible for updating these components.

Then we ask how to monitor. So again, this is another aspect that’s to be defined in the project plan, because if you think of a project plan, think of it as a playbook. If you’re in sports, it’s the playbook. If you’re a musician, it’s the music sheet. This is how you operate your plan. I brought one with me. This is just a simple project with the project plan in a notebook. So the notebook has a table of contents with all of these things included. This can literally sit on the shelf on your desk, but meaning don’t let it sit there without being updated.

It indicates what is to be updated, when, and by who. Also is asked how to communicate these changes. So again, this is defined in specifically the communications plan. The communications plan outlines what is to be communicated, when is it to be communicated, how, and to who.

So these are some of the things that are components of the project plan. This includes showing that it’s defined within the project plan and why it’s so important , because these are the dynamics of the project, and that’s why it should not sit on the shelf because these things are changing constantly and it has to be updated, communicated to all team members, including the Change Control Board, stakeholders, and everyone involved.

So I hope this helps, and I hope this helps explain why your project plan should not sit on the shelf.

If you need a tool to help you manage your project plan components, then sign up for software now at ProjectManager.com.

Related Posts

Back to Blog

Get the Best PM Tools for Your Team

Start a Free Trial