12.1 Initiating a Project (IP) Process & Assembling the PID

Initiating a Project (IP) Process & Assembling the PID in PRINCE2 7

Practitioner Core Mandate: In professional project management, enthusiasm is never a substitute for preparation. Committing organizational capital, human resources, and reputational equity to delivery before understanding the full scope of work, technical approach, risk profile, and commercial commitments is the leading cause of catastrophic project failure. The Initiating a Project (IP) process ensures that a project does not rush blindly from pre-project feasibility into physical delivery. It establishes the solid foundations of the project, assembling the definitive Project Initiation Documentation (PID) that serves as the baseline contract between the Project Manager and the Project Board.

---

1. Purpose, Objectives & Context of Initiating a Project (IP)

The Fundamental Purpose

The purpose of the Initiating a Project (IP) process is to establish solid foundations for the project, enabling the organization to understand the work that needs to be done to deliver the project's products before committing to a significant financial and operational investment.

Core Objectives

To achieve this purpose, the IP process must establish a shared, unambiguous understanding among all key stakeholders regarding:

• The Business Justification: Why the project is being undertaken, the measurable business benefits expected, the quantified dis-benefits, and the total investment cost.
• The Scope & Products: What is included in the project boundaries, what deliverables must be produced, and what acceptance criteria must be satisfied.
• The Delivery Strategy & Schedule: How and when the project products will be generated, at what cost, and through which technical approaches.
• The Governance Architecture: Who will make decisions, who holds ultimate accountability, and how the four levels of management will interact.
• Baseline Control Frameworks: How quality, risks, issues/changes, communications, digital/data assets, commercial agreements, and sustainability targets will be identified, monitored, and managed.
• Progress Measurement: How project baselines will be established, tracked, and controlled across the seven project performance targets (cost, time, quality, scope, benefits, risk, and sustainability).

                  THE INITIATION BRIDGE IN THE PROJECT LIFECYCLE

   PRE-PROJECT               INITIATION STAGE                  DELIVERY STAGES

   ┌───────────────┐         ┌────────────────────────┐         ┌───────────────────────┐
   │  STARTING UP  │         │  INITIATING A PROJECT  │         │ CONTROLLING A STAGE   │
   │ A PROJECT(SU) │────────►│         (IP)           │────────►│         (CS)          │
   └───────┬───────┘         └───────────┬────────────┘         └───────────────────────┘
           │                             │
           ▼                             ▼
   [Project Brief &              [Project Initiation Documentation
    Stage 1 Plan]                 (PID) & Stage 2 Plan]
           │                             │
           ▼                             ▼
   Board: "Worth initiating?"    Board: "Authorize the project?"

Principles Operationalized in IP

The Initiating a Project process puts multiple core PRINCE2 principles into direct operational practice:

• Continued Business Justification: IP refines the tentative outline Business Case from SU into a comprehensive, robust, and investment-appraised Business Case supported by a Benefits Management Approach.
• Focus on Products: IP creates the overarching Project Plan using product-based planning, culminating in detailed Product Descriptions for all major deliverables.
• Defined Roles and Responsibilities: IP establishes the complete project management team structure, including role descriptions and delegated limits of authority.
• Manage by Stages: IP forms the entirety of the project's first management stage (the Initiation Stage), separating planning expenditure from physical delivery commitment.
• Manage by Exception: IP establishes baseline tolerances across all seven performance targets, defining the boundaries of autonomous decision-making for the Project Manager.
• Tailoring to Suit the Project Context: IP defines the degree of governance formality, digital tooling, and commercial models suitable for the project's scale, environment, and complexity.

---

2. The Seven Activities of Initiating a Project (IP)

In PRINCE2 7, the project manager leads the execution of the IP process, supported by project assurance and team specialists. Table 15.1 names seven activities (15.4.1 to 15.4.7). The process is not a linear administrative checklist; several activities run in parallel and culminate in the assembly of the PID.

