4.5 Product-Based Planning Technique

4.5 Product-Based Planning Technique

A core principle of PRINCE2 is Focus on products. In traditional project management, planning often starts by asking What activities do we need to perform? PRINCE2 flips this perspective: project planning must begin by identifying and defining the tangible and intangible products (deliverables) required to achieve the project objectives. Only after products are fully defined and agreed upon are the necessary activities, resources, dependencies, and schedules derived.

The Product-Based Planning Technique is a structured, step-by-step approach that ensures complete scope clarity, reduces the risk of missed requirements, aligns stakeholder expectations regarding quality, and provides a solid baseline for estimating effort and cost.

---

Rationale and Benefits of Product-Based Planning

Activity-based planning carries inherent risks. When teams jump straight into listing tasks and constructing Gantt charts without defining output criteria, they frequently suffer from scope creep, ambiguous quality standards, and optimistic duration estimates.

Why Product-Based Planning Works

• Scope Clarity: By focusing on deliverables rather than tasks, all stakeholders gain a shared, unambiguous understanding of what the project will produce.
• Quality Integration: Quality criteria and inspection methods are embedded into product definitions upfront rather than added as an afterthought.
• Improved Estimation: Estimating the effort to produce a fully specified product is far more accurate than estimating abstract activity durations.
• Clear Accountability: Every product has a designated producer, reviewer, and approver, eliminating confusion over deliverable ownership.
• Enhanced Stakeholder Engagement: Business sponsors and users understand products (e.g., an automated payment portal) far better than technical activity lists (e.g., writing API endpoints).

---

The Four Steps of Product-Based Planning (+ Step 5)

PRINCE2 7 details four formal steps in the Product-Based Planning technique, followed by activity derivation to create the final schedule.

┌─────────────────────────────────────────────────────────────┐
│ Step 1: Design the Plan                                     │
│ (Select presentation format, layout, tools, and standards)  │
└──────────────────────────────┬──────────────────────────────┘
                               │
┌──────────────────────────────▼──────────────────────────────┐
│ Step 2: Write the Project Product Description (PPD)          │
│ (Define overall product, customer quality expectations, DoD) │
└──────────────────────────────┬──────────────────────────────┘
                               │
┌──────────────────────────────▼──────────────────────────────┐
│ Step 3: Create the Product Breakdown Structure (PBS)        │
│ (Decompose total project scope into sub-products)            │
└──────────────────────────────┬──────────────────────────────┘
                               │
┌──────────────────────────────▼──────────────────────────────┐
│ Step 4: Write Product Descriptions (PDs)                    │
│ (Specify composition, quality criteria, tolerances, methods)│
└──────────────────────────────┬──────────────────────────────┘
                               │
┌──────────────────────────────▼──────────────────────────────┐
│ Step 5: Create the Product Flow Diagram (PFD)               │
│ (Map logical dependencies, sequence, and delivery flow)     │
└─────────────────────────────────────────────────────────────┘

---

Step 1: Design the Plan

Before listing deliverables, the Project Manager must determine how the plan will be structured and presented to suit the audience and organizational standards.

• Key Considerations:
  • Audience needs (e.g., executive summary graphics for Project Board vs. detailed Gantt/Kanban for delivery teams).
  • Planning tools and software (e.g., MS Project, Jira, Primavera, or visual mapping tools).
  • Estimating units (e.g., story points, person-days, financial cost blocks).
  • Alignment with corporate or programme planning templates.

---

Step 2: Write the Project Product Description (PPD)

The Project Product Description (PPD) represents the overall primary deliverable of the project (e.g., New Online Banking Platform).

