NOTE: See also the “Downloads” section of the website for the Project Plan template.

The Project Plan Contents

Revision History Table

Like any important and constantly changing document the Project Plan should contain a “Revision History” table (see Exhibit 1). The purpose of the table is to record version number, version date, name of the person making the change and a short revision description.

Why should we keep a record of all the changes made to the document? First, one can expect to make up to several dozen revisions to a project plan during the planning and execution stages. Stakeholder feedback, customer-initiated updates and technical project team inspections act as a source of updates and modification to the document. By the same token, during the execution stage change requests, various risks and other events may have an impact on various aspects of the project. Committing all of this information to the memory of the project manager is probably not the most efficient use of his brainpower.

Secondly, people have the tendency to save the files they receive via e-mails to their computer hard drives. As a result they continue referring to the older versions of the document while the newer, “fresher” versions have already been posted in the project documentation repositories. Therefore, “what version of the document are you looking at?” is one of the most frequently asked questions in conversations between the project manager and the project stakeholders.

Exhibit 1

Version Number	Version Date	Added By:	Revision Description
0.1	01-Sep-2009	John Smith	First draft of the document
0.2	15-Sep-2009	John Smith	Changes in scope and time made after the review with the project team
0.3	20-Sep-2009	John Smith	Changes and additions in scope, risks and budget sections made after the stakeholder review
1.0	10-Oct-2009	John Smith	Document sign-off

 

Overview

Document Purpose

It is worthwhile to start the document with an explanation of its purpose, since the readers may include people who are not very familiar with project management and may not fully understand the objective of the project plan.

A sample text for the project plan overview is provided below:

 

“This document is the project plan for the <Project Name>. It addresses scope, deliverables, risks, assumptions, milestones, schedule, budget and team working practices required to achieve a successful outcome.

"The Project will be placed under the Change Control process once signed off.

Updates to the Project Plan must be reviewed and approved by the Project Manager and any relevant stakeholders for the section that is changed. “

 

List Of Relevant Project Sponsors And Stakeholders

Also, a list of all the relevant project sponsors and external stakeholders should be included in the “Overview” section (see Exhibit 2).

Exhibit 2

Project Role	Name	Organizational Role
Project Champion	Robert Smith	COO
Project Sponsor	John Black	CFO
Customer	Leslie Brown	VP, Sales
Stakeholder	Cassandra Jones	Director, Marketing Department
Stakeholder	Alexandra Smalls	Director, Legal Department
Stakeholder	Joseph Chan	Director, IT Department

Among other things this table serves as a quick reference check as to who should approve the project plan, scope documentation and all subsequent change requests.

Project Scope Management

Project Goals

Provide a high-level description of the project scope. Identify why the project was initiated and what opportunities it is supposed to seize or what problems it is intended to solve. Note that the original project goals were outlined in the Project Charter, so you will probably have to revisit the original document.

Project Feasibility

Comment on project feasibility. Mention which model was used to assess the project’s feasibility (e.g. NPV, IRR, payback, weighted-scoring model, strategic importance, strategic risk management, etc.) Keep in mind that the first feasibility estimate was done in the Project Charter, so you will probably have to revisit the original calculation and assess whether the inputs into the formula (project cost estimates, increase in revenue and/or decrease in costs, discount rates) have changed.

Another important factor to remember is that the measures of feasibility mentioned in the Project Plan template should be synchronized with the factors used by the senior executives of the organization to assess the value of the ventures at the portfolio process checkpoints.

Scope Inclusions And Exclusions

Mention several key features that will be included in the scope of the project. Also provide a list of high-level scope items that should be excluded from the scope of the project.

For example, for the “Scope Inclusions” section the document may state:

• Feature 1: Three-bedroom, two-bathroom Victorian style family home
• Feature 2: Separate two-car garage
• Feature 3: Swimming pool

And for the “Scope Exclusions” part may list:

• Fence around the property
• Property landscaping
• House furnishings
• Household appliances