┌─────────────────────────────────────────────────────────────────────────────┐
│               THE 7 ACTIVITIES OF INITIATING A PROJECT (IP)                 │
├─────────────────────────────────────────────────────────────────────────────┤
│ 15.4.1 AGREE TAILORING REQUIREMENTS  ← NEW as a named activity in v7        │
│    • Review the project brief for the outlined tailoring approach.          │
│    • Seek lessons on tailoring from similar projects inside and outside.    │
│    • Document agreed tailoring (and related controls) in the PID.           │
├─────────────────────────────────────────────────────────────────────────────┤
│ 15.4.2 AGREE THE MANAGEMENT APPROACHES:                                     │
│    • Risk management approach                                               │
│    • Issue management approach (issue handling and change control)          │
│    • Quality management approach                                            │
│    • Communication management approach and change management approach       │
│    • Digital and data management approach (NEW in v7)                       │
│    • Commercial management approach and sustainability management approach  │
│    • Benefits management approach                                           │
├─────────────────────────────────────────────────────────────────────────────┤
│ 15.4.3 ESTABLISH PROJECT CONTROLS:                                          │
│    • Tolerances across the seven performance targets, reporting cycles,     │
│      management stage structure, and escalation routes                      │
│    • The project log (daily log, issue register, lessons log, product       │
│      register, quality register, risk register) is updated, not re-created  │
├─────────────────────────────────────────────────────────────────────────────┤
│ 15.4.4 PREPARE THE PROJECT PLAN:                                            │
│    • Create the Project Plan using the PRINCE2 planning technique           │
├─────────────────────────────────────────────────────────────────────────────┤
│ 15.4.5 PREPARE THE FULL BUSINESS CASE:                                      │
│    • Develop the outline business case into the full Business Case          │
├─────────────────────────────────────────────────────────────────────────────┤
│ 15.4.6 ASSEMBLE THE PROJECT INITIATION DOCUMENTATION (PID):                 │
│    • Consolidate approaches, controls, team structure, plan, business case  │
├─────────────────────────────────────────────────────────────────────────────┤
│ 15.4.7 REQUEST PROJECT AUTHORIZATION:                                       │
│    • Output: project authorization request, which triggers Directing a      │
│      Project (activity 14.4.2 'authorize the project')                      │
└─────────────────────────────────────────────────────────────────────────────┘

[!EXAM WATCHPOINT: TAILORING IS AN ACTIVITY, NOT AN AFTERTHOUGHT] PRINCE2 7 promotes tailoring to the first IP activity. An exam option that has the project manager assembling approaches and plans before any tailoring has been agreed and documented in the PID is describing the wrong sequence.

---

3. The Management Approaches in PRINCE2 7: Foundations for Delivery

A critical evolution in PRINCE2 7 is the comprehensive expansion of management approaches. Previous editions focused on four core strategies (Risk, Quality, Change, and Communication). PRINCE2 7 modernizes this suite by formally incorporating Digital and Data Management, alongside explicit Commercial and Sustainability frameworks, reflecting contemporary project realities.

3.1 Quality Management Approach

The Quality Management Approach defines how quality expectations and criteria will be achieved, controlled, and assured throughout the project lifecycle:

• Details user's quality expectations, acceptance criteria, and project quality tolerances.
• Identifies the specific quality standards, regulatory benchmarks, and corporate methodologies to be enforced.
• Specifies the quality control techniques to be used (e.g., formal quality reviews, automated testing, physical inspections, peer reviews).
• Defines the roles and responsibilities for quality activities (e.g., who produces, who reviews, who approves).
• Sets up the Quality Register, which records all planned and completed quality activities.

3.2 Issue Management Approach

The Issue Management Approach defines how changes, non-conformances, and unexpected operational problems will be managed. PRINCE2 7 states that it comprises baselines, issue resolution, change control, delegating authority for changes, and the change budget:

• Defines the 5-step issue management technique (Capture, Assess, Recommend, Decide, Implement).
• Establishes the five Version 7 issue categories: problem or concern, event external to the project, business opportunity, request for change, and off-specification.
• Describes what is subject to change control: the level at which products are baselined, and how a new version is created each time a change is approved and implemented. Product status and versions are tracked in the project log: product register.
• Do not confuse this with the change management approach, which in PRINCE2 7 belongs to the People element and covers organizational change — preparing the people affected by the project to adopt its outputs.
• Defines the composition, delegated limits, and operating rules of the Change Authority.
• Defines the rules governing the allocation and drawdown of the Change Budget (if established).

3.3 Risk Management Approach

The Risk Management Approach details the discipline used to identify, assess, control, and communicate threats and opportunities:

