5.1 The Three Project Stakeholder Groups & Four Organizational Layers

The Three Project Stakeholder Groups & Four Organizational Layers

Quick Summary: A project is a temporary organization created to deliver one or more business products according to an agreed Business Case. Standard line management hierarchies are structured for steady-state operations, making them ill-suited for the cross-functional, time-bound, and high-uncertainty nature of projects. The Organizing practice establishes a temporary governance structure—the Project Management Team (PMT)—that balances three primary stakeholder interests (Business, User, and Supplier) across four distinct management levels.

In PRINCE2® 7, the former "Organization theme" was deliberately modernized to the Organizing practice. This terminology shift emphasizes that organizing is not a static one-off charting exercise completed in project initiation and filed away. Rather, organizing is an active, dynamic, and continuous capability. The project management team must assemble, evolve its governance mechanisms, adapt its delivery relationships across stages, and gracefully disband upon project closure.

---

The Defined Roles and Responsibilities Principle

The Organizing practice directly embodies the core PRINCE2 principle: Defined Roles and Responsibilities. Projects inevitably bring together diverse individuals from different functional departments, external vendor organizations, user communities, and regulatory bodies. Without explicit governance, projects suffer from ambiguity, conflicting instructions, unaccountable decision-making, and political friction.

A successful project management team structure must answer three fundamental governance questions at all times:

1. What is expected of me? (Explicit role descriptions and accountability boundaries)
2. What is expected of others? (Clarity of delegated decision-making and reporting lines)
3. Who makes the decisions? (A clear escalation path based on tolerances and exceptions)

PRINCE2 establishes that everyone involved in the project must know their role, understand the limits of their delegated authority, and recognize who is accountable for project success.

---

The Three Project Stakeholder Groups

A project can only be deemed truly successful if it balances the requirements of three distinct stakeholder viewpoints. If any one of these interests is missing or marginalized, the project faces critical vulnerabilities: an initiative with strong business and technical support that ignores users will deliver shelfware; an initiative dominated by users without business discipline will suffer catastrophic cost overruns; and an initiative driven solely by technology without commercial viability will fail to deliver business value.

                     THE THREE PROJECT INTERESTS
   
                            ┌──────────────┐
                            │   BUSINESS   │
                            │  (Project Executive) │
                            └──────┬───────┘
                                   │
                       Value for Money & Viability
                                   │
                 ┌─────────────────┴─────────────────┐
                 │                                   │
          ┌──────┴───────┐                    ┌──────┴───────┐
          │     USER     │                    │   SUPPLIER   │
          │(Senior User) │                    │(Senior Supp.)│
          └──────────────┘                    └──────────────┘
         Operational Need &                  Technical Skills &
        Benefits Realization                Production Feasibility

1. Business (Represented by the Project Executive)

The business interest ensures that the project represents value for money, aligns with organizational strategy, and maintains financial and economic justification. The Project Executive is the single individual who owns the Business Case and is ultimately accountable for project success.

• Primary focus: Return on investment (ROI), strategic fit, funding security, and ongoing business viability.
• Key question: "Is this investment justified, affordable, and aligned with corporate strategy?"

2. User Interest (Represented by the Senior User)

The user interest represents the individuals, business units, or customer groups who will actively utilize the project's outputs to realize operational benefits, or who will operate, maintain, or support the products post-handover.

• Primary focus: Product requirements, usability, operational readiness, acceptance criteria, and post-project benefits realization.
• Key question: "Will these products meet our operational needs, work reliably in practice, and deliver the promised operational benefits?"

3. Supplier Interest (Represented by the Senior Supplier)

The supplier interest represents the parties who provide the technical skills, resources, tools, materials, and engineering expertise required to design, manufacture, build, or configure the project products. These can be internal specialist teams (e.g., internal software engineering, legal, facilities) or external contractors and vendors.

• Primary focus: Technical feasibility, engineering integrity, development standards, resource allocation, and adherence to technical specifications.
• Key question: "Can we design and build these products within the required technical, quality, and contractual parameters?"

Comparative Analysis of the Three Stakeholder Groups

---

The Four Organizational Layers in PRINCE2 7

PRINCE2 7 structures project governance across four organizational layers (table 6.2: commissioning, directing, managing, delivering). The 6th Edition called the top layer 'corporate, programme management or the customer'; Version 7 calls it the business layer, and matching questions use business layer as an option alongside the named roles. Each level has defined boundaries of authority, reporting requirements, and decision-making responsibilities. Understanding where each role resides—and where the Project Management Team boundary falls—is essential for Practitioner scenario analysis.

                  THE FOUR ORGANIZATIONAL LAYERS IN PRINCE2 7

   ═══════════════════════════════════════════════════════════════════════════
   LAYER 1: COMMISSIONING (THE BUSINESS LAYER)
   └─ Sits OUTSIDE the Project Management Team
   └─ Provides the project mandate and identifies the project executive
   └─ Defines the project-level tolerances within which the board works
   └─ Decides whether to authorize any breach of a project-level tolerance
   ───────────────────────────────────────────────────────────────────────────
   ▲ Direction & Exception Reports          │ Mandate, Project Tolerances
   │                                        ▼
   ┌─────────────────────────────────────────────────────────────────────────┐
   │ PROJECT MANAGEMENT TEAM (PMT) BOUNDARY                                  │
   │                                                                         │
   │ LAYER 2: DIRECTING (Project Board)                                      │
   │ └─ Project executive, senior user(s), senior supplier(s)                │
   │ └─ Accountable for project success; directs by exception                │
   │ └─ Authorizes stages, commits resources, sets stage tolerances          │
   │ └─ Independent Project Assurance provides oversight                     │
   │                                                                         │
   │   ▲ Progress / Highlight / Exception   │ Stage Authorization / Controls │
   │   │                                    ▼                                │
   │                                                                         │
   │ LAYER 3: MANAGING (Project Manager)                                     │
   │ └─ Day-to-day management of the project within stage tolerances         │
   │ └─ Plans, monitors, controls; manages risks, issues, and quality        │
   │ └─ Supported by Project Support (administrative / tools)                │
   │                                                                         │
   │   ▲ Checkpoint Reports / Issues        │ Work Packages / Tolerances     │
   │   │                                    ▼                                │
   │                                                                         │
   │ LAYER 4: DELIVERING (Team Managers & Team Members)                      │
   │ └─ Production of specialized products to agreed specifications          │
   │ └─ Executes authorized Work Packages within Work Package tolerances     │
   │                                                                         │
   └─────────────────────────────────────────────────────────────────────────┘
   ═══════════════════════════════════════════════════════════════════════════

Layer 1: Commissioning (the Business Layer)

This layer sits outside the project management team. PRINCE2 7 calls it the business layer: the commissioning party within the business, which may be a corporate entity, a programme, or a commercial customer. Table 6.2 gives it four responsibilities:

• Providing the project mandate that triggers starting up a project.
• Identifying the project executive.
• Defining the project-level tolerances within which the project board will work, across the seven performance targets (benefits, costs, time, quality, scope, risk, sustainability).
• Determining whether to authorize any potential breach of a project-level tolerance escalated by the project board.

[!EXAM WATCHPOINT] In a matching question, the option letter for this layer will read 'Business layer', not 'the business layer'.

Layer 2: Directing (The Project Board)

The Project Board operates at the strategic directing level. It is responsible for the overall direction and governance of the project, operating under the principle of Manage by Exception. Rather than micro-managing daily tasks, the board establishes stage tolerances and empowers the Project Manager to manage within those bounds. Key duties include:

• Approving the Project Brief and authorizing project initiation.
• Approving the Project Initiation Documentation (PID) and authorizing delivery stages.
• Authorizing Exception Plans if stage tolerances are breached.
• Providing strategic advice, resolving inter-departmental conflicts, and committing enterprise resources.
• Authorizing project closure and confirming end-project documentation.

Layer 3: Managing (The Project Manager)

The Project Manager operates at the tactical management level, managing the project on a day-to-day basis on behalf of the Project Board. The Project Manager's operational boundary is bounded by the current Stage Plan and agreed stage tolerances. Key duties include:

• Formulating detailed Stage Plans and Work Packages.
• Directing and motivating delivery personnel and team managers.
• Monitoring progress and producing Highlight Reports for the Project Board.
• Maintaining the project log (daily log, issue register, lessons log, product register, quality register, risk register).
• Escalating forecast tolerance breaches to the Project Board via Exception Reports.

Layer 4: Delivering (Team Managers & Team Members)

The delivering level represents the technical production engine of the project. Whether delivery is organized through traditional technical teams, external vendor contractors, or agile development squads, this level is responsible for creating products to required quality standards. Key duties include:

• Accepting and executing authorized Work Packages assigned by the Project Manager.
• Managing team specialists and day-to-day production workflows.
• Monitoring production progress against Work Package tolerances.
• Submitting regular Checkpoint Reports to the Project Manager.
• Escalating technical issues and risks forecast to exceed Work Package tolerances.

---

The PRINCE2 Technique for Organizational Design and Development

Section 6.3.1 of the manual defines a five-step technique (figure 6.4) for designing and developing the project organization. It is the organizing practice's named technique, and it exists because several of the People-element concerns from Chapter 3 — culture, collaboration, relationships, and effective project teams — are addressed by deliberate organizational design rather than by good intentions. As with the other PRINCE2 techniques, an alternative procedure may be used if the business already has one, provided the choice is documented as a tailoring decision in the PID.

      THE FIVE-STEP ORGANIZATIONAL DESIGN AND DEVELOPMENT TECHNIQUE

   1. UNDERSTAND THE ORGANIZATIONAL ECOSYSTEM
      └─ Clarify who retains responsibility for: people management
         (performance, rewards, advancement, wellbeing); governance (which
         decisions are subject to corporate governance); management
         approaches (policies, procedures, ways of working); and how and
         when team members transition on and off the project.
                                  │
                                  ▼
   2. DESIGN THE PROJECT ECOSYSTEM
      └─ How to organize work and people to achieve the objectives:
         the effective team structure, the people and resources needed,
         and integrated working practices.
                                  │
                                  ▼
   3. DEVELOP THE PROJECT ECOSYSTEM
      └─ Implement the design and evolve it: onboarding (site visits,
         induction, certification), skills and capability assessments,
         training, team building, establishing a project culture,
         succession planning, and offboarding to capture lessons.
                                  │
                                  ▼
   4. MANAGE THE ONGOING CHANGES TO THE PROJECT ECOSYSTEM
      └─ Match responsibilities to capability and capacity; source or
         upskill as needs change; keep the commercial management approach
         able to move people on and off; review the project management
         team structure at transition points.
                                  │
                                  ▼
   5. TRANSITION THE PROJECT INTO THE ORGANIZATIONAL ECOSYSTEM
      └─ Three things the project board must consider at closure:
         PRODUCTS accepted into the business with owners for further
         development, benefits monitoring, operation, and maintenance;
         PEOPLE transitioned back into the business or managed per the
         commercial arrangements; LEARNING shared, including the skills
         team members acquired that will benefit the wider business.

Why this technique earns exam marks

• Step 1 is about boundaries, not org charts. The recurring scenario is a team member whose line manager still sets their objectives while the project manager directs their work. PRINCE2 7 wants that ambiguity resolved up front by agreeing who owns people management, governance, and ways of working.
• Step 4 explains why stages and team structure line up. The manual notes that a project stage is often defined by transition points in the required capabilities — which makes a stage boundary the natural moment to review the project management team structure and confirm the commercial management approach supports the change.
• Step 5 is a project board responsibility, and it has three parts. An option covering only product handover has missed people and learning.
• The change management approach works inside the project too. PRINCE2 7 says the change management approach used to deliver new capabilities to the organizational ecosystem can also deliver new capabilities to the project ecosystem — for instance, when preparing for a transition point such as appointing a key supplier.

Supporting techniques for organizing

The manual names two: delivery models (how the work will be sourced and structured — see the example delivery model in table 6.3) and the RACI chart, which PRINCE2 7 uses throughout the process chapters to state who is Responsible, Accountable, Consulted, and Informed for each activity.

---

The Project Management Team (PMT) Structure

The Project Management Team (PMT) encompasses everyone who performs a management role on the project. It includes:

• The Project Board (Project Executive, Senior User, Senior Supplier)
• Project Assurance (Business, User, and Supplier assurance roles)
• The Project Manager
• Project Support (if formally appointed)
• Team Manager(s) (if formally appointed)

                 THE PROJECT MANAGEMENT TEAM (PMT) STRUCTURE
   
                        ┌─────────────────────────┐
                        │      PROJECT BOARD      │
                        │ Project Executive               │
                        │ Senior User(s)          │
                        │ Senior Supplier(s)      │
                        └────────────┬────────────┘
                                     │
             ┌───────────────────────┼───────────────────────┐
             │                       │                       │
     ┌───────┴───────┐       ┌───────┴───────┐       ┌───────┴───────┐
     │    PROJECT    │       │    PROJECT    │       │    PROJECT    │
     │   ASSURANCE   │       │    MANAGER    │       │    SUPPORT    │
     │(Business, User│       └───────┬───────┘       │(Admin, Tools, │
     │   Supplier)   │               │               │   Filing)     │
     └───────────────┘       ┌───────┴───────┐       └───────────────┘
                             │  TEAM MANAGER │
                             │ (Delivering   │
                             │ Work Packages)│
                             └───────────────┘

