Northwind Rail: reconciling PRINCE2 stages with three teams of sprints
Northwind Rail is 18 months into replacing its timetable-planning system. The project runs with PRINCE2: four management stages, a stage boundary at the end of month 9, and a project board that meets quarterly. Beneath that, three delivery teams work in two-week sprints - one team's sprint ends three days before the stage boundary, another's ends five days after it. The project manager is drafting the stage 2 plan in detail, as she has always done, and has issued work packages that each team must sign off before starting each sprint. The board has asked for a weekly RAG status and a monthly percentage-complete figure for the whole project. Team leads report that work-package sign-offs arrive mid-sprint and stall delivery.
1. How should the project manager reconcile 'manage by stages' with the teams' sprint cycle? What actually needs to change?
Read the worked answer
- Recognise what manage by stages is for. It is a control concept: a decision point at which the board authorises the next chunk of work and commits the next set of tolerances. It does not require that the work inside a stage be sequential. Nothing here is broken in principle - the calendar and the content of the boundary are what need adjusting.
- Align the boundary to the sprints, not the sprints to the boundary. Either extend the last sprints by a few days to land on the boundary, or hold the boundary at the last common sprint end and treat the remaining five days as the start of stage 3. The cost of imperfect alignment is reporting noise; the cost of bending every team's cadence is worse.
- Make the stage plan a coarse release plan with tolerances, refined at the last responsible moment and re-baselined at the boundary. It is not a Gantt chart of every story.
- Use the boundary properly: end-stage report based on products actually accepted against the definition of done, plus lessons distilled from sprint retrospectives, so 'learn from experience' is wired into the governance rather than bolted on.
2. How should work packages and the 'managing product delivery' process be set up so the teams stop being blocked mid-sprint?
Read the worked answer
- A work package is the agreement between the project manager and the team manager - it sets the products, the quality criteria and the tolerances. Issuing one per sprint misuses it: it inserts a formal sign-off into the middle of a flow the team is supposed to self-organise within, which is exactly the stall being reported.
- Agree a work package covering a stage or a release for a defined product set, with the definition of done as its quality criteria and time/cost/scope tolerances attached. Inside it, the team pulls sprint backlog items and sequences its own work.
- Replace checkpoint reporting with the sprint review. The team demonstrates accepted increments; the project manager attends rather than chasing weekly checkpoint reports. Control comes from manage by exception - the team escalates when it forecasts breaching a tolerance, not every time it re-orders a story.
- Keep the PRINCE2 controls that earn their place: acceptance of deliverables by the project manager against agreed quality criteria, and a clear route for an exception to reach the board.
3. What should replace the board's weekly RAG and monthly percentage-complete? Justify the change in terms the board will accept.
Read the worked answer
- Percentage complete is the figure to retire. Work is either accepted against the definition of done or it is not; a '70% complete' feature forecasts nothing and invites the 90%-done plateau. Report accepted products and what remains, plus what is blocked.
- Give them a forecast with a range, not a point. 'At current velocity we will have delivered 62–70 of the 80 must-have features by month 9' is directly decision-useful; 47% complete is not.
- Support it with a burn-up of scope delivered against plan, plus a cumulative flow view of where work is queuing. This shows trend and bottlenecks, which a RAG dot hides.
- Keep the highlight report, at a frequency the board actually uses (monthly is defensible for a quarterly board), covering exceptions, risks, tolerances and decisions needed. Weekly RAG at programme level is false precision and trains the board to ignore it.
- Justify it as better governance, not less: the board still gets manage by exception, but the exception is triggered by a forecast breach rather than by a colour someone chose.