PRINCE2 7 Foundation common mistakes
PRINCE2 7 Foundation · Understand the traps and how to avoid them.
Answers questions about what a project delivers by swapping 'output', 'outcome' and 'benefit' interchangeably - for example calling a new booking system a benefit and the resulting increase in sales an output.
Everyday project language uses the three words loosely, but PRINCE2 draws a hard line between them because the business case, the benefits management approach and the Senior User's accountability all depend on that line.
What to do instead
Memorise the chain as a sentence you can write from memory: the project creates an output (the product), which enables an outcome (the new operational state), which delivers a benefit (the measurable value). Practise on a project you know: name one output, one outcome and one benefit, then check which of the three the project team actually builds.
Recites the seven principles from memory but treats them as optional good practice, choosing answer options in which a principle is quietly dropped to suit a small or agile project.
The practices and processes are explicitly tailorable, so candidates over-extend the idea of flexibility to the principles as well - the one part of PRINCE2 that cannot be tailored out.
What to do instead
Fix the rule in mind: principles are universal and self-validating, and only the way they are applied is tailored. For each principle, write one sentence describing what evidence would show it is being applied, and use that sentence to eliminate options that contradict it.
Selects answers in which the Project Board reviews day-to-day work, or in which the Project Manager escalates every issue upwards, instead of applying the principle of manage by exception.
Candidates read 'the board is accountable for the project' as 'the board is involved in the project', blurring accountability with operational decision-making.
What to do instead
Hold the tolerance loop in mind: the board sets tolerances, the Project Manager works within them, and escalation happens only when a tolerance is forecast to be exceeded, via an Exception Report. For any 'who decides X' question, ask first whether X falls inside the Project Manager's delegated tolerance.
Skims the People material and answers stakeholder questions using process logic - for example stating that stakeholders are engaged once during Starting up a Project, or that engaging them is the Project Board's job.
People reads like general management common sense, so it gets the least revision time, yet the exam phrases these questions in PRINCE2-specific terms about who engages stakeholders, when, and which management product records how it will be done.
What to do instead
Treat People as examinable content: learn that stakeholder identification and engagement continues throughout the project, that the Project Manager is responsible for it, and that it is planned and recorded in a management product rather than left informal. Answer in PRINCE2's wording, not intuitive HR wording.
Confuses management products with near-identical names - using an End Stage Report where an End Project Report is required, a Lessons Log where a Lessons Report is required, or a Project Brief where the project initiation documentation is required.
The products come in families with almost the same names, and candidates learn them as a list of titles rather than by purpose, timing and audience.
What to do instead
Build a three-column table for each product: purpose, the process in which it is created or updated, and who approves or receives it. Study the classic pairs side by side (End Stage vs End Project Report, Lessons Log vs Lessons Report, Project Brief vs project initiation documentation) so the difference is explicit rather than assumed.
Treats quality assurance, quality control and project assurance as the same thing, so questions about quality planning are answered by naming the wrong role or the wrong activity.
All three terms sit in the same vocabulary, and PRINCE2 separates reviewing whether the project's quality methods are sound from checking whether a specific product meets its quality criteria.
What to do instead
Anchor each term to the question it answers: quality control asks 'does this product meet its quality criteria, and who takes part in the review?'; quality assurance asks 'are the project's quality methods sound and being followed?'; project assurance asks 'is the project being run properly from this stakeholder's point of view?'. Learn which role performs each and where each appears in the quality management approach.
Answers plan questions from activity lists rather than from products - for example scheduling tasks first and adding product descriptions later, or muddling which plan level the Project Board actually approves.
Most candidates come from activity-based planning tools, whereas PRINCE2 planning is product-based, and the plan hierarchy with its different approvers is easy to skim because the terms feel familiar.
What to do instead
Practise building a small plan in PRINCE2 order every time: product breakdown structure, then product descriptions, then product flow diagram, then activities, dependencies, resources and estimates, then the schedule. Separately learn the plan levels (project, stage, team) and which management level approves each one.
Places familiar activities in the wrong process - for example putting the appointment of the Project Board or the creation of the daily log into Initiating a Project, or treating Managing a Stage Boundary and Closing a Project as interchangeable.
The processes overlap in content (both boundary processes produce reports and update the business case), and candidates learn the process names as a sequence without learning each process's trigger and purpose.
What to do instead
For every process, learn the trigger, the purpose and the outputs unique to it before memorising its activities. Concentrate on the boundaries: Starting up a Project runs from the mandate to the request to initiate; Managing a Stage Boundary is used only at a stage end or when an exception plan is needed; Closing a Project confirms product acceptance and the arrangements for benefits.
Mixes up the decision points, choosing 'authorise the project' when the question concerns approving the Project Brief, or 'authorise a stage' when the question concerns closing the project.
All five decision points sound like generic board approval, and their names differ by only a word or two, so candidates answer from the gist of the option rather than from the specific authorisation.
What to do instead
Learn the decision points as a numbered set, each paired with what it authorises: DP1 authorise initiation, DP2 authorise the project, DP3 authorise a stage or exception plan, DP4 give ad hoc direction, DP5 authorise project closure. Recite the pairs until the mapping is automatic.
Reads tailoring as 'cut what you don't need', so answers strip out principles, roles or management products to fit a small project, or choose an option where tailoring is left implicit and unrecorded.
Tailoring is often the last area revised and is easily reduced to a slogan about scaling, which invites the intuition that PRINCE2 is simplified by removing elements.
What to do instead
Learn tailoring as adapting how the practices, processes and products are applied to the project's environment while every principle remains satisfied; nothing is dropped without justification. Where two options look workable, prefer the one in which the tailoring decision is explicitly recorded, for example in the project initiation documentation.