Product Based Planning (PBP)
This is referenced within the Plans Theme, and the product-based planning technique is used whenever a “real” Plan is needed – these are:
- Project Plan
- Stage Plan
- Optional Team Plan
- Exception Plan if required.
Remember that within product-based planning, a product is something that the specialist team builds; they are usually physical – anything that you can hold or kick!
So during product-based planning, examples may be:
- software
- hardware
- a building
- a document
- Trained individual (you don’t make the person, of course, but you deliver training in some way so that the product is an individual with new or enhanced knowledge, skills and experience)
- a diagram
- a procedure
- a refurbishment
- Etc.
Activity-based planning
You are probably more familiar with bar charts or Gantt Charts as the starting point in planning. These contain the activities in a plan – still vital and used within a PRINCE2 Plan, but they are NOT what must be identified first, NOR are they part of PRINCE2 product-based planning, as we shall see…
The power of product-based planning is that by starting with the product and not just thinking about its activities, PRINCE2′ forces you to think through precisely what the product is, plus other characteristics such as quality criteria.
Imagine that you will create a document ‘help guide’ for using a new facility. If you start thinking about the activities involved, how do you know how long they will take and the resources and work involved?
You don’t know that because you have yet to first think through ‘what exactly we mean by a ‘Help Guide’. This is where PRINCE2 product-based planning comes into its own.
PRINCE2 product-based planning – there are four steps:
- Create the Project Product Description for the End Product (this step is only needed when creating the Project Plan – but it starts its life within the Project Brief)
- Create the Product Breakdown Structure (PBS)
- Create Product Descriptions (if needed) for lower-level products.
- Create the Product Flow Diagram (PFD)
I will not cover the creation of the Project Product Description here (even though it is the first step within product-based planning, as I have described in other articles.
Instead, I’ll remind you that:
- It is a document.
- It is created only once for the project
- it contains the customer’s quality expectations and acceptance criteria
- it is updated at the end of every stage
- the project is deemed finished once the acceptance criteria have been accepted.
Again, the Product descriptions are dealt with in detail in other articles, but I shall summarize them here:
- they are a document
- they are written in consultation with the users
- they contain the product quality criteria
- they are used to create, quality check, and authorize the completion of the product
- one will be written for each specialist product in your project
The PBS is a hierarchical diagram used within product-based planning and does not show the product creation sequence. It breaks the End Product down into lower levels of products as part of product-based planning. If you visualize a bottle of water – that would be the end product, and at lower tiers, you would have the plastic container, the cap, the label, and the water content itself.
The PBS does NOT show the sequence of creation of the products – it is a hierarchy showing how each product level ‘breaks down’. There can be no one-to-one connections (only one product underneath another – it must always break down into two or more products underneath.
A NOUN or OUTCOME describes a product (Brick Wall, New Brick Wall, or example).
Tasks are NEVER shown on PBS or PFD.
A task would have a NOUN and VERB (dig hole, write a report, design the widget, etc.)
The Product Breakdown Structure
The product at the top of the PBS is the End Product, the final product shown in the PFD.
Products shown without other products underneath them are called SIMPLE Products in product-based planning.
THEREFORE, all remaining products in the “middle” of the PBS are called INTERMEDIATE Products.
There are TWO types of Intermediate products:
- COLLECTIVE. These can be drawn as a rhomboid (squashed rectangle!) These are not actual products and help the planner to include/brainstorm all the authentic products underneath. So use the words Group or Grouping to describe them. Think of a collective within product-based planning as representing a “theme” where the products underneath have some common trait – such as Food Group, Hardware Group, Document Group, etc.). An example above is the ‘Food Group.’
- INTEGRATION. These are genuine products, and the products underneath them are combined in some way to become an Integration product. The shape of an Integration product can be the same as a simple or end-product, a rectangle. A simple example might be “Prepared Chicken Curry”; underneath this sit the food products that are combined to make the curry ( chicken breast, herbs, spices, garlic, tomatoes, etc.) An example above is ‘Prepared fruit Punch’.
- EXTERNAL PRODUCTS.
These are shown within product-based planning as an ELLIPSE. An external product is needed by the project but must pass one of the following tests: - It already exists. For example, a catalogue/price list, a tool or piece of equipment, an existing product, a current document, etc.
The Product Flow Diagram
The PFD shows “the sequence of creation of the products” within product-based planning and is drawn with arrows showing sequence and dependencies. Refer to the diagram below as an example:
That concludes the aspects of product-based planning within a PRINCE2 plan, but for completeness, here are the typical remaining steps to complete the plan document:
- identify the activities needed to create each product
- estimate each activity (duration, resources, cost, and work)
- create the schedule of activities (their sequence and dependencies)
- Assign resources to each activity
- include risk response and communication activities
- perform resource levelling if needed
- include controls
- add the text such as introduction, constraints, scope, etc.
PRINCE2 Product-based planning from structure to flow.
The PRINCE2 method details the approach made to planning as an initial three steps; create the project product description, create the product breakdown structure, and then create the product flow diagram.
I have covered this information elsewhere in a previous article, so I am giving you some guidance beyond the official Manual.
When you initially create your first attempt at a product breakdown structure, your ideas may only be random if you know the project area well. Just like writing a report, it’s best to leave it overnight and revisit it the next day, as this will give you a fresh insight and allow you to spot omissions or improvements more quickly.
The product breakdown structure (PBS) is a simple hierarchical diagram with the categories and subcategories of products, with the actual products being described at the lowest all bottom level.
The Product Breakdown Structure
You would then want to take those bottom-level products and use them to create the product flow diagram.
Take an example product breakdown structure, this shows the product list at its lowest level; the visual check is to spot each box with nothing underneath it. These are the lowest-level products that will be taken next to form the product flow diagram.
The product at the top is the end product that the project product description would have been written around. Therefore, this represents the whole project; when the product flow diagram is created, this would be the final product in the sequence.
PRINCE2 Intermediate Products
But between the top and bottom products, there are intermediate products. These usually describe a particular category or grouping. For example, the ‘prepared fruit punch’ product is authentic, consisting of ‘juiced oranges’, ‘juiced lemons’ and ‘blended wine’.
Whereas the intermediate product called ‘food group’ is not genuine; just a temporary title was given to all the authentic products below it. I’ve called it a group to make it evident to the reader that it is an intermediate product.
Still, I could have given it a different and agreed shape for intermediate products such as a rhomboid.
Some products may already exist or have been created earlier in this project or another project. These products should be included as they are needed to complete this project. An ellipse may be suggested to differentiate between an external product and an internal product.
Be clear, however, that this current project will not create external products but that they are needed to complete this current project.
To summarise, the only products taken to the product flow diagram are; the end-product, genuine intermediate products, external products, and the lowest-level products.
Structuring the structure.
“one man’s meat is another man’s poison”, quotes the old saying! And the same is valid when creating the product breakdown structure.
Suppose two separate and independent groups produce the product breakdown structure for the same project. In that case, there will likely be some differences even though both would deliver the correct result.
To use a rather trite example, if you are producing the product breakdown structure of a family car, you may group the categories in terms of the body shell, chassis, engine, brakes, and so on.
Another team may produce the product breakdown structure for third-party parts, standard parts, furnishings and fittings, mechanical parts, electrical parts, etc. Both systems could have a complete car, even though the structure diagrams may look completely different.
Before I leave the example of a family car, it’s worth mentioning again the intermediate products. Remember that I said only the integration type of products would be transferred to the product flow diagram. In contrast, the categories or groupings are merely invented devices to help create the product breakdown structure or will not be shared.
These integration intermediate-type products would need to be transferred to the product flow diagram. An example might be the gearbox, consisting of various gears, splines, sprockets, brackets and mouldings.
Therefore, regarding the product flow diagram sequence, all of the above lower-level products, such as gears, would need to be shown the first within the sequence, ultimately flowing into the gearbox as the final sub-products within the car.
In terms of the depth of the structure, I want this to be evenly balanced with the same level of detail throughout.
An example of a mobile thought through a product breakdown structure could be the body shell product of the car being at the same level as, say, the disc brake pads. This would signify an unbalanced structure whose main crime would be making the diagram harder to read and interpret.
In extreme circumstances, for example, if little is known about the project or the business area, getting an initial team together and simply brainstorming the product flow diagram is a great place to start.
The products that have been identified will undoubtedly be some of them. Still, the initial product flow diagram can be used to extract ideas and thoughts and talk to many other people, possibly over several days, to add products to this initial product flow diagram.
Carrying out this exercise very early in the project can be a neat way of defining the project scope!
Fairly obviously, the product flow diagram will show the sequence in which you planned to produce them, which is why the end product mentioned above is the final product to be shown in the product flow diagram.
PRINCE2 Masterclass
Fully compliant with the current PRINCE2 2023 Syllabus
Your Route To PRINCE2 Practitioner
Prepare for your PRINCE2 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.
The Projex Academy
related posts: