Project Delivery · Project Control Methods
Initiating a Project and Establishing Control Baselines
Initiation converts an approved project idea into a controlled delivery proposition. It defines what will be delivered, why it remains worthwhile, how and by whom it will be delivered, how quality, risk, change and communication will be controlled, how progress and benefits will be measured, and which authority and tolerance govern the first delivery stage.
Executive summary
What this guide enables
Initiation converts an approved project idea into a controlled delivery proposition. It defines what will be delivered, why it remains worthwhile, how and by whom it will be delivered, how quality, risk, change and communication will be controlled, how progress and benefits will be measured, and which authority and tolerance govern the first delivery stage.
Learning outcomes
- Explain the purpose and lifecycle position of initiating a project and establishing control baselines.
- Recognise the entry triggers, control evidence and completion conditions.
- Assign activities and decisions to the correct governance, management and delivery roles.
- Tailor the process without weakening accountability, product focus or exception control.
Control guidance
Purpose and lifecycle position
The purpose is to establish solid foundations so the organisation understands the work needed to deliver the products before making a significant commitment. Initiation turns outline assumptions into an approved project baseline, exposes uncertainty and gives governance a defensible start-or-stop decision.
Lifecycle position: This is the first management stage, authorised after startup and completed before the governing body commits to full project delivery. Initiation is the period of greatest leverage: a change to scope, approach or governance is normally cheaper before contracts, detailed design and construction create commitment. It should be thorough enough for the decision but proportionate to project exposure.
Control depends on the resulting decision and evidence, not on reproducing a particular flowchart. The process begins on a recognised trigger, uses current controlled inputs and ends with an explicit status, product, authorisation or request.
Control guidance
Entry triggers and prerequisites
Treat the trigger as the reason to act and the prerequisite as evidence needed to act safely. Confirm authority, applicable tolerance, status date and current product or plan versions; expose missing inputs rather than silently assuming them.
Initiation authorised
The governing body approves the project brief and initiation-stage plan.
Startup products available
Outline case, product definition, approach, team and lessons provide a foundation.
Management resources committed
The project manager and contributors can prepare plans and approaches.
Project decision scheduled
Governance knows what evidence and assurance it needs to authorise delivery.
Control guidance
Activity sequence
Activities may overlap or be combined, but each outcome must remain visible: what was considered, who acted or decided, and which authorised position now applies.
- 1
Agree tailoring requirements
Document how lifecycle, roles, stages, controls, records, terminology and tools will suit the context and external obligations.
- 2
Prepare the risk management approach
Define context, appetite, scales, procedure, ownership, reporting and escalation, then establish initial risk records.
- 3
Prepare the change and configuration approach
Define baselines, product identification, issue classification, authority, budget, status accounting and verification.
- 4
Prepare the quality management approach
Define standards, product criteria, quality methods, roles, records, assurance and acceptance controls.
- 5
Prepare the communication approach
Identify stakeholders, information needs, frequency, methods, confidentiality, feedback and engagement ownership.
- 6
Set up project controls
Define tolerances, reports, work authorisation, stage gates, issue and exception routes, data dates and decision response times.
- 7
Create the project plan
Develop the product-based whole-project plan, stages, resources, cost, milestones, dependencies, acceptance and control events.
- 8
Refine the business case and benefits approach
Update options, costs, timescales, benefits, dis-benefits, risk, affordability, ownership and review schedule.
- 9
Assemble the initiation baseline
Integrate or reference all approved foundations in a controlled package and request project and first-stage authorisation.
Control guidance
Management products and evidence
The record may be a document, workflow item, database entry or integrated view. Give every item a purpose, owner, status, update trigger and audience; protect baselines from silent change and ensure reports trace back to source evidence.
| Management product or evidence | Control purpose |
|---|---|
| Tailoring record | Explains the project's selected control operating model. |
| Risk management approach and register | Establish uncertainty control and current exposure. |
| Change and configuration approach | Protects baselines and defines issue decisions. |
| Quality management approach and register | Defines fitness, verification, approval and evidence. |
| Communication management approach | Defines project information and stakeholder interfaces. |
| Project controls | Set reporting, work authorisation, tolerance and escalation. |
| Project plan | Provides the overall delivery and stage-control baseline. |
| Detailed business case and benefits approach | Supports investment and value decisions. |
| Project initiation documentation | Assembles the authoritative baseline for project authorisation. |
Control guidance
Roles, decision rights and assurance
Keep direction, day-to-day management, product delivery and independent challenge distinguishable. If compatible duties are combined, map responsibilities and add an independent decision or review wherever self-authorisation, self-acceptance or self-assurance would otherwise result.
| Role or level | Core responsibility | Decision or evidence |
|---|---|---|
| Governing body | Defines assurance needs and approves the project baseline | Authorises or rejects delivery |
| Business lead | Owns detailed justification and funding | Recommends investment |
| Project manager | Coordinates approaches, plan, controls and baseline | Submits authorisation request |
| User and operational roles | Define acceptance, communication, transition and benefits | Confirm need and readiness assumptions |
| Supplier and technical roles | Define feasibility, resources, methods and quality | Confirm delivery credibility |
| Assurance and support | Challenge evidence and establish controlled systems | Report readiness and findings |
Control guidance
Interfaces and control logic
Map incoming evidence, outgoing authority and response deadlines so products or decisions do not stall between roles. Forecast breaches move to the tolerance-setting authority; baseline impacts follow change control; weakened justification returns to the accountable business authority.
- The initiation baseline is a controlled set of information, not necessarily one large document.
- Every management approach should connect roles, procedure, records, reports and escalation.
- The first delivery-stage plan must fit the project plan and authorised business case.
- Unresolved assumptions and risks should be visible to governance, with owners and decision triggers.
| Control question | Evidence to inspect | Decision or response |
|---|---|---|
| Is the input authoritative? | Version, status, owner, approval and data date | Use, clarify or reject the input |
| Is action within delegated authority? | Plan, tolerance, budget, role and external constraints | Act locally or escalate |
| Has the activity produced a usable output? | Defined completion, assurance, decision and conditions | Pass forward or return for action |
| Has the overall forecast changed? | Integrated impact and remaining-work evidence | Update plans, business case, risks and reports |
Control guidance
Tailoring the process
A small project can combine the approaches, plan and business case into one concise controlled baseline. A complex project may create separate plans, registers and assurance reviews. Iterative projects can define release and increment controls inside stage tolerance. Initiation can be repeated or refreshed for a major tranche when the original baseline no longer provides sufficient decision confidence.
Record the selected form, role mapping and evidence route in the initiation baseline. Revisit it when risk, suppliers, obligations, pace or decision lead time changes; tailoring must preserve purpose and authority even when format and frequency change.
Tailoring and readiness check
- The trigger and decision authority are explicit
- Inputs are current, approved where required and linked to their source
- Products and activities have one accountable owner
- Forecast impact covers time, cost, quality, scope, benefits and risk
- Issues, decisions and assumptions are recorded at the appropriate level
- Interfaces with the preceding and following processes are controlled
- Tailoring preserves the process purpose and required evidence
- The completion decision and any conditions have a traceable record
Control guidance
Worked application
Refusing false certainty during initiation
Situation: A sponsor requests a fixed completion date before supplier capacity, user acceptance and a critical interface have been validated.
- The project manager records the date as a constraint or target, not an evidence-backed forecast.
- Product and dependency planning identify which assumptions determine feasibility and what initiation work can validate them.
- The business case includes scenario ranges and the consequences of compression; risk responses and a staged commitment are proposed.
- Governance authorises the first delivery stage with explicit interface and supplier decision gates instead of presenting unsupported precision as a baseline.
Control outcome: The baseline is ambitious but honest, with uncertainty converted into controlled products, decisions and tolerances.
Control guidance
Failure modes, recovery and common questions
| Failure mode | Consequence | Control response |
|---|---|---|
| Template completion without integration | Approaches conflict and evidence is duplicated | Map interfaces and assemble one authoritative control model |
| Plan before product definition | Scope and acceptance remain hidden | Use product descriptions and flow before detailed scheduling |
| Unsupported fixed forecast | Governance receives false confidence | Record assumptions, ranges, validation work and decision triggers |
| Unapproved initiation drift | Delivery starts before project authority | Keep work inside the initiation-stage plan until authorisation |
Is the initiation baseline one document?
It may be one document or an integrated controlled set. Authority and version relationships must be clear.
Must every uncertainty be resolved?
No. Material uncertainty should be understood, owned, controlled and acceptable for the next commitment.
Can delivery prototypes occur in initiation?
Yes when explicitly authorised as initiation products and not mistaken for full delivery approval.
Who approves the baseline?
The governing body within its project authority, informed by business, user, supplier and assurance evidence.