11.2 Directing a Project (DP) Process & Project Board Authorizations

Directing a Project (DP) Process & Project Board Authorizations in PRINCE2 7

Practitioner Core Mandate: In PRINCE2 7, project governance is divided into two distinct organizational tiers: direction (exercised by the Project Board) and management (exercised by the Project Manager). The Directing a Project (DP) process provides the structural mechanism through which the Project Board maintains overall accountability for project success, makes high-impact strategic decisions, commits corporate resources, and steers project delivery—all while respecting delegated boundaries so the Project Manager can manage day-to-day work without interference.

---

1. Purpose, Scope & Unique Lifecycle Architecture of Directing a Project (DP)

The Directing a Project (DP) process has a unique lifecycle span in PRINCE2. While all other processes operate within specific lifecycle phases (pre-project, initiation, stage delivery, or stage boundary), DP operates continuously from before project inception until after final closure.

                    THE LIFECYCLE SPAN OF DIRECTING A PROJECT

   PRE-PROJECT          STAGE 1 (INITIATION)       DELIVERY STAGES (2..N)       PROJECT CLOSURE

   [SU Process] ──►     [IP Process]         ──►   [CS / MP / SB]        ──►    [CP Process]
         │                    │                          │                            │
         ▼                    ▼                          ▼                            ▼
   ┌──────────────────────────────────────────────────────────────────────────────────────┐
   │                       DIRECTING A PROJECT (DP) PROCESS                               │
   │                                                                                      │
   │  1. Authorize       2. Authorize         3. Authorize a          5. Authorize        │
   │     Initiation         the Project          Stage or                Project          │
   │     (Gate 1)           (Gate 2)             Exception Plan          Closure          │
   │                                             (Gate 3..N)             (Final Gate)     │
   │                                                                                      │
   │  ◄──────────────────────── 4. GIVE AD HOC DIRECTION ───────────────────────────────► │
   │     (Continuous: Highlight Reports, Exception Reports, advice, external changes)     │
   └──────────────────────────────────────────────────────────────────────────────────────┘

The Core Purpose of Directing a Project

The purpose of DP is to enable the Project Board to be accountable for the project's success by making key decisions and exercising overall control, while delegating day-to-day management of the project to the Project Manager.

Key Objectives of the DP Process:

• Ensure there is continued business justification throughout the project lifecycle;
• Provide formal authorization gates before committing corporate capital to successive stages;
• Provide overall direction and advice to the Project Manager during execution;
• Ensure effective liaison with corporate, programme management, and external stakeholders;
• Authorize project closure and confirm orderly deliverable handover to operational teams.

Principle in Action: Manage by Exception

DP is the operational embodiment of Manage by Exception:

• The Project Board does not hold routine weekly progress meetings, inspect daily timesheets, or interfere in Work Package assignments.
• Instead, the Board sets Stage Tolerances across the seven project performance targets (cost, time, quality, scope, benefits, risk, sustainability) and delegates day-to-day autonomy to the Project Manager.
• As long as the project remains forecast within these agreed tolerances, the Project Manager manages autonomously.
• The Board monitors progress through periodic, time-driven Highlight Reports.
• The Board intervenes only at predefined Stage Gates or when an Exception Report is escalated because tolerances are forecast to be breached.

---

2. The Five Governance Activities of Directing a Project

PRINCE2 7 structures the directing tier into five precise governance activities:

┌─────────────────────────────────────────────────────────────────────────────┐
│               THE 5 ACTIVITIES OF DIRECTING A PROJECT (DP)                  │
├─────────────────────────────────────────────────────────────────────────────┤
│ 1. AUTHORIZE INITIATION (Gate 1)                                            │
│    • Triggered at end of Starting Up a Project (SU).                        │
│    • Approves Project Brief and commits funds for Initiation Stage Plan.    │
├─────────────────────────────────────────────────────────────────────────────┤
│ 2. AUTHORIZE THE PROJECT (Gate 2)                                           │
│    • Triggered at end of Initiating a Project (IP).                         │
│    • Evaluates PID, baselines project, commits full budget, approves Stage 2│
├─────────────────────────────────────────────────────────────────────────────┤
│ 3. AUTHORIZE A STAGE OR EXCEPTION PLAN (Gates 3..N)                         │
│    • Triggered at stage boundaries (SB) or during exceptions.               │
│    • Evaluates End Stage Report, updates Business Case, approves next plan. │
├─────────────────────────────────────────────────────────────────────────────┤
│ 4. GIVE AD HOC DIRECTION (Continuous Oversight)                             │
│    • Responds to Highlight Reports, advice requests, and Exception Reports. │
│    • Maintains alignment with external corporate strategy changes.          │
├─────────────────────────────────────────────────────────────────────────────┤
│ 5. AUTHORIZE PROJECT CLOSURE (Final Gate)                                   │
│    • Triggered at end of Closing a Project (CP).                            │
│    • Verifies operational acceptance, reviews Lessons Report, hands over    │
│      Benefits Management Approach, and formally dissolves the project.      │
└─────────────────────────────────────────────────────────────────────────────┘

