2.2 Defined Roles, Responsibilities, and Relationships

2.2 Defined Roles, Responsibilities, and Relationships

Practitioner Core Mandate: Projects bring together individuals from diverse departments, functional hierarchies, and commercial organizations who may have never worked together before. Without unambiguous accountability, governance degenerates into political gridlock, neglected responsibilities, and misaligned delivery. PRINCE2 7 requires explicit definitions not only of what each role does, but also how individuals and organizations relate, communicate, and collaborate across operational boundaries.

---

Principle 3: Defined Roles, Responsibilities, and Relationships

Principle 3 mandates that an effective project management structure must explicitly answer: "Who is accountable?", "Who is responsible for delivery?", and "How do we work collaboratively across organizational interfaces?"

To ensure complete governance without operational ambiguity, PRINCE2 establishes two foundational structural frameworks:

1. The Three Primary Project Interests
2. The Four Levels of Management

---

The Tripartite Governance Model: The Three Primary Project Interests

Every project is an investment that alters operations and consumes technical capabilities. To succeed, the project management structure must continuously balance the competing priorities of three primary stakeholder interests on the Project Board:

                    ┌─────────────────────────┐
                    │      PROJECT BOARD      │
                    │   (Directing Level)     │
                    └────────────┬────────────┘
         ┌───────────────────────┼───────────────────────┐
         ▼                       ▼                       ▼
┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐
│    BUSINESS     │     │      USER       │     │    SUPPLIER     │
│    INTEREST     │     │    INTEREST     │     │    INTEREST     │
│ (Project Exec.) │     │  (Senior User)  │     │(Senior Supplier)│
├─────────────────┤     ├─────────────────┤     ├─────────────────┤
│ • Value/money   │     │ • Requirements  │     │ • Feasibility   │
│ • Business Case │     │ • Usability     │     │ • Technical res.│
│ • Strategic fit │     │ • Benefit yield │     │ • Delivery stds │
└─────────────────┘     └─────────────────┘     └─────────────────┘

1. The Business Interest (The Project Executive)

• Accountability: The Project Executive represents the organization funding the project and holds ultimate accountability for the project's overall success and the Business Case.
• Key Responsibilities: Ensures value for money, secures project funding, balances user and supplier demands, appoints the Project Manager and Project Board members, and holds final decision-making authority when consensus cannot be reached.

2. The User Interest (The Senior User)

• Accountability: Represents the individuals, groups, or operational departments that will utilize the project's products to realize business benefits.
• Key Responsibilities: Specifies operational requirements, defines user's quality expectations and acceptance criteria, commits user resources for testing and transition, monitors operational feasibility, and remains accountable for post-project benefits realization.

3. The Supplier Interest (The Senior Supplier)

• Accountability: Represents the internal specialists or external commercial entities responsible for designing, building, and delivering the specialist products.
• Key Responsibilities: Verifies technical feasibility of proposed solutions, commits supplier resources and craft specialists, guarantees product design standards, and ensures delivery integrity.

---

The Four Levels of Management

PRINCE2 isolates governance authority from day-to-day coordination by dividing project management into four distinct management levels:

The Governance vs. Management Firebreak

A cornerstone of PRINCE2 is the firm separation between the Directing level (governance) and the Managing level (management):

• The Project Board directs: they do not manage daily activities, allocate hourly tasks, or micro-manage specialist teams.
• The Project Manager manages: they run daily delivery within delegated stage tolerances, but cannot authorize their own stage transitions, approve their own major budget variances, or close the project.

---

The Evolution in PRINCE2 7: Why "Relationships" Was Added

In prior versions of PRINCE2, Principle 3 was titled "Defined roles and responsibilities". In PRINCE2 7, the title was expanded to: "Defined roles, responsibilities, and relationships".

This deliberate modification reflects a critical reality in modern project management: formal organizational charts and job descriptions do not guarantee project success.

Traditional Model (Pre-v7):          PRINCE2 7 Modern Relational Model:
┌────────────────────────┐           ┌────────────────────────┐
│ Structural Allocation  │           │ Structural Allocation  │
│ • Role Descriptions   │    +      │ • Role Descriptions   │
│ • Governance RACI      │           │ • Governance RACI      │
└────────────────────────┘           └───────────┬────────────┘
                                                 │
                                     ┌───────────▼────────────┐
                                     │  Relational Dynamics   │
                                     │ • Psychological Safety │
                                     │ • Cross-Boundary Trust │
                                     │ • Co-Creation & Voice  │
                                     │ • Commercial Alignment │
                                     └────────────────────────┘

The Four Relational Imperatives in PRINCE2 7:

1. Cross-Organizational Collaboration: Projects routinely span corporate boundaries, combining internal staff, external commercial suppliers, and third-party contractors. Principle 3 requires explicit protocols for communication, mutual respect, and collaborative problem-solving to mitigate defensive "contractual posturing."
2. Psychological Safety and Openness: Defined roles must create an environment where team members can voice technical concerns, escalate risks, and highlight early forecast tolerance breaches without fear of retaliation.
3. Co-Creation with Users: Rather than treating users as passive recipients at final acceptance, modern relationships require active co-design, continuous feedback loops, and shared ownership of product outcomes.
4. Commercial Relationship Management: When suppliers operate under commercial contracts, alignment of incentives is vital. Relationship management ensures that contractual terms foster transparency, trust, and alignment with the Business Case.

---

Role Combinations, Rules, and Governance Boundaries

In tailored projects, roles can often be shared or combined to reflect team size, provided specific governance boundaries are never breached.

Permissible vs. Forbidden Role Combinations

The Independence of Project Assurance

Project Assurance is the mechanism by which the Project Board independently verifies that the project is being conducted properly across Business, User, and Supplier dimensions.

• While the Project Board holds accountability for Project Assurance, board members can delegate assurance tasks to independent specialists.
• Critical Exam Rule: Project Assurance cannot be delegated to the Project Manager, Team Managers, or Project Support. Project Assurance must remain strictly independent of the Project Manager to ensure objective verification of stage progress, quality specifications, and risk registers.

---

PRINCE2 7 Practitioner Scenario Analysis

Scenario A: The Self-Assuring Project Manager

On an urgent cybersecurity upgrade project, the Project Executive appoints an experienced technical Project Manager. To save project costs, the Project Executive specifies in the Project Brief that the Project Manager will also carry out Business and Technical Project Assurance on behalf of the Board. The Project Executive asserts that the PM's 15 years in enterprise security makes external assurance redundant.

Practitioner Evaluation:

• This configuration is a severe governance violation under Principle 3. Project Assurance belongs to the Project Board to provide independent confidence that products meet quality standards and the Business Case remains viable.
• Allowing the Project Manager to perform Project Assurance creates an inherent conflict of interest: the individual managing daily execution cannot objectively audit their own compliance, risk management, or stage performance.
• Mandatory Action: The Project Board must reject this delegation. Assurance must be performed by the Project Board members themselves or delegated to independent individuals who report directly to the Board, isolated from the Project Manager's operational authority.

Scenario B: The Excluded Commercial Supplier

A municipal government launches a $10,000,000 traffic automation project. The Project Board is composed of the City Director (Project Executive) and the Transportation Chief (Senior User). The prime engineering software firm contracted to build the automated control system is excluded from the Project Board, because the Project Executive believes external commercial vendors should only interact with the Project Manager via fixed-price contracts.

Practitioner Evaluation:

• This structure violates Principle 3 by omitting the Supplier Interest (Senior Supplier) from the Project Board. Without direct Senior Supplier representation at the Directing level, the Board makes strategic decisions, approves timelines, and evaluates risks without authoritative technical feasibility guidance.
• This breakdown creates adversarial supplier relationships, leads to unrealistic stage plans, and increases commercial disputes.
• Mandatory Action: The Project Board must appoint a senior representative from the engineering firm as the Senior Supplier (or appoint an internal technical authority accountable for supplier governance) to ensure balanced tripartite governance.

Scenario C: The Disconnected Proxy User

During a hospital software implementation, the Senior User appointed to the Project Board is a corporate IT administrator who has never worked on clinical wards. The IT administrator signs off on Product Descriptions and acceptance criteria without consulting operational nurses or doctors. At final stage handover, clinical staff refuse to use the system, citing unsafe workflow disruption.

Practitioner Evaluation:

• This failure represents a collapse of User Representation and Relational Engagement under Principle 3. The Senior User role must genuinely represent those who will operate the products to realize benefits.
• Appointing a technical proxy who fails to build collaborative relationships with real end-users invalidates the User interest.
• Mandatory Action: The Senior User role must either be assigned to clinical operational leadership or supported by active User Assurance groups who directly represent frontline clinical end-users.

---

Practitioner Exam Traps & Decision Rules

• Trap 1: Confusing Project Assurance with Quality Assurance: Quality Assurance is an organizational, enterprise-wide function that establishes corporate quality standards independent of projects. Project Assurance is project-specific, owned by the Project Board, and monitors the project's compliance independently of the Project Manager.
• Trap 2: Assuming the Project Manager Owns the Business Case: While the Project Manager updates and maintains the Business Case on a day-to-day basis, the Project Executive holds ultimate accountability for the Business Case and the project's business justification.
• Trap 3: Believing Relationships Replace Governance: Some exam scenarios suggest that having "high trust and great relationships" eliminates the need for formal Product Descriptions or Project Board approvals. In PRINCE2 7, relationships enhance and operationalize defined roles—they never replace formal governance controls.