Tips on using PRINCE2 Product Based Planning

The PRINCE2 method offers only 2 techniques, one being the powerful ‘product based planning’ technique. It starts with the simple premise that you need to identify and think about the project deliverables (which, in PRINCE2 are called products) before you think about the tasks / activities required to build them. So, for example, before you cook a meal you would decide what’s on the menu before you do anything else because you wouldn’t need to turn the oven on to pre-heat. It’s the same with projects.

There are four steps to product based planning, which are:

1. Write a Project Product Description – this describes the high level deliverable for your project. It is created right at the start of your project and contains some really useful information, such as the customer’s quality expectations and acceptance criteria. All of which helps both with planning and getting sign-off at the end.
2. Design a Product Breakdown Structure – this is a breakdown of the final deliverable into its (main) constituent parts. It looks a bit like an organisation chart, and is a great diagrammatic way of showing (& agreeing!) the scope of your project.
3. Write individual Product Descriptions – these are required for each major product that contributes to your high level product described above. They ensure that whoever is creating / building the product / sub-products knows the standards they are expected to deliver. A real aid to getting quality right.
4. Create a Product Flow Diagram – this puts the products into their logical order of creation and will identify / show where there are dependencies between the products. To my mind, this is the piece of product based planning that can often be skipped, especially if you are experienced in planning this way. It is possible to plug the products as milestones directly into a Gantt chart and identify the dependencies (& order of creation) there rather than requiring a separate diagram.

All of this is well and good, but one of the most common problems people face when trying to use it in earnest is in identifying the products, in-fact what is a product? Furthermore, to what level do products need to be broken down?

The initial, but rather unhelpful, answer is that ‘it depends’. It depends upon things like the nature of your project, how complicated the project is, and to what level do you care / need to care about the detail? If your project has safety issues, such as building an aircraft, sending a rocket to the moon, or building a sky-scraper – the answer will be you’ll probably care a great deal and therefore need to go down to significant detail.

To provide a more helpful answer it helps to use examples as it is a bit of a ‘dark art’. Let’s take the example of building / designing a car:

• If your project entails buying in the engine & not making it yourself you just need to specify the engine (dimensions, power etc) & not break it down into constituent parts
• If your project actually entails building the engine itself you will probably need to drill further down & identify the major parts that make up the engine, such as pistons, valves and spark plugs (describing their dimensions).

Another way to look at it is to break your products down to a level that the ‘parts’ can be independently installed / implemented and maintained.
Writing product descriptions can take quite a bit of time, so it is important to bear in mind that everything you do in product based planning should add value & clarity without re-inventing the wheel. So, if you feel you are spending too much time on small details that aren’t giving much benefit try to work out for your project(s) which aspects have / are most likely to really help you.

A final area that can get confused is when your project needs to create many products that are the same, or have different ‘flavours’. For example, I once knew of a project manager who was running an IT project and was new to PRINCE2. Keen to implement the method properly, he thought that a product description was required for every program specification that needed to be produced. Not so! Where your project is creating many products that have the same attributes and structure only one product description is required for all of them. In this scenario think of a product description as a template or standard to which all program specifications must adhere. So, look for re-use wherever possible. You wouldn’t write a standard for a PID every time to need to create a project PID would you? But, your organisation should have a standard or template that all good PID’s should meet.