Study PRINCE2 Foundation by classifying, not just memorising. The method's vocabulary sorts into five families: principles (always-on commitments), practices (ongoing aspects such as risk and quality), processes (phased activities), roles (who decides), and management products (what is written down and when). The method's term families overlap, so a single sentence can touch several at once; build a routine that tags each clue to its family, then drills role-to-decision and situation-to-product pairings until they are automatic. Use the worked scenarios and rubric below as learning milestones, not predictions.
The Core Difficulty: Five Interlocking Term Families, Not One Long List
PRINCE2 is organised into principles, practices, processes, people and roles, and management products. A single scenario sentence can blend several families at once, so build labelling fluency before drilling individual definitions.
A principle such as manage by exception is a commitment that shapes the whole project. A practice such as the risk practice is an aspect of running a project that is applied continuously. A process such as controlling a stage is a sequence of activities in time. A role such as the executive carries specific decision rights. A management product such as an exception report is a written output produced at a defined moment. The same scenario sentence can legitimately touch all five families at once.
The confusion this creates is predictable in your own revision notes. If you write 'the executive manages by exception', you have blended a role, a principle, and an implicit process decision into one sentence, and any question separating those three will defeat you. Practise the reverse skill first: take any textbook sentence and label it P1 for principle, P2 for practice, PR for process, R for role, or MP for management product. Once labelling feels instant, definition memorisation becomes far easier because each definition now has a shelf.
- Principles: commitments that must hold for the project to be PRINCE2 (for example, continued business justification).
- Practices: ongoing aspects such as plans, quality, risk, issues, and progress.
- Processes: ordered phases from starting up through closing.
- Roles: named decision rights, from the project board down to team managers.
- Management products: documents with a defined purpose and moment, from project brief to end project report.
Seven Principles: Separating Manage by Exception from Manage by Stages
Manage by exception means delegating with defined tolerances and escalating only when they are forecast to be breached. Manage by stages means planning, authorising, and reviewing the project in chunks. The two are easy to confuse.
Manage by stages is about structure in time: the project is divided into management stages, each ending with a review before the board authorises the next. Manage by exception is about authority and information flow: the board sets tolerances, the project manager runs the stage inside them, and escalation happens when a forecast shows the tolerances will be exceeded. A stage can run smoothly with no escalation at all, and an exception can arise mid-stage; neither principle depends on the other being triggered.
Worked scenario: mid-way through a warehouse fit-out project, a key supplier collapses and the business case for the whole project becomes doubtful. The plausible mistake is for the project manager to announce in the next highlight report that the project is cancelled and to instruct teams to stop work. The better decision is to record the situation as an issue, assess its impact on the business case, and escalate to the project board, because the executive owns the business case and only the board can stop, redirect, or continue the project. This matters because continued business justification is a principle that must be actively confirmed by the right authority, and stopping a project without that decision breaks accountability and leaves contractual exposure unmanaged.
The Seven Practices: Continuous Aspects, Not Project Phases
The practices cover business case, organising, plans, quality, risk, issues, and progress. Unlike processes, they are not time slots; each runs across the whole lifecycle. Read every question about one of these topics through its practice lens.
A useful test when revising: if a topic could appear on the agenda of any meeting at any point in the project, it is probably a practice. The business case is verified and updated throughout, not written once at the start. Risks are identified and reviewed continuously. Plans exist at several levels (project, stage, team) and are refined as stages approach. Quality, issues, and progress each have their own practice describing how that aspect is managed end to end.
Note on labels: some editions of the manual call these aspects 'themes' rather than 'practices'. The labels differ, the content largely does not, so match the vocabulary of the manual edition your course and practice materials use, and do not mix editions mid-revision. When a scenario question describes, say, a new risk being spotted during stage execution, ask which practice explains the response (risk), which process houses the activity (controlling a stage), and who needs to know under the tolerances set (the roles). Answering one blended question by routing through three families is exactly the skill the classification drill from the first section builds.
Roles and Decisions: Who Owns the Business Case, Tolerances, and Approvals
The executive owns the business case and directs the board. Senior users represent benefit recipients, senior suppliers represent delivery capability, and the project manager runs the stage within tolerances. Map every decision to its owner.
A pairing to know cold: which decision belongs to which role. Business case direction and project-level authorisation sit with the executive and the project board; day-to-day stage management sits with the project manager; delivery of products to specification sits with team managers; project assurance provides independent checks on behalf of the board rather than reporting to the project manager. When a scenario hands a business case decision to a project manager or gives the project manager independent assurance duties, the pairing is broken and the answer is wrong.
Worked scenario: a team manager reports that a design work package will slip by two days, against a work package tolerance of three days and a stage time tolerance the project manager is comfortably inside. The plausible mistake is escalating immediately to the project board, treating every slip as an exception. The better decision is for the project manager to accept the recovery within the work package tolerance and continue managing the stage, escalating only if the forecast shows the stage tolerance itself will be breached. This matters because manage by exception only reduces noise if escalation thresholds are respected: escalating too often undermines delegation, while absorbing a slip that eats into stage tolerance hides a genuine exception from the people who funded the project.
Management Products: Matching the Right Document to the Right Moment
Each management product has a defined trigger: the project brief precedes authorisation, work packages delegate delivery, highlight reports inform, and exception reports respond to forecast tolerance breaches. Match situation to product, not to a favourite document.
The project brief and the project initiation documentation (PID) are the classic confusion pair. The brief is a transitional product created during starting up a project so the board can decide whether initiating is worth the cost. The PID is created and refined during initiating a project and becomes the working reference for the project. If a question describes a document still being assembled to justify whether detailed planning should even happen, that is the brief; if it describes the established reference the project is being run against, that is the PID.
Reports follow the same trigger logic. A highlight report is a routine, scheduled progress summary from the project manager to the board. An exception report is triggered by a forecast that tolerances will be breached and presents the situation with options for the board to choose. An issue report captures something that has already happened or been raised: a request for change, an off-specification, or a problem or concern. Before answering any report question, ask whether the situation is routine (highlight), forecast (exception), or an event that has occurred (issue report).
| Situation in the scenario | Correct management product | Typically prepared by | Main audience |
|---|---|---|---|
| Pre-project output letting the board judge whether to commit to detailed initiation | Project brief | Project manager with the executive | Project board |
| Delegated, agreed description of products a team will deliver, with tolerances | Work package | Project manager | Team manager |
| Routine, periodic progress summary for the stage | Highlight report | Project manager | Project board |
| Forecast that stage or project tolerances will be exceeded | Exception report | Project manager | Project board |
| A change request, off-specification, or problem has been raised | Issue report | Project manager (or whoever raised it) | Project manager, then board or change authority as needed |
| Board review point at the end of a management stage | End stage report | Project manager | Project board |
Processes in Order: Starting Up Versus Initiating, Directing Versus Managing
Starting up a project happens before the project exists; initiating it happens after authorisation to plan in detail. Directing a project is the board's activity across the lifecycle; managing stage boundary work prepares each authorisation decision.
Starting up a project and initiating a project are inherently confusable, because both happen before delivery begins and both involve planning. The distinction is depth and authority: starting up is short, pre-project work — appointing the executive and project manager, capturing an outline of the idea, and producing the project brief. Initiating is where the method does its heavy planning: the PID, detailed plans, and the refined business case, all feeding the board's decision to authorise the project. If a scenario says 'the board wants to see whether this idea justifies the cost of proper planning', the answer lives in starting up; if it says 'the project is being set up in detail before delivery authorisation', it lives in initiating.
Directing a project is the project board's own process and runs from authorisation through to closure, including ad hoc decisions between stage ends. Managing a stage boundary is the project manager's process that generates the products the board needs at each stage end, including an updated plan and business case for the next stage. The pairing test: whenever the question's actor is the board, look for directing; whenever the actor is the project manager preparing something for a stage-end decision, look for managing a stage boundary. Controlling a stage covers the project manager's day-to-day work inside a stage, and managing product delivery covers the team managers' side of that interface.
A Scenario-Reading Routine and a Three-Week Preparation Sequence
Read each scenario in three passes: classify the clue, name the role with the decision right, and select the product or activity with the correct trigger. Then run a structured three-week sequence ending in readiness checks.
Practical exercise: take any project scenario (a construction fit-out, a software rollout, an office relocation) and mark each sentence with its family label and its owner, for example 'sentence four: principle, manage by exception; decision owner: project board'. Then self-check against a rubric of learning milestones: you can label at least 8 of 10 sentences correctly; you can name all seven principles, practices, and processes from memory; you can allocate every decision in the scenario to the right role with no hesitation; and you can state the trigger for each report in the decision table above. These are study milestones to show your classification skill is forming, not a prediction of any exam outcome.
A realistic adaptable sequence: in week one, learn the shape of the method by building your own one-page map of the five families rather than copying one, and run the labelling drill daily. In week two, drill pairings: role-to-decision flashcards and situation-to-product sorting using the table above, extended with products from your manual. In week three, do timed sets of mixed scenario questions, then review every miss by family, not by question: a miss in the process family sends you back to the sequence map, a miss in the roles family to the decision-rights list. Finish with readiness checks: you can explain why each wrong answer in a practice set is wrong in family terms, and your labelling drill stays above threshold under time pressure.
Administrative note: exam format, duration, and booking details are set by the examination institute and can change, so confirm current arrangements directly via PeopleCert (https://www.peoplecert.org/) before scheduling.
- Exercise rubric: 8+ of 10 sentences correctly labelled by family; all role-to-decision pairs named instantly; all report triggers stated without notes.
- Week 1: build the five-family map and run daily labelling drills.
- Week 2: pairings week — flashcards for roles, sorting drills for management products.
- Week 3: timed mixed sets, review misses by family, finish with readiness checks.
- Readiness check: you can articulate why each distractor in a practice question is wrong, in the method's own vocabulary.
References and further reading
Use these references to explore the concepts and check the latest information from the relevant organizations.