20 THINGS FOR YOUR PROJECT MANAGEMENT PLAN [WITH 3 FREE TEMPLATES] by Elizabeth Harrin
Referred Link - http://www.girlsguidetopm.com/2017/04/20-things-for-your-project-management-plan-with-3-free-templates/
1. Project Definition
This is a short statement saying what you are doing. It’s a quick overview of the project. Think: Executive Summary.
2. Background and Context
Now you can go into bit more detail. How did this project come about? 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. 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).
4. Scope
In this part of the document include or at least make reference your product breakdown structure, and Work Breakdown Structure if you have them, key deliverables, or other products. Ideally you should list everything that is in scope in as much detail as you can. If you have a fully-fledged requirements document then you can always reference that.
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 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, 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).
6. Organisation Chart
A project organisation chart is helpful. By now you should know who is doing what on the project, so pop them on a hierarchy chart.
This 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.
Get a free Roles & Responsibilities template here. Then you can simply reference that, maybe pulling out a few of the key roles and responsibilities to add into your plan.
8. RACI
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.
9. Monitor and Control Methods
This sets out what you are going to use to keep the project under control. For example, you 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 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.
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.
12. Budget
You need to include an indication of the approved 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 authorised, then note them in the plan.
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. Communications Plan
Who are you communicating to? When? In what way? A full comms 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.
Get a project communications milestone calendar here. It’s not a full comms plan (I have a template that I’m working on to share with you later in the year) but it’s a high-level version that works for small projects or parts of projects where you need to map your communications against dates.
15. Reporting Schedule
A longer document does not make you look more clever or organised. It just raises the likelihood that no one will read it except you.
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. But you 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.
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
Note how you are going to manage 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.
If you have a schedule for quality audits or other quality checkpoints, write the dates in the plan.
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 change management procedure then just reference that. Don’t bother to copy it all out.
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 organised. It just raises the likelihood that no one will read it except you.
Posts
0 comments