Project Management Plan Checklist

As a project manager one of the most comprehensive and important documents you will have to produce is the project plan. This plan contains all the key information that you need to manage, monitor and implement your project successfully.

The plan should begin with a management summary that provides the project stakeholders with a high-level view of the project objective. It should also outline the deliverables and benefits your organization will gains from completion of the project. Note that for larger projects, some of the sections detailed below would be self-contained subsidiary plans.

Today's Top Picks for Our Readers:

Recommended by

This checklist can be used in conjunction with the associated project management plan template to help you produce your own project plan. The purpose of a project management plan is to explain how the project is going to be to managed.

In the case of smaller projects, this plan can serve as a self-contained planning document. However, in larger projects it makes more sense to create a series of subordinate plans for each functional area (scope, budget, schedule, risk, quality, human resources, etc).

Using the project plan as a parent plan that refers to these subordinate plans prevents it from becoming too lengthy and complex. The following outline provides a good foundation for a project management plan but you will need to use your own judgment about which sections to use and how much detail to go into.

Management Summary
This section should explain the business background to the project, what the project hopes to achieve and what the intended outcome will look like. This information should already exist in the business case, project charter and the preliminary scope statement.

Project Objectives
It is important that these objectives are stated in a clear and measurable way so that when the project is completed there can be no argument about whether or not it has achieved these stated objectives. Many projects 'fail' because the objectives are not measurable and the language used to describe them means different things to different stakeholders. For example, the objective 'resolve 75% of billing queries during first customer call' is clear and measurable, whereas 'improve how customer billing queries are handled' is not. The objectives must be clear enough so that the project can be measured against them once completed. Most of this information should already exist in the business case, project charter and the preliminary scope statement.

Plan Purpose
The purpose of this plan should be to describe how and when a project's objectives are to be achieved, by showing the major products, milestones, activities and resources required on the project. It should also document project team roles and responsibilities, and the governance structure of the project.

Project Deliverables
These are the products and services that the project will deliver rather than the project management deliverables (other plans and documents), which are detailed below. This information should already exist in the business case, project charter and the preliminary scope statement.

Note: For larger projects, the following sections could be subsidiary documents.

Human Resource Management (Project Roles and Responsibilities)
Identify the key project stakeholders and their duties and responsibilities. In a matrix-management environment, where some resources are not under the direct control of the project manager, this section will need to provide information on where the priority of the project falls with respect to other responsibilities of the project team members. For example, where resources allocated to the project might have other operational responsibilities that cannot be ignored, the HR plan will need to take account of this.

Communications Management
The need for good and appropriate communications between the project manager and project stakeholders is critical for the success of any project. Understanding the importance and influence of each stakeholder enables you to define the appropriate depth and frequency of communication you have with that person throughout the project.
This section defines the lines of communication and the methods to be used. In other words what should be communicated, and to whom.

This may seem unnecessary during the planning phase of a project but focusing on the importance of communication at this stage will eradicate serious problems later on that could result from too much or too little communication. The ease of sending emails and attached documents means that that there is a real risk of over-communication. This results in team members becoming snowed under with largely irrelevant emails. To avoid this, the ultimate goal of communications management is to ensure that stakeholders receive the information they need to know at the appropriate time and at the appropriate level of detail. This section should identify what they each role is responsible for communicating, how often they need to communicate, what communication tool and medium to use and any specific triggers for communication.

Scope Management
In this section you should document and collate the 'end users' requirements and gain agreement for what they expect as a final product. This plan documents the scope management approach; roles and responsibilities as they pertain to project scope; scope definition; verification and control measures; scope change control; and the project's work breakdown structure. All project communications that affect the project's scope should follow this part of the plan.

The objective of this section is to ensure that everyone involved has been thoroughly communicated with and has a comprehensive understanding of what your project means to them and the organization.

Within this section you will document and collate the 'end users' requirements and gain agreement for what they expect as a final product. The Project charter provides a broad overview to which you need to add a stakeholder register and once the scope is verified demonstrates their acceptance of the project deliverables.

From the information and data you collect in this activity you will be able to define your project scope and set stakeholder expectations. You detail the project documentation and reports that will be produced. This includes any exclusions, constraints and assumptions that have been made as part of the project. It is inevitable that projects will have or need changes made to them and how this process will be managed and controlled is outlined here.

An important part of this section is the Work Breakdown Structure (WBS) document, which shows the decomposition process you have undertaken to break the project deliverables in manageable chunks of work. The definition of each work package is kept in your WBS dictionary. Your WBS also produces the approved version of the detailed scope statement in what is commonly known as 'scope baseline'.

Schedule Management
The project schedule is the road map for how the project will be executed. Schedules are an important part of any project as they provide the project team, sponsor, and stakeholders a picture of the project's status at any given time. This section explains how the project schedule is developed and managed. It details the procedures for monitoring progress against the schedule baseline and making changes to it.

This would include the timing and format of progress meetings including who should attend. The purpose of the schedule management plan is to define the approach the project team will use in creating the project schedule. This plan also includes how the team will manage changes after the baseline schedule has been approved, including: identifying, documenting, prioritizing, approving, and publishing all schedule-related changes.

The milestones of your project are described in this section along with any known constraints. Controlling this area will be critical to the success of your project in a timely and cost effective manner.

From your WBS you will define the activities needed to complete each work package, the sequence they need to be performed in plus an estimate of resources required. The schedule that you develop will highlight your 'Critical Path' (CPM) or 'Critical Chain' (CCM) and include a description of how you will control and monitor change requests.

Cost Management
This section explains how the project's costs are going to be measured, reported and controlled. This details the procedures for: monitoring project cost, identifying who is responsible for managing them, who has the authority to approve changes to the project budget, and how cost performance is measured and reported including report formats, frequency and to whom they are presented. For example, if the project begins to incur cost overruns, at what thresholds must specific actions take place? For example, if the cost variance exceeds 15%, then the project must undergo a review to determine what actions must take place to bring the project back on track.

Quality Management
This section details the specific quality assurance and quality control measures that will be used and why these measures have been chosen. Quality should also be considered from both a product and process perspective and must always be planned into a project in order to prevent unnecessary rework and waste. Even if the organization already has a standardized approach to quality, this must be defined and communicated to all project stakeholders.

Change Management
This is a critical aspect of your project because this is where you define 'who' has the authority to approve change requests and how those change requests will be managed and approved. As more and more organizations become project based entities it is likely that you will need to liaise with a 'Change Control Board' or 'CCB' that manages, records and monitors this aspect of projects.

Risk Management
This section defines the key roles and responsibilities for risk management activities, and establishes the framework in which the project team will identify risks and develop strategies to mitigate or avoid those risks. It documents the procedures for identifying, analyzing, prioritizing, assigning and mitigating a risk. As well as those for implementing a contingency plan should a risk be realized and become an issue.

Supplier Management
This section identifies the products, services and resources that need to be acquired or purchased from outside of the project team. It will include the timeframe for each resource and the quoting and management processes attached to this procurement. It will also explain the procedures for making purchases and soliciting requests for quotes (RFQ) from service providers, and detail how the suppliers will be evaluated against the Statement of Work (SOW). It needs to make clear who has purchasing authority and at what level. For example, a team leader might have a purchase authority limit that is different from the project manager.