3.3 Defined Roles, Responsibilities & Relationships

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:

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.

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:

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.