Chapter 11

Templates for Planning

In This Chapter

A template for the Project Charter

A template for the PMP – the Project Management Plan

Templates for major plans within the PMP

This chapter has a number of templates aimed at saving you time and effort as you plan your project. As with all other templates in this book, you may need to adapt them a bitto fit the exact needs of your organisation and then, if necessary, your current project. If you’re new to projects and not completely sure what you need, it’s best to leave most of the headings in and do a bit too much rather than a bit too little when it comes to the Project Charter and the Project Management Plan (PMP). You want to be sure that you’ve thought everything through, and it shouldn’t take that long to do anyway.

This chapter contains templates for the Project Charter and Project Management Plan which in turn contain other things. If you’re unfamiliar with the Charter and PMP, have a look at Chapter 2. In short, though, they are the two key project-level planning documents that you produce in the first stage of the project, the Planning Stage. The Charter contains strategic elements such as the scope (what the project covers and also what it doesn’t) while the PMP contains the more tactical elements such as the Project Plan and the Risk Plan.

Header Block

For each document you’ll need a header block with standard information. This first section of the chapter lists the sort of information you should include. The individual templates will then just have a section called ‘header block’ to save repeating the same stuff over and over.

Try to keep the header block simple. Instead of a simple header block, some templates that are available (both free and paid for) have a big cover page for every document. This page has all sorts of detailed information but nearly always you simply don’t need all of that.

• Document name: Such as ‘Project Charter’.
• Project name: A short project name.
• Version number: This is very important. You need this number so that you know whether a particular copy is the latest one or not.
• Date: The date on which this document, or version of it, was created.
• Author: The person who created the document and who can be asked about it. For many documents the author will be the Project Manager.

The Project Charter

This important document sets down the strategic aspects of the project, including what it is and the justification for it. The Charter will be checked by the Project Steering Group (PSG) at the start of the project to ensure that the project is viable, but then you keep it up-to-date throughout the project. It must be checked again by the PSG at every Stage Gate to be sure that the project continues to be viable.

• Header block: Project and document information.
• Background and summary: Very briefly explain the background to the project and how it came about (such as an HQ instruction or the need to solve an operational problem) and then describe the project.
• Scope statement: Explain here exactly what the project will cover. Unless your project is very simple, it’s best to use some subsections.
  • Project product: What the project will deliver at the end. It’s surprising that people can use similar words but still have a misunderstanding of what the project will actually produce.
  • Areas included: What the project will cover. You might define that by geography such as regions within your organisation, or functions.
  • Areas excluded: What the project won’t cover. The exclusions aren’t the whole world outside the project, but rather things that could be misunderstood and where somebody might assume that they are included. Although the project is a perfectly good one, that person will be disappointed when the project finally delivers. Making things clear at the beginning is powerful in managing expectations.

It pays to include the section on ‘Project Product’. It won’t take long to write and it adds great clarity. In the National Health Service in the UK, a major project document similar to the Charter was approved by senior managers and signed off. Parts of the document described how the project would investigate a problem, design new procedures and stop there. In other places the text referred to implementing the procedures and the wording at those points indicated that the implementation was part of the project. So what project had the managers agreed to when they signed the document?

• Requirements: A list of requirements for the project, such as from users, senior managers and perhaps including legal requirements, and then a note against each one of where that requirement came from.
• Objectives: Set down here what the project is trying to achieve. It’s important that everyone is clear on the objectives and agrees with them. Otherwise you may have people thinking different things and bringing the project under pressure later. For example, the Production Manager thinks that the new production line project is about increasing quality and product reliability, even if the cost of manufacture goes up slightly. However the Finance Manager thinks it is about reducing the production costs with new, low-maintenance machines and making more money, even if quality is reduced. We’re in for problems then when it comes to specifying and ordering the new production line equipment later in the project.
• Business Case: State the justification for running the project, along with details of the business benefits. Although part of the Project Charter, the Business Case is a major document and you’ll find a separate template for it in this chapter.
• Organisation: Specify the roles and responsibilities. You can have a text list but it’s usually best as a chart showing who is doing what, such as who the Sponsor and Project Manager are. You’ll find checklists on roles in Chapter 6.
• Business Impact Statement: This item is high profile in the PRIME project method, but I’ve yet to see it anywhere near so clearly in any other approach. It’s important information, though, and here you say how the project will impact business areas outside the immediate area where the project is taking place. That impact might be in other departments which must change their procedures to fit, or perhaps with central computer systems where modifications will be needed to some databases. If no external impact occurs, you just say so. PRIME says that the Sponsor must personally sign this section to confirm the extent of the business impact. It’s an important element of the strategic view embodied in the Charter.
• Constraints and acceptance criteria: In this section put in any constraints that will affect the project. That might be things like a fixed delivery date, or a limit on funding or constraints on which specialist staff can be used. Then specify the acceptance criteria for the project. The reason that both of these items are in a single section is that they are often related. So an acceptance criterion is that the project product must be ready to hand over on or before 1 December, but that fixed deadline is also a constraint on the project. Failing to reach one or more of the acceptance criteria doesn’t necessarily mean that the project will be refused, but it won’t be seen as an outright success.
• Assumptions: Record in this section any assumptions affecting the project and any other elements of the Charter. For example, in setting a particular delivery deadline in the ‘Constraints and acceptance criteria’ section, that may assume that other projects ahead of this one will finish no more than four weeks late. If those projects are late finishing and don’t release the specialist project staff until six weeks after they were supposed to start work on this one, everyone will then understand why you were late, because you stated the assumption clearly up front.
• Acceptance arrangements: How the project team will hand over the project product(s) at the end of the project. Don’t ignore this section because it won’t take long to agree and record, but could save huge confusion later. You may also want to record who is responsible within the organisation for taking delivery of the product(s). The acceptance may be fairly informal, with just verbal agreement, or might be legally binding, such as with the handover of a new building from the developers to the new owners.

