Project Delivery · Project Control Methods
Managing Work Packages and Product Delivery
Product delivery is a two-way commitment between the project manager and a delivery lead. The lead accepts an authorised work package, plans and coordinates product creation, maintains quality and configuration, reports credible checkpoints, raises forecast deviations and delivers approved products and records back to project management.
Executive summary
What this guide enables
Product delivery is a two-way commitment between the project manager and a delivery lead. The lead accepts an authorised work package, plans and coordinates product creation, maintains quality and configuration, reports credible checkpoints, raises forecast deviations and delivers approved products and records back to project management.
Learning outcomes
- Explain the purpose and lifecycle position of managing work packages and product delivery.
- Recognise the entry triggers, control evidence and completion conditions.
- Assign activities and decisions to the correct governance, management and delivery roles.
- Tailor the process without weakening accountability, product focus or exception control.
Control guidance
Purpose and lifecycle position
The purpose is to control the link between project management and delivery by agreeing requirements for acceptance, execution and delivery. It ensures teams work only on authorised products, understand constraints and quality, and provide reliable progress and completion evidence.
Lifecycle position: This process operates inside delivery stages and interfaces directly with stage control for each authorised work package. The delivery lead may be an internal team manager, technical lead, supplier representative or the project manager acting in a separate delivery capacity. External suppliers can use their own internal method if the work-package interface satisfies project and contract needs.
Control depends on the resulting decision and evidence, not on reproducing a particular flowchart. The process begins on a recognised trigger, uses current controlled inputs and ends with an explicit status, product, authorisation or request.
Control guidance
Entry triggers and prerequisites
Treat the trigger as the reason to act and the prerequisite as evidence needed to act safely. Confirm authority, applicable tolerance, status date and current product or plan versions; expose missing inputs rather than silently assuming them.
Package proposed
The project manager identifies products within the authorised stage and prepares the agreement.
Package accepted
The delivery lead confirms feasibility, resources, criteria, reporting and tolerance.
Checkpoint or exception
Delivery status or a forecast deviation requires communication with stage control.
Products approved
Completion evidence is ready for delivery and package closure.
Control guidance
Activity sequence
Activities may overlap or be combined, but each outcome must remain visible: what was considered, who acted or decided, and which authorised position now applies.
- 1
Accept the work package
Review products, criteria, dependencies, constraints, resources, schedule, risk, tolerance, reporting, approval and handover; negotiate before commitment.
- 2
Prepare or refine the team plan
Organise the accepted products into resource-feasible activities and quality events inside the package boundary.
- 3
Execute the work package
Create products, manage team work, apply technical and quality methods, maintain configuration and control internal risks and issues.
- 4
Report checkpoints
Provide actual product status, remaining work, quality, issues, risks, forecast and decisions at the agreed frequency.
- 5
Raise forecast deviations
Advise the project manager when package tolerance may be exceeded or a baseline decision is required.
- 6
Deliver the work package
Provide approved product versions, records, handover information, residual items and a clear completion statement.
- 7
Support package acceptance
Resolve queries and corrections until the project manager confirms that the agreement is fulfilled.
Control guidance
Management products and evidence
The record may be a document, workflow item, database entry or integrated view. Give every item a purpose, owner, status, update trigger and audience; protect baselines from silent change and ensure reports trace back to source evidence.
| Management product or evidence | Control purpose |
|---|---|
| Accepted work package | Records the two-way delivery commitment and constraints. |
| Team plan where useful | Coordinates detailed delivery inside the package. |
| Specialist products | Provide the authorised outputs in controlled versions. |
| Quality and approval records | Demonstrate criteria and completion. |
| Checkpoint reports | Provide time-driven product and forecast evidence. |
| Issue or deviation notifications | Trigger project-manager assessment and decision. |
| Updated risk, issue and configuration records | Maintain traceability through execution. |
| Delivered package record | Shows products, evidence, open items and handover. |
Control guidance
Roles, decision rights and assurance
Keep direction, day-to-day management, product delivery and independent challenge distinguishable. If compatible duties are combined, map responsibilities and add an independent decision or review wherever self-authorisation, self-acceptance or self-assurance would otherwise result.
| Role or level | Core responsibility | Decision or evidence |
|---|---|---|
| Project manager | Authorises package and accepts completion | Controls package tolerance and stage interface |
| Delivery lead | Commits to and coordinates product delivery | Owns package forecast and team action |
| Team members | Create and verify specialist products | Provide technical and quality evidence |
| Product reviewers or approvers | Perform defined quality methods | Approve or reject product versions |
| Project support | Maintains configuration and status where delegated | Links evidence to project records |
| Supplier or contract authority | Controls commercial commitments where relevant | Issues or receives contractual notices |
Control guidance
Interfaces and control logic
Map incoming evidence, outgoing authority and response deadlines so products or decisions do not stall between roles. Forecast breaches move to the tolerance-setting authority; baseline impacts follow change control; weakened justification returns to the accountable business authority.
- A work package should align with both the stage plan and any contract; neither silently substitutes for the other.
- The delivery lead reports forecast and remaining work, not only effort consumed.
- Product approval evidence must reference the delivered configuration.
- Package tolerance is a delegation boundary; a forecast breach is raised before actual failure.
| Control question | Evidence to inspect | Decision or response |
|---|---|---|
| Is the input authoritative? | Version, status, owner, approval and data date | Use, clarify or reject the input |
| Is action within delegated authority? | Plan, tolerance, budget, role and external constraints | Act locally or escalate |
| Has the activity produced a usable output? | Defined completion, assurance, decision and conditions | Pass forward or return for action |
| Has the overall forecast changed? | Integrated impact and remaining-work evidence | Update plans, business case, risks and reports |
Control guidance
Tailoring the process
A simple internal package may be a product description plus a short authorisation record and weekly status. A contracted package may reference a statement of work, deliverable schedule, acceptance regime and notice process. Iterative teams may accept a package for a stage objective and product increments, provided scope envelope, quality, release, reporting and exception boundaries are explicit.
Record the selected form, role mapping and evidence route in the initiation baseline. Revisit it when risk, suppliers, obligations, pace or decision lead time changes; tailoring must preserve purpose and authority even when format and frequency change.
Tailoring and readiness check
- The trigger and decision authority are explicit
- Inputs are current, approved where required and linked to their source
- Products and activities have one accountable owner
- Forecast impact covers time, cost, quality, scope, benefits and risk
- Issues, decisions and assumptions are recorded at the appropriate level
- Interfaces with the preceding and following processes are controlled
- Tailoring preserves the process purpose and required evidence
- The completion decision and any conditions have a traceable record
Control guidance
Worked application
Rejecting an unready package constructively
Situation: A project manager asks a specialist team to begin immediately, but the interface input, acceptance reviewer and test environment are not confirmed.
- The delivery lead does not treat urgency as authorisation and records the missing prerequisites.
- The package is split into an authorised preparation product and a later build product dependent on the interface and test decisions.
- The project manager resolves ownership, updates the stage forecast and sets an exception trigger if prerequisite dates move.
- The team accepts and executes the preparation package while avoiding unapproved build assumptions and rework.
Control outcome: Delivery begins on controlled, useful work without creating false commitment to an undefined product.
Control guidance
Failure modes, recovery and common questions
| Failure mode | Consequence | Control response |
|---|---|---|
| Package is a one-way instruction | Team commits without feasibility or resource agreement | Require explicit acceptance and negotiation |
| Quality left to the end | Completion is delayed by avoidable review and rework | Plan methods, reviewers and records inside the package |
| Supplier report does not support project forecast | Parallel status views emerge | Map contract evidence to product and remaining-work controls |
| Package closes on task completion | Unapproved products or missing records are handed over | Use product approval and configuration evidence |
Must a delivery team use the project's method internally?
No, provided the interface supplies authorised products, quality, forecast, issues, tolerance and evidence required by the project.
Is a work package a contract?
It can reference or form part of one, but it is the project-control agreement and must align with commercial authority.
Can the project manager also be delivery lead?
Yes on a small project with an explicit package and independent product approval or completion check.
What is the strongest progress measure?
Approved product status and credible remaining work, supported by quality and configuration evidence.