PRINCE2 Foundation (PRINCE2) common mistakes
PRINCE2 Foundation · Understand the traps and how to avoid them.
Selecting answers that say a principle can be adapted, scaled, or dropped for small projects - for example, agreeing that 'continued business justification' can be relaxed on a short project, or that only 'some' of the seven principles need to apply.
The whole point of tailoring is made in the Practices/Processes material, so candidates carry the idea 'PRINCE2 is scalable' across to the Principles and assume the seven principles are equally adjustable.
What to do instead
Learn the seven principles word-for-word with their one-line definitions, and memorise the rule 'principles are mandatory and never tailored; only the practices, roles and processes are tailored'. Whenever an option offers an exception to a principle, eliminate it.
In scenario questions asking 'which principle is being demonstrated', choosing the practice, role, or product that appears in the scenario (e.g. picking 'business case' or 'manage by exception' when the correct answer is 'continued business justification').
The scenario dialogue and the option list use the same vocabulary as the practices, and 'manage by exception' in particular sounds like a description of an exception report rather than a behavioural principle.
What to do instead
Rehearse a behaviour-test for each principle ('is the answer a way of thinking/behaving, or a thing someone produces?'). If the option names a document, a role, a tolerance or a process activity, it is not the principle. Practise 20 short scenarios and label the principle before looking at the options.
Assigning accountability to the wrong role - for example, saying the Project Manager is accountable for realisation of benefits, that the Executive can delegate overall accountability for the project, or that the Senior Supplier signs off the achievement of benefits.
In day-to-day project life the Project Manager does most of the visible work, so candidates transfer real-world habit onto the exam instead of using the PRINCE2 accountability split.
What to do instead
Build a one-page role chart: Executive = accountable for the project and the Business Case; Senior User(s) = accountable for user needs and benefits realisation; Senior Supplier = accountable for supplier resources and quality of supplier products; Project Manager = responsible for day-to-day management within tolerances. Test every People/Organisation question against this chart.
Treating 'People' questions as general leadership or HR trivia and picking the option that sounds most collaborative (e.g. 'involve the whole Project Board in every issue', 'hold a team-building day to resolve a performance problem') rather than the PRINCE2-consistent behaviour.
People-domain stems read like soft-skills scenarios, and candidates switch off their PRINCE2 filter because the question does not mention a process or a product.
What to do instead
Filter every People option through two tests: (1) does it fit manage by exception - escalate only when a tolerance is forecast to be exceeded; (2) does it match the role's defined accountability? Discard options that require the Board to make operational decisions or that rely on generic morale-building with no defined-role or communication-management hook.
Confusing which management product is created or updated in which process - e.g. placing the Project Brief in Initiating a Project, the PID in Starting up a Project, or mixing the Lessons Log with the Lessons Report and the Checkpoint Report with the Highlight Report.
The products appear across several processes and the question stems often ask 'which process is this activity part of?' while the options list products, so candidates match on keyword familiarity rather than on sequence.
What to do instead
Make a timeline table of products against processes: Starting up a Project produces the Project Brief, outline Business Case and Daily Log; Initiating a Project produces the PID, benefits management approach and communication management approach; Lessons Log is created in Starting up and maintained throughout, while Lessons Reports are produced at stage end and project end. Learn who receives each report (Checkpoint = Project Manager from Team Manager; Highlight = Project Board from Project Manager).
Getting the tolerance hierarchy wrong - for example, saying the Project Manager sets stage tolerances, that the Project Board sets project tolerances from scratch, or that a forecast breach of a stage tolerance is escalated straight to corporate/programme management.
All six tolerance types and three organisational levels are taught together, and candidates learn 'tolerances exist' without learning the direction in which they are delegated and escalated.
What to do instead
Memorise the delegation chain and the escalation chain: corporate/programme sets project tolerances (the Board may refine them) → Board sets stage tolerances for the Project Manager → Project Manager sets team/work-package tolerances for the Team Manager. Escalation mirrors it: stage tolerance forecast breach goes to the Project Board as an exception; project tolerance forecast breach is escalated by the Board to corporate/programme.
Mixing up quality planning, quality assurance and quality control, or misassigning quality review responsibilities - e.g. saying the Project Manager performs quality assurance, that product descriptions are produced during quality control, or that quality assurance is part of the Project Manager's team.
The words 'quality' and 'assurance' appear in several places (project assurance roles, the Quality practice, quality review technique), and candidates blur the terms because they never separated planning/assurance/control into three distinct purposes.
What to do instead
Learn the three-part split: quality planning defines what quality means and how it will be achieved (quality management approach, product descriptions, quality register); quality assurance is an independent check that the quality approach is being followed (not done by the Project Manager); quality control is the execution of the quality methods on products (quality review, testing) and updates the quality register. For every quality question, first ask 'plan, check the method, or check the product?'.
Attributing Project Board decision activities to the wrong process - for example placing 'authorise the project', 'authorise a stage or exception plan' or 'authorise project closure' inside Initiating a Project or Controlling a Stage, or expecting the Project Manager to authorise a stage.
The processes run in parallel and the Board's activities are short, so candidates absorb them into the phase where they notice them rather than into Directing a Project, which is the Board's own process.
What to do instead
Learn Directing a Project as 'the Board's process with the authorise verbs': authorise initiation, authorise the project, authorise a stage or exception plan, give ad hoc direction, authorise project closure. If an option has the Project Manager authorising a stage, an exception plan or closure, eliminate it automatically.
Confusing Managing a Stage Boundary with Controlling a Stage - placing 'authorise a work package', 'review work package status' or 'take corrective action' in Managing a Stage Boundary, or believing an exception plan is prepared inside Controlling a Stage.
Both processes involve the Project Manager reacting to work-package information, and Managing a Stage Boundary only happens at stage end (or when an exception plan is needed), so candidates merge the two.
What to do instead
Anchor each process to its trigger: Controlling a Stage is continuous, work-package-driven, and the Project Manager's day-to-day process; Managing a Stage Boundary is triggered only by the end of a stage or a request to prepare an exception plan, and its output is the End Stage Report, the next Stage Plan, and an updated PID and Business Case for Board approval. Classify any option by asking 'is this routine delivery control or stage-end preparation?'.
Getting Starting up a Project and Initiating a Project out of order - e.g. saying the full Business Case, the PID or the benefits management approach is produced in Starting up a Project, or that the Project Brief is created in Initiating a Project.
Both processes happen before delivery starts and share products (Business Case, project approach, team roles), so candidates memorise 'the front end' as a single block instead of two distinct decision points.
What to do instead
Learn the two questions: Starting up a Project answers 'is this project worth initiating at all?' and outputs the Project Brief, outline Business Case, project approach and initiation stage plan; Initiating a Project answers 'how will we actually do it?' and outputs the PID, benefits management approach, communication management approach and the first Stage Plan. If an option puts a detailed planning artefact in Starting up a Project, it is wrong.