These sections allow the project manager to establish the scope boundary and to list the high-level items that will be specifically excluded from the list of deliverables to avoid possible unpleasant surprises in the future.

Scope Definition Documentation

There are several possibilities available for this section of the document. If the project is very small and does not require any additional scope documentation – a fairly rare occasion – this section can be used for a detailed description of the project scope.

However, if the project is of medium or large size, separate scope documentation should definitely exist in a form of a separate standalone document. These documents tend to have variety of names and titles as one moves from industry to industry, from company to company and even from one department of the same organization to another. They are called “System Requirements Specifications”, “Software Requirements Specifications”, “Detailed Design” in software and IT industries; “Requirements Specs”, “Statement of Work”, “Bill Of Materials” and blueprints in the engineering field and several other fields.

The point of this article is not to dwell on a specific document names but rather to highlight the importance of the detailed scope documentation in general and provide a reference to it in the project plan in particular.

Thus, it is very important to provide a link or a location of the Scope Definition documents in this section of the project plan.

Project Time Management – Schedule And Milestones

Estimation Methodology

Mention what methodology was used to obtain the estimates (e.g. top-down, bottom-up, historical or expert judgment). Please note that while at the Project Charter +75/-25% degree of precision was required, at the completion of the Project Plan the estimates should be at +30/15%).

Project Duration

Indicate project duration in days, weeks, months or years, whatever is applicable to the size and the complexity of the project:

• Plus-or-minus qualifiers – e.g. “6 months ± 2 months”
• Ranges – e.g. “4 months to 8 months”
• Cases – e.g. Best case – 4 months, Most likely – 6 months, Worst case – 8 months
• Coarse dates and time periods – e.g. “3 Quarters” instead of “270 days”
• Confidence factors – e.g. “We are 95% sure the project will be done in between 90 and 118 days

Project Milestones

Include key project milestones as shown in Exhibit 3. Provide +/- qualifiers for each date. The idea behind this table is that senior managers and customer are probably unlikely to examine complicated Gantt charts created in MS Project or other project management software. Thus, a list of key high-level milestone could be of great assistance in explaining the general schedule for the project in question in a user-friendly, easy-to-understand fashion.

Exhibit 3

Project Phase/Activity	Completed By
INITIATION
Project Charter	12-Sep-2009
Kick-off Meeting	20-Sep-2009
PLANNING
Project Plan	30-Oct-2009
Requirements Document(s)	20-Oct-2009
EXECUTION
Activity 1	15-Nov-2009
Activity 2, etc.	20-Nov-2009
Note: All dates provided are +/- 2 weeks

Gantt Chart

If the project required a creation of a Gantt chart in Microsoft project or other project management software, include a link to the MS Project .mpp file. These files are probably unlikely to be reviewed by the business, non-technical stakeholders, but project management professionals at your organizations and technical team members of the project team may need to see a more detailed view of the schedule and specific tasks.

Project Cost Management – Budget

This section of the document should contain a project budget table. The level of detail appropriate for the project plan varies from company to company and from industry to industry, but it should at least include variable costs, fixed costs (overhead) and other expenses including bonds, forward contracts, foreign contracts, contingency and escalation costs (see Exhibit 4 for a sample project budget).

Exhibit 4

Furthermore, the total cost figures should also include +/- qualifiers as was the case in the duration estimates.

Project Quality Management

Describe which ones of the Quality Management tools and techniques will be utilized in your project to ensure proper quality management and control:

• Document control
• Training
• Customer Complaints
• Design and Development
• Peer reviews
• Inspections
• Customer feedback
• Document management
• Testing
• Change control, etc.

Preferably the project plan should also specify the timing of these activities or indicate if they are ongoing tasks. For example:

“Appropriate safety and security training will take place in the first week of the execution stage of the project.”

“All key documents including project plan, scope and design documentation and change requests shall undergo peer reviews and inspections before the sign-offs.”

