10.1 The Purpose of the Seven PRINCE2 Agile Processes
Key Takeaways
- PRINCE2 Agile keeps all seven processes intact — none is added, removed, merged or split — and tailors how each is carried out.
- Starting up a project answers whether there is a viable and worthwhile project; initiating a project establishes solid foundations for it.
- Directing a project provides overall control while delegating day-to-day management to the project manager.
- Controlling a stage takes care that the stage remains within its tolerances; managing a stage boundary ensures the project board can decide on the next steps.
- Version 2 attaches named agile workshops to the processes, and these workshops are directly examinable within the 25% process learning outcome.
10.1 The Purpose of the Seven PRINCE2 Agile Processes
Quick summary: Seven processes, none added, removed, merged or split by PRINCE2 Agile. Learning outcome 3 is worth 25% of the paper — roughly ten marks — and it covers both the processes and the agile workshops that support them.
The seven purposes
Learn these in the phrasing the exam uses. Purpose questions are usually a straight match between a process name and a distinctive phrase.
| Process | Purpose | Distinctive phrase |
|---|---|---|
| Starting up a project (SU) | To ensure the prerequisites for initiating a project are in place — answering do we have a viable and worthwhile project? | "viable and worthwhile" |
| Directing a project (DP) | To enable the project board to be accountable for the project's success by making key decisions and providing overall control while delegating day-to-day management | "delegating day-to-day management" |
| Initiating a project (IP) | To establish solid foundations for the project, so that everyone understands the work before committing to it | "solid foundations" |
| Controlling a stage (CS) | To assign and monitor work, deal with issues, report progress, and take care that the stage remains within its tolerances | "remains within the tolerances" |
| Managing product delivery (MP) | To control the link between the project manager and the delivery team by agreeing, executing and delivering work packages | "the link between project manager and team" |
| Managing a stage boundary (SB) | To ensure that the project board can decide on the next steps — reviewing the stage just finished, planning the next, and re-testing justification | "decide on the next steps" |
| Closing a project (CP) | To provide a fixed point at which acceptance of the project product is confirmed and to recognise that the objectives have been achieved | "a fixed point ... acceptance confirmed" |
Two of these are confused more often than the rest, so isolate them now:
- CS keeps the stage inside its tolerances. Day-to-day control, during the stage.
- SB gives the board what it needs to decide the next steps. A control point, at the end of a stage.
And note where delegation happens: the project board delegates day-to-day management to the project manager in the directing a project process, not in initiating or controlling a stage.
How the processes relate
The processes are not a strict linear sequence. Three of them run in parallel throughout:
- Directing a project runs from just after SU until closure, above everything else. It is the board's process.
- Controlling a stage and managing product delivery run together within every delivery stage, one at the managing level and one at the delivering level.
The rest occur at defined points: SU before the project is authorized, IP during the initiation stage, SB at the end of each stage except the last, and CP at the end.
The pre-project and initiation distinction
Starting up a project happens before the project exists. Its whole purpose is to do the minimum necessary to decide whether the idea is worth initiating, and to avoid the failure mode of poorly conceived ideas absorbing real budget before anyone has asked the obvious questions. SU is deliberately light.
Initiating a project happens once the board has authorized initiation. It is where the foundations are laid: the tailoring decisions, the management approaches, the controls, the plan and the detailed justification.
A useful pairing to remember:
| Starting up a project | Initiating a project | |
|---|---|---|
| Timing | Pre-project | The initiation stage |
| Question | Is this worth initiating? | How exactly will we run it? |
| Weight | Light | Fuller |
| Key output | Enough to justify authorizing initiation | The agreed basis for delivery |
Agile workshops
Version 2's distinctive addition to the processes is a set of named agile workshops. The examinable pattern is which workshop does what, and which process it supports.
The workshops named in the official Foundation material include:
| Workshop | What it does |
|---|---|
| Project canvas workshop | Produces the project canvas; user groups are defined and prioritized here |
| Starting up workshop | Establishes the early shared understanding needed to justify initiating the project |
| Agile enablement workshop | Establishes how agile will be used and agrees the critical agile artifacts, such as the Definition of Done |
| Project initiation workshop | Aligns the team on vision, objectives and goals, and develops the detailed project canvas |
| Project kickoff workshop | Forms the team: team introduction, values and norms, decision-making, team dashboard |
| Release planning workshop | Plans which features land in which release |
| Team planning workshop | Plans a team's timebox; team OKRs are defined here |
| Team retrospective workshop | The team shares the key accomplishments of its iteration and agrees improvements |
| Progress review workshop | Inspects progress collaboratively and agrees next steps |
| Project closure workshop | Establishes clear guidelines for ongoing benefits realization |
| Project retrospective | Captures project-level lessons at closure |
Sections 10.2 to 10.8 place these against the processes they support. Where PeopleCert has published a workshop's purpose, this guide states it; the complete process-by-process mapping is set out in sections 13.2 to 13.8 of the Official PRINCE2 Agile Book, and any workshop-to-process pairing you are unsure of should be confirmed there rather than guessed.
How is the 'managing a stage boundary' process used?
In which process should the project board delegate day-to-day management of the project to the project manager?
Which statement about PRINCE2 Agile and the seven processes is correct?