Practicing the processes II: controlling, delivering, boundaries and closing

The four remaining processes run the project from its first delivery stage to its end. Controlling a stage is the project manager's day-to-day process; managing product delivery is the team manager's process for delivering work packages; managing a stage boundary prepares the board's decision at the end of each stage; and closing a project brings the project to a controlled end. These processes generate many Practitioner questions, because most scenario events happen during delivery stages. This lesson revises each process and then works through original practice questions on Ridgeline's outage alert app, which Ana managed, and the Harbor City makerspace refit, which Dev managed.

Controlling a stage: revision points

Corrective action and escalation form a pair. If a problem can be solved within stage tolerance and the project manager's authority, the project manager takes corrective action and records it. If stage tolerance is forecast to be exceeded, the project manager escalates with an exception report. Options that escalate problems that are within tolerance, or that fix problems that are outside it without telling the board, are classic distractors.

Managing product delivery: revision points

Managing product delivery is tailored heavily on agile projects, where a work package might cover a release or a set of sprints, and checkpoint reports might be replaced by sprint reviews and a team dashboard. The purpose stays the same: the project manager and team manager agree what is to be delivered, within what tolerances, and how progress and completion will be reported.

Managing a stage boundary: revision points

Closing a project: revision points

Foundation-style practice

Practitioner-style practice: the outage alert app

Scenario extract. Ridgeline's outage alert app is in its second release stage. Ana, as project manager, has authorized a work package to the vendor's team for push notifications and the map view, with tolerance of plus or minus one sprint and must-have scope fixed. The vendor's team lead reports in sprint 5 that the map provider changed its license terms, which will add 12 thousand a year in running costs; the stage cost tolerance is 20 thousand. In sprint 6 the team lead reports that the map view will slip by two sprints because of the change.

Practitioner-style practice: closing the makerspace

Scenario extract. The Harbor City makerspace refit finished its last stage. All products have been accepted except the laser cutter's fume extraction, which the supplier will deliver four weeks late. Dev wants to close the project now and treat the extractor as a follow-on action. The library's facilities team will maintain the space.

The makerspace's fume extraction is also a workplace safety matter for library staff under occupational safety and health rules, so the follow-on action names the facilities manager as owner and the board's closure notification asks for confirmation before the laser cutter is used with patrons.

Escalation logic in code

The decision rules for corrective action and escalation are simple enough to write as a function, which is a good way to test your understanding. The program below applies them to the outage app events.

def route(level, within_wp, within_stage, within_project):
    if level == "team":
        return "team manager handles" if within_wp else "issue to project manager"
    if within_stage:
        return "project manager takes corrective action"
    if within_project:
        return "exception report to the board"
    return "board escalates to the business layer"

events = [
    ("map terms change, 12k/yr", "pm", True, True, True),
    ("map slip 2 sprints, team view", "team", False, True, True),
    ("map slip, stage can absorb", "pm", False, True, True),
    ("map slip, stage cannot absorb", "pm", False, False, True),
    ("vendor exits, project at risk", "pm", False, False, False),
]
for name, level, wp, stage, project in events:
    print(f"{name:<32} -> {route(level, wp, stage, project)}")

map terms change, 12k/yr         -> project manager takes corrective action
map slip 2 sprints, team view    -> issue to project manager
map slip, stage can absorb       -> project manager takes corrective action
map slip, stage cannot absorb    -> exception report to the board
vendor exits, project at risk    -> board escalates to the business layer

The output mirrors the routing rule from lesson 8. Writing it as code is not something the exam asks for, but candidates who can state the rule this precisely rarely miss escalation questions.

Highlight reports versus end stage reports

Two of the progress products in these processes are frequently confused. A highlight report is time-driven: the project manager sends it to the board at the frequency agreed in the PID, summarizing progress in the stage, forecasts against tolerances, issues and risks, and products completed. An end stage report is event-driven: the project manager produces it in managing a stage boundary, reviewing the whole stage's performance, the business case, risks, issues and lessons, together with the request to approve the next stage plan. If a question describes a report at a fixed interval during a stage, it is a highlight report; if it describes a review at the end of a stage, it is an end stage report.

A related point concerns the timing of lessons. Lessons can be reported at the end of a stage, as part of the end stage report, when they would benefit the rest of the project or the organization straight away, and at closure in a lessons report. Candidates who think lessons are only reported at closure often miss questions about managing a stage boundary.

Finally, remember that the board can ask for an exception plan at any time during a stage, not only at its planned end. When it does, managing a stage boundary runs early to produce that plan, and the current stage continues under the board's direction until the exception plan is approved.