Product Based Planning Demystified – Part 2 

Product Based Planning Demystified – Part 2

Product based planning

With this approach you identify and plan the deliverables or products first, and then, and only then determine the activities that you need to build each of those products.

This is entirely different to the more traditional activity-driven approach which starts with identifying activities and roaring up activity networks and Gantt charts.

Let me be clear, you still need activity planning because that is a vital element, but the product-led approach provides a powerful front end by performing product planning first – and hence it is called a product-led or product-based approach to planning.

Thinking “product” is not very natural, whereas thinking “activity” is.  Just pause for a minute about the regular activities that you carry out on an average day, I’m betting that you think of them in terms of tasks.  An example here is “I really must cut the grass today”.

So if the product-led approach is new to you, don’t worry if you don’t first understand it fully, because in this series of articles are will show you exactly how it is done.

Product identification

The first step in product-based planning is to think what the products are, and if you wish you could simply make a list.  But because of the way our brains are wired, steering and a blank piece of paper or a screen, and simply typing in a list of products is a hard thing to do.

And what I mean by hard, is that it is very easy to miss products out, and that will result in an incomplete plan with very many errors contained within it.

Another problem with simply making a list is that as you think up the various products, not only will you miss some, but the list will contain a mix of high level products and lower level detail products.  In other words it will have no structure.

In a project plan, you would typically look for between 15 to 30 products to cover the whole of the project have a fairly consistent level of detail.  More on this later.

The definition of a product

Put simply, a product is something that one of the project team builds or produces.  As an example, imagine that I carry out the review of an operational area and find that it needs a help desk.

In this review, the objective is to identify the problems to help define exactly what the help desk needs, and then launch a project that implements such a help desk.

So what are the products?  You must remember that products are something the team builds, so they are things that normally you can hold in your hands or, if they are too big for that, things that you can kick!

In this example, the products are small:

• List of requirements from the review
• Operating procedure for the new help desk
• Office furniture
• Computing hardware and software
• Installed communications
• Layout diagram for the facility
• Staff training
• Help desk application software
• New form designs
• New forms

….  And so on….

… to be continued …