PRINCE2 Practitioner — PRINCE2 Project Management Practitioner (Version 7) Cheat Sheet

The Practitioner exam is not just a definition test. Expect scenario-based decisions: who should do something, which management product should be updated, whether a tolerance breach needs escalation, how to tailor PRINCE2 without weakening governance, and how the principles, people, practices, and processes fit together.

Use this Cheat Sheet as a checklist before PM Mastery practice:

1. Drill one practice at a time. For example, do only risk questions until you can separate risk cause, event, effect, owner, and response.
2. Then drill process timing. Focus on whether the scenario is starting up, initiating, controlling a stage, managing delivery, stage boundary, or closing.
3. Review every explanation. For Practitioner-level preparation, the reason an option is wrong is often more valuable than the right answer.
4. Track recurring mistakes. Common patterns include role confusion, weak exception logic, and mixing up risk vs issue.
5. Move to mixed mock exams only after topic drills. Mixed practice is most useful when the core decision rules are already familiar.

The seven principles

The principles are the safest anchor in scenario questions. If two options sound plausible, choose the one that best protects a principle without creating unnecessary bureaucracy.

Quick principle decision rules

• No business case? The project lacks a core reason to continue.
• No defined products? Planning and quality control will be weak.
• No tolerances? Manage by exception cannot operate.
• No lessons use? The project is repeating avoidable mistakes.
• No clear roles? Escalation, assurance, acceptance, and decisions become confused.
• No tailoring? The method may become either too heavy or too informal.

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]

Exception and escalation decision path

    flowchart TD
	    A[Variance or new information identified] --> B{Is tolerance forecast to be exceeded?}
	    B -->|No| C[Manage within current authority and update records]
	    B -->|Yes| D[Project Manager prepares Exception Report]
	    D --> E[Escalate to Project Board]
	    E --> F{Within Project Board authority?}
	    F -->|Yes| G[Board gives direction or requests Exception Plan]
	    F -->|No| H[Board escalates to business layer]
	    G --> I[Approved plan replaces previous baseline if authorized]

High-yield distinction:

• Actual variance matters, but PRINCE2 is especially concerned with forecast breach.
• You do not wait until tolerance is already exceeded if it is forecast to be exceeded.
• An exception plan is not created automatically for every variance; it is prepared when requested/authorized.

Product-based planning sequence

1. Write or refine the project product description.
2. Identify major products and create the product breakdown structure.
3. Write product descriptions with quality criteria and approval responsibilities.
4. Identify product dependencies with a product flow view.
5. 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 decision points:

If a quantitative scenario provides probability and impact, risk exposure may be estimated as:

Risk ownership distinctions:

Issue procedure:

1. Capture the issue.
2. Examine type, cause, severity, and impact.
3. Propose options and recommendation.
4. Decide using delegated authority.
5. Implement the decision and update records.

Progress decision rules:

Governance traps

• Letting the Project Manager approve changes outside delegated authority.
• Continuing to the next stage without Project Board authorization.
• Treating stage boundaries as calendar milestones only, rather than decision points.
• Escalating too late after tolerance has already been exceeded.
• Forgetting that the Project Board also has limits and may need to escalate upward.

Planning traps

• Planning activities before products.
• Using one detailed plan for the entire project when uncertainty is high.
• Not replacing a plan after an authorized exception.
• Ignoring team plans or work packages in delivery scenarios.
• Failing to update plans after approved changes.

Business case traps

• Ignoring increased risk or cost because benefits are attractive.
• Treating sunk cost as justification.
• Forgetting benefit ownership.
• Closing without follow-on benefit review arrangements.
• Failing to consider dis-benefits.

Risk and issue traps

• Calling an event a risk after it has already happened.
• Implementing change without impact analysis.
• Assigning every risk response to the Project Manager.
• Treating an off-specification as a minor defect with no governance impact.
• Not updating registers after decisions.

People traps

• Assuming users will adopt outputs automatically.
• Ignoring communication needs of affected groups.
• Using the same message for all stakeholders.
• Not involving user representation in acceptance and benefits.
• Treating conflict as only a personal issue rather than a project risk or issue when it affects objectives.

Final rapid checklist

Before answering a scenario question, ask:

• Is continued business justification being protected?
• Are the correct roles making the correct decisions?
• Is the project being managed by stages and by exception?
• Are products, quality criteria, and acceptance clearly defined?
• Is this a risk, issue, change request, or off-specification?
• Has the impact been assessed across time, cost, quality, scope, benefits, risk, and sustainability?
• Is the answer appropriately tailored without removing PRINCE2 principles?
• Does the management product named in the answer actually fit the situation?
• Is the Project Manager managing within tolerance, or should the matter be escalated?
• Are people, stakeholders, communication, and adoption being handled deliberately?

