What are the PRINCE2 principles?

PRINCE2 is built on 7 principles. They are universal, self-validating and empowering. All 7 MUST be applied to every project - if even one is missing, it is not a PRINCE2 project. Unlike themes and processes, principles are never tailored away.

The 7 principles

• Continued business justification - there must be a justifiable reason to start the project, it must remain valid throughout, and it is recorded in the Business Case.
• Learn from experience - lessons are sought, recorded and acted on at the start, throughout and at the end of a project. Never assume there is nothing to learn.
• Defined roles and responsibilities - the project has an organisation structure that engages the business, user and supplier interests, with clear accountability for everyone involved.
• Manage by stages - the project is planned, monitored and controlled on a stage-by-stage basis, giving senior management control points at the end of each management stage.
• Manage by exception - each management level is given tolerances (time, cost, quality, scope, benefits, risk) against which it can operate without needing to escalate; exceeding tolerance triggers an escalation to the next level up.
• Focus on products - the project focuses on the definition and delivery of products, particularly their quality requirements, not just on the activities needed to produce them.
• Tailor to suit the project - PRINCE2 is tailored to suit the project's environment, size, complexity, importance, capability and risk. Tailoring is not the same as embellishing or adding to the method.

Common mistakes to avoid

• Do not confuse principles with themes (there are 7 of each, but themes CAN be tailored, principles cannot).
• Do not think 'manage by exception' means no reporting - exception reports are still raised when tolerance is forecast to be exceeded.
• Do not think tailoring means skipping principles or roles - it means adapting HOW they are applied, not whether.
• Remember all 6 tolerance areas for manage by exception: time, cost, quality, scope, benefits and risk - not just time and cost.
• Learn from experience applies at ALL points (start, during, end) - not just as a lessons report at closure.

Exam tip

Questions often give a scenario and ask which principle is being illustrated or breached. Memorise the 7 names precisely (word order matters, e.g. 'continued business justification' not 'business justification continues') and match the scenario keyword to the principle.

Why themes matter

The seven PRINCE2 themes are the aspects of project management that must be addressed continually. This topic covers three of them: Business Case, Organization and Quality.

Business Case theme

The Business Case answers one question: is this project desirable, viable and achievable, and does it remain so?

• It is developed in Starting Up a Project and refined in Initiating a Project, then verified by the Project Board at every stage boundary.
• The Executive owns the Business Case throughout the project - not the Project Manager.
• PRINCE2 uses the output-outcome-benefit chain: a project delivers outputs, which enable outcomes, which realise benefits.
• Two techniques support it: cost-benefit analysis and investment appraisal.
• The Benefits Review Plan defines how and when benefits will be measured - some benefits are only measurable after the project closes, so this plan can outlive the project.
• Common mistake: thinking the Project Manager owns the Business Case. Remember - Executive owns it, Project Manager maintains supporting documents like the Benefits Review Plan.

Organization theme

This theme defines the roles and responsibilities in the temporary PRINCE2 project management team, based on a four-level structure: Corporate/programme management, Project Board, Project Manager, Team Manager(s).

• The Project Board has three roles: Executive (represents the business), Senior User (represents users, commits user resources, ensures benefits are realised) and Senior Supplier (represents supplier interests, ensures product quality from a supplier viewpoint).
• The Executive is ultimately accountable - only one person can hold this role.
• Project Assurance is independent of the Project Manager and checks the project on behalf of the Board members.
• Change Authority is a role the Board can delegate to authorise changes within set limits.
• Project Support provides administrative help and can include configuration management.
• Common mistake: confusing Project Assurance (independent checking) with Project Support (admin help) - they are different roles.

Quality theme

Quality is about ensuring the project delivers products that are fit for purpose - meeting user needs, not just conforming to a specification.

• Quality planning happens early: quality criteria and quality methods are captured in the Project Product Description and Product Descriptions.
• Quality control is carried out through quality methods - mainly quality inspection (e.g. reviews) and quality testing.
• The Quality Register is the log that records all planned and completed quality activities and their status.
• Two key documents: the Quality Management Strategy (how quality will be managed) and the Quality Register (tracking log).
• Distinguish quality assurance (independent check that the approach is being followed correctly, done outside the project) from quality control (checking specific products against criteria, done within the project).
• Common mistake: mixing up the Quality Management Strategy (the plan) with the Quality Register (the record).

Why themes exist

