South East Training - The Project Management Toolkit

The Project Management Toolkit is owned by South East Training.

You may use this resource for free on the condition that you include this statement on each page.

Copyright South East Training 2014 Available for free from: www.easyprojectmanagement.co.uk

Product Based Planning

Back Next

Overview

There is a lot of debate as to where to start planning a project. Some planners advocate starting at the end and working back to the beginning. Others prefer to start at the beginning and work through to the end.

Both of these approaches will work but the Product Based Planning approach, which works by starting at the end, is easier and more accurate. This is a top down approach which has its focus on the outputs or project deliverables. The traditional approach has been to look at the work involved in the project and break it down into tasks. More recent methodologies recommend looking at the products of the project and breaking those down.

Product Breakdown

 
The principal reason for adopting product-based planning is that it helps planners focus on the outputs or deliverables of a project rather than on the activities that go to create the outputs. In general, there are far fewer deliverables than tasks, so the process of defining the key stages of a project and arranging them in a logical sequence is much easier than trying to do the same with the multitude of tasks involved. Starting with the outputs also allows the planners to specify the quality of the deliverables at the earliest stage.

One method of deciding what the project will deliver is to use a mind-map, similar to the example below.


 



This illustrates the products created in preparing for a conference. Note that, at this stage, no attempt has been made to 'order' or sequence the products. The purpose of using a mind-map is to allow a free flow of thoughts without the constraint of having to put these in orde

Product Breakdown Structure

If necessary, each sub-product may be further divided into its sub-components. This produces a Product Breakdown Structure (PBS). It is possible to continue this sub-division until no further division is possible, although this is likely to over-complicate the process without providing additional benefits.

 


Note

An alternative way at looking at the Product Breakdown Structure is in terms of milestones. So, in the example above, key stages in providing the venue are:

  • Completing the venue specification
  • Selecting a venue
  • Establishing a contract with the venue.

 
The resulting output is called a Work Breakdown Structure (WBS) as it refers to the work necessary to reach the milestone rather than the product that emerge as a result. Many people find this concept easier to grasp, especially if the outputs at each milestone are intangible.

Product Descriptions

The next stage, once the various products have been identified, is to define them in sufficient detail to allow both the producers and those who will verify the outputs what to expect. The quality criteria applied to the product are an important part of this description. For example, the selected papers will need to meet certain criteria in terms not only of content but also spelling, grammar, layout, number of words and so on.

Typically, the product description will include:

  • The purpose of the product
  • The products from which it is derived
  • The composition of the product
  • Any standards for format and presentation
  • The product's quality criteria
  • The quality verification method.

This approach also helps the project team define the work packages essential for delivery of the project. In this example, it might be that you want to allocate development of the products in each product category to different team members. So, team member A develops the venue specification.  When that is complete, team member B visits suitable venues and makes a selection.  Subsequently, team member C negotiates the contract. Each product, therefore, can be represented as a work package specifying the product, product quality, duration, resource requirement and deadline for completion.  We will address work packages later.

Product Flow Diagrams

 With the knowledge of what is needed to create each product, it is possible then to place the products in a logical sequence. The resulting diagram is known as a Product Flow Diagram, Project Logic Diagram or, sometime, a Precedence or Dependency Diagram.

 




The previous diagram shows the dependencies involved in preparing for the conference. We have already seen from the Product Breakdown that for our conference to go ahead we need a venue, some speakers and, crucially, an audience. We also know that to attract our audience we are going to have to advertise and send this to prospective delegates in the form of a mailshot.

In terms of precedence, we know that as soon as we have decided the format of the conference, the broad topics to be addressed and when it will take place (all included in our initiation document), we are in a position to start identifying suitable venues, potential speakers and the prospective audience. These products are mutually independent. We do not need to know the precise venue for the event in order to decide who will be speaking, nor do we need to know who the speakers are before establishing a list of potential delegates.

However, before we can start advertising and registering delegates onto our conference we will have to have made decisions about the venue and the speakers as this information needs to go into the literature. It would be rash of us to invest in expensive advertisements and sending out mailshots until we had established formal agreements with these parties. So, the creation of the advertisement is dependent on the existence of agreements with the venue and the speakers.

Finally, the mailshot and the registration of delegates is dependent on us having the approved advertisement (ready to send) and our list of potential delegates (who to send it to). The conference can proceed as soon as we have our audience.

This diagram now allows us to phase the project and look in more detail at how we are going to achieve the final output.

Identifying the Activities

At some stage, it will be necessary to identify the activities necessary to produce the outputs so these can be allocated to individual contractors, functions, departments or team members.

One method of identifying activities is to use the transformation process recommended in the PRINCE2 handbook. This involves using the Product Flow Diagram to help identify what activities are required to turn one product or set of products into the next product. The diagram below illustrates how this might be done for part of the sequence.

 


Identifying the activies only becomes necessary if the 'doers' need that level of instruction, or if there is discretion in the sequence in which the activities could be conducted but you require it to be done in a specific way.  For example, if you allocate the task of painting a window to a professional decorator, other than specifying that you want three coats (primer, undercoat and top coat), it would normally be unnecessary to tell them that they have to rub down the existing paintwork, fill any holes, apply primer to any bare would, apply an undercoat, rub this down and apply a top coat.