A Project Management Plan explains how to manage the project. Depending on the size of the project, the Project Management Plan can serve as the main planning document for the project (smaller projects), or it can serve as a parent plan with a series of subordinate plans (larger projects). The following outline provides a good base for a Project Management Plan.
1. Project Description
Explain what the project is, and how it will be accomplished. Explain the ultimate intended outcome of the project. This should serve as a brief introduction. Provide some background about the history of how the project got to this point.
Note: Pull some of the Project Description information from the Project Charter or Preliminary Project Scope Statement if available.
2. Project Objectives
Provide clear, actionable and measurable objectives of the project. The objectives should be clear enough so that the project can be measured against the objectives once completed. The ultimate success of a project is whether the project achieved its stated objectives. Take time to clearly document the objectives here.
An example of an objective is:
- The system/product/service will cut response times in half, thus allowing the organization to process twice as many tickets.
Note: Pull some of the Project Description information from the Project Charter or Preliminary Project Scope Statement if available.
3. Project Management Plan Purpose
State the purpose of this Plan. The purpose of the plan should be to describe how the project is going to be managed. Specifically, this Plan should provide guidance to the project team on how to execute the project against the 9 knowledge areas identified within the Project Management Body of Knowledge (PMBOK). This Plan should also identify the key project milestones and document project team roles and responsibilities, and the governance structure of the project (who is what decisions).
4. Project Deliverables
Identify the products and services that the project will deliver. The intent of this section is to list the product or system deliverables (e.g., an online shopping site), and not the project management deliverables (e.g., Requirements Management Plan)
An example of a product deliverable is:
- An online store with a shopping cart and credit card purchasing capability.
Note: Pull some of the Project Description information from the Project Charter or Preliminary Project Scope Statement if available.
5. Project Milestones
Identify the project milestones.
| Milestone Date | Milestone Name | Milestone Description |
| [Jan 1] | System Requirements Complete | System requirements version 1.0 are approved and baselined so that the project can begin design and development. |
| [June 1] | Development Complete | Software development is complete and ready for integration testing |
| [Dec 1] | Deployed to Production | System passes integration and end-user acceptance testing and is deployed to production |
Note: Pull some of the Project Description information from the Project Charter or Preliminary Project Scope Statement if available.
6. Project Roles and Responsibilities
Identify the key project stakeholders here and their responsibilities on the project.
| Role | Responsibilities |
| Project Sponsor | Sponsor of the project. Provides the budget and funding for the project. Sets the strategic goals and objectives. |
| Project Manager | Responsible for the overall success of the project. Delivers the product with an acceptable level of quality, on budget and on time. Responsible for the project team, the project schedule and maintaining the project scope. Responsible for providing status report to the project sponsor periodically and escalating issues to the project sponsor and program manager as needed. |
| Project Risk Lead | … |
| Project Schedule Lead | … |
| Project Testing Lead | … |
| Project Quality Lead | … |
| … |
7. Project Scope Management
Describe the process for managing requirements. Specifically, describe how requirements are baselined and maintained. Describe how decisions are made to accept modifications to the project scope.
Note: For larger projects, the Project Scope Management section could be a separate subsidiary Plan document. For smaller projects, this section could serve as the main documentation for how requirements are managed and project scope is maintained.
8. Project Time Management
Explain how the project schedule is developed and managed. Identify the procedures for monitoring progress against the schedule baseline and making changes to it. For example, if there are weekly meetings to monitor progress against the project schedule, provide that information here. Identify who must attend and what decisions can be made in the meeting. Explain the project schedule format. Identify specific tools used to develop and maintain the project schedule.
Note: For larger projects, the Project Time Management section could be a separate subsidiary Plan document. For smaller projects, this section could serve as the main documentation for how the schedule is managed.
9. Project Cost Management
Explain how the project cost is developed and managed. Identify the procedures for monitoring project cost. Identify who has the authority to make spending decisions. Identify who has authority to change funding for the project. Define the procedures for requesting additional funding. Explain specific thresholds for cost monitoring and control. 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 10%, then the project must undergo a Program review with the project sponsor and the project manager to determine what actions must take place to bring the project back into alignment.
Note: For larger projects, the Project Cost Management section could be a separate subsidiary Plan document. For smaller projects, this section could serve as the main documentation for how project cost is monitored and project budget (funding) is allocated or modified.
10.Project Quality Management
Explain how quality will be measured on the project in order to ensure that the project deliverables meet a minimum level of quality. Explain the specific measures that will be used and why the measures were selected. The collected measures should provide information on whether the project is meeting its stated objectives. The measures should focus on whether the project is delivering the defined requirements at an acceptable level of quality to the customer. For example, if the project is intended to improve efficiency of order fulfillment by 50%, then the project should track the number of orders filled. Also collect baseline measures at the start of the project for all quality measures that will be tracked. Additionally, if the project wants to improve the online user shopping experience, then the online shoppers should be polled before and after the changes to see if the feedback has improved. (Tip: When conducting a survey of customers, you can quantify the feedback by using a Likert-scale questionnaire).
Define the quality baseline measures here:
| Quality Measure | Quality Measure Goal | Baseline |
| Web Site Response Time | At least 6 second average response time at peak load | Average Response time is 13.5 seconds at peak load |
| Errors | Less than 1% response page errors | 3 percent page errors due to load issues |
| Customer resolution | Customer issues resolved 50% faster | Number of customer issues due to load issues is high. Expect that as the load errors decrease, customer issues will decrease – thus allowing customer service to respond to issues faster |
| Deploy Product | Deployment without production downtime | N/A |
Note: For larger projects, the Project Quality Management section could be a separate subsidiary Plan document. For smaller projects, this section could serve as the main documentation for how project quality is measured.
11.Project Human Resource Management
Explain how resources will be applied to the project. Identify resources here for small projects. For larger projects, explain the process for ensuring that the project maintains 100% resource allocation, meaning that there are no activities that should be started but are waiting to be resourced. In a matrixed project, where the resources are provided by authority from external organizations or divisions, provide information on who provides the authority. Provide information on where the priority of the project falls with respect to other responsibilities of the project team members. For example, resources allocated to a project might have other operational responsibilities that cannot be put on hold. In this situation, the project needs to be able to have a strategy for how to maintain the momentum of the project if key resources have to move off the project for a period of time. In such a scenario, a possible strategy might be to ensure that every activity has a backup resource.
Include a resource calendar, if possible, to show the key roles and when they will be needed.
Note: For larger projects, the Project Human Resource Management section could be a separate subsidiary Plan document. For smaller projects, this section could serve as the main documentation for how project resources are managed.
12.Project Risk Management
Identify the process by which risks will be managed. A detailed and well-defined risk management process is critical to project success – specifically on larger projects. Document the procedures for identifying, analyzing, prioritizing, assigning and mitigating a risk. Identify the procedures for implementing a contingency plan should a risk be realized and become an issue. Identify the tools used to maintain the Risk Ledger. Define key roles and responsibilities for risk management activities. Define the escalation procedures for risks. Not all risks are managed at the same level. Think about how a risk would escalate within the project and even beyond the project to a higher level of authority. What types of risks would go above the project to the program or organization level? And who would be responsible for managing the risk? Document how to write risks. For examples on how to write a risk statement, visit http://www.pmdocuments.com/category/risk-management/
13.Project Communications Management
Communications management is another key component to project success. Define the lines of communication and the methods of communication to be used. For example, if an issue is identified (meaning that something is currently having a negative impact on the project), define how the risk should be communicated, and to whom. Communications planning requires some foresight and careful planning. Imagine if everyone was responsible to communicate everything. It would make for a challenging web of communication patterns. Often, the results of an incomplete communications strategy manifest itself as excessive meetings attended by the same people with repeated topics. 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.
Identify roles and responsibilities with respect to communications activities. 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. Also identify who should receive communications and how often. For example, the project sponsor would probably like to receive periodic status updates on the project. This information should be included here.
Note: For larger projects, the Project Communications Management section could be a separate subsidiary Plan document. For smaller projects, this section could serve as the main documentation for how project communications is managed.
14.Project Procurement Management
Explain the procurement strategy here. Explain the procedures for making purchases and soliciting requests for quotes (RFQ) from service providers. Explain how the RFQ respondents will be evaluated against the Statement of Work (SOW).
Explain the strategy for purchases, specifically on longer term projects. For example, if a project takes three years to launch the final product, then ensure that the final production hardware purchase is made in year three and not year one. This will ensure that the latest technology is obtained. A good example would be servers. Purchasing production servers for a project that will launch in three years would be an inefficient use of the first year funds and would not take advantage of year three technology.
Identify who has purchasing authority. If there are different levels of purchasing authority, identify it here. For example, the network administrator might have a budget and purchase authority limit that is different from the program manager.
Note: For larger projects, the Project Procurement Management section could be a separate subsidiary Plan document. For smaller projects, this section could serve as the main documentation for how project procurement is managed.
[download the Project Management Plan Template from http://www.pmdocuments.com]
