The principles in different contexts

Because the principles are universal, they apply in every setting. But how they are applied changes with the context. This lesson looks at five common contexts: agile delivery, small projects, the public sector, projects inside a larger program of change, and commercial customer-supplier relationships. For each, it asks what the principles look like in practice and where the usual pitfalls lie.

Agile delivery

In agile delivery, teams work in short timeboxes, deliver usable increments frequently and adjust priorities as they learn. Some people assume that agile and PRINCE2 are opposites. They are not. PRINCE2 governs the project: it decides whether the investment is justified, sets tolerances and defines roles at the direction and management levels. Agile methods such as Scrum or Kanban govern how specialist teams deliver. PRINCE2 Agile, updated in 2025, gives detailed guidance on combining them.

The common pitfall is to let agile ceremonies replace governance. A team can hold perfect sprint reviews while nobody checks whether the overall investment is still justified. The opposite pitfall is to impose heavy documents on an agile team, which slows delivery without improving control. The principles help find the middle: justification, stages and tolerances at the top; agile practices in delivery.

Small projects

Small projects are where the temptation to drop principles is strongest. With a small team, a modest budget and a few months to deliver, writing a business case or holding a stage boundary can feel like bureaucracy. Lesson 8 showed how heavy tailoring keeps the principles in a light form. The key is that each principle survives as a question someone answers, even if the answer is a short email.

The public sector

Public-sector projects spend public money, face scrutiny from auditors and legislators, and often operate under statutory deadlines. Governments typically have their own investment and gating frameworks, which a PRINCE2 project must fit inside.

In the US, federal agencies work under OMB guidance such as Circular A-11 for capital planning and Circular A-130 for information resources, and under the Program Management Improvement Accountability Act of 2016, which strengthened program and project management standards and created senior program management roles. The Federal Acquisition Certification for Program and Project Managers sets competency levels. States and cities have their own capital planning and procurement rules. A PRINCE2 project in this setting tailors its stage boundaries to match budget and acquisition milestones, uses the agency's business case formats and records how its tolerances relate to the authorities granted.

The principles are particularly valuable in the public sector because they create an audit trail of decisions. When an auditor asks why a project continued after costs rose, a board that reviewed an updated business case at each stage boundary, with minutes, can answer. A board that did not cannot. Public inquiries into failed projects repeatedly find missing or ignored decision points, unclear accountability and business cases that were never updated.

Projects within a program

Many projects are part of a larger program of related projects and activities that together deliver a strategic change. In that setting, some responsibilities shift. The program usually sets the project's tolerances, owns some of the benefits and may provide shared assurance and support. The project's business case may be a section of the program business case. Benefits are often realized at program level, after several projects deliver.

• Continued business justification: the project shows its contribution to program benefits, and the program may stop or reshape it.
• Defined roles: the project executive may be a program-level role such as a business change manager.
• Manage by exception: project tolerances come from the program, and project exceptions escalate to the program board.
• Learn from experience: lessons flow both ways between program and project.

The pitfall is duplication: a project producing its own full business case, risk management approach and reports that repeat the program's. Tailoring should make clear what the project inherits from the program and what it does itself.

Commercial customer-supplier relationships

When the supplier is an external company, there are two organizations, two sets of management and two commercial interests. PRINCE2 assumes a customer-supplier environment. The customer's project is governed by the customer's board; the supplier may run its own project, using its own method, to deliver what the contract requires.

• Continued business justification: the customer and supplier each have their own business case. The supplier's case is about profit and reputation; the customer's is about benefits. The two can conflict, especially when changes are priced.
• Defined roles and relationships: the contract, the senior supplier role and the work packages define who decides what. Good relationships matter even more, because each side can see only part of the picture.
• Manage by exception: work package tolerances must be consistent with contract terms. A tolerance in the work package that contradicts the contract invites dispute.
• Focus on products: product descriptions and acceptance criteria often become contract schedules. Vague criteria are a frequent cause of disputes.

Hybrid projects

Many projects mix predictive and agile work. A new transit station might have predictive construction work, with fixed designs and contracts, alongside an agile team building the passenger information app. PRINCE2 handles this naturally: management stages and tolerances apply to the whole project, while each work package can use the delivery approach that suits it. The construction work package may have tight scope tolerance and looser time tolerance; the app work package may have fixed time and cost with flexible scope. The project manager integrates the two through the stage plan and highlight reports.

Projects in very small organizations

In a small business or charity, one person may be the whole board and another the whole team. The principles still apply, but in a very compressed form. The owner acting as executive should still write down why the project is worthwhile and check it before each major spend. They should still ask someone with relevant experience what went wrong last time. Even if one person holds several roles, it helps to name whose interest each decision serves: the business, the users or the supplier. Stage boundaries may be a single conversation; tolerances may be a simple rule such as "tell me if we will be more than a week late or 10 % over". The method shrinks, but the questions remain.

Regulated and safety-critical projects

In regulated sectors such as health care, energy, aviation or rail, the principles interact with external rules. Quality criteria may be set partly by regulators. Stage boundaries may coincide with regulatory approvals, and a project may not proceed until a safety case or license is accepted. Tolerances on quality and risk may be very tight or zero. Tailoring in these contexts tends to add formality: more assurance, more detailed product descriptions and stronger configuration management. The principles help by making the decision points and authorities explicit, which regulators often expect to see.

Whatever the context, the test is the same. For each principle, ask what it would look like here, who is responsible for it and what evidence would show it is being applied. If you can answer those three questions for all seven, the project is applying PRINCE2, however unusual its setting.

A useful habit for any context is to write a one-line statement for each principle at initiation, describing how it will be applied on this project, and to revisit those seven lines at each stage boundary. The statements become a compact charter for the project's governance and a quick reference for new team members and assurance reviewers.