The second task is to produce the Product Breakdown Structure.
Before you can do this you must:
These are at the lowest level of the Product Breakdown Structure hierarchy.
By their nature they are not broken down into any more products.
At this level the Project Manager, Project Board are happy that control is feasible.
Even these products could probably be broken down further but as they can be controlled at this level there would be no logical need to do so.
These lie between the lowest level of simple products above and the final product.
Each of these is broken down further into other products.
They are one of 2 types.
Integration productsThese require one or more activities, for example, assembly or testing applying to it, after its sub-products have been produced.
They should appear in the Product Flow Diagram and require Product Descriptions.
This is not a product in its own right but a convenient group of products.
This can act as a trigger to establish the actual products that may be required.
For example, ‘training product grouping’. This becomes a convenient umbrella to consider items such as student notes, PowerPoint presentations and exercises and examples.
A collective grouping is represented within a rhomboid, for a Product Flow Diagram, as opposed to the individual products which will be in rectangles.
The distinction between ‘integration products’ and ‘collective grouping’ items must be made clear and this can be accomplished in their naming.
The former including ‘integrated’, ‘tested’ or ‘assembled’ and the latter including the word ‘group’ or ‘grouping’.
Note that in this method the ‘integrated product’ could be a ‘product’ identified under a ‘collective group’ heading.
This is shown diagrammatically in the file ‘PID product grouping.doc’ in the product package.
The use of collective groupings should be consistent with how the Customer and supplier may view these groups.
How you name them must also be consistent so that all parties involved understand exactly the nature of the ‘collective group’ under discussion.
There are 2 types of product.
Specialist productsThe development of which are the subject of the plan
Management productsThese are required as part of managing the product and for establishing and maintaining quality, for example, End Stage Reports.
Examples of these management products are seen in the file ‘management products.doc’ in the product package.
They stay constant whatever the type of project.
The ‘Quality products’ are shown in an expanded diagram in the file ‘management quality products.doc’ in the product package.
The Product Breakdown Structure begins with the final product at the top of the hierarchy of levels.
The next level down becomes the immediate major products that must be produced before the final product.
The next level contains those just ahead of the above major ones and so forth.
The levels stop when you reach a level that you do not wish to break down any further and is controllable.
These can be represented as a Product Flow Diagram, as in Gantt charts or as spider diagrams.
Any lower level product must be a constituent of an upper level product and as such they are completely defined by their lower level products.
When products are represented in a Product Flow Diagram or Product Breakdown Structure there is no indication of the order in which they will be produced. As such product ‘rectangles’ (or rhomboids or ellipses) are not connected by arrows.
A product can exist in different states that form intermediates to a finished product.
For example, mix cement, apply the mix, allow to set.
If you had to move a large piece of machinery you might have dismantle machinery, move the machinery and finally assemble machinery.
We mentioned earlier the need to take products to a level that is controllable.
For control the product must require quality criteria that will be defined and checked.
If the planner feels that this is necessary then each ‘state’ could be treated as a product with its own Product Description that defines the quality criteria and the checking procedures.
If this is not the case then the ‘product states’ can be considered as one item, for example, ‘apply cement mix’ or ‘relocate machinery’.
A reason for considering each state as requiring its own Product Description might be if different resources are required.
This is considered further under Identifying Activities and Dependencies (PL3).
Products include those derived from external sources and those that already exist for the project.
Any plan must recognise, through dependencies, that these products are essential for the project.
The Project Manager is not responsible for their production.
For the purposes of PRINCE2® external products are identified by an ellipse symbol in the Product Flow Diagram or Product Breakdown Structure.
The delivery of external products are a risk that must be assessed.
These steps summarise the ‘hints and tips’ in ‘Managing successful projects with PRINCE2, 2005 edition’ and in addition may cross refer to sections of the appropriate Product Description outlines.