2.6 Principle 6: Focus on Products

2.6 Principle 6: Focus on Products

Many failed projects start with enthusiasm by listing activities: "We need to hold workshops, write code, build walls, and conduct testing." However, focusing primarily on activities creates a major risk: team members become absorbed in being busy without a clear, shared understanding of what they are supposed to produce or what quality standards the final output must meet. This leads to scope creep, misunderstandings, and rework.

PRINCE2 Principle 6: Focus on Products mandates that a project must define and clarify its deliverables—including their quality requirements—before activity planning begins.

PRINCE2 Principle Rule: A PRINCE2 project focuses on the definition and delivery of products, particularly their quality requirements.

---

Product-Oriented vs. Activity-Oriented Planning

In PRINCE2, a product is defined as an input or output artifact that can be described, measured, and verified. Products can be physical objects (a building, a server), digital assets (software, databases), documents (a training manual), or operational capabilities.

POOR PRACTICE (Activity-Oriented):   List Tasks -> Assign People -> Execute -> Hope Output Meets Needs
PRINCE2 PRACTICE (Product-Oriented): Define Product & Quality -> Identify Steps -> Schedule Tasks -> Verify Quality

Why Focus on Products First?

1. Clear Stakeholder Expectations: Writing a detailed Product Description ensures the Business, User, and Supplier agree on product features and quality criteria before work starts.
2. Prevents Scope Creep: Unplanned features cannot be sneaked in without updating the Product Description.
3. Objective Quality Acceptance: Quality criteria provide unambiguous pass/fail test standards for product approval.
4. Accurate Effort Estimation: It is much easier to estimate the time and cost required to build a well-defined product than an abstract activity.

---

Classification of Products: Specialist vs. Management

PRINCE2 classifies all project products into two distinct categories:

+-----------------------------------------------------------------------------------+
|                             TWO TYPES OF PRODUCTS                                 |
+-----------------------------------------------------------------------------------+
|  1. SPECIALIST PRODUCTS | Deliverables created to satisfy customer requirements   |
|                         | (e.g., Software module, clinical report, building)    |
|  2. MANAGEMENT PRODUCTS | Artifacts created to manage, govern, and control project  |
|                         | (e.g., Business Case, PID, Risk Register, Highlight)    |
+-----------------------------------------------------------------------------------+

1. Specialist Products

• The tangible or intangible outputs that form the final deliverable for the customer.
• Examples: A new hospital wing, an e-commerce website, a staff training course curriculum.
• Developed primarily by Team Managers and specialist team members during delivery stages.

2. Management Products

• Artifacts used by the project management team to plan, monitor, control, and communicate during the project.
• Managed by the Project Manager, Project Board, and Team Managers.
• Management products are sub-divided into three types:
  • Baseline Products: Management products that define the project targets and are subject to formal change control once approved (e.g., Business Case, Project Plan, PID, Product Descriptions).
  • Records: Dynamic logs maintained to track project variables (e.g., Risk Register, Issue Register, Lessons Log, Daily Log).
  • Reports: Management summaries used to communicate status and performance (e.g., Highlight Report, Exception Report, End Stage Report, End Project Report).

---

Key Tools of Product-Based Planning

PRINCE2 defines a specific technique called Product-Based Planning that executes in four sequential steps:

[Step 1: Project Product Description] 
              │
              ▼
[Step 2: Product Breakdown Structure (PBS)] 
              │
              ▼
[Step 3: Individual Product Descriptions] 
              │
              ▼
[Step 4: Product Flow Diagram (PFD)]

1. Write Project Product Description

• Created during Starting up a Project.
• Defines the overall outcome, customer quality expectations, and acceptance criteria for the entire project.

2. Create Product Breakdown Structure (PBS)

• A hierarchical tree diagram that decomposes the project outcome into major products and sub-products.
• Contains only products (nouns), never activities (verbs).

3. Write Product Descriptions

• Detailed specifications created for every major product listed in the PBS.
• A standard PRINCE2 Product Description includes:
  • Title & Purpose: What is the product and why is it needed?
  • Composition: What sub-components make up this product?
  • Derivation: What source materials or inputs are needed to build it?
  • Quality Criteria: What measurable standards must the product satisfy?
  • Quality Tolerances: What variance is acceptable in quality criteria?
  • Quality Method: How will the product be tested/verified?
  • Quality Skills & Responsibilities: Who builds, checks, and approves it?

4. Create Product Flow Diagram (PFD)

• A visual flowchart showing the sequence of production and dependencies between products.
• Only after the PFD is complete does the Project Manager identify tasks, estimate durations, and construct Gantt schedules.

---

Quality Criteria and Customer Acceptance

Without explicit quality criteria, handover from Supplier to User often results in disputes over whether a product is "finished."

In PRINCE2:

• Quality Criteria defined in Product Descriptions serve as objective acceptance tests.
• Senior User signs off on User acceptance based strictly on whether products meet agreed quality criteria.
• Executive accepts the project outputs based on fulfilled Business Case justification.

---

Comparison Table: Activity-Focused vs. Product-Focused Management