Prince2 header
products page

PRINCE2 - Plans part 2

Levels of plan

A project is carried out at different levels of management.
PRINCE2® recognises 3 levels of plan that reflect this.

These are:

  • Project Plan
  • Stage Plan
  • Team Plan

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:

  • The detail of later work elements will be uncertain
  • The work environment may be uncertain or changing
  • There will be risk factors that could affect the situation
  • Resource availability may not be easy to predict
  • Business conditions are hard to predict

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.

Project 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:

  • Providing the Business Case with project costs
  • Monitoring actual costs against forecasts in the review of progress of each stage by the Project Board
  • Identifying key products
  • Identifies resources
  • Identifies total costs
  • Key control points [see Milestones] often at the end of stages

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.

Stage Plan

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:

  • Shorter period affords increase accuracy of durations and resources
  • It builds on the known performance of earlier stages

Team Plan

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:

  • From the Stage Plan by breaking it down into activities and tasks and preparing the Team Plan in parallel
  • From the individual teams, which then combine their Team Plans to form the Stage plan

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)().

Stage and team quality plans

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.

  • They will identify their key products of interest
  • Identify the resource for the checking
  • Specifying the check points in the project where checking will occur

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.

Exception plans

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:

  • For a Team Plan by the Project Manager
  • For a Stage Plan by the Project Board
  • For a Project Plan by the Project Board following referral to corporate or programme management


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.

This product contains EVERYTHING in the publications:

Managing Successful Projects with PRINCE2 - 2005 edition
Managing successful Projects with PRINCE2 – 2009 edition
Directing Projects with PRINCE2.
The Complete Project Management package.

And much more besides - at a fantastic price.