• Defines the 5-step Risk Management procedure (Identify, Assess, Plan, Implement, Communicate).
• Documents organizational risk appetite, risk capacity, and explicit project risk tolerances.
• Defines risk scoring matrices (probability and impact grids) and proximity categories.
• Establishes risk response strategies (for threats: avoid, reduce, transfer, share, accept, contingency; for opportunities: exploit, enhance, share, reject).
• Defines the rules governing the use of the Risk Budget.
• Sets up the Risk Register for tracking active risks across delivery stages.

3.4 Communication Management Approach

The Communication Management Approach governs the flow of information to, from, and between internal and external stakeholders:

• Identifies and maps all project stakeholders, analyzing their interests, power, influence, and information requirements.
• Defines the communication channels, formats, media, and frequency of updates (e.g., weekly Highlight Reports, executive dashboards, community newsletters).
• Establishes feedback mechanisms to verify whether messages have been understood and acted upon.
• Defines responsibilities for communicating with regulatory bodies, media, and senior the business layer.

3.5 Digital and Data Management Approach (NEW in PRINCE2 7)

Introduced in PRINCE2 7, the Digital and Data Management Approach reflects the reality that modern projects operate in digital environments and generate vast informational assets. This approach defines:

• Data Governance & Custodianship: Rules for data ownership, data classification (confidential, internal, public), data quality standards, and master data management.
• Digital Toolchains & Collaborative Platforms: Software applications, project management information systems (PMIS), agile workflow boards (Jira, Azure DevOps), version control repositories (Git), and virtual collaboration spaces utilized by the project team.
• Security & Privacy Compliance: Protocols for cybersecurity, access controls, data encryption at rest and in transit, and statutory compliance with privacy legislation (such as GDPR, HIPAA, or local data protection acts).
• Information Lifecycle & Asset Protection: How digital products, models, codebases, and architectural schemas are archived, protected against loss or ransomware, and decommissioned.
• Artificial Intelligence & Automation Guidelines: Ethical guardrails, algorithmic transparency, validation rules, and acceptable-use policies when leveraging AI or automated generative tools within project workflows.

┌─────────────────────────────────────────────────────────────────────────────┐
│             THE DIGITAL & DATA MANAGEMENT APPROACH IN PRINCE2 7             │
├─────────────────────────────────────────────────────────────────────────────┤
│ 1. DATA GOVERNANCE: Master data standards, ownership, retention schedules   │
│ 2. DIGITAL TOOLING: PMIS platforms, agile backlog software, code repos      │
│ 3. CYBER & PRIVACY: Access controls, encryption, regulatory data compliance │
│ 4. ASSET MANAGEMENT: Intellectual property, model storage, archival rules   │
│ 5. AI & AUTOMATION: Validation protocols, algorithmic policies, security    │
└─────────────────────────────────────────────────────────────────────────────┘

3.6 Commercial Management Approach

In multi-organization and contractor-dependent environments, the Commercial Management Approach outlines how contractual and supplier interfaces will be governed:

• Outlines the procurement strategy: competitive tendering, direct awards, framework agreements, or public-private partnerships.
• Defines contracting models: fixed-price lump sum, time-and-materials, target-cost with pain/gain share, or cost-reimbursable.
• Outlines supplier relationship management, performance monitoring mechanisms, and commercial escalation routes.
• Establishes dispute resolution procedures and intellectual property ownership boundaries between customer and suppliers.

3.7 Sustainability Management Approach

With sustainability elevated to one of the seven core project performance targets in PRINCE2 7, the Sustainability Management Approach ensures that environmental, social, and economic responsibility is woven into project execution:

• Defines sustainability baselines, targets, and tolerances (e.g., carbon emissions ceilings, waste diversion percentages, embodied carbon limits, local labor hiring quotas).
• Specifies environmental measurement frameworks (e.g., GHG Protocol, Life Cycle Assessments, ESG metrics).
• Sets out reporting frequencies for sustainability performance indicators alongside standard cost/schedule tracking.
• Details circular economy practices, material reuse requirements, and ethical supply-chain sourcing mandates.

---

4. Setting Up Controls, Baseline Planning & Refining Business Justification

Beyond drafting management approaches, the Project Manager must assemble three foundational delivery instruments: project controls, the Project Plan, and the refined Business Case.

4.1 Setting Up Project Controls

Project controls define how project governance is operationalized day to day. They prevent project drift by defining decision gates, reporting tempos, and delegation thresholds:

