For organisations that develop commercial products — software products, manufactured goods, regulated products — the PRINCE2 quality planning approach sometimes raises a question: how does the Project Product Description relate to the organisation's existing product definition documents, such as a Functional Requirements Specification or a Design Brief?
The Project Product Description (PPD) Is High-Level
The Project Product Description is not a Functional Requirements Specification, a Design Brief, or a Technical Specification. It operates at the project governance level — defining, in summary terms, what the project will create and how it will be accepted by the customer.
The PPD answers three questions at a high level:
- What will the project produce? (the overall output, described in plain terms)
- What quality characteristics must it have? (the quality expectations)
- How will we know it is acceptable? (the acceptance criteria)
These are governance-level questions. The PPD is created during Starting Up and approved as part of the Project Brief — before the project's detailed requirements are worked out. It establishes the "contract" between the commissioning organisation and the project team at a level the Project Board can understand and agree.
Detailed Product Definitions Come Later
The detailed requirements, design specifications, and functional definitions are specialist products in their own right — created during the project's delivery stages, not during initiation. They will have their own Product Descriptions, quality criteria, and review processes.
In a regulated product development context, for example, a Design Input document (as required by ISO 13485 or FDA 21 CFR Part 820) would be a specialist product produced by the project — it would have its own Product Description defining its required content and quality criteria.
The Hierarchy
Think of it as a hierarchy: the PPD sits at the top and defines overall acceptance; below it, individual Product Descriptions define each component's quality requirements; below those, the organisation's domain-specific documentation (requirements specs, design documents, test reports) provides the technical detail. PRINCE2 provides the governance layer — the domain methodology provides the technical layer.
See Does Design Input Replace Product Description? for how PRINCE2 quality planning works in regulated product development environments.