Product based planning and product centred approaches sit at the heart of nearly all modern project management methodologies; but why? Here is a ‘whistle-stop’ tour of twelve good reasons:

1. The only thing a project leaves behind; projects are by definition temporary entities. The team will disband, the sponsor and project manager move on and the project itself will be nothing more than a file-note in the PMO library. The legacy is the tangible output that the project generated; its product set
2. Easier to manage than tasks; it is often not possible to tell the real status of a task, even with the most honest and diligent reporting. By looking at the extent of the completeness of a product (because of its physical nature) it is far easier and quicker to get an accurate view of progress
3. The power of visualisation; a joint understanding of theoretical concepts can be difficult to achieve; this is why people use analogies all the time. Products are very much easier to visualize – to see in your ‘mind’s eye’ – than activities, allowing people to reach and share a joint understanding much more quickly
4. Perfect source for milestones; why place a milestone at the end of an activity? If the output of the process is unsatisfactory then you will have to repeat the activity, so it hasn’t really finished and the milestone hasn’t been met. Base the milestone, instead, on the output….otherwise known as the product!
5. Easy to decompose; once the primary level product has been decided upon it is a relatively simple process to establish the sub-products. A house has foundations, walls and a roof; walls have vertical surfaces, windows and doors and so on. This ability to quickly decompose a product allows the selection of appropriate management points and highlights areas of particular risk very early in the project.
6. Tangible and therefore easy to monitor; because a product has, in all instances, a physical presence it is easy to establish if it is present or not. And, if a product is too big, late in the lifecycle or inappropriate as a monitoring point, you can simply select a product or combination of products at a level or two lower in the decomposition.
7. Unarguable evidence of progress; giving you the ability to demonstrate to your client (and your suppliers to you) what has been achieved so far for the time and money expended.
8. The answer to the client’s requirements; and therefore good for stakeholder engagement, management and expectation setting
9. Necessary to satisfy your critical success factors (CSFs); not only are products the key to benefits, but without appropriate products the CSFs are also unattainable. Remember, if you don’t achieve your CSFs then you have failed. Products allow you to place appropriate focus and emphasis
10. Ease of communication; akin to visualization, being able to clearly describe and itemise the deliverable set facilitates effective communication. It allows a straightforward explanation of what is in and what is out of scope of the project – because the product set is the scope.
11. The scope of the project; is often a problem because people interpret it in different ways. The user sees scope as the functionality that they need and have articulated in the requirements; the supplier, conversely, will see the scope as the work (activities) that they will have to undertake. The point at which these two unite is in the products – this is why they exactly define the scope
12. Highlight risks; as soon as people start to visualise or understand the level of complexity inherent in the products or their dependencies they start to understand the risks. At its simplest this may simply be a question of looking at a product definition and thinking “we’ve never done one of these before, I bet it’s tricky!” At a more sophisticated level the way in which the product breakdown structure is populated will tell you plenty about risk.
13. Clarifies dependencies; product flow diagrams (clearly impossible without an appreciation of the product set) give the earliest indication of the dependencies within and beyond a project. These are vital, later on in the planning process, to understanding the dependency network and critical path – if you can’t infer these, and you don’t fully understand your product flow diagram, you will have little control of your schedule.

Well there’s a ‘baker’s dozen’ of reasons for focusing on products – the key to effective project management. The question is which do you find most important? Please contribute to the debate and let us know your views