“Testing will take place at the end of the execution phase between 15-Jan and 25-Jan.”

Project Human Resources Management

Project Team

List all of the project team members in the table below. For the project role try to mention person’s role on the specific project rather than his/her title in the organization (see Exhibit 5).

Exhibit 5

Project Role	Name
Project Manager	Brenda Yang
Scope Specialist	Cathy Nadeau
Public Relations Expert	Daryl Leung
Legal Expert	Justin Robinson
Engineer	Michael Moniz
Architect	Paul Sutherland
Foreman	Rob Teves
IT Specialist	Sara Whyte

Responsibility Assignment Matrix (RAM)

It would also be a good idea to assign responsibilities to at least each key task to specific personnel on your project. This will allow the project manager to avoid potential future surprises and miscommunications especially in a traditional functional organization where the resources are assigned by the departmental managers and directors.

Responsibility Assignment Matrix (RAM) is a tabular representation of the project tasks and resources responsible for completion of these tasks (see Exhibit 6 for a partial RAM).

Exhibit 6

	Project Team Members
Deliverables	Project Manager	Scope Specialist	PR Expert	Engineer	Architect
Project Plan	X
Scope Definition	X	X
PR Campaign			X
Design Documents				X	X
Blueprints and Bill Of Materials				X	X

 

Project Communications Management

Communications Planning & Distribution

Exhibit 7 contains a partial list of key project documents that have to be distributed during the project. It is a good idea to decide who should and wants to receive what documentation at the beginning of the planning stage in order to avoid the complaints from people who needed to receive the documentation but were not notified. By the same token senior managers may request to be excluded from the meeting minutes mailing list and be sent status reports instead.

Exhibit 7

Document	Distributed To	Frequency
Project Charter	All project stakeholders	Once before the sign-off. Posted on the intranet afterwards
Project Plan	All project stakeholders	Once before the sign-off. Every time a significant change is made to it. Posted on the intranet afterwards
Meeting Minutes	Project team, other stakeholders based on individual requests	Weekly. Posted on the intranet afterwards
Status Reports	Customers, senior management	Bi-weekly. Posted on the intranet afterwards
Lessons Learned	All project stakeholders	Once. Posted on the intranet afterwards
Change Requests	Change control committee, project team	As needed. Posted on the intranet afterwards

Project Meetings and Meeting Minutes

Describe how often the project’s status meeting will be conducted and when (e.g. “project status team meetings will be held weekly on Wednesdays at 2:30 pm”). Also, specify how the meeting minutes will be created, who will be responsible for writing them and how they will be distributed and stored. For example:

“Project status team meetings will be held weekly. Project manager will be responsible for keeping proper meeting minutes and publishing them within 24 hours after the project meeting. Also, all project stakeholders shall be e-mailed meeting minutes upon their requests.”

Project Documentation

Include a reference to the project documentation locations. For instance:

All project documentation related to this project will be kept in the following folder: F:/Projects/Project ABC

Project Risk Management

The Project Risk Management section does not differ too much from the “Risk Management” section of the project charter. The only distinction is that by the time the project reaches the planning stage some of the assumptions, risks and constraints have either materialized or become obsolete. On the other hand, new risks could have been identified during the project progress from the initiation to the planning stages and need to be recorded.

Furthermore, there are two schools of thought on whether old but still valid assumptions, constraints and risks should be transferred from the project charter to the project plan. Some organizations think that if they have already been mentioned in the project charter they shouldn’t be copied into the project plan. This document, according to this particular philosophy, must contain only new assumptions, constraints and risks.

The other school insists that in reality once the project plan is written, people rarely return to review the project charter. Hence, they argue, all relevant risk management factors must be restated in the project plan.

It is entirely up to the readers to decide which option is more applicable to them, but in authors opinion the second alternative is indeed preferable due to the simple fact that people typically prefer to keep track of one document rather than two.

Assumptions

Include several (but no more than 5 or 6) assumptions in the table (see Exhibit 8) below.