• Event-Driven Controls: Actions triggered by a specific occurrence (e.g., Project Initiation authorization, Stage Boundary assessments, Exception Reports when tolerances are breached, Work Package authorisations).
• Time-Driven Controls: Regular, rhythm-based interactions that occur on a predetermined schedule (e.g., weekly Checkpoint Reports from Team Managers to the Project Manager, bi-weekly or monthly Highlight Reports from the Project Manager to the Project Board).
• Management Stages Structure: Deciding the number and duration of delivery stages based on technical risk, decision gates, organizational planning horizons, and commercial milestones.
• Seven-Target Tolerances: Setting baseline tolerance thresholds for Cost, Time, Quality, Scope, Benefits, Risk, and Sustainability at the project and stage levels.

┌─────────────────────────────────────────────────────────────────────────────┐
│                     THE SEVEN PROJECT PERFORMANCE TARGETS                   │
├─────────────────────────────────────────────────────────────────────────────┤
│ 1. COST: Overall financial budget and allowable deviation (e.g., ±5%)       │
│ 2. TIME: Overall delivery schedule and milestone tolerances (e.g., ±2 weeks)│
│ 3. QUALITY: Performance ranges and defect limits (e.g., 99.9% uptime ±0.05%)│
│ 4. SCOPE: Mandatory core vs. flexed deliverables (e.g., MoSCoW criteria)    │
│ 5. BENEFITS: Expected ROI or savings variance (e.g., minimum $1.2M savings) │
│ 6. RISK: Aggregated risk exposure threshold (e.g., max $150k exposure)      │
│ 7. SUSTAINABILITY: Carbon and waste ceilings (e.g., max 50t CO2e ±5%)       │
└─────────────────────────────────────────────────────────────────────────────┘

4.2 Creating the Project Plan

The Project Manager develops the overall Project Plan using the Product-Based Planning technique:

1. Identifies Products: Creates the Product Breakdown Structure (PBS) for the entire project, defining all major management and specialist deliverables.
2. Writes Product Descriptions: Drafts Product Descriptions for key project deliverables, defining their purpose, components, quality specifications, and quality tolerance limits.
3. Maps Dependencies: Constructs the Product Flow Diagram (PFD) to show sequence and interdependencies.
4. Estimates & Schedules: Quantifies effort, duration, resource requirements, and costs; identifies the critical path and resource bottlenecks.
5. Establishes Stages: Divides delivery into distinct management stages, ensuring that planning horizons remain realistic.

4.3 Refining the Business Case & Creating the Benefits Management Approach

During Starting Up a Project (SU), only an outline Business Case was created to determine if the project was worth initiating. During IP, the Business Case must be refined into a definitive, quantified investment appraisal:

• Detailed Cost-Benefit Analysis: Compares capital expenditures, operational maintenance costs, and quantified tangible benefits over the product's operational lifecycle.
• Quantifies Dis-Benefits: Explicitly documents measurable negative outcomes resulting from the project (e.g., temporary lost revenue during retail store closures, initial productivity drops during new software adoption).
• Risk Profile Integration: Factors in the financial impact of active threats and mitigation costs.
• Creates the Benefits Management Approach: A separate management product detailing:
  • Which specific benefits will be measured;
  • Who is accountable for realizing each benefit (typically designated Senior User representatives or operational business managers);
  • How and when benefit realization will be measured (including post-project operational reviews);
  • Baseline measurements against which future performance improvements will be evaluated.

---

5. Assembling and Baselining the Project Initiation Documentation (PID)

All of the outputs generated during Initiating a Project are consolidated into a single master governance document: the Project Initiation Documentation (PID).

