2.4 Common Traps in 7 PRINCE2 Principles
Key Takeaways
- Top trap: claiming a principle was 'tailored away' — principles are mandatory and cannot be tailored; only practices and processes are.
- Do not confuse principles (7), practices/themes (7), processes, and management products — they are different categories of PRINCE2 element.
- Memorize PRINCE2 7 wording: 'ensure continued business justification' and 'define roles, responsibilities, and relationships' (the 2023 updates).
- Manage by exception means escalate only on a forecast tolerance breach — not on every variance, and not never.
- Focus on products is product-based (define products first), not activity-first; 'we'll know it when we see it' violates it.
Trap 1 — "The team tailored away a principle"
This is the single most common distractor in the principles topic. Any answer or stem implying a principle was removed, skipped, or tailored out is wrong. The mantra: tailor the method, not the principles. Practices, processes, management products, roles, and terminology are tailored; the seven principles are always present in a genuine PRINCE2 project.
Watch the exact phrasing in distractors:
| Distractor wording | Why it's wrong |
|---|---|
| "They tailored out continued business justification" | Principles cannot be tailored away. |
| "Manage by stages was dropped to save time" | Removing a principle means it is not PRINCE2. |
| "Principles are optional guidance" | Principles are mandatory, not optional. |
| "Small projects can ignore the principles" | Principles are universal — they apply to every project. |
Trap 2 — Mixing up the categories
Foundation candidates conflate principles, practices (themes), processes, and management products. Keep them separate:
- Principles (7) — guiding obligations (e.g., manage by exception).
- Practices (7) — aspects to manage continually: business case, organizing, plans, quality, risk, issues, progress.
- Processes — activity sets across the lifecycle (starting up, directing, initiating, controlling a stage, managing product delivery, managing a stage boundary, closing).
- Management products — documents/records (business case, PID, lessons log, risk register, product description).
If a question asks "which of these is a principle," and an option is quality or risk, that option is a practice, not a principle.
Trap 3 — Outdated wording
Legacy 6th-edition study material uses "continued business justification" and "defined roles and responsibilities." PRINCE2 7 (2023) updated these to "ensure continued business justification" and "define roles, responsibilities, and relationships." Likewise, the old word "themes" is now "practices." If two answer options differ only by this wording, pick the current PRINCE2 7 form.
Trap 4 — Over- or under-escalating (manage by exception)
Two opposite wrong answers appear:
- Under-escalation — "absorb the overspend quietly." Wrong: a forecast breach must be escalated.
- Over-escalation — "report every minor variance to the board immediately." Wrong: that defeats delegated tolerances; the manager works freely within tolerance.
The correct trigger is precise: escalate when a tolerance is forecast to be exceeded — via an exception report to the level that set the tolerance.
Trap 5 — Activity-first thinking (focus on products)
Distractors that say planning should "start by listing the tasks/activities" invert the principle. PRINCE2 is product-based: define the products and their quality criteria first, then derive the activities. "We'll recognize success when we see it" and "start building, define quality later" both violate focus on products because they skip measurable quality criteria and acceptance criteria.
Quick-reference: principle vs. its mechanism
A frequent exam pattern matches a principle to the management product or mechanism that delivers it. Memorize these pairings:
| Principle | Primary mechanism |
|---|---|
| Ensure continued business justification | Business case (reviewed each stage) |
| Learn from experience | Lessons log / lessons report |
| Define roles, responsibilities, and relationships | Four-level organization + project board |
| Manage by stages | Management stages + stage boundaries |
| Manage by exception | Tolerances + exception report |
| Focus on products | Product descriptions + product-based planning |
| Tailor to suit the project | Tailoring decisions recorded in the PID |
If a question gives you the mechanism and asks for the principle (or vice versa), this table is your answer key. The exam rarely asks you to apply a principle in deep detail at Foundation — it asks you to recognize the principle, its definition, its current wording, and the mechanism it uses.
Trap 6 — Confusing 'continued' with 'one-time' justification
A subtle distractor implies the business case is settled at the start ("the project was justified at kick-off, so it stays justified"). The word continued makes this wrong: justification is reassessed every stage and at every exception. A project can be perfectly justified at initiation and become unjustified halfway through — at which point PRINCE2 says stop it. The correct phrase to listen for is "reviewed throughout" or "reassessed at each stage boundary," not "approved once."
Trap 7 — Treating tailoring as 'doing less PRINCE2'
Candidates sometimes read tailoring as permission to cut corners. Tailoring is a deliberate, recorded decision to make the method fit, not an excuse to drop governance. The output of tailoring still satisfies all seven principles; it simply expresses them proportionately. A two-page PID on a tiny project is tailoring done right; no business case at all is a principle breach.
Trap 8 — Mismatching a principle to the wrong mechanism
The quick-reference table above is also a trap source: examiners pair a principle with a plausible but wrong mechanism. Common decoys:
| Tempting wrong pairing | Correct pairing |
|---|---|
| Manage by exception → product description | Manage by exception → tolerances/exception report |
| Focus on products → lessons log | Focus on products → product descriptions |
| Learn from experience → exception report | Learn from experience → lessons log |
| Continued business justification → risk register | Continued business justification → business case |
When you see a principle-to-mechanism question, do not pick the first familiar word in the options — match it precisely. The mechanism that uniquely delivers the principle is the answer; a mechanism that merely touches the project is a distractor.
A scenario states a project team 'tailored out the manage by stages principle to deliver faster.' What is the correct evaluation?
Which of the following is a PRINCE2 practice (formerly a theme), NOT a principle?
Which mechanism most directly delivers the 'learn from experience' principle?
A team writes a two-page Project Initiation Documentation for a small, low-risk project but still keeps a business case, manages by stages, and reviews lessons. This is best described as: