5.2 Project Board, Project Manager & Team Roles

Project Board, Project Manager & Team Roles

Quick Summary: In PRINCE2® 7, effective governance depends on razor-sharp accountability. The Project Board directs the project, commits enterprise resources, and makes strategic decisions under the ultimate authority of the Project Executive. The Project Manager manages the project on a day-to-day basis within delegated stage tolerances. The Team Manager focuses on technical execution, ensuring delivery teams produce products that satisfy the quality specifications established in agreed Work Packages.

Practitioner examination scenarios frequently assess your ability to diagnose role boundary disputes, detect unauthorized delegation, evaluate management product ownership, and resolve stakeholder political conflicts. To succeed, candidates must move beyond simple role definitions and master the precise division of power, accountability, and operational interaction between these roles.

---

The Project Board: Collective Governance & Decision-Making

The Project Board (representing Directing Level 2) is collectively responsible to the business layer for the overall success of the project. It possesses the authority to direct the project, authorize stage progression, approve plans, and commit organizational resources.

                 THE PROJECT BOARD GOVERNANCE STRUCTURE
   
                       ┌─────────────────────────┐
                       │        EXECUTIVE        │
                       │ └─ Ultimate Accountable │
                       │ └─ Owns Business Case   │
                       └────────────┬────────────┘
                                    │
                 ┌──────────────────┴──────────────────┐
                 │                                     │
          ┌──────┴───────┐                      ┌──────┴───────┐
          │ SENIOR USER  │                      │SENIOR SUPPLIER│
          │└─ Operational│                      │└─ Technical   │
          │   Needs &    │                      │   Feasibility │
          │   Benefits   │                      │   & Quality   │
          └──────────────┘                      └──────────────┘
                 │                                     │
                 └──────────────────┬──────────────────┘
                                    ▼
                        Consensus-Driven Decisions
                    (Project Executive has final authority)

Consensus vs. Project Executive Authority

A frequent area of confusion is how decisions are made on the Project Board:

• The Ideal Mechanism: Consensus: The Project Board aims to reach unanimous agreement on major decisions (e.g., stage authorizations, exception plan approvals, scope adjustments).
• The Legal Reality: The Board is NOT a Democracy: The Project Board does not operate by majority vote. The Project Executive is ultimately accountable for the project. If a conflict arises between the Senior User and Senior Supplier that cannot be reconciled through consensus, the Project Executive has the casting vote and final decision-making power.
• Constraint on Project Executive Power: The Project Executive's decision-making power is bounded by the project tolerances set by corporate/programme management. If resolving a board dispute requires breaching project-level tolerances, the Project Executive cannot unilaterally approve it; they must escalate to corporate/programme management via an Exception Report.

What Makes a Project Board Effective

PRINCE2 7 states the requirement directly: an effective project board requires the right level of authority for the nature and scale of the project, and credibility across the project ecosystem. Two further attributes follow from the method's own mechanics — manage by exception only works if board members can delegate, and stage-gate governance only works if they are available. A convenient memory hook is ACDA, but note that it is a study aid rather than a list the manual prints:

1. Authority (stated in the manual): the right level of authority for the nature and scale of the project — enough seniority to commit budgets, operational staff, and technical resources without waiting for further committee approvals.
2. Credibility (stated in the manual): credibility across the project ecosystem, so that each member can represent their stakeholder community authoritatively.
3. Ability to delegate (implied by manage by exception): the board sets tolerances and then lets the project manager work within them, rather than micro-managing.
4. Availability (implied by manage by stages): the bandwidth to attend stage boundary decisions, review management products promptly, respond to exception escalations, and give ongoing direction.

---

Detailed Breakdown of Project Board Roles

1. The Project Executive (Business Interest)

The Project Executive is identified by the business layer (commissioning) and appointed during the Starting up a Project process, in activity 13.4.1. Key characteristics and duties include:

• Single Individual: The Project Executive is strictly one person, never a committee or joint appointment.
• Business Case Ownership: The Project Executive owns the Business Case throughout the entire project lifecycle, ensuring continued business justification from pre-project feasibility to project closure.
• PMT Appointments: Appoints the Project Manager and confirms the appointments of the Senior User(s), Senior Supplier(s), Project Assurance, and Project Support.
• Funding & Value: Secures the project financial budget, ensures value for money, and balances the competing demands of users and suppliers.
• Project Brief Approval: Approves the Project Brief and authorizes initiation in the Directing a Project process.

2. The Senior User (User Interest)

The Senior User represents the interests of all those who will use the project's products to deliver operational benefits, or who will operate and maintain the products post-handover. Key characteristics and duties include:

