PRINCE2 (Projects IN Controlled Environments): PRINCE2 – Tutorial (about 60 minutes)

PRINCE2 (Projects IN Controlled Environments) is a process-based method for managing projects. It sets out who decides what, when decisions are taken, and what information people need to take them. Project managers, sponsors, PMO staff, team leads and suppliers use it in government, finance, engineering, IT, health and many other sectors, often alongside agile delivery. After this tutorial you will be able to explain how PRINCE2 is built, follow a project through its seven processes, and tailor the method sensibly to a real project.

Free tutorial · about 60 minutes · 7 lessons · 4 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: The current edition is PRINCE2 7 (the seventh edition), published in September 2023 under the AXELOS brand of PeopleCert, which has owned the method since it acquired AXELOS in 2021. The official manual is Managing Successful Projects with PRINCE2. PeopleCert's certification pages currently list PRINCE2 Project Management Foundation (Version 7) and Practitioner (Version 7) as the live examinations. PeopleCert's pages show no newer edition and no announced revision. PRINCE2 is a proprietary best-practice method, not an ISO or national standard. Verified 2026-10-29 against PeopleCert's PRINCE2 7 Foundation and Practitioner pages.

Who it is for: new and aspiring project managers, team managers, project sponsors and board members, PMO and project support staff, business analysts, and engineers or consultants who work on PRINCE2 projects and want to understand the vocabulary and the decisions around them.

Prerequisites: none. It helps if you have worked on a project, but every term is defined when it first appears.

How to use this tutorial: work through the seven lessons in order (about 45 minutes) and study the four diagrams. Then spend the rest of the hour on the reflection questions before you take the 25-question knowledge check.

Learning objectives:

You will be able to explain why PRINCE2 exists, who owns it and what problems it is designed to prevent.
You will be able to name and apply the seven principles, the seven practices and the seven processes.
You will be able to describe the project management team structure and the duties of each role.
You will be able to follow a project from its mandate to closure, naming the main decisions and management products.
You will be able to explain how tolerances and management by exception keep senior people in control without micromanaging.
You will be able to describe the Foundation and Practitioner examinations and what PRINCE2 certification does and does not prove.
You will be able to relate PRINCE2 to PRINCE2 Agile, MSP, P3M3, the PMBOK Guide, ISO 21502 and Scrum.

Lesson 1 – Origins, purpose and scope

Why a project method at all?

A project is different from day-to-day operations. It is temporary, it brings together people who may not normally work together, it changes something, and it carries more uncertainty than routine work. Those features create familiar failure patterns: nobody is sure who can approve a change, the reason for the project fades while spending continues, the team builds something that users did not need, and senior managers either interfere in every detail or only hear about problems when it is too late to act.

PRINCE2 answers those problems with structure. It gives each project a clear decision-making body, a documented justification that is checked throughout, a plan broken into stages with a decision point between them, agreed limits within which each level of management can act alone, and a defined way of handling changes, risks and lessons. The method is generic. It describes how to manage a project, not how to do the specialist work. Writing software, building a bridge or running a marketing campaign needs other techniques, and PRINCE2 deliberately leaves them out.

Where it came from

PRINCE2 has its roots in a UK government method called PROMPT II. In 1989 the Central Computer and Telecommunications Agency (CCTA) adopted a version of it, named PRINCE, as the government standard for IT projects. In 1996 the method was rewritten as PRINCE2, a generic method for any type of project. Major revisions followed in 2009 and 2017, and these are now counted as the fifth and sixth editions. Ownership passed from the UK Cabinet Office to AXELOS, a joint venture formed in 2013, and then to PeopleCert when it acquired AXELOS in 2021.

The seventh edition, released in September 2023, kept the core of the method: the seven principles and the seven processes stayed, with only minor changes to process activities. The main changes were:

The former "themes" were renamed practices, and the "change" theme became the issues practice.
A new people element was placed at the heart of the method, covering leadership, teams, communication and the organisational change that a project causes.
Sustainability became a performance target that a project must plan for and control, alongside time, cost, quality, scope, benefits and risk.
New guidance was added on commercial management, digital and data management, and sustainability management.
Examples and guidance were updated for modern ways of working, including agile and hybrid delivery.

What PRINCE2 covers and what it leaves out

PRINCE2 covers the management of one project, from the moment someone first asks for it to the moment it is formally closed. It does not cover the specialist techniques mentioned above. It also does not cover the management of several related projects as a programme (that is MSP, Managing Successful Programmes) or of an organisation's whole change investment (portfolio management). The method also says little about specific interpersonal skills such as negotiation and coaching. The seventh edition adds a people element, but it still expects you to develop those skills elsewhere.

A project that follows PRINCE2 should be recognisable by what it does, not by how many documents it produces. The method itself says that the seven principles must all be applied. If one is missing, the project is not really a PRINCE2 project, however many PRINCE2 templates it uses. Everything else can be adapted.

Lesson 2 – Key concepts and vocabulary

PRINCE2 uses ordinary words in precise ways. Learn these before you study the structure, because reports, plans and board discussions will use them.

Project – a temporary organisation, with its own team and decision makers, created to deliver one or more products that a business case has justified.
Business case – the justification for the project. It sets out the reasons, options considered, expected benefits and dis-benefits, costs, timescale and major risks, and shows whether the investment is worthwhile.
Benefit – a gain that can be measured and that stakeholders value, arising from an outcome. A dis-benefit is a measurable consequence that some stakeholders regard as a loss.
Output, outcome and benefit – an output is a product the project delivers (a new system); an outcome is the change that results from using it (orders processed faster); a benefit is the measurable improvement from that outcome (lower cost per order).
Product – anything, physical or not, that the project receives or delivers and that can be specified beforehand, then built and checked. Specialist products are what the project exists to deliver; management products are the documents and records used to manage it.
Management stage – a section of the project that the project manager runs on behalf of the project board. At the end of each stage the board decides whether to continue.
Tolerance – the agreed margin either side of a plan's target, set for a performance target such as time or cost (for example plus or minus two weeks, or plus ten per cent cost). A manager acts alone inside it; beyond it, the decision moves up one level.
Exception – the situation that arises when a forecast shows a plan going outside its agreed tolerance. It is escalated to whoever set that tolerance.
Project board – the group of senior people (executive, senior user and senior supplier) accountable for the project's success and with the authority to direct it.
Executive – the single person ultimately accountable for the project. The executive owns the business case and chairs the project board.
Work package – the bundle of instructions and product details that the project manager agrees with a team manager when assigning work to a team.
Issue – something relevant to the project that has already occurred, was not expected, and needs a management decision. Requests for change, off-specifications (something delivered or forecast to be delivered that does not meet its specification) and problems or concerns are all issues.
Risk – something that might or might not happen and, if it did, would make the objectives easier or harder to achieve. A negative risk is a threat; a positive one is an opportunity.
Project initiation documentation (PID) – the set of documents, assembled during initiation, that defines the project and forms the baseline against which progress is judged.
Tailoring – adapting the method to the project's environment, scale, complexity, risk and delivery approach, while keeping all the principles in place.

Five integrated elements

The seventh edition presents PRINCE2 as five integrated elements. Four of them, the principles, practices, processes and project context, describe the method and how it is adjusted. The fifth, people, sits at the centre because projects are delivered by people working together, often through change that affects other people.

A useful way to read Figure 1 is from the top. The project context (the organisation, its sector, the size and risk of the project, and its delivery approach) and the principles together guide the people. The people then apply the practices, which are aspects of project management that must be handled continuously, through the processes, which say who does what at which point in the lifecycle.

Lesson 3 – Structure of the method

The seven principles

The principles are universal, self-validating and empowering. They apply to every project, they have been proved in practice, and they give people confidence to adapt the rest of the method. In plain terms:

Ensure continued business justification. There must be a justifiable reason to start the project, that reason must stay valid throughout, and it must be recorded and approved. If the justification disappears, the project should stop or change course, however much has been spent.
Learn from experience. Teams look for lessons from earlier projects when they start, record new lessons as they go, and pass them on at the end.
Define roles, responsibilities and relationships. Business, user and supplier interests must all be represented in decision making, and everyone should know what is expected of them and whom they deal with.
Manage by stages. The project is planned, monitored and controlled stage by stage. Each stage ends with a decision point where the board reviews progress and the business case before committing more resources.
Manage by exception. Each level of management has defined tolerances. Within them, people get on with their work and report routinely; outside them, they escalate.
Focus on products. The project defines what it will deliver, including quality expectations, before it plans the work to produce it.
Tailor to suit the project. The method is adapted to the project's context rather than applied mechanically.

