PRINCE2 Foundation — PRINCE2 Project Management Foundation (Version 7) Quick Reference

Last revised: July 1, 2026

Compact PRINCE2 7 Foundation reference for principles, practices, processes, roles, products, tailoring, and exam traps.

Exam identity and how to use this page

Item	Reference
Provider	PeopleCert
Official exam title	PRINCE2 Project Management Foundation (Version 7)
Official exam code	PRINCE2 Foundation
Page purpose	Independent Quick Reference for rapid review before practice questions
Best use	Rehearse definitions, role responsibilities, process flow, product purpose, and “what happens next” decisions

For Foundation-level questions, expect emphasis on recognition and understanding: which PRINCE2 element applies, who is responsible, which management product is used, what process happens next, and how principles govern decisions.

PRINCE2 at a glance

PRINCE2 is a project management method built around governance, delegation, product focus, justification, and controlled progress. It does not prescribe a technical delivery method; it can be tailored for predictive, iterative, agile, supplier-led, internal, or hybrid environments.

Core concepts

Concept	Exam-ready meaning	Common trap
Project	Temporary organization created to deliver one or more business products according to an agreed Business Case	Not the same as business-as-usual operations
Product	Any input or output, especially specialist products delivered by the project	PRINCE2 plans around products before activities
Output	The delivered product or capability	Output is not automatically a benefit
Outcome	Result of using the output	Benefits normally depend on adoption and use
Benefit	Measurable improvement perceived as advantageous by stakeholders	Benefits may be realized after project closure
Dis-benefit	Measurable negative outcome accepted as a consequence of the project	Not the same as a risk; it is expected if the project proceeds
Risk	Uncertain event or set of events that would affect objectives	Future uncertainty, not a current problem
Issue	Relevant event that has happened, is happening, or requires management action	Includes change requests, off-specifications, problems, concerns
Tolerance	Permissible deviation before escalation is required	If forecast to exceed tolerance, it is an exception
Exception	Forecast or actual breach of agreed tolerance	PRINCE2 escalates by exception, not every minor variance

Five integrated elements

Element	What to know for the exam
Principles	Universal obligations. If all principles are not applied, it is not a PRINCE2 project.
People	Projects depend on people, relationships, leadership, collaboration, communication, and change adoption.
Practices	Recurring aspects of project management: Business Case, Organizing, Plans, Quality, Risk, Issues, Progress.
Processes	Step-by-step lifecycle management from pre-project startup through closure.
Project context	PRINCE2 must be tailored to environment, scale, complexity, risk, importance, capability, delivery approach, and commercial setting.

Seven project performance aspects

PRINCE2 Version 7 uses these performance aspects when setting targets, monitoring progress, and applying tolerances.

Aspect	What is controlled	Example exam cue
Time	Schedule, milestones, deadlines	“The stage will finish two weeks late”
Cost	Budget and expenditure	“The forecast spend exceeds the stage budget”
Scope	Products and required features	“A new requirement is proposed”
Quality	Fitness for purpose and acceptance/quality criteria	“The product does not meet the agreed tolerance”
Benefits	Expected measurable improvements	“The expected savings are no longer achievable”
Risk	Exposure to uncertainty	“A threat may affect delivery”
Sustainability	Environmental, social, or sustainability-related targets and constraints	“A supplier choice affects sustainability targets”

The seven PRINCE2 principles