• Multiple Appointments Permitted: Unlike the Project Executive, there can be more than one Senior User on the Project Board if the project impacts multiple business units or customer groups. However, board size should be kept compact to maintain decision velocity.
• Requirements & Acceptance: Specifies operational needs, defines quality expectations, and formalizes user acceptance criteria.
• Commits User Resources: Commits operational personnel to participate in product design reviews, user acceptance testing (UAT), training sessions, and pilot deployments.
• Accountable for Benefits Realization: Demonstrates that the delivered products are being effectively utilized in operational business units to achieve the benefits forecasted in the Business Case.

3. The Senior Supplier (Supplier Interest)

The Senior Supplier represents the interests of those designing, developing, facilitating, procuring, and implementing the project's products. Key characteristics and duties include:

• Multiple Appointments Permitted: More than one Senior Supplier can sit on the board (e.g., one representing internal IT and one representing a prime software contractor).
• Commits Supplier Resources: Commits engineering specialists, software developers, technical equipment, and contractor capacity.
• Technical Feasibility & Standards: Accountable for the technical integrity of products, ensuring that design solutions, engineering standards, and production methodologies are technically viable.
• Quality of Delivered Products: Accountable for the quality of outputs supplied, ensuring they conform to technical specifications and quality specifications.

Detailed Comparison of Project Board Roles

---

The Project Manager: Day-to-Day Operational Governance

The Project Manager is the single point of operational focus. Appointed by the Project Executive, the Project Manager is responsible for managing the project on a day-to-day basis within the constraints and tolerances established by the Project Board.

                  THE PROJECT MANAGER'S SPHERE OF CONTROL
   
                            ┌─────────────────┐
                            │  PROJECT BOARD  │
                            └────────┬────────┘
                                     │ Directs via Stage Tolerances
                                     ▼
                      ┌─────────────────────────────┐
                      │       PROJECT MANAGER       │
                      │  └─ Single Operational Head │
                      │  └─ Manages Day-to-Day      │
                      └──────────────┬──────────────┘
                                     │
         ┌───────────────────────────┼───────────────────────────┐
         │                           │                           │
         ▼                           ▼                           ▼
   ┌───────────┐               ┌───────────┐               ┌───────────┐
   │ PLANNING  │               │MONITORING │               │CONTROLLING│
   │& BASELINES│               │& REPORTING│               │ & ISSUES  │
   │Stage Plans│               │Highlight  │               │Authorizes │
   │Work Pkgs  │               │Reports    │               │Work Pkgs  │
   └───────────┘               └───────────┘               └───────────┘

Primary Responsibilities of the Project Manager

1. Planning & Preparation: Prepares the Project Initiation Documentation (PID), Project Plan, Stage Plans, and Exception Plans (under board direction).
2. Work Package Management: Authors, negotiates, authorizes, and reviews Work Packages assigned to Team Managers or delivery teams.
3. Progress Tracking: Monitors stage progress against baselines, measures tolerance consumption, and produces regular Highlight Reports for the Project Board.
4. Risk & Issue Management: Maintains the project registers (Risk Register, Issue Register, Quality Register, Lessons Log), assesses risks and issues, and executes approved mitigation actions.
5. Exception Handling: Immediately notifies the Project Board via an Exception Report whenever a stage is forecast to breach any of its seven performance tolerances.
6. Stakeholder Engagement: Manages day-to-day communications with stakeholders according to the Communication Management Approach.

Limits of the Project Manager's Authority

Practitioner questions frequently test candidates on what the Project Manager cannot do unilaterally:

• The Project Manager cannot alter stage or project tolerances.
• The Project Manager cannot approve Exception Plans (only the Project Board can).
• The Project Manager cannot approve project closure (only the Project Board can).
• The Project Manager cannot reallocate project contingency budgets without explicit Change Authority or Project Board delegation.
• The Project Manager cannot commit user or supplier resources beyond those agreed in authorized plans.

---

The Team Manager: Managing Product Delivery

The Team Manager operates at Delivering Level 4. The primary role of the Team Manager is to facilitate production of the project's specialist products as defined in agreed Work Packages.

Key Responsibilities of the Team Manager

• Work Package Agreement: Formally accepts Work Packages from the Project Manager, confirming scope, quality specifications, technical constraints, and Work Package tolerances.
• Technical Team Leadership: Directs and coordinates technical specialists, developers, and trade contractors in day-to-day delivery tasks.
• Team Planning: Produces optional Team Plans to guide technical production (internal to the team; not approved by the Project Board).
• Quality Execution: Ensures quality activities (reviews, testing, inspections) are carried out in accordance with the Quality Management Approach and records results in the Quality Register.
• Reporting & Escalation: Submits regular Checkpoint Reports to the Project Manager and immediately escalates any anticipated breach of Work Package tolerances via an issue.

When is a Separate Team Manager Required?

A separate Team Manager is not mandatory under PRINCE2. If the Project Manager has the technical expertise, geographic proximity, and available capacity, the Project Manager can act as Team Manager directly. However, appointing separate Team Managers becomes essential when:

1. Specialist Skills: The technical domain requires specialized engineering leadership (e.g., civil engineering, advanced cybersecurity).
2. Geographic Distribution: Delivery teams operate across different countries, time zones, or remote facilities.
3. Scale & Complexity: The project involves numerous concurrent delivery streams that would overwhelm a single manager.
4. Commercial Vendor Boundaries: Products are being manufactured by an external contractor where a designated contractor team lead interfaces with the client Project Manager.

---

Role Descriptions & The Appointment Process

Role descriptions define the specific duties, reporting lines, and delegated authorities for every member of the Project Management Team.

                  APPOINTMENT LIFECYCLE IN PRINCE2 7
   
   1. STARTING UP A PROJECT (SU)
      ├─ The business layer appoints the PROJECT EXECUTIVE
      ├─ Project Executive appoints the PROJECT MANAGER
      └─ Project Executive & PM draft role descriptions and identify candidates for the PMT
         (Activity: Designing and appointing the project management team)
      
   2. INITIATING A PROJECT (IP)
      ├─ Role descriptions refined, confirmed, and signed off
      ├─ PMT structure, reporting lines, and delegation documented
      └─ Formalized into the Project Initiation Documentation (PID)
         (Activity: Setting up the project management team)
      
   3. MANAGING A STAGE BOUNDARY (SB)
      └─ Review PMT structure for upcoming stage; adjust for new specialist teams
         or external contractor onboarding
      
   4. CLOSING A PROJECT (CP)
      └─ PMT members officially released and returned to corporate line management

---

Areas of Focus for Key Roles, Practice by Practice

Every practice chapter in the manual ends with a table titled "Areas of focus for the key roles associated with the … practice" (tables 5.1, 6.4, 7.1, 8.2, 9.3, 10.2, and 11.3), and the syllabus tests those tables directly under assessment criterion 3.x.1(b). Learning seven separate tables is unnecessary — they follow one repeating pattern, and the pattern is what scenario questions exploit.

The pattern: who sets tolerance, who approves, who prepares

The two rules that answer most role questions

1. Project-level tolerance belongs to the business layer; stage-level tolerance belongs to the project executive. This repeats in the business case, quality, risk, and sustainability tables. A question where a project board grants itself extra project-level tolerance is describing a governance breach.
2. The project manager prepares, a board role approves. Across every practice, the project manager consults and drafts; the project executive, senior user, or senior supplier approves within their interest. An option in which the project manager approves their own product description or management approach is wrong.

Where the pattern bends

• Quality: the senior user, not the project executive, provides the user's quality expectations and acceptance criteria, while the project executive approves the project product description and confirms acceptance of the project product.
• Business case: the project executive is accountable for the business case for the whole project, but the business layer takes over accountability for the benefits management approach once the project has closed — which is why closing a project hands it over rather than closing it out.
• Organizing: the project executive appoints the project manager, and the business layer identifies the project executive. Nobody appoints themselves.

---

Practitioner Scenarios: Vacancies, Conflicts, and Politics

In real-world project scenarios, human and political friction poses significant risks to governance integrity. Practitioner questions test your ability to apply PRINCE2 principles to resolve these operational dilemmas.

Dilemma 1: Mid-Project Project Board Vacancies

• Scenario: A Senior User resigns mid-project during delivery Stage 3.
• Rule: The project cannot proceed without valid user representation. The Project Executive must immediately identify and appoint an interim or permanent replacement from the impacted user community.
• Exam Trap: The Project Manager cannot temporarily assume the Senior User role, nor can the Project Board continue to make stage decisions without active user representation.

Dilemma 2: Managing Multiple Senior Users Without Board Bloat

• Scenario: A global CRM deployment impacts sales teams, marketing teams, customer service, and field technicians across six geographic regions. Each department demands a seat on the Project Board.
• Rule: A Project Board should ideally remain small (typically 3 to 6 members) to preserve decision velocity. Appointing 12 Senior Users creates paralysis.
• PRINCE2 Solution: Appoint 1 or 2 lead Senior Users to sit on the Project Board (e.g., Global Head of Customer Operations). Establish a User Reference Group or appoint departmental representatives as User Assurance delegates who feed operational requirements into the lead Senior Users.

Dilemma 3: Commercial Supplier Conflicts of Interest

• Scenario: A project involves two competing external engineering vendors, Vendor A and Vendor B, delivering different components of a defense radar system.
• Rule: Placing competing external suppliers side-by-side on the Project Board can compromise commercial confidentiality, intellectual property, and pricing neutrality.
• PRINCE2 Solution: Appoint an internal technical director (e.g., Chief Systems Engineer) as the single Senior Supplier on the Project Board to represent the overarching supplier interest. Manage Vendor A and Vendor B separately at the delivering level via formal commercial contracts and distinct Work Packages.