Business Case

The Business Case forms part of the Project Charter and is a seriously important document. It’s the justification for the project. The contents are wider in scope than you might expect, but that’s because the Business Case may sometimes be seen on its own, such as by senior organisational managers who want to know what the project is all about and why you are doing it, or perhaps because their authority is needed for funding it. If you’re sure that the Business Case will only ever be seen as part of the Charter and alongside the PMP, then you can take out information that is in other places, such as in the Project Plan (time and cost).

You must keep the Business Case up-to-date throughout the project. It will be used by the Project Steering Group at Stage Gates (as mentioned earlier in the chapter) to ensure that the project is still viable, but also when dealing with change or problems during the stages. Some changes, for example, may have a significant impact on the Business Case such as to increase benefits.

• Header block: Project and document information.
• Project summary: A short description of the project so someone can quickly get to grips with what the project is all about.
• Justification: Why the project should be run.
• Benefits: A list of benefits and for each quantifiable benefit, how it will be measured and when. Have a look at Chapter 5 for a checklist on the three different types of benefit.
• Cost: The latest estimated cost of the project, including staff costs. You should normally separate out capital costs – which are one-off expenses – from revenue costs, which are ongoing running costs in the organisation such as for project staff. And don’t leave out the staff costs; they’re a genuine project expense and probably quite a big one.
• Time: The latest estimated time that the project will take to deliver.
• Risk: Detail of the major risks involved in the project. It’s important for any senior managers reading the Business Case to see what risk the organisation is exposed to in order to achieve the project result, such as business benefits.

The Project Management Plan

The Project Management Plan (PMP) is primarily the Project Manager’s plan to say how he will control the project. However the Project Steering Group (PSG) has an interest too, since the PSG members, with their ‘project governance’ hats on, must make sure that the project will be properly managed and controlled. It can be really productive for the Project Manager to work in ‘workshop mode’ with the members of the Steering Group to at least sketch out the main parts of the PMP and so incorporate the right PSG controls from the start. That workshop will also pay off for the PSG since the members will have a much better feel for the project which will help them as it progresses.

The PMP is a bundle of other plans and you can think of it as being a bit like a folder. As with the Project Charter, you must keep the PMP up-to-date throughout the project.

• Header block: Add the project and document information.
• Project Plan: Put together the product plans, activity plans, resource plan and budget. You can find a number of checklists to help you in Chapter 8, including the ‘Four Dogs’ to help you check that the plan is achievable.
• Procurement Plan: In projects that involve a lot of procurement, use this plan to record the details of what has to be bought and when. This plan should also include the elements involved in the procurement and the timing. For example, major purchases may have to go through your Procurement Department and there is a six week lead time. You’ll find a separate template to help where your project justifies having a Procurement Plan.
• Quality Plan: Specify the level of quality you need to deliver in this project, and exactly how you are going to achieve it. The plan also sets down the checking mechanisms such as Quality Audit. There’s a separate template for the Quality Plan later in this chapter.
• Risk Plan: State how you are going to manage risk in the project. Don’t confuse this with information on individual risks; that’s all in the Risk Log. Again you’ll find a separate template in this chapter for the Risk Plan.
• Stakeholder Plan: Include information on how you will handle different groups of stakeholders. There’s a separate template in this chapter for the Stakeholder Plan too.
• Communications Plan: Specify what communications will take place and how they will be carried out. Your objective here is to achieve good communications and to avoid over-communication where people are bombarded with information that they don’t want. You may be very aware of the over-communication problem as you plough through all those unwanted emails in your in-box. In Chapter 8 you’ll find a checklist to help you think this through.
• Version control: You have to keep track of versions. That applies to management products such as the Risk Plan as well as to technical products such as the floor plan for a new building or the system specification document. Your version control may be very simple, with just a central record of what the latest version is for each document, or something much more sophisticated. As with so much else in project management, the degree of sophistication you go to will depend on the needs of the project.
• Project controls: This is the section where you set down controls that aren’t in other plans in the PMP. For example, situations may arise where the Project Manager must refer something to the PMP immediately, even if it doesn’t affect the time and cost of running the project.

Look carefully at what version control you need, because you’ll just about always need it, even in very small projects and even if it’s just the management products. Figure 11-1 illustrates two management documents, and they’re different. Which one are we supposed to be using then? You’ll find a template for a Version Record in Chapter 16, Templates for Control.

You may hear version control referred to as versioning and, more confusingly if you’re not an engineer or IT specialist, Configuration Management. Strictly speaking Configuration Management is a bit more than just version control, but that isn’t a concern for the vast majority of projects.

Procurement Plan

Not all projects need a Procurement Plan. However, if you have a lot of procurement involving a lot of steps, such as with setting up contracts, the plan can be really helpful. The Procurement Plan brings together information from other places, such as the Project Plan, Stage Plans and budget. It gives you a clear view of what procurement actions are to be carried out and when, and when money will be spent.

The simplest way of structuring the plan is to set down the procurements one at a time with a block of repeating information for each procurement. Have the normal project header block first, then the individual procurement information blocks.

• Item or service: A brief description of what is to be bought.
  • Contract/internal procurement: Say whether a contract is to be set up as part of the project, or whether the item is to be procured through your organisation’s normal purchase procedure and doesn’t need a contract.
  • Cost: Insert here the total cost of the procurement and when the money will be committed and then spent. Or, if the cost is to be split up with something like staged payments, put in the detail of that split as well as the total.
  • Date required: Specify the date when the item or service will be needed in the project.
  • Procurement steps: List the steps in the procurement, with the target date for each. For example, Invitation to Tender (ITT), shortlisting, presentations and then award of contract. Or it might be a single step for an internal procurement which is putting in a procurement form to the Procurement Department seven weeks before the item is needed.
  • Authority: Say whether any particular authority is needed to make the procurement. For example a very large purchase may have to be approved by the Finance Director.
• Item or service: The next block of information for the next procurement. Continue for as many blocks as you have procurements in the project.

You’ll usually commit money before you spend it so the procurement steps can be very significant for your project budget. When you place an order, the money to cover that procurement is committed and can’t be used for anything else. However the invoice won’t usually be sent in by the supplier until after an item or service has been delivered, and the bill will be paid about four weeks after that. The timing of the steps can be important. You may place an order in one financial year, but the actual payment is made in the next one. In some cases your finance people will want to put money from the first year on hold so that the purchase falls into that year’s accounts, even if the money is spent in the following year. Clear? Well if not, then ask your finance guys to explain how they record finances and about accruals.

Quality Plan

You won’t deliver the required project quality by accident. It needs careful thought and then a considered plan on how you will achieve it. ‘Considered’ doesn’t mean long and complicated though. Your Quality Plan may be short and straightforward, and actually it’s an advantage if it is.

The Quality Plan forms part of the PMP. To help you get the plan right, you’ll find a checklist in Chapter 8.

• Header block: Project and document information.
• Quality level: The overall level of quality you need to achieve in this project. You might have an organisational scale here or you may write in a description of the quality level, such as ‘safety-critical’ or ‘low-quality’.
• Standards: List here any standards with which you must comply. You may immediately think of external standards such as electrical, data protection and safety. However don’t forget any relevant internal standards required by your organisation.
• Testing: A generic description of the sort of tests and checks that you will do in the project to ensure that the quality is right. It’s not the detail of the individual tests on products; that goes onto your Product Definitions. For example, you may say that you will use informal, ‘peer level’ review to check out some documents, but major designs will go through full formal review.
• Quality records: If you need to, specify the nature and content of quality documentation, such as test reports.
• Audit: A crucial section where you set down how you will check that the required testing and checking has actually been done, not merely talked about and then quietly forgotten.

Specifying an excessive quality level isn’t a good thing. It will drive up project overheads unnecessarily both in money and staff effort. Good project quality is appropriate project quality. Remarkably few of your projects will need to achieve a ‘safety of life’ level, unless your career is building air traffic control systems or nuclear reactors, that is.

Risk Plan

As with the Quality Plan not covering individual tests, the Risk Plan isn’t there to say how you will manage individual risks, but rather how you are going to control risk across the whole project.

