Product Descriptions should be created for all the products as part of the planning activities and before the Project Plan can be completed. It is not always possible to create all the Product Descriptions in the Initiation Stage in each project and therefore, Product Descriptions may be created or updated in the Stage Boundary process. The typical content of a Product Description is similar to the Project Product Description .
A Product Description is normally written for each of the identified products in the product breakdown structure if required. Here are some things to consider when creating the product descriptions. Remember that quality information forms a good part of these descriptions.
A Product Description is used to:
- Understand the purpose of the product and its function.
- Define who will use the product and perhaps how it will be used.
- Identify the level of Quality required of the product so the product will be usable (fit for purpose).
- Define the skills required to produce the product and also to review and approve the product.
Timeline Product Description
The 4 steps in defining and analysing the products are:
- Write the Project Product Description in the Starting Up a Project process.
- Create the product breakdown structure which lists the products that need to be created.
- Write the Product Descriptions which is started in the Initiation Stage and Product Descriptions can also be created in the Stage Boundary process.
- Create the Product Flow Diagram which shows the flow of how product will be created and their interdependencies.
Sample Communication Management Approach document
Sample Product Description from the PEN project
Sample Product Description from the PRINCE2 Foundation Study Guide
Sample Product Description from the Driving School Project on Trello
Source data for Product Description
- Project Product Description from the SU process
- Product Breakdown Structure (PBS)
- End users of the product as they will be invited to workshops
- Team Managers / Subject matter experts who can give good feedback to users on what is and what is not possible
- Quality Management Approach
- Change Control Approach .
Format of the Product Description
- A document
- Presentation slide
- A mind-map which is not so popular
- Entry in a project management tool
The following quality criteria should be observed:
- The purpose of the product is clear and is consistent with other products.
- The product is described to a level of detail sufficient to plan and manage its development.
- The Product Description is concise yet sufficient to enable the product to be produced, reviewed and approved.
- Responsibility for the development of the product is clearly identified.
- Responsibility for the development of the product is consistent with the roles and responsibilities described in the project management team organization and the Quality Management Approach.
- The quality criteria are consistent with the project quality standards, standard checklists and acceptance criteria.
- The quality criteria can be used to determine when the product is fit for purpose.
- The types of quality inspection required are able to verify whether the product meets its stated quality criteria.
- The Senior User confirms that their requirements of the product, as defined in the Product Description, are accurately defined.
- The Senior Supplier confirms that the requirements of the product, as defined in the Product Description, can be achieved.
Tips from Frank
- Start with a good Product Breakdown Structure that is well facilitated and take your time as this the Scope of project.
- Identify what the project will not do (out of scope) and then think inside the box (not outside) .
- PRINCE2 says that start Product Descriptions should be started as soon as they have been identified but I don’t agree as it much better to keep have a better overview of the whole scope first than going to quick into detail.
- Keep the Product Descriptions as simple as possible: See the Driving School Trello example above.
- Focus on the quality of criteria for each Product Description by adding a quality requirement to each feature.
- E.g., Instead of saying a “PC with a good amount of RAM”, say “RAM 16 GB”.
- It is much easier see if the product has meet the requirements .
- Baseline the Product Descriptions as soon as the Project Plan is complete and remind users of the change control procedure.
- Refer to standards whenever possible instead of writing out the specification in detail.
- Note: For small projects, you may only need to write the Project Product Description .