Capstone: controlling a stage, with exam strategy for these practices

This capstone applies all four control practices to one management stage of a different project. It uses Harbour City Libraries, the invented library system from the PRIN-130 capstone, which planned a 25-week pilot branch stage to install self-service kiosks with RFID tags and an online room booking system in one branch, and to measure customer uptake. Here the stage has been authorized and work is under way. You will set up quality and risk control, handle issues as they arise, report progress, and decide whether an exception is needed. The lesson ends with exam strategy for questions on quality, risk, issues and progress. All names and figures are invented and illustrative.

The authorized stage

Step 1: quality control for the stage

The project product description already contains the acceptance criteria. For the stage, the project manager makes sure each product description has measurable quality criteria and a method, and plans the quality activities into the stage schedule and the quality register. The most important quality activity is the measurement of uptake during the pilot, because it feeds the board's decision on rollout; it is planned as a product in its own right, with its method agreed in advance so that nobody can argue later about how uptake was calculated.

Step 2: risks for the stage

At the start of the stage, the project manager holds a short workshop with the team managers and assurance roles and reviews lessons from Ridgeline Water's project, which the city's project office has shared. Five main risks are recorded with owners and responses. The code below calculates their expected values before and after responses, checks them against the 15 thousand risk tolerance and adds up the cost of responses against the 25 thousand risk budget.

risks = [
    # id, description, p, impact k, response, response cost k, p after, impact after
    ("H1", "Tagging slower than planned", 0.5, 30, "train extra staff; temp helpers on standby", 6, 0.3, 20),
    ("H2", "Patrons avoid kiosks", 0.4, 45, "staff ambassadors at kiosks for 4 weeks", 8, 0.25, 45),
    ("H3", "Kiosk delivery late", 0.2, 12, "accept; kiosks have float", 0, 0.2, 12),
    ("H4", "Booking system fails accessibility audit", 0.3, 20, "early audit of templates", 4, 0.1, 20),
    ("H5", "Library system upgrade overruns", 0.3, 25, "vendor support contract hours", 5, 0.15, 25),
]
budget, tol = 25, 15
spent = 0
for rid, text, p, imp, resp, cost, p2, imp2 in risks:
    before, after = p * imp, p2 * imp2
    spent += cost
    flag = "  board review" if after > tol else ""
    print(f"{rid} {text:40} EV {before:5.1f} -> {after:5.1f}{flag}")
print(f"responses cost {spent}k of {budget}k risk budget")
print(f"total EV before {sum(r[2]*r[3] for r in risks):.1f}k, after {sum(r[6]*r[7] for r in risks):.1f}k")

H1 Tagging slower than planned              EV  15.0 ->   6.0
H2 Patrons avoid kiosks                     EV  18.0 ->  11.2
H3 Kiosk delivery late                      EV   2.4 ->   2.4
H4 Booking system fails accessibility audit EV   6.0 ->   2.0
H5 Library system upgrade overruns          EV   7.5 ->   3.8
responses cost 23k of 25k risk budget
total EV before 48.9k, after 25.4k

Responses cost 23 thousand of the 25 thousand risk budget and cut the total expected value of the threats from about 49 to about 25 thousand. Before responses, patron avoidance, at 18 thousand, exceeded the 15 thousand tolerance and would have needed board review; after responses, no single risk exceeds it, and patron avoidance remains the largest at about 11 thousand. That is appropriate: uptake is the uncertainty the pilot exists to measure, and no response can remove it completely. The project manager records the residual risk clearly so that the board does not mistake a well-managed risk for a resolved one.

Step 3: issues as they arise

Over the first twelve weeks, the project manager captures many small items in the daily log and three significant issues in the issue register. Each is classified, assessed and routed according to the issue management approach and the change authority limits.

The routing follows the rules from lessons 5 and 6. The tagging problem is handled by the project manager because the response is already planned and funded. The kiosk off-specification is corrected rather than accepted, because accessibility is a must-have criterion and no concession is appropriate. The payment request goes to the board because it exceeds the project manager's change authority, even though it would not breach any tolerance on its own.

Step 4: progress at week 12

At week 12 the project manager prepares the third highlight report. The main question is the time forecast, because tagging is on the critical path. The code below forecasts the end of tagging from the actual weekly rates, including the standby helpers who started in week 9, and works out the effect on the stage end date and on time tolerance, with and without the payment change.