Themes are the 7 aspects of project management that must be applied continually throughout a PRINCE2 project. This topic covers four of them: Risk, Change, Progress, and Plans. Each theme has a specific purpose and must be tailored, not skipped.

Risk theme

The purpose of the Risk theme is to identify, assess and control uncertainty. PRINCE2 uses a Risk Management Procedure with 5 steps: Identify, Assess, Plan, Implement, Communicate (this last one runs throughout, not as a single step). Risks are recorded in the Risk Register. Each risk has a probability, impact and proximity. Responses to threats are: Avoid, Reduce, Fallback, Transfer, Accept, Share. Responses to opportunities are: Exploit, Enhance, Reject, Share. A common mistake is confusing risk responses for threats with those for opportunities - remember Share applies to both.

Change theme

The purpose of the Change theme is to identify, assess and control any potential and approved changes to baselines. Three types of issue: Request for Change, Off-Specification, and Problem/Concern. All issues are logged in the Issue Register and assessed for severity. Changes go through Issue and Change Control Procedure. Configuration Management supports this by tracking product versions - the 5 core activities are Planning, Identification, Control, Status Accounting, Verification and Audit. Do not confuse an Off-Specification (product fails to meet spec) with a Request for Change (a wanted change to an agreed baseline).

Progress theme

The purpose of the Progress theme is to establish mechanisms to monitor and compare actual achievements against planned ones, and to control any unacceptable deviations. Progress is controlled using tolerances across 6 targets: Time, Cost, Quality, Scope, Risk, Benefits (remember: TeCQuSRB, often shortened to Time/Cost/Scope/Quality plus Risk/Benefit). If tolerance is forecast to be exceeded, an exception is raised via an Exception Report to the next level up. Management stages and management by exception are the key mechanisms - they let the Project Board delegate day-to-day authority while retaining control.

Plans theme

The purpose of the Plans theme is to facilitate communication and control by defining the means of delivering products. PRINCE2 uses three levels of plan: Project Plan, Stage Plan, Team Plan (Team Plans are optional). Plans are created using Product-Based Planning, which has 4 steps: write the Project Product Description, create a Product Breakdown Structure, write Product Descriptions, create a Product Flow Diagram. A common mistake is starting planning with activities and tasks rather than products - PRINCE2 is product-focused, not activity-focused.

Exam tip

Expect questions that test the exact terminology (e.g. Fallback vs Reduce) and the correct sequence of steps in the Risk Management Procedure and Product-Based Planning.

What the PRINCE2 processes are for

PRINCE2 has seven processes that describe WHO does WHAT and WHEN across the life of a project, from the spark of an idea through to closure. Each process is a set of activities linked to roles, and each hands off to the next. Think of the processes as the project's timeline, running alongside the seven themes (the knowledge areas applied throughout) and the seven principles (the guiding philosophy).

The seven processes in order

• Starting up a Project (SU) - a short pre-project process to check the idea is worth doing before committing real money.
• Directing a Project (DP) - runs from start to finish, used only by the Project Board to make key decisions.
• Initiating a Project (IP) - builds the Project Initiation Documentation (PID), the baseline for the whole project.
• Controlling a Stage (CS) - the day-to-day work of the Project Manager, managing each management stage.
• Managing Product Delivery (MP) - where Team Managers accept, execute and deliver work packages.
• Managing a Stage Boundary (SB) - reports on the current stage and plans the next one.
• Closing a Project (CP) - a controlled, deliberate close, not an abrupt stop.

Key sequencing rules to remember

• SU happens before the project formally exists - it produces the outline Project Brief and the Project Product Description.
• DP is triggered by, and only responds to, the other processes - the Project Board never manages the project directly, only makes decisions at key points.
• IP produces the PID, which the Project Board must approve before work starts.
• CS and MP run in parallel throughout each stage - CS is the Project Manager directing, MP is the Team Manager delivering.
• SB happens near the end of every stage except the final one, where CP takes over instead.
• CP is a process, not just an event - it confirms acceptance, evaluates the project, and recommends follow-on actions.

Common mistakes to avoid

• Do not confuse SU (deciding whether to start) with IP (planning how to run the whole project) - SU is quick and light, IP is thorough.
• Do not think the Project Board manages daily work - that is DP's whole point, it is exception-driven, not hands-on.
• Do not forget MP exists even on projects with no separate Team Manager - the Project Manager can perform the MP activities themselves.
• Remember there is no SB at the end of the final stage - CP replaces it.
• The seven processes are mandatory to consider, but PRINCE2 is meant to be tailored to the size and complexity of the project.

