PRINCE2 Foundation (PRINCE2) common mistakes
PRINCE2 Foundation · Understand the traps and how to avoid them.
Applying a principle as if it were optional, e.g., accepting a project with no defined business case or no defined roles because 'the organisation works differently'.
Candidates treat the seven principles as good-practice guidance rather than mandatory characteristics that must be visibly present in every project, so they pick answers that describe typical practice instead of principle compliance.
What to do instead
Memorise the seven principles and, for each, learn the one test question it answers (continued business justification, learn from experience, defined roles and responsibilities, manage by stages, manage by exception, focus on products, tailor to the environment). When a scenario lacks one, treat that as the error regardless of organisational custom.
Choosing 'tailor to the environment' as the correct principle whenever a scenario mentions scaling, size, or complexity, even when the real issue is a missing principle such as manage by exception.
Tailoring is the most familiar-sounding principle and candidates over-apply it because it feels like a catch-all for any variation from the standard method.
What to do instead
Before selecting tailoring, check whether the scenario describes a legitimate adaptation (correct) or an omission of another principle (incorrect). Tailoring adjusts how principles are applied; it never removes them. If a principle is absent, that is the failure, not tailoring.
Confusing the business case with the benefits management approach, or assuming the business case is produced once at Starting Up a Project and never revisited.
Both documents relate to benefits, so candidates merge them, and the 'continued' in continued business justification is easily overlooked under exam time pressure.
What to do instead
Anchor each document to its owner and purpose: the business case (Executive-owned, justifies the project, reviewed at every end stage and exception) versus the benefits management approach (how and when benefits will be measured and realised, often after project closure). Expect questions testing that the business case is reviewed and updated at stage boundaries.
Assigning accountability for a theme to the wrong role, e.g., saying the Project Manager owns the business case or that the Senior User owns the risk management approach.
Candidates learn the products but not the accountability mapping, and PRINCE2 deliberately splits accountability (Executive, Senior User, Senior Supplier) from delegated responsibility (Project Manager, Team Manager).
What to do instead
Build a role-to-product table: Executive owns the business case and end-project decision; Senior User owns benefits and user acceptance; Senior Supplier owns supplier commitment and quality of supplier output; Project Manager owns day-to-day plans, risk/issue/quality registers and stage plans. Drill the accountability questions until the mapping is automatic.
Treating the plans theme as a single plan, or failing to distinguish project plan, stage plan, team plan and exception plan by who creates them and when they are used.
All four share a common structure, so candidates answer on content similarity rather than on trigger, owner, and level of detail.
What to do instead
Learn each plan by trigger and owner: project plan (Project Manager, initiated in Initiating a Project), stage plan (Project Manager, one per management stage, produced near the end of the preceding stage), team plan (Team Manager, optional, covers a work package), exception plan (replaces the plan that is off-track, produced after an exception is escalated). Match the scenario wording to the trigger.
Mixing up which process produces which management product, e.g., placing the project brief in Initiating a Project or the PID in Starting Up a Project.
The two pre-delivery processes overlap in purpose (both concern project set-up), and candidates rely on general impressions rather than the precise output of each activity.
What to do instead
Memorise the boundary: Starting Up a Project produces the project brief, the daily log and the outline business case, and ends with the request to authorise initiation. Initiating a Project produces the PID, the business case, benefits management approach and the project controls. Use the trigger 'authorise initiation' as the dividing line.
Describing Managing a Stage Boundary as an activity that happens inside the stage being managed, or omitting that it can also be triggered by an exception.
Its name suggests ongoing stage control, so candidates conflate it with Controlling a Stage and forget the exception-planning use of the process.
What to do instead
Remember Managing a Stage Boundary sits at the end of a stage (or on an exception) and produces the next stage plan, an updated project plan and business case, and an end stage report for the board. Controlling a Stage is the ongoing work within the stage. Distinguish by timing: boundary equals transition or exception response.
Assuming the project board authorises work packages or approves team plans, rather than reserving board decisions for stage boundaries and exceptions.
Candidates over-attribute authority to the board because it is the senior decision-making body, ignoring the manage by exception delegation to the Project Manager.
What to do instead
Learn the board's decision points: authorise initiation, authorise the project, authorise each stage (or exception plan), and authorise project closure. Everything below that - work packages, team plans, day-to-day issues within tolerance - is the Project Manager's delegated authority.
Ignoring tolerances entirely, or treating a breach of stage tolerance as something the Project Manager resolves locally instead of escalating to the board.
Tolerances are abstract numeric concepts, and candidates focus on the narrative of the scenario rather than asking 'which tolerance, whose tolerance, and is it breached?'
What to do instead
For every scenario, ask three questions: which tolerance (time, cost, scope, quality, risk, benefit), whose tolerance (stage or project), and has it been forecast to be exceeded? Stage tolerance breach is escalated by the Project Manager as an exception; project tolerance breach is the board's concern and may trigger project closure.
Treating tailoring as licence to drop processes or products, e.g., saying a small project can omit the business case or skip Managing a Stage Boundary.
Candidates read 'tailor to the environment' as 'scale down by removing elements', which contradicts the principle that tailoring adapts the method without compromising the principles.
What to do instead
Learn the tailoring rule explicitly: processes and products can be combined, simplified, or documented more lightly, but the principles must still be demonstrably applied and the minimum management products still exist in some form. Any answer that removes a principle or a required product is wrong, regardless of project size.