items_total = 60000
weekly = {6: 7200, 7: 7800, 8: 8100, 9: 9900, 10: 10400, 11: 10600}   # items tagged each week
done = sum(weekly.values())
recent_rate = sum(list(weekly.values())[-3:]) / 3
weeks_left = (items_total - done) / recent_rate
tag_finish = 12 + weeks_left
slip = tag_finish - 12            # tagging was planned to finish at week 12
stage_end = 25 + slip
tol = 3.0
print(f"tagged {done} of {items_total}; recent rate {recent_rate:.0f} per week")
print(f"tagging forecast to finish week {tag_finish:.1f}; slip {slip:.1f} weeks")
print(f"stage end forecast week {stage_end:.1f}; time tolerance used {slip / tol:.0%}")
# the payment change uses booking float (1 week) exactly, so no extra critical path delay
print("with payment change: no additional delay (uses booking float)")
# but if the board also extends the measured pilot by 2 weeks to cover a school term:
print(f"with pilot extended 2 weeks: stage end week {stage_end + 2:.1f}; tolerance used {(slip + 2) / tol:.0%}")

tagged 54000 of 60000; recent rate 10300 per week
tagging forecast to finish week 12.6; slip 0.6 weeks
stage end forecast week 25.6; time tolerance used 19%
with payment change: no additional delay (uses booking float)
with pilot extended 2 weeks: stage end week 27.6; tolerance used 86%

With the helpers, tagging is now running at about 10,300 items a week. The 6,000 items still to tag will take a little over half a week, so tagging finishes around week 12.6, about 0.6 weeks late, and the stage is forecast to end around week 25.6, using about 19 % of the time tolerance. The payment change would use the booking system's float without delaying the stage. The highlight report shows time as green, notes that the tagging response worked, and asks the board to decide the payment request.

At the board meeting, the chief librarian raises a new point: the measured pilot will run during the summer, when patron numbers and patterns differ from the rest of the year. The library board wants the pilot extended by two weeks to include the first two weeks of the school term. The project manager's forecast shows that this would push the stage end to around week 27.6, using about 86 % of the time tolerance, still within it, but leaving little margin for anything else. The board approves both changes, notes the reduced margin, and asks for weekly rather than four-weekly status emails until the measured pilot starts.

Step 5: an exception after all

In week 15, the kiosk vendor reports that a firmware fault found at another library means all kiosks must be updated and recertified before the pilot can go live, taking 1.5 weeks. Kiosk installation is on the critical path. With the pilot extension already approved, the forecast stage end becomes about week 29.1, beyond the 28-week limit. The project manager raises an exception report. The options are to shorten the extended pilot back to 8 weeks, accepting a less representative measurement; to start the measured pilot with staff-assisted checkout while kiosks are recertified, which would distort the uptake measure; to ask the board for a revised time tolerance at little extra cost, since the vendor bears the firmware cost; or to defer the booking system go-live, which would not help because it is not on the critical path. The project manager recommends a stage exception plan with a revised time tolerance, because the measurement is the purpose of the stage and project tolerances can absorb the delay.

Exam strategy for these practices

PRIN-101 and PRIN-120 summarized the exam formats: the PRINCE2 7 Foundation exam is a closed-book paper of 60 multiple-choice questions in 60 minutes with a pass mark of 36, and the Practitioner exam is a 150-minute, 70-question objective test based on a scenario, with a pass mark of 60 %, in which the official PRINCE2 7 manual may be consulted. Formats change from time to time, so check the current guidance from PeopleCert or an accredited training provider before you sit an exam. PRIN-160 covers exam strategy in depth; the table below summarizes the traps that questions on these four practices most often set.

A reliable method for scenario questions is to ask, in order: what has happened or been proposed; which practice it belongs to; which management product records it; which role is responsible for the next action; and which tolerance or authority limit applies. Most wrong options in well-written questions fail one of these checks: they assign the action to the wrong role, use the wrong record, or escalate to the wrong level.

questions, minutes = 70, 150
reserve = 15                 # minutes kept for review at the end
per_q = (minutes - reserve) / questions
print(f"about {per_q:.1f} minutes per question, with {reserve} minutes reserved")
checkpoints = [10, 20, 35, 50, 70]
for q in checkpoints:
    print(f"after question {q:2}: aim to be at about {q * per_q:5.0f} minutes")

about 1.9 minutes per question, with 15 minutes reserved
after question 10: aim to be at about    19 minutes
after question 20: aim to be at about    39 minutes
after question 35: aim to be at about    68 minutes
after question 50: aim to be at about    96 minutes
after question 70: aim to be at about   135 minutes

With 15 minutes kept for review, each question gets just under two minutes. Checkpoints help a candidate notice early if look-ups in the manual are taking too long. For questions on these four practices, the most time-efficient look-ups are the contents of management products, such as what an exception report contains, and the responsibilities tables, such as who approves the quality management approach.

Self-assessment

Before finishing the course, check your own capstone work against these questions. Does every key product have measurable quality criteria, a method and a named approver, and is the uptake measurement method agreed before the pilot starts? Is every significant risk described as cause, event and effect, with an owner, a proportionate response and an expected value? Were the three issues classified correctly and routed according to the change authority and tolerances? Does the highlight report show tolerance used, not just in or out, and ask for decisions where needed? Was the exception raised when the breach was forecast, with genuine options? If you can answer yes to each, you have applied the control practices as an integrated system rather than as four separate sets of paperwork.