Activity 1: Authorize Initiation

• Trigger: The Project Manager submits the Project Brief and Initiation Stage Plan at the conclusion of Starting Up a Project (SU).
• Governance Objective: First formal gateway. The Board must confirm that the project concept is viable and that the resources required to plan the project are justified.
• Key Decisions:
  • Validate the Project Definition and Outline Business Case;
  • Confirm that user's quality expectations and acceptance criteria are adequately understood in the Project Product Description;
  • Approve the Project Management Team structure and confirm all role appointments;
  • Authorize the Initiation Stage Plan, releasing the budget, people, and resources needed for the Initiating a Project process;
  • Establish stage tolerances for the initiation stage.
• Crucial Distinction: Authorizing initiation does not authorize project execution. It releases funding only for the work required to plan the project in the initiation stage.

Activity 2: Authorize the Project

• Trigger: The Project Manager submits the completed Project Initiation Documentation (PID) and the Stage Plan for Stage 2 (first delivery stage) at the end of Initiating a Project (IP).
• Governance Objective: The most significant commitment gate in the project lifecycle. The Board decides whether to formally baseline and fund the entire project.
• Key Decisions:
  • Scrutinize the detailed Business Case to ensure Continued Business Justification (NPV, ROI, payback, benefits, and dis-benefits);
  • Review and approve the four management approaches: Risk Management, Quality Management, Change Control, and Communication Management;
  • Approve the project-level baseline Project Plan and the overall Project Tolerances delegated by the business layer;
  • Approve the Benefits Management Approach and ensure accountability for benefits realization is assigned;
  • Approve the Stage Plan for the first delivery stage (Stage 2) and allocate stage tolerances across all seven performance targets;
  • Formally commit the total organizational capital and resources required for the project.

Activity 3: Authorize a Stage or Exception Plan

• Trigger: Submitted by the Project Manager at the end of a delivery stage (via Managing a Stage Boundary - SB), or when recovering from an escalated breach via an Exception Plan.
• Governance Objective: Ensure continued viability before committing funds to the next delivery stage or recovery effort.
• Key Decisions:
  • Review the End Stage Report to verify that all products in the expiring stage achieved their quality specifications and were approved;
  • Re-verify the Business Case against accumulated actual spend, updated forecasts, and evolving external market conditions;
  • Assess the aggregated risk exposure across the entire project portfolio;
  • Review and approve the Stage Plan for the next stage (or Exception Plan), releasing funds strictly for that stage and setting new stage tolerances;
  • Verify that lessons learned during the stage have been recorded in the Lessons Log.

Activity 4: Give Ongoing Direction

• Trigger: Continuous throughout the project lifecycle; prompted by time-driven Highlight Reports, event-driven Exception Reports, requests for guidance, or external corporate changes.
• Governance Objective: Provide responsive steering, resolve escalations, remove organizational roadblocks, and maintain strategic alignment.
• Key Decisions:
  • Review periodic Highlight Reports to monitor stage progress against tolerances without micromanaging;
  • Provide guidance, advice, and assistance to the Project Manager on emerging issues and stakeholder friction;
  • Evaluate escalated Exception Reports when stage tolerances are forecast to be breached, deciding whether to adjust tolerances, request an Exception Plan, or direct premature closure;
  • Communicate corporate or programme strategic changes down to the Project Manager;
  • Inform corporate/programme management when project-level tolerances are threatened.

Activity 5: Authorize Project Closure

• Trigger: The Project Manager submits the End Project Report, Lessons Report, and draft closure documentation at the conclusion of Closing a Project (CP).
• Governance Objective: Confirm that the project has completed its mandate, deliverables are safely integrated into business operations, and the project organization can be dissolved.
• Key Decisions:
  • Confirm that all specialist products have received formal operational acceptance from users and maintenance teams;
  • Ensure that operational handover and custodial transfer are legally and practically complete;
  • Review and approve the End Project Report, noting actual performance against original baselines;
  • Review the Lessons Report and authorize its transmission to corporate knowledge repositories;
  • Review and approve the updated Benefits Management Approach, formally transferring ownership of post-project benefits tracking to the business layer;
  • Issue formal notice of project closure to corporate/programme management, releasing project resources, closing project budgets, and disbanding the Project Management Team.

---

3. The Project Board: An Active Steering Body vs. Passive Rubber Stamp

A critical emphasis in PRINCE2 7 is that the Project Board is not an honorary or passive committee. It is an executive decision-making organ with direct accountability for business success.

                       THE PROJECT BOARD GOVERNANCE TRIAD
   
                                ┌─────────────────┐
                                │    EXECUTIVE    │
                                │ (Business Role) │
                                └────────┬────────┘
                                         │
                   ┌─────────────────────┴─────────────────────┐
                   │                                           │
                   ▼                                           ▼
         ┌───────────────────┐                       ┌───────────────────┐
         │    SENIOR USER    │                       │  SENIOR SUPPLIER  │
         │    (User Role)    │                       │  (Supplier Role)  │
         └─────────┬─────────┘                       └─────────┬─────────┘
                   │                                           │
                   └─────────────────────┬─────────────────────┘
                                         │
                                         ▼
                            ┌─────────────────────────┐
                            │    PROJECT ASSURANCE    │
                            │ (Independent Oversight) │
                            │ • Business Assurance    │
                            │ • User Assurance        │
                            │ • Supplier Assurance    │
                            └─────────────────────────┘

The Three Project Interests

The Project Board balances three distinct organizational perspectives:

1. The Business Interest (Project Executive): Represents the commissioning organization. The Project Executive is the single individual with ultimate accountability for project success. The Project Executive owns the Business Case, secures funding, and ensures the investment delivers value for money.
2. The User Interest (Senior User): Represents the people who will use, operate, or maintain the project deliverables. The Senior User defines user requirements, specifies operational acceptance criteria, monitors deliverable usability, and commits to realizing the projected business benefits post-project.
3. The Supplier Interest (Senior Supplier): Represents the internal or external specialists who design, manufacture, and deliver the products. The Senior Supplier confirms technical feasibility, commits supplier engineering resources, and is accountable for the technical and craftsmanship quality of deliverables.

Core Attributes of Effective Board Members

Every Project Board member must possess four essential attributes:

• Authority: The organizational seniority to commit company funds, deploy personnel, and make binding strategic decisions without seeking higher committee approvals.
• Credibility: Respected standing within their respective corporate, user, or technical communities.
• Ability to Delegate: The discipline to delegate day-to-day management to the Project Manager, steering through tolerances rather than micromanaging.
• Availability: Ready accessibility to review gateway submissions, read Highlight Reports, and assemble rapidly when an Exception Report requires urgent direction.

Decision-Making Dynamics: Consensus vs. Project Executive Authority

• Collaborative Consensus: In daily operations, the Project Board operates by consensus. The Project Executive, Senior User, and Senior Supplier debate trade-offs openly to reach unified decisions.
• The Project Executive Veto: The Project Board is not a democratic parliament. If a deadlock occurs—such as the Senior User demanding scope additions that the Senior Supplier claims are unachievable—the Project Executive holds ultimate single-point decision authority.
• The Project Executive makes the final binding decision, ensuring the project remains aligned with commercial business justification. If the Senior User or Senior Supplier strongly objects, their recourse is to escalate through corporate or commercial channels—they cannot block the Project Executive within the Board.

The Critical Role of Project Assurance

Project Board members are senior executives with crowded calendars. They cannot personally inspect code, audit engineering calculations, or interview every user group.

• Project Assurance fulfills this independent validation role, acting as the eyes and ears of the Board.
• Assurance is divided into three streams: Business Assurance (monitors business case and finances for the Project Executive), User Assurance (monitors user specifications and acceptance criteria for the Senior User), and Supplier Assurance (monitors technical standards and engineering quality for the Senior Supplier).
• The Golden Independence Rule: Project Assurance must be independent of the Project Manager. The Project Manager cannot perform Project Assurance, because a project manager cannot objectively audit their own plans and progress.

---

4. Directing Activities Matrix

The following matrix provides an authoritative exam reference for the five activities of Directing a Project:

---

5. Practical Scenario Evaluations

Scenario A: The Micromanaging Project Board

On a major transport ticketing project, the Project Board schedules mandatory weekly meetings where the Project Manager must present all daily timesheets, review individual developer task allocations, and seek Board approval before assigning any Work Package to a Team Manager. Stage delivery grinds to a halt as the PM spends 60% of their working hours preparing weekly administrative presentations for the Board.

Practitioner Evaluation:

• Governance Flaw: The Project Board is violating the core principle of Manage by Exception and the fundamental purpose of the Directing a Project process. The Board's role is strategic steering, not operational supervision.
• Systemic Consequence: Micromanagement destroys the Project Manager's autonomy, delays decision-making, inflates administrative overhead, and blurs accountability lines.
• Correct PRINCE2 Governance: The Project Board must set agreed Stage Tolerances across the seven performance targets and empower the Project Manager to manage day-to-day operations autonomously within those limits. Progress should be monitored through concise, periodic Highlight Reports, reserving Board intervention for stage boundaries or escalated Exception Reports.

