Study guide
12.4 Work Packages & Reporting Cycle
PRINCE2 Practitioner Version 7
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
1.1 Current Exam Facts 1.2 Exam Strategy & Open-Book Technique
2 PRINCE2 7 Method Overview
2.1 The PRINCE2 7 Method 2.2 What Changed in PRINCE2 7 2.3 Performance Targets, Tolerances & Project Context
3 PRINCE2 Principles (1–4)
3.1 Continued Business Justification 3.2 Learn from Experience 3.3 Defined Roles, Responsibilities & Relationships 3.4 Manage by Stages
4 PRINCE2 Principles (5–7) & Applying Principles
4.1 Manage by Exception 4.2 Focus on Products 4.3 Tailor to Suit the Project 4.4 Applying Principles in Context
5 People Management in Projects
5.1 Organisational & Project Ecosystems 5.2 Leadership in Projects 5.3 Team Culture & Diversity 5.4 Communication, Stakeholder Engagement & Change Management
6 Practices Overview & Business Case
6.1 The Seven Practices & Tailoring 6.2 Business Case: Desirability, Viability & Achievability 6.3 Business Case Lifecycle & Management Products 6.4 Business Case Application & Tailoring Scenarios
7 Practices: Organising & Plans
7.1 Organising: Roles & Accountability 7.2 Organising: 5-Step Ecosystem Technique 7.3 Plans: Three Levels & Product-Based Planning 7.4 Plans: Techniques, Tolerances & Tailoring
8 Practices: Quality & Risk
8.1 Quality: Planning, Control & Assurance 8.2 Quality Techniques & Management Products 8.3 Risk: Threats & Opportunities 8.4 Risk 5-Step Technique & Application
9 Practices: Issues
9.1 Issues Practice: Issue vs Change & Categories 9.2 Issues 5-Step Technique & Supporting Techniques 9.3 Change Control, Configuration & Priority/Effort Assessment
10 Practices: Progress, Sustainability & Application
10.1 Progress: Controls, Tolerances & Reports 10.2 Sustainability as the 7th Performance Target 10.3 Tailoring the Practices 10.4 Practices Application Scenarios (BL4)
11 Processes: Model, Starting, Directing & Initiating
11.1 The Seven Processes & Process Model 11.2 Starting Up a Project 11.3 Directing a Project 11.4 Initiating a Project
12 Processes: Controlling a Stage & Product Delivery
12.1 Controlling a Stage 12.2 Managing Product Delivery 12.3 Stage Control & Exception Scenarios (BL4) 12.4 Work Packages & Reporting Cycle
13 Processes: Stage Boundary, Closing & Tailoring
13.1 Managing a Stage Boundary 13.2 Closing a Project 13.3 Tailoring the Processes 13.4 Process Application Scenarios (BL4)
14 Tailoring, Management Products & Exam Technique
14.1 Tailoring to Project Environment, Scale & Agile 14.2 Management Products & the v7 Project Log 14.3 Final Exam Technique, Full Scenarios & Common Traps
12.4 Work Packages & Reporting Cycle
Key Takeaways Explain This Topic AI
The Work Package lifecycle is: PM authorises → Team Manager accepts → Team Manager executes (with quality checks) → Team Manager delivers (obtains acceptance) → PM receives the completed Work Package.
Tolerances flow downward: project tolerance (board) → stage tolerance (board sets at stage authorisation) → Work Package tolerance (PM sets for the Team Manager).
The reporting cycle connects the two processes: Checkpoint Reports flow Team Manager → PM; Highlight Reports flow PM → Project Board; both are time-driven.
The PM does not manage team members directly — the Team Manager does, via the Work Package. The PM manages the stage, not the specialists.
Last updated: August 2026
The Work Package is the single most important management product for joining Controlling a Stage and Managing Product Delivery . It is both the instruction the PM gives to a Team Manager and the agreement that binds both sides while the work is done. Understanding its lifecycle — and the reporting cycle that runs alongside it — is essential for Practitioner scenarios that ask "what happens next?" or "who owns this product now?"
The Work Package lifecycle
The lifecycle has five steps. The first and last belong to the PM (under Controlling a Stage); the middle three belong to the Team Manager (under Managing Product Delivery).
Step Owner Process What happens
1. Authorise Project Manager Controlling a Stage PM issues the Work Package, setting Product Descriptions, tolerances, quality methods, reporting frequency, and constraints
2. Accept Team Manager Managing Product Delivery Team Manager confirms the Work Package is understood and achievable, negotiates if needed, and commits
3. Execute Team Manager Managing Product Delivery Team Manager plans the work, develops the products, performs quality checks, produces Checkpoint Reports
4. Deliver Team Manager Managing Product Delivery Team Manager obtains acceptance against the Product Descriptions and returns the completed products
5. Receive Project Manager Controlling a Stage PM confirms acceptance, integrates the products into the stage, updates the Stage Plan and Quality Register
A common exam trap is to compress steps 4 and 5 into a single 'handover'. They are distinct: in step 4 the Team Manager obtains acceptance and returns the products; in step 5 the PM receives the completed Work Package and integrates it. Until acceptance in step 4, the product is the Team Manager's responsibility; after step 5, it is the PM's.
The reporting cycle
The reporting cycle is the nervous system of the two processes. Two time-driven reports keep information flowing:
Checkpoint Report — flows from Team Manager → PM at the frequency set in the Work Package. It covers work completed, work planned next, issues and risks for the Work Package, and the Work Package tolerance position. The PM consumes it during assess progress in Controlling a Stage.
Highlight Report — flows from PM → Project Board at the frequency set in the Communication Management Approach. It summarises stage status, the tolerance position, issues and risks that the board needs to know about, and any decisions needed. It is the board's routine view of the stage; the Exception Report is the non-routine escalation.
Both reports are time-driven , meaning they are produced on a cadence (weekly, fortnightly, at the end of each sprint) regardless of whether anything notable has happened. This is deliberate: a quiet Highlight Report is itself a signal that the stage is on track. Event-driven reports in this part of PRINCE2 are the Issue Report, Risk update, and Exception Report — each is produced because something happened.
- Report From → To Driver Source of frequency
- Checkpoint Report Team Manager → PM Time Work Package
- Highlight Report PM → Project Board Time Communication Management Approach
- Issue Report Anyone → PM Event Issue Register
- Exception Report PM → Project Board Event Forecast tolerance breach
- The tolerance cascade
Tolerances in PRINCE2 flow downward, and exceptions flow upward. The cascade is precise:
Project tolerance — set by corporate/programme management (or the Project Board if there is no higher layer) and recorded in the Project Plan. It defines the limits within which the Project Board may operate without referring back.
Stage tolerance — set by the Project Board when it authorises each stage (the output of Managing a Stage Boundary ). It is a slice of the project tolerance delegated to the PM for that stage.
Work Package tolerance — set by the PM for each Work Package issued under Controlling a Stage. It is a slice of the stage tolerance delegated to the Team Manager.
If a Team Manager forecasts a Work Package tolerance breach, the Team Manager raises an Issue to the PM. The PM then decides whether the breach can be absorbed within the stage tolerance (corrective action under Controlling a Stage) or whether the stage tolerance itself is now forecast to be breached (Exception Report to the Project Board). The Team Manager never raises an Exception Report — that act belongs to the PM, because the PM is the person who holds the stage tolerance.
Who manages the team?
A rule that appears repeatedly in Practitioner questions is that the PM does not manage team members directly. The PM manages the stage ; the Team Manager manages the team , via the Work Package. This is why the Work Package exists: it is the mechanism by which the PM directs work without becoming the line manager of the specialists. If a team member is underperforming, the PM raises it with the Team Manager (perhaps as an Issue); the Team Manager handles it. If a specialist product needs rework, the PM returns it to the Team Manager; the PM does not pick up the tools.
This separation is what makes PRINCE2 scalable to large projects. On a small project, the PM and Team Manager may be the same person, but the roles remain distinct — the PM still authorises a Work Package to the Team Manager, even if both hats are on the same head. The Practitioner exam rewards candidates who can name the role that owns each step, not the individual who happens to perform it.
Putting it together: a single cycle
Picture one full turn of the cycle. The PM authorises a Work Package. The Team Manager accepts it and begins execution, producing Checkpoint Reports each week. The PM reads them, assesses progress, and at the end of the month sends a Highlight Report to the Project Board. The board governs by exception — it does not respond unless the Highlight Report flags a tolerance concern or an Exception Report arrives. The Team Manager finishes the products, quality-checks them against the Product Descriptions, obtains acceptance, and delivers them back. The PM receives the completed Work Package, updates the Stage Plan, and the cycle begins again with the next Work Package. That is one heartbeat of Controlling a Stage and Managing Product Delivery working together.