Plans

• Purpose
• Defined
  • What is a plan?
  • What is planning?
  • Levels of plan
  • The Project Plan
  • Stage Plans
  • Team Plans
  • Exception Plans
• The PRINCE2 approach
  • Philosophy
  • Prerequisites for planning -
    design the plan
  • Define and analyse the products
• Prerequisites for planning
  • Write the Project Product Description
  • Create the product breakdown structure
  • Write the Product Descriptions
  • Create the product flow diagram
• Identify activities and dependencies
  • Activities
  • Dependencies
• Prepare estimates
• Prepare the schedule
  • Overview
  • Define activity sequence
  • Assess resource availability
  • Assign resources
  • Level resource usage
  • Agree control points
  • Define milestones
  • Calculate total resource requirements and costs
• Analyse the risks
• Document the plan
• Responsibilities

Key sections

• Introduction
• Business case
• Organization
• Quality
• Plans
• Risk
• Change
• Progress
• Introduction to processes
• Starting up a projectDirecting a project
• Initiating a project
• Controlling a stage
• Managing Product Delivery
• Managing a Stage Boundary
• Closing a Project
• Tailoring PRINCE2 to the project environment
• Directing Projects with PRINCE2

The PRINCE2 approach

Prerequisites for planning – design the plan

Create the product breakdown structure

The plan is broken down into its major products, which are then further broken down until an appropriate level of detail for the plan is reached.
A lower-level product can be a component of only one higher-level product.
The resultant hierarchy of products is known as a product breakdown structure.

When creating a product breakdown structure, consider the following:

• It is usual to involve a team of people in the creation of a product breakdown structure, perhaps representing the different interests and various skill sets involved in the plan’s output
• It is common to identify products by running a structured brainstorming session (for example, using sticky notes or a whiteboard) to capture each product as it is identified
• When a team is creating a product breakdown structure, there is likely to be discussion on the way in which to break down the products. For example, if the output of the plan is a computerized accounts system, users might want to separate the system into Accounts Payable, Accounts Receivable, General Ledger etc. The suppliers, however, may prefer Screens, Reports, Databases etc. Neither breakdown is wrong, but the project management team must reach a consensus on which approach will be used in the product breakdown structure (and hence the plan)
• It is useful to identify any external products required by the plan. External products already exist or are being created or updated outside of the scope of the plan and are required in order to create one or more of the plan’s products. For example, a procurement project would show the bidders’ tender responses as external products. The Project Manager is not accountable for the creation of external products as they will be supplied by parties external to the project management team. For each external product there should be a corresponding entry on the Risk Register detailing the threat to the plan if they are late or not to the required specification. Consider whether external products require Product Descriptions to reduce the likelihood of them not providing what’s expected of them
• When using product-based planning, it is important to consider whether to include different states of a particular product. An example of product states is ‘dismantled machinery, moved machinery and reassembled machinery’. It could be appropriate to identify the different states as separate products, where each state would require its own Product Description with different quality criteria and quality controls. This may be particularly useful when the responsibility for creating each state will pass from one team to another. Alternatively, a single Product Description could be used with a set of quality criteria that the product needs to meet in order to gain approval for each state
• When presenting the product breakdown structure, consider the use of different shapes, styles or colours for different types of product. For example, a rectangle could be used in a product breakdown structure to represent most types of product, but it may be helpful to use different shapes such as ellipses or circles to distinguish external products. Colours could be used to indicate which team is responsible for the product or in which stage the product will be created
• If the project is broken down into several stages, the products for each stage are extracted from the project product breakdown structure to form the stage product breakdown structure. These may be expanded to more levels of detail and thus ‘extra products’ may be added to give the detail required of the Stage Plan. Care must be taken to use the same names in the Stage Plan diagrams as were used in the Project Plan. The creation of Stage Plan diagrams may cause rethinking that requires further modification of the Project Plan’s diagrams in order to retain consistency
• In some cases, the organization’s lifecycle model may have a preset product breakdown structure and product flow diagram for common types of projects and a library of Product Description outlines for common products. In such cases the steps in the PRINCE2® product-based planning technique should not be skipped but used to verify the completeness of any library material. As every project is unique, there may be additional product requirements for this project or subtle differences in the quality criteria; the locations may be different, or the people and responsibilities involved may be different. Moreover, lifecycle models frequently address only one aspect of a project’s scope

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