Initiating a Project
The purpose of the Initiating a Project process (IP) is to establish a solid foundation for the project. It creates a state in which the business can fully understand the work, cost, and risk involved in delivering the products before committing to major expenditure and resource allocation.
Objectives
Aims to give all parties a shared understanding of the following.
- Justification and value: The reason for undertaking the project, expected benefits, and associated risks (Business Case)
- Scope and products: The scope of work to be undertaken and the specific products to be delivered
- Plans: How, when, and at what cost products will be delivered (Project Plan)
- Roles and responsibilities: Who is involved in decisions and what their responsibilities are
- Quality: How required quality is defined and will be achieved
- Controls: How baselines will be established, progress monitored, and risks and issues managed
- Communication: Who needs information, in what format, and when
- Alignment: How organisational business policies, methods, and guidance are applied to the project
Context
Trigger
Initiated when project initiation is authorised by the Directing a Project process (DP).
Key Implementation Points
- Importance of the process
- True commitment: All parties have a clear understanding of the project’s purpose, need, approach, and responsibilities, and are genuinely committed to the project
- Supporting decision-making: Based on information produced in this process, the Project Board determines whether continuing the project aligns with business objectives
- Approval of management products: The PM creates a set of management products matching the level of control required by the Board, and who reviews and approves them and how is agreed in advance
- Considerations in a commercial environment
- Differing risk and reward: The customer side and supplier side have different reasons for undertaking the project, different acceptable risks, and different expected rewards
- Aligning interests: Foundations must be built in a way that considers both perspectives and satisfies both parties
Activities
| Input | Activity | Output |
|---|---|---|
| Project initiation authorisation (trigger) Project Brief (review) Project Log (confirm) Project Product Description (review) Stage Plan — initiation (review) | Agree the Tailoring Requirements | Tailoring requirements (defined) Management approaches (created) |
| Same as above | Agree the Management Approaches | Each management approach document (9 types) (created) |
| Same as above | Establish the Project Controls | Control design Project Plan (created) |
| Same as above | Prepare the Project Plan | Project Plan (created) Product Register (created/updated) |
| Business Case outline | Prepare the Business Case | Business Case (created) |
| Business Case Project Brief Project Product Description Project Plan Management approaches | Assemble the Project Initiation Documentation | Project Initiation Documentation — PID (created) Project Log (updated) Approaching end of stage (triggers SB) |
| Project Initiation Documentation | Request Project Authorisation | Request for project authorisation (triggers DP) |
Activity Details
Agree the Tailoring Requirements
Standard methods cannot be applied as-is to every project. Management systems must be optimised (tailored) to suit the project’s scale, complexity, risk, and importance.
- Need for tailoring
- Leveraging organisational standards: Where the business already has a standard framework, clarify how to apply it and where to adjust
- Importance of agreement: Agreed adjustments must be documented and agreed among stakeholders
Recommended actions for the PM:
- Review existing policies: Review the Project Brief and understand the tailoring approach already outlined
- Gather lessons: Collect lessons on effective tailoring approaches from similar past projects and external organisations
- Define requirements: Define tailoring requirements as part of the PID, including relevant project controls
- Confirm validity: Consult with Project Assurance to confirm the proposed tailoring suits the Board’s and organisation’s needs
- Obtain approval: Seek the Board’s approval for the tailoring content
Agree the Management Approaches
Management approaches are the rulebook for how the project will be managed and operated. Defining them enables consistent control and allows detailed project planning to proceed.
- Sequencing: Multiple management approach activities can be developed in parallel, but it is recommended that the Communication Management Approach is completed last, as it must cover the communication requirements for all other approaches
- Basis: Developed based on business strategy, organisational standards, user quality expectations in the Product Descriptions, and sustainability requirements
9 management approaches to define:
- Change Management Approach
- Communication Management Approach
- Sustainability Management Approach
- Benefits Management Approach
- Commercial Management Approach
- Quality Management Approach
- Risk Management Approach
- Issue Management Approach
- Digital and Data Management Approach
Recommended actions for the PM:
- Assess impacts: Review the impact of agreed tailoring on each approach
- Understand requirements: Review the Project Brief to identify applicable business strategies, practices, and contractual obligations
- Apply lessons: Gather lessons from similar past cases and reflect them in the approaches
- Confirm risks and issues: Review the Project Log to identify risks related to approach development; update the log as needed
- Verify and obtain approval: Consult with Project Assurance to confirm the proposals meet the Board’s and business’s needs; then seek Project Board approval
Establish the Project Controls
Build mechanisms to manage the project effectively and efficiently in a manner appropriate to its scale, risk, complexity, and importance.
Elements to define and establish for effective control:
- Communication: Frequency and format of reporting between management layers
- Stage setting: Number and boundaries of stages as appropriate decision points
- Issue management: Mechanisms to reliably capture and analyse issues
- Setting tolerances: Scope of delegated authority (time, cost, quality, scope, benefits, risk)
- Monitoring: How to check that delegated authority is being respected
- Escalation: Reporting route when exceptions occur (situations where tolerances are forecast to be exceeded)
Recommended actions for the PM and Project Support:
- Assess methods and environment
- Review delivery approach: Assess the impact of waterfall, agile, hybrid, and other methods on controls
- Reflect tailoring: Confirm the impact of tailoring defined in the PID on controls
- Apply lessons and risks
- Reflect lessons: Gather knowledge from past projects about what level of control worked
- Review risks and issues: Review the log and assess how accumulated risks affect the rigour of management
- Build structure and procedures
- Confirm stage boundaries: Decide and document stage breaks for timely control
- Establish decision-making procedures: Assign optimal decision-making authority at each level and develop specific procedures
- Update roles: Reorganise the team structure as needed; reflect decision-making authority and responsibilities in role descriptions
- Confirm escalation paths: Confirm the reporting route: Team → PM → Board → Business
- Final confirmation and approval
- Consult with Project Assurance to confirm the proposed controls align with the nature of the project and the business’s needs; seek Board approval
Prepare the Project Plan
Before committing to major expenditure and resources, clearly define the project’s duration, cost, resource, and staffing requirements, provide a basis for benefits realisation, and give the Project Board a standard for overall control.
- Co-creation: Plans are not created by the PM alone. Work closely with users and suppliers; use workshops to identify products and dependencies
- Operational considerations: Include not just product completion but also maintenance arrangements and service-level agreements (SLAs) after handover, as needed
Recommended actions for the PM:
- Confirm prerequisites and methods: Review the delivery approach and tailoring requirements; assess their impact on planning
- Define and structure products: Create the Product Breakdown Structure (PBS), Product Descriptions, and Product Flow Diagram to structurally define what will be built; update the Project Product Description as understanding evolves during initiation
- Estimate and secure resources: Select estimation methods and identify tools and control techniques; identify needed people and resources and secure their availability and commitment
- Incorporate management activities: Reflect quality management and project control activities, resources, and timing in the plan; record each product’s information in the Product Register
- Present and obtain approval: Present in the most understandable format for the audience (e.g., Project Board); consult with Project Assurance to confirm it meets business needs; obtain Board approval
Prepare the Business Case
Expand the Business Case outline created during the Starting up a Project stage into a detailed version, based on the latest Project Plan (estimated time and cost) and the Project Log (aggregated risks).
The Business Case is not an activity the PM executes alone — it should be co-created in close collaboration with the Project Executive.
Recommended actions for the PM:
- Gather and elaborate information
- Confirm requirements: Review the Project Brief to understand the required format and content of the Business Case
- Apply lessons: Gather lessons from similar past projects and external cases related to effective Business Case development
- Build detailed version: Aggregate project plan estimates and Project Log risks to create a detailed Business Case
- Manage and confirm validity
- Update the log: Reflect new risks and issues identified during development in the Project Log
- Consult Project Assurance: Confirm that the proposals meet the Project Board’s and Business Layer’s needs
- Seek Board approval: Request Project Board approval of the completed Business Case
Assemble the Project Initiation Documentation
The PID consolidates all information about the project’s what, why, who, how, when, and how much. It is the project’s charter.
- Form agreement: Confirm that key stakeholders have agreed on the project content
- Provide guidance: Serve as an official reference that all project parties can consult at any time
- Basis for authorisation: The final basis for gaining authorisation to execute the project
- Baseline: The approved version of the PID is saved as a baseline and becomes subject to change control
Recommended actions for the PM:
- Incorporate Project Brief information: Revise to the latest state and incorporate
- Include key information: Include or reference the following in the PID:
- Project management team organisational structure and role descriptions
- Full Business Case
- All management approaches (quality, risk, communication, etc.)
- Project Plan
- Summarise tailoring: Summarise how methods have been tailored to suit the project’s nature
- Check compatibility: Confirm there are no inconsistencies between different documents and elements
- Consult Project Assurance: Confirm the PID content meets the Project Board’s and organisation’s needs
- Prepare for the next stage: Assembling the PID triggers the Managing a Stage Boundary (SB) process
Request Project Authorisation
Conclude the initiating process and obtain final approval to proceed to the project execution phase.
Recommended actions for the PM:
- Submit final documents: Present the final version of the Business Case, PID, and Project Plan to the Project Board
- Formally request execution authority: Request formal authority to deliver the project products and implement the plan
- Secure resources: Formally request the Project Board’s authority to secure and use the people and resources needed to deliver the products
Applying the Process
General Considerations
The scale and level of detail of the process should be appropriately tailored to the project’s complexity and risk.
- Flexible activities: Each activity in the initiating process can be combined, split, or run in parallel as the project dictates
- Progressive elaboration of tailoring: Excessive detail is not required from the outset. Start simply and elaborate as the situation becomes clearer
- Handling uncertainty: For projects too complex to fully define outputs immediately, incorporate investigation stages into the lifecycle
Tailoring Roles
- PM accountability: The PM bears accountability for creating management products; the PM can delegate tasks to appropriate people while retaining accountability
- Using support organisations: Existing organisations such as Project Support or a Programme Office (PMO) can support the PM in creating supplementary products
- Maintaining accountability: Regardless of who assists with practical work, the PM must remain the single point of accountability to the Project Executive for how the project is managed
Responsibilities
| Activity | Business Layer | Project Executive | Senior User | Senior Supplier | Project Manager | Team Manager | Project Assurance | Project Support |
|---|---|---|---|---|---|---|---|---|
| Agree the Tailoring Requirements | — | A | C | C | R | C | C | I |
| Agree the Management Approaches | — | A | C | C | R | C | C | I |
| Establish the Project Controls | — | A | C | C | R | C | C | I |
| Prepare the Project Plan | — | A | C | C | R | C | C | C |
| Prepare the Business Case | — | A | C | C | R | C | C | I |
| Assemble the Project Initiation Documentation | — | C | C | C | A | C | C | R |
| Request Project Authorisation | I | A | C | C | R | I | C | I |
R = Responsible, A = Accountable, C = Consulted, I = Informed
Applying Practices to the Process
| Practice | Application to Initiating a Project |
|---|---|
| Business Case | Develop the outline into a full Business Case. Develop the Benefits Management Approach and Sustainability Management Approach to strengthen investment justification |
| Organising | Update the team structure to reflect delegation details; appoint and onboard remaining members. Create the Communication, Change, and Commercial Management Approaches; use WBS to determine work structure and external procurement |
| Plans | Create the Project Plan using product-based planning techniques (PBS, Product Flow Diagram); define the required stage structure |
| Quality | Create Product Descriptions, the Quality Management Approach, the Product Register, and the Quality Register; update the Project Product Description as needed |
| Risk | Create the Risk Management Approach and Risk Register; assess and record identified risks; set a risk budget as needed |
| Issues | Create the Issue Management Approach and Issue Register; assess and record identified issues; set a change budget as needed |
| Progress | Create the Digital and Data Management Approach. Establish controls across all approaches as the foundation for progress management; use Highlight Reports for reporting during this stage |
Comparison with Other Frameworks
| Concept | PRINCE2 | PMBOK | PgMP |
|---|---|---|---|
| Initiating process | Initiating a Project (IP) | Develop Project Management Plan | (TBD) |
| Central document | Project Initiation Documentation (PID) | Project Management Plan | (TBD) |
| Management approaches | 9 management approaches | Various management plans (risk, quality, communication, etc.) | (TBD) |
| Baseline management | PID baselining and change control | Change Management Plan | (TBD) |
If you enjoyed this, leave a comment~