Project Product Description

Purpose
The Project Product Description is a special form of product description that defines what the project must deliver in order to gain acceptance. It is used to:

• gain agreement from the user on the project’s scope and requirements
• define the customer’s quality expectations
• define the acceptance criteria, method and responsibilities for the project.
   

The Product Description for the project product is created in the Starting Up a Project process as part of the initial scoping activity, and is refined during the Initiating a Project process when creating the Project Plan. It is subject to formal change control and should be checked at management stage boundaries (during Managing a Stage Boundary) to see if any changes are required. It is used by the Closing a Project process as part of the verification that the project has delivered what was expected of it, and that the Acceptance Criteria have been met.

Composition

The project product description includes the following:

• Title - Name by which the project is known
• Purpose - This defines the purpose that the project’s product will fulfil and who will use it. It is helpful in understanding the product’s functions, size, quality, complexity, robustness, etc.
• Composition - A description of the major products and/or outcomes to be delivered by the project
• Derivation - What are the source products from which this product is derived? Examples are:
  • existing products to be modified
  • design specifications
  • a feasibility report
  • the project mandate
• Development skills required - An indication of the skills required to develop the product, or a pointer to which area(s) should supply the development resources
• Customer’s quality expectations - A description of the quality expected of the project’s products and/or outcomes and the standards and processes that will need to be applied to achieve that quality. They will impact on every part of the product development, and thus on time and cost. The quality expectations are captured in discussions with the customer. Where possible, expectations should be prioritized
• Acceptance criteria - A prioritized list of criteria that the project’s products and/or outcomes must meet before the customer will accept them. These are measurable definitions of the attributes that must apply to the set of products to be acceptable to key stakeholders and, in particular, the users and the operational and maintenance organizations. Examples are ease of use, ease of support, ease of maintenance, appearance, major functions, development costs, running costs, capacity, availability, reliability, security, accuracy or performance
• Project-level quality tolerances - Specification of any tolerances that may apply for the acceptance criteria
• Acceptance method - Statement of the means by which acceptance will be confirmed. This may simply be a case of confirming that all the project’s products and/or outcomes have been approved or may involve describing complex handover arrangements for the project’s products, including any phased handover of the project’s products
• Acceptance responsibilities - Definition of who will be responsible for confirming acceptance.

Derivation
The Project Product Description is derived from the following:

• Project Mandate
• discussions with the Senior User and Executive, possibly via scoping workshops
• request for proposal (if in a commercial customer/supplier environment).

Format & Presentation
A Product Description for the project product can take a number of formats, including:

• a document, presentation slides or mind map
• an entry in a project management tool.

Quality Criteria
The following Quality Criteria apply to a Project Product Description:

• The purpose is clear.
• The composition defines the complete scope of the project.
• The acceptance criteria form the complete list against which the project will be assessed.
• The acceptance criteria address the requirements of all the key stakeholders (e.g. operations and maintenance).
• The Project Product Description defines how the users and the operational and maintenance organizations will assess the acceptability of the finished product(s). It should ensure that:
  • all criteria are measurable
  • each individual criterion is realistic
  • the criteria are consistent as a set. For example, high quality, early delivery and low cost may not go together
  • all criteria can be proven within the project life (e.g. the maximum throughput of a water pump) or by proxy measures that provide reasonable indicators as to whether acceptance criteria will be achieved post-project (e.g. a water pump that complies with design and manufacturing standards of reliability)
• The quality expectations have been considered, including:
  • the characteristics of the key quality requirements (e.g. fast/slow, large/small, national/global)
  • the elements of the customer’s quality management system that should be used
  • any other standards that should be used
  • the level of customer/staff satisfaction that should be achieved if surveyed.

Extract PRINCE2 6th Edition. Copyright© AXELOS Limited 2017. Used under permission of AXELOS Limited. All rights reserved.  You can purchase your own full copy here