PRINCE2 Practitioner — PRINCE2 Project Management Practitioner (Version 7) Exam Blueprint
Independent exam blueprint for PeopleCert PRINCE2 Project Management Practitioner (Version 7) candidates preparing for PRINCE2 Practitioner.
How to Use This Exam Blueprint
This independent checklist is for candidates preparing for the PeopleCert PRINCE2 Project Management Practitioner (Version 7) exam, exam code PRINCE2 Practitioner. Use it as a practical readiness map: not just “do I remember the term?” but “can I apply the PRINCE2 method to a project scenario?”
For each topic area, check whether you can:
- Identify the relevant PRINCE2 principle, practice, process, role, or management product.
- Decide what should happen next in a scenario.
- Choose who should act, approve, escalate, review, or provide assurance.
- Know which artifact should be created, updated, reviewed, or baselined.
- Tailor the method without weakening governance, accountability, business justification, or product focus.
A good final-review approach is to read a scenario and ask:
- Where are we in the project lifecycle?
- Which PRINCE2 process is active?
- Which practice is being tested?
- Which role has authority or accountability?
- Which management product needs to be used or updated?
- Is this within tolerance, or does it require escalation?
- How should the method be tailored for the project context?
Exam Identity
| Item | Details |
|---|---|
| Vendor / provider | PeopleCert |
| Official exam title | PRINCE2 Project Management Practitioner (Version 7) |
| Official exam code | PRINCE2 Practitioner |
| Professional area | Project management |
| Page purpose | Practical exam blueprint and readiness blueprint for review and practice |
Topic-Area Readiness Table
| Readiness area | What to review | You are ready when you can… | Common red flags |
|---|---|---|---|
| PRINCE2 principles | Continued business justification, lessons, roles, stages, exception, product focus, tailoring | Use a principle to justify the best action in a scenario | Memorizing principle names but not applying them |
| People in PRINCE2 7 | Stakeholders, relationships, communication, collaboration, change impact | Explain how people factors affect project decisions and adoption | Treating stakeholders as a communication list only |
| Business case practice | Justification, benefits, costs, risks, dis-benefits, continued viability | Decide when to update, challenge, escalate, or use the business case | Thinking the business case is only created at initiation |
| Organizing practice | Project board, executive, senior user, senior supplier, project manager, team manager, assurance, support | Assign accountability and decision authority correctly | Giving the project manager authority that belongs to the project board |
| Plans practice | Project plan, stage plan, team plan, exception plan, product-based planning | Choose the right planning level and plan update for a scenario | Confusing activity schedules with product-based planning |
| Quality practice | Acceptance criteria, quality specifications, quality control, quality assurance, quality register | Connect product descriptions to quality activities and acceptance | Testing quality only at the end |
| Risk practice | Threats, opportunities, risk responses, owners, actionees, risk register | Distinguish risk from issue and select appropriate response actions | Treating every uncertainty as an issue |
| Issues practice | Problems, concerns, requests for change, off-specifications, issue reports/registers | Assess impact, route decisions, and update baselines when appropriate | Approving changes without impact analysis |
| Progress practice | Tolerances, controls, reports, exceptions, stage boundaries | Decide whether to take corrective action or escalate | Escalating everything, or failing to escalate forecast exceptions |
| Processes | Starting up, directing, initiating, controlling, product delivery, stage boundary, closing | Identify the active process and next PRINCE2-consistent step | Choosing a technically reasonable action at the wrong lifecycle point |
| Management products | PID, business case, plans, registers, reports, work packages, product descriptions | Select the artifact that supports the decision or control | Knowing artifact names but not their purpose |
| Tailoring and context | Project scale, complexity, commercial setting, delivery approach, governance needs | Tailor PRINCE2 without removing essential controls | Assuming tailoring means skipping governance |
| Agile, predictive, and hybrid delivery | PRINCE2 governance over different delivery methods | Separate project direction/control from team delivery technique | Replacing PRINCE2 roles and controls with delivery-team rituals |
| Scenario judgment | “What should happen next?” “Who decides?” “What is updated?” | Justify answers using PRINCE2 logic, not generic PM preference | Choosing answers because they sound collaborative but lack authority |
Principles: Application Checklist
| PRINCE2 principle | Can you apply it? | Scenario cues to watch |
|---|---|---|
| Ensure continued business justification | Decide whether the project should continue, change direction, or close when benefits, costs, risks, or viability change | Benefits reduced, costs rise, strategic priority changes, major risk appears |
| Learn from experience | Use lessons from previous projects, current stage experience, and closure reviews | Repeated problems, new team members, prior project data, supplier history |
| Define roles, responsibilities, and relationships | Identify who is accountable, who makes decisions, and who provides assurance or delivery | Role conflict, unclear approvals, stakeholder disagreement, supplier/user tension |
| Manage by stages | Use stage boundaries for review, planning, and authorization | End of stage, need for next stage plan, major uncertainty ahead |
| Manage by exception | Compare forecast performance against agreed tolerances and escalate only when needed | Forecast breach, issue within tolerance, unclear authority level |
| Focus on products | Define outputs, quality expectations, acceptance criteria, and product dependencies | Vague deliverables, activity-focused planning, unclear acceptance |
| Tailor to suit the project | Adjust documentation, controls, roles, and processes to fit context while preserving PRINCE2 intent | Small project, complex supplier model, agile team, regulatory need, urgent delivery |
Principle Readiness Prompts
Check each item when you can do it in a scenario, not just define it.
- I can explain why a project should not continue without a valid business case.
- I can identify when a lesson should be captured, reviewed, or applied.
- I can separate accountability from responsibility and support.
- I can explain why project board authorization is needed at key decision points.
- I can decide whether an issue is within delegated tolerance or an exception.
- I can use product descriptions and acceptance criteria to resolve ambiguity.
- I can tailor a PRINCE2 control without eliminating the control’s purpose.
People and Stakeholder Readiness
PRINCE2 Practitioner candidates should be ready to apply the people element in context. The exam is likely to reward answers that preserve governance while also addressing collaboration, communication, stakeholder needs, and change impact.
| People topic | What to be ready for | Scenario decision cue |
|---|---|---|
| Stakeholder identification | Recognize affected groups, decision makers, users, suppliers, support teams, and governance bodies | “A key department was not consulted” |
| Stakeholder engagement | Select communication and involvement appropriate to influence, interest, and impact | “Users resist the new product” |
| Roles and relationships | Clarify reporting lines, escalation paths, and decision rights | “The team manager and project manager disagree” |
| Communication | Use the communication management approach and tailor frequency, content, and channel | “Senior leaders say they are surprised by project status” |
| Change impact | Consider adoption, training, business readiness, and benefits realization | “The product is delivered but users are not ready” |
| Collaboration | Encourage effective working while respecting PRINCE2 accountability | “The supplier wants informal acceptance” |
| Conflict and negotiation | Resolve issues at the right level and escalate when authority is exceeded | “Stakeholders cannot agree on scope priority” |
Can You Do This?
- Identify the stakeholder group most affected by a proposed change.
- Choose when to update the communication management approach.
- Recognize when poor engagement threatens benefits realization.
- Decide whether a conflict should be handled by the project manager, project board, or another authority.
- Explain how people risks can become delivery, benefits, or quality risks.
- Keep the distinction between collaborative behavior and formal approval.
Practices Checklist
Business Case Practice
| Review point | Ready means you can… |
|---|---|
| Purpose of the business case | Explain how it supports continued business justification |
| Benefits and dis-benefits | Distinguish positive outcomes from negative consequences |
| Ongoing review | Know when to review or update the business case: initiation, stage boundaries, major issues, exceptions, closure |
| Benefit ownership | Identify who is interested in realizing and confirming benefits |
| Decision support | Use the business case to recommend continuation, change, or closure |
| Link to risk and cost | Explain how risk exposure and cost changes affect justification |
| Benefits management | Recognize that some benefits may be realized after project closure |
Readiness prompts
- Can you identify when the business case is no longer credible?
- Can you decide whether a benefits change requires escalation?
- Can you connect product acceptance to expected benefits?
- Can you explain why “the project is already funded” is not enough justification to continue?
Organizing Practice
| Role or group | What to know | Common scenario trap |
|---|---|---|
| Project board | Directs the project and makes key authorization decisions | Assuming the project manager authorizes the whole project |
| Executive | Owns business justification and overall accountability | Giving business-case accountability to a supplier or user role |
| Senior user | Represents user needs and benefits interests | Ignoring user acceptance and operational readiness |
| Senior supplier | Represents supplier capability and delivery resources | Treating supplier concerns as purely technical |
| Project manager | Manages day-to-day project work within tolerance | Escalating matters the project manager can correct |
| Team manager | Delivers agreed work packages | Assuming team managers can change project baselines independently |
| Project assurance | Checks that the project is being conducted properly from business, user, and supplier perspectives | Confusing assurance with doing the project manager’s work |
| Project support | Provides administrative, tool, configuration, or information support as tailored | Overstating project support decision authority |
| Change authority | May be delegated authority for certain changes | Sending every change to the full project board |
Readiness prompts
- Can you identify the best role to approve a stage plan?
- Can you identify who should accept or reject a work package?
- Can you distinguish assurance from quality control?
- Can you determine when delegated change authority is enough?
- Can you map a stakeholder concern to the correct project board interest?
Plans Practice
| Planning topic | What to be ready for |
|---|---|
| Planning levels | Project plan, stage plan, team plan, and exception plan |
| Product-based planning | Start with products, descriptions, dependencies, and quality expectations |
| Product descriptions | Define purpose, composition, derivation, format, quality criteria, and acceptance needs where appropriate |
| Estimates and dependencies | Understand how uncertainty affects plans and tolerances |
| Tolerances | Connect time, cost, scope, quality, benefits, risk, and sustainability targets where defined |
| Stage planning | Plan in detail only as far as is sensible for the next stage |
| Exception planning | Replace a plan that is forecast to exceed tolerance when authorized |
| Tailoring | Scale planning detail to project complexity and risk |
Can you do this?
- Select the correct plan type for a project, stage, team, or exception situation.
- Explain why product descriptions reduce ambiguity.
- Identify when a plan should be updated versus replaced by an exception plan.
- Use stage boundaries to refine future planning.
- Avoid planning only as a task list without product acceptance criteria.
Quality Practice
| Quality topic | Ready means you can… |
|---|---|
| Quality planning | Define quality expectations, acceptance criteria, standards, responsibilities, and methods |
| Quality control | Confirm that products meet defined quality criteria |
| Quality assurance | Understand independent checking of project processes and standards |
| Product descriptions | Use them as the basis for quality criteria and review methods |
| Quality register | Track planned and completed quality activities |
| Acceptance | Link final acceptance to agreed criteria, not informal satisfaction |
| Tailoring | Adjust formality of reviews and records without losing evidence of quality |
Scenario cues
| If the scenario says… | Think about… |
|---|---|
| “Users disagree on whether the product is acceptable” | Acceptance criteria and product description |
| “Testing is delayed until the final week” | Quality planning and staged quality control |
| “Supplier says the product is technically complete” | User acceptance and quality criteria |
| “No one recorded the review results” | Quality register and evidence |
| “A defect is found after baseline approval” | Issue handling and impact assessment |
Risk Practice
| Risk topic | What to review |
|---|---|
| Risk vs issue | Risk is uncertain; issue has happened or is happening |
| Threats and opportunities | Be ready for both negative and positive uncertainty |
| Risk cause, event, effect | Identify why the risk exists, what may happen, and the impact |
| Probability and impact | Assess exposure in a way suitable for the project |
| Risk owner and actionee | Separate accountability for managing the risk from assigned response actions |
| Responses | Select suitable responses for threats or opportunities |
| Escalation | Escalate if risk exposure is outside tolerance or authority |
| Risk register | Record, assess, track, and update risks |
Readiness prompts
- Can you convert a vague concern into a clear risk statement?
- Can you tell when a risk has become an issue?
- Can you select a response that matches the risk and project authority?
- Can you identify when a risk threatens the business case?
- Can you update the risk register at the right point in a scenario?
Issues Practice
| Issue type or decision | What to be ready for |
|---|---|
| Problem or concern | Something affecting the project that needs management attention |
| Request for change | Proposed change to a baselined product or requirement |
| Off-specification | A product or forecast product not meeting specification |
| Impact analysis | Consider cost, time, scope, quality, risk, benefits, sustainability, and business case implications |
| Change authority | Know when decisions are delegated and when project board direction is needed |
| Baselines | Understand that approved changes may require baseline updates |
| Issue register and issue report | Track and analyze issues at the right level of detail |
| Configuration/product information | Know what product version or baseline is affected |
Can you do this?
- Decide whether a situation is a risk, issue, request for change, or off-specification.
- Identify which information is needed before approving a change.
- Decide whether the project manager can resolve the issue within tolerance.
- Determine when to escalate to the project board or change authority.
- Explain why an approved change may require updates to plans, product descriptions, business case, and registers.
Progress Practice
| Progress topic | Ready means you can… |
|---|---|
| Controls | Explain how PRINCE2 uses plans, tolerances, reports, and reviews to maintain control |
| Tolerances | Identify whether performance is within delegated authority |
| Highlight reports | Communicate stage progress to the project board |
| Checkpoint reports | Track team progress against work packages |
| End stage reports | Support project board decisions at stage boundaries |
| Exception reports | Escalate forecast breaches of tolerance |
| Corrective action | Know when the project manager should act without escalation |
| Stage authorization | Know when the project board should authorize next work |
Tolerance decision check
| Situation | Likely PRINCE2 response |
|---|---|
| Forecast remains within stage tolerance | Project manager manages corrective action and updates relevant records |
| Forecast exceeds stage tolerance | Project manager raises an exception to the project board |
| Project-level tolerance is threatened | Project board may need to escalate to corporate, programme, customer, or equivalent governance |
| Team work package is forecast to exceed agreed limits | Team manager informs project manager; project manager decides next action within authority |
| Approved exception plan is needed | Project board decides whether to authorize the exception plan |
Processes Checklist
| PRINCE2 process | Purpose in readiness terms | Can you identify these scenario signals? | Key outputs or artifacts to review |
|---|---|---|---|
| Starting up a Project | Decide whether the project idea is worth initiating | Project mandate, appointment of key roles, outline justification, initial lessons | Project brief, outline business case, project product description, initiation stage plan, lessons log |
| Directing a Project | Enable the project board to make key decisions and provide direction | Authorization requests, exceptions, stage approvals, closure recommendation | Authorizations, direction, decisions, approvals |
| Initiating a Project | Establish solid foundations before major commitment | Detailed planning, management approaches, controls, baselining | PID, business case, project plan, management approaches, registers |
| Controlling a Stage | Manage day-to-day stage work within tolerance | Work package authorization, issue/risk handling, progress reporting | Work packages, highlight reports, issue/risk updates, quality updates |
| Managing Product Delivery | Agree, execute, and deliver work packages | Team accepts work, creates products, checks quality, reports progress | Work package, checkpoint reports, completed products, quality records |
| Managing a Stage Boundary | Review current stage and prepare for next decision | End of stage, next stage plan, updated justification, lessons | End stage report, next stage plan, updated business case, updated project plan |
| Closing a Project | Confirm acceptance and close in an orderly way | Final product acceptance, handover, lessons, follow-on actions | End project report, lessons report, acceptance records, updated benefits information |
Process Readiness Questions
- If the scenario is before initiation, can you avoid choosing actions that belong later in the project?
- If the project is at a stage boundary, can you identify what must be reviewed before authorizing the next stage?
- If a team is delivering products, can you separate team manager responsibilities from project manager responsibilities?
- If a forecast exception occurs, can you route the decision through the correct governance path?
- If the project is closing, can you distinguish product handover, acceptance, lessons, and benefits follow-up?
Management Product and Artifact Checklist
| Management product / artifact | Main readiness use | Typical update or decision trigger |
|---|---|---|
| Project mandate | Starting point for considering the project | New project idea or external instruction |
| Project brief | Defines initial scope, justification, roles, and approach enough to decide whether to initiate | During Starting up a Project |
| Project product description | Defines the overall project output and acceptance expectations | Early definition, acceptance clarification, closure |
| Business case | Justifies the project and supports continuation decisions | Initiation, stage boundary, major issue, exception, closure |
| Benefits management approach | Defines how benefits will be measured and reviewed | Benefit changes, closure planning, post-project review planning |
| Project initiation documentation | Baseline for what the project is, how it will be controlled, and how it will be delivered | End of initiation, major approved changes |
| Project plan | Overall plan for delivering the project | Initiation, stage boundary, approved change, exception |
| Stage plan | Detailed plan for the current or next management stage | Stage authorization, stage boundary, replanning |
| Team plan | Delivery-level plan used by a team manager where appropriate | Work package planning and execution |
| Exception plan | Replacement plan after forecast tolerance breach, if authorized | Exception handling |
| Work package | Agreement between project manager and team manager on products, constraints, reporting, and quality | Product delivery assignment or change |
| Product description | Defines a product’s purpose, composition, quality criteria, and acceptance needs | Product planning, quality review, change impact |
| Quality management approach | Defines quality standards, responsibilities, methods, and records | Initiation, changed quality expectations |
| Quality register | Tracks planned and completed quality activities | Quality review planning and results |
| Risk management approach | Defines how risk will be identified, assessed, controlled, and reported | Initiation, changed risk context |
| Risk register | Records risk details, assessments, owners, responses, and status | New or changed risk, response review |
| Change or issue management approach | Defines how issues and changes are captured, assessed, decided, and controlled | Initiation, changed control needs |
| Issue register | Tracks issues and their status | New issue, change request, off-specification |
| Issue report | Provides detailed analysis for significant issues | Decision needed or escalation required |
| Communication management approach | Defines stakeholder communication needs and channels | Stakeholder changes, communication problems |
| Lessons log | Captures lessons during the project | Starting up, stage work, issue resolution |
| Lessons report | Communicates lessons for current or future use | Stage boundary or closure |
| Daily log | Captures informal issues, notes, or actions not yet needing formal registers | Day-to-day management |
| Checkpoint report | Team manager progress report to the project manager | Work package monitoring |
| Highlight report | Project manager progress report to the project board | Stage progress reporting |
| End stage report | Summarizes stage performance and supports next-stage decision | Stage boundary |
| Exception report | Alerts project board to forecast tolerance breach | Exception situation |
| End project report | Summarizes project performance, acceptance, and remaining actions | Closure |
Scenario and Decision-Point Checks
Use this table to practice “what should happen next?” judgment.
| Scenario cue | First thing to decide | PRINCE2-consistent action pattern |
|---|---|---|
| A forecast shows the stage will exceed agreed tolerance | Is this within the project manager’s authority? | Raise an exception report and seek project board direction |
| A team manager expects a work package delay | Does it affect work package limits or stage tolerance? | Team manager informs project manager; project manager assesses impact |
| A stakeholder requests a new feature | Is it a request for change to a baseline? | Log, assess impact, route to change authority or project board as defined |
| A product fails agreed quality criteria | Is this an off-specification or defect requiring correction? | Record issue/quality result, assess impact, decide correction or escalation |
| Business benefits are reduced by market change | Does the business case remain justified? | Update business case and escalate if justification or tolerance is threatened |
| Users were not consulted on acceptance criteria | Is product acceptance at risk? | Engage senior user/user representatives and review product descriptions |
| Supplier wants to substitute a component | Does it affect scope, quality, risk, cost, or acceptance? | Treat as issue/change; analyze before approval |
| Project board asks for less reporting | Can controls still support management by exception? | Tailor reporting while preserving decision-quality information |
| Team wants to use agile delivery | Does governance remain clear? | Tailor PRINCE2 controls around agile delivery, roles, products, and tolerances |
| A risk response costs more than planned | Does it affect budget, tolerance, or business case? | Assess impact and escalate if outside delegated authority |
| End of stage is approaching | What decision is needed? | Prepare end stage information, update business case/plans, request authorization |
| Final product is complete | Has it been accepted and handed over? | Confirm acceptance, prepare closure records, capture lessons and follow-on actions |
Can You Do This? High-Value Practitioner Checklist
Lifecycle and Process Skills
- Identify the active PRINCE2 process from scenario timing and language.
- Choose the correct next action at startup, initiation, delivery, stage boundary, exception, or closure.
- Distinguish directing work from managing work.
- Explain why authorization is needed before committing to major next steps.
- Recognize when closure is appropriate, including premature closure.
Governance and Role Skills
- Assign decisions to the project board, executive, senior user, senior supplier, project manager, team manager, or change authority.
- Identify when project assurance should review or challenge project information.
- Separate user acceptance from supplier delivery.
- Recognize when corporate, programme, customer, or equivalent governance may need escalation.
- Avoid giving day-to-day control to the project board.
Artifact Skills
- Select the artifact that best supports a decision.
- Know when the PID should be baselined or updated.
- Link product descriptions to quality checks and acceptance.
- Use registers for tracking and reports for decision support.
- Identify when a plan, business case, or management approach needs revision.
Judgment Skills
- Decide whether to correct, escalate, defer, reject, approve, or request more analysis.
- Identify whether the issue affects time, cost, scope, quality, benefits, risk, or sustainability targets.
- Balance delivery urgency against governance, acceptance, and business justification.
- Tailor documentation and controls to project risk and complexity.
- Justify an answer using PRINCE2 logic rather than generic project management preference.
Calculation and Interpretation Checks
PRINCE2 Practitioner is not primarily a calculation exam, but candidates should be comfortable interpreting project control information.
| Control item | Be able to interpret |
|---|---|
| Baseline vs actual | Whether the project is performing as planned |
| Forecast vs tolerance | Whether escalation is required |
| Cost increase | Effect on business case and delegated authority |
| Benefit reduction | Effect on continued justification |
| Risk exposure change | Whether response, escalation, or business case review is needed |
| Scope change | Impact on products, plans, quality, benefits, and acceptance |
| Schedule delay | Whether delay is within tolerance and what plan should be updated |
| Quality failure | Whether correction, concession, change, or escalation is appropriate |
Quick check:
- Can you tell the difference between an actual variance and a forecast exception?
- Can you avoid escalating a problem that is still within the project manager’s tolerance?
- Can you identify when a small cost change still matters because it affects benefits or risk?
- Can you connect a product-level issue to project-level justification?
Tailoring, Delivery Approach, and Context
| Context | How PRINCE2 thinking should adapt | Trap to avoid |
|---|---|---|
| Small project | Use lighter documentation and simpler controls while keeping clear roles, justification, products, and tolerances | Removing controls entirely |
| Large or complex project | Use stronger governance, assurance, reporting, and stage control | Creating bureaucracy that does not support decisions |
| High-risk project | Increase attention to risk responses, tolerances, assurance, and business case review | Treating risk as a one-time initiation activity |
| Supplier-heavy project | Clarify supplier responsibilities, work packages, quality evidence, and commercial constraints | Assuming supplier plans replace PRINCE2 governance |
| Agile delivery | Govern by products, tolerances, roles, and stage decisions while allowing iterative delivery | Confusing team-level agile practices with project direction |
| Hybrid delivery | Coordinate predictive governance with iterative or incremental delivery teams | Applying one delivery style blindly to all work |
| Sustainability-sensitive project | Include sustainability targets or constraints where defined in justification, planning, risk, and progress control | Treating sustainability as separate from project performance |
| Business change project | Include adoption, communication, user readiness, benefits, and operational transition | Assuming product delivery equals benefit realization |
Common Weak Areas and Traps
| Weak area | Why it causes wrong answers | Better exam habit |
|---|---|---|
| Memorizing terms without scenario application | Practitioner questions require judgment | Ask “what is the PRINCE2 reason for this action?” |
| Confusing risk and issue | Risk is uncertain; issue requires current management | Look for whether the event has occurred |
| Escalating too early | Management by exception gives authority within tolerance | Check tolerance before escalating |
| Escalating too late | Forecast tolerance breach requires direction | Look for forecast, not just actual breach |
| Misplacing authority | PRINCE2 has defined decision roles | Identify who owns the decision |
| Ignoring the business case | Continued justification is central | Recheck business case when costs, benefits, or risks change |
| Treating quality as testing only | Quality starts with expectations and product descriptions | Connect quality criteria to product planning |
| Treating plans as schedules only | PRINCE2 planning is product-based | Start with products and acceptance |
| Forgetting lessons | Lessons are used throughout the lifecycle | Ask what can be learned now, not only at closure |
| Over-documenting tailoring | Tailoring should fit the project | Preserve purpose, reduce unnecessary formality |
| Under-documenting tailoring | Informality can weaken control | Keep evidence needed for decisions |
| Confusing assurance and control | Assurance checks independently; control manages delivery | Identify who is checking versus doing |
| Ignoring stakeholders | People issues can threaten acceptance and benefits | Include communication, engagement, and change impact |
| Assuming delivery method replaces PRINCE2 | Agile or technical methods do not remove project governance | Keep roles, stages, tolerances, and business justification clear |
Final-Week Review Checklist
Build Your One-Page PRINCE2 Map
- List the principles and write one scenario cue for each.
- List the practices and write the main artifact or decision each supports.
- Draw the process lifecycle from Starting up a Project through Closing a Project.
- Map major roles to their decision authority.
- Write down when the business case is reviewed.
- Write down when an exception report, exception plan, end stage report, and highlight report are used.
Practice Scenario Reasoning
For each practice question or case study, mark:
- Active process.
- Relevant practice.
- Relevant principle.
- Role with authority.
- Artifact to create, update, or review.
- Whether the matter is within tolerance.
- Whether tailoring affects the answer.
- Why the best answer is better than the second-best answer.
Review Artifacts by Trigger
- New project idea: project mandate, project brief, outline business case.
- Before major commitment: PID, detailed business case, project plan, management approaches.
- Work assigned to team: work package, product descriptions, checkpoint reporting.
- Quality activity: product description, quality register, quality records.
- New uncertainty: risk register.
- Current problem or change: issue register or issue report.
- Stage review: end stage report, next stage plan, updated business case.
- Forecast tolerance breach: exception report and possible exception plan.
- Closure: acceptance, end project report, lessons report, benefits follow-up information.
Tighten Common Distinctions
- Risk vs issue.
- Quality assurance vs quality control.
- Project board vs project manager authority.
- Stage plan vs project plan.
- Team plan vs work package.
- Highlight report vs checkpoint report.
- Exception report vs exception plan.
- Product output vs business benefit.
- Tailoring vs skipping.
- User acceptance vs supplier completion.
Practical Next Step
Use this checklist to diagnose your next study session. Pick the three weakest rows, then practice scenario questions that force you to decide what happens next, who decides, and which PRINCE2 artifact changes. For PRINCE2 Project Management Practitioner (Version 7) readiness, prioritize applied judgment over memorized definitions.