3.3 Defined Roles, Responsibilities & Relationships

PRINCE2 Practitioner Version 7

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Exam Strategy & Open-Book Technique

2 PRINCE2 7 Method Overview

2.1 The PRINCE2 7 Method 2.2 What Changed in PRINCE2 7 2.3 Performance Targets, Tolerances & Project Context

3 PRINCE2 Principles (1–4)

3.1 Continued Business Justification 3.2 Learn from Experience 3.3 Defined Roles, Responsibilities & Relationships 3.4 Manage by Stages

4 PRINCE2 Principles (5–7) & Applying Principles

4.1 Manage by Exception 4.2 Focus on Products 4.3 Tailor to Suit the Project 4.4 Applying Principles in Context

5 People Management in Projects

5.1 Organisational & Project Ecosystems 5.2 Leadership in Projects 5.3 Team Culture & Diversity 5.4 Communication, Stakeholder Engagement & Change Management

6 Practices Overview & Business Case

6.1 The Seven Practices & Tailoring 6.2 Business Case: Desirability, Viability & Achievability 6.3 Business Case Lifecycle & Management Products 6.4 Business Case Application & Tailoring Scenarios

7 Practices: Organising & Plans

7.1 Organising: Roles & Accountability 7.2 Organising: 5-Step Ecosystem Technique 7.3 Plans: Three Levels & Product-Based Planning 7.4 Plans: Techniques, Tolerances & Tailoring

8 Practices: Quality & Risk

8.1 Quality: Planning, Control & Assurance 8.2 Quality Techniques & Management Products 8.3 Risk: Threats & Opportunities 8.4 Risk 5-Step Technique & Application

9 Practices: Issues

9.1 Issues Practice: Issue vs Change & Categories 9.2 Issues 5-Step Technique & Supporting Techniques 9.3 Change Control, Configuration & Priority/Effort Assessment

10 Practices: Progress, Sustainability & Application

10.1 Progress: Controls, Tolerances & Reports 10.2 Sustainability as the 7th Performance Target 10.3 Tailoring the Practices 10.4 Practices Application Scenarios (BL4)

11 Processes: Model, Starting, Directing & Initiating

11.1 The Seven Processes & Process Model 11.2 Starting Up a Project 11.3 Directing a Project 11.4 Initiating a Project

12 Processes: Controlling a Stage & Product Delivery

12.1 Controlling a Stage 12.2 Managing Product Delivery 12.3 Stage Control & Exception Scenarios (BL4) 12.4 Work Packages & Reporting Cycle

13 Processes: Stage Boundary, Closing & Tailoring

13.1 Managing a Stage Boundary 13.2 Closing a Project 13.3 Tailoring the Processes 13.4 Process Application Scenarios (BL4)

14 Tailoring, Management Products & Exam Technique

14.1 Tailoring to Project Environment, Scale & Agile 14.2 Management Products & the v7 Project Log 14.3 Final Exam Technique, Full Scenarios & Common Traps

3.3 Defined Roles, Responsibilities & Relationships

Key Takeaways Explain This Topic AI

PRINCE2 v7 names this principle "define roles, responsibilities, and relationships" — the v7 rename adds "relationships", tying the principle to the People element.

The Organising practice defines a three-interest structure — business, user, and supplier — reflected in the Project Board roles of Executive, Senior User, and Senior Supplier.

No individual should hold two roles that conflict in accountability; the Project Manager cannot also be the Executive, for example.

Last updated: August 2026

What the principle means

PRINCE2 v7 restates this principle as "define roles, responsibilities, and relationships" . The addition of "relationships" is deliberate: it links the principle to the People element introduced in v7, recognising that how people interact across role boundaries is as important as the role titles themselves. The principle is delivered through the Organising practice .

A project involves three distinct stakeholder interests, and the role structure is built to represent each:

• Interest Board role Accountability
• Business Executive Overall decision-making; the business case
• User Senior User Benefits realisation and user needs
• Supplier Senior Supplier Resources and specialist skills to deliver

The wider management structure defined by the Organising practice is:

