10.5 Controlling a Stage and Its Agile Workshops
Key Takeaways
- Controlling a stage takes care that the stage remains within its tolerances, through the project manager's day-to-day management.
- Its activities include authorizing work packages, evaluating stage status, reporting highlights, capturing issues and risks, and taking corrective action.
- Uncertainties are logged in the 'capture issues and risks' activity.
- The progress review workshop is the collaborative forum in which progress is inspected and next steps agreed.
- Corrective action within tolerance is the project manager's decision; a forecast breach triggers an exception report to the project board.
10.5 Controlling a Stage and Its Agile Workshops
Quick summary: CS exists to take care that the stage remains within its tolerances. It is the project manager's day-to-day process, running in parallel with managing product delivery throughout every delivery stage. Its agile workshop is the progress review workshop.
Purpose
The purpose of controlling a stage is to assign the work to be done, monitor that work, deal with issues, report progress to the project board, and take corrective action so that the stage remains within its tolerances.
That phrase identifies CS. Compare it with SB, which exists so the board can decide on the next steps — CS is during the stage, SB is at the end of it.
Activities
| Activity | What happens |
|---|---|
| Authorize a work package | Agree what a delivery team will produce, with tolerances and the Definition of Done |
| Review work package status | Take in the team's current position — usually from the team dashboard rather than a written report |
| Receive completed work packages | Confirm products are complete against the Definition of Done and acceptance criteria |
| Evaluate stage status | Compare the stage's actual and forecast position against its plan and tolerances |
| Report highlights | Produce the highlight report for the project board on the agreed cadence |
| Capture issues and risks | Log uncertainties and issues as they arise |
| Take corrective action | Act within tolerance to bring the stage back on track |
| Escalate issues and risks | Raise an exception when a tolerance is forecast to be breached |
Two of these are examinable by name:
- Uncertainties are logged in the capture issues and risks activity. A risk is uncertainty; capturing it here puts it on the risk register.
- Evaluate stage status is the activity in which the manager forms the judgement that triggers everything else — corrective action if inside tolerance, escalation if not.
Corrective action versus escalation
This is the operational heart of manage by exception.
| Situation | Response | Who decides |
|---|---|---|
| Deviation, forecast to stay within tolerance | Take corrective action — re-sequence, trade scope, address the impediment | Project manager |
| Deviation forecast to breach tolerance | Escalate — produce an exception report | Project board decides |
The trigger is the forecast, not the actual breach. Escalating once the tolerance has already gone removes the board's ability to do anything about it.
Corrective actions available on an agile project are unusually good, precisely because scope flexes:
- Re-prioritize the backlog so the highest-value work completes within the timebox
- Trade or swap requirements of equivalent size, with the product owner agreeing priorities
- Drop Could-have and then Should-have items to protect the date
- Swarm the team on the blocking item
- Remove an impediment through the team coach or by escalating a dependency
Note what is not on that list: extending the timebox, adding people mid-flight, or weakening the Definition of Done. Those break the time, cost and quality targets respectively.
The progress review workshop
The progress review workshop is the collaborative forum in which progress is inspected and next steps agreed. It brings the project manager, product owner, team representatives and relevant board members together to look at the same evidence at the same time.
Its advantage over circulating a report is that questions get answered in the room by the person who knows. It is where:
- Actual delivery is compared against the release map
- Tolerance consumption is reviewed across the performance targets
- Risks, issues and impediments are surfaced and owned
- Trade-offs are agreed with everyone present — flexing scope, re-sequencing releases, or agreeing that an exception must be raised
Agile tailoring of CS
Work packages are agreements, not instructions. A work package states the products, tolerances and Definition of Done. It does not tell a self-managing team how to do the work.
Monitoring is by dashboard, not by report. The project manager reads the team dashboard continuously rather than waiting for a fortnightly checkpoint report. Reviewing work package status becomes an ongoing activity.
Progress is measured in completed increments meeting the Definition of Done, not in percentage complete.
Change is absorbed rather than escalated. Most change is handled by re-prioritizing the backlog inside the agreed baseline. Only changes to the baseline itself go through formal change control.
Reporting is thinner. The highlight report is assembled from dashboard data the team produces anyway, so reporting costs the team nothing extra.
In which activity of the 'controlling a stage' process are uncertainties logged?
A stage is forecast to consume 90% of its time tolerance. The project manager re-prioritizes the backlog and drops two Could-have items. What has happened?
What is the principal advantage of a progress review workshop over circulating a written progress report?