6.3 Directing a Project (DP) Process

6.3 Directing a Project (DP) Process

The Directing a Project (DP) process defines the core governance responsibilities of the Project Board throughout the project lifecycle. Its fundamental purpose is to enable the Project Board to exercise ultimate accountability for the project's success by making key strategic decisions and providing high-level oversight, while delegating the daily operational management of the project to the Project Manager.

Unlike operational delivery processes that function strictly within individual management stages (such as Controlling a Stage or Managing Product Delivery), Directing a Project is an overarching governance process. It is activated as soon as the pre-project process Starting Up a Project (SU) produces a viable Project Brief, and it remains continuously active until formal project decommissioning and closure.

---

The Project Board: Composition, Roles, and Governance Principles

To understand how Directing a Project functions, one must first examine the structure and accountabilities of the Project Board. PRINCE2 7 mandates that executive decision-making is shared among three primary roles representing distinct stakeholder interests:

1. The Executive (Business Interest): Owns the Business Case and retains ultimate accountability for the project. The Executive ensures that the project delivers value for money and remains aligned with corporate strategic objectives.
2. The Senior User (User Interest): Represents the operational end-users and beneficiaries of the project's products. The Senior User defines user requirements, specifies expected benefits, and ensures that project deliverables are fit for operational use.
3. The Senior Supplier (Supplier/Developer Interest): Represents those who design, construct, deliver, and support the project's specialist deliverables. The Senior Supplier confirms technical viability and commits supplier resources.

The Delegation and Governance Interface

The Project Board does not engage in day-to-day project tasks. Instead, it governs by setting clear boundaries—known as tolerances—and establishing formal reporting channels with the Project Manager. This architecture enforces the PRINCE2 principle of Manage by Exception. The Project Manager is granted autonomy to manage within agreed stage tolerances. The Board intervenes only when performance is forecast to breach these predefined limits or when major decision gates are reached.

---

The 5 Key Decision Activities of the DP Process

The Directing a Project process is organized around five core activities, four of which act as major decision gates and one that operates continuously as ad hoc direction:

                  +-----------------------------------+
                  |      1. Authorize Initiation      |
                  +-----------------------------------+
                                    |
                                    v
                  +-----------------------------------+
                  |      2. Authorize the Project     |
                  +-----------------------------------+
                                    |
                                    v
                  +-----------------------------------+     
                  | 3. Authorize Stage/Exception Plan | <---+
                  +-----------------------------------+     | (Iterative
                                    |                       |  Delivery
                                    v                       |  Stages)
                  +-----------------------------------+     |
                  |     4. Give Ad Hoc Direction      | ----+
                  +-----------------------------------+
                                    |
                                    v
                  +-----------------------------------+
                  |    5. Authorize Project Closure   |
                  +-----------------------------------+

1. Authorize Initiation

• Trigger and Timing: Occurs immediately after the Project Manager completes the Starting Up a Project (SU) process during the pre-project phase.
• Inputs Evaluated: The Project Board reviews the Project Brief (including the Outline Business Case, Project Approach, and Project Management Team structure) alongside the Initiation Stage Plan.
• Governance Focus: The Board asks: Is this initiative viable, worthwhile, and aligned with organizational strategy? Is the proposed plan for Stage 1 (Initiation) realistic and adequately funded?
• Outputs & Decisions: If satisfied, the Board formally approves the Initiation Stage Plan, allocates funds for Stage 1, and authorizes the Project Manager to execute the Initiating a Project (IP) process. If unviable, the project is rejected before incurring significant expenditure.

2. Authorize the Project

• Trigger and Timing: Occurs at the conclusion of the Initiation Stage (Stage 1).
• Inputs Evaluated: The Board conducts a thorough review of the newly assembled Project Initiation Documentation (PID) and the standalone Benefits Management Approach.
• Governance Focus: The Board reviews the comprehensive Business Case, master Project Plan, risk profile, and the six core Management Approaches.
• Outputs & Decisions: Approving this gate represents a major corporate commitment. The Board formally baselines the PID, approves the Stage 2 Plan, commits the overall project capital and resources, and authorizes full project execution.

3. Authorize a Stage Plan or Exception Plan

• Trigger and Timing: Occurs near the end of each delivery stage during a Stage Boundary review, or immediately following the escalation of an Exception Report.
• Inputs Evaluated: End Stage Reports, Next Stage Plans, updated Project Plans, refreshed Business Cases, or escalated Exception Reports and Exception Plans produced by the Managing a Stage Boundary (SB) process.
• Governance Focus: The Board evaluates past stage performance against tolerances and assesses whether continued business justification exists.
• Outputs & Decisions: The Board can:
  • Approve the next Stage Plan and grant stage-specific tolerances.
  • Approve an Exception Plan (replacing an out-of-tolerance stage plan).
  • Defer approval pending modifications.
  • Instruct the Project Manager to prematurely close the project if business justification has ceased.

