Managing product delivery I: accepting and executing work packages

Managing product delivery is the team manager's process. It controls the link between the project manager and the teams that build the specialist products, and it ensures that work is accepted on clear terms, done to the agreed quality, reported honestly and handed back properly. PRINCE2 does not tell team managers how to install meters, write code or build networks; that is specialist work, done with the team's own methods. What managing product delivery adds is a disciplined interface. This lesson covers accepting and executing a work package. Lesson 6 covers delivering it and the special cases of suppliers and agile teams.

The team manager's position

A team manager may be a member of the customer's staff, an employee of a supplier or a contractor engaged for one piece of work. At Ridgeline Water, the installation team manager is Marco Silva, Northline Metering's installation lead; the network team manager is Ridgeline's network supervisor; the billing interface team manager is the IT team's product owner and lead developer; and the customer communication team manager is a customer operations supervisor. Each reports to the project manager for the work package, whatever line management they have in their own organization. For Marco, that means two reporting lines: to the project manager for the work package, and to Northline's operations director for the contract and his crews.

Managing product delivery is sometimes said to be optional in the sense that a project may have no separate team managers, especially a small one. In that case the project manager performs the team manager's activities. The activities still need to happen, because someone must accept the work, do it to the right quality and confirm it is done. What changes is only who does them.

Accepting a work package

Acceptance is not a formality. The team manager reads the work package, checks the product descriptions, the constraints, the interfaces, the tolerances and the reporting arrangements, and asks one question: can my team really deliver this? To answer it, the team manager produces a team plan, or reviews an existing one, showing how the products will be built, by whom and when. If the plan shows that the work cannot be done within the work package's constraints, the team manager negotiates with the project manager before accepting, not after starting.

Marco received WP1 in week 9. His first draft team plan, using Northline's standard rate of 14 installations per crew per day and four crews, showed the 3,000 meters (the original pilot scope) taking 54 working days, or about 11 weeks, well inside the 21 weeks allowed. That looked comfortable until he added the realities the work package itself mentioned: the 30-minute water-off limit meant crews had to wait for customers in older streets, the no-weekends constraint removed days he had counted on, and customer appointments in the pilot district were available only on weekday mornings for many homes. A realistic rate was nearer 9 installations per crew per day. He raised these points before accepting, and the project manager agreed to add a fifth crew for weeks 18 to 26 within the existing cost estimate, because Northline's crew costs were lower than assumed in the stage plan.

The team plan

A team plan is optional in PRINCE2 terms: the project manager may ask for one or the team manager may produce one for the team's own use. For any substantial work package, it is wise. It sits below the stage plan, covering only the products in the work package, at whatever level of detail the team needs. It may be a crew schedule, a sprint plan, a network build sequence or a simple checklist. The project manager does not need to approve the detail, but should see enough to be confident that the work package is achievable and that its interfaces with other teams are planned.

The code below shows the kind of check Marco made. It compares the time needed at the standard and realistic installation rates with the time available, with and without the fifth crew, for the 2,800 meters in the revised pilot scope.

meters = 2800
days_per_week = 5
available_weeks = 21
def weeks_needed(rate, crew_weeks):
    # crew_weeks: list of (crews, weeks) blocks
    done, weeks = 0, 0
    for crews, length in crew_weeks:
        for _ in range(length):
            if done >= meters:
                break
            done += crews * rate * days_per_week
            weeks += 1
    while done < meters:
        done += crew_weeks[-1][0] * rate * days_per_week
        weeks += 1
    return weeks
for label, rate in [("standard rate 14/day", 14), ("realistic rate 9/day", 9)]:
    four = weeks_needed(rate, [(4, 30)])
    five = weeks_needed(rate, [(4, 9), (5, 9), (4, 30)])
    print(f"{label:22} four crews: {four:2} weeks   fifth crew in weeks 10-18 of WP1: {five:2} weeks   (available {available_weeks})")

standard rate 14/day   four crews: 10 weeks   fifth crew in weeks 10-18 of WP1: 10 weeks   (available 21)
realistic rate 9/day   four crews: 16 weeks   fifth crew in weeks 10-18 of WP1: 15 weeks   (available 21)

At the standard rate, four crews finish in 10 weeks; at the realistic rate, they need 16. With the fifth crew for nine weeks, the realistic plan needs 15 weeks. Either way the work fits in 21 weeks, but the team plan also has to leave room for weather, illness and appointment no-shows, and for the commissioning dependency on the collector network, which was not live until week 27 for the last streets. The fifth crew buys that margin.

Executing a work package

Executing a work package is where the specialist work happens. The team manager manages the team's work using its own methods, within the work package's constraints. Managing product delivery adds four disciplines. First, quality: products are built and checked using the quality methods in the work package, and the results are recorded in the quality register. Second, tolerance: the team manager monitors the work against the work package tolerances and raises an issue to the project manager as soon as a breach is forecast. Third, reporting: checkpoint reports go to the project manager at the agreed frequency. Fourth, records: product records and the team's own records are kept up to date so the project manager can see the true position.

Rework is the team's job. If a product fails its quality check, the team manager arranges for it to be corrected and checked again, within the work package. The project manager does not do rework and does not need to be told about every failed check, only about patterns that threaten the work package's tolerance or the product's acceptance. Early in WP1, the 5 % sample found seals missing on 3 of 60 sampled meters. Marco retrained one crew, added a seal photo to the installation checklist and asked the inspector to double the sample for two weeks. The failure rate fell to zero, and the inspector returned to the normal sample.

Raising issues from the team

The team manager raises an issue to the project manager when something threatens the work package tolerances, when a product cannot meet its quality criteria, when an interface with another team breaks down, or when something new arises that the project manager should know about. The team manager does not escalate to the board and does not change the work package unilaterally. In week 33, when the backflow valve supplier announced its delay, Marco raised an issue the same day, with his own analysis of the options. That allowed the project manager to examine it quickly and choose the temporary fitting option described in lesson 4.

Checkpoint reports from the team's side

For the team manager, the checkpoint report is a discipline of honesty. It should state what was done, what is planned, the status of quality checks, the tolerance position and any issues and risks, in terms the project manager can rely on. A good team manager reports problems early, with options, and does not wait until the problem is certain. Marco's weekly reports included a small table of installations per crew per day and a three-week forecast, which made it easy for the project manager to see trends and to plan the stage status reviews.

Northline's crews follow OSHA's construction standards for excavations and traffic, the state's rules where it runs its own occupational safety plan, and the utility's own installation standard. Their safety records and inspection results are part of the work package's quality records, because a product installed unsafely is not an acceptable product.

The team manager and the stage plan

Team managers do not own the stage plan, but they help to create it. When the project manager plans a stage in managing a stage boundary, team managers estimate their work, identify dependencies and suggest tolerances. During the stage, their checkpoint reports keep the stage plan accurate. And near the end of the stage, their experience feeds the next stage plan and the lessons log. At Ridgeline, Marco's crew productivity data became the basis for the rollout stage estimates, which made those estimates far more credible than the supplier's standard rate.