Directing a Project
The purpose of the Directing a Project process (DP) is for the Project Board to take overall control and make key decisions, remaining accountable for the success of the project. Day-to-day management activities are delegated to the Project Manager (PM).
Objectives
Aims to confirm and establish the following.
- Authorise initiation: The project initiation has been authorised
- Authorise delivery: Delivery of project products has been authorised
- Maintain governance: Appropriate direction and control throughout the lifecycle
- Confirm continued justification: The project continues to be viable
- Strategic alignment: Alignment with the Business Layer is maintained
- Authorise closure: Project closure has been authorised
- Value realisation: Post-project benefit realisation plans are appropriately managed and reviewed
Context
Trigger
Initiated when the Starting up a Project process (SU) is complete and the PM has issued a request to initiate a project.
Key Implementation Points
- Operating characteristics
- Manage by exception: The Project Board does not involve itself in day-to-day activities; it focuses on monitoring via reports and key decision-making
- Delegating authority: Providing appropriate authority to the PM and Team Managers, with clearly defined decision-making processes, is essential
- Key roles
- External liaison: Aligns the project with Business Layer strategy and acts as a communication channel
- Unified direction: Provides consistent and coherent guidance to the PM (when opinions differ within the Board, the Project Executive makes the final decision)
- Advice and guidance
- Two-way interaction: The Board provides informal advice to the PM, and the PM can also seek advice as needed — two-way communication is important
Activities
| Input | Activity | Output |
|---|---|---|
| Request to initiate a project (trigger) Business Case outline (review) Project Brief (review) Project Product Description (review) Stage Plan — initiation (review) | Authorise Initiation | Business Case outline (approved) Project Brief (approved) Project Product Description (approved) Stage Plan — initiation (approved) Initiation notification Project initiation authorisation (triggers Initiating a Project) |
| Request for project authorisation (trigger) Project Initiation Documentation (review) Business Case (review) | Authorise the Project | Project Initiation Documentation (approved) Business Case (approved) Project authorisation notification |
| Request for next stage (trigger) Request for Exception Plan approval (trigger) End Stage Report (review) Stage Plan — next stage (review) Project Plan (confirm) Business Case (confirm) | Authorise a Stage or Exception Plan | End Stage Report (approved) Stage Plan — next stage (approved) Project Plan (updated and approved as needed) Business Case (updated and approved as needed) Authorised stage or exception (triggers CS) PID (updated and approved as needed) |
| Request for advice (trigger) Exception raised (trigger) Lessons Report (review) Highlight Report (review) Issue Report (review) Exception Report (review) Business Case (confirm) | Give Ad Hoc Direction | Request for Exception Plan (triggers SB) Project Board advice and decisions (triggers CS) Early closure notification (triggers CP) |
| Request for project closure (trigger) End Project Report (review) Business Case (confirm) | Authorise Project Closure | Project closure notification |
Activity Details
Authorise Initiation
Initiating a project requires significant investment in time, cost, and resources. The purpose of this activity is for the Project Board to rigorously assess whether that investment is worthwhile and issue formal go-ahead.
Recommended actions for the Project Board:
- Confirm alignment and viability
- Confirm the project approach aligns with business policies
- Confirm the Business Case outline is viable and contributes to strategic objectives
- Approve key documents
- Review and approve the Project Brief and Project Product Description
- Confirm plans and resources
- Approve the Stage Plan for the initiation stage and set tolerances
- Direct that logistics — people, facilities, Project Support — are secured
- Notify and authorise
- Notify stakeholders and relevant teams that the project has entered the initiation stage
- Formally authorise the PM to begin the initiation stage
Authorise the Project
Triggered at the end of the initiation stage when the PM submits a request to authorise the project. Before committing funds and resources, the Project Board rigorously assesses whether the following are secured.
- Business justification: A robust Business Case exists; the project is viable and beneficial
- Feasibility: The Project Plan and Benefits Management Approach can reliably deliver the expected value
- Management structure: Management approaches and controls adequately support achievement of the plan
If the Project Board does not authorise the project, it must proceed to early closure at that point.
Recommended actions for the Project Board:
- Approve documents and standards
- Review and approve the Project Initiation Documentation (PID)
- Confirm and agree the overall project tolerances
- Validity checks
- Confirm that lessons from similar past projects have been reflected in the plans
- Confirm that responses to risks (threats and opportunities) are appropriately planned
- Secure resources and notify
- Secure and commit the people and resources needed to complete the project (provided to the PM stage by stage)
- Officially notify the business and stakeholders that the project has been authorised
- Final direction
- Formally authorise the PM to execute the project (or direct early closure if not authorised)
Give Ad Hoc Direction
The Project Board not only acts at authorisation points but also supports the PM and controls progress throughout the entire project lifecycle.
Main triggers for ad hoc direction:
- General advice: Clarifying business sustainability objectives (ESG requirements, etc.)
- Responding to requests: Resolving conflicts or narrowing complex options
- Responding to reports: Receiving Highlight Reports, Exception Reports, and Issue Reports
- External changes: Business priority changes or external factors affecting the project
- Concerns: Individual concerns from Project Board members
- Structure changes: Changes in Board membership
When exceptions occur within a stage:
- Authorise Exception Plan: When an exception exceeds stage tolerances, the Board reviews and approves an Exception Plan. The approved plan becomes the new baseline.
- Change in project mandate: When the business directs a policy change or closure, the Board chooses between:
- Treat as change request: Ask the PM to re-plan the stage or project
- Early closure and restart: Stop the current project and restart based on a new mandate
Recommended actions for the Project Board:
- Advice and support: Research and advise in response to informal requests from the PM
- Escalation responses
- Issues: Make decisions. For off-specifications, decide whether to reject (request correction) or conditionally approve (accept as-is)
- Exception Reports: Examine the content and decide whether to continue
- Monitor progress: Review Highlight Reports and take corrective action as needed
- Communicate information: Promptly notify the PM of business decisions and policy changes
Authorise a Stage or Exception Plan
No stage may begin without formal approval from the Project Board. This activity confirms current performance and justifies investment in the next stage.
- Required for all stages: Every stage must go through this approval process before starting
- Review focus: After confirming current stage performance, assess whether the next Stage Plan (or Exception Plan) is appropriate
Recommended actions for the Project Board:
- Evaluate performance: Review and approve the End Stage Report
- Examine the plan: Scrutinise the Stage Plan or Exception Plan the PM is seeking approval for
- Execute decisions:
- Approve the plan and proceed
- Reject the plan and ask the PM to reconsider and revise
- Determine project justification has been lost and direct early closure
- Communicate status: Notify the business and stakeholders of the current situation in accordance with the Communication Management Approach
Authorise Project Closure
Closing a project in a controlled manner is just as important as starting it. The Project Board compares the original plan (PID) with final performance to confirm the project has fulfilled its purpose.
Risks of uncontrolled closure:
- Incomplete transfer to operations, resulting in unrealised benefits
- Project team not released, disrupting their next assignments
- Final success or deviation remains ambiguous
Recommended actions for the Project Board:
- Evaluate achievement
- Compare the initial and final versions of the Project Initiation Documentation (PID) to assess goal achievement and deviations
- Review and approve the End Project Report
- Transfer benefits management
- Approve the updated Benefits Management Approach
- Formally transfer responsibility for reviewing benefits that can only be confirmed after project closure to the business (operational side)
- Final Business Case confirmation
- Compare actual figures (cost, risk, duration) with the Business Case to assess final justification
- Notify and release resources
- Formally notify all parties of the closure in accordance with the Communication Management Approach
- Direct withdrawal and return of support infrastructure and resources; specify the end date to stop cost accrual
- Confirm that team member offboarding has been properly completed
Applying the Process
General Considerations
The most important thing when applying this process in practice is to clearly define the boundary between directing and managing.
- Project Executive’s responsibilities: The Project Executive ultimately bears accountability for all activities in this process
- Work delegation: The Project Executive can delegate practical tasks to others, but the authority to make key decisions and grant authorisations remains with the Executive
- The PM cannot make decisions or grant approvals on matters within the Project Executive’s scope of accountability (such as project authorisation, final funding approval, and strategic judgements)
Tailoring Roles
Situations where Project Assurance can be delegated:
- Authorise Initiation: Validity checking of the initiation Stage Plan can be delegated to Project Assurance
- Authorise the Project: Checking the Communication Management Approach, etc., can be delegated
- Give Ad Hoc Direction: Impact assessment checking of change requests, etc., can be delegated
In all cases, ultimate accountability rests with the Project Board.
Responsibilities
| Activity | Business Layer | Project Executive | Senior User | Senior Supplier | Project Manager | Team Manager | Project Assurance | Project Support |
|---|---|---|---|---|---|---|---|---|
| Authorise Initiation | I | A/R | — | — | — | — | — | — |
| Authorise the Project | I | A/R | C | C | I | I | C | I |
| Give Ad Hoc Direction | C | A/R¹ | R² | R³ | C/I | I | C | I |
| Authorise a Stage or Exception Plan | I | A/R | C | C | I | I | C | I |
| Authorise Project Closure | I | A/R | C | C | I | I | C | I |
R = Responsible, A = Accountable, C = Consulted, I = Informed
- R¹: Business-related
- R²: User-related
- R³: Supplier-related
Applying Practices to the Process
| Practice | Application to Directing a Project |
|---|---|
| Business Case | Confirm strategic alignment and viability; approve each version of the Business Case. Agree benefits and sustainability tolerances with the business; set stage-level tolerances |
| Organising | Ensure the Board is composed of appropriate authority holders representing business, user, and supplier interests. Approve the PM team structure, all management approaches (commercial, communication, change), and the delivery model |
| Plans | Review whether plans and methods are aligned with strategy and key milestones. Approve the Project Plan, each Stage Plan, and Exception Plans; commit required funding, people, and resources |
| Quality | The Senior User defines quality expectations and acceptance criteria. Bear accountability for Project Assurance; approve all management approaches and Product Descriptions; agree and set quality tolerances |
| Risk | Consider high-level risks before initiation and stage approvals. Approve the Risk Management Approach; continuously confirm the overall risk level is within acceptable limits |
| Issues | Approve the Issue Management Approach and respond to raised issues in a timely manner. Delegate a change authority as needed; decide on the change budget |
| Progress | Approve the Digital and Data Management Approach. Agree time, cost, and scope tolerances with the business; oversee planned progress via Highlight Reports and Exception Reports |
Comparison with Other Frameworks
| Concept | PRINCE2 | PMBOK | PgMP |
|---|---|---|---|
| Governance body | Project Board (DP) | Sponsor / Steering Committee | Programme Governance Board |
| Manage by exception | Delegate to PM within tolerances; escalate when exceeded | Change request management / escalation process | (TBD) |
| Authorisation timing | Required before each stage | Phase gate review | (TBD) |
If you enjoyed this, leave a comment~