PRINCE2 - Planning (PL) part 8
of the Cabinet Office under delegated authority from the Controller of HMSO.
Completing a Plan (PL7)
Fundamental principles
A plan is not simply a diagram.
It is incomplete without certain supporting narrative sections.
A decision needs to be made on the format of the presentation of the plan to the Project Board.
Context
Having completed the schedule and assessment of the risks satisfactorily, the plan, its costs, the required controls and its supporting text need to be consolidated.
Process description
Narrative needs to be added to explain the plan, any constraints on it, external dependencies, assumptions made, the risks identified and their required countermeasures.
Suggested texts for a Project Plan and a Stage Plan are given in the Product Descriptions in files ‘Project plan.doc’ and ‘Stage plan.doc’ in the product package.
The relevant management products should now be added to the plan:
Plan narrativeA plan is not completely understandable without text to explain:
- What the plan covers (for example, a particular stage, the project, specific products)
- The planning approach taken
- The intended approach to implemented the plan (for example, the number of stages, the size of Work Packages)
- How the plan will be monitored and controlled
- What management reports will be issued
- Any included constraints
- Risks contained in the plan and any countermeasures taken
- External dependencies
- Assumptions made, including any planning assumptions
- Tolerances to be applied
- The quality control methods and resources to be used (Stage and Team Plans)
Some risk monitoring events nay have been added to the plan, but at this point there is also a need to add the creation of any required management products to the plan because these take time and effort.
Examples are checkpoint Reports in a Team Plan, and Highlight Reports and End Stage Reports in a Stage Plan.
The graphical presentation of the plan is normally a Gantt or bar chart.
Most computerised planning and control packages provide a report in this format.
Such packages also provide a report on cost and resource requirements, typically in the form of a spreadsheet.
The majority of the material for the narrative sections of the plan will evolve as the previous steps in the planning cycle are undertaken.
Some of it will already be known because of adherence to local standards.
Tolerance margins for the plan should be agreed with the next level of management.
Depending on such factors as size, complexity and risk there must be agreement on what amount of deviation from planned cost, timescale, scope, quality, benefit and risk tolerances is to be allowed before the plan is considered to be in exception.
Tolerances are discussed more fully under Controls.
The products of the planning cycle should be checked for completeness and reasonableness by people experienced in planning and who know the project subject.
Amend the plans as required by the quality check.
The Product Checklist (if it is to be used) is now completed with the planned start and end dates added from the plan.
Responsibilities
The Project Manager is responsible for completing each plan, assisted by Team Managers where appropriate, and by Project Support staff where available.
Those with Project Assurance responsibility may wish to review the plan(s) and narrative.
| Management information | Usage | Explanation |
|---|---|---|
| Assessed plan | Input | Basics of the final planning package. |
| Product Checklist | Update | (If used) Start and end dates added to the list. |
| Completed plan for approval | Output | For approval by the next higher level of authority. |
These are given in tabular form in the file ‘PL7 completing a plan.doc’ in the product package.
Key criteria
- When considering a suitable level of tolerance, what level of confidence is there in the plan?
- Has consideration been to the business risks and constraints when setting tolerance levels?
- Has the format of the plan’s presentation material been agreed with the Project Board?
- Will the planning tool produce acceptable formats and quality for the presentation?
Keep the plans simple.
It is a good discipline to try to keep all graphical plans presented to the Project Board to one sheet of paper.
In this way, the plan is easily prepared, easily read and therefore more likely to be understood.
Anything that cannot be displayed in this way should be summarised and the detail included in a lower level of plan.
Similarly, do not use complex symbols, or present plans that require education or too much explanation for them to b e understood.
It might be worth considering the replacement of the graphical Project Plan with the Product Checklist.
Do not rely on pictures alone.
As far as planning is concerned, it is not necessarily true that ‘a picture paints a thousand words’.
Although a Gantt chart can show what is intended to happen and then what actually happened, it does not show why
it should happen that way or why something is different from the plan.
The narrative of a plan describes the thought that went into it, the assumptions made in preparing the plan, and any inherent risks.
This is particularly important when presenting plans for approval.
The readers are then able to accept both the plans and the assumptions to the plans from senior management.
If the layout of the report produced by a software package is not satisfactory, the data can usually be transferred to a spreadsheet or graphical package, where the required presentation can be constructed.
The Project Manager should discuss a Stage Plan informally with the Project Board and any Project Assurance personnel appointed by the Project Board before formally presenting it for approval.
The presentation of the plan should be appropriate for the audience.
In some circumstances it may be necessary to break down into further detail areas of a plan for the use of teams or individuals.
Be wary of producing an over-complex plan containing lots of detail that might be better supplied in narrative form.
A confusing or too detailed plan may ‘switch off’ the reader.
It helps if assumptions are consistent across all the projects of a programme.
Managing Successful Projects with PRINCE2 - 2005 edition
Managing successful Projects with PRINCE2 – 2009 edition
Directing Projects with PRINCE2.
plus:
The Complete Project Management package.
And much more besides - at a fantastic price.