• Header block: Project and document information.
• Overall risk levels: An overview of the nature of the risk in the project and if it is high risk, medium or low risk. In your description specify the level for the positive as well as the negative risk. The project may be rich in ‘opportunities’ (upside, positive risk) to increase benefits for example.
• Risk measures: Specify the risk measures for impact, probability and proximity. Depending on the size of your organisation, a $1 million negative risk exposure may be threatening to your whole organisation, a minor inconvenience, or something in between. For proximity (how soon the risk can occur) you might specify project stages, project week numbers or calendar dates.
• Risk procedures: How people in the project will report new risks, changes to risks already identified and risks actually happening. Also explain how the project risk management will interface with organisational risk management and the procedures for passing information between the two.
• Risk review: the pattern for reviewing risks in the project to look for changes and to see whether the risk management actions are working. For example, you might review all risks at the end of each Delivery Stage, or the very high- and high-probability risks every two weeks and the rest every six weeks.
• Risk documentation: If you need it, the format and content of risk documentation. Don’t bother with this section if you’re only going to specify the content of the Risk Log because that’s self-evident from the Risk Log itself.

Keep the risk procedures very simple and easy to understand. Don’t have too many people in the reporting chain either. When advising clients on risk management I always suggest a one-bounce approach. That means that there is never more than one person between the person making the report and the one empowered to take action. If there’s more than one person, there are two dangers. First, it will take too long for the information to reach the person who needs to take action. Second, that information dilution will take place where a ‘serious crisis’ is transformed into ‘a minor inconvenience’ by the time it has gone through six levels.

Stakeholder Plan

Stakeholders can often make or break a project. If you have a lot of stakeholders then you can set up a Stakeholder Log. If the management of those stakeholders will be a significant part of your project, which often it is, you can then develop a Stakeholder Plan in which you group stakeholders together and specify the management action that you’ll need during the project. Then make sure that you build the actions into your Project and Stage Plans.

• Header block: Project and document information.
• Summary: In this section explain the significance and pattern of stakeholders in the project. For example that most of the management action will be needed at the front end of the project to consult stakeholders, or perhaps that the most significant ones are actually outside the organisation, such as shareholders or customers.
• Stakeholder group: Replace the title ‘Stakeholder group’ with the actual name of the group, such as ‘voluntary organisations’ in a hospital project or ‘major donors’ in a charity.
  • Description: In this section describe the characteristics of the group. In other words, why have you grouped these stakeholders together?
  • Stakeholders: list the stakeholders who are in the group. Cross check with your Stakeholder Log that you have got everyone in a group somewhere, even if one or two ‘groups’ are just an individual stakeholder who needs individual management.
  • Specific project concerns: List the specific interests that the group has in the project. You can also include the overall stance of the group as to whether it is in favour of the project or opposed to it. Note the warning below though.
  • Management actions: List the actions needed to manage the stakeholder group, each with a date (or frequency if it is ongoing) and say who is responsible for taking the action.
• Stakeholder group: The next stakeholder group with the subsections as before.

Be careful how you record the stance of a stakeholder group. For example if you note that a group is opposed to the project and you use derogatory terms, that’s not only unprofessional but you’ll also increase the opposition if those stakeholders then get to know what you’ve written about them.

Communication Plan

The Communication Plan records those communications that you expect to take place within the project, to come in from outside and be sent out of the project. For each, you record how the communication will take place, such as by email, meeting or phone call.

The Communications Plan forms part of the PMP. When you have completed it, make sure that the related activity is reflected in your Project and Stage Plans. For example, don’t forget to plan for the Project Manager’s time to produce a progress report each month.

• Header block: Project and document information.
• Communication: A short name for the communication such as ‘Stage Progress Report’ or ‘Stakeholder briefing’. Then include further information in subsections.
  • Created by: Who generates the communication, which could be someone outside the project if the communication is inbound.
  • Received by: Who receives the communication. It may be a single person or a group; a distribution list.
  • Frequency: The frequency with which the communication is made. It could be a progress report sent out monthly, or an event-driven communication, such as when a team member notices and reports a new risk.
  • Media: The way in which the communication takes place, such as by email or written report.
  • Content and format: What the communication will actually contain and any requirement for the way that it is formatted. For example, a report may contain financial information on spending, and you should present that financial information in the form of a table. In many cases it helps to attach an example so people can immediately see what you mean rather than struggle while they try to interpret a text description.
• Communication: The next communication with subsections.

If you have a lot of expected communications in the project, you may find it easier to break the plan into three sections to cover inbound communications, internal project communications and then outbound communications. The Word template available to accompany this book has got those sections on it, so just remove them if your comms will be simpler and you don’t need the sections.