PRINCE2
In the PRINCE2 methodology this technique is represented as Planning (PL) and Managing A Project (MP).
Product-Based Planning
When starting a plan, it can be quite hard to think of all the tasks that will need to be undertaken if the project is to meet its objectives. PRINCE2 recommends a product-based planning approach.
This approach looks at all the deliverables of a project and the component parts as products. If the project is to implement a new information system then the final product would be 'working information system'.
This then allows the final product - the 'working information system' to be broken down into its component parts.
Note that there is seldom a single word descriptor for a product. There is usually a verb, normally in the past tense, describing the noun. This helps identify the tasks and products that are its component parts. Think of a car and you think only of the finished article. Describe it as an 'assembled car' and your mind immediately starts to think of the components.
The dotted lines show that many of these sub products break down further. How far you go when breaking down products depends on the ability to identify the necessary tasks for the project plan. As an example 'Designated Staff' may be sufficient where there is no re-structure of teams and no recruitment involved. Otherwise it may be necessary to break the product down into 'Redeployed Staff' and 'Freshly-Recruited Staff' to allow the somewhat different components of those two products to be identified.
Similarly if there is a well-equipped designated training room with computer, data projector and whiteboard then 'Booked Training Room' is sufficient. Otherwise the components of the room need to be specified.
The rhomboid shape used for the products 'Policy & Procedures' and 'Planned Activities' is used where there may be a product grouping rather than a single product. The fact that the rhomboid has not been used for the product 'Equipped Offices' suggests that whilst there may be more than one office, there are no required differences between the various offices. The product breaks down further into furniture, equipment and services.
One product - the course - has been included twice, because it has two different states: a planned course and a delivered course. This approach could usefully be employed for the software product which will have at least the following states - each of which requires task actions to arrive at it:
Specified Software
Tendered Software
Purchased Software
Installed Software
Tested Software
And that is for a single piece of software. There may be several: a database system bought-in, mixed with a web environment, an in-house front end and separate in-house database, office software etc.
The approach gives a focus to the planning task. It can be easier to identify tasks from such a product breakdown than it can be from trying to think of tasks off the top of your head. It also assists in identifying dependencies for the plan i.e. what needs to come first.
