PRINCE2 Creating a 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 high-level product.
The result and hierarchy of products is known as a product breakdown structure.
The format and presentation of the product breakdown structure and product flow diagram are determined by personal preference. The product breakdown structure can be in the form of hierarchical charts, in the form of a mind map, or as an indented list.
The development of the product breakdown structure helps to identify dependencies among the products.
These dependencies can be described in a product flow diagram, which illustrates the sequence in which the products in the plan will be developed and any dependencies between them.
In some cases, intermediate products will need to be delivered. Intermediate products are products that are created as an essential input to the delivery of another product but not intended for use by the user.
For example, producing a prototype can be an effective way to reduce the risk of full-scale production, but the prototype itself is only the input to the full-scale production stage.
The product flow diagram and product breakdown structure must include both intermediate and final products, as well as any dependencies on external products outside the scope of the plan.
The product flow diagram leads naturally to the consideration of the activities required to deliver the products and provides the information for estimating and scheduling.
A product flow diagram should have a clear starting point and a clear end point. Its level of detail should be appropriate to the cost, duration, and scale of the products and work involved.
Preparing the product flow diagram usually involves consultation with subject matter experts in the delivery and acceptance of the required products.
The project manager and senior user may find it useful to use the product breakdown structure and product flow diagram to identify when project outputs (the products) will begin to affect outcomes and to allow the user to begin to measure the realization of benefits.
It may also be useful to distinguish products by which stage they are completed in, for example by colour.
When creating a product breakdown structure, the following should be considered:
It is usual to involve a team of people in the creation of a product breakdown structure, perhaps representing the other interests and various skill sets involved in the plan 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 are likely to be different opinions on how to break down the products.
As an example here, if the output of the plan is a computerized account system, users might want to separate the system into accounts payable, accounts receivable, general ledger, and so on.
The suppliers, however, may prefer screens, reports, databases, and so on. 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 products that are required to be created by other projects, or purchased, or hired directly from a supplier. These are externally sourced products.
The project manager is not responsible for the creation of externally sourced products as they will be supplied by parties outside the project team.
The project team will, however, be responsible for the products which are created using externally source products.
As an example here, the project may require an earth-moving machine which will be hired from a specialist contractor and is to be used by the project team to create a retaining wall on a building site.
For external resource products, consideration should be given to identifying threats to the plan should products be late or not to the required specification. In short, external products have risks.
PRINCE2 product-based planning
When using product-based planning, it is important to consider whether to include different states of a particular product. As an example here product states could be described as ‘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 externally sourced products.
Colours could be used to indicate which team is responsible for the products or in which management stage the product will be created.
If the project is broken down into several stages, the products for each management stage are extracted from the product breakdown structure to form a management stage product breakdown structure.
These may be expanded into 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 plans as we used in the project plan. The creation of stage plans may cause rethinking that requires for the modification of the project plan in order to retain consistency.
In some cases, the organization’s life cycle 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 of the PRINCE2 approach to product-based planning 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 the project or subtle differences in the quality criteria, 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.
Pass Your PRINCE2 Exams At First Try HERE!
This course is DEPRECATED
The old PRINCE2 6th Edition Foundation and Practitioner syllabus was upgraded in 2024. Check out the brand NEW PRINCE2 7th Edition Masterclass, covering all the current syllabus, training material and online exam benefits HERE
Your Route To PRINCE2 6th Edition Practitioner
Study PRINCE2 6 Foundation and Practitioner Exams with our famous on-line course with streaming HD Video Lessons, study guides and mock exams. In the last fifteen years we have had 6,000+ Academy students successfully transform their careers as PRINCE2 Practitioners.