• Timing: Drafted in Starting up a project (SU) by the Project Manager on behalf of the Executive, and refined in Initiating a project (IP).
• Purpose: Establishes the high-level boundary of project scope and defines what must be delivered for the customer to accept the project.
• Core Components of a PPD:
  1. Title & Purpose: What the overall product is and why it is being created.
  2. Composition: High-level summary of major components.
  3. Customer Quality Expectations: Broad expectations regarding usability, performance, reliability, and security.
  4. Acceptance Criteria: A prioritized, measurable list of target attributes that the final product must meet before customer sign-off (often prioritized using MoSCoW: Must have, Should have, Could have, Won't have for now).
  5. Project-level Quality Tolerances: Acceptable variances in overall product performance or operational targets.
  6. Acceptance Responsibilities: Who is responsible for reviewing and formally accepting the final product (typically the Senior User).

Worked Example: PPD Snapshot for an E-Commerce Portal Migration

---

Step 3: Create the Product Breakdown Structure (PBS)

The Product Breakdown Structure (PBS) is a hierarchical decomposition diagram that breaks down the overall project product (defined in the PPD) into its constituent sub-products.

Rules for Building a PBS

1. Nouns Only: Every item in a PBS must be a product (a noun or outcome phrase). Never use verbs or activities in a PBS (e.g., use User Training Documentation, NOT Write user manual).
2. Hierarchy: The top node is the Project Product. Each level below decomposes the parent product into child products.
3. Product Classification: A complete PBS includes three distinct types of products:

Example PBS Hierarchy (ASCII Representation)

                       [ Global Omnichannel Platform ] (Project Product)
                                      │
        ┌─────────────────────────────┼─────────────────────────────┐
        │                             │                             │
 [ Management Products ]    [ Specialist Products ]       ( External API ) [External]
        │                             │
  ├─ PID                       ├─ Platform Software
  ├─ Stage Plans               │   ├─ Database Schema
  └─ Quality Register          │   ├─ Microservices API
                               │   └─ Mobile UI Component
                               │
                               └─ User Enablement
                                   ├─ Admin User Manual
                                   └─ Operational Training Module

Exam Tip: Remember that External Products are items the project depends upon, but the project team does NOT produce them. They are included in the PBS to ensure their quality criteria and arrival dates are tracked, but they do not have internal Work Packages assigned to create them.

---

Step 4: Write Product Descriptions (PDs)

Once the PBS is constructed, individual Product Descriptions (PDs) are written for products identified in the PBS. (While every specialist product requires a PD, simple or generic products may be grouped into a single PD to avoid excessive paperwork).

Comprehensive Structure of a Product Description

---

Step 5: Create the Product Flow Diagram (PFD)

The Product Flow Diagram (PFD) maps the logical sequence, dependencies, and delivery flow of the products defined in the PBS.

• How it Works: Products are represented as nodes, connected by directional arrows showing which products must be completed before subsequent products can be created.
• Entry Points: External products and baseline inputs appear at the start of the flow diagram.
• Exit Points: The final Project Product appears at the end of the flow.

 ( External API Spec ) ───┐
                          ├───► [ Microservices API ] ───┐
 [ Database Schema ]  ────┘                              ├───► [ Mobile UI Component ] ───► [ Integrated Platform ]
                                                         │
 [ Admin User Manual ] ──────────────────────────────────┘

---

From Products to Activities and Schedules

Once the PFD is completed, the Project Manager derives the required activities needed to transform inputs into finished products:

1. Activity Derivation: For each product in the PFD, identify the specific tasks required to produce, review, and approve it.
2. Estimating: Estimate effort, duration, and resource requirements for each activity based on the Product Description details.
3. Scheduling: Apply activity dependencies (from the PFD) to build network diagrams, Gantt charts, resource histograms, and establish the Critical Path.

---

Product-Based Planning in Agile Contexts

Product-based planning aligns perfectly with modern agile frameworks (such as Scrum, Kanban, and SAFe):

• PBS to Product Backlog: The PBS translates directly into a Product Backlog hierarchy (Epics -> Features -> User Stories).
• Product Descriptions to User Stories: A Product Description maps to a User Story enriched with Acceptance Criteria and the Definition of Done (DoD).
• PFD to Release Planning: The PFD provides the dependency structure needed to sequence user stories across Sprints and Release Roadmaps.

---

Roles and Governance in Product-Based Planning