This step adds text to explain the plan.
A plan should not be simply a diagram, Gantt chart or a tabular list of products and target dates. Plans should have a narrative section. Suggested headings for the narrative are:
• Plan description. • Quality plan. • Plan assumptions. • Plan prerequisites. • External dependencies. • Risks. • Tolerances. • Reporting. How?
• Agree tolerance levels for the plan.
• Document what the plan covers, the approach to the work and the checking of its quality.
• Document any assumptions you have made.
• Add the planning dates to the Product Checklist (if used). • Publish the plan.
In practice
The majority of the material for the text will evolve from the previous planning steps. Some of it will already be known because of local standards.
For small projects
Even if you don’t have to publish a plan, you should still document the assumptions.
5.4 LINKS
There is a link between the structure of plans and the controls described in the Controls theme (see section 6.5). For example, at an end stage assessment the Project Board will examine the performance of the current Stage Plan and be asked to approve the next Stage Plan. The Team Manager will prepare a Team Plan and agree this with the Project Manager as part of accepting a Work Package.
5.5 DO’S AND DON’TS
By all means use a planning and control tool. It is much easier to modify a plan electronically rather than reach for the eraser. But don’t let the tail wag the dog. I have known project managers shut themselves in their office for two or three days a week, adjusting the plan to reflect the last set of timesheets. By the time they emerge, things have changed (slightly) again, and back they go to tune the plan again. By all means update the plan regularly with actuals, but then stand back and look at what the latest situation is telling you. If you have broken the plan down into sufficient detail, you should be getting warnings of slippage or faster progress than expected. Go out and have a word in the right ears. Can we recover? Can we take advantage of the progress? Is anyone struggling and in need of help? Project progress is often a case of swings and roundabouts. We have a good week followed by a bad week, or vice versa. By all means update the plan with actuals every week, but the plan itself should only be modified every two or three weeks on the basis of definite corrective actions that are needed to put the plan back on an even keel. Naturally, if an event comes along that we know will require a major change, don’t wait. But a lot of small hiccups will sort themselves out if the team is aware that you know and have taken an interest in putting things right.
5.6 IF IT’S A LARGE PROJECT
You really will need to use a planning and control tool – a software package. There may already be a standard tool that you are expected to use. Think very carefully about whether you have the time to update it with actuals. In a large project it may well be worth delegating the maintenance of plans to Project Support. Do you have expertise in using the package? Can you afford the time to become an expert? Many project managers struggle to create and update the plans themselves. Many of them have had to learn how to use the tool as they go along. In consequence they know about 10 per cent of the tool’s capabilities, and are ignorant of many shortcuts and easier ways of doing things with the plan. The Project Manager’s job is to generate the information to build the plan in the first place, use the updated plan as a guide to the status and look ahead for problems or risks. 5.7 IF IT’S A SMALL PROJECT
You may be prepared to put enough detail into the Project Plan to allow you to monitor and control the entire project. If so, no other plans are needed. But remember that in a small project you need to have broken down the creation of each product to a small handful of days, otherwise you will have insufficient detail against which to monitor progress. Balance this need for detail against the Project Board’s desire to be able to see the entire project on one page.
6.1 INTRODUCTION
Three of the PRINCE2 principles are supported by the Progress theme. These are:
• Management by stages; • Management by exception; • Continued business justification.
The purpose of the Progress theme is to define the points in a project at which control should be exercised, and to define the PRINCE2 responsibilities, documentation and procedures for monitoring progress at these points, and comparing actual progress against plans. 6.2 MANAGEMENT BY STAGES
A stage is a collection of activities and deliverables whose delivery is managed as a unit. As such, it is a subset of the project, and in PRINCE2 terms it is the element of work that the Project Manager is managing on behalf of the Project Board at any one time.