Scenario B: The Passive Rubber-Stamp Board

During the initiation stage of a hospital patient portal, the Project Manager submits the Project Initiation Documentation (PID) containing a 10-page Business Case. The Project Board signs the approval block within 15 minutes of receipt without reading the document, validating the financial payback estimates, or confirming that the Senior User's nursing staff have committed to the change. In Stage 3, the project collapses because clinical staff refuse to adopt the interface, eliminating all projected benefits.

Practitioner Evaluation:

• Governance Flaw: The Board acted as a passive rubber stamp, abdicating its fiduciary duty under Authorize the project. Project Board members are personally accountable for project success.
• Systemic Consequence: Unscrutinized assumptions, fictional benefits models, and uncommitted user groups were allowed into the baseline, guaranteeing commercial failure.
• Correct PRINCE2 Governance: During Authorize the project, the Board must rigorously interrogate the Business Case, verify that User Assurance confirms operational feasibility, ensure the Senior User explicitly signs off on benefits ownership, and verify that the Senior Supplier confirms technical delivery viability before authorizing delivery expenditure.

Scenario C: The Irreconcilable Voting Deadlock

During Stage 3 of a commercial airline booking engine, a major technical dilemma arises. The Senior User insists that a complex seat-selection graphic must be retained, while the Senior Supplier proves that the graphic causes mobile page timeouts and will breach server latency tolerances. The Senior User and Senior Supplier refuse to concede. The Project Manager asks the Board how to vote.

Practitioner Evaluation:

• Governance Flaw: The Project Manager mistakenly believes the Project Board is a democracy governed by majority voting.
• Correct PRINCE2 Governance: The Project Board is governed by single-point executive accountability. The Project Executive holds ultimate decision authority for the project. When the Senior User and Senior Supplier reach an impasse, the Project Executive evaluates both positions against the Business Case and makes the final, binding determination. The PM and Board members must execute the Project Executive's ruling.

---

6. Responsibilities in DP: The RACI Chart and Practice Application

Table 14.2 — RACI for directing a project

Key: A = Accountable (one role only), R = Responsible, C = Consulted, I = Informed. The manual's footnotes read R¹ business related, R² user related, R³ supplier related.

The three patterns worth memorizing

1. The project executive is A/R for every single DP activity. Directing a project is the one process where the accountable role is also the responsible role throughout. This is the structural reason the project executive — not the board collectively — carries the casting decision.
2. The project manager is only ever Informed or Consulted in DP. Any option in which the project manager authorizes a stage, approves the PID, or closes the project is wrong by RACI alone.
3. Give ongoing direction is the only activity where the senior user and senior supplier are Responsible. Everywhere else they are consulted. This reflects that ongoing direction is where board members actively advise, respond to escalations, and feed in organizational change — and it is why the business layer moves from Informed to Consulted for this one activity.

How the practices are applied in DP (table 14.3)

The board authorizes against the business case at every gate (is the project still desirable, viable, and achievable?); uses the organizing practice to confirm the project management team and to delegate change authority; uses plans to approve the stage plan or exception plan; uses quality to approve the project product description and confirm acceptance; uses risk and issues to decide escalated exceptions and changes beyond the project manager's delegated authority; and uses progress to set project and stage tolerances and to read highlight and end stage reports.

---

7. Practitioner Exam Pitfalls & Governance Traps

• Trap 1: Believing the Project Board Authorizes Work Packages: The Project Board never authorizes Work Packages; Work Packages are authorized exclusively by the Project Manager in the Controlling a Stage (CS) process.
• Trap 2: Confusing 'Authorize initiation' with 'Authorize the project': Authorize initiation (Gate 1) releases funding only for the planning work in the initiation stage (IP). Authorize the project (Gate 2) commits the organization to the entire project budget and baselines the PID.
• Trap 3: Project Assurance Reporting to the Project Manager: Project Assurance works on behalf of the Project Board to provide independent validation; Project Assurance must remain strictly independent of the Project Manager.
• Trap 4: Expecting Routine Calendar Meetings for the Board: In PRINCE2, the Project Board does not direct via fixed-interval operational meetings. Board governance is event-driven (stage gates, exception reports) supported by periodic time-driven information (Highlight Reports).
• Trap 5: The Project Manager Authorizing Closure: The Project Manager executes the closure activities in Closing a Project (CP), but only the Project Board can authorize project closure in the DP process.