PRINCE2

How PRINCE2 Works

PRINCE2 was developed by the UK government’s Central Computer and Telecommunications Agency (CCTA) in 1989, building on earlier methods for managing IT projects in the public sector. It was updated significantly in 1996, 2009, 2017, and most recently in 2023 under PeopleCert, which now owns the PRINCE2 certification program.

The defining characteristic of PRINCE2 is its focus on governance rather than execution. Where Scrum tells you how to run a sprint and Waterfall tells you what phases to execute in order, PRINCE2 tells you who has authority over which decisions, what must be documented before work proceeds, and how to maintain business justification throughout the project. The framework can be layered on top of almost any delivery approach, including Agile: PRINCE2 Agile is a variant that explicitly combines PRINCE2 governance with Agile delivery methods.

The Seven PRINCE2 Principles

The principles are the non-negotiable rules of PRINCE2. Any project claiming to use PRINCE2 must apply all seven. They are philosophical commitments rather than processes.

Continued business justification requires that the project maintain a viable, documented reason to proceed throughout its life. The business case is not written at the start and filed away. It is reviewed at every stage boundary, and if the project can no longer justify its costs and risks, it is stopped.

Learn from experience requires that lessons from previous projects be captured and applied. Each PRINCE2 project creates a lessons log and a lessons report so that the organization improves its project management capability over time.

Defined roles and responsibilities requires that every person involved in the project knows what they are responsible for. PRINCE2 defines a specific set of roles: the Project Board (executive, senior user, senior supplier), the Project Manager, and the Project Team. No project should proceed with ambiguous authority.

Manage by stages requires that the project be divided into management stages, with the Project Board authorizing each stage only after reviewing the previous stage’s performance. The Project Board maintains control by deciding whether to proceed, change, or stop at each stage boundary.

Manage by exception gives the Project Manager authority to manage within agreed tolerances on time, cost, quality, scope, risk, and benefits, without referring upward. When a forecast shows those tolerances will be breached, the issue escalates to the Project Board. This prevents the Board from being burdened with daily decisions while maintaining clear accountability.

Focus on products requires that PRINCE2 projects define what will be produced (the products) before defining how the work will be done. Product descriptions define the quality criteria each deliverable must meet, which prevents scope ambiguity during delivery.

Tailor to suit the project requires that the PRINCE2 framework be adapted to the size, complexity, and risk of each project. A small internal project does not need the same documentation overhead as a large government program. The principles and themes remain; the processes and documents are scaled appropriately.

The Seven Themes

PRINCE2’s seven themes are the aspects of project management that must be addressed continuously throughout the project. They are not phases: they run in parallel from start to finish.

The Business Case theme ensures the project justification is developed, maintained, and verified throughout delivery. The Organization theme defines and maintains the project’s governance structure and roles. The Quality theme establishes what quality means for each deliverable and how it will be measured. The Plans theme covers the development and maintenance of project, stage, and team plans at appropriate levels of detail. The Risk theme identifies, assesses, and manages threats and opportunities. The Change theme controls how issues and changes to scope are assessed and approved. The Progress theme monitors and reports on actual performance against the plan, enabling management by exception.

The Seven Processes

PRINCE2’s seven processes define the activities that occur during the project lifecycle, who performs them, and what products they produce. Each process has a set of recommended management products (documents) associated with it.

Starting Up a Project covers the pre-project work: confirming the project mandate, assembling the Project Management Team, and producing the Project Brief. Directing a Project covers the Project Board’s ongoing governance through all stages. Initiating a Project establishes the project’s foundational documents: the Project Initiation Documentation (PID), which includes the project plan, business case, risk register, and quality management approach. Controlling a Stage covers the day-to-day management of work within a stage. Managing Product Delivery covers the interface between the Project Manager and the teams doing the work. Managing a Stage Boundary covers the review and decision at the end of each stage before authorizing the next. Closing a Project covers the formal end of the project, including product handover, lessons report, and benefits review plan.

Stage-Based Delivery and the Business Case

The stage gate model is PRINCE2’s most distinctive structural feature and the source of both its strength and its overhead. At the end of each management stage, the Project Board reviews what was produced, assesses whether the business case still holds, decides whether the next stage should proceed, and authorizes the next stage plan. This creates explicit accountability checkpoints that prevent projects from continuing when conditions have changed enough to make them unviable.

In practice, the business case review is the most consequential discipline PRINCE2 introduces. Projects that started with a strong justification often continue past the point where that justification still applies, because stopping a project is organizationally difficult. PRINCE2’s requirement to re-examine the business case at every stage gate provides a legitimate mechanism for stopping a project that is no longer worth completing, which prevents the escalating commitment that characterizes many failed large-scale projects.

When to Use PRINCE2

PRINCE2 is the dominant project governance framework in the United Kingdom, Australian, and European public sectors. For organizations doing work with UK government departments, local authorities, or EU-funded programs, PRINCE2 is often a contractual requirement or at minimum an expected professional standard. The PRINCE2 Practitioner certification is roughly the UK equivalent of the PMP in terms of professional recognition within those contexts.

PRINCE2 is also appropriate for large, complex, multi-supplier projects where clear governance authority is essential: major infrastructure programs, large IT implementations, and regulated-industry projects where documented decisions and formal change control are compliance requirements. The framework’s explicit role definitions and stage gate structure are valuable precisely because they reduce ambiguity about who is authorized to make which decisions.

Smaller organizations and projects can use PRINCE2 effectively by tailoring the framework aggressively: using a simplified Project Brief instead of a full Project Initiation Document, combining the Project Board roles into a single sponsor, and reducing formal documentation to what genuinely serves the project rather than what the framework recommends at maximum rigor.

When PRINCE2 Is Too Heavy for the Job

PRINCE2’s documentation requirements, while scalable in theory, create real overhead in practice. A small, fast-moving internal project managed by one person does not benefit from a full set of PRINCE2 management products. The time spent on Project Initiation Documentation, risk registers, quality registers, and stage boundary reports can exceed the time spent on the actual work for smaller projects.

PRINCE2 also assumes a governance structure that many organizations do not have: a Project Board with a genuine executive who controls the budget, senior users who represent the business requirements, and senior suppliers who commit their resources. In flat organizations, startups, or small teams, these roles either do not exist or are all played by the same person, which reduces the framework’s governance value significantly.

For software product teams running Agile workflows, PRINCE2’s stage-based model conflicts with iterative delivery. PRINCE2 Agile addresses this explicitly by mapping PRINCE2 governance to Agile execution: the stage boundary reviews become sprint review checkpoints, and the business case review is built into the product roadmap cycle. Teams that want both Agile delivery and formal governance may find PRINCE2 Agile worth evaluating.