PRINCE2 Foundation — PRINCE2 Project Management Foundation (Version 7) Cheat Sheet

For Foundation-level questions, expect emphasis on recognition and understanding: which PRINCE2 element applies, who is responsible, which management product is used, what process happens next, and how principles govern decisions.

Five integrated elements

Seven project performance aspects

PRINCE2 Version 7 uses these performance aspects when setting targets, monitoring progress, and applying tolerances.

The PRINCE2 7 Method at a Glance

PRINCE2 7 is built around integrated elements. Do not study the parts in isolation; exam questions often combine a process, role, practice, and management product in one scenario.

The Seven PRINCE2 Principles

PRINCE2 principles are the safest first filter in many questions. If an answer violates a principle, it is probably wrong.

Fast Principle Decision Rules

• If the question asks why the project should continue, think business justification.
• If the question asks who has authority, think roles, responsibilities, and relationships.
• If the question asks how much freedom a manager has, think manage by exception.
• If the question asks how to avoid vague deliverables, think focus on products.
• If the question asks how PRINCE2 fits a small, agile, supplier-led, complex, or regulated environment, think tailoring.
• If the question asks what should be reused or recorded for future use, think learn from experience.

People-related exam traps

Accountability shortcuts

Management by Exception

Management by exception is one of the most tested PRINCE2 control ideas.

Authority Levels

Exception Decision Path

    flowchart TD
	    A[Variance identified] --> B{Forecast outside tolerance?}
	    B -- No --> C[Project Manager or Team Manager takes corrective action within authority]
	    B -- Yes --> D[Exception]
	    D --> E[Escalate to next higher authority]
	    E --> F{Authority requests exception plan?}
	    F -- Yes --> G[Prepare exception plan]
	    F -- No --> H[Other direction: continue, change scope, stop, or close]
	    G --> I{Exception plan approved?}
	    I -- Yes --> J[Replace affected plan and continue]
	    I -- No --> H

Exception Traps

• An actual small delay is not automatically an exception; the key is the forecast against tolerance.
• If a Team Manager forecasts work package tolerance will be exceeded, the Project Manager is the next authority.
• If a Project Manager forecasts stage tolerance will be exceeded, the Project Board is the next authority.
• An exception plan is created only when requested or required by the controlling authority.
• Tolerance supports delegation. Without tolerance, every decision would require escalation.

The Seven PRINCE2 Practices

PRINCE2 7 uses the term practices for the recurring disciplines that support project management throughout the lifecycle.

Business Case Practice

The business case is the central justification for the project. In PRINCE2, a project should not start, continue, or close without reference to whether it still makes business sense.

Business Case Concepts

Business Case Traps

• The Executive is accountable for the business case; the Project Manager may maintain or draft it.
• Benefits may be realized after the project closes, so benefits planning is not the same as product delivery.
• A project can deliver all outputs and still fail if expected outcomes or benefits are not achieved.
• Disbenefits are not risks. A disbenefit is an expected negative consequence; a risk is uncertain.
• Continued business justification includes costs, timescales, risks, benefits, scope, quality, and sustainability considerations.

Plan types

Plan selection traps

Plans Practice

PRINCE2 planning is product-based. The exam frequently tests the difference between defining products and merely listing activities.

Levels of Plan

Product-Based Planning

Planning Traps

• A project plan is not detailed enough for daily control of all work.
• A stage plan is more detailed because it covers the near-term management stage.
• A team plan may be optional depending on project needs and team structure.
• An exception plan is not a casual workaround; it replaces an approved plan after an exception is handled.
• Product descriptions help define quality expectations before work starts.

Quality review technique

Exam cue: a quality review is mainly to check a product against agreed criteria and identify defects. It is not a general design workshop.

Quality Practice

Quality in PRINCE2 means products are fit for purpose and meet agreed criteria. Do not reduce quality to “testing at the end.”

Quality Terms

Quality Traps

• Acceptance criteria apply to acceptance of the project product; quality criteria apply to individual products.
• Quality should be planned before product creation, not inspected in only at the end.
• Quality assurance is independent of the project management team’s daily product checks.
• A product can be complete from an activity perspective but unacceptable if quality criteria are not met.

Risk procedure

Risk roles and responses

Risk Practice

A risk is an uncertain event or set of events that, if it occurs, affects objectives. Risks can be threats or opportunities.

Risk Basics

Risk Responses

Risk Traps

• A risk has not happened yet; an issue has happened or is currently affecting the project.
• A risk can be positive or negative.
• A risk response should be proportionate to the risk exposure.
• Risk management supports decision-making; it is not just maintaining a register.
• Risk tolerance is part of management by exception.

Issue handling logic

Common issue decisions

Issues Practice

Issues are events that have happened, are happening, or require a decision. PRINCE2 commonly distinguishes between different issue types.

Issue Handling Decision Rules

• If it is uncertain, manage it as a risk.
• If it has happened or requires a decision now, manage it as an issue.
• If it changes an approved baseline, consider change control and delegated authority.
• If the Project Manager can resolve it within tolerance, it may not need escalation.
• If it threatens tolerance, it may become an exception.

Progress decision table

Progress Practice

