7 Essential Project Planning Documents

From the Voices on Project Management Blog
by , , , , , , , , , , , , , ,
Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with - or even disagree with - leave a comment.

About this Blog

RSS

Recent Posts

End a Business Relationship and Keep Your Cred

Fair's Fair

Give Your Project a Home

A Hollywood-Style Move From PM to Scrum Master

To Have and To Hold

Email Notifications off: Turn on

Categories: Project Planning


Solid project planning is a prerequisite for project success. Poor planning, meanwhile, can lead to missed deadlines, budget overruns, poor quality deliverables, frustrated project teams and even project failure.

In my previous post, I offered five steps to assist in planning the project-planning phase. One of those steps involved preparing planning documents.

To foster a successful planning phase, here are seven planning documents I believe most project managers will find indispensable. This list certainly might vary depending on the project setup, project size, complexity and organizational planning guidelines.

1. Project management plan -- This is used as a reference index, encompassing all planning and project documents.

2. High-level project schedule plan -- This document captures high-level project phases and key milestones. It is the document most project stakeholders will see or want to see.

3. Project team planning -- This document provides a "who-is-doing-what" view of the project. This document fosters efficient project execution and effective project communication.

4. Scope plan -- The scope plan documents the project requirements, the agreed scope and the Requirements Traceability Matrix (RTM) summary.

5. Detailed project work plan -- This keeps track of the activities, work packages, resources, durations, costs, milestones, project's critical path, etc. It will be an essential document and work guideline for your core project team.

6. Quality assurance planning -- This document tracks the quality standards your project deliverables will have to align to. These may typically include product testing approach and tools, quality policies, quality checklists, deviations definitions, quality metrics, product defect severity grades, acceptance criteria, cost of poor quality, etc.

7. Risk planning -- This document contains the project risks and the related mitigation plans; as well as the project opportunities and the related exploiting plans. The importance of this document is one of the most underestimated in project planning. Be prepared to have a contingency plan in case something goes wrong or to take advantage of opportunities when they arise.

Start with this checklist when you sit down to plan for your next project-planning phase. Depending on your project's needs, fine tune the checklist and tailor it by adding and removing planning assets, determining the planning time frame, the underlying details and rigor.

Revisit this planning exercise, learn from it and enhance it, to continuously improve your project planning skills.

What project planning documents do you find indispensable?

See other posts from Marian.

Posted by Marian Haus on: November 08, 2011 12:31 PM | Permalink

Comments

Fez Miester
Nice post Marian, having those lists or documents created uniquely by the essential people or board of an individual project would help steer. Do you create standards or make your new team per project design each of the 7 documents anew?

Mounir Ajam
Dear Marian You are contradicting yourself. Here is how: In your second paragraph in this post you write: "In my previous post, I offered five steps to assist in planning the project-planning phase." Yet in the post you are referring to, you said: "Planning is not just a one-off activity completed in the early stages of a project. Planning is a process (or rather a group of processes), conducted throughout the project." So in one post you say planning is a "phase" and another you say "planning is a process". So which is the correct position?

Mounir Ajam
A few more comments: 1. Is not scope more and less = work? Most of you list under work plan is already part of scope or schedule (activities, critical path, milestones are all schedule) 2. Where is the cost plan? 3. Where is the communication plan? 4. Where is the change management plan?

Marian Haus
Mounir, thanks for the comments. Regarding the phase vs. process I see the two terms complementary in this context. I see the "planning phase" as a line (or actually a Gaussian curve to be precise) stretching throughout the project lifecycle. We start planning very early in the project, peak while the execution is accelerating and stop towards the end of the project execution. I also see "planning" as being a "process" rather than a simple activity. One does the planning as a series of steps, executed in a certain sequence, with inputs and outputs, etc. Regarding the other type of documents, certainly they are also important for the planning. The focus of this post was on the planning documents which I find essential, rather than on a comprehensive list of planning documents. I will not comment the importance of each the documents that you mentioned (which is by the way undoubtful); however in my next posts I shall dive deeper in each of the planning documents, including the ones that you mentioned.

Nadja
7 planning documents are too many!

Emad E. Aziz
Great and very resourceful article. I assume the Project Management Plan includes the Communication Management Plan, which out of experience has proven its utmost vitality in every project/program I have managed.

Two other tools i wouldn't plan a project without, and would create from the beginning along with initiation are the "Issues/Dependencies/Decisions Log" and the "Change Log" the earlier entries are logged and monitored the higher the delivery assurance.

Tony Pashigian
Marian: Your list is clearly the blocking-and-tackling of program management and serves as a concentrated "get started" resource.

It has been my experience that program managers that create the "detailed project work plan" (your number 5) often end up force feeding it to the team or just look on as the team does what they feel is best while referring to the "high-level project schedule plan" (your number 2).

So, I have had success compiling the functional group's individual detailed plan into a comprehensive detailed project work plan as opposed to creating it by committee or by myself. It seems that they act as if they have a dog in the fight if it is their plan instead of the program managers.

The could very well be what you meant. I just thought I would add the refinement for consideration.

Tony Pashigian

Marian Haus
Nadja, thanks for your comment. Planning in all those areas might sound like too much, but in reality this is what makes projects hard to control (especially big and complex ones), which is the missing or poor planning. Let’s not forget the saying “Proper Prior Planning Prevents Poor Performanceâ€쳌, which too often proves to be true.

Emad, thanks for your reply. You’re right with the comment on the Communication Plan. Regarding the logs, I personally always use the issues logs, change logs etc as complementary tools, to stay on top of issues, challenges, etc.

Tony, thanks for your valuable comment!

-Marian


Job Veenstra
Nice artikel. I agree with your steps. What I would like to add to the detailed project work plan is remote access. With remote access project managers and employees can share and access the project information from everywhere. It will let them work in a flexible way and support the new way of work. I think this is a key feature for a succesful project.

Glen B. Alleman
The scope is defined in the Work Breakdown Structure (WBS) and the WBS Dictionary. That's a single document . The project team planning is defined in the Organizational Breakdown Structure (OBS). Skill sets can be identified, but the assignment of work takes place at the intersection of the WBS and the OBS. This is the Responsibility Assignment Matrix (RAM). It shows who is doing what. This can be monetized as well to show how the budget is allocated to the work effort. The detailed work plan mentions all the elements of the Integrated Master Schedule. It should be called that. The Risk Management Plan, must not only have contingencies, it must address the risk "retirement" plans. If there is only contingency, then when the risk comes true - becomes an issue - the project is likely behind schedule and over budget, and the product doesn't work. It is much better to "buy down" risk, than to wait for it to happen. The rest of the "plans" must connect with these. Full traceability from the WBS to all the requirements and then the deliverables is what defines a "credible" project

Please Login/Register to leave a comment.

ADVERTISEMENTS

"A day without sunshine is like, you know, night."

- Steve Martin

ADVERTISEMENT

Sponsors

>