Creating a Powerful PRINCE2 Project Product Description
What is the point of holding a project planning session if you need clarification on the end product or deliverable?
The first information you must capture and understand is the customer’s requirements – right? In PRINCE2, this is done, as well as other information in the Project Product Description. First, let me remind you of where the Project Description starts, how it is used, and by whom.
The Starting Up a Project Process is where it all begins, and it is the Project Manager who liaises with the project board Executive and the Senior Users to create the Project Product Description.
At this point, it will contain just enough information to provide the project board with sufficient information for them to make an informed choice (this is done within the Directing a Project process) as to whether or not to proceed further with the project.
The Project Product Description forms part of the Project Brief. If approval is given, the project moves into the Initiation Stage.
During this stage, the project manager refines the Project Product Description further if needed, and it now forms part of the Project Plan within the Project Initiation Documentation since all PRINCE2 plans contain information on the products to be created within the scope of each plan.
The refined Project Product Description, along with the other information within the PID, is used by the project board (again within the Directing a Project process) to decide whether or not to proceed. If yes, this will trigger the second stage, the first (or only) of the specialist product delivery stages.
The Project Product Description is reviewed at the end of each stage by the project manager within the Managing a Stage Boundary process. It may be updated to reflect new information or changes the end product requires. If it is updated, this new version will need to be approved by the project board before continuing to the next delivery stage.
The Project Product Description plays a pivotal role by being referenced as products are handed over to the customer/users to check that the correct products/deliverables have been created. This may happen at the end of one or more stages if a staged delivery has been planned, but it will typically occur (for the end products) as part of the Closing a Project process.
Let me now give you some guidance when first creating or updating the Project Product Description:
Project Product Description Document
Title
This is usually the project’s name; let’s invent one for the rest of this section – “Villa Swimming Pool.”
Product Purpose
This defines the purpose that the project’s product will fulfil, the project product description function, what the overall products of the project are, and who will use them. It helps understand the product’s functions, size, quality, complexity, robustness, etc.
For example: To provide swimming and water leisure activities for the family and relatives within the villa grounds. Small children, as well as adults, will need to be catered for, in particular safety aspects for bathing as well as entrance and exit to the water.
Product Composition
A description of the major products to be delivered by the project. This is typically a list which defines the product scope of the project. It may also include essential management products such as 3rd party agreements:
For our example:
- Pool foundations
- Pump room
- Piping and drainage products
- Anti-slip tiling
- Pool tiles
- Roman steps
- Children s Play area
- Outside shower
- Contract plus terms and conditions
- Planning permission
- Statement of Work
- Product Derivation
First, you need to think about why this is important. The derived aspect may be predecessors from a previous stage or project, without which the current project cannot be started. It may be a prerequisite.
What are the source products from which this product is derived? Without knowing or referring to them – there is a risk that you may build the wrong products.
Examples are:
- Existing products or those to be modified
- Design specifications
- Reports
- The Project mandate
- Requirement documents
An indication of the skills/knowledge/experience required to develop the product or reference to which area(s) should supply the development resources should be included.
For example, planning permission, architectural design documents, catalogue product references, or existing wiring and drainage pipes within the villa grounds.
Customer’s quality expectations
A description of the quality expected of the project’s product, overall outputs, and the standards and processes that will need to be applied to achieve that quality. They will impact every part of the product development, and thus on time and cost.
The quality expectations are captured during discussions with the customer. Expectations should be prioritized. Be careful to solicit all critical stakeholders for their quality expectations and priority as there may be conflicts of opinion, and these will need to be agreed upon by (ultimately) the project board.
Product Acceptance criteria
This helps to resolve subjective customer quality expectations because ALL acceptance criteria must be measurable in some way. The project manager must expect to work with the customer to define measurable product criteria derived from the customer’s Quality Expectations.
Such criteria must contain a description, criteria measurement, prioritization, tolerances (remember them?), the method used, and who is responsible for measuring them (and when, if appropriate). The Acceptance criteria document should include who will review and authorize it.
The tolerances will be project-level; an example could be the size of the swimming pool within specific maximum and minimum dimensions.
Again for the swimming pool, the acceptance criteria method may be testing for the pump room and simply measuring the pool dimensions. It may include how many gallons of water per hour the pump can manage or the level (size) of contaminants the filter system can trap. In summary, the acceptance method can be anything from a simple visual inspection to a set of complex data gathered technically.
When dealing with responsibilities for signing off the acceptance criteria, consider who will own or operate the end product and, say, the Senior User role. A clear and appropriate sign-off of the acceptance criteria will reduce potential disputes once the end product is in operational use – plus, it will clearly show who is now responsible for fixing such issues!
Acceptance criteria may include aspects such as:
- Ease of use, support, or maintenance
- Appearance
- Functionality
- Project or operational costs
- Availability
- Reliability
- Security
A prioritized list of criteria that the project’s product must meet before the customer accepts it. These must be measurable definitions of attributes that must apply to the set of products to be acceptable to key stakeholders.
Whenever a plan in PRINCE2 is created or updated, the PRINCE2 Product-based planning technique is used, meaning a new or modified product description will be made.
A PRINCE2 product description will be created, modified or reviewed at the following activity points within a PRINCE2 project:
- Plan the initiation stage
- Create the project plan
- Accept a work package (the Team Plan)
- Plan the next stage
- Produce an exception plan
A product description is required for all specialist products, and Appendix A of the PRINCE2 Manual contains product description outlines that may be used or tailored for the management products.
Because such management products are typically used on all PRINCE2 projects, creating a product description for them is optional; merely applying the product description outlines as a template.
To help understand the value of creating a PRINCE2 product description and using this description as a basis for making the actual product, it is essential to understand the importance and purpose of doing this:
A product description assists in understanding from both the customer and supplier side the product’s precise nature, purpose, function and appearance.
The information in the PRINCE2 product description defines who will use the product, the sources of information, the level of quality required and the people or skills needed to create the product.
When the need for a PRINCE2 product has been identified, its product description should be created. First, a product description may have some of the information required, but at least they have identified the need for the product within the project.
The initial product description will be refined and updated as the product becomes better understood in later planning steps.
The project manager or the team manager is responsible for writing the PRINCE2 product description in the first place.
However, it is sensible and desirable to involve representatives from the operational area, users, or those with expertise in the product. Of particular use is the involvement of such individuals when defining the product’s quality criteria.
Suppose an organization has a central project office, as described in PRINCE2. In that case, they should keep a library of each product description created in previous projects for reuse on future projects containing similar products.
In this way, a project manager should reference such a library to see if an earlier product description can be reused or modified for the current project.
Because the product description is a central part of any PRINCE2 plan, the moment such plans are authorized and baselined, the product description for each product within the plan is also baselined and hence, is under change control.
Each PRINCE2 product description contains its quality criteria, which will differentiate the difference between an acceptable and unacceptable product. For this reason, the PRINCE2 product description quality criteria should be carefully considered.
Choosing general or ambiguous quality criteria will result in poor product quality, while at the other extreme, choosing tight and complex criteria may push up the cost and time of product creation, resulting in unnecessary ‘gold plating’.
The PRINCE2 product description.
I referred to the product description outlines within Appendix A of the PRINCE2 Manual and stated that these were management product outlines. The one exception is the product description of how to create a product description! This is intended as a template for creating specialist products.
Each PRINCE2 product description should have a unique identifier, including the project’s name, the product’s name and version number. Each product must be given a title. This is the name by which the product is to be known, and it, therefore, will be a noun or outcome, as verbs would confuse the reader into believing it is an activity.
An excellent example of a product title is ‘Power Supply Unit. A bad example is ‘Create the Power Supply unit, as this would infer an activity.
The purpose of the PRINCE2 product must be clearly stated as it helps understand the product’s functionality, quality and size, complexity, etc. Some products will be an end in themselves, while others may be the means to an end; an example is a specification document which will lead to creating a design document. It is a description of what the project products will fulfill and who will use them
The purpose of the project product description is to describe the project’s major products and
intended purpose, including the user’s quality expectations, the acceptance criteria, and acceptance
methods for the project. It is created in the process of starting up a project and refined during the
process of initiating a project.
The composition of the PRINCE2 product should also be described and broken down into its elemental products; for example, if the product were a plastic bottle, then its component parts would be the bottle itself, the cap or lid and the labeling. The composition could describe the structure or chapter headings if the product were a document. It is a description of the major products to be delivered
Derived from: what the products are based on, such as existing products or a requirement for a
new capability. In the example above, a source product for the plastic bottle may be the specification document from this or a previous PRINCE2 project, or the bottle itself may be derived or bought from the manufacturer as the project objective is to fill and label the product.
Another example of the relationship could be an email or statement from the user or customer laying out the benefits the product must bring and eventually realize.
The PRINCE2 product description must describe the product’s presentation or format. If the product were a document, it would tell whether it is to be presented as a ring binder, an email, or an electronic format such as a memory stick.
For the PRINCE2 product to be successfully created, then the knowledge, skills and experience of those needed to develop it must be stated. If this is neither known nor required, the area, department, group, or organization may be referenced here rather than identifying specific individuals.
If the product description is first created as part of the project plan, then the actual details of the individuals may be left until planning the relevant stage within which the product is to be created.
PRINCE2 Product Description Quality criteria.
This lays down the quality specification that the product is to be produced or created against and describes the quality measurements that those inspecting the finished PRINCE2 product will need to be applied.
In some cases, this only needs a reference to a common standard that is documented elsewhere rather than a detailed explanation of such criteria.
Where a product will it exist in various states, then different quality criteria for each state should be described. Alternatively, a unique PRINCE2 product description should be created for each state.
An example of the various states of a product could be a document in different languages, a prototype version, or different physical locations of the same product.
User’s quality expectations: description of the quality expected of the project products and the
standards and procedures that will need to be applied to achieve them
Acceptance criteria: a prioritized list of criteria that the project products must meet to be accepted
by the user
Acceptance methods and responsibilities: the means by which acceptance will be confirmed, and
the people responsible for the acceptance decisions will be determined
Project level quality tolerances: any tolerances that apply to the acceptance criteria.
The quality tolerance of each of the above quality criteria within the PRINCE2 product description must also be stated, and these will be the range of quality criteria within which the product would still be acceptable.
Examples here might be plus and minus specific dimensions, speed, resolution, colour, functionality, or weight.
The method of checking the quality or functionality must also be stated. Examples here are a visual inspection, the application of a test programme, a review or walkthrough, the use of an external test house, the use of a calibrated instrument, etc.
In addition to the skills required to create the product in the first place, it is also vital that the necessary skills to carry out the above quality checking are documented within the product description.
This may point towards the knowledge, skills and experience of individuals or the area which will supply such checking resources. As with the development skills, the identification and such individuals may be left until the planning of the relevant stage that this product description is used.
Finally, the quality responsibilities of those producing the product, those reviewing the product and those approving the product within a PRINCE2 project must be stated.
PRINCE2® 7 Foundation and Practitioner
Learn PRINCE2® 7 Foundation and Practitioner Online
** Enhance your PRINCE2 career now **
PRINCE2® Masterclass gives you the skills necessary to manage projects effectively and achieve your objectives.
Get 7 days a week 12 months one to one coaching with ex PRINCE2 examiner Dave Litten.
PRINCE2® is a globally recognized project management framework. By completing both the Foundation and Practitioner courses through our self-paced e-learning, you will develop an understanding of the methodology and learn how to effectively adapt it to any project.
The PRINCE2® 7 Foundation and Practitioner Masterclass is PeopleCert Accredited and guarantees to take you from PRINCE2 Novice to PRINCE2 Practitioner with our famous video learning, study guides and practice exams.
What Does the Masterclass Cover?
The PRINCE2 Foundation examination assesses your knowledge and comprehension of the PRINCE2 project management methodology as detailed in the syllabus. The PRINCE2 Practitioner examination, on the other hand, gauges your ability to apply and tailor the PRINCE2 method. Candidates who pass the Practitioner exam should be able to start implementing the method on an actual project with some guidance. However, their effectiveness may differ based on their experience in project management, the complexity of the project, and the level of support they receive in their work environment.
