Study guide
4.4 Applying Principles in Context
PRINCE2 Practitioner Version 7
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
1.1 Current Exam Facts 1.2 Exam Strategy & Open-Book Technique
2 PRINCE2 7 Method Overview
2.1 The PRINCE2 7 Method 2.2 What Changed in PRINCE2 7 2.3 Performance Targets, Tolerances & Project Context
3 PRINCE2 Principles (1–4)
3.1 Continued Business Justification 3.2 Learn from Experience 3.3 Defined Roles, Responsibilities & Relationships 3.4 Manage by Stages
4 PRINCE2 Principles (5–7) & Applying Principles
4.1 Manage by Exception 4.2 Focus on Products 4.3 Tailor to Suit the Project 4.4 Applying Principles in Context
5 People Management in Projects
5.1 Organisational & Project Ecosystems 5.2 Leadership in Projects 5.3 Team Culture & Diversity 5.4 Communication, Stakeholder Engagement & Change Management
6 Practices Overview & Business Case
6.1 The Seven Practices & Tailoring 6.2 Business Case: Desirability, Viability & Achievability 6.3 Business Case Lifecycle & Management Products 6.4 Business Case Application & Tailoring Scenarios
7 Practices: Organising & Plans
7.1 Organising: Roles & Accountability 7.2 Organising: 5-Step Ecosystem Technique 7.3 Plans: Three Levels & Product-Based Planning 7.4 Plans: Techniques, Tolerances & Tailoring
8 Practices: Quality & Risk
8.1 Quality: Planning, Control & Assurance 8.2 Quality Techniques & Management Products 8.3 Risk: Threats & Opportunities 8.4 Risk 5-Step Technique & Application
9 Practices: Issues
9.1 Issues Practice: Issue vs Change & Categories 9.2 Issues 5-Step Technique & Supporting Techniques 9.3 Change Control, Configuration & Priority/Effort Assessment
10 Practices: Progress, Sustainability & Application
10.1 Progress: Controls, Tolerances & Reports 10.2 Sustainability as the 7th Performance Target 10.3 Tailoring the Practices 10.4 Practices Application Scenarios (BL4)
11 Processes: Model, Starting, Directing & Initiating
11.1 The Seven Processes & Process Model 11.2 Starting Up a Project 11.3 Directing a Project 11.4 Initiating a Project
12 Processes: Controlling a Stage & Product Delivery
12.1 Controlling a Stage 12.2 Managing Product Delivery 12.3 Stage Control & Exception Scenarios (BL4) 12.4 Work Packages & Reporting Cycle
13 Processes: Stage Boundary, Closing & Tailoring
13.1 Managing a Stage Boundary 13.2 Closing a Project 13.3 Tailoring the Processes 13.4 Process Application Scenarios (BL4)
14 Tailoring, Management Products & Exam Technique
14.1 Tailoring to Project Environment, Scale & Agile 14.2 Management Products & the v7 Project Log 14.3 Final Exam Technique, Full Scenarios & Common Traps
4.4 Applying Principles in Context
Key Takeaways Explain This Topic AI
All seven PRINCE2 principles are mandatory and interdependent; a breach of one usually undermines others.
Analysis-level questions require recognising which principle a described action breaches, not just reciting the principle.
Common breach symptoms map to specific principles: cancelled stage boundaries breach manage by stages; building before agreeing quality criteria breaches focus on products; continuing without funding breaches continued business justification.
Principles cannot be traded off against one another — applying six does not excuse omitting the seventh.
Last updated: August 2026
Principles Are Mandatory and Interdependent
The seven PRINCE2 principles are mandatory : every project claiming to use PRINCE2 must apply all seven. They are also interdependent — a decision that breaches one usually undermines others. Analysis-level (Bloom's Level 4) exam questions test your ability to look at a described action and identify which principle is breached, and often which secondary principles are weakened as a consequence.
The seven principles
Continued business justification — a project exists only while its Business Case remains viable.
Learn from experience — lessons are sought, recorded, and acted on throughout.
Define roles and responsibilities — everyone knows who does what and who decides what.
Manage by stages — the project is controlled through accountable management stages.
Manage by exception — authority is delegated with tolerances; escalation happens on breach.
Focus on products — the project delivers outputs with agreed quality, not activity.
Tailor to suit the project — the method is scaled to context, never applied verbatim.
Principle → breach symptom table
- Breach symptom (what you observe) Principle breached
- Project continues after the Business Case is no longer viable Continued business justification
- Lessons from a previous project are ignored or never recorded Learn from experience
- No one knows who has authority to approve changes Define roles and responsibilities
- Stage boundaries skipped or combined without board authority Manage by stages
- PM silently absorbs a stage tolerance breach instead of reporting it Manage by exception
- Team builds before quality criteria are agreed Focus on products
- Board removes all controls and calls it tailoring Tailor to suit the project
- Worked scenario analyses
Scenario A — cancelled stage boundary review. The Project Manager cancels the stage boundary review to save time and moves straight into the next stage.
Primary breach: Manage by stages. The stage boundary is where the Project Board reviews the completed stage, checks the Business Case, and authorises the next stage. Skipping it removes board control between stages.
Secondary breach: Continued business justification is weakened because the Business Case is not re-checked at the boundary; Manage by exception is weakened because stage tolerance performance is not formally reported.
Scenario B — building before agreeing quality criteria. The team starts building the product before the Product Description's quality criteria are agreed, to hit an early milestone.
Primary breach: Focus on products. Quality criteria must be agreed before development so done is defined.
Secondary breach: Manage by exception is weakened because without quality criteria there is no quality tolerance to monitor; Learn from experience is weakened if this rework pattern was seen before and not acted on.
Scenario C — continuing after sponsor withdraws funding. The Project Board continues the project after the main sponsor withdraws funding, hoping a new sponsor will appear.
Primary breach: Continued business justification. Without funding and an active sponsor, the Business Case is not viable.
Secondary breach: Define roles and responsibilities is breached because the Executive role is unfilled; Manage by stages is weakened because the board authorising the next stage without a viable Business Case defeats the stage gate's purpose.
Scenario D — PM absorbs the tolerance breach. The Project Manager forecasts that the stage will exceed its cost tolerance but does not raise an Exception Report, hoping to recover by stage end.
Primary breach: Manage by exception. A forecast breach must trigger an Exception Report to the level above.
Secondary breach: Manage by stages is weakened because the board cannot make an informed stage decision without the exception information.
Why you cannot trade off principles
A common distractor in exam questions is a justification such as 'we skipped the stage boundary because the project is small, so tailoring applies.' This conflates tailoring with abandoning controls. Tailoring scales the form of the stage boundary; it does not remove the board's authority to authorise the next stage. The principles do not offset each other — applying six does not excuse omitting the seventh.
Approach for analysis questions
Read the scenario for the action taken , not the intention stated .
Identify which control or expectation the action removes or weakens.
Map that to the principle whose purpose is undermined.
Check for secondary breaches — a single action often weakens two or three principles.
Reject distractors that confuse tailoring with abandonment, or activity with output.