PRINCE2 in a six-week release cycle
Northwind Claims has a nine-person in-house team delivering a £480k customer-facing claims front end against a fixed seven-month regulatory deadline. The team has run two-week Scrum sprints for three years, uses a single product owner and a consistent definition of done. The sponsoring finance director requires PRINCE2 "compliance"; internal audit expects a PID, stage plans and board reports. There is no full-time project manager - the delivery lead would take the role two days a week, and the same three people would form the project board. The team objects that product descriptions and a quality register will "double the paperwork".
1. Design a tailored PRINCE2 approach for this project. What are the management stages, how do sprints fit, and which artefacts should be light or merged?
Read the worked answer
Tailoring here means mapping PRINCE2's controls onto the cadence the team already runs, not running two systems in parallel.
Stages: three management stages aligned to release milestones (foundations/design, core build, hardening and regulatory sign-off). Within each stage, the two-week sprints are the team plans, and the sprint backlog is the work package agreement.
What gets lighter or merged:
- Product descriptions for the small set of products the board genuinely needs to control (the front end, the regulatory submission pack, the data migration) - not one per user story. The team's definition of done becomes the quality criteria for increments, with the quality register generated from it rather than written alongside it.
- Highlight reports at sprint boundaries, one page, by exception - the board does not need a separate monthly cycle.
- Stage plans at milestone level with sprint-level detail delegated to the team; team plans replace duplicated scheduling.
- Board meetings end-of-stage plus ad hoc, with written board reports in between; three members meeting monthly for the sake of it is cost without control.
- Work packages issued once per stage to the team, with sprint-level checkpoint reporting inside it.
Record all of this in the PID's tailoring section, with reasons, so audit can see deliberate choices rather than omissions.
2. What cannot be tailored away, and where is the part-time project manager most exposed?
Read the worked answer
Cannot be tailored away:
- The seven principles. Tailoring adapts processes, practices and documentation; it may not remove the requirement that justification is reviewed, that roles and responsibilities are defined, that the project is managed by stages and by exception, that products and their quality criteria are defined, that lessons are sought, and that the approach suits the environment. A sprint cadence does not remove the need for a business case reviewed at stage boundaries, or for tolerances that let the board direct by exception.
- Accountability of the board and the three project interests. With three part-time board members, the executive, senior user and senior supplier accountabilities must still each be owned by a named person. If the same three people hold every role, the separation of business, user and supplier interest collapses and the senior supplier's challenge to estimates disappears.
Where the two-day-a-week PM is most exposed:
- Being drawn into sprint-level delivery decisions, which is the team's job.
- Project assurance - with nobody independent of the PM, the board cannot verify that the tailored approach is being followed. Allocate assurance explicitly to a board member or a competent third party.
The tailoring decision must be justified and agreed by the board, not assumed by the team.
3. How should the project manager satisfy the audit requirement for a PID, stage plans and board reports without duplicating what the team already produces?
Read the worked answer
Treat the audit requirement as a demand for evidence of control, and meet it with one set of records rather than two.
Practical approach:
- PID at initiation with an explicit tailoring section stating what is produced, what is combined, what is not produced and why - this converts "compliance" into a defensible position the auditor can test.
- Single source of truth: Jira boards and sprint reviews are the team plans and checkpoint evidence; a one-page highlight report per sprint is the board-facing summary. Export, do not transcribe.
- Stage plans at milestone level with a clear link to the release milestones, so auditors see baselines, tolerances and the exception route.
- Board reports generated from the same data, with decisions recorded in a decision and issue log - the log is far stronger audit evidence than a set of meeting minutes.
- Quality: the definition of done plus the resulting quality register gives auditable evidence that products were checked, by whom and with what result.
Then verify with the auditor before stage 1 ends that this evidence set is acceptable. Discovering at closure that the format was wrong is an avoidable failure, and the tailoring decision itself should be revisited if it is not working.