Progress is about comparing actual and forecast performance against approved plans and tolerances.

Seven Performance Aspects to Control

PRINCE2 7 emphasizes control of multiple performance aspects:

Tolerances and Exceptions

Progress Reporting

Management Products to Recognize

You do not need to write full PRINCE2 documents for Foundation review, but you should recognize what each management product is for.

Process reference table

Process activity cues

The Seven PRINCE2 Processes

Processes describe what happens across the project lifecycle. For Foundation review, know the purpose, main actors, and main management products.

Starting up a Project

Purpose: Ensure the prerequisites for initiating a project are in place and avoid wasting effort on a poor idea.

High-yield points:

• Triggered by a project mandate or similar initiating information.
• Confirms there is enough justification to invest in initiation.
• Appoints or identifies key roles such as the Executive and Project Manager.
• Captures previous lessons.
• Produces early definition such as the project brief and outline business case.
• Plans the initiation stage.

Common trap: Starting up a Project does not produce the full Project Initiation Documentation. It asks, “Is this worth initiating?”

Directing a Project

Purpose: Allow the Project Board to remain accountable while delegating day-to-day management to the Project Manager.

High-yield Project Board decisions:

• Authorize initiation.
• Authorize the project.
• Authorize each stage or exception plan.
• Provide ad hoc direction when needed.
• Authorize project closure.

Common trap: The Project Board does not manage work packages or daily team activity.

Initiating a Project

Purpose: Establish a firm foundation so the organization understands what is being delivered, why, how, by whom, at what cost, and under what controls.

Key outputs commonly associated with initiation:

• Project Initiation Documentation
• Business case refinement
• Project plan
• Management approaches
• Project controls
• Benefits management approach

Common trap: Initiation is where the project is properly defined, but the project is still subject to authorization before full delivery commitment.

Controlling a Stage

Purpose: The Project Manager manages the current stage within tolerances.

Typical activities:

• Authorize work packages.
• Monitor work package progress.
• Review checkpoint reports.
• Capture and examine issues and risks.
• Take corrective action within tolerance.
• Report progress to the Project Board through highlight reports.
• Escalate forecast exceptions.

Common trap: If the forecast remains within stage tolerance, the Project Manager should normally take corrective action rather than escalate every variance.

Managing Product Delivery

Purpose: Control the interface between the Project Manager and those producing specialist products.

Typical flow:

1. Team Manager accepts a work package.
2. Team creates products.
3. Quality checks are performed.
4. Team Manager reports progress through checkpoint reports.
5. Completed products are delivered back according to the work package agreement.

Common trap: Work packages are not informal task lists; they define what is to be delivered, constraints, reporting, quality expectations, and acceptance arrangements.

Managing a Stage Boundary

Purpose: Provide information needed for the Project Board to decide whether to continue.

• Review current stage performance.
• Update the business case.
• Update the project plan if needed.
• Prepare the next stage plan.
• Update risk, issue, lessons, and other records.
• Prepare an end stage report.
• Prepare an exception plan if requested.

Common trap: Stage boundaries support control. They are not just administrative milestones.

Closing a Project

Purpose: Close the project in a controlled way, whether completed as planned or closed prematurely.

• Confirm acceptance of products.
• Ensure handover and support arrangements are addressed.
• Evaluate project performance.
• Capture lessons.
• Recommend closure to the Project Board.
• Prepare closure information such as an end project report.
• Update benefits-related information for post-project review where appropriate.

Common trap: Closure is not just “stop working.” It confirms status, acceptance, follow-on actions, lessons, and benefit review arrangements.

Agile/hybrid exam cues

Last-Minute Review Checklist

Before moving to question-bank practice, confirm that you can answer these without notes:

• Can you name and explain all seven PRINCE2 principles?
• Can you distinguish the seven practices from the seven processes?
• Can you explain the business, user, and supplier interests?
• Can you identify who sits on the Project Board?
• Can you explain what the Executive is accountable for?
• Can you distinguish project plan, stage plan, team plan, and exception plan?
• Can you tell whether a scenario is a risk, issue, or exception?
• Can you explain how tolerance enables management by exception?
• Can you identify checkpoint, highlight, exception, end stage, and end project reports?
• Can you explain why product-based planning comes before activity planning?
• Can you distinguish acceptance criteria from quality criteria?
• Can you explain how tailoring preserves PRINCE2 principles?
• Can you identify what happens in each PRINCE2 process?

Key Roles

Accountability Shortcuts

• Project Board directs.
• Project Manager manages day to day.
• Team Manager delivers assigned work packages.
• Executive owns business justification.
• Senior User represents needs and benefits.
• Senior Supplier represents delivery capability.
• Project Assurance checks independently; it does not manage the project for the Project Manager.

Tailoring Traps

• Tailoring is not skipping governance because the project is small.
• Tailoring should be deliberate and documented enough to be understood.
• Principles remain mandatory.
• A high-risk small project may need stronger controls than a low-risk large project.
• Tailoring should account for project context, including complexity, commercial arrangements, culture, sustainability, and delivery method.

Project Board vs Project Manager

Risk vs Issue vs Exception

Quality Assurance vs Quality Control

Lessons Log vs Lessons Report