Delivering the project: the stage processes

PRIN-140 followed a project from its mandate to the moment the project board authorized it. This course follows what happens next: the stages in which the products are actually built, the boundaries between those stages, and the controlled end of the project. Four processes do this work. Controlling a stage is how the project manager runs each delivery stage day to day. Managing product delivery is how team managers accept, build and hand back the work. Managing a stage boundary prepares the information the board needs to decide whether to continue, and plans the next stage. Closing a project confirms that the products are accepted, hands them over and evaluates the project. Directing a project, which PRIN-140 studied, sits above all four, and its decisions start and end each of them.

Process and activity names in this course follow common PRINCE2 7 usage as described in published study guides. When you sit a PRINCE2 exam, the official PRINCE2 7 manual is the authority for exact wording, so check the names there as you build your tabs and notes.

Where these processes sit

The PRINCE2 process model has three levels of management inside the project. The project board directs, the project manager manages and team managers deliver. Above the board, the business layer (corporate, program or customer management) sets project tolerances and receives the closure notification. Starting up and initiating happen once at the start. Then each delivery stage follows the same rhythm: the board authorizes the stage, the project manager controls it, team managers deliver work packages within it, and near its end the project manager manages the stage boundary to prepare the next authorization. The final stage ends with closing a project instead of a stage boundary.

The running case: Ridgeline Water's delivery stages

Like PRIN-130, PRIN-131 and PRIN-140, this course uses Ridgeline Water, the invented municipal water utility replacing about 40,000 manually read water meters with smart meters that report over a radio network. PRIN-140 ended with the board authorizing the project and the pilot stage at week 8. PRIN-131 controlled that pilot stage and dealt with an exception at week 24, when cleaning legacy billing data added about 70 thousand to the stage cost. The board approved an exception plan with a revised cost tolerance, a 30-week pilot and 2,800 connections instead of 3,000. This course picks the story up inside the pilot stage and follows it through the stage boundary, the two rollout stages and closure at the end of the project.

The pilot stage has four work packages, each led by a team manager. Northline Metering, the meter supplier and installer, installs meters in the pilot district. Ridgeline's own network team, working with the radio network vendor, builds and tunes the collector network. Ridgeline's IT team builds and tests the interface between the meter data system and the upgraded billing system. Customer operations runs the customer communication and appointment booking for installations. These four teams return in almost every lesson.

How the processes hand over to one another

The processes are easiest to understand as a chain of triggers. A trigger is an event or a product that starts a process or an activity. The board's authorization of a stage triggers controlling a stage. Inside it, the project manager authorizes work packages, which trigger managing product delivery for each team manager. Team managers send checkpoint reports back, and a completed work package notice when they finish. The project manager reviews stage status regularly. When the end of the stage approaches, that review triggers managing a stage boundary. If a forecast shows a stage tolerance will be breached, the project manager sends an exception report, the board decides, and if it asks for an exception plan, managing a stage boundary produces it. In the final stage, the approach of the project end triggers closing a project.

Management by exception in delivery

These processes are where management by exception really earns its keep. The board does not want to be involved in the daily work of installing meters, and it should not need to be. It has delegated the stage to the project manager within stage tolerances. The project manager in turn delegates work packages to team managers within work package tolerances. Each level reports regularly, but decisions move upward only when a forecast shows a tolerance will be breached. The result is that the board's time is spent on the decisions that genuinely belong to it: whether to continue at each stage boundary, how to respond to exceptions and whether to close the project.

A useful way to read the stage processes is to ask, for any event, which level of management owns the decision. A single meter that fails its acceptance test is the team manager's problem: rework it. A batch of faulty meters that will delay the installation work package beyond its tolerance is the project manager's: adjust the work packages, take corrective action or approve a change within delegated authority. A delay that will push the whole stage past its time tolerance is the board's. A delay that would breach the project's time tolerance belongs to the business layer.

A first look at the products

Several management products appear repeatedly in this course. A work package is the agreement between the project manager and a team manager about what will be delivered, how and under what constraints. A checkpoint report is the team manager's regular progress report to the project manager. A highlight report is the project manager's regular progress report to the board. An exception report warns the board of a forecast breach of stage or project tolerance. An end stage report summarizes the stage at its boundary, and an end project report evaluates the whole project at closure. The project log (the daily log and lessons log) and the registers for issues, risks, quality and products are updated throughout.

Mapping the stage lifecycle in code

The code below models Ridgeline Water's stage sequence after the pilot exception plan and lists which process is active, and which board decision falls due, at each boundary. It also checks the time position against the project's time tolerance of 8 weeks over the 100-week baseline.

stages = [  # (name, start_week, end_week, ends_with)
    ("Initiation", 0, 8, "authorize the project and the pilot stage"),
    ("Pilot", 8, 38, "stage boundary: authorize rollout stage 1"),
    ("Rollout stage 1", 38, 68, "stage boundary: authorize rollout stage 2"),
    ("Rollout stage 2 and closure", 68, 100, "closing a project: authorize closure"),
]
baseline_end, time_tol = 100, 8
for name, a, b, ends in stages:
    proc = "initiating a project" if name == "Initiation" else "controlling a stage + managing product delivery"
    print(f"weeks {a:3}-{b:3}  {name:28} {proc:48} then {ends}")
forecast_end = stages[-1][2]
used = max(0, forecast_end - baseline_end)
print(f"forecast close week {forecast_end}; time tolerance used {used} of {time_tol} weeks")

weeks   0-  8  Initiation                   initiating a project                             then authorize the project and the pilot stage
weeks   8- 38  Pilot                        controlling a stage + managing product delivery  then stage boundary: authorize rollout stage 1
weeks  38- 68  Rollout stage 1              controlling a stage + managing product delivery  then stage boundary: authorize rollout stage 2
weeks  68-100  Rollout stage 2 and closure  controlling a stage + managing product delivery  then closing a project: authorize closure
forecast close week 100; time tolerance used 0 of 8 weeks

The forecast close is still week 100 because the project plan absorbs the one-week slip from the pilot inside rollout stage 2. None of the project's 8 weeks of time tolerance has been used yet. That position will change during the course, and the board will see each change in highlight reports, end stage reports and, if necessary, exception reports.

Ridgeline Water reports to its municipal council through the general manager. Council receives a summary at each major stage boundary because the rollout stages commit capital approved in the municipal budget. In most Canadian municipalities, capital budgets are approved annually by council, so the project plan aligns the boundary at week 38 with the council meeting where the rollout contract award goes forward.

Common misunderstandings

Students often treat the stage processes as a strict sequence: control the stage, then manage the boundary, then repeat. In practice they overlap. Controlling a stage runs for the whole stage, including the weeks when the project manager is also preparing the boundary products. Managing product delivery runs in parallel for every active work package. And managing a stage boundary can be triggered in the middle of a stage when the board asks for an exception plan. A second misunderstanding is that team managers report to the board. They do not: their reports go to the project manager, who consolidates them in highlight reports. A third is that the project manager can close the project. Only the board can authorize closure, and only after the project manager recommends it.