Project management header
products page

Detailed planning – Overview


Whilst this section focuses on guidance in putting together a project schedule (derived from a work breakdown structure) PRINCE2® advocates product-based planning.

PRINCE2 2005 describes a product-based planning methodology which produces four products:

  • A Product Description of the final product of the project
  • A Product Breakdown Structure
  • Product Description of each product
  • A Product Flow Diagram

It provides a simple method for devising the project’s work in order to produce a product.
PRINCE2 2009 also advocates product-based planning.

The philosophy behind producing plans in PRINCE2 [see ‘The Complete Project Management plus PRINCE2’] is that the products required are identified first, and only then are the activities, dependencies and resources required to deliver those products identified.

This is known as product-based planning and is used for the Project Plan, the Stage Plan and, optionally, the Team Plan.
[see Plans - The PRINCE2 approach - Philosophy]
[see Plans - The PRINCE2 approach - Define and analyse the products]

Identify tasks

This section covers, in general terms, the main steps in getting to the finished project schedule.

The following activities assume that the project still needs approval by the Project Board.
In addition, it assumes the strategy to the final product is in place (necessary for approval anyway) and all we are now doing is trying to put together the overall project plan with more detail needed for the first stage plan.
The overall project schedule, and the more accurate stage schedule, is needed to gain approval.

Firstly a list of all tasks or work packages is required.
This is prepared from the top down.

That is, the major elements of a stage are identified and the tasks within this are then broken down and identified.
Detail of each task must be recorded.

Tasks should be identified down to a manageable level.

Estimate effort / duration

For each task the amount of effort, that is the number of personnel required, must be identified.
Knowing this the duration of the task can be estimated.
This should be more accurate for the stage plan but may be produced at a higher level for later stages and the overall project plan.

Identifying dependencies

Most tasks are reliant on other tasks or feed into other tasks and do not stand alone.
These interdependencies must be clarified and their exact nature ascertained.

Note that dependencies across departments will need to be considered.

The different type of dependency are described elsewhere.

Dependency links are now most commonly controlled by computer software.

Constructing the dependency network

When these are known the schedule should be put together with this information.
Further detail and the use of activity-on-arrow (AOA) and activity-on-node (AON) is discussed elsewhere.

Assigning responsibilities

Enter task responsibilities as necessary. When you get down to work package level identifying individuals for each task may be impractical for the schedule. This will be done locally. It may be better to indicate managers or supervisors who will be responsible for groups of tasks.

Allocating resources

Identify resources necessary.
For example, this will mean the number of personnel on each task and perhaps any equipment needed.
For major pieces of equipment it may be useful to consider creating a separate task for this.
For example, a large and expensive piece of equipment you may need to consider the following:

  • Ordering
  • Lead time for delivery
  • Equipment setup
  • User training (operation and health and safety)
  • Dismantling of the equipment
  • Return of equipment

Producing a Gantt chart

It is not compulsory to present the schedule as a Gantt chart but it is by far the most common way and has become a standard.
The Gantt chart represents each task or group of tasks as a horizontal bar with the length of the bar indicating the task duration.

Refining the plan

Once the Gantt chart has been produced it should be circulated to interested parties for comment.
Once any modifications are made the final version can be presented to the Project Board for ratification along with project approval.

It is possible that the schedule will require additional changes prior to Project Board approval.

The final schedule (that is the original for the project) should be archived and baselined for later comparison purposes.

In terms of managing paper distribution it is often desirable to limit circulation of paper schedules.
However, it is a good idea to provide electronic copies for the wider audience.

The act of planning can take a long time in itself and the cost should be incorporated into the programme.
If the planning is likely to be very complex it may be a good idea to carry it out as a separate project.

PRINCE2® is a Registered Trade Mark of the Office of Government Commerce in the United Kingdom and other countries.