Practitioner exam lens
This independent Quick Reference supports candidates preparing for the PeopleCert PRINCE2 Project Management Practitioner (Version 7) exam, code PRINCE2 Practitioner. Practitioner questions are scenario-driven: the best answer is usually the one that applies PRINCE2 governance, roles, tolerances, products, and tailoring to the facts given.
Use this decision lens on every scenario:
- Which process is active? Starting up, initiating, controlling a stage, managing delivery, stage boundary, directing, or closing.
- Which role has authority? Project manager, team manager, project board, executive, senior user, senior supplier, change authority, or business layer.
- Is tolerance forecast to be exceeded? If yes, escalate by exception to the correct level.
- Which management product should be created or updated? Business case, PID, plan, register, report, work package, product description, etc.
- Which principle is being protected? Business justification, stages, exception, products, roles, lessons, or tailoring.
- What people factor matters? Stakeholder relationship, communication, leadership, culture, collaboration, or change impact.
PRINCE2 method map
| Element | What it means | Practitioner use |
|---|
| Principles | Mandatory guiding obligations for a PRINCE2 project | If an answer violates a principle, it is usually wrong even if it sounds efficient |
| People | Leadership, relationships, stakeholder engagement, collaboration, and change adoption | Do not treat delivery as only documents and controls; consider affected people |
| Practices | Business case, organizing, plans, quality, risk, issues, progress | Select the right practice to handle the scenario problem |
| Processes | The lifecycle activities and decision points | Identify where the project is and what should happen next |
| Project context | Size, complexity, delivery method, commercial model, culture, sustainability, digital/data context | Tailor without removing PRINCE2 control |
Seven principles: high-yield distinctions
| Principle | Practical meaning | Common exam trap |
|---|
| Continued business justification | The project must remain desirable, viable, and achievable | Continuing because money has already been spent |
| Learn from experience | Capture and apply lessons before, during, and after the project | Waiting until closure to think about lessons |
| Defined roles, responsibilities, and relationships | Business, user, supplier, and project management interests must be clear | Letting the project manager make project board decisions |
| Manage by stages | Plan, authorize, monitor, and control one management stage at a time | Planning the entire project in excessive detail too early |
| Manage by exception | Delegate authority with tolerances; escalate only forecast breaches | Escalating every minor variance or hiding a forecast breach |
| Focus on products | Define outputs, quality criteria, and acceptance before activities | Building an activity schedule before agreeing products |
| Tailor to suit the project | Adapt PRINCE2 to context while preserving principles | Removing governance because the project is small or agile |
Roles and decision rights
| Role | Represents / focus | Key responsibilities | Practitioner traps |
|---|
| Business layer | Sponsoring organization, programme, customer, or commissioning context | Provides mandate, appoints executive, sets project-level constraints and tolerances | Confusing business-layer approval with day-to-day project board direction |
| Project board | Overall direction within delegated authority | Authorizes initiation, project, stages, exceptions, and closure | Board should not manage daily work |
| Executive | Business interest; value for money | Owns business case; accountable for project success | Senior user or project manager does not own the business case |
| Senior user | User needs, benefits, operational impact | Specifies needs, confirms acceptance, ensures benefits are realized | Senior supplier should not decide whether user benefits are adequate |
| Senior supplier | Supplier resources, technical integrity, deliverability | Confirms feasibility and supplier capability | Supplier interest is not the same as business justification |
| Project manager | Day-to-day management within stage tolerances | Plans, controls, reports, manages risks/issues, agrees work packages | PM cannot approve a forecast breach of stage tolerance |
| Team manager | Delivers specialist products | Accepts work packages, manages team plans, reports checkpoints, delivers products | Team manager does not authorize changes beyond the work package |
| Project assurance | Independent checking on behalf of the board | Assures business, user, and supplier interests | Not the same as project support or quality control |
| Project support | Administrative and configuration support | Maintains records, tools, logs, configuration information if delegated | Support does not make governance decisions |
| Change authority | Delegated authority for certain changes | Approves/rejects changes within delegated limits and budget | Major impacts still escalate to project board or business layer |
| Stakeholders | Affected or interested parties | Provide input, acceptance, constraints, and adoption support | Ignoring stakeholder resistance can threaten benefits |
Tolerance and exception control
PRINCE2 controls delegation through tolerances. The project manager acts within agreed tolerances; a forecast breach triggers exception handling.
| Control level | Tolerance set by | Managed by | If forecast tolerance will be exceeded |
|---|
| Project | Business layer | Project board | Project board escalates to business layer |
| Stage | Project board | Project manager | Project manager raises an exception report to the project board |
| Work package | Project manager | Team manager | Team manager alerts project manager; work package may be replanned or escalated |
| Product quality | Product description / acceptance criteria | Responsible producer and approver | Treat as quality failure, off-specification, or issue depending on impact |
| Risk | Risk management approach / delegated limits | Risk owners and project manager | Escalate if risk exposure threatens agreed tolerance |
| Benefits | Business case / benefits management approach | Executive and senior user | Reassess continued business justification |
| Sustainability | Defined targets and constraints where applicable | Relevant accountable roles | Escalate if forecast impact breaches agreed tolerance |
Exception decision path
flowchart TD
A[Variance, issue, risk, or change identified] --> B{Can current plan still meet tolerance?}
B -- Yes --> C[Manage within delegated authority]
C --> D[Update relevant register, plan, or report]
B -- No, forecast breach --> E{Which tolerance level?}
E -- Work package --> F[Team manager escalates to project manager]
E -- Stage --> G[Project manager raises exception report to project board]
E -- Project --> H[Project board escalates to business layer]
G --> I{Board decision}
I -- Request recovery plan --> J[Prepare exception plan]
I -- Stop project --> K[Premature closure route]
I -- Continue with direction --> L[Update controls and baselines]
Seven processes: purpose, products, and likely next action
| Process | Purpose | Key products / decisions | Best “what next?” clues |
|---|
| Starting up a Project | Decide whether the idea is worth initiating | Project mandate reviewed, executive and project manager appointed, previous lessons captured, project brief, outline business case, project product description, initiation stage plan | If the scenario is only an idea or mandate, do not jump to full PID; first confirm viability and prepare the project brief |
| Directing a Project | Enable the project board to make key decisions and provide overall control | Authorize initiation, authorize project, authorize stage or exception plan, give ad hoc direction, authorize closure | If a decision exceeds PM authority, the board directs rather than the PM deciding alone |
| Initiating a Project | Establish firm foundations before delivery investment | PID, detailed business case, project plan, management approaches, controls, refined roles | If the board needs confidence before delivery, complete and approve the PID |
| Controlling a Stage | Manage current stage within tolerances | Work packages, highlight reports, issue/risk actions, corrective action, stage progress control | If delivery is underway, PM assigns work, monitors, manages issues/risks, and reports |
| Managing Product Delivery | Control the interface between PM and specialist teams | Work package acceptance, team plan, checkpoint reports, completed products | If the team is doing specialist work, focus on work package agreement, reporting, and product approval |
| Managing a Stage Boundary | Review current stage and plan the next | End stage report, next stage plan, updated business case, updated PID, exception plan if requested | If a stage is ending or tolerances cannot be recovered, update justification and seek authorization |
| Closing a Project | Confirm acceptance and close in an orderly way | Product acceptance, handover, end project report, lessons, follow-on actions, benefits review arrangements | If products are complete or project is stopped, verify acceptance, hand over, evaluate, and recommend closure |
Practice-by-practice reference
| Practice | Core question | Main artifacts | High-yield decisions |
|---|
| Business case | Is the project still justified? | Business case, benefits management approach, project brief, PID, end stage/end project inputs | Stop, re-scope, or escalate if justification weakens |
| Organizing | Who is accountable for what? | Project management team structure, role descriptions, communication approach | Separate business, user, supplier, assurance, support, and delivery responsibilities |
| Plans | What products will be delivered, when, by whom, and within what tolerance? | Project plan, stage plan, team plan, exception plan, product descriptions, work packages | Use product-based planning before activity scheduling |
| Quality | What makes the product fit for purpose? | Project product description, product descriptions, quality management approach, quality register | Define measurable criteria and approval responsibilities before work starts |
| Risk | What uncertain events may affect objectives? | Risk management approach, risk register, risk responses, risk budget where used | Distinguish uncertain risk from current issue |
| Issues | What has happened or what change is requested? | Issue register, issue reports, change control records, product status information | Classify, assess impact, decide through delegated authority |
| Progress | Are we on track and still within tolerance? | Highlight reports, checkpoint reports, end stage reports, exception reports, end project report | Forecast, compare to tolerance, escalate only by exception |
Management products: quick selection table
| Product | Use it when | Owned / driven by | Key exam distinction |
|---|
| Project mandate | The business layer has an initial project idea or requirement | Business layer | Input to Starting up a Project, not a full plan |
| Project brief | The board needs enough information to authorize initiation | Project manager with executive input | Created before PID; contains outline business case |
| Project product description | The overall project output and acceptance criteria must be clear | Project manager, senior user, board approval | Supports product focus and final acceptance |
| PID | The board needs a baseline for project authorization | Project manager prepares; board approves | Foundation for governance, controls, plans, and approaches |
| Business case | Justification must be assessed or updated | Executive owns | Must remain valid throughout the project |
| Benefits management approach | Benefits need measurement after delivery | Executive and senior user | Benefits may occur after project closure |
| Communication management approach | Stakeholder communication needs planning | Project manager with board input | People and relationships are actively managed |
| Plan | Project, stage, team, or exception planning is needed | Depends on plan level | Match plan to authority level |
| Product description | A product’s quality and approval need definition | Product owner/producer with PM control | Defines quality criteria and tolerances |
| Work package | The PM delegates product delivery to a team | Project manager and team manager | Agreement between management and delivery |
| Quality register | Planned and completed quality activities need tracking | Project manager / project support | Evidence of quality control activity |
| Risk register | Uncertain threats and opportunities need tracking | Project manager, risk owners | Risk has not yet happened |
| Issue register | Current problems, concerns, requests for change, or off-specifications need tracking | Project manager / project support | Issue has happened or is being formally requested |
| Issue report | A significant issue needs analysis and decision | Project manager | Used when register entry alone is insufficient |
| Highlight report | Board needs regular stage progress information | Project manager | Time-driven report from PM to board |
| Checkpoint report | PM needs team progress information | Team manager | Time-driven report from team to PM |
| End stage report | Board must assess stage performance and next stage | Project manager | Supports authorization of next stage |
| Exception report | Forecast tolerance breach needs escalation | Project manager or board depending on level | Comes before exception plan authorization |
| Exception plan | A replacement plan is requested after an exception | Project manager or relevant planner | Not produced casually for every variance |
| End project report | Board needs final performance evaluation | Project manager | Supports closure authorization |
| Lessons log / lessons report | Experience must be captured and shared | All contribute; PM manages | Lessons are used throughout, not only at the end |
| Daily log | Informal notes, actions, or minor issues need capture | Project manager | Do not over-formalize every small item |
Plan levels and when to use them
| Plan type | Covers | Approved by | Use when |
|---|
| Project plan | Whole project at a level suitable for board control | Project board | Authorizing the project and monitoring overall progress |
| Stage plan | One management stage in detail | Project board | Authorizing and controlling the next stage |
| Team plan | Specialist team work, if useful | Team manager / PM agreement | Delivery team needs its own detailed plan |
| Exception plan | Remainder of current plan after exception | Same authority level as replaced plan | A forecast breach means the original plan is no longer viable |
Product-based planning sequence
- Write or refine the project product description.
- Identify major products and create the product breakdown structure.
- Write product descriptions with quality criteria and approval responsibilities.
- Identify product dependencies with a product flow view.
- Add activities, estimates, resources, schedule, risks, and controls.
Trap: in PRINCE2, the plan should be driven by products and quality expectations, not by a task list alone.
Business case and benefits
| Term | Meaning | Example distinction |
|---|
| Output | Specialist product delivered by the project | New claims system |
| Outcome | Result of using the output | Claims processed faster |
| Benefit | Measurable improvement valued by stakeholders | Reduced processing cost |
| Disbenefit | Measurable negative consequence accepted as part of the project | Temporary productivity drop during transition |
| Risk | Uncertain event that may affect objectives | Supplier may miss a critical milestone |
| Issue | Event or request that has occurred or requires action now | Supplier has missed the milestone |
Business case decision points:
| Scenario | Strong PRINCE2 response |
|---|
| Benefits are no longer achievable | Update business case and escalate; do not continue automatically |
| Costs increase but tolerance is not forecast to be exceeded | PM manages within delegated authority and reports normally |
| Costs increase and project justification is doubtful | Executive and board reassess continued business justification |
| Senior user says benefits will be realized after closure | Ensure benefits management approach defines post-project measurement |
| Project is technically successful but users will not adopt it | Treat as a business justification and stakeholder/change issue, not only a delivery issue |
Quality practice distinctions
| Concept | Meaning | Exam clue |
|---|
| Customer quality expectations | Broad expectations for the project product | Captured early, often in project product description |
| Acceptance criteria | Measurable conditions for accepting the project product | Used at closure to confirm acceptance |
| Quality criteria | Product-level measures of fitness for purpose | Found in product descriptions |
| Quality tolerance | Permitted range for a quality criterion | A product may pass if within agreed tolerance |
| Quality planning | Define standards, criteria, methods, responsibilities | Should occur before product creation |
| Quality control | Inspect, test, review, or approve products | Evidence tracked in quality register |
| Quality assurance | Independent check that processes and standards are appropriate | Outside day-to-day product checking |
| Project assurance | Board’s independent view of project performance and interests | Business, user, and supplier assurance |
Common trap: quality assurance checks the quality system or process; quality control checks the product; project assurance supports the project board’s governance responsibilities.
Risk practice reference
Risk describes uncertainty. Use a clear cause-event-effect structure:
- Cause: supplier has limited availability.
- Event: critical design review may be delayed.
- Effect: stage completion may exceed time tolerance.
If a quantitative scenario provides probability and impact, risk exposure may be estimated as:
\[
\text{Risk exposure} = \text{Probability} \times \text{Impact}
\]
| Response | Threat / opportunity | Use when |
|---|
| Avoid | Threat | Change plan so the threat can no longer occur or affect the project |
| Reduce | Threat | Lower probability or impact |
| Fallback | Threat | Prepare contingency if the threat occurs |
| Transfer | Threat | Move financial impact to another party, often through insurance or contract terms |
| Accept | Threat | Take no proactive action beyond monitoring |
| Exploit | Opportunity | Ensure the opportunity happens |
| Enhance | Opportunity | Increase probability or impact |
| Share | Both | Allocate risk and reward with another party |
| Reject | Opportunity | Decide not to pursue the opportunity |
Risk ownership distinctions:
| Role | Responsibility |
|---|
| Risk owner | Accountable for managing a specific risk |
| Risk actionee | Carries out agreed response actions |
| Project manager | Maintains risk process and escalates if tolerance is threatened |
| Project board | Provides direction and decisions for risks beyond PM authority |
Issues and change control
| Issue type | Meaning | Typical response |
|---|
| Request for change | Proposal to change an agreed baseline | Assess impact, decide through change authority or board |
| Off-specification | Product will not meet an agreed requirement | Assess impact on quality, scope, benefits, tolerance |
| Problem / concern | Any other issue requiring management action | Log, analyze, assign action, escalate if needed |
Issue procedure:
- Capture the issue.
- Examine type, cause, severity, and impact.
- Propose options and recommendation.
- Decide using delegated authority.
- Implement the decision and update records.
| Scenario | Best response |
|---|
| Minor issue within PM authority | Log and manage within stage tolerance |
| Change request within delegated change authority | Assess impact and route to change authority |
| Change request breaches stage tolerance | Raise exception report to project board |
| Product cannot meet agreed quality criteria | Treat as off-specification and assess effect on acceptance/business case |
| A risk has occurred | Convert or manage it as an issue; update issue and risk records |
| Stakeholder asks for “just a small change” | Do not bypass change control; assess cumulative impact |
Progress reporting and control
| Report / control | From | To | Purpose |
|---|
| Checkpoint report | Team manager | Project manager | Team progress against work package |
| Highlight report | Project manager | Project board | Regular stage status and forecast |
| End stage report | Project manager | Project board | Stage performance, lessons, updated justification |
| Exception report | PM or board, depending on level | Authority above | Forecast tolerance breach and options |
| End project report | Project manager | Project board | Final evaluation and closure recommendation |
Progress decision rules:
| Condition | Correct action |
|---|
| Actual variance but forecast remains within tolerance | PM takes corrective action and reports through normal controls |
| Forecast stage tolerance breach | PM escalates with exception report |
| Board wants recovery plan after exception | PM prepares exception plan |
| Forecast project tolerance breach | Board escalates to business layer |
| Stage end approaching | PM prepares end stage report and next stage plan |
| Project product complete | PM verifies acceptance and recommends closure |
“What should the manager do next?” matrix
| Scenario clue | Likely best next action | Role / product |
|---|
| Project idea received but no viability check | Start up the project, capture lessons, prepare project brief | PM, executive |
| Need authority to spend on delivery | Complete PID and seek project authorization | Project board |
| Team is ready to begin specialist work | Agree work package before work starts | PM and team manager |
| Team forecasts work package tolerance breach | Team manager informs PM; PM decides or escalates | Work package, checkpoint |
| PM forecasts stage tolerance breach | Raise exception report | PM to project board |
| Board asks for a replacement stage plan | Prepare exception plan | PM |
| A requested change affects baselined scope | Use issue/change control | Issue register/report |
| Product quality is disputed | Check product description, quality criteria, approval method | Quality register |
| New stakeholder resistance threatens adoption | Review communication and stakeholder engagement approach | PM, senior user |
| Supplier solution is technically risky | Engage senior supplier, update risk register and plan responses | Senior supplier, PM |
| Business benefits are no longer credible | Update business case and escalate | Executive, board |
| Stage is ending | Update business case/PID, prepare end stage report and next stage plan | PM, board |
| Product delivered but not formally accepted | Confirm acceptance against project product description | Senior user, board |
| Project is no longer justified | Consider premature closure through proper direction | Executive, board |
Tailoring reference
Tailoring means adapting PRINCE2 to the project context while preserving principles and effective control.
| Context | Suitable tailoring | Do not do this |
|---|
| Small, low-risk project | Combine roles where no conflict of interest; simplify products; use lighter reporting | Remove business justification, stage control, or defined authority |
| Large or complex project | More formal assurance, configuration control, reporting, and stakeholder engagement | Let documentation replace decision-making |
| Agile or iterative delivery | Use product descriptions, acceptance criteria, tolerances, and work packages around increments or timeboxes | Assume agile delivery removes project board governance |
| Supplier / commercial delivery | Clarify senior supplier role, work package acceptance, contract constraints, change authority | Let contract management bypass PRINCE2 issue control |
| Programme environment | Align business case, benefits, dependencies, and reporting with programme controls | Duplicate governance unnecessarily |
| High-risk or regulated environment | Strengthen assurance, records, approvals, and quality evidence | Treat tailoring as reducing control |
| Sustainability-sensitive project | Include sustainability targets, risks, impacts, and reporting where relevant | Treat sustainability as separate from project performance |
| Digital/data-heavy project | Define data ownership, security, integration, quality, and operational handover needs | Leave acceptance criteria vague |
People, relationships, and stakeholder engagement
PRINCE2 7 gives explicit attention to people because projects require cooperation and change adoption.
| Situation | Strong response |
|---|
| Stakeholders misunderstand the project purpose | Improve communication using agreed stakeholder engagement approach |
| Users resist the new product | Involve senior user; address outcomes, benefits, training, and transition |
| Supplier and user disagree on quality | Use product descriptions, quality criteria, and defined approval responsibilities |
| Team lacks clarity on responsibilities | Review role descriptions, work package, and reporting lines |
| Conflict threatens progress | Escalate through defined roles only when it cannot be resolved within authority |
| Cultural or organizational change is significant | Plan engagement, leadership actions, and communication, not only technical delivery |
| Benefits depend on operational adoption | Ensure senior user and business stakeholders own benefit realization actions |
Common Practitioner traps
| Trap answer | Why it is weak | Better PRINCE2 logic |
|---|
| PM approves a major change because it is urgent | May exceed delegated authority | Assess impact and route through change control or exception |
| Board asks for daily task updates | Board should direct by exception, not micromanage | PM reports through highlight reports and exceptions |
| Senior supplier decides whether benefits are acceptable | Benefits are user/business concern | Senior user and executive assess benefits and justification |
| Project continues despite invalid business case | Violates continued business justification | Escalate and consider closure or re-scope |
| Detailed full-project schedule is created before products are defined | Violates focus on products | Use product-based planning |
| Exception plan is produced for a small variance within tolerance | Over-control | PM manages corrective action within tolerance |
| Exception report is delayed until tolerance is actually exceeded | Exception is based on forecast breach | Escalate when breach is forecast |
| Lessons are documented only at closure | Lessons should be applied throughout | Use lessons log from startup onward |
| Quality issue is handled as a personal dispute | PRINCE2 uses objective criteria | Refer to product description and quality records |
| Tailoring removes project board approval | Tailoring cannot remove principles | Simplify, but keep governance fit for risk |
Final review checklist
Before answering a PRINCE2 Practitioner scenario question, confirm:
- The answer protects continued business justification.
- The decision is made by the right role.
- The action matches the current process.
- The response respects tolerances and exception rules.
- The correct management product is created or updated.
- Product, quality, risk, issue, and benefit impacts are considered.
- Stakeholder and people impacts are not ignored.
- Tailoring is proportionate but does not remove PRINCE2 principles.
Next step: practise with scenario questions by forcing yourself to identify the active process, responsible role, tolerance position, management product, and principle before reading the answer options.