In practice the Business case should describe what the project is to deliver, so MMU does not equire a formal Product Description separately from the Business case. PBS, which is the subject of this toolkit. Product Descriptions: detailed descriptions of each product (deliverable) that goes to make up the final product. In practice a large project may have hundreds of products and it is felt that the creation and maintenance of individual Product Descriptions may be unnecessary. Each project manager should decide whether this is an appropriate part of their project documentation.
A Product Description template is available if required. Product Flow diagram: this shows the sequence that the products will be delivered. This is covered in a separate Activity Network toolkit. 2. Why have a PSS? PRINCE2 describes a PBS as "a hierarchical structure that breaks down a final product into its constituent sub-products. It helps the planner to think of what other products are needed to build the final product, and to clarify all necessary work for the creation of that final product. 2 Another similar technique used by project managers is to create a Work Breakdown Structure (WBS). A WBS is the same idea, but instead of identifying the products, you identify the work. PBS seems a more logical approach s the aim of a project is to create the products, and the work is a by-product of that. So PBS focuses on products first - the work identification comes later. Thus the reason for creating a PBS is to help identify all the products you have to create within the project in order to deliver the overall product, and to link them in logical groups.
PRINCE2 defines different types of product and suggests creating PBS charts for each type - for example it differentiates between management products (e. g. the Business case, the project plan, the risk log) and specialist products (the things that the project s there to produce, e. g. the new IT system, the new building). At MMU the focus is on the latter - it is not felt to be necessary to build a PBS for management products as the project management framework defines what documentation should be used for different types of project.
Specialist products comprise the top level products that make up the final product, plus all the subproducts that go into creating those top level products. If a top level product doesn''t need to be broken down into sub-products, it''s called a simple product. The ones that can be broken down are called intermediate products. The following diagram for a "project" to make a cup of tea illustrates the idea. 1 The newest version on PRINCE2, released in 2009, no longer includes specific techniques as part of the methodology, though it still states that an appropriate set of techniques is a requirement for project management. OGC (2005) Managing successful projects with PRINCE2, TSO, London, P293 MMU Product Breakdown toolkit (VI) Page 1 The diagram shows that a cup of tea is made up of four products: the kettle intermediate group, the cup intermediate group, the tea simple product and the milk simple product. The kettle and cup each have three sub-products. Note that the PBS does not show sequence, though for something as simple as this example parts of the sequence can be implied, e. g. ou get the kettle, fill it with water and bring the water to the boil. Similarly you get the cup, wash it and then put the boiled water into it. But the diagram doesn''t show whether you get the cup after boiling the water or before. So once you have completed the PBS the next Job is to put it into sequence order (see Activity Network toolkit). Note that the second tier of the diagram does not represent actual products - these re there as labels for the groups of sub-products that go together.
They could be omitted from the diagram, but it''s helpful to have them there, and also when you create the project plan, they become the names of the project activity headings. 4. How to identify the products In all but the simplest of projects, no one person will be able to identify all of the products. The best way to identify the products is to hold a workshop with relevant people from across the project - not only will this help tease out the products, but it will help build a common understanding of what the project is to deliver, and Joint wnership of that. orkshop, but not essential. The workshop should comprise a series of steps: People think about products and write each product on a sticky note; All the sticky notes are put on a wall; Review the sticky notes and remove duplicates; Review the remaining sticky notes and put them in related groups; Repeat the steps as necessary until everyone feels that all the products have been identified, (usually three or four iterations is enough).
At the first run-through people will be a little uncertain, so allocate a reasonably short period of time for the first step - once a few sticky notes are up on the wall and hey can see how things get grouped, theyll cotton on and become more productive. A more complex (but still quite simple) project example is shown below for moving and renovating a garden shed. Page 2 Moved Shed 1. Old Shed 2. 1 Rotten Pieces 3. 1Shed Dimensions 2. Dismantled 3. New Requirements 2. 2 3. 2 New Piece 4. 1 New 3. 3Prepared Site 4.
Re-Assembled Shed 4. 2 Transported 3. 4New Fixtures & Fittings. 3. 5 Fixtures & Fittings List In practice there will be too many products to show on a single PBS diagram, so the master diagram would show the main groups, and a series of supplementary iagrams would show the breakdown for each group. For example item 3 in the above example could occupy a separate diagram with further breakdown of 3. 1 (3. 1. 1 Floor dimensions, 3. 1. 2 Longest wall dimensions, 3. 1. 3 Shortest wall dimensions), etc.
Note that the products have been numbered as well as labelled in the shed diagram. This is not obligatory, but it is useful because it helps identify products that belong on a group and also their level in the hierarchy. Once the PBS has been completed, a final check should be made with the project stakeholders, that everything has been captured. For example the item "3. 4 New Fixtures & Fittings" might have a further breakdown that identifies two windows and a door and the sponsor may say that a third window is required.
Although such requirements should have been written into the project''s mandate, business case and initiation document, in practice these documents are too high level so the PBS is a good tool for teasing out more details in the user specification. Product descriptions are not mandated for MMU projects, but they can be useful as part of productbased planning for the following reasons: • They establish the criteria for user acceptance; They act as a checklist for project deliverables; They clarify what each product is required to deliver.
In small and medium projects, product descriptions possibly are not required - or could perhaps be used for top level products in the PBS. In Major projects it is worth considering whether at least some, if not all, of the products should have product descriptions. Once the PBS has been completed, as described in section 4, the product descriptions can be written. These should be checked with relevant stakeholders and ideally signed off by the sponsor or project board. A product description template is available, and can be refined as appropriate. Page 3
No comments:
Post a Comment