Essential PMT Structural Characteristics

1. Temporary: The PMT is established during Starting up a Project, confirmed during Initiating a Project, and formally disbanded in Closing a Project.
2. Cross-Functional: It spans corporate silos, blending business managers, operational users, and technical suppliers into a single unified team.
3. Excludes Corporate Governance: Corporate or programme management sets the framework but is never inside the PMT.

---

Rules on Combining vs. Separating Roles

In real-world projects, especially in small to medium-sized initiatives, organizations rarely have the personnel to assign every single PRINCE2 role to a separate individual. PRINCE2 permits significant flexibility in tailoring the PMT, but enforces strict, non-negotiable governance separation rules to preserve accountability and integrity.

The Golden Separation Rules

1. The Project Executive and Project Manager can NEVER be combined:
   • Rationale: The Project Executive is accountable for governance, strategic direction, and Business Case ownership. The Project Manager manages day-to-day execution. Combining these roles eliminates independent oversight and destroys the "Manage by Exception" mechanism—a manager cannot objectively direct and audit themselves.
2. Project Assurance can NEVER be delegated to the Project Manager, Team Manager, or Project Support:
   • Rationale: Project Assurance provides independent, objective verification to the Project Board that the project is being managed properly and products are meeting standards. An operational manager cannot independently assure their own work.
3. The Senior User and Senior Supplier should NOT be combined if a commercial boundary exists:
   • Rationale: In commercial environments where external vendors supply products, combining user requirements with supplier interests creates severe conflicts of interest, compromising contract negotiations and quality acceptance.

Permissible Role Combinations

• Project Manager and Team Manager: The Project Manager can act as Team Manager directly, managing team members and technical production without appointing intermediate team leads. This is standard in small projects or internal IT delivery.
• Project Manager and Project Support: If no dedicated Project Support office exists, the Project Manager automatically assumes all project support duties (clerical tasks, updating registers, scheduling, document configuration).
• Project Board Member and Project Assurance: Project Board members are inherently responsible for project assurance. If they have sufficient time, technical skill, and objectivity, they can perform assurance directly rather than delegating it to independent specialists.
• Project Executive and Senior User: In internal projects where the sponsoring business unit is also the sole operational user (e.g., Finance Director sponsoring a new general ledger system for the finance department), the Project Executive can also represent the user interest.

Summary of Role Combination Governance Rules

---

Scenario Case Study: Structuring Governance at NovaRetail

NovaRetail, a nationwide department store chain, is launching a major digital transformation to deploy an automated inventory tracking system across 85 retail stores. The total capital expenditure is £4.2 million over an 18-month timeline.

The Governance Dilemma

During the Starting up a Project process, the Corporate Retail Operations Board issues a project mandate and designates the Chief Information Officer (CIO) as the project lead. The CIO proposes the following project management structure:

• Project Executive: Chief Information Officer (CIO)
• Project Manager: Lead Enterprise Architect
• Senior User: Retail Operations Director
• Senior Supplier: External RFID Hardware Vendor
• Project Assurance: Assigned entirely to the Lead Enterprise Architect (Project Manager) to save budget.

Governance Audit & Analysis

1. Board Representation: The three project interests are represented—Business (CIO, funding and enterprise IT strategy), User (Retail Operations Director, representing store managers and inventory clerks), and Supplier (External RFID Vendor, providing scanners and tracking beacons).
2. Fatal Governance Breach: The CIO assigned Project Assurance to the Project Manager (Lead Enterprise Architect). This directly violates PRINCE2 governance. The Project Manager cannot perform Project Assurance because they cannot independently verify their own project plans, risk registers, or stage governance.
3. Corrective Action: Project Assurance must be decoupled from the Project Manager. The Retail Operations Director can assign an internal retail auditor to perform User Assurance, the CIO can appoint a corporate finance analyst for Business Assurance, and an independent quality engineer can perform Supplier Assurance.