Projects are often complicated, and this complication will get out of control if you don’t have a project management plan. As a project manager, you need to be sure you and your team know what they are doing in the project. The team needs a clear set of guidelines on what the project is, how to do it, when it is due and how much you have available to spend. All of this (and more) should be in your project management plan.
Table of Contents
Problem: Your Team Doesn’t Know What to Do
Your project is undefined, your project team doesn’t know what to do, when it is due, how to do it, and they don’t know where to find and store documents. Your project is a mess.
You don’t have a plan on how your project is supposed to be done. Or if you do have a plan, it is either not good enough, not used properly, or maybe your team doesn’t even know about it or cannot find it.
Without a good plan your project might fail. It will cost more, run over schedule, and probably lead to the end of the world (ok, probably not, but don’t forget that butterfly effect).
Here is a good article on why a project management plan is important and how to write one (in case you want more information than from me) “How to Write a Project Plan”.
Solution: Use a Good Project Management Plan
The solution to a messy project is simple. Write and use a good Project Management Plan.
A good project management plan should tell the reader enough about the project that they can join the team (or even take over the project) without having to ask lots of questions.
Some of the links on this website may be affiliate links to products I use, have tested or am familiar with. I may receive a commission if you click on some of those links and make a purchase. This is at no additional cost to you.
It should be concise and easy to read, but should still have enough detail that it covers everything needed to work on or run the project, or link to relevant documents if necessary.
I believe your project management plan should include at least the following:Some of the details of these could be in a document such as “Project Procedures”, which you could link to after the summary point.
Very Important Items:
- Official title of the project
- Your internal system titles of the project (e.g. some finance systems need to shorten the name of the project, or just list it by a project number). People need this title to be able to find it.
- Project number, code, or similar used to refer to the project
- Project Manager name
- Client name (company and main client contact)
- Brief summary of the project, this might include:
- Problem being solved
- Objective
- Short description of the project scope (like an elevator pitch, something that you use to describe the project to someone who knows nothing about it).
- Links to any predecessor documents (such as a business case, client scope or RFT document).
- Funding summary (budget, which program or department it belongs to, whether it is internal or client funded etc).
- List of scope items (with links to details on these)
- Important due dates or milestones
- Link to the project schedule (and possibly a high level gantt chart included in this plan).
- Key contacts (including roles, names, email and phone)
- Client
- Internal staff, including project manager, project director, lead roles
- Contractor or consultants (company names, main contact names and details)
- Document storage locations (i.e. links to project folders or similar)
- Cost codes for booking time
- Main risks
- Main tools the project will use (if different from your standard company systems).
As I noted above, I also think it is a good idea to link to a project procedures document, which might cover project specific details of how to run the project day to day (“how to” documents).
Other Items to possibly include (if the project size or complexity warrants this):
Some of these could be a brief description with a link to your company’s detailed standard procedure document.
- Review process (such as gates or phases)
- Review process members
- Roles and responsibilities
- An organisation chart
- Work Breakdown Structure (WBS)
- Assurance requirements, such as regulator requirements, check points, peer review etc
- Stakeholders
- Inclusions and exclusions of the scope
- Procurement requirements
- Procurement management
- Commissioning and transition (how the project will be completed and handed over to the client or other business unit)
- Cost breakdown (estimates, phase or stage breakdown, possibly links to the detailed cost estimates).
- Cost management
- Schedule details
- Schedule management
- Project controls
- Risks and Issues
- Risk management
- Resources
- Resource management
- IT requirements
- Quality Management process
- Variation management
- Health and Safety
- Environmental impact process
- Communication management
- Change management
- Lessons learnt
- Reporting management / schedule
Project Summary Page
I also like to make a one to two page project summary page (short project management plan) for my team, covering the day to day basics that they need. This is the kind of thing that project team members need to look at regularly. This is unfortunately sometimes necessary because some companies have a standard project management plan template that requires the inclusion of so much extraneous information, policies and procedures that it loses most of its day to day value.
A Project Summary Page might include:
- Project name
- Key contacts
- Project Code
- Time booking codes
- Schedule milestones
- Short scope summary
- Important meeting dates
- Where to work on and store documents
You might even split this into two parts. One page that is the same for everyone, and one page specific to that person (such as a project role brief). The role brief would add information specific to that person such as their project title, who they report to, key responsibilities etc.
Lesson: You Need a Project Management Plan
A Project Management Plan is one of the most important documents in any project. Every project should have one. Even a short plan is better than no plan.
Ensure that it is easy to read, accurate, and that it can be used to manage the project with little to no other information. I like to make it such that someone could successfully take over the project if I suddenly left without doing a hand over.
