Managing product delivery II: delivering work packages with suppliers and agile teams

A work package is not finished when the team stops working. It is finished when its products have been approved by the people named in the approval method, the records show it, anything that had to be handed to another team or to operations has arrived, and the project manager has been told. This lesson covers that last activity of managing product delivery, then looks at two situations that shape how managing product delivery works in practice: external suppliers working under contracts, and agile teams delivering in sprints. Both appear in Ridgeline Water's pilot stage.

Delivering a work package

Delivering a work package has three parts. First, the team manager confirms that every product in the work package has passed its quality checks and has been approved using the approval method, and that the quality register and product records show this. Second, the team manager hands over the products as the work package requires: to the project manager, to another team that needs them, or into a holding area until the project hands them to operations at closure. Third, the team manager updates the team plan to show the work complete and notifies the project manager that the work package is complete. Controlling a stage then receives the completed work package, as lesson 3 described.

The lessons the team manager sends at the end of a work package are often the most useful in the project. Marco's included the realistic installation rate, the value of booking appointments two weeks ahead, the seal checklist step and the advice to check component lead times before a stage starts. They went straight into the lessons log and shaped the rollout stage plan.

Work packages with external suppliers

When a team manager works for a supplier, managing product delivery sits alongside a contract. PRINCE2 7 recognizes this explicitly through its commercial management approach, which describes how suppliers will be selected, contracted, managed and paid. The work package does not replace the contract, and the contract does not replace the work package. They must say the same things about products, quality, dates and acceptance, and when one changes, so must the other.

The supplier will often have its own project management method, perhaps its own version of PRINCE2. That is fine. What matters is that the supplier's team manager works to the agreed work package interface: accepts work packages, reports checkpoints, raises issues and confirms completion. Inside its own organization, Northline uses its own scheduling system and its own crew supervisors; Ridgeline does not need to see that detail, only the reliable information the work package asks for.

Linking approvals to payment

One of the strongest controls on supplier work is to make payment depend on the same evidence as product approval. If a meter counts as installed for payment only when it has passed the inspector's sample and appears as approved in the product register, the supplier has every reason to keep the quality records complete. Ridgeline's contract pays Northline monthly for meters approved in that month, minus a percentage held back until the work is complete. The code below calculates the payment for the last month of the pilot under two holdback rates.

rate_per_meter = 0.335   # thousand, installed and commissioned (illustrative)
approved_this_month = 708
rework_open = 0
gross = approved_this_month * rate_per_meter
for label, held in [("10 % held back", 0.10), ("5 % held back", 0.05)]:
    retained = gross * held
    print(f"{label:15} gross {gross:6.1f}k  held {retained:5.1f}k  paid now {gross - retained:6.1f}k")
print(f"meters with open rework (not paid): {rework_open}")

10 % held back  gross  237.2k  held  23.7k  paid now  213.5k
5 % held back   gross  237.2k  held  11.9k  paid now  225.3k
meters with open rework (not paid): 0

In the United States, state prompt payment and public works laws often limit retainage on public contracts, commonly to 5 % or 10 % and sometimes reducing once the work is half complete, and set deadlines for paying approved invoices. Ridgeline's contract applies 5 % retainage and aligns invoice timing with the monthly approval run, so that an invoice and its approval evidence arrive together.

Agile teams in managing product delivery

Ridgeline's billing interface team works in two-week sprints with a product owner, a team lead and developers. Managing product delivery fits this cycle well. Accepting the work package means agreeing the timebox, the team cost, the must-have features and the definition of done. Executing it means running sprints, with sprint reviews as the main quality method and automated tests as quality checks recorded in the team's tools. Delivering it means demonstrating that every must-have feature meets the definition of done and that the interface has passed integration testing with the billing system, then notifying the project manager. Checkpoint reports come at the end of each sprint and include the burn-up chart.

The team manager of an agile team must still respect the work package's limits. A team that discovers a valuable new feature does not simply add it; it raises it with the project manager, who decides whether it fits within the flexible scope or needs a change decision. And a team that is falling behind does not quietly drop must-haves; it raises an issue as soon as the burn-up shows the risk. At week 30 the billing team had deferred two could-have reports, which was within its authority, and reported that in its checkpoint. That is self-organization inside clear boundaries, which is what PRINCE2 and agile methods both want.

Interfaces between work packages

Most of the problems in delivery happen at the joins between teams. The installation team needed the collector network live before meters could be commissioned remotely; the billing interface needed commissioned meters to test with real data; customer operations needed installation schedules to book appointments. Each work package names these interfaces, and each team manager is responsible for keeping them, but it is the project manager who coordinates them across work packages. At Ridgeline, the project manager held a 30-minute weekly interface call with the four team managers, which caught the coverage gap in WP2 and the appointment backlog in WP4 before they became issues.

When a supplier is struggling

Sometimes a supplier's team cannot deliver. The first response is through managing product delivery: the team manager raises issues, proposes recovery and works within the work package. If that fails, the project manager deals with it in controlling a stage, perhaps by adjusting work packages or taking corrective action. If the commercial relationship itself is in trouble, for example persistent quality failures or a dispute about payment, the commercial management approach applies, and the board may need to be involved, especially if the remedy is to change suppliers. In none of these cases should the supplier's team manager bypass the project manager and go straight to the board or to the executive.

Closing out a work package cleanly

Completing the last work package of a stage has knock-on effects that team managers sometimes overlook. Spare materials have to be returned or recorded, temporary access permits closed, crews released or reassigned, and any warranty obligations noted for the handover at project closure. Ridgeline's installation work package left 46 spare meters, 3 spare collectors and a part box of temporary valve fittings. Marco recorded them in the product register as project stock, so that they could be used in rollout stage 1 rather than written off or forgotten in a depot. The project manager added a one-line check to the receiving completed work packages activity: what is left over, where is it, and who owns it now?