4.3 The Seven PRINCE2 Principles
Key Takeaways
- The seven principles are: ensure continued business justification, learn from experience, define roles, responsibilities and relationships, manage by stages, manage by exception, focus on products, and tailor to suit the project.
- All seven must be applied for a project to be a PRINCE2 project; they are universal, self-validating and empowering.
- 'Ensure continued business justification' is the principle that explains whether a project can still deliver value.
- 'Define roles, responsibilities and relationships' was extended in PRINCE2 7 to include relationships, not just roles and responsibilities.
- 'Manage by exception' is what makes delegated, self-managing agile delivery compatible with project board control.
4.3 The Seven PRINCE2 Principles
Quick summary: Seven principles. All must be applied — dropping one means the project is not a PRINCE2 project. They are universal (they apply to every project), self-validating (proven in practice over decades) and empowering (they give practitioners confidence and the ability to shape their approach).
The seven principles
| # | Principle | What it requires |
|---|---|---|
| 1 | Ensure continued business justification | There is a justifiable reason to start, and it remains valid and is re-tested throughout |
| 2 | Learn from experience | Lessons are sought at the start, captured during, and passed on at the end |
| 3 | Define roles, responsibilities and relationships | An agreed structure that engages business, user and supplier interests, and defines how those roles relate |
| 4 | Manage by stages | Plan, monitor and control the project stage by stage, with a board decision at each boundary |
| 5 | Manage by exception | Define tolerances for each performance target, delegate authority within them, escalate only when they will be breached |
| 6 | Focus on products | Define and agree the products and their quality criteria before deciding how to produce them |
| 7 | Tailor to suit the project | Scale the method to the project's context, size, complexity, importance, team capability and risk |
Two wording points that matter in Version 7 and therefore in PRINCE2 Agile Version 2:
- Principle 3 was formerly "defined roles and responsibilities". It now explicitly includes relationships, reflecting the elevation of the people element — how roles interact matters as much as who holds them.
- Principle 7 was formerly "tailor to suit the project environment". It is now "tailor to suit the project".
Taking them one at a time
1. Ensure continued business justification
There must be a justifiable reason to start the project, that justification must remain valid throughout, and it must be documented and approved. If it ceases to be valid, the project should be stopped — a project that is stopped early for good reason is a success, not a failure.
This is the principle that answers the question "can this project still deliver value?" It is the direct parent of the business case practice and of the project board's decision at every stage boundary.
In agile delivery this principle becomes sharper rather than weaker. Frequent releases produce real evidence about whether the forecast benefits are materialising, so continued justification can be tested against measured outcomes rather than against a spreadsheet written a year earlier.
2. Learn from experience
Lessons are actively sought when the project starts, recorded as it runs, and passed on when it closes. The intent is that lessons change behaviour, not merely that they are logged.
Agile delivery is unusually well suited to this because the retrospective is a scheduled, recurring mechanism for it. The team retrospective workshop improves the team's next iteration; the project retrospective feeds the organization's next project.
3. Define roles, responsibilities and relationships
A project needs an explicit organization structure engaging the three project interests — business, user and supplier — with clear accountability and clear relationships between the roles.
Agile does not dissolve this. Adding a product owner and a team coach does not remove the need to know who is accountable for the business case. Chapter 9 covers the eleven roles the Version 2 syllabus names.
4. Manage by stages
The project is planned, monitored and controlled stage by stage. A stage boundary is a genuine decision point: the board reviews what has been delivered and the updated business case, and authorizes the next stage or stops the project.
A stage is not an iteration. A stage exists for management control and may contain several releases, each containing several iterations.
5. Manage by exception
Tolerances are defined for each performance target at each level of the project. Within its tolerances, a level has delegated authority to act without referring upward. Only a forecast breach is escalated.
This is the principle that makes agile delegation and project governance compatible. Self-managing teams need genuine autonomy; project boards need genuine control. Manage by exception delivers both by making the boundary explicit: the team decides everything inside the tolerance, the board decides everything outside it. Without it, either the board micromanages or it loses control.
6. Focus on products
PRINCE2 is product-based. You define what is to be delivered and its quality criteria first, and derive the activities from that — not the other way round.
The agile expression of this is precise product definition through user stories, acceptance criteria and the Definition of Done. Note the compatibility: a backlog is a product-focused artifact. It lists things to be delivered, not tasks to be performed.
7. Tailor to suit the project
PRINCE2 is scaled to the project's context, size, complexity, importance, team capability and risk. Tailoring decisions are recorded — typically at initiation — so that they are deliberate and visible rather than drift.
Tailoring is what PRINCE2 Agile is. But note the limit: you tailor the practices, the processes and the artifacts. You never tailor away a principle. A project that has abandoned continued business justification has not tailored PRINCE2; it has stopped using it.
Which principle explains whether a project can still deliver value?
Which principle makes it possible for a self-managing delivery team to have genuine autonomy while the project board retains control?
A project manager proposes dropping the business case entirely because the project is small and agile. Which statement is correct?