┌─────────────────────────────────────────────────────────────────────────────┐
│             ANATOMY OF THE PROJECT INITIATION DOCUMENTATION (PID)           │
├─────────────────────────────────────────────────────────────────────────────┤
│ 1. PROJECT DEFINITION                                                       │
│    • Project background, objectives, scope boundaries, and exclusions       │
│    • Project Product Description (user's quality expectations & criteria)   │
├─────────────────────────────────────────────────────────────────────────────┤
│ 2. PROJECT APPROACH                                                         │
│    • Selected technical and operational delivery method (in-house, bespoke, │
│      commercial-off-the-shelf, agile, predictive waterfall, hybrid)         │
├─────────────────────────────────────────────────────────────────────────────┤
│ 3. BUSINESS CASE & BENEFITS MANAGEMENT APPROACH                             │
│    • Investment appraisal, ROI, payback period, risk profile, benefits plan │
├─────────────────────────────────────────────────────────────────────────────┤
│ 4. THE SEVEN MANAGEMENT APPROACHES                                          │
│    • Quality, Change, Risk, Communication, Digital/Data, Commercial,        │
│      and Sustainability Management Approaches                               │
├─────────────────────────────────────────────────────────────────────────────┤
│ 5. PROJECT MANAGEMENT TEAM STRUCTURE & ROLE DESCRIPTIONS                    │
│    • Organization chart, named role appointments, and job descriptions      │
├─────────────────────────────────────────────────────────────────────────────┤
│ 6. PROJECT CONTROLS                                                         │
│    • Stage structure, decision gates, tolerance limits across 7 targets,    │
│      Highlight/Checkpoint reporting tempos, and escalation pathways         │
├─────────────────────────────────────────────────────────────────────────────┤
│ 7. PROJECT PLAN                                                             │
│    • Product Breakdown Structure, schedule, budget, and major milestones    │
└─────────────────────────────────────────────────────────────────────────────┘

The PID as a Baseline Governance Contract

The PID is not a bureaucratic academic report; it is the formal baseline contract between the Project Manager and the Project Board:

• The Single Source of Truth: It provides a definitive point of reference so that everyone involved understands what the project will achieve, how it will be governed, and how success will be measured.
• The Performance Baseline: During delivery, the Project Board evaluates progress by comparing actual results against the baselines established in the PID.
• Configuration Control: Once approved by the Project Board (in the Directing a Project process via "Authorize the project"), the PID is baselined. It cannot be casually altered. Any subsequent changes to project scope, approaches, budget, or major milestones must pass through formal change control under the Change Management Approach.

---

6. Comparative Analysis: Starting Up a Project (SU) vs. Initiating a Project (IP)

A common area of confusion on the PRINCE2 Practitioner exam is distinguishing between the pre-project SU process and the project-lifecycle IP process:

---

7. Practical Scenario Evaluations

Scenario A: The Agile Bypass Trap

A software development agency is commissioned by a retail bank to build a customer self-service loan application portal. The agency's Scrum Master convinces the bank's Project Executive that because they will be working in 2-week agile sprints, creating a PID and formal management approaches in Initiating a Project is 'wasteful waterfall bureaucracy.' The team immediately begins writing software code in Sprint 1 without defining quality specifications, commercial payment milestones, data privacy policies, or baseline tolerances.

Practitioner Evaluation:

• Governance Flaw: Total abandonment of the Manage by Stages and Continued Business Justification principles. In PRINCE2, agile delivery methods (Scrum, Kanban) are delivery techniques utilized inside Managing Product Delivery (MP); they do not eliminate project-level governance.
• Consequences: Without a PID, the project lacks agreed acceptance criteria, has no established data protection protocols (exposing the bank to catastrophic regulatory fines under financial privacy laws), lacks clear scope boundaries, and has no agreed tolerances.
• Correct PRINCE2 Action: The team must execute the Initiating a Project process. In an agile context, the PID is tailored to be lean and dynamic—the Project Plan may feature release roadmaps and burn-up charts, the Digital and Data Management Approach defines Git branching and CI/CD pipelines, and the Quality Management Approach defines the "Definition of Done". However, establishing a baselined governance foundation remains non-negotiable.

Scenario B: Overlooking the Digital and Data Management Approach

During the initiation stage of a regional healthcare integration project, the Project Manager prepares the Risk, Change, Quality, and Communication approaches, completely omitting the Digital and Data Management Approach. Three months into delivery, the hospital trust's legal department halts all work because patient diagnostic images are being uploaded to unencrypted commercial cloud storage servers, and proprietary software libraries are being utilized without commercial licensing verification.

Practitioner Evaluation:

• Governance Flaw: Failure to prepare the Digital and Data Management Approach mandated by PRINCE2 7.
• Consequences: The project suffered severe delivery delays, legal liability, and reputational damage due to unmanaged data flows, inadequate cybersecurity controls, and unauthorized toolchains.
• Correct PRINCE2 Action: The Project Manager must prepare the Digital and Data Management Approach during IP, collaborating with corporate IT security, data privacy officers, and supplier technical leads. The approach must specify approved cloud repositories, encryption standards, data handling permissions, and software licensing compliance mechanisms before any technical deliverables are developed.

Scenario C: Confusing Outline with Baselined Business Case

On a renewable energy wind turbine project, the Project Manager assembles the PID by simply copy-pasting the outline Business Case and rough revenue estimates written in the Project Brief during Starting Up a Project. The PM argues that because the Project Board approved initiation based on those numbers, re-running the financial investment appraisal in IP is unnecessary rework.

Practitioner Evaluation:

• Governance Flaw: The PM has failed to execute the activity Refine the Business Case in IP.
• Consequences: The outline Business Case in SU was an educated guess designed solely to justify the small cost of the initiation stage. Assembling the Project Plan and technical approaches in IP uncovers real supplier quotes, soil survey complexities, and grid connection fees that significantly increase total capital costs. By failing to refine the Business Case, the PM presents an inaccurate, misleading document to the Project Board.
• Correct PRINCE2 Action: During IP, the PM must update the Business Case using the detailed costings and timelines derived from the newly created Project Plan. The PM must perform sensitivity analysis, quantify dis-benefits, integrate active risk mitigation costs, and produce the Benefits Management Approach to ensure the project remains viable and justifiable before the Board commits millions in delivery capital.

---

8. Responsibilities in IP: The RACI Chart and Practice Application

Table 15.2 — RACI for initiating a project

Key: A Accountable · R Responsible · C Consulted · I Informed. Empty cells mean the role takes no part in that activity.

The one row that breaks the pattern

Six of the seven IP activities follow the house style — project executive A, project manager R. Assemble the project initiation documentation inverts it: the project manager becomes Accountable, project support becomes Responsible, and the project executive drops to Consulted. The logic is that assembling the PID is a compilation task; the project manager answers for the document's completeness while project support does the assembly. This single cell is a favourite matching-question target.

Note also that the business layer appears only once in IP, as Informed on request project authorization. Initiation is a project-board-governed stage, not a business-layer one.

How the practices are applied in IP (table 15.3)

Table 15.3 is unusually concrete, and it is where several management products are created:

• Business case: the outline business case becomes the full business case; the benefits management approach and sustainability management approach are developed.
• Organizing: the project management team structure gains detail on delegated authority; a work breakdown structure is considered, based on the project plan, to organize work into teams and identify externally supplied elements; the communication, change, and commercial management approaches are created.
• Plans: the project product description drives a product breakdown structure and product flow diagram, which produce the project plan and define the project's stages. The product register is created.
• Quality: product descriptions are created and the project product description updated if needed; their quality specifications feed the quality management approach. The quality register is created.
• Risk: the risk management approach is created; the risk register is created; risks from the business case and project plan are logged and assessed; a risk budget is considered.
• Issues: the issue management approach is created; the issue register is created; a change budget is considered.
• Progress: project controls, tolerances, and reporting arrangements are established.

---

9. Practitioner Exam Pitfalls & Governance Traps

• Trap 1: Believing Specialist Products are Built in the Initiation Stage: The initiation stage is dedicated exclusively to project planning, foundation-setting, and governance baselining. Specialist deliverables (e.g., coding software, pouring concrete, assembling machinery) are strictly delivered during subsequent delivery stages under Controlling a Stage and Managing Product Delivery.
• Trap 2: Assuming the Project Manager Authorizes the PID: The Project Manager merely assembles the PID. Only the Project Board has the authority to review, approve, and baseline the PID (executing the activity Authorize the project within Directing a Project).
• Trap 3: Treating the PID as a Rigid, Unchangeable Relic: Baselining the PID does not mean it is frozen in stone forever. If major changes, scope shifts, or project-level exceptions occur during delivery, the PID is formally reviewed and re-baselined via formal change control and Project Board authorization.
• Trap 4: Confusing the Project Plan with the Stage Plan: In IP, the Project Manager produces two distinct plans: the Project Plan (covering the entire project from initiation to closure at a high level) and the Stage Plan for Stage 2 (covering the immediate next delivery stage at a granular, day-to-day operational level).
• Trap 5: Neglecting the Benefits Management Approach in the PID Package: The Benefits Management Approach is created during IP alongside the Business Case. While it is presented to the Project Board alongside the PID, it exists as an independent management product that outlives the project, guiding post-project operational benefits realization.