Assumptions are typically “good” things that are supposed to happen on your project, but you are not entirely sure they will happen

Exhibit 8

ID	Description
A1	“We assume that all the resources required for the successful delivery of this project will be available”
A2	“We assume that the sub-contractor involved on the project shall be able to complete the bridge painting by the deadline indicated in the project schedule”

Constraints

Include several (but no more than 5 or 6) constraints in the table (see Exhibit 9) below.

Constraints are the certain things that constrain your options with respect to the successful delivery of project products or services. They typically, but not exclusively, include deadlines, budgets, availability of resources, etc

Exhibit 9

ID	Description
C1	“Project budget was capped at $300,000”
C2	“Only one senior architect shall be available to perform work on design documentation”

Risks

Include several (but no more than 5 or 6) risks in the table (see Exhibit 10) below.

Risks are the uncertain things that can jeopardize the project success.

Exhibit 10

ID	Description
R1	“There is a possibility of major contractor’s employees going on strike”
R2	“The municipality may require additional environmental cleanup leading to an increase in project budget and timeline”

 

It is also desirable to add the planned responses for each one of the risks outlined in the table above.

Project Procurement Management

Indicate the selection process (e.g., preferred supplier, RFI, RFP, quote etc.,). Describe which parts of the project will be outsourced to the external contractors, who these contractors are and how they will be managed.

In general larger companies have fairly well-defined guidelines on outsourcing and sub-contractor selection. Make sure to reference these policies in the project plan.

Article Summary

This article attempts to describe and explain the process for writing a project plan for a medium-sized project. The following assumptions were made before witting this article:

• Assumption 1: The document contains the absolute minimum of information required for planning a medium-sized project.

• Assumption 2: If the project is larger, more sophisticated or simply has additional requirements specific to a given industry or a company the reader is expected to expand and tailor it according to his specific needs.

• Assumption 3: If the venture is smaller and a simple one, it is recommended to add “N/A” with a brief explanation to the irrelevant sections rather that delete them altogether.

The project plan should include a “Revision History” table to keep track of all the changes, updates and modification made to the document.

An “Overview” statement describing the overall purpose of the document especially for the stakeholders who are not very proficient in the area of project management is highly recommended.

The rest of the document follows the eight project management knowledge areas outlined and described in the Project Management Body Of Knowledge (PMBOK) by the Project Management Institute (PMI). It includes:

• Scope Management section – contains project scope description and reference to the detailed scope documentation.
• Time Management section – includes the project schedule and key milestones.
• Cost Management section – contains project budget broken down into variable, fixed and other costs.
• Quality Management – describes quality tools and techniques that wil be utilized on the project.
• Human Resource Management – outlines the project team and the tasks they will be responsible for.
• Communications Management – explains the distribution of project documentation.
• Risk Management – lists all relevant assumptions, constraints and risks.
• Procurement Management – clarifies all the relevant procurement and outsourcing guidelines for the project.

 

This is an excerpt from my new book “Delivering Exceptional Project Results: A Practical Guide to Project Selection, Scoping, Estimation and Management” that is was published by J.Ross Publishing.

About the Author

Jamal Moustafaev, MBA, PMP – president and founder of Thinktank Consulting is an internationally acclaimed expert and speaker in the areas of project/portfolio management, scope definition, process improvement and corporate training. Jamal Moustafaev has done work for private-sector companies and government organizations in Canada, US, Asia, Europe and Middle East.  Read Jamal’s Blog @ www.thinktankconsulting.ca

• Please follow me on Twitter: 
• Like our page on Facebook: 
• Connect with me on LinkedIn: 
• Subscribe to my RSS feed: 

Jamal is an author of two very popular books: Delivering Exceptional Project Results: A Practical Guide to Project Selection, Scoping, Estimation and Management and Project Scope Management: A Practical Guide to Requirements for Engineering, Product, Construction, IT and Enterprise Projects.