For the next step, use original practice questions and topic drills to test these decision rules under scenario pressure, then review detailed explanations until the PRINCE2 reasoning becomes automatic.

High-scoring candidates usually ask:

1. Which principle is being protected?
2. Which role has accountability or decision authority?
3. Which practice provides the control mechanism?
4. Which process is the project currently in?
5. Which management product records the decision, plan, risk, issue, or lesson?

Common people-related mistakes:

• Assuming a technically correct product will be accepted without user engagement.
• Treating stakeholder resistance as an issue to suppress rather than a risk or change-adoption concern to manage.
• Communicating the same level of detail to executives, users, suppliers, and team members.
• Letting the project manager become the only communication route when other roles have ownership.
• Ignoring senior user involvement in benefits, acceptance, and user readiness.

Business case traps:

• Confusing outputs with benefits. A new system is an output; faster processing or reduced errors may be benefits.
• Treating benefits as guaranteed without ownership, measurement, or timing.
• Ignoring the impact of risks, issues, or changes on continued justification.
• Continuing because the project is politically popular rather than justified.
• Forgetting that some benefits may be realized after project closure and still need planned review.

Organizing practice

The organizing practice defines who is accountable, who represents key interests, and how decisions are made.

Role traps:

• The Project Manager manages within delegated authority; they do not own the business case.
• The Project Board directs; it should not micromanage daily delivery.
• Assurance should be independent of the work being assured.
• One person may hold multiple roles only if conflicts are managed and interests remain represented.
• Stakeholder communication is not the same thing as governance, but both must be organized.

Plans practice

Plans translate objectives into deliverable products, activities, resources, timing, and controls. PRINCE2 planning is product-focused.

Product-based planning logic:

1. Define the final product and acceptance criteria.
2. Break down required products.
3. Describe products clearly, including quality criteria.
4. Identify dependencies and sequence.
5. Estimate effort, resources, and schedule.
6. Add controls and tolerances.

Plans practice traps:

• Creating activity schedules before defining products.
• Treating the project plan as detailed enough to manage all future stages.
• Continuing with an old plan after an exception without authorization.
• Ignoring dependencies between supplier deliverables and user acceptance.
• Planning benefits realization as if it were always completed before closure.

Quality practice

Quality ensures products are fit for purpose and meet agreed criteria.

Quality decision rules:

• If the question asks what “good” means, look for product descriptions and quality criteria.
• If the question asks how quality will be checked, look for quality methods and the quality register.
• If a delivered product fails an agreed criterion, treat it as an issue/off-specification, not just informal feedback.
• If users are surprised by product behavior at the end, the project likely failed to define or communicate acceptance criteria early.

Quality traps:

• Confusing quality assurance with quality control.
• Assuming supplier internal testing is enough for user acceptance.
• Leaving acceptance criteria vague.
• Accepting extra features without assessing scope, cost, time, risk, benefits, and sustainability impacts.

Risk practice

A risk is an uncertain event or set of events that, if it occurs, will affect objectives. PRINCE2 treats threats and opportunities as risks.

Common response logic:

Risk traps:

• Confusing a risk with an issue. If it has already happened, it is usually an issue.
• Recording vague risks such as “supplier problem” without cause, event, and effect.
• Assigning a risk to a group instead of a clear owner.
• Ignoring risk impact on business justification.
• Treating all risk responses as tasks for the project manager.

Issues practice

Issues are events that have happened, requests, concerns, or situations requiring management attention. Issues are controlled so the project does not drift away from agreed baselines.

Issue handling sequence:

1. Capture the issue.
2. Assess impact on objectives, tolerances, business case, risks, benefits, quality, scope, sustainability, cost, and time.
3. Propose options.
4. Decide using the correct authority.
5. Implement approved action.
6. Update records and affected baselines.

Issue traps:

• Treating every change request as automatically approved.
• Letting the loudest stakeholder bypass change control.
• Failing to assess impact across all performance targets.
• Confusing an off-specification with a request for change.
• Updating delivery work without updating the relevant plan or baseline.

Progress practice

The progress practice provides monitoring, control, forecasting, reporting, and escalation.

Manage by exception is central:

• The Project Board delegates tolerances to the Project Manager.
• The Project Manager manages within those tolerances.
• If a tolerance is forecast to be exceeded, the Project Manager escalates.
• The Project Board decides what to do within its authority.
• If project-level tolerances are threatened, the Project Board escalates to the business layer.

Process table