PRINCE2

What PRINCE2 is for

PRINCE2 is often compared with Scrum, and the comparison confuses almost everyone the first time. That is because the two are not alternatives. They answer completely different questions.

Scrum describes how a team turns a list of work into working software. PRINCE2 describes how an organisation decides to start a project at all, keeps checking whether it should carry on, and stops it when the answer changes. One is about building. The other is about deciding and funding.

The name is an acronym: PRojects IN Controlled Environments. It came out of the UK government in 1989 and is now widely used across Europe, particularly in the public sector and in regulated industries where a supplier must demonstrate control to win a contract.

A terminology change worth knowing

Before we go through the elements, one practical warning. PRINCE2 was updated in 2023, and the seventh edition renamed one of its three groups. What used to be called the seven themes are now called the seven practices.

The substance is largely the same, but most training material, blog posts and job descriptions online still say "themes". If you meet that word, it refers to what this page calls practices. Knowing both terms saves confusion in an interview.

The seven principles

The principles are the non-negotiable part. A project can drop paperwork, simplify processes and skip roles, and still be PRINCE2 — but if it violates a principle, it is not PRINCE2 any more, whatever the documentation says. Here is each one, and what it actually asks of you.

• 1. Continued business justification

  There must be a documented reason for the project, and it must still hold at every checkpoint. Not written once for budget approval — reviewed repeatedly. If the reason disappears, the project stops.

• 2. Learn from experience

  Lessons are looked up at the start, recorded during, and passed on at the end. The method makes this an explicit duty because organisations reliably forget otherwise.

• 3. Defined roles and responsibilities

  Everyone knows who decides what. Three interests must always be represented: the business paying, the users who will use it, and the suppliers building it.

• 4. Manage by stages

  The project is split into stages, and the board authorises only one at a time. You plan the next stage in detail and the rest of the project roughly — a hedge against planning what you do not yet understand.

• 5. Manage by exception

  The board agrees limits — for time, cost, scope, risk, quality and benefit — and then leaves the manager alone inside them. Escalation happens only when a forecast breaks a limit.

• 6. Focus on products

  Agree what will be delivered and to what quality before discussing how long it takes. A project defined by activities has no way to check whether it is finished.

• 7. Tailor to suit the project

  Scale the method to the size and risk of the work. Applying the full apparatus to a small project is the most common way PRINCE2 gets a bad name.

The seven practices (formerly themes)

If the principles are what you must believe, the practices are what you must keep an eye on throughout. Each one is an aspect of the project that has to be managed continuously rather than dealt with once. Here is each one and the question it keeps asking.

Two of these are worth a closer look, because the distinction between them is where teams usually get muddled.

The seven processes

The processes are the timeline: what actually happens, in what order, and who is doing it. Read them in sequence and you have the whole life of a PRINCE2 project from the first idea to the final report.

Notice two things about this list. First, processes 4, 5 and 6 repeat for every stage — they are the loop the project runs in. Second, "Closing a Project" is used both when the project succeeds and when it is stopped early. PRINCE2 treats cancellation as a proper ending with a proper process, not as an embarrassing exit.

Who sits on the board

Principle 3 said three interests must always be represented. Here they are, and the reason the split matters is that these three interests genuinely conflict — the business wants it cheap, the users want it good, the suppliers want it feasible. Naming them separately stops one of them quietly winning by default.

• Executive — the business

  Owns the business case and the money, and has the final say. Always one person: PRINCE2 is explicit that a board cannot own a decision jointly.

• Senior User

  Represents the people who will use the result, and is accountable for the benefits actually being realised after delivery.

• Senior Supplier

  Represents those building it, and is accountable for the solution being technically viable and properly resourced.

PRINCE2 next to Scrum

Read the two columns together and it becomes obvious that neither replaces the other. That is exactly why the combination is common, and why the official PRINCE2 Agile variant exists to formalise it.

How this shows up in real delivery

For an engineering team, PRINCE2 mostly shows up as stage boundaries: predictable moments when funding is re-examined and evidence is expected. Teams that fare well treat those as genuine reviews and bring outcome numbers to them. Teams that fare badly bring a percentage-complete figure, which answers a question nobody at the board actually asked.

Where it degrades

• A business case written once for approval and never reviewed — principle 1 simply absent while the paperwork claims otherwise.
• The full documentation set applied to a small project, where governance costs more than the risk it manages.
• No tolerances agreed, so management by exception quietly becomes management by interruption.
• A board that meets but has never actually stopped anything, which makes every stage gate ceremonial.
• Issues logged as risks, so a problem that has already happened waits for someone to reclassify it.

When to use it

Related pages

• ManagementPMBOKPMBOK is PMI's body of knowledge for project management — and, since the 7th edition, a fundamentally different document from the one most people were taught. It stopped prescribing 49 processes and now describes 12 principles and 8 performance domains, which makes it a way of thinking rather than a procedure to follow. This page covers all twelve principles, all eight domains, the older structure you are probably carrying, and how it differs from PRINCE2.
• ManagementWaterfallWaterfall is a way of running a project in strict order: finish and sign off each phase before the next begins. Waterfall is usually taught as the outdated thing Agile replaced, which is both unfair and unhelpful. It is the right choice whenever changing your mind later costs more than specifying carefully now — and that is more often than its reputation suggests.
• ManagementScrumScrum is the most widely used way of organising a software team. Scrum breaks work into short, fixed cycles called sprints, gives three people clear areas of responsibility, and puts a small set of regular meetings around the work so problems surface within days instead of months. This page walks through every one of those meetings — including several that real teams hold but the official guide never mentions.