The seven practices

The practices (called themes in earlier editions) are the aspects of project management that must be addressed continuously and in parallel across the whole project:

Practice	Question it answers	Typical management products
Business case	Why are we doing this, and is it still worth it?	Business case, benefits management approach
Organizing	Who is responsible for what?	Project management team structure, role descriptions, communication approach
Plans	How, how much and when?	Project plan, stage plans, team plans, product descriptions
Quality	What do we deliver, and how good must it be?	Project product description, quality management approach, quality register
Risk	What might happen, and what will we do about it?	Risk management approach, risk register
Issues	What has happened that we did not plan, and what do we do?	Issue management approach, issue register, issue reports
Progress	Where are we now, where will we end up, and should we carry on?	Highlight, checkpoint, end stage, exception and end project reports

Each practice is supported by an "approach" document agreed during initiation. The approach records how the project will handle that aspect: for example, which risk scales will be used, who can approve a change, and how often reports are sent. The seventh edition also adds a sustainability management approach and a digital and data management approach, plus guidance on commercial management (working with suppliers under contracts). These are included in the initiation documentation when relevant.

The seven processes

The processes describe the lifecycle from first request to closure. Each process groups activities and says which role is responsible for each, so that the right decisions happen at the right time.

Starting up a project – a short pre-project process that checks whether the project is worthwhile and viable before any serious commitment of resources. It appoints the executive and project manager, designs the team, captures previous lessons, and produces a project brief and a plan for the initiation stage.
Directing a project – runs from the end of start-up to closure and is the project board's process. It covers authorising initiation, authorising the project, authorising each stage or exception plan, giving ad hoc direction, and authorising closure.
Initiating a project – the first management stage. It establishes solid foundations: the management approaches, the project plan, the detailed business case and the project controls, all brought together in the PID.
Controlling a stage – the project manager's day-to-day process during a stage: authorising work packages, reviewing progress, capturing and handling issues and risks, reporting highlights to the board, and escalating exceptions.
Managing product delivery – the team manager's process. It controls the link between the project manager and the teams: accepting a work package, executing it, and delivering the finished products.
Managing a stage boundary – near the end of each stage (except the final one), the project manager reports on the stage, plans the next stage, updates the project plan and business case, and asks the board to authorise the next stage. The same process produces an exception plan when the board asks for one.
Closing a project – confirms acceptance of the project's products, reviews performance against the baselines, hands products over to operations, records follow-on actions and lessons, and recommends closure to the board.

Figure 2 – How the seven processes connect: the board directs throughout, the project manager runs each stage, teams deliver products, and each stage boundary returns to the board for a decision.

Notice in Figure 2 that there is always a decision point between management stages. A PRINCE2 project has at least two management stages: the initiation stage and at least one further stage. Larger projects have more. The number and length of stages depend on the project's risk and complexity, on natural decision points (for example a tender award) and on how far ahead it is sensible to plan in detail.

The project management team

The organizing practice defines a team structure with four levels. The business layer (corporate, programme or customer management) commissions the project, sets project tolerances and appoints the executive. The directing level is the project board. The managing level is the project manager. The delivering level is the team managers and their teams.

Figure 3 – The PRINCE2 project management team: the business layer sets direction, the board directs, the project manager manages day to day, and teams deliver.

The project board balances three interests. The executive represents the business and makes sure the project gives value for money. The senior user (one or more people) specifies what the users need, commits user resources, and later shows that the expected benefits are realised. The senior supplier represents those who design, build and implement the products and commits their resources. The board is not a democracy: the executive takes the final decision, advised by the other two.

Three further roles support the structure. Project assurance checks, on behalf of the board members, that the project is being run properly and that business, user and supplier interests are being protected. It must be independent of the project manager, so it cannot be delegated to them. A change authority is a person or group to whom the board delegates authority to approve some requests for change, usually within a change budget. Project support provides administrative help, such as maintaining registers, version control and planning tools. It is often provided by a project or programme office, and it is kept separate from assurance.

Roles are not jobs. One person can hold several roles (on a small project the executive may also be the senior user), and one role can be shared by several people (several senior users from different departments). The rule is that no conflicts of interest are created. For example, the executive role is never shared, and the project manager never acts as their own assurance.

Lesson 4 – How it works in practice

From mandate to initiation

Every project starts with a trigger from the business layer, called the project mandate. It may be a single email or a detailed request. Starting up a project turns it into something the board can judge. The executive and project manager are appointed, the rest of the team is designed, and lessons from similar projects are gathered. An outline business case and a project product description (what the final product must be, and what the customer's quality expectations and acceptance criteria are) are prepared. These become the project brief. The approach to delivering the project is chosen, for example building in-house, buying a package or using an agile supplier. The project manager also plans the initiation stage.

The board then decides whether to authorise initiation. This is the first formal investment decision, and it is small: the organisation is only paying to plan the project properly.

During initiation the project manager and team agree the management approaches for risk, quality, issues and communication, and the benefits management approach. They set up the project controls (stages, tolerances, reporting), build the project plan, refine the business case into a detailed one, and assemble the PID. When the board authorises the project, the PID becomes the baseline. The board can then also authorise the first delivery stage.

Product-based planning

Because the method focuses on products, plans start with what must be delivered rather than with a list of tasks. A typical sequence is:

write the project product description, describing the final product and the quality the customer expects;
break it into a hierarchy of products (a product breakdown structure), separating products the project creates from those it receives from outside;
write product descriptions for the important products, giving purpose, composition, quality criteria and quality methods;
draw a product flow diagram showing the order in which products are created and their dependencies;
only then identify activities, estimate effort, schedule, add resources and analyse the risks to the plan.

PRINCE2 has several levels of plan. The project plan covers the whole project and is used by the board. A stage plan covers one management stage in detail and is used by the project manager day to day. Optional team plans are produced by team managers for their work packages. An exception plan replaces a project or stage plan when that plan has gone outside tolerance and the board wants to see a recovery or revised course.

Running a stage

Inside a stage, the project manager authorises work through work packages. Each package says which products are to be built, the techniques and standards to use, tolerances for the team, reporting arrangements, and how the finished products will be approved. The team manager accepts the package, plans it if needed, does the work, tests the products against their quality criteria, records results in the quality register, and sends regular checkpoint reports to the project manager.

The project manager reviews progress, keeps the stage plan up to date, and sends highlight reports to the board at the agreed frequency. Each report summarises progress, forecasts, issues and risks. The board does not need to meet to receive these reports. It holds formal decision meetings at stage boundaries and when an exception occurs.

Tolerances and management by exception

Tolerances are the engine of the "manage by exception" principle. They are set for each performance target that matters: time, cost, quality, scope, benefits, risk and, since the seventh edition, sustainability. They cascade down the structure:

the business layer sets project tolerances and the board must stay within them;
the board sets stage tolerances for the project manager;
the project manager sets work package tolerances for each team manager.

Figure 4 – Management by exception: a forecast breach of tolerance is escalated to the level that set it, which decides how to respond.

As Figure 4 shows, the key word is forecast. An exception is raised when a plan is expected to exceed tolerance, not after the money is spent. The project manager uses an exception report to explain the cause, the consequences and the options, with a recommendation. The board may adjust tolerances, give direction, ask for an exception plan, or close the project early. The same logic applies one level up: if the project tolerance is threatened, the board refers the matter to the business layer, because only that level can change it.

Handling risks, issues and change

Risks are identified, assessed for probability, impact and proximity, given responses and owners, and recorded in the risk register. Each risk has a named owner who is responsible for keeping it under control. Responses differ for threats (for example avoiding or reducing them) and opportunities (for example exploiting or enhancing them).

Issues are captured and examined. Informal ones can simply be noted by the project manager and resolved directly. Formal ones go on the issue register, often with a separate issue report. Requests for change and off-specifications are decided by the board or the change authority, depending on their size and the change budget. Problems and concerns that the project manager can resolve within tolerance are handled directly. The important habit is that nothing changes a baselined product without passing through the agreed issue procedure.

Closing the project

A project closes when its products are accepted, or earlier if the board decides to stop it. Closing a project confirms that acceptance, hands products to operations, records follow-on action recommendations, writes an end project report and a lessons report, updates the benefits management approach so that benefits are measured after the project, and asks the board to authorise closure. Closure releases the resources, and the business layer then receives the benefits.

Tailoring and the people element

Tailoring is where PRINCE2 succeeds or fails. A two-month internal project might combine the initiation documents into one short document, merge roles, use a single register for risks, issues and lessons, and report verbally. A multi-year infrastructure programme project might have many stages, formal assurance and a full set of approaches. Tailoring never removes a principle. A tiny project still has a justification, still has someone accountable, still has at least one decision point and still knows its limits.

The people element reminds the team that processes alone do not deliver. It covers leadership styles, building and running teams, communication, collaboration with suppliers, and helping the people affected by the project accept and use what it delivers. In practice this means planning stakeholder engagement and business change activities as products in their own right, not as afterthoughts.

PRINCE2 with agile delivery

PRINCE2 governs a project; agile methods such as Scrum organise delivery work. They fit together well. The board and stages provide governance and investment decisions, while teams deliver in short iterations inside work packages. Tolerances are often set so that time and cost are fixed and scope (the features delivered) is the flexible element. PeopleCert publishes separate guidance and a certification called PRINCE2 Agile for this combination.

Lesson 5 – Assessment, certification and compliance

Individual certification

PRINCE2 certification is for individuals. PeopleCert, the owner of the method, sets and administers the examinations, either through accredited training organisations or through online proctored exams. As of the verification date, the Version 7 scheme has two main levels:

Level	Aim	Format (per PeopleCert, verified 2026-10-29)
PRINCE2 Project Management Foundation	Shows that you know and understand the method well enough to work in a PRINCE2 project team	60 multiple-choice questions, 60 minutes, closed book, pass mark 60 %
PRINCE2 Project Management Practitioner	Shows that you can apply and tailor the method to a scenario	Objective testing, 56 questions and sub-questions worth 70 marks, 150 minutes, open book, pass mark 60 %

To sit the Practitioner exam you need a qualifying certification. Accepted examples include PRINCE2 Foundation (Version 7, or an earlier PRINCE2 Foundation or Practitioner) and recognised project management credentials such as PMP, CAPM and IPMA levels A to D. PeopleCert's current pages describe Version 7 certificates as subject to renewal (a three-year cycle is stated for Foundation). Holders can renew by collecting continuing professional development points through PeopleCert's membership scheme or by passing another exam in the same product suite. Always check the exam page before you book, because formats and rules can change.

Related certifications include PRINCE2 Agile (Foundation and Practitioner) and, for programmes, MSP.

What certification does and does not prove

A Foundation certificate shows that you know the vocabulary and structure. A Practitioner certificate shows that you can apply the method to a written scenario under exam conditions. Neither proves that you can lead a difficult project, handle stakeholders, or tailor the method wisely in a real organisation; those come from experience. Employers and clients often list PRINCE2 as a requirement for roles in the UK, Europe, Australia and parts of Africa and Asia, so it is useful as a shared language. It does not replace judgement.

Organisations and compliance

There is no PRINCE2 certification for an organisation or for a project. An organisation cannot be "PRINCE2 certified". It can, however, adopt PRINCE2 as its standard method, write a tailored version into its project management framework, train its staff, and check through assurance and audits that projects follow it. If an organisation wants an independent view of how mature its project, programme and portfolio management is, the related model P3M3 offers formal assessments by accredited consulting partners.

In practice, compliance with PRINCE2 is checked by:

Project assurance – the board's own independent checks during the project, for example that quality reviews actually happen and that the business case is updated at each stage boundary.
Quality assurance – a check by people outside the project (often a PMO or internal audit) that the project follows the organisation's standards. It is different from project assurance, which serves the board.
Stage gate or gateway reviews – many organisations, especially in the public sector, hold independent reviews at key decision points, which line up naturally with PRINCE2 stage boundaries.
Contract terms – some clients require suppliers to manage projects using PRINCE2, with named roles and specified reports.

A good test of real compliance is to ask for evidence of the principles rather than templates. Ask when the business case was last reviewed and by whom, whether the stage tolerances are written down, which lessons from earlier projects changed this project's plan, and whether the board actually took a go or no-go decision at the last stage boundary.

Lesson 6 – Worked example

Northvale Logistics is a fictional regional distribution company with three warehouses and about 600 staff. Its warehouse management system is out of support, and picking errors are rising. The operations director asks the IT department to replace the system before the next peak season. Here is how a sensible PRINCE2 project would run.

Step 1 – Mandate and start-up

The executive committee (the business layer) issues a one-page mandate: replace the system within 12 months, budget about 1.2 million, reduce picking errors. It appoints the finance director as executive and an experienced internal project manager. During start-up the project manager reviews the lessons report from a failed transport-planning project two years earlier. Its main lesson was that warehouse supervisors had not been involved in testing. The project manager therefore designs the board with the head of warehouse operations as senior user and the IT director as senior supplier. Because the system will be bought from a vendor, the vendor's account director also joins as a second senior supplier. The project brief includes an outline business case comparing three options: do nothing, upgrade the existing system, or replace it with a cloud package. Replacement is preferred because the upgrade only delays the problem.

Step 2 – Initiation

The board authorises initiation, a four-week stage. The project manager agrees the management approaches. The risk approach uses a five-point scale. The issue approach gives a change authority (the head of warehouse operations plus the IT architect) a change budget of 40,000 for small requests. The quality approach requires supervisors to take part in user acceptance testing, applying the earlier lesson. A new sustainability target is set because the company has an emissions commitment: the new system must support route consolidation, and old hardware must be recycled through a certified provider.

The project product description defines the final product as a live system in all three warehouses, with trained staff, migrated stock data and working interfaces to the finance and transport systems. Acceptance criteria include picking accuracy above an agreed level after two months of live use. Product-based planning produces a breakdown structure and flow. Configuration, data migration, interfaces, training materials and three warehouse go-lives are the main products.

The project plan sets four further stages: design and configuration, build and test, pilot at the smallest warehouse, and roll-out to the other two. The stage boundaries match real decisions. After design, does the package fit well enough? After testing, is it good enough to pilot? After the pilot, are the benefits visible enough to roll out? The board approves the PID with project tolerances from the business layer of plus or minus one month and plus ten per cent cost. It sets stage tolerances of two weeks and five per cent.

Step 3 – Controlling stages

In the build and test stage the project manager issues work packages to the vendor team (configuration and interfaces) and to an internal team (data migration and training). The vendor works in two-week sprints. Its work package fixes the sprint cadence and stage end date but lets the vendor and senior user re-order features within the package. Checkpoint reports arrive weekly, and the project manager sends a fortnightly highlight report to the board.

Halfway through the stage the data team finds that a third of product records have inconsistent units of measure. Cleaning them will add three weeks, which breaches the stage time tolerance. The project manager does not wait. She captures the issue, assesses options (clean all data now, clean only active products, or delay the pilot) and sends an exception report recommending cleaning active products only. That option fits within the project tolerance. The executive calls a short board meeting. The senior user confirms that inactive products can be cleaned after go-live, and the board asks for an exception plan. Managing a stage boundary produces the revised stage plan, an updated project plan and a refreshed business case. The board approves it, and work continues.

Step 4 – Pilot, roll-out and benefits

At the end of the pilot, the end stage report shows that picking errors fell sharply in the pilot warehouse, but staff found the handheld scanners slow. The board authorises the roll-out stage on condition that a scanner configuration fix is included, and the change authority approves it within its budget. Roll-out completes three weeks late, within project tolerance.

Step 5 – Closure

Closing a project confirms acceptance by the senior user and hands support to the IT service desk. Follow-on actions are recorded: clean inactive product data, and review scanner models at the next hardware refresh. An end project report compares performance with the PID baselines. A lessons report records that early data profiling should be a standard initiation activity. The benefits management approach schedules measurements of picking accuracy and emissions at three and twelve months, owned by the senior user. The board authorises closure, and the team is released.

What the example shows

Every principle was visible: the business case was checked at each boundary, an old lesson changed the design, roles balanced business, user and supplier, stages matched real decisions, the data problem was escalated as a forecast exception, products were defined before work started, and the method was tailored to include agile sprints.
The board spent little time on routine matters and acted quickly when tolerance was threatened.
Benefits did not end at closure: someone outside the project was made responsible for measuring them.

Lesson 7 – Relationship to other standards and frameworks

PRINCE2 is one of several bodies of project and change management guidance. Knowing the differences helps you combine them instead of arguing about which is "right".

Framework	Owner	What it is	Relationship to PRINCE2
PMBOK Guide and PMI standards	Project Management Institute	A body of knowledge and standard describing principles, performance domains and a wide range of tools and techniques	Broader and less prescriptive about roles and process flow; PRINCE2 provides a specific method that can use PMBOK techniques. Many professionals hold both PMP and PRINCE2.
ISO 21502	ISO	International guidance standard on project management concepts and practices	Describes what good project management covers at a general level; PRINCE2 is one way of putting such guidance into practice.
PRINCE2 Agile	PeopleCert	Guidance on combining PRINCE2 governance with agile delivery	Builds directly on PRINCE2, adding agile behaviours, focus areas and how to tailor tolerances for flexible scope.
Scrum	Scrum Guide authors	A lightweight framework for delivering products in short iterations	Works at the delivery level inside PRINCE2 work packages; Scrum does not cover business justification or board-level governance.
MSP	PeopleCert	Method for managing programmes of related projects to achieve outcomes and benefits	Sits above PRINCE2: a programme often acts as the business layer for several PRINCE2 projects.
P3M3	PeopleCert	Maturity model for portfolio, programme and project management	Assesses how capable the whole organisation is; PRINCE2 is a method a project uses. Adopting PRINCE2 can support higher maturity but does not guarantee it.

In the UK public sector, PRINCE2 also sits beside the government's Project Delivery Functional Standard, which sets expectations for how government projects and programmes are directed and managed. The standard does not mandate any single method, and PRINCE2 is a common way of meeting its expectations at project level.

A good rule of thumb: use a body of knowledge or ISO guidance to understand the full scope of project management, PRINCE2 to give a project clear governance and control, agile frameworks to organise delivery teams, MSP and portfolio guidance above the project, and a maturity model such as P3M3 to measure and improve the organisation's capability.

Common pitfalls and best practices

Common pitfalls:

Template-driven PRINCE2. Producing every management product in full for a small project creates paperwork without control. Teams then work around the method, and it falls out of use.
A business case written once. The business case is used to win approval and then never opened again, so nobody notices when costs rise or benefits shrink.
A board that does not direct. Members delegate attendance to junior staff, avoid decisions at stage boundaries, or interfere in day-to-day work instead of setting tolerances and trusting the project manager.
Missing tolerances. Without written tolerances, "manage by exception" becomes "escalate everything" or "escalate nothing".
Stages without decisions. Stages are drawn as arbitrary time boxes, so stage boundaries become status meetings rather than real go or no-go points.
Lessons logged but not used. Lessons reports are filed at closure, and nobody reads them when the next project starts.
Weak user involvement. The senior user role is held by someone without authority over the people who will use the products, so acceptance and benefits suffer.

Best practices:

Tailor deliberately and record it. Write a short statement in the PID of what is being tailored and why, so assurance and auditors can judge the choices.
Align stages with real decisions, such as contract awards, design approval, pilot results or regulatory approvals.
Set tolerances for every performance target that matters, including benefits and sustainability, and cascade them clearly to work packages.
Review the business case at every stage boundary and be willing to recommend stopping the project if it is no longer justified.
Start every project by reading lessons from similar projects, and change the plan visibly because of them.
Write product descriptions with measurable quality criteria and involve the people who will use the products in quality checks.
Keep assurance independent of the project manager, and give it access to the board.
Plan the people side: stakeholder engagement, communication and business change activities appear in plans as products with owners.

Summary and key takeaways

PRINCE2 is a generic, process-based method for managing a single project. PRINCE2 7 (2023) from PeopleCert is the current edition.
It consists of five integrated elements: principles, people, practices, processes and project context.
The seven principles must always be applied; everything else can and should be tailored.
The seven practices (business case, organizing, plans, quality, risk, issues, progress) are managed throughout the project.
The seven processes take a project from mandate through start-up, initiation, controlled stages and closure, with the board directing at every decision point.
Tolerances cascade from the business layer to the board, the project manager and team managers, and forecast breaches are escalated to the level that set them.
Certification (Foundation, Practitioner) applies to individuals; there is no organisational PRINCE2 certificate.
PRINCE2 works alongside agile delivery, MSP, P3M3, the PMBOK Guide and ISO 21502 rather than replacing them.

Reflection questions

Think of a project you know that ran into trouble. Which PRINCE2 principle was weakest, and what early sign could a board have spotted?
For a six-week internal project, which management products would you combine or drop, and how would you still show that every principle was applied?
Choose a current project and propose sensible stage boundaries. What decision would the board take at each one?
Who in your organisation would be the right senior user for a new HR system, and what authority would they need to make the role effective?
How would you set tolerances for a project delivered by an agile supplier, and which performance target would you leave most flexible?