13.2 Managing Product Delivery (MP) Process: Work Packages & Checkpoints

Managing Product Delivery (MP) Process: Work Packages & Checkpoints in PRINCE2 7

Practitioner Core Mandate: In professional project management, there is a fundamental distinction between managing a project and building its deliverables. The Project Manager oversees overall governance, stage plans, budgets, risks, and stakeholder communication. However, the physical deliverables—whether lines of software code, architectural blueprints, civil infrastructure, or pharmaceutical test batches—are generated by specialist teams. The Managing Product Delivery (MP) process establishes the formal interface between project management and specialist craftsmanship. Governed from the Team Manager's perspective, MP ensures that specialist work is formally agreed, executed to rigorous quality standards, and delivered with absolute transparency.

---

1. Purpose, Objectives & Context of Managing Product Delivery (MP)

The Fundamental Purpose of MP

The purpose of the Managing Product Delivery (MP) process is to control the link between the Project Manager and the Team Manager(s), by agreeing the requirements for acceptance, execution, and delivery.

Core Governance Objectives

The MP process satisfies several vital operational objectives during delivery stages:

• Ensure Authorization: Guarantee that specialist work is only undertaken when formally authorized and agreed via an approved Work Package.
• Clarity of Expectations: Ensure that Team Managers, specialist team members, and external suppliers have an unambiguous understanding of what products must be created, their quality specifications, the effort and budget available, and any technical constraints.
• Quality Compliance: Ensure that deliverables are produced in strict accordance with their baselined Product Descriptions and that all defined quality control activities (testing, inspections, peer reviews) are executed.
• Transparent Reporting: Provide accurate, objective, time-driven progress data upward to the Project Manager via Checkpoint Reports.
• Controlled Handover: Ensure that completed specialist products obtain formal approval from authorized approvers before being handed over to the Project Manager or operational environment.

                  THE MANAGING PRODUCT DELIVERY (MP) LIFECYCLE

   PROJECT MANAGER (CS)                      TEAM MANAGER / SPECIALISTS (MP)

   ┌───────────────────────┐                 ┌─────────────────────────────┐
   │ Authorize Work Package│────────────────►│ 1. ACCEPT A WORK PACKAGE    │
   │ (Proposes WP terms)   │                 │    • Evaluate feasibility   │
   │                       │◄────────────────│    • Agree scope/tolerances │
   │                       │  Agreement      │    • Align Team Plan        │
   └───────────────────────┘                 └──────────────┬──────────────┘
                                                            │
                                                            ▼
   ┌───────────────────────┐                 ┌─────────────────────────────┐
   │                       │                 │ 2. EXECUTE A WORK PACKAGE   │
   │                       │                 │    • Coordinate specialists │
   │                       │                 │    • Run quality activities │
   │                       │                 │    • Create the products    │
   └───────────────────────┘                 └──────────────┬──────────────┘
                                                            │
                                                            ▼
   ┌───────────────────────┐                 ┌─────────────────────────────┐
   │ Evaluate WP Status    │◄────────────────│ 3. EVALUATE A WORK PACKAGE  │
   │ (16.4.2, reads them)  │   Checkpoint    │    • Assess progress and    │
   │                       │   Reports       │      quality results        │
   │                       │                 │    • Monitor WP tolerances  │
   └───────────────────────┘                 └──────────────┬──────────────┘
                                                            │
                                                            ▼
   ┌───────────────────────┐                 ┌─────────────────────────────┐
   │ Receive Completed WP  │◄────────────────│ 4. NOTIFY WP COMPLETION     │
   │ (16.4.3, verifies)    │   Completed WP  │    • Secure product approval│
   │                       │   Notice        │    • Update the team plan   │
   └───────────────────────┘                 └─────────────────────────────┘

The Perspective of the Team Manager

While all other PRINCE2 processes are viewed primarily from the perspective of the Project Board or Project Manager, Managing Product Delivery is unique: it is viewed from the perspective of the Team Manager:

• Internal Specialist Teams: A Team Manager may be an internal organizational lead (e.g., Lead Systems Architect, Civil Site Foreman, Head of UX Design).
• External Commercial Suppliers: In commercial environments, the Team Manager is often a vendor's Project Manager, Contractor Account Lead, or Service Delivery Manager operating under an external commercial contract.
• Agile Delivery Teams: In agile environments, the Team Manager role may be fulfilled by a Scrum Master, Agile Coach, Product Owner, or collectively by a self-organizing delivery squad.

---

2. The Four Activities of Managing Product Delivery

PRINCE2 7 table 17.1 names four activities (17.4.1 to 17.4.4). The 6th Edition's third activity, notify work package completion, has been split into a separate evaluation step and a separate notification step:

┌─────────────────────────────────────────────────────────────────────────────┐
│            THE 4 ACTIVITIES IN MANAGING PRODUCT DELIVERY (MP)               │
├─────────────────────────────────────────────────────────────────────────────┤
│ 17.4.1 ACCEPT A WORK PACKAGE:                                               │
│    • Review the work package description to understand what and when        │
│    • Evaluate feasibility, skills, resources, constraints, and reporting    │
│    • Output: TEAM PLAN created or updated (e.g. for the agile timebox)      │
├─────────────────────────────────────────────────────────────────────────────┤
│ 17.4.2 EXECUTE A WORK PACKAGE:                                              │
│    • Coordinate day-to-day specialist production                            │
│    • Conduct quality activities per the product descriptions                │
│    • Outputs: SPECIALIST PRODUCTS created; project log updated              │
├─────────────────────────────────────────────────────────────────────────────┤
│ 17.4.3 EVALUATE A WORK PACKAGE:                                             │
│    • Assess progress and quality results against the work package and       │
│      team plan; check the project log                                       │
│    • Outputs: CHECKPOINT REPORTS created for each reporting period          │
├─────────────────────────────────────────────────────────────────────────────┤
│ 17.4.4 NOTIFY WORK PACKAGE COMPLETION:                                      │
│    • Confirm quality activities are recorded and approvals obtained         │
│    • Outputs: team plan updated; work package complete; COMPLETED WORK      │
│      PACKAGE NOTICE triggers 'receive completed work package' in CS         │
└─────────────────────────────────────────────────────────────────────────────┘

[!EXAM WATCHPOINT: MP HAS FOUR ACTIVITIES IN VERSION 7] Checkpoint reports are produced in evaluate a work package (17.4.3), not as a side-effect of execution, and the hand-back to the project manager is its own activity, notify work package completion (17.4.4). An option that says MP has three activities, or that the team manager "delivers a work package", is using 6th Edition wording.

---

3. Accepting a Work Package (17.4.1): Feasibility, Negotiation & Commitment

When a Project Manager issues a Work Package, the Team Manager does not simply sign it blindly. The activity Accept a Work Package represents a critical due diligence checkpoint.

Evaluation and Due Diligence

The Team Manager must thoroughly examine the proposed Work Package:

• Product Descriptions: Are the quality specifications, tolerances, and acceptance methods realistic and technically achievable?
• Resources & Capability: Does the team possess the necessary skills, tooling, hardware, and bandwidth during the allocated timeframe?
• Dependencies & Interfaces: Are external technical interfaces (e.g., third-party APIs, physical site conduits, vendor components) clearly defined and accessible?
• Work Package Tolerances: Are the proposed tolerances (e.g., ±2 days, ±$1,000, defect thresholds) sufficient to absorb normal technical variations?
• Reporting Requirements: Is the frequency and format of Checkpoint Reports practical and non-burdensome?

The Negotiation Dynamic

If the Team Manager determines that the requirements cannot be delivered within the stated constraints, the Team Manager must negotiate with the Project Manager before accepting the Work Package:

• "We cannot deliver these five modules in four weeks with three developers; we can deliver four modules, or we require a fourth developer, or we need a six-week timeline."
• Once mutual agreement is reached, the Work Package is baselined.

Developing or Aligning the Team Plan

Upon accepting the Work Package, the Team Manager prepares or updates a Team Plan:

• The Team Plan is an internal management tool for the Team Manager and specialists.
• It breaks down the Work Package into detailed technical tasks, daily assignments, and internal micro-milestones.
• Crucial Exam Rule: The Team Plan is optional in PRINCE2 (the TM may use agile backlogs, Kanban boards, or engineering schedules instead) and is never authorized by the Project Board. In fact, the Project Manager does not formally approve the Team Plan—the PM only reviews it to confirm that its milestones align with the overarching Stage Plan.

---

4. Executing a Work Package (17.4.2): Craftsmanship, Quality & Team Controls

During Execute a Work Package, the specialist deliverables are actively built, tested, and refined.

Day-to-Day Execution Responsibilities

The Team Manager directs the technical execution while maintaining strict control over four dimensions:

1. Technical Production: Overseeing specialist craftsmanship in compliance with the techniques, processes, and tools mandated in the Work Package.
2. Quality Control Execution: Conducting quality checks (unit testing, peer reviews, material strength inspections, usability labs) as defined in each Product Description. Recording quality results and notifying the Project Manager to update the Quality Register.
3. Tolerance Monitoring: Continuously measuring team progress against the Work Package tolerances across cost, schedule, quality, and sustainability.
4. Checkpoint Reporting: Compiling and submitting regular Checkpoint Reports to the Project Manager at the agreed intervals.

Checkpoint Reports: Anatomy and Frequency

The Checkpoint Report is the primary communication vehicle flowing upward from the Team Manager to the Project Manager:

┌─────────────────────────────────────────────────────────────────────────────┐
│                     STRUCTURE OF A CHECKPOINT REPORT                        │
├─────────────────────────────────────────────────────────────────────────────┤
│ 1. IDENTIFICATION: Work Package ID, Team Manager name, reporting period.    │
│ 2. WORK COMPLETED IN PERIOD: Products finished and quality-tested.          │
│ 3. WORK IN PROGRESS: Active technical deliverables and percent complete.    │
│ 4. QUALITY ACTIVITIES IN PERIOD: Tests performed, passes, defects logged.   │
│ 5. ISSUES & RISKS: Operational challenges, internal dependencies, threats.  │
│ 6. WORK SCHEDULED FOR NEXT PERIOD: Tasks planned for next checkpoint window.│
│ 7. TOLERANCE STATUS & FORECAST: Statement on whether Work Package tolerances│
│    (time, cost, quality, sustainability) remain protected.                  │
└─────────────────────────────────────────────────────────────────────────────┘

What Happens When Work Package Tolerances Are Threatened?

Just as the Project Manager operates within stage tolerances, the Team Manager operates within Work Package tolerances:

• If an unforeseen technical hurdle occurs (e.g., corrupted database schema, delayed raw material delivery) and the Team Manager forecasts that a Work Package tolerance will be breached, the Team Manager cannot resolve this independently.
• The Team Manager must immediately raise the issue to the Project Manager.
• The Project Manager then determines whether the variance can be absorbed using stage-level contingency, or whether an Exception Report must be submitted to the Project Board.

---

5. Evaluating a Work Package (17.4.3) and Notifying Completion (17.4.4)

The final activity in Managing Product Delivery is Notify Work Package Completion.

┌─────────────────────────────────────────────────────────────────────────────┐
│             THREE GATES TO DELIVERING A WORK PACKAGE                        │
├─────────────────────────────────────────────────────────────────────────────┤
│ GATE 1: QUALITY VERIFICATION                                                │
│ • Verify that every quality review, inspection, and test required by the    │
│   Product Description has been executed and passed.                         │
│ • Verify that defect remediation is complete and logged in Quality Register.│
├─────────────────────────────────────────────────────────────────────────────┤
│ GATE 2: FORMAL PRODUCT APPROVAL                                             │
│ • Obtain documented sign-off from the explicit approvers named in the       │
│   Product Description (e.g., Senior User, Technical Authority, Regulator).  │
├─────────────────────────────────────────────────────────────────────────────┤
│ GATE 3: HANDOVER & NOTIFICATION                                             │
│ • Transfer custody of deliverables per Work Package handover procedures     │
│   (e.g., code deployment, physical delivery to client warehouse).           │
│ • Issue formal Work Package completion notification to Project Manager.     │
└─────────────────────────────────────────────────────────────────────────────┘

Crucial Quality Rule: Designated Approvers

A common exam trap involves who has the legal authority to sign off on a product. A product cannot be approved by the Team Manager who built it (unless explicitly authorized in the Product Description). The approver is specified in the baselined Product Description during planning (e.g., Lead Operations Engineer, User Security Representative). The Team Manager must obtain documented proof of approval from these designated individuals before notifying the PM that the package is delivered.

---

6. The Work Package as a Contractual & Operational Boundary

The Work Package is the most versatile governance instrument in PRINCE2, acting as a modular bridge across diverse organizational boundaries:

6.1 The Commercial Supplier Boundary

When specialist delivery is outsourced to third-party commercial contractors:

• The Work Package serves as the operational mechanism linked directly to the commercial contract (e.g., Statement of Work, Call-Off Order, Purchase Agreement).
• It binds the external supplier to PRINCE2 governance (quality gates, Checkpoint Reports, formal change control) without requiring the supplier to understand internal PRINCE2 structures.
• Milestone sign-offs in the Work Package trigger commercial progress payments.

6.2 Tailoring for Agile Environments (Scrum, Kanban, XP)

PRINCE2 7 seamlessly embraces agile product delivery through the MP process:

                     TAILORING MP FOR AGILE DELIVERY

   PRINCE2 GOVERNANCE (PM in CS)          AGILE EXECUTION (Team in MP)

   ┌───────────────────────────┐         ┌───────────────────────────────┐
   │ Authorizes Work Package   │────────►│ SPRINT PLANNING / BACKLOG     │
   │ (Defines Sprint timebox,  │         │ • Pulls user stories          │
   │  budget, Def. of Done)    │         │ • Commits to sprint goal      │
   └─────────────┬─────────────┘         └───────────────┬───────────────┘
                 │                                       │
                 ▼                                       ▼
   ┌───────────────────────────┐         ┌───────────────────────────────┐
   │ Receives Checkpoint Data  │◄────────│ DAILY STANDUPS & BOARDS       │
   │ (Burn-down charts,        │         │ • Kanban WIP tracking         │
   │  velocity trends)         │         │ • Continuous testing (CI/CD)  │
   └─────────────┬─────────────┘         └───────────────┬───────────────┘
                 │                                       │
                 ▼                                       ▼
   ┌───────────────────────────┐         ┌───────────────────────────────┐
   │ Receives Completed WP     │◄────────│ SPRINT REVIEW & DEMO          │
   │ (Verifies DoD & PO signoff│         │ • Product Owner approves      │
   │  against Stage Plan)      │         │ • Incremental release demo    │
   └───────────────────────────┘         └───────────────────────────────┘

---

7. Practical Scenario Evaluations

Scenario A: The Supplier Scope Creep Trap

An external IT consultancy is contracted to deliver an enterprise inventory database under an authorized Work Package. During development, the client organization's Head of Logistics approaches the consultancy's lead developer and asks for an emergency export feature to be added to the interface. The developer agrees and codes the feature. When the Work Package is submitted, delivery is 2 weeks late and costs $15,000 extra. The Team Manager submits an invoice for the extra work, citing the Head of Logistics' verbal request.

Practitioner Evaluation:

• Governance Flaw: Severe violation of the Manage by Exception principle and Managing Product Delivery protocols.
• Consequences: The Head of Logistics had zero authority to modify the Work Package. Under PRINCE2, scope changes can only be authorized via formal change control. The supplier developer executed unapproved work, resulting in a tolerance breach.
• Correct PRINCE2 Action: In Managing Product Delivery, the Team Manager must enforce the boundaries of the authorized Work Package. When the Head of Logistics requested the feature, the Team Manager should have captured the request as a Request for Change (RFC) and directed the stakeholder to the Project Manager. The Team Manager cannot alter the Work Package scope without a formal amendment authorized by the Project Manager.

Scenario B: Agile Team Bypassing Quality Acceptance

A fintech startup uses Scrum inside Managing Product Delivery. At the end of Sprint 4, the Scrum Master declares the sprint complete because all 12 user stories were coded and moved to 'Done' on the virtual Jira board. The Project Manager discovers that the security encryption reviews specified in the Product Description's quality specifications were skipped because the team prioritized feature velocity. The Scrum Master claims that agile autonomy permits the team to waive formal quality specifications.

Practitioner Evaluation:

• Governance Flaw: Total misunderstanding of how agile integrates with PRINCE2. Agile provides execution flexibility; it does not grant license to abandon baselined quality standards.
• Consequences: The software exposes customer financial data to unencrypted transmission, creating catastrophic regulatory and financial liability.
• Correct PRINCE2 Action: In Managing Product Delivery, the activity Notify Work Package Completion requires that all products satisfy the quality specifications defined in their Product Descriptions and pass the Definition of Done. The Project Manager must refuse to receive the Work Package until mandatory security reviews are completed and documented in the Quality Register.

Scenario C: The Silent Tolerance Breach by a Team Manager

On a commercial construction project, a specialist steel fabrication Team Manager experiences a 5-day delay due to welding equipment breakdowns. The Work Package time tolerance agreed with the PM was ±2 days. Believing the team can make up the lost time by working overtime during the final assembly stage, the Team Manager omits the breakdown from the weekly Checkpoint Report and marks the forecast schedule as 'On Track'. Two weeks later, the delay cascades into a 12-day stoppage on the critical path, halting concrete pouring across the entire site.

Practitioner Evaluation:

• Governance Flaw: Breach of reporting integrity and failure to escalate within Execute a Work Package.
• Consequences: By concealing the tolerance breach, the Team Manager prevented the Project Manager from taking early corrective action (e.g., re-sequencing other trades or re-allocating crane access), turning a manageable 3-day net delay into a massive site-wide stoppage.
• Correct PRINCE2 Action: The moment the Team Manager forecasts that a Work Package tolerance will be exceeded, the TM has a professional duty under PRINCE2 to raise the issue immediately to the Project Manager. Checkpoint Reports must reflect truthful progress and transparent tolerance forecasts.

---

8. Responsibilities in MP: The RACI Chart and Practice Application

Table 17.2 — RACI for managing product delivery

Key: A Accountable · R Responsible · C Consulted · I Informed. The business layer, project executive, senior user, and senior supplier have no entries at all in this table.

Why the table is so short

Managing product delivery is the only process written from the team manager's perspective, and the RACI chart shows it plainly: the team manager is Responsible for all four activities and the project manager is Accountable for all four. Nobody on the project board appears anywhere in the table.

Two consequences the exam tests:

1. A team manager never reports to the project board. Checkpoint reports go to the project manager, and escalation beyond work package tolerance goes to the project manager, who decides whether it becomes a stage-level issue. An option routing a team manager's concern straight to the senior supplier or the project executive is wrong regardless of how urgent the scenario makes it sound.
2. Accountability stays with the project manager even for work performed by an external supplier. Commercial arrangements change who does the work, not who answers for it inside the PRINCE2 structure.

How the practices are applied in MP (table 17.3)

Plans supplies the team plan and the work package description; quality supplies the product descriptions and the quality activities whose results are recorded in the quality register; risk and issues require the team manager to capture and escalate what cannot be absorbed within the work package; progress produces the checkpoint reports at the frequency set in the work package description; organizing defines the team structure delivering the package; business case rarely touches MP directly, which is exactly why a team manager must escalate rather than trade scope unilaterally.

---

9. Practitioner Exam Pitfalls & Governance Traps

• Trap 1: Believing the Team Manager Reports Directly to the Project Board: In PRINCE2, the Team Manager reports exclusively to the Project Manager via Checkpoint Reports. The Team Manager has no direct reporting relationship to the Project Board.
• Trap 2: Commencing Specialist Work Before Work Package Acceptance: Specialist teams cannot begin physical work based on verbal conversations, draft designs, or informal requests. Delivery commences only after formal acceptance of an authorized Work Package.
• Trap 3: Confusing Work Package Tolerances with Stage Tolerances: Work Package tolerances are allocated by the Project Manager to the Team Manager. Stage tolerances are allocated by the Project Board to the Project Manager. A Team Manager cannot breach Work Package tolerances without escalating to the PM, even if the stage as a whole has plenty of buffer.
• Trap 4: Assuming Checkpoint Reports are Shared with the Project Board: Checkpoint Reports are internal management documents between the TM and the PM. The Project Board receives Highlight Reports, which aggregate information from across all Checkpoint Reports and stage logs.
• Trap 5: Believing Agile Replaces Managing Product Delivery: Agile delivery techniques (Scrum, Kanban, DSDM) operate inside the Managing Product Delivery process; they do not replace it. The Work Package frames the sprint or release, maintaining governance while preserving agile execution freedom.