6.2 The PRINCE2 Planning Technique (PPD, PBS, Product Descriptions, PFD, WBS)

Product-Based Planning Technique (PBS, PFD, Product Descriptions)

Practitioner Core Mandate: The hallmark of PRINCE2 planning is its unwavering embodiment of the Focus on Products principle. Traditional project management frequently stumbles into the "activity trap"—rushing to create task lists, assign labor hours, and draw Gantt charts before stakeholders have agreed on exactly what physical, digital, or operational outputs must be delivered. In PRINCE2 7, work is never scheduled until the required products, their quality specifications, their constituent components, and their sequence of delivery have been formally defined and analyzed.

---

1. Philosophy & Advantages of Product-Based Planning

Product-Based Planning is a structured, four-step technique unique to PRINCE2 that ensures projects deliver business outcomes rather than mere busyness.

Why Traditional Activity-Based Planning Fails

When project managers jump straight into activity planning (asking "What do we need to do?"):

• Premature Focus on Effort: Teams focus on labor and tasks rather than the tangible deliverable that creates value.
• Invisible Omissions: Essential deliverables (such as user manuals, regulatory licenses, data migration scripts, or training curricula) are forgotten because activities like "implement software" obscure the necessary sub-products.
• Ambiguous Quality Standards: When activities finish, arguments erupt over whether the output is acceptable because no pre-agreed quality specifications were established.
• Scope Creep: Without a clear boundary of products, teams easily absorb extra "helpful" tasks that do not contribute to authorized deliverables.

The Product-Based Solution

By shifting the opening question to "What products must be delivered to achieve the project outcome?", PRINCE2 guarantees:

1. Complete alignment between customer expectations and supplier deliverables.
2. Clear, verifiable quality specifications established upfront before design or construction begins.
3. Explicit identification of external dependencies (external products) beyond the project team's direct control.
4. Objective progress tracking: a product is either 100% complete (tested and approved against its Product Description) or it is not.

---

2. The Seven Steps of the PRINCE2 Planning Technique

PRINCE2 7 figure 7.3 sets out a planning technique built on product-based planning. It is repeated for the project plan, each stage plan, and each team plan, and the same technique is used for an exception plan. The manual is explicit that the technique is not strictly sequential — scheduling and estimating in particular are interdependent and are performed collaboratively, while the budget is usually most efficient to prepare once product descriptions, work package descriptions, and the schedule are relatively mature. An alternative planning procedure may be used instead, provided the choice is documented as a tailoring decision in the PID.

┌─────────────────────────────────────────────────────────────────────────────┐
│               THE PRINCE2 7 PLANNING TECHNIQUE (FIGURE 7.3)                 │
├─────────────────────────────────────────────────────────────────────────────┤
│ STEP 1: DEFINING AND ANALYSING PRODUCTS  (section 7.3.2)                    │
│ ┌─────────────────────────────────────────────────────────────────────────┐ │
│ │ 1a. Write the PROJECT PRODUCT DESCRIPTION (7.3.2.1)                     │ │
│ │     └─ Overall scope, user's quality expectations, acceptance criteria  │ │
│ │ 1b. Create the PRODUCT BREAKDOWN STRUCTURE (7.3.2.2)                    │ │
│ │     └─ Hierarchical decomposition into products, not activities         │ │
│ │ 1c. Write the PRODUCT DESCRIPTIONS (7.3.2.3)                            │ │
│ │     └─ Purpose, composition, derived from, quality specifications,      │ │
│ │        quality tolerances, producer / reviewer / acceptance authority   │ │
│ │ 1d. Create the PRODUCT FLOW DIAGRAM (7.3.2.4)                           │ │
│ │     └─ Logical sequence of creation and external product dependencies   │ │
│ └─────────────────────────────────────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────────────────────────────┤
│ STEP 2: ORGANIZING WORK PACKAGES  (7.3.2.5)                                 │
│ • Group the products into work packages; the WORK BREAKDOWN STRUCTURE       │
│   links the product breakdown structure to those work packages              │
├─────────────────────────────────────────────────────────────────────────────┤
│ STEP 3: PREPARING ESTIMATES  (7.3.2.6)                                      │
│ • Effort, duration, and resource requirements per work package              │
├─────────────────────────────────────────────────────────────────────────────┤
│ STEP 4: ANALYSING RISKS  (7.3.2.9)                                          │
│ • Examine the emerging plan for threats and opportunities; feed the risk    │
│   register and, where needed, the risk budget                               │
├─────────────────────────────────────────────────────────────────────────────┤
│ STEP 5: PREPARING A SCHEDULE  (7.3.2.7)                                     │
│ • Sequence, resource, and critical-path the work; set milestones            │
├─────────────────────────────────────────────────────────────────────────────┤
│ STEP 6: PREPARING THE BUDGET  (7.3.2.8)                                     │
│ • Project costs, plus the optional risk budget and change budget            │
├─────────────────────────────────────────────────────────────────────────────┤
│ STEP 7: DOCUMENTING THE PLAN                                                │
│ • Assemble the plan itself, with its tolerances across the seven targets    │
└─────────────────────────────────────────────────────────────────────────────┘

