The Seven PRINCE2 2017 Principles: A Practical Handbook

Executive summary

What a principle means in the method

The source presents a principle as a fundamental truth that provides a foundation for behaviour. PRINCE2 2017 is therefore principle-based rather than purely prescriptive. This matters because projects differ greatly in size, complexity, industry and delivery method; fixed procedures would either be excessive for small work or insufficient for complex work. Principles provide a stable management logic that can survive those differences.

The material characterises the principles as universal because they apply to every project using the method, self-validating because they have been demonstrated in practice, and empowering because they help practitioners decide how to apply the method when the detailed situation is not identical to a textbook example.

1. Continued business justification

A project must have a justifiable reason to start, that justification must be recorded and approved, and it must remain valid throughout the project. The justification can evolve as forecasts and circumstances change, but if it disappears the project should be changed or stopped rather than continuing simply because money or effort has already been spent.

The source also stresses that mandatory work still requires justification. The decision may be constrained by law, policy or other obligation, but the selected solution should still represent value relative to alternatives and should still be assessed for cost, risk, benefits and dis-benefits.

2. Learn from experience

Projects operate under uncertainty, and one important source of risk is failing to use knowledge that already exists. The principle requires teams to seek relevant lessons when a project starts, continue capturing and applying lessons while work is under way, and pass useful lessons forward. Learning is therefore an active control rather than an end-of-project archive exercise.

A lesson becomes valuable only when it changes behaviour. Recording that a previous estimate was optimistic is not enough; the current project should adjust its estimating approach, assumptions, review points or contingency. Later process activities use the lessons log and lessons reports to embed this behaviour.

3. Defined roles and responsibilities

Project teams are often cross-functional and temporary. People may have operational line-management relationships that differ from their project responsibilities. The principle therefore requires an agreed project organisation that engages three interests: business, user and supplier. The business interest protects value and justification; the user interest protects the needs of those who will use the products and realise benefits; the supplier interest protects technical feasibility and delivery capability.

The key lesson is not simply to draw an organisation chart. Each management decision should have a clear owner, and the people expected to perform project duties must understand the authority and accountability attached to their roles.

4. Manage by stages

The project is divided into sequential management stages. The project board authorises one stage at a time rather than committing detailed authority for the entire delivery period on day one. The project manager prepares a detailed stage plan for the current stage while the project plan remains a higher-level view of the full project.

Stage boundaries create deliberate review points. They allow the project board to assess performance, risk, the updated business case and the plan for the next stage before committing further resources. The number and length of stages should reflect the need for control: greater uncertainty or major decision points may justify shorter stages, while stable work may allow longer ones.

5. Manage by exception

Senior management time is scarce. The method therefore delegates authority using tolerances around the six performance targets. The level receiving the delegation may manage freely inside the tolerance. It must escalate when forecasts indicate that tolerance will be exceeded. This creates a structured form of autonomy rather than either micromanagement or uncontrolled delegation.

Tolerance should not be confused with target. A target states the expected performance; tolerance defines the authorised variation around it. It is the tolerance that establishes the limit of delegated authority.

6. Focus on products

The source warns that project teams can become overly focused on activities, tools and schedules while losing sight of the products that justify the work. Product focus means defining what must be delivered and the quality requirements attached to it before building an activity schedule around it.

The Project Product Description defines the overall project product and its acceptance expectations. Product Descriptions define individual products and their quality criteria, methods and responsibilities. Once products are understood, the team can derive activities, resources, dependencies and schedule. This reverses the weak practice of listing activities first and hoping they collectively produce an acceptable result.

7. Tailor to suit the project

Tailoring means adapting the method to the situation in which it will be used. The source allows tailoring of processes, themes, roles, management products and terminology. It also warns that tailoring should add value. A small project may combine roles or management products, while a large or high-risk project may require greater formality, more detailed controls or specialised assurance.

Tailoring does not mean deleting the principles. Nor does it mean weakening management because the team dislikes documentation. The test is whether the adapted method remains appropriate to the project and helps people make reliable decisions with proportionate effort.

How the principles reinforce each other

The principles are strongest when applied together. Continued business justification gives the project a reason to exist. Product focus converts that reason into clearly defined outputs. Defined roles establish who owns the decisions needed to create those outputs. Managing by stages limits forward commitment and creates review points. Managing by exception delegates authority between those points. Learning from experience improves the quality of decisions. Tailoring ensures the whole system remains proportionate to context.

Principle-based review questions

• Is there a current, approved reason for continuing the project?
• What relevant lessons have been sought and what action has been taken because of them?
• Are business, user and supplier interests represented with clear accountability?
• Is the project divided into management stages that match the required control intensity?
• Are tolerances explicit enough that each management level knows its delegated authority?
• Are products and their quality requirements defined before activities are optimised?
• Has the method been tailored for the project rather than copied mechanically or stripped of useful control?

Testing whether the principles are really operating

A useful way to assess implementation is to look for observable evidence of each principle. Continued business justification should appear in decisions to start, continue, change or stop. Learning should change plans or controls, not merely populate a lessons log. Defined roles should make decision ownership clear. Management stages should create real authorisation points. Exception management should give each level freedom within tolerance and a clear escalation path. Product focus should be visible in Product Descriptions, Work Packages and acceptance criteria. Tailoring should be documented and intentional.

Weak projects often claim to use a principle while defeating its purpose. A project may have stage names but no Board decision at the boundary; it is then technically divided but not managed by stages. It may have tolerance figures but escalate every small decision upward; manage by exception is not really operating. It may create lessons at closure but never apply them during delivery; learning is retrospective rather than active.

When reviewing a project, therefore ask what behaviour each principle changes. The principles are criteria for a coherent management system. If one is missing, the effect usually appears elsewhere—for example weak product focus produces scope ambiguity, which generates changes, which consumes tolerance, which undermines the Business Case.

Practical verification checklist

• Confirm every one of the seven principles is visible in the project’s actual management approach.
• Keep the business justification current and stop or change the project if it ceases to be valid.
• Seek, record and apply lessons throughout the lifecycle rather than only at closure.
• Define roles around business, user and supplier interests and make decision rights explicit.
• Plan, monitor and authorise the project stage by stage.
• Set meaningful tolerances for delegated authority and escalate forecast exceptions promptly.
• Define products and quality expectations before building activity detail.
• Document how the method has been tailored and why the chosen level of control adds value.

Common mistakes to avoid

• Selecting only some principles and still describing the project as fully using the method.
• Treating sunk cost as a reason to continue after business justification has disappeared.
• Recording lessons without changing any current or future practice.
• Using management stages as technical phases without considering where governance decisions are actually needed.
• Escalating every variance instead of only those that threaten delegated tolerance.
• Building an activity schedule before products and acceptance expectations are sufficiently defined.
• Using tailoring as a synonym for removing controls or documentation with no value-based rationale.

Related KEVOS handbook pages