Scope vs PPD
April 2025

PRINCE2 Project Brief — Scope vs PPD

A common problem in PRINCE2 Project Briefs is that the Project Product Description (PPD) ends up unnecessarily repeating information already captured in the Scope section. This redundancy has no value — it makes the document longer without making it clearer, and it risks creating inconsistencies when one section is updated but the other is not.

The Problem

The Scope section should define what the project includes and what it excludes — the boundaries. The Project Product Description defines the end product of the project: what it is, what it contains, what quality it must meet. When project managers start listing product functionality and requirements in the scope section, they create overlap that serves no one.

Four Guidelines

1

Separate Concerns

Don't start listing end product details in the scope description. Product functionality and requirements belong in the PPD. The scope section should define the breadth of the project — what areas of the organisation and delivery it encompasses.

2

Expand Scope Breadth

Rather than detailing the end product in the scope section, address all dimensional aspects of what the project covers: production environment, maintenance readiness, training and capability, rollout and communication, and support documentation.

3

Align PPD Composition to Scope

Match the main deliverables in the PPD's Composition section to each scope item. This creates a clear linkage — every area covered by the scope has a corresponding deliverable in the PPD.

4

Link Quality to Each Deliverable

For every deliverable listed in Composition, specify the customer quality expectations, applicable standards, or high-level requirements. This applies to both external and internal stakeholder needs.

Following these four guidelines produces a Project Brief where the Scope and PPD are clearly differentiated, mutually reinforcing, and free from redundancy. Stakeholders get a cleaner document that is easier to review and approve.