[!EXAM WATCHPOINT: THE 6th EDITION STEPS ARE GONE] The 6th Edition taught "design the plan → define and analyse the products → identify activities and dependencies → prepare estimates → prepare the schedule → analyse the risks → document the plan". PRINCE2 7 replaces identify activities and dependencies with organizing work packages and drops design the plan as a named step. Answer from figure 7.3.

---

3. Before You Start: Designing the Plan (a tailoring decision, not a step)

Before drafting diagrams or lists, the Project Manager must determine the operational design of the plan itself. Planning is not a one-size-fits-all exercise.

Key Design Decisions:

• Audience & Presentation Format: Will the plan be presented as a high-level executive dashboard for the Project Board, a Gantt chart for engineers, or a visual Kanban board for an agile delivery team?
• Planning Tools & Data Standards: Which digital tools will be utilized (e.g., enterprise PPM software, spreadsheet registers, Jira boards)? How will data integrity and auditability be maintained in line with the project's Digital and Data Management Approach?
• Estimating Methods: Will the plan rely on top-down parametric models, three-point PERT analysis, or agile planning poker?
• Level of Granularity: How detailed should the plan be, given the planning horizon and project complexity?
• Sustainability Standards: How will carbon emission tracking, waste metrics, and material life cycle data be captured and baselined within the schedule?

---

4. Step 1: Defining and Analysing the Products (7.3.2)

Step 1 is the intellectual core of the technique, comprising four interconnected management products:

4.1 Step 1a: Write the Project Product Description (7.3.2.1)

