A project is carried out at different levels of management.
PRINCE2® recognises 3 levels of plan that reflect this.
These are:
The Team Plan is optional depending on the size of the project and its complexity.
The Stage Plan may consist of a compilation of Team Plans, reflecting Work Packages from a number of teams, or that are required for the activity of sub-contractors.
If a Project, Stage or Team Plan is forecast to exceed its tolerances an Exception plan may be required.
As with any planning operation the lower the level of plan the more detail it will contain over a shorter time period.
It is recognised that the longer the time period for a plan the more difficult it is to accurately estimate task durations and resource.
Hence, costs are less certain.
However, some estimate must be carried out for the project as a whole in order to gain approval.
It is not possible to accurately plan the cost of an entire project from the start for a variety of reasons:
In addition, a project may form part of a programme. In this case plans must not clash with the aims of programme plan.
The Project Plan should be reviewed for uniformity and any Project Issues should be examined with a view to the programme plan.
It forms part of the Project Initiation Document.
It gives an overview of the total project.
Under PRINCE2 this plan must be produced. It is used for:
The Project Initiation Document separately identifies the Project Quality Plan.
Following the approval of the Project Initiation Document the original Project Plan is ‘frozen’ by baselining.
If the plan is subsequently changed at the end of stage reviews it will be freshly baselined as a new version.
By reviewing the original plan and any newer version the Project Board can monitor any change in the scope of the project.
Note that if any agreed plans indicate that tolerances will be exceeded this will need to be referred to the Project Board to agree any necessary corrective action.
This is required for each stage.
This follows the principle of horizon planning , that is, the detailed planning is triggered near the completion of a previous stage.
The Stage Plan is finalise near the end of a stage as part of Managing a Stage Boundary (SB)().
The plan will be used for day-to-day management by the Project Manager.
For small projects (say 2 stages) they may be incorporated directly into the Project Plan.
This is easy to do with modern software.
The level of detail will depend on the ability to manage the activities. If control is weak more detail may be needed.
This will be an opportunity to re-examine information going into the plan.
For example, assumptions, any risk analysis. Are there any new risks?
Stage plans should evoke a high degree of confidence owing to:
These may be needed if there are different skill groups or the use of external sub-contactors.
The project management should review their need. It will also depend on the size and complexity of the project.
They are derived in one of two ways:
The latter case is more likely when a number of sub-contractors are involved.
All Team Plans will need the approval of the Project Manager.
The input of Team Plans will form part of Managing a Stage Boundary (SB)().
These will identify the methods used to check the quality of each product created / updated during the plan and the resources that will be used for the checks.
Key roles will be from the user and supplier Project Assurance function.
The stage and team quality plans will be an integral part of their plans and not separate.
The resource and timing will be shown in the plan, for example, as a bar chart.
The chairperson and the reviewers for any quality reviews will be identified.
Should a plan exceed tolerances there may be a need to replace it with an Exception Plan.
This could happen for a Stage, Team or even a Project Plan.
It will carry on from the old plan and will contain the same level of detail.
The format is shown in the file ‘Exception plan.doc’ in the product package.
The Exception Plan will need approval:
Make sure that resource is added to assess any change requests.
Record whether products are owned by the customer or supplier by adding another heading to Product Descriptions as necessary.
When writing plans make sure that the level of any plans supplied by the supplier or customer are at a similar level.