4. Give Ad Hoc Direction

• Trigger and Timing: Functions continuously across all management stages.
• Inputs Evaluated: Regular Highlight Reports (submitted by the PM at agreed intervals), formal Issue Reports, risk escalations, and informal requests for guidance.
• Governance Focus: Monitoring project progress, responding to external strategic changes, resolving inter-departmental conflicts, and advising the PM on complex risk responses.
• Outputs & Decisions: Issue responses, revised tolerance guidance, formal decision logs, and strategic guidance to navigate emerging project constraints.

5. Authorize Project Closure

• Trigger and Timing: Occurs in the final delivery stage after all specialist deliverables have been completed, verified, and accepted.
• Inputs Evaluated: The End Project Report, Lessons Report, draft closure notification, and confirmed product acceptance documentation from operational end-users.
• Governance Focus: Verifying that all project deliverables have been accepted, operational support and maintenance transition is complete, and post-project benefit realization ownership is confirmed by the Senior User.
• Outputs & Decisions: Formal approval to decommission the project infrastructure, authorization to release project resources, and distribution of the closure notice to corporate or programme management.

---

Detailed Decision Gate Governance Breakdown

The table below summarizes the governing criteria, essential inputs, and formal outputs across all five DP activities:

---

How Management by Exception Operates in DP

A critical element tested on the PRINCE2 7 exam is how the Project Board exercises governance without micromanaging. This is achieved through tolerance management across the 6 performance aspects:

1. Cost Tolerance: Permissible variance in spending (e.g., +/- $50,000 or +/- 5%).
2. Time Tolerance: Permissible schedule variance (e.g., +/- 2 weeks on stage completion date).
3. Quality Tolerance: Acceptable targets or ranges in product performance criteria (e.g., system response time between 1.2s and 1.5s).
4. Scope Tolerance: Agreed flexibility regarding permissible variation in scope deliverables (e.g., mandatory vs. optional user features).
5. Risk Tolerance: Thresholds of acceptable overall project risk exposure (e.g., no single risk exceeding $100k unmitigated impact).
6. Benefit Tolerance: Allowable variance in expected benefit achievement (e.g., target 20% cost reduction, minimum acceptable 15%).

The Exception Escalation Workflow

• Within Tolerances: As long as the Project Manager forecasts that performance will remain within agreed stage tolerances, the PM manages the stage autonomously. The PM keeps the Board informed via periodic Highlight Reports.
• Tolerance Breach Forecast: If the PM forecasts that any of the 6 tolerances will be exceeded, an exception has occurred. The PM cannot grant themselves additional tolerance. The PM MUST write an Exception Report and escalate it immediately to the Project Board via DP.
• Board Decision: The Board reviews the Exception Report and chooses to:
  • Increase tolerances to absorb the variance.
  • Instruct the PM to prepare an Exception Plan via the SB process to replace the current plan.
  • Terminate the project if the exception invalidates the Business Case.

---

Tailoring Directing a Project Across Contexts

PRINCE2 7 emphasizes that DP governance must be tailored to suit the specific environment of the project:

• Commercial / Customer-Supplier Contracts: In commercial arrangements, the Project Board contains representatives from separate legal entities (Customer Executive/Senior User and Supplier Senior Supplier). DP activities must respect formal contract boundaries, procurement rules, and legally binding change control mechanics.
• Agile & Iterative Environments: When using agile delivery practices, the Project Board does not abandon governance. Instead, decision gates align with release milestones. Stages are treated as fixed timeboxes, and scope tolerances are used to provide flexibility. The PM reports progress in Highlight Reports using burn-up charts and velocity metrics, allowing the Board to direct by exception without disrupting rapid iteration cycles.
• Programme & Portfolio Context: When part of a larger programme, the Project Board's Executive may report directly to the Programme Director. Some DP decision authority (such as approving initiation or major capital allocation) may be delegated upward to programme management, with project tolerances set at the programme level.

---

Key Exam Traps & Core Takeaways for DP

• Trap 1: Believing the Project Manager owns the DP process. False! Directing a Project is owned and executed exclusively by the Project Board.
• Trap 2: Assuming the Project Board conducts day-to-day management. False! Day-to-day management is delegated to the PM. The Board directs using decision gates and Manage by Exception.
• Trap 3: Thinking DP is only active during stage boundaries. False! DP runs continuously across the entire project lifecycle, providing ad hoc direction and reviewing Highlight Reports during delivery stages.
• Trap 4: Confusing Authorize Initiation with Authorize the Project. Authorize Initiation occurs at the end of SU to approve Stage 1 (Initiation). Authorize the Project occurs at the end of IP to baseline the PID and authorize full project execution.