• Creation Timing: Drafted in Starting up a Project (SU); finalized and baselined in Initiating a Project (IP) as part of the Project Initiation Documentation (PID).
• Purpose: Defines what the project must deliver to gain final customer acceptance. It represents the overarching product of the entire project.
• Key Components:
  • Title & Purpose: The high-level identity and business rationale.
  • Composition: The major product groupings that constitute the whole.
  • User's Quality Expectations: High-level quality goals expressed by the customer (e.g., "high reliability, 99.99% uptime, zero carbon operational footprint").
  • Acceptance Criteria: Prioritized, measurable list of criteria that the final project product must satisfy before the customer will accept delivery (e.g., using MoSCoW: Must Have, Should Have, Could Have, Won't Have this time).
  • Project-Level Tolerances: Allowable variances for the project product's performance attributes.
  • Acceptance Method & Responsibilities: How and by whom final acceptance will be verified and signed off.

4.2 Step 1b: Create the Product Breakdown Structure (7.3.2.2)

The Product Breakdown Structure (PBS) is a hierarchical decomposition of the project product into its constituent physical, functional, or information components.

                  SAMPLE PRODUCT BREAKDOWN STRUCTURE (PBS)

                          [New Headquarters Campus]
                                     │
         ┌───────────────────────────┼───────────────────────────┐
         ▼                           ▼                           ▼
   [Civil Works]           [Building Management]        [Transition Products]
         │                           │                           │
   ┌─────┴─────┐               ┌─────┴─────┐               ┌─────┴─────┐
   ▼           ▼               ▼           ▼               ▼           ▼
[Foundations][Frame]      [HVAC System] (Power Grid)   [Staff     [Facility
                                         (External)    Training]   Manuals]

Types of Products in a PBS:

1. Integration Products: Deliverables that assemble or integrate component products into a coherent whole (e.g., "Integrated Testing Environment", "Assembled Chassis").
2. Collective Products: Grouping nodes used to organize the hierarchy (e.g., "Civil Works", "Marketing Assets").
3. Specialist Products: The individual deliverables built by technical teams (e.g., "HVAC System", "Database Schema").
4. External Products: Deliverables that are required by the project but are created or supplied outside the project's direct control (e.g., "Power Grid Connection", "Government Environmental Permit", "Client-Supplied Server Hardware"). In a PBS, external products are visually distinguished (traditionally using an ellipse or dashed border).

4.3 Deep Dive: PBS and WBS Are Partners in PRINCE2 7, Not Rivals

The 6th Edition taught the work breakdown structure mainly as a foil for product-based planning. PRINCE2 7 adopts it. Section 6.2.5 of the manual defines a work breakdown structure as "a hierarchy of all work to be done during a project that forms a link between the product breakdown structure and the work packages", and section 7.3.1 says supporting elements of the plan — including the work breakdown structure, estimates, and project schedule — are derived from the product descriptions. The sequence still starts with products; the WBS is what turns products into assignable work.

[!EXAM WATCHPOINT] An option that says PRINCE2 7 rejects the work breakdown structure, or that a WBS is inherently un-PRINCE2, is wrong. The correct Version 7 position is that the WBS is derived after the PBS and links it to work packages. What remains true is the ordering rule: products first, work second.

[!CRITICAL EXAM RULE] A Product Breakdown Structure must NEVER contain verbs or actions. If an exam question presents a PBS containing items like "Construct foundation", "Write software", or "Test engine", that PBS is defective under PRINCE2 rules. The nodes must be re-stated as products: "Completed foundation", "Software module", and "Test results". Those activities belong in the work breakdown structure, which is built from the PBS in the next step.

4.4 Step 1c: Write the Product Descriptions (7.3.2.3)

Every product identified in the PBS (or at minimum, every significant specialist deliverable) requires a formal Product Description. In PRINCE2, the Product Description provides the explicit quality contract for that deliverable.

Anatomy of a Complete Product Description:

1. Identifier & Title: Unique reference code and descriptive product name.
2. Purpose: Why the product is needed and what business utility or operational function it fulfills.
3. Composition: The internal components, sections, or technical ingredients that make up the product.
4. Derivation: Source inputs, predecessor products, background data, or external specifications used to construct it (e.g., "Derived from Corporate Brand Guidelines v4.2 and Customer Survey Results").
5. Quality Specifications: The measurable specifications, technical standards, performance tolerances, and aesthetic rules the product must satisfy (e.g., "Sub-second database query response under 5,000 concurrent users").
6. Quality Method: The specific technique, inspection, walkthrough, or test used to verify compliance with the quality specifications (e.g., "Automated load testing using JMeter scripts").
7. Quality Tolerances: The allowable variance around the quality specifications (e.g., "Response time: 1.0 second ± 0.2 seconds").
8. Quality Skills Required: The specialized technical or operational competencies necessary to execute the quality method.
9. Quality Responsibilities: Defined individuals or roles responsible for:
   • Producer: Person/team who creates the product.
   • Reviewer(s): Independent person/team who inspects or tests the product against its criteria.
   • Approver(s): Role with delegated authority to sign off and baseline the product (often the Senior User or delegated specialist).

4.5 Step 1d: Create the Product Flow Diagram (7.3.2.4)

The Product Flow Diagram (PFD) defines the logical sequence in which the products identified in the PBS will be created and identifies the dependencies between them.

                  SAMPLE PRODUCT FLOW DIAGRAM (PFD)
   
   (Environmental Permit) ──┐
         (External)         │
                            ▼
   [Site Survey] ──► [Architectural Design] ──► [Constructed Facility]
                            ▲                            │
   [Soil Test Data] ────────┘                            ▼
                                                [Commissioning Report]

Rules for Constructing a PFD:

• Products Only: Like the PBS, the PFD contains only products (nouns), never activity verbs.
• External Products as Starting Nodes: External products (e.g., "Environmental Permit", "Client Legacy Data") originate outside the project and therefore have no predecessor nodes on the PFD. They appear as entry points representing critical external dependencies.
• Logical Sequencing: Arrows represent product dependencies ("Product A is required to create Product B"), not timeline durations.
• Avoid Premature Scheduling: The PFD shows logical sequence, not start dates, end dates, or resource allocations.

---

5. Step 2: Organizing Work Packages (7.3.2.5)

Once the PFD is established, the products are grouped into work packages. PRINCE2 7 makes this a named step of the planning technique, and it is also where the work breakdown structure comes in: the WBS is the hierarchy of all the work to be done, and it forms the link between the product breakdown structure and the work packages. It supports the project manager in deciding how to structure project teams and where the boundaries between them fall.

Organizing work packages is genuinely a design decision, not clerical grouping:

• Keep internal and external work separate where possible. PRINCE2 7 advises that a single work package should not mix internally staffed and externally supplied work — the commercial and reporting arrangements differ, and a mixed package makes accountability ambiguous.
• Scale to the project. A WBS is most useful when there are multiple work packages, especially a mix of internal and external ones. For a very simple project delivering one work package with a small team, a work breakdown structure is not required.
• Feed the statement of work. For externally supplied packages, the WBS is what makes it possible to write a defensible statement of the work required.
• Then derive the activities. Within each work package, examine each product node on the PFD and derive the work required to make it a reality.

Turning products into work: for every product on the PFD, derive four activity types

1. Creation Activities: The work necessary to design, construct, code, or manufacture the product (e.g., "Draft user manual", "Fabricate steel frame").
2. Quality Verification Activities: The execution of the quality method defined in the Product Description (e.g., "Conduct peer review of manual", "Perform ultrasonic weld inspection").
3. Approval & Baselines Activities: The formal administrative sign-off by the designated Approver (e.g., "Obtain Senior User approval for manual").
4. Handover / Integration Activities: Commissioning, installing, or transferring the product into operational ownership.

---

6. Steps 3-6: Estimates, Risk Analysis, Schedule and Budget (7.3.2.6-7.3.2.9)

With all activities derived directly from approved Product Descriptions and mapped through logical PFD dependencies, the Project Manager completes the planning technique by:

1. Estimating effort, resource requirements, and durations for each activity.
2. Establishing dependencies between activities (finish-to-start, lead/lag times).
3. Calculating the Critical Path and identifying float.
4. Allocating resources, resolving over-allocations through leveling, and calculating cost and carbon baselines.
5. Documenting the agreed stage and project tolerances.

---

7. Comparative Matrix: Product-Based Planning Artifacts

---

8. Practitioner Scenario Evaluations

Scenario A: The Defective PBS with Activity Verbs

A municipal project team is planning a Smart Traffic Management initiative. The Project Manager convenes a workshop and produces a draft breakdown structure containing nodes labeled: "Audit existing traffic lights", "Write central controller code", "Install fiber optic cables", "Test camera feeds", and "Commissioned Traffic System". The Project Manager submits this diagram to Project Assurance as the project PBS.

Practitioner Evaluation:

• Governance Flaw: The draft is not a PRINCE2 Product Breakdown Structure; it is an activity breakdown. Items like "Audit existing traffic lights" and "Install fiber optic cables" are active verbs describing effort, not product deliverables.
• Impact: By listing activities rather than products, the team has omitted critical physical and digital artifacts—such as the "Traffic Audit Report", "Fiber Cable Infrastructure", and "Acceptance Sign-Off Certificate". Quality review cannot be conducted against an activity; it can only be conducted against a tangible product.
• Correct PRINCE2 Action: Project Assurance must reject the diagram. The Project Manager must convert all active verbs into product nouns (e.g., "Traffic Audit Report", "Central Controller Software", "Installed Fiber Network", "Camera Feed Test Log").

Scenario B: Subjective Quality Specifications

On a retail banking mobile application project, the Project Manager authors a Product Description for the "Customer Biometric Login Module". Under Quality Specifications, the Project Manager writes: "The login screen must be intuitive, modern, user-friendly, and load quickly without confusing the customer." Under Quality Method, the Project Manager writes: "Informal walkthrough by the development team."

Practitioner Evaluation:

• Governance Flaw: The Quality Specifications are completely subjective, qualitative, and unmeasurable. Vague terms like "intuitive", "modern", and "load quickly" make objective quality verification impossible.
• Impact: When the product is delivered, the Senior User and the developer will inevitably dispute whether the module is acceptable. Furthermore, an "informal walkthrough by the development team" lacks independence and objective validation.
• Correct PRINCE2 Action: The criteria must be reformulated into quantifiable specifications: "Login screen renders within 1.2 seconds on 4G mobile connections; biometric recognition accuracy rate ≥ 99.8%; zero accessibility contrast errors under WCAG 2.1 AA." The Quality Method must specify objective user testing with documented pass/fail metrics, reviewed by an independent quality reviewer.

Scenario C: The Missing External Product on the PFD

On an automated medical laboratory project, the Project Manager constructs a Product Flow Diagram showing: "Automated Centrifuge Assembly" ──► "Diagnostic Software Calibration" ──► "Clinical Pilot Run". The Project Manager omits the "National Health Ministry Regulatory Operating License", arguing that because the license is granted by an independent government agency, it is an external legal matter that should not clutter the project's internal technical flow.

Practitioner Evaluation:

• Governance Flaw: External products must always be included on the Product Flow Diagram as predecessor dependencies.
• Impact: Diagnostic calibration and clinical pilot runs cannot legally or practically occur without the government operating license. By omitting this external product from the PFD, the Project Manager failed to derive the activities needed to apply for, track, and secure the license, resulting in a schedule that will stall indefinitely waiting for regulatory sign-off.
• Correct PRINCE2 Action: The "National Health Ministry Regulatory Operating License" must be added to the PFD as an External Product with a dependency arrow feeding directly into "Clinical Pilot Run".

---

9. Practitioner Exam Pitfalls & Governance Traps

• Trap 1: Activity Verbs in the PBS or PFD: Whenever an exam option includes active verbs (e.g., "Design database", "Train users", "Deploy code") inside a Product Breakdown Structure or Product Flow Diagram, that option is wrong under PRINCE2 rules. Look for product nouns ("Database Design Document", "Trained Users", "Deployed Code").
• Trap 2: Confusing Quality Specifications with Quality Tolerances: Quality Specifications define the target standard (e.g., "Weight: 10.0 kg"). Quality Tolerances define the permissible variance around that standard (e.g., "±0.5 kg"). Exam distractors often claim that quality specifications must be absolute with zero variance permitted, ignoring the role of quality tolerances.
• Trap 3: Omitting External Products: Candidates frequently assume external dependencies belong only in the Risk Register. In PRINCE2, external products must appear explicitly on both the PBS and PFD.
• Trap 4: Conflating Producer, Reviewer, and Approver: A Product Description must clearly segregate quality responsibilities. The Producer builds it; the Reviewer verifies quality compliance; the Approver (usually representing the Senior User or Senior Supplier) holds the formal authority to sign off and baseline the product.