Why roles matter in PRINCE2

PRINCE2 is role-based, not person-based. One person can hold several roles, and a role can be shared by several people (as long as no conflict of interest). The Project Manager cannot also be the Executive, and Project Assurance must stay independent of the Project Manager.

Project Board

The Project Board owns the project and is accountable to corporate/programme management. It has three roles:

• Executive: chairs the board, owns the Business Case, ultimately accountable for the project's success. Only ONE Executive.
• Senior User(s): represent(s) everyone who will use the products, specify benefits, commit user resources, and are accountable for the benefits being realised.
• Senior Supplier(s): represent(s) those designing, developing, procuring and implementing the products; accountable for the quality of supplier deliverables.

Project Manager

Runs the project day-to-day on behalf of the Project Board: planning, delegating, monitoring and controlling. Manages Team Managers and reports progress via Highlight Reports and end-stage/exception reports.

Team Manager

Optional role (used on larger projects) that creates Work Packages into products and manages a team; reports to the Project Manager via Checkpoint Reports.

Project Assurance

Independent check, on behalf of the Project Board, that the project remains viable and is being run correctly (business, user and supplier assurance). Must NOT be delegated to the Project Manager, because it would mean checking your own work.

Change Authority

A person or group, delegated by the Project Board, given authority to approve or reject requests for change and off-specifications, often within a set change budget.

Project Support

Optional administrative role — filing, configuration management, planning tools — can be a separate person/office or covered by the Project Manager if there is no dedicated support.

Corporate/programme management

Sits above the Project Board, appoints the Executive, sets project tolerances, and receives the End Project Report.

Common exam mistakes

• Confusing Project Assurance (independent check) with Project Support (admin help).
• Thinking the Project Manager appoints the Executive — it is the other way round, corporate management appoints the Executive.
• Forgetting there must be exactly one Executive but user/supplier roles can be shared or split.
• Mixing up Highlight Reports (Project Manager to Board) with Checkpoint Reports (Team Manager to Project Manager).

What are management products?

PRINCE2 defines three types of management product. These are NOT the specialist products the project delivers (like a bridge or an app) - they are the paperwork that runs the project.

• Baselines - approved products that define aspects of the project and are subject to change control, eg the Project Plan, PID, Product Descriptions.
• Records - dynamic products that maintain a log of project progress, eg the Risk Register, Issue Register, Quality Register, Daily Log, Lessons Log.
• Reports - give a snapshot of the status of aspects of the project, eg Highlight Report, End Stage Report, End Project Report, Lessons Report.

The three levels of plan

PRINCE2 uses three levels of plan, matched to the three levels of management:

• Project Plan - Board level, whole project, mandatory.
• Stage Plan - Team Manager/PM level, one management stage at a time, mandatory.
• Team Plan - Team Manager level, optional, used when work is delegated.

An Exception Plan replaces a Stage or Project Plan when a tolerance has been (or is forecast to be) exceeded - it covers the period from now to the end of the current stage.

Key management products to know cold

• Business Case - the justification, owned by the Executive, checked at every stage boundary.
• Project Initiation Documentation (PID) - the baseline for the whole project, created during Initiating a Project.
• Product Description - defines a product's purpose, composition, derivation, format, and quality criteria/tolerance/method.
• Work Package - the agreement between PM and Team Manager to deliver one or more products.
• Communication Management Approach - defines how and when communication will happen.

Tailoring

Tailoring means adapting PRINCE2 to suit the project's context - size, complexity, importance, capability and risk. Tailoring is NOT the same as embedding (which is adopting PRINCE2 organisation-wide as standard practice).

• The seven PRINCE2 principles are never tailored - they always apply.
• Themes, processes and management products CAN and SHOULD be tailored.
• You can combine management products (eg merge the Risk and Issue Register) but you must never lose the required information.
• Justify and record every tailoring decision, normally in the PID.

Common mistakes

• Confusing baselines with records - baselines change only through change control, records are updated routinely as work happens.
• Thinking tailoring means dropping themes or processes - you tailor how they're applied, not whether they're applied.
• Believing small projects skip the PID - it can be brief, but it must still exist.
• Mixing up Product Description (defines what a product should be) with Product Status Account (reports on what state products are actually in).