2.2 Core Workflows and Decision Points

Principle 1 — Ensure continued business justification

This principle requires a documented, justifiable reason to start the project, and that reason must remain valid throughout. The word continued is the exam's favourite trigger: justification is not a one-time gate at the start; it is reassessed at every stage boundary and whenever an exception occurs.

The mechanism is the business case, the most important management product. It records the costs, the expected benefits, the risks, the timescale, and the balance between them. PRINCE2 distinguishes that a project should be both viable (worth doing) and desirable (the benefits justify the costs and risks). If the balance no longer holds — costs balloon, benefits evaporate, or risk becomes unacceptable — the correct PRINCE2 response is to stop the project, even mid-flight. A project that is killed because its business case collapsed has succeeded in applying this principle, not failed.

The business case lifecycle maps onto the processes:

• Starting Up a Project — an outline business case is created.
• Initiating a Project — the detailed business case is developed.
• Each stage boundary — the business case is reviewed and updated.
• Closing a Project — the business case confirms benefits and hands the benefits-management approach to corporate/programme.

Exam trap: "continued" justification means it can be withdrawn. If a stem describes a project that has lost its justification but is allowed to continue "because work has already started" (sunk-cost reasoning), that violates the principle.

Principle 2 — Learn from experience

PRINCE2 teams learn from experience: they look for lessons at the start, record them as the project runs, and pass them on at the end. The point is to avoid reinventing wheels and repeating mistakes.

The mechanism is the lessons log (a record opened in startup) and lessons reports (compiled at stage boundaries and closure). Learning flows in three directions:

• Seek lessons from previous and concurrent projects when starting up.
• Capture lessons continuously as the project proceeds.
• Pass on lessons to future projects and the wider organization at closure.

Everyone is responsible for proactively seeking lessons — it is not a passive activity that happens only at the end.

Principle 3 — Define roles, responsibilities, and relationships

PRINCE2 7 expanded this principle to include relationships — not just who does what, but how the parties interact. A PRINCE2 project has people from the business, the user, and the supplier interests, and they need clearly defined accountability.

This principle gives PRINCE2 its four levels of organization:

The three project-board interests are the business (executive — represents value for money), the user (senior user — will use the products), and the supplier (senior supplier — provides resources/expertise).

Principle 4 — Manage by stages

A PRINCE2 project is planned, monitored, and controlled stage by stage. Stages are separated by decision points (also called control points or stage boundaries) where the project board reviews progress and the business case, then decides whether to authorize the next stage — a genuine go/no-go gate.

The most-tested fact: a PRINCE2 project has a minimum of two management stages:

1. The initiation stage — where the Project Initiation Documentation (PID) is created. Initiation is always a stage on its own.
2. At least one further (delivery) stage — where the specialist products are built and approved.

More stages are used for larger or riskier projects; the number of stages is a tailoring decision based on planning horizon, risk, and confidence. Do not confuse a management stage (a board decision/commitment boundary) with a technical stage (a phase of specialist work such as design or build) — they can overlap but are different concepts, and PRINCE2 controls by management stages.

How these four principles interlock

At each stage boundary the board does three things at once: it confirms the business case still justifies the project (principle 1), reviews lessons captured so far (principle 2), and uses the defined roles (principle 3) to make a controlled stage decision (principle 4).

The decision points in detail

A decision point is where the project board exercises control. PRINCE2 keeps the board out of day-to-day work and brings it in at defined moments, all within the Directing a Project process. The key board authorizations are:

Notice that every board decision re-tests the business case — the link between manage by stages (the timing of the decision) and ensure continued business justification (the basis for it). A Foundation question may describe a stage boundary and ask which principle drives the go/no-go check: the timing is manage by stages, but the reason the board can say "no" is continued business justification.

Roles at each decision point

The project manager prepares the information (end-stage report, next-stage plan, updated business case) but does not authorize the next stage — that is the board's accountability under define roles, responsibilities, and relationships. A project manager who "approves their own next stage" has broken the role boundaries the method depends on.