Your project management plan is more than just a schedule of work. Although I am guilty of using ‘plan’ and ‘Gantt chart’ interchangeably.
A project management plan is a document that sets out how you are going to do what you’re going to do. It’s a guide to how the project will be managed. And as a project manager, it provides the guardrails and guidelines for how you are going to do your job.
So what does go in the project management plan? In this article, you’ll learn about 20 things to include in a project plan. That’s a comprehensive list!
Be pragmatic though. Pick and choose what is relevant to you and the project team. If you aren’t buying anything, then don’t waste time producing a procurement plan that says as much.
Project documentation is designed to be tailored, so feel free to tailor as much as you like so your plan ends up representing the work you’ll do on your project.
1. Project definition
The project definition is something I’d definitely include in a project plan. This is a short statement saying what you are doing. It’s a quick overview of the project. Think: Executive Summary.
Mention the project goals in here, a high level nod to the project schedule and a summary of the entire project.
2. Background and context
Now you can go into bit more detail in this section. How did this project come about? What are the project objectives? What’s it going to achieve? Reference the business case and any prior documentation.
It’s always easier to reference other documents than try to reproduce them in here. You can embed them too, as an icon, so people can click to read if they want extra info.
Keep this section to a paragraph. Your document is going to be long, so there’s no point in padding it out more than you have to.
3. Execution strategy
This is the ‘how’. Talk briefly about your approach to delivery, what project life cycle you are going to follow, and the project planning process. You could mention the methodology you plan to use, whether it’s a big bang deployment or a phased rollout (and if phased, how you are going to split it).
You can also talk about the project management tool you are going to use and your approach to document management.
Tip: Mention learnings from previous projects in here. A nod to lessons learned is always a good idea, and shows that hopefully you won’t be making the same mistakes as past projects because there is a process in place for organizational knowledge sharing and transfer.
In this part of the document include or at least make reference your product breakdown structure, and Work Breakdown Structure if you have them, major deliverables, or other products. Ideally you should list everything that is in the project scope in as much detail as you can.
If you have a fully-fledged requirements document then you can always reference that, or the project scope statement.
It’s really important to talk about exclusions from scope as well. If you aren’t covering the work of the Sales team, or if you have no plans to include the Italian office, state as much.
5. High level schedule
This is always a hard part, but you should have some indication in here of the high level project schedule.
Include a list of milestones. You can pull important dates from the business case, such as delivery timescales that the exec team has set. There is normally someone who has an idea of when it should be delivered, even if they have done no planning and won’t be involved in any of the actual tasks themselves.
If you do have the detail for a project timeline, pop in an extract from your rolled-up Gantt chart. I tend to use a graphics package to make my high level schedules as I think a rolled-up version of MS Project doesn’t look that great in a document. I use Vizzlo (read my review of Vizzlo here).
You can link to your detailed project schedule if you have one at this point, but I wouldn’t put individual tasks into the project management plan, it’s not the right place for that level of detail.
6. Organization chart
A project organization chart is helpful to identify the project sponsor and key stakeholders. By now you should know who is doing what on the project, so pop them on a hierarchy chart to show the project structure.
This section shows how the different teams fit together, who is on the Project Board, how the PMO fits in, who is leading the different workstreams and so on. Make one in PowerPoint or a mind-mapping tool and then slot a picture of it into your document.
7. Roles and responsibilities
Leading on from your org chart, you should go into a bit more detail about what everyone is going to be doing. Setting roles and responsibilities clearly at the start of the project is a huge help when it comes to getting people to commit to the work.
Then you can simply reference that, maybe pulling out a few of the key roles and responsibilities to add into your plan.
You can go further and include a resource management plan that sets out how you are going to secure, onboard and work with project resources. I would say it depends on how far you have already got with getting the project team in place (because when we say ‘resources’, mostly we mean ‘human resources’). If you don’t have people in mind already, it could be worth documenting how you are going to build the team from scratch.
Tip: The roles and responsibilities section can help you identify resource requirements. If you need a role that you don’t have covered, make a plan for how to secure the right person in post to get the work done.
If you’ve never produced a RACI chart before, read my complete guide to RACI/RASCI charts. It’s easy when you know what it’s for.
Drop a summary chart into your project plan document. A complex project might need an appendix that sets out the full detail, but a summary is probably good enough for most project plans.
9. Monitor and control methods
This section of the plan sets out what you are going to use to keep the work under control. How are you going to know if you are on track for project success?
For example, your project plan template might include your approach to status reporting, whether you are going to use Earned Value or not, what software you are going to use to manage the project budget and schedule and so on.
10. Risk management plan
Here’s where you set out how you are going to manage risk. Think about the tolerances you are prepared to work with, what risk profile your sponsor feels most comfortable with and the strategies that will most likely apply to your risks.
Document how often you will review risks, what can be dealt with by the team and what should be escalated. If your company has a standard risk management process, refer to that here.
Tip: Putting risks in categories can help you identify more of them, so list your categories in the risk management plan. For example, schedule risks, technical risk, scope risk.
11. Risk log
Part of managing risk is having your risks documented somewhere. You don’t want to list every risk in the project plan, but it is worth including the main ones that you know about right now. Then reference where all the other risks will be stored and managed.
If you’ve got a business case or project charter, you can probably pull the main project risks from there.
Note: this section is optional as it doesn’t 100% marry up to my ideal situation of using the plan as a way to describe how the project is going to be managed. This section is ‘doing’ the project management, instead of ‘planning the project management, so if it feels like it’s an extra you can do without, ditch it.
You need to include an indication of the approved project budget. You won’t want to mention much more than that here, but if there are any constraints about what you can spend in what tax year or how to get money authorized, then note them in the plan.
You probably won’t need to include indirect costs (costs related to having staff who are working on the project) but check with your Finance team as there might be some cases where some costs do get charged to the project.
13. Estimating assumptions and methods
Record how you are going to create your estimates for the project (time and money) and note any assumptions.
This is really important because if those assumptions are later proved to be incorrect you will find that the basis of estimates you’ve been working to is wrong – with all the catastrophic effect that will have on your schedule.
If you have company-approved estimating techniques, note which ones you are going to use.
14. Project communications plan
Who are you communicating to? When? In what way? A full communication plan is probably several pages and if you have another document that covers everything off just reference that one here.
Otherwise include the details about how you are going to manage communications on your project. Typically, that would mean:
- Who will receive the communication
- What communication method will be used
- What frequency comms will be issued
- What the process for creation, approval and distribution will be.
Tip: Include external stakeholders in your comms planning.
15. Reporting schedule
During project execution, you’ll need to share updates with key stakeholders and the rest of the team. How often are you going to report and to whom? Who needs to know about project progress and therefore needs to receive the reports?
This section could be moved to be a sub-set of your comms plan if you are trying to save space but I think it’s worth calling out reporting separately so that your project stakeholders know what to expect when.
Tip: Look at when the project milestones fall and try to get status updates issued around them, in addition to the regular recurring reporting you produce.
16. Procurement plan
If you plan to buy something as part of the project, this section is for you to explain how you are going to go about it. It could be simply a line that says you’ll follow standard company procedures.
Larger projects, or those that require many purchases, could go into detail about the way you will source vendors, choose a vendor and manage the contract.
17. Health & safety plan
I don’t think I have ever worked on a project that had a health and safety plan but if you’re in any kind of industry where that’s important then you should include it.
Construction, engineering, environmental projects, even those that involve workers going out to site by themselves or working at night alone should have some kind of formal approach for keeping the team safe.
There’s more information here about what project managers should know about health and safety.
18. Information management plan and configuration management plan
Information management plans talk about how you are going to create, share and store project information.
You simply need a statement or two in here. Also talk about how you are going to control documentation and other project deliverables so that it’s easy to see which is the most current version. Reference your project management software and collaboration tools, to set the expectation for the team about what they will be required to use.
Configuration management can be much more complicated than that if you are checking in and out code, for example, but in that case you’ll probably have team or company standards for doing the work that you can reference here.
19. Quality management plan
A successful project is one that delivers a quality output — however you decide to define quality. In this section of the plan, note down your approach to managing project quality on the project.
If you have a full quality management plan separately, then you can reference it here. Otherwise talk about what your quality standards are and how you intend to hit them.
Need a template? There’s one here.
If you have a schedule for project quality audits or other quality checkpoints, write the dates in the plan. You can add more detail as you go through the planning phases and work out how to best manage quality at each stage.
Alternatively, read this about why I don’t use quality plans.
20. Change control procedure
Finally, note the procedure that you’ll use for managing changes. This could be as simple as “This project will follow the standard process for change control.” If your business already has a
Changes happen for lots of reasons, from poor planning to project delays or a stakeholder changing their mind. The whole team should know what to do when that happens, which is why this section is really valuable.
With everything here, only bother to do what you need. “Plan” does not have to mean pages and pages. A longer document does not make you look more clever or organized. It just raises the likelihood that no one will read it except you.
Write what you need to and crack on with doing the next part of the job!
In this article, you learned the essential elements for a detailed project plan, and how it can help you manage a project more successfully. Need more help? Get a project management plan template.