PRINCE2 Practitioner common mistakes
PRINCE2 Practitioner · Understand the traps and how to avoid them.
When asked to tailor a theme to a project scenario, the candidate copies the full PRINCE2 process or theme description from the manual instead of stating which specific products, roles, or controls the scenario project will use and why, so the answer never addresses the scenario's stated constraints (size, complexity, risk, delivery approach).
Candidates memorise the manual's baseline definitions and treat the Practitioner question as a recall test; they have practised theory questions rather than applied 'what would you do here' questions, so they default to describing the method rather than tailoring it.
What to do instead
For every tailoring answer, use a three-part structure: (1) name the scenario driver (e.g. fixed-price supplier, regulatory audit, distributed team), (2) state the specific tailoring decision (e.g. combine Stage 1 and 2 into one management stage, use a single combined Risk/Issue Log, replace a full Project Board with a project assurance delegate), (3) justify it against that driver and note the residual risk. Practise by taking one theme and writing tailoring decisions for three different project profiles (small low-risk, multi-supplier, agile-delivery).
The candidate identifies the correct PRINCE2 principle or theme that is being breached but cannot name the specific management product, role, or process activity that would fix it, so the answer says 'the business case should be reviewed' without saying who reviews it, at which process activity, and what decision they take.
Practitioner questions are marked against a mark scheme that rewards named products and roles; candidates revise principles as slogans and never build the mental link from principle to concrete product (e.g. 'continued business justification' maps to the Business Case, Benefits Management Approach, and the 'Authorise a Stage or Exception Plan' activity).
What to do instead
Build a one-page mapping table from each principle and theme to its products, responsible roles, and the process activities where it is applied. When answering, always name at least one product, one role, and one process activity. For example: 'The Project Board (role) reviews the updated Business Case at the End Stage Report (product) during Managing a Stage Boundary (activity) and confirms continued viability before authorising the next stage.'
The candidate treats the Business Case as a one-off document produced at Starting Up a Project and never revisits it, so in scenario questions about a change in scope, cost overrun, or benefit shortfall they fail to recommend updating the Business Case and re-checking the business justification before proceeding.
The Business Case is taught early in courses and candidates mentally file it as an initiation artefact; they forget that PRINCE2 requires it to be reviewed at every stage boundary and whenever a significant change or exception occurs, and that 'continued business justification' is a principle, not a one-time gate.
What to do instead
Memorise the Business Case review points: at each stage boundary (Managing a Stage Boundary), at an Exception (Exception Report and Exception Plan), at any significant Change (via the change control approach), and at Project Closure for benefit realisation handover. In scenario answers, when a question mentions cost, scope, or benefit variance, explicitly state that the Business Case is updated, the Senior User and Executive re-assess viability, and the outcome is recorded in the End Stage Report or Exception Report.
The candidate confuses the Project Board roles with the project manager's team-level roles, assigning quality assurance, change control, or risk ownership to the Project Manager or to the Project Support office when PRINCE2 assigns them to Project Assurance, the Change Authority, or the Risk Owner respectively, and mislabels the Senior User's accountability for benefits.
Role names in PRINCE2 overlap with generic job titles; candidates map 'assurance' to 'the PM checks quality' and 'change authority' to 'the PM approves changes', losing the separation-of-duties logic that PRINCE2 deliberately builds into the organisation theme.
What to do instead
Learn the organisation theme as a set of accountabilities with distinct purposes: Executive (business justification, ultimate accountability), Senior User (benefits and user requirements), Senior Supplier (supplier resources and technical integrity), Project Assurance (independent monitoring on the Board's behalf, not decision-making), Project Support (administrative and specialist support, not assurance), Change Authority (delegated change approval), Team Manager (product delivery). For each scenario answer, name the role and state why that role, not another, holds the accountability, citing the separation of duties.
The candidate describes the quality theme in terms of testing or inspection only, omitting the product-based planning link: they fail to mention Product Descriptions, quality criteria, quality tolerance, quality methods, and the Quality Register, and cannot explain how acceptance criteria flow from the Product Description to the Quality Register and into the stage quality activities.
Quality is intuitively associated with testing, and candidates with a technical background default to test plans; they under-learn the PRINCE2-specific products (Product Description, Quality Register, Quality Management Approach) and the Project Product Description with its customer's quality expectations and acceptance criteria.
What to do instead
For any quality scenario, walk the chain explicitly: Project Product Description (customer quality expectations and acceptance criteria) -> Product Descriptions for each product (quality criteria, quality method, quality tolerance, quality responsibilities) -> Quality Register (scheduled quality activities and results) -> quality control activities in the stage plan -> acceptance by the customer at the end. When asked to improve quality in a scenario, name the missing product in that chain (e.g. 'no Product Descriptions exist, so quality criteria are undefined') and the fix, rather than generic 'more testing'.
The candidate writes stage plans and team plans as activity lists (a Gantt-style task breakdown) and omits the PRINCE2 planning products that make the plan controllable: the product breakdown structure, product flow diagram, planning assumptions, external dependencies, and the tolerances (time, cost, scope, risk, benefit) that the plan must carry.
Candidates with PMP or agile backgrounds default to activity-based scheduling; PRINCE2's product-based planning is distinctive and is often skimmed in revision because it feels familiar, so the product breakdown structure and product flow diagram are never internalised.
What to do instead
Practise converting a scenario's deliverables into a product breakdown structure first, then a product flow diagram, then activities derived from the products. Always state the plan's tolerances and the planning assumptions and external dependencies. When a question asks why a plan failed, check for the missing element: no product definitions, no tolerances, no dependency on an external supplier, or a plan that mixes management and delivery activities. Name the missing element and the corrective product (e.g. 'rework the Stage Plan with a product breakdown structure and set stage tolerances').
The candidate treats risk as a list of threats only, omitting opportunities, and cannot apply the PRINCE2 risk management procedure steps in order (identify, assess, plan, implement, communicate) or distinguish risk appetite/tolerance from the risk owner and risk actionee.
Risk is often revised as a glossary of terms rather than as a procedure; candidates conflate 'risk owner' (accountable for managing the risk) with 'risk actionee' (carries out the response), and forget that PRINCE2 explicitly includes opportunities and that the Risk Management Approach is a project product.
What to do instead
Learn the five-step procedure with its inputs and outputs per step, and practise classifying each scenario risk by step ('this is at the assess step; the missing output is the evaluated probability and impact'). Memorise the role distinction: risk owner is accountable and usually a manager; risk actionee implements the response and may be anyone. In every risk answer, include both threat and opportunity responses and reference the Risk Management Approach and the Risk Register as the controlling products.
The candidate handles change by describing a generic change request form and an ad hoc approval, missing the PRINCE2 change control approach: the Change Budget, the Change Authority and its delegated limits, the Issue Register versus the Change Log distinction, the impact analysis on all six performance targets, and the decision options (approve, reject, defer, refer to the Board).
Change control feels administrative, so candidates revise the forms rather than the governance: they do not internalise that issues and changes are handled through the same issue and change control procedure but recorded in different registers, and that the Change Authority's limits come from the Change Control Approach and the Project Board's delegation.
What to do instead
Build a decision tree for a change: log it (Issue Register if it is an issue or a request for change; Change Log for the change itself), perform impact analysis against time, cost, scope, quality, risk, and benefits, compare against tolerances and the Change Budget, then choose approve/reject/defer/refer. State who decides based on the Change Authority's delegated limits. In scenario answers, name the register, the impact dimensions assessed, the decision-maker, and the escalation route if tolerances would be exceeded.
The candidate answers progress questions by describing status reporting frequency only, and cannot distinguish the seven progress controls (tolerance, stage boundaries, checkpoint reports, highlight reports, end stage reports, end project reports, exception reports) or explain how a forecast against stage tolerances triggers an Exception Report and Exception Plan.
Progress looks like routine reporting, so candidates skim it; the distinctive PRINCE2 logic - that progress is managed by comparing actual and forecast against tolerances at defined control points, and that breaching a tolerance escalates to the next management level - is not practised, so candidates cannot apply it to a scenario with a forecast overrun.
What to do instead
Memorise the control hierarchy: Work Package tolerance (Team Manager) -> Stage tolerance (Project Manager) -> Project tolerance (Project Board) -> Corporate/programme tolerance (above the project). For a scenario, identify which tolerance is forecast to be breached, which control point detects it (checkpoint or highlight report), which product escalates it (Exception Report to the Board), and which plan is produced (Exception Plan at Managing a Stage Boundary). Practise by writing the escalation chain for a cost overrun at each level.
The candidate describes the PRINCE2 processes as a linear waterfall and cannot explain the iterative loops (e.g. Managing a Stage Boundary repeats for every stage, Directing a Project runs concurrently throughout, and Starting Up a Project and Initiating a Project can overlap), so scenario questions about re-planning mid-project or about an exception during a stage are answered with the wrong process or the wrong sequence.
Processes are taught as a list of seven activities in order; candidates memorise the sequence but not the triggers, inputs, outputs, and the fact that some processes are ongoing and some repeat, so they cannot place a scenario event in the correct process.
What to do instead
Draw the process model as a diagram with the concurrent Directing a Project spine and the repeating Managing a Stage Boundary loop, and annotate each process with its trigger, key inputs, and key outputs. For each scenario event, ask three questions: which process is currently running, what triggered the event, and which process produces the required output. Then name the process, the activity within it, and the product produced.