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.
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.
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 narrative
A plan is not completely understandable without text to explain:
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.
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.
|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.
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.