• Project Board — Executive, Senior User, Senior Supplier (above)
• Project Manager — day-to-day management within the stage
• Team Manager(s) — produce the products within a Work Package
• Project Assurance — independent assurance of the board's interests
• Project Support — administrative and tooling support to the PM
• Why the structure matters

Projects fail when accountability is diffuse — "everyone is responsible" in practice means no one is. PRINCE2 attacks this by giving every role a defined accountability and a defined reporting relationship. The Project Board owns the project; the Project Manager runs it within a stage; Team Managers deliver products; Project Assurance watches on behalf of the board; Project Support enables the PM.

The v7 emphasis on relationships extends this beyond the org chart: it asks how the PM communicates with the board, how assurance is exercised without becoming a bottleneck, and how supplier teams coordinate with user-facing teams. The principle is as much about the quality of the interactions as about the role titles.

No conflicting roles

A hard rule flows from this principle: no single person should hold two roles whose accountabilities conflict . The classic exam example is the Project Manager who is also the Executive. The Executive is accountable for the business case and sits above the PM; the PM is accountable for delivery within a stage. One person holding both destroys the independence the board structure is meant to provide and removes the very assurance that the principle guarantees.

• Role conflict Why it fails
• PM + Executive The PM reports to the board; cannot also chair it
• Executive + Senior Supplier Business accountability conflicts with supplier resource accountability
• PM + Team Manager (on same products) Management of the stage conflicts with production of the products
• Application in exam scenarios

At Bloom's Level 4 the exam asks you to analyse a role assignment and identify either the correct role for an action or a conflict. Typical scenarios:

"Who is accountable for realising the benefits?" — the Senior User , not the Executive or PM.

"Who signs off the completed project and the Lessons Report?" — the Project Board via the Executive.

A PM who is also performing Project Assurance on the same project — conflict, because assurance must be independent of the PM.

A scenario where a supplier manager is also the Senior User — conflict, because supplier resource accountability conflicts with representing user benefit interests.

The analytical move is to first ask which interest (business, user, supplier) the action serves, then match it to the role whose accountability covers that interest, then check whether the same person already holds a conflicting role.

The four levels of decision-making

The Organising practice defines four levels at which decisions are taken in a PRINCE2 project:

Level Who decides Typical decision

Corporate or programme Senior management outside the project Whether to commission the project; set project-level tolerances

• Directing Project Board Authorise stages, re-test the business case, premature closure
• Managing Project Manager Plan the stage, issue Work Packages, manage within stage tolerances
• Delivering Team Manager(s) Produce products within a Work Package to agreed quality

A scenario that has the Project Manager authorising the next stage, or the Team Manager re-testing the business case, is confusing these levels. The principle requires each level to stay within its decision rights.

The Executive must be a single named person

The Executive is the single point of accountability for the business case and chairs the Project Board. PRINCE2 is explicit that this is an individual role, not a committee. "The executive team will jointly own the business case" fails the principle because it diffuses accountability — exactly what the structure is designed to prevent. The same logic applies to the Project Manager: a project with "co-PMs" violates the principle because no single person is accountable for day-to-day management within a stage.

Stakeholder engagement and the Communication Management Approach

The v7 emphasis on relationships ties the principle to the Communication Management Approach , a management product that records who needs what information, when, and in what format. The principle is not only about the internal org chart; it extends to how the project engages external stakeholders who are not part of the management structure. A project with a clear board but no defined communication to regulators, affected business units, or partner organisations has defined the roles but not the relationships , and therefore under-delivers on the v7 wording.

Worked scenario: assigning the Senior User

A hospital is implementing a new patient records system. The IT director appoints the head of clinical coding as Senior User because "they understand the system". The correct analysis: the head of clinical coding is a specialist user but does not represent the broad body of clinical users (doctors, nurses, ward staff). The Senior User must represent the user interest as a whole , not a single user group. A scenario with a narrow Senior User appointment fails the principle because user-side accountability is incomplete.

Common traps

Assuming Project Assurance is optional. It is a defined role representing the board's three interests.

Confusing Project Support with Project Assurance — support enables the PM, assurance watches on behalf of the board.

Treating "relationships" as soft and untestable. The v7 wording makes them part of the principle and therefore examinable.