Peter F. • Thanks martin for sharing your article. I look forward to reading the next installments.

One of the main benefits of PBP is that it turns the focus to deliverables. I have started non-exam PRINCE2 training sessions by simulating a project and getting people work shopping. Experienced PRINCE2 people start developing a Business Case and then move to defining what has to be delivered. Non-PRINCE2 people start drawing up a list of tasks.

How can you develop a plan without clearly understanding what you have to deliver? Product Based Planning brings about this discipline.

The other major advantage is in measuring progress. As a project manager, I'm not really concerned about what you are doing. I really care about what you are delivering. The true measure of progress is the successful creation of products that have passed review against the quality criteria defined in their Product Descriptions. PBP is an effective tool for this.

Note that other tools may be just as effective. The key is that we need to document and agree what has to be delivered.

Ian M. • Martin. Clean and crisp reminder on the process. Ian

Carolyn P. • Producing a PID focuses the mind on the what, why, when, how, how much and who. All of which are key to understanding the boundaries of any project.

In terms of management, I consider that deliverables are key to monitoring progress at Programme and Project levels. However, I sometimes consider it worthwhile at the team resource level to also estimate effort and monitor effort-to-go on completion of tasks required to produce the deliverables and for the allocation of human resources as this gives an earlier warning of slippage and escalating costs. And, if necessary, stopping Projects which are failing to deliver to target, time and budget, (default is STOP not go on) even within a stage.

Wiesław K. • Hi Martin,
I think that the product-based planning is really a very useful technique. People who use it are of the opinion that in the first project one can save even up to 90% of the time used for planning, and with a next project, partially similar, additionally 50% of time can be saved.
The most important is that if you have the product flow diagram you can generate an activity network and a basic Gantt chart without using your brain. I kindly invite you to visit www.p2ware.com and download the P2ware Planner Trilal version. If you find a better tool for product-based planning, please let me know and I will send you a bottle of a good wine.

Steven D. • Good article!
Product based planning is a great technique. It helps tremendously in clarifying the scope.

When I give a PRINCE2 Foundation or Practitioner training, there is always an exercise on this technique. The eyes of the participants really go open: "Can we collect all this information through a single workshop...!?!".
Yes indeed, so please keep using it after the training ;-)

To support this technique PostIts and whiteboards are superb tools: simple and effective. I added a little boost to the PostIts by having a custom-made set so that the key information of every product can be captured. These are available from my website www.prooptimize.be

Mohit G. • Whether you call it products or deliverables or activities it doesn't really matter. Now in terms of WBS or Product based planning you can follow either of the 2 approaches:

1. Top- down: This is useful if you have a clear idea of what the final product/deliverable will be and you work your way down to identify if you have all the skills and resources to get to that end state. the interim products/deliverables can be identified and they will form your milestones. It will also give you a good idea of what your starting state should be in terms of budget, timeline and skills/resources. Any variances from your current state will need to be accounted for.

2. Bottom-up: This is extremely useful where you have to are constrained by budget, skills, etc. working your way up from your current state to where you want to get to will uncover the risks, dependencies and gaps which need to be addressed or else the end product / deliverable cannot be achieved with the current constraints.

Also once the planning is complete, there should be solid control over your progress. Again how you run the status meetings and control the progress will largely depend on your management and leadership style, the local/global nature of your project and the organisation culture.

Steven D. • @Mohit,
If you call it products or deliverables, I agree, no difference. If you start with activities though it does matter.
My experience is that the discussion is ending very fast when starting with activities. In general activities are covering multiple products. The problem with this is that there are so many assumptions about the products that a lot of these products are actually not estimated - resulting in a unrealistic schedules.

Martin W. • @Mohit, I'm with Steven on this. What's more, we should not assume that the product breakdown structure and the work breakdown structure are the same. They are not. Product-based planning focuses on the destination whereas work-based planning is more about the journey.

Product-based planning puts quality at the heart of planning; products are unambiguously defined which is a better way to deal with constraints and assumptions. Diving into the activities without understanding what the project intends to deliver is usually disastrous.

Product-based planning: http://wp.me/pyeK6-1dP.

Mohit G. • :) I don't want to get into the WBS/PBS debate frankly. As I use the best of all worlds. Of course if you read carefully, both the bottom up and top down approach both focus on products/deliverables. Again which approach you use depends on the nature of the project. There are just as many SCRUM/PMBOK/PRINCE2 related success stories as there are failures. It is really your ability to understand which fits in best. I personally use PRINCE2 for the overall project while I might incorporate elements of SCRUM during the stages. Now the important question is no matter which approach you use, what matters is how accurate are your estimates, dependency mapping and decision making skills. If you constantly end up with huge variances or missed products or activities required to deliver those products, hen methodology can't be blamed. The bottom line is we have to deliver successfull projects and programmes and not projects that confirm to certain methodology.

Martin W. • @Mohit I am not debating the relative merits of each technique. I'm merely pointing out that they differ significantly in a number of ways.

However, I do think the bottom-up approach described should be used cautiously (if at all.) To define all the low level activities it is assumed that the requirements are well defined and those involved are experts in all domains. This is rarely the case (I say this with knowledge and experience.) What's more, such an approach is more likely to miss something.

In my opinion - and it's only my opinion - the top-down approach is more complete and more accurate.