Principle	Meaning	High-yield exam signal	Trap to avoid
Ensure continued business justification	The project must remain desirable, viable, and achievable	Business Case is reviewed at key decision points	A project should not continue just because money has already been spent
Learn from experience	Use lessons from previous and current work	Lessons Log, Lessons Report, reviewing prior projects	Lessons are not only captured at closure
Define roles, responsibilities and relationships	Everyone knows accountability, decision rights, and working relationships	Project Board, Project Manager, Team Manager, assurance roles	Stakeholders are not automatically decision-makers
Manage by stages	Plan, authorize, and control one management stage at a time	Stage boundaries, next Stage Plan, End Stage Report	Management stages are not necessarily technical phases
Manage by exception	Delegate authority using tolerances and escalate only forecast breaches	Time/cost/scope/quality/benefits/risk/sustainability tolerance	The Project Manager does not escalate every small variance
Focus on products	Define products and quality expectations before planning work	Project Product Description, Product Descriptions, product-based planning	Activity lists without product definitions are weak PRINCE2 planning
Tailor to suit the project	Adapt method to context while preserving principles	Scaling roles, products, controls, language, formality	Tailoring is not omitting governance or justification

People, stakeholders, and change

PRINCE2 7 makes people an integrated element because project success depends on more than plans and controls.

Topic	Foundation reference
Stakeholder	Any individual, group, or organization that can affect, be affected by, or perceive itself affected by the project
Stakeholder engagement	Identify stakeholders, understand interests, plan communication, manage involvement, and respond to concerns
Communication	Planned through the Communication Management Approach; should be two-way, timely, audience-specific, and relevant
Change management	Helps people move from current ways of working to the future state needed for outcomes and benefits
Collaboration	Encourages shared understanding across business, user, and supplier interests
Leadership	Adapts style to context, supports decision-making, removes obstacles, and reinforces project objectives
Effective teams	Need clear roles, trust, competence, agreed ways of working, and empowerment within tolerances

Scenario wording	Likely answer logic
“Users will not adopt the new process”	This threatens outcomes and benefits; address stakeholder engagement/change management, not only product delivery
“A stakeholder has not been informed of a decision affecting them”	Review communication arrangements and stakeholder needs
“The team is unclear who can approve a change”	Organizing and issue/change control responsibilities need clarification
“A supplier team is waiting for direction”	Check Work Package agreement, Team Manager role, and Project Manager communication
“Senior management wants every minor decision escalated”	Use management by exception with agreed tolerances

Roles and responsibilities

Project organization structure

Role	Primary responsibility	Key decisions/products	Common trap
Business layer	Commissions the project, provides mandate, sets project-level tolerances	Project mandate, project-level direction	Outside day-to-day project management
Project Board	Overall direction and management within constraints set by the business layer	Authorizes initiation, project, stages, exceptions, closure	Directs; does not manage daily delivery
Executive	Ultimate accountability for project success and Business Case	Owns Business Case; chairs Project Board	Not merely a sponsor name on a chart
Senior User	Represents those who use products and realize benefits	User needs, benefits, acceptance perspective	Benefits realization often extends beyond closure
Senior Supplier	Represents supplier interests and delivery capability	Feasibility, supplier resources, technical integrity	Not the same as Team Manager unless tailored that way
Project Manager	Day-to-day management within stage tolerances	Plans, reports, issues, risks, Work Packages	Cannot simply approve own tolerance breaches
Team Manager	Manages creation of products in a Work Package	Team Plans if used, Checkpoint Reports, completed products	Responsible for delivery of assigned products, not project governance
Project Assurance	Independently checks project is being conducted properly for business, user, and supplier interests	Assurance reviews and advice	Should remain independent from the Project Manager
Project Support	Administrative, tool, configuration, and information support	Registers, filing, version control, logistics	Supports management; does not direct the project
Change Authority	Decides issues/changes within delegated limits	Approve/reject/defer changes, concessions	Cannot approve beyond delegated authority or tolerance
Stakeholders	Provide needs, feedback, constraints, influence, acceptance input	Engagement and communication inputs	Not every stakeholder sits on the Project Board

Accountability shortcuts

Question asks…	Look for…
Who owns the Business Case?	Executive
Who represents users and benefits?	Senior User
Who represents solution delivery capability?	Senior Supplier
Who manages the current stage daily?	Project Manager
Who delivers products in a Work Package?	Team Manager
Who provides independent checking?	Project Assurance
Who handles admin/configuration support?	Project Support
Who approves a delegated change?	Change Authority, if within authority; otherwise Project Board/business layer as appropriate

Management by exception

Level of control	Tolerance set by	Managed by	If tolerance is forecast to be exceeded
Project	Business layer	Project Board	Project Board escalates to business layer
Stage	Project Board	Project Manager	Project Manager sends Exception Report to Project Board
Work Package	Project Manager	Team Manager	Team Manager raises issue/escalates to Project Manager
Product quality	Product Description/quality criteria	Producer, reviewer, approver roles	Handle as quality failure, issue, or off-specification as appropriate

Key rule: Corrective action is taken at the lowest level that has authority. Escalate only when forecast performance exceeds delegated tolerance.

The seven PRINCE2 practices

Practice	Purpose	Main questions it answers	High-yield products/records	Exam trap
Business Case	Establish and maintain business justification	Why do this project? Is it still worthwhile?	Business Case, benefits information, updated justification	Business justification must continue, not just exist at startup
Organizing	Define and maintain accountability, responsibilities, and relationships	Who decides, manages, assures, delivers, supports?	Project management team structure, role descriptions, Communication Management Approach	A role may be combined only if accountability and independence remain clear
Plans	Facilitate communication and control by defining products, activities, resources, timing, and cost	What will be delivered, how, when, by whom, and within what tolerance?	Project Plan, Stage Plan, Team Plan, Exception Plan, Product Descriptions, Work Packages	PRINCE2 planning starts with products, not activity brainstorming
Quality	Define and verify products fit for purpose	What quality is required and how will it be checked?	Project Product Description, Product Descriptions, Quality Register, quality records	Acceptance criteria are project-level; quality criteria are product-level
Risk	Identify, assess, and control uncertainty	What might happen, what would it affect, and what response is planned?	Risk Management Approach, Risk Register	A risk is uncertain; an issue is already real or requires current action
Issues	Capture, assess, and resolve events affecting the project	What has happened or changed, and who decides?	Issue Register, Issue Report, change/issue control records	A request for change is not the same as an off-specification
Progress	Monitor and control actual vs planned achievement	Are we on track? Should we escalate? Can we continue?	Highlight Report, Checkpoint Report, End Stage Report, Exception Report, End Project Report	Progress control is based on forecasts as well as actuals

Business Case quick reference

Business justification chain

Term	Meaning	Example
Output	Product delivered by the project	New claims portal
Outcome	Change resulting from use of output	Customers submit claims online
Benefit	Measurable improvement	Lower processing cost
Dis-benefit	Expected negative outcome	Some staff roles require redesign
Risk	Uncertain effect	Vendor integration may fail
Business Case	Justification for investment	Costs, benefits, risks, options, timescales, rationale

Business Case decision points

When	What should happen
Starting up a Project	Create outline justification to decide whether initiation is worthwhile
Initiating a Project	Develop full Business Case as part of the project foundation
End of each stage	Confirm continued justification before committing to the next stage
Exception	Reassess justification if tolerances or expected benefits are threatened
Closing a Project	Confirm performance, acceptance, and future benefit review arrangements

Planning and product focus

Product-based planning

Step	Purpose
Define the Project Product Description	Clarifies overall deliverable, customer quality expectations, acceptance criteria, and acceptance method
Create a product breakdown structure	Shows major products and components
Write Product Descriptions	Defines each product’s purpose, composition, quality criteria, tolerances, method, and responsibilities
Create a product flow diagram	Shows sequence and dependencies between products
Derive activities, estimates, schedule, and resources	Activities support product delivery, not the other way around

Plan types

Plan	Level	Created/used by	Use
Project Plan	Project	Project Manager, Project Board	Overall delivery basis for Business Case and project control
Stage Plan	Management stage	Project Manager, Project Board	Detailed control for the next/current stage
Team Plan	Delivery team/work package	Team Manager, if used	Detailed delivery planning for assigned products
Exception Plan	Replacement plan	Prepared when requested after exception	Replaces a Project Plan, Stage Plan, or Team Plan after approval
Work Package	Control agreement, not just a plan	Project Manager and Team Manager	Authorizes product creation with constraints, tolerances, reporting, and acceptance

Plan selection traps

Scenario	Correct reference
“The Project Board needs enough information to authorize the whole project”	Project Plan in the PID
“The next management stage needs detailed planning”	Stage Plan
“The supplier team needs details to build assigned products”	Work Package and possibly Team Plan
“The current Stage Plan is no longer viable due to tolerance breach”	Exception Report first; Exception Plan if requested
“Acceptance criteria for the final project product are unclear”	Project Product Description
“Quality criteria for a component product are unclear”	Product Description

Quality quick reference

Quality concept	Meaning	Exam cue
Customer quality expectations	Broad expectations for the final product	Captured early in Project Product Description
Acceptance criteria	Prioritized measurable criteria for accepting the project product	Used at closure/acceptance
Quality criteria	Specific measurable attributes for an individual product	Found in Product Description
Quality tolerance	Permitted range for a quality criterion	“Must process 95–98% within target time”
Quality method	How quality will be checked	Test, review, inspection, demonstration
Quality responsibilities	Who produces, reviews, approves	Defined in Product Description
Quality Register	Record of planned and completed quality activities	Used to track quality control
Quality assurance	Independent check that quality processes are appropriate	Different from quality control of a product

Quality review technique

Role	Responsibility
Chair	Runs the review and ensures focus
Presenter	Represents the product and explains it
Reviewer	Reviews against criteria and identifies defects/questions
Administrator	Records results and actions

Exam cue: a quality review is mainly to check a product against agreed criteria and identify defects. It is not a general design workshop.

Risk quick reference

Risk structure

A well-stated PRINCE2 risk often follows cause → event → effect.

Element	Example
Cause	The third-party API is unstable
Event	Integration testing may fail
Effect	The release could be delayed and cost more

Risk procedure

Step	Purpose
Identify	Find threats and opportunities; record in Risk Register
Assess	Estimate probability, impact, proximity, and overall exposure
Plan	Select responses and assign owners/actionees
Implement	Carry out agreed responses
Communicate	Keep stakeholders informed through reports and records

Risk roles and responses

Item	Meaning
Risk owner	Accountable for managing, monitoring, and controlling a risk
Risk actionee	Carries out specific response actions
Threat responses	Avoid, reduce, transfer, share, accept, prepare fallback/contingency
Opportunity responses	Exploit, enhance, share, reject
Proximity	How soon the risk might occur
Secondary risk	New risk created by a response
Residual risk	Risk remaining after response

Issues and change control

Issue types

Issue type	Meaning	Example
Request for change	Proposal to change an approved baseline	Add a new reporting feature
Off-specification	Something required will not be delivered or will not meet specification	Product fails an agreed performance criterion
Problem/concern	Other matter requiring management action	Stakeholder complaint, supplier dispute, resource conflict

Issue handling logic

Step	Purpose
Capture	Record the issue; decide whether informal or formal
Assess	Analyze impact on performance aspects, Business Case, risks, plans, products
Propose	Identify options and recommendations
Decide	Use the appropriate authority: Project Manager, Change Authority, Project Board, or business layer
Implement	Update plans/products/records and communicate decision

Common issue decisions

Decision	Meaning
Approve	Accept the change or resolution
Reject	Do not proceed
Defer	Consider later
Grant concession	Accept an off-specification product without full correction
Request more information	Delay decision until impact is clearer
Escalate	Required when authority or tolerance would be exceeded

Progress controls and reports

Control/report	Direction	Timing	Purpose
Checkpoint Report	Team Manager to Project Manager	Time-driven	Work Package progress
Highlight Report	Project Manager to Project Board	Time-driven	Stage/project status summary
End Stage Report	Project Manager to Project Board	Event-driven	Review stage performance and support next-stage decision
Exception Report	Project Manager to Project Board	Event-driven	Report forecast breach of tolerance
End Project Report	Project Manager to Project Board	Event-driven	Summarize project performance and closure information
Lessons Log	Project team record	Continuous	Capture lessons as they arise
Lessons Report	Project Manager/team to relevant audience	Event-driven, often stage end or closure	Pass on useful lessons
Daily Log	Project Manager/project support	As needed	Informal issues, actions, notes not yet requiring formal registers

Progress decision table

Situation	What happens next
Work Package forecast remains within tolerance	Team Manager continues; reports via Checkpoint Reports
Work Package forecast exceeds tolerance	Team Manager raises issue/escalates to Project Manager
Stage forecast remains within tolerance	Project Manager may take corrective action
Stage forecast exceeds tolerance	Project Manager sends Exception Report to Project Board
Project forecast exceeds project tolerance	Project Board escalates to business layer
Stage is ending normally	Project Manager runs Managing a Stage Boundary activities
Project is complete or must close prematurely	Use Closing a Project; Project Board authorizes closure

Key management products

Product	Main purpose	Usually created/updated	Common exam distinction
Project mandate	Triggers the project; provided by the business layer	Pre-project	Input to Starting up a Project, not created by the Project Manager
Project Brief	Defines the project enough to decide whether to initiate	Starting up a Project	Less detailed than the PID
Project Initiation Documentation	Baseline for project governance and control	Initiating a Project; updated as needed	“Contract” between Project Manager and Project Board for how the project will be managed
Business Case	Documents justification	Outline in startup; detailed in initiation; updated throughout	Owned by Executive
Project Product Description	Defines final project product, acceptance criteria, and customer quality expectations	Startup/initiation; refined if needed	Project-level product definition
Product Description	Defines an individual product’s purpose, composition, quality criteria, and responsibilities	Planning	Product-level quality reference
Plan	Defines products, activities, schedule, cost, resources, controls	Startup/initiation/stage boundary/exception	Project, Stage, Team, or Exception level
Work Package	Agreement authorizing product creation	Controlling a Stage / Managing Product Delivery	Includes constraints, tolerances, reporting, and acceptance
Risk Register	Records identified risks and responses	Throughout	For uncertain future events
Issue Register	Records formal issues	Throughout	For current events, changes, off-specifications, concerns
Quality Register	Tracks planned and completed quality activities	Throughout delivery	Evidence of quality control
Lessons Log	Captures lessons during the project	Throughout	Not only at closure
Communication Management Approach	Defines stakeholder communication needs and methods	Initiation; updated as needed	Connects organizing, people, and stakeholder engagement
Risk Management Approach	Defines how risk will be managed	Initiation; updated as needed	Procedure, scales, responsibilities, reporting
Highlight Report	Keeps Project Board informed	During stages	From Project Manager to Project Board
Checkpoint Report	Keeps Project Manager informed	During Work Package delivery	From Team Manager to Project Manager
End Stage Report	Supports decision to continue	Stage boundary	Reviews completed stage
Exception Report	Escalates tolerance forecast breach	On exception	Comes before an Exception Plan is approved
Exception Plan	Replaces an approved plan after exception	If requested/authorized	Not created for every minor variance
End Project Report	Supports project closure	Closing a Project	Compares actual performance against baselines
Benefits review information	Defines how/when benefits will be measured	Initiation and closure updates	Benefits may be measured after closure

The seven PRINCE2 processes

    flowchart LR
	    M[Project mandate] --> SU[Starting up a Project]
	    SU --> DP1[Directing a Project: authorize initiation]
	    DP1 --> IP[Initiating a Project]
	    IP --> DP2[Directing a Project: authorize project]
	    DP2 --> CS[Controlling a Stage]
	    CS <--> MP[Managing Product Delivery]
	    CS --> SB[Managing a Stage Boundary]
	    SB --> DP3[Directing a Project: authorize next stage or exception plan]
	    DP3 --> CS
	    CS --> CP[Closing a Project]
	    CP --> DP4[Directing a Project: authorize closure]

Process reference table

Process	Purpose	Main actor	Key outputs/decisions	Common trap
Starting up a Project	Decide whether the idea is worth initiating	Executive and Project Manager	Project Brief, outline Business Case, initiation Stage Plan, project management team design	Startup is before full project authorization
Directing a Project	Enable Project Board decision-making and control	Project Board	Authorize initiation, project, stages/exception plans, ad hoc direction, closure	Runs throughout; not a single phase
Initiating a Project	Establish solid foundations before committing significant resources	Project Manager	PID, detailed Business Case, Project Plan, management approaches, controls	Initiation plans how the project will be managed
Controlling a Stage	Manage day-to-day work within a management stage	Project Manager	Work Packages authorized, progress monitored, issues/risks handled, Highlight Reports, Exception Reports	Project Manager acts within stage tolerance
Managing Product Delivery	Control the link between Project Manager and delivery teams	Team Manager	Accept Work Package, create products, quality-check, Checkpoint Reports, deliver completed products	Team Manager should not start work without agreed authorization
Managing a Stage Boundary	Review current stage and plan next stage	Project Manager	End Stage Report, next Stage Plan, updated Business Case/PID/risk info	Used at stage end or for exception planning, not at final closure
Closing a Project	Confirm acceptance and bring project to controlled closure	Project Manager, Project Board	End Project Report, handover, lessons, benefit review arrangements, closure recommendation	Closure is controlled even when premature

Process activity cues

If the question says…	Process likely involved
“Is this idea worth initiating?”	Starting up a Project
“Authorize initiation/project/next stage/closure”	Directing a Project
“Create the PID and detailed Business Case”	Initiating a Project
“Authorize Work Packages and manage stage progress”	Controlling a Stage
“Accept, execute, and deliver a Work Package”	Managing Product Delivery
“Prepare the next Stage Plan and End Stage Report”	Managing a Stage Boundary
“Confirm acceptance, hand over, and evaluate performance”	Closing a Project

Practice-to-process interaction

Practice	Strongest process links
Business Case	Started in Starting up a Project, developed in Initiating a Project, reviewed by Directing a Project and Managing a Stage Boundary, confirmed in Closing a Project
Organizing	Project management team designed in startup, refined in initiation, used throughout
Plans	Initiation Stage Plan in startup; Project Plan in initiation; Stage Plans at boundaries; Work Packages during stages
Quality	Acceptance expectations early; product quality planned and controlled during delivery
Risk	Identified and managed throughout; especially reviewed at stage boundaries and exceptions
Issues	Captured and controlled mainly during Controlling a Stage but can arise anytime
Progress	Reported and controlled through all management levels; central to Directing, Controlling, Managing Product Delivery, and Stage Boundaries

High-yield distinction table

Distinction	Know this
Project Brief vs PID	Project Brief supports authorization to initiate; PID supports authorization of the project
Project Plan vs Stage Plan	Project Plan is overall; Stage Plan is detailed for one management stage
Stage Plan vs Team Plan	Stage Plan is managed by Project Manager; Team Plan is delivery detail for Team Manager if used
Product Description vs Project Product Description	Product Description is for an individual product; Project Product Description is for the final project product
Acceptance criteria vs quality criteria	Acceptance criteria apply to final project acceptance; quality criteria apply to individual products
Checkpoint Report vs Highlight Report	Checkpoint: Team Manager to Project Manager; Highlight: Project Manager to Project Board
End Stage Report vs End Project Report	End Stage supports next-stage decision; End Project supports closure
Exception Report vs Exception Plan	Exception Report escalates a forecast breach; Exception Plan replaces a plan if requested and approved
Risk vs issue	Risk is uncertain; issue is current/relevant and requires action
Request for change vs off-specification	Request changes a baseline; off-spec means an agreed requirement will not be met
Project Assurance vs Project Support	Assurance independently checks; Support assists with administration and information
Project Board vs Project Manager	Board directs and authorizes; Project Manager manages day-to-day within tolerance
Benefits vs outputs	Outputs are delivered products; benefits come from using outputs
Tailoring vs weakening	Tailoring adapts controls; it does not remove principles

“What should the manager do next?” decision table

Scenario	Best PRINCE2 response
Project idea is vague but potentially worthwhile	Start up the project and prepare a Project Brief/outline Business Case
Project Board wants to decide whether to commit to full project delivery	Initiate the project and produce PID, Business Case, Project Plan
Team Manager says assigned product cannot be delivered within Work Package tolerance	Escalate to Project Manager as an issue
Project Manager forecasts stage tolerance will be exceeded	Create/send Exception Report to Project Board
Project Board believes project tolerance will be exceeded	Escalate to business layer
A user requests a new feature after baseline approval	Treat as request for change; assess impact and authority
A product will not meet agreed specification	Treat as off-specification; consider correction or concession
A risk response would exceed approved budget/tolerance	Escalate to appropriate authority
A stage is complete and the project should continue	Prepare End Stage Report and next Stage Plan through Managing a Stage Boundary
Final product is ready for acceptance	Use Closing a Project activities; confirm acceptance and handover
Business justification disappears	Escalate; Project Board/business layer decision may stop the project
Stakeholders are resisting the new ways of working	Address people/change management and communication, not only product delivery

Tailoring reference

Tailoring is the deliberate adaptation of PRINCE2 to the project context while keeping the principles intact.

Tailoring area	Examples
Roles	Combine roles in a small project if accountability and assurance independence remain clear
Products	Scale document formality; use tools, dashboards, or integrated repositories
Processes	Combine activities, adjust formality, or align stage boundaries with funding/release decisions
Practices	Adjust risk scales, issue thresholds, reporting frequency, quality methods
Controls	Set tolerances appropriate to risk, importance, complexity, and stakeholder needs
Language	Use organizational terminology while preserving PRINCE2 meaning
Delivery approach	Apply PRINCE2 governance to agile, iterative, predictive, supplier-led, or hybrid delivery

Agile/hybrid exam cues

Cue	PRINCE2 interpretation
“The team uses sprints/iterations”	PRINCE2 can still govern through stages, tolerances, products, and decisions
“Scope may flex but deadline is fixed”	Tolerances and prioritization must be clear; business justification remains central
“The delivery team self-organizes”	Team can be empowered within Work Package tolerances
“Frequent releases are planned”	Stage boundaries may align with major releases or governance decisions
“Product owner/user priorities change”	Handle through issue/change control and Business Case impact assessment

Last-minute Foundation checklist

Use this as a final scan before practice questions.

Can you list the seven principles and explain each in one sentence?
Can you identify the seven practices from scenario wording?
Can you put the seven processes in order and explain who acts in each?
Can you distinguish Project Brief, PID, Business Case, Project Plan, and Stage Plan?
Can you identify who sends Checkpoint, Highlight, Exception, End Stage, and End Project reports?
Can you distinguish risk, issue, request for change, off-specification, and problem/concern?
Can you explain management by exception at project, stage, and Work Package levels?
Can you identify the roles of Executive, Senior User, Senior Supplier, Project Manager, Team Manager, Project Assurance, and Project Support?
Can you explain why benefits are not the same as outputs?
Can you explain why tailoring must preserve all PRINCE2 principles?

Practical next step

Work timed PRINCE2 Foundation practice questions that ask which role, process, practice, or management product applies next. For every missed question, map the scenario back to one table above and note the trigger word that should have led you to the correct answer.

Scenario Guide

Project and PRINCE2 Key Concepts