KEVOS
ArticlesServicesCase studiesAboutContact
ArticlesServicesCase studiesAboutContact
← ArticlesManaging Product Delivery Process in PRINCE2 2017Project Delivery · Planning & SchedulingLesson 18/22← PrevNext →
GuidePublished 13 Aug 20267 min readBy KEVOSPRINCE2 2017Managing Product Deliveryteam managerwork package
On this page

Ask about this page

KEVOS AIManaging Product Delivery Process in PRINCE2 2017

KEVOS knowledge first · trusted web sources when needed

Project Delivery · Project Control Methods

Managing Product Delivery Process in PRINCE2 2017

Create a clean contract between project management and specialist delivery: accept an achievable Work Package, execute it using the agreed methods and quality controls, provide accurate progress information and return approved products.

PRINCE2 2017 source scopeApprox. 7 min readHandbook guide
Source scope: This page is derived from the supplied 2017 training/reference material and related sample-assessment material. It is intentionally scoped to that edition. It does not claim to describe later revisions, current examination rules or requirements not present in the supplied source.

Executive summary

Team perspective

Managing Product Delivery mirrors Controlling a Stage from the specialist delivery side of the Project Manager–Team Manager interface.

Three activities

Accept a Work Package, execute a Work Package and deliver a Work Package.

Quality is part of delivery

Products are developed using agreed methods, checked against Product Description quality criteria and approved by the identified authority before delivery.

External suppliers can fit

The process defines the required project-management interface even when an external supplier uses a different internal delivery method.

Purpose and management interface

Managing Product Delivery controls the link between the Project Manager and Team Manager by agreeing the requirements for acceptance, execution and delivery of specialist work. The Team Manager can be internal or external to the customer organisation and coordinates an area of work that produces one or more project products.

The process does not tell specialists how to perform their craft. Instead, it establishes the contract between project control and technical execution. The Project Manager needs confidence that authorised products will be delivered within agreed constraints; the Team Manager needs a clear statement of products, quality expectations, interfaces, resources, tolerances and reporting requirements.

This separation allows specialist teams to use appropriate technical methods while still fitting into project governance. It also makes responsibility clearer when external suppliers operate their own management systems.

Relationship with Controlling a Stage

Controlling a Stage is written from the Project Manager’s perspective: authorise work, monitor status, receive products and control the overall stage. Managing Product Delivery is the corresponding Team Manager view: accept authorised work, manage execution and deliver completed products.

The two processes should therefore be designed together. A Checkpoint Report that is useful to the Project Manager must be feasible for the team to produce. Work Package tolerance must be meaningful at team level. Product acceptance responsibilities in the Product Description must be accessible to the people who actually perform the review.

If the same person performs both Project Manager and Team Manager roles on a very small project, the source still supports use of Work Packages. This maintains the distinction between “management of the stage” and “performance of the specialist work” even when organisational separation is minimal.

InterfaceProject Manager sideTeam Manager side
Work authorisationCreates and authorises Work Package.Reviews and accepts Work Package.
ProgressReviews Checkpoint and team status.Monitors execution and provides Checkpoint information.
ToleranceSets Work Package tolerance within stage authority.Manages within tolerance and raises forecast deviations.
QualitySpecifies/controls Product Description and required records.Performs specified methods and obtains required approvals.
CompletionReceives completed Work Package/products.Delivers approved products and completion information.

Activity 1 — accept a Work Package

Acceptance is more than acknowledging receipt. The Team Manager should check that the products, constraints, expected effort/cost/timescale, dependencies, interfaces, quality methods, reporting requirements and tolerance are understood and achievable.

Where the team needs a Team Plan, it can be prepared to show how the Work Package will be executed. The source allows this plan to range from a simple schedule appended to the Work Package to a more fully developed plan similar in style to a Stage Plan. Formality should reflect complexity and supplier context.

Before accepting, challenge missing inputs and unrealistic assumptions. If the Work Package depends on an external product that has no confirmed availability, accepting it without qualification creates false commitment. The Project Manager and Team Manager should resolve the constraint or record the dependency and associated risk.

Acceptance protects both sides

A clear Work Package agreement prevents later disputes about whether scope, quality, dates or constraints were ever understood. The form can be lightweight, but the commitment should be explicit.

Activity 2 — execute a Work Package

During execution, the Team Manager coordinates team members and suppliers, maintains the interfaces specified in the package and ensures the agreed development methods are followed. The Team Plan, if used, provides the working schedule and resource view.

Quality is built into execution. Each product should be developed according to its Product Description and checked through the specified quality methods. The Team Manager ensures required reviews, inspections or tests occur and that the identified approval authority approves completed products. Quality evidence should be available to the project control system.

Risk and issue information should be kept current. The Team Manager can update relevant registers or provide information for the Project Manager/Project Support according to the tailored approach. Configuration Item Records and product status should also reflect actual progress so the project knows which version is current and what state the product is in.

Accurate forecasting is critical. A Team Manager should not wait until the due date to announce that the package cannot meet tolerance. If time, cost, scope, quality or another Work Package limit is forecast to be exceeded, notify the Project Manager so corrective action can be considered within stage authority.

Checkpoint reporting

The Checkpoint Report provides the Project Manager with regular information about progress against the Work Package. It is typically time-driven and its frequency should be agreed in the Work Package or relevant communication/control approach.

A useful checkpoint reports product progress, work completed, work remaining, quality activity status, actual/forecast effort or cost, relevant risks/issues and any expected tolerance concern. The Team Manager should distinguish facts from forecasts and explain significant changes since the previous checkpoint.

Reporting frequency can be tailored. A mature internal team delivering low-risk products may need less frequent checkpoints. A new supplier, high-risk interface or compressed stage may justify more frequent communication. The objective is timely control, not a fixed administrative ritual.

Product approval before delivery

The source expects the Team Manager to demonstrate that each product meets the quality criteria specified in its Product Description and to obtain approval from the authority identified there. This creates a strong rule: product delivery to the Project Manager should not merely mean “the team has finished working on it”.

Where approval is external to the team, plan the review lead time. A product can be technically complete but still undeliverable if the authorised reviewer is unavailable. Approval records should identify the product/version and the basis on which it was accepted.

Off-specifications discovered during review should move through issue/change control rather than being silently accepted. The Team Manager should not redefine quality criteria to make the product pass.

Activity 3 — deliver a Work Package

Delivery transfers the completed, approved products back to the Project Manager according to the procedures in the Work Package. The Team Manager also provides the associated completion information: approval records, status updates, actual performance, residual issues, risks or follow-on actions.

The Project Manager then performs the receiving side of Controlling a Stage. Completion should update product/configuration status and the Stage Plan. If there are unresolved conditions, describe them explicitly so they can be accepted as controlled follow-on work rather than disappearing in the handover.

Delivery can occur product by product or as a package depending on the agreement. What matters is that the Project Manager knows what has been delivered and approved and can use that evidence to control the stage.

1

Accept

Review the authorised package, constraints, product definitions, tolerance and reporting.

→
2

Plan

Prepare a Team Plan or practical schedule where useful.

→
3

Execute

Coordinate specialist production, interfaces, risks and quality methods.

→
4

Report

Provide accurate Checkpoint information and early forecast warnings.

→
5

Approve

Obtain the product approvals specified in Product Descriptions.

→
6

Deliver

Return approved products and completion/status evidence to the Project Manager.

External-supplier and contractual interfaces

The source explicitly notes that an external supplier does not need to use PRINCE2 internally. Managing Product Delivery provides the interface the project requires. The Work Package may even form part of a contractual agreement.

When a contract is involved, align Work Package information with contractual scope, deliverables, acceptance criteria, milestones and reporting obligations. Avoid creating contradictory project and contract instructions. If contractual change procedures differ from project issue/change control, define how they interact and which approval is needed before supplier work changes.

The principle remains the same: the supplier is free to organise internal technical work according to its system, but the project needs controlled acceptance, progress, quality, tolerance and delivery information at the interface.

Practical verification checklist

  • Review every Work Package before accepting it as achievable.
  • Confirm products, Product Descriptions, constraints, interfaces, tolerance and reporting expectations.
  • Create a Team Plan when it adds useful delivery control.
  • Use the agreed specialist development methods and maintain interfaces.
  • Perform planned quality activities and obtain the specified product approvals.
  • Provide accurate Checkpoint Reports at the agreed frequency.
  • Raise forecast Work Package tolerance deviations early to the Project Manager.
  • Keep risk, issue, quality and configuration/product status information current.
  • Deliver approved products with the associated evidence and completion information.
  • Align project Work Packages with contractual obligations for external suppliers.

Common mistakes to avoid

  • Treating Work Package acceptance as a one-way task assignment.
  • Beginning work despite unclear product or acceptance criteria.
  • Changing product criteria within the team to avoid an off-specification.
  • Reporting only activity effort and not product/quality status.
  • Waiting until delivery date to disclose a forecast tolerance problem.
  • Assuming an external supplier must adopt the entire PRINCE2 method internally.

Related KEVOS handbook pages

Controlling a StageProduct-based planningQuality theme

Continue learning

Controlling a Stage Process in PRINCE2 2017Guide · Planning & SchedulingNEXT LESSON →Managing a Stage Boundary Process in PRINCE2 2017Guide · Planning & SchedulingInitiating a Project Process in PRINCE2 2017Guide · Planning & SchedulingClosing a Project Process in PRINCE2 2017Guide · Planning & Scheduling
KEVOS · Engineering, manufacturing and project improvement
ArticlesServicesCase studiesAboutContact
© 2026 KEVOS®