Project planning
Initiating a Project
Build a practical project baseline that can be controlled, reported, and adapted without excessive bureaucracy.
What this helps you do
Convert the approved idea into an operational baseline covering scope, products, controls, tolerances, and governance rhythm.
Use this when
- After startup approval to proceed into formal project control.
- Before significant delivery spend or supplier mobilisation.
- When governance asks for a clear baseline for accountability.
What good looks like
- Scope boundaries and acceptance criteria are explicit.
- Stage structure and control cadence are realistic and usable.
- Tolerances are set and understood by sponsor and PM.
- RAID, decision, and reporting controls are active from day one.
- The baseline is concise enough to use weekly, not shelfware.
Minimum viable version
- PID Lite with outcome, scope, stage approach, controls, and approval record.
- Project product description or equivalent acceptance definition.
- Stage plan for the first stage with milestones and dependencies.
- Live RAID and decision logs with named owners.
Stronger version
- Quality and assurance approach linked to risk profile.
- Communications plan and stakeholder map for adoption-heavy work.
- Benefits profile with owner, baseline, target, and review points.
- Supplier integration controls and work package standards.
Step-by-step operating flow
- Translate startup decision into initiation objectives and deliverables.
- Define products, acceptance criteria, and scope boundaries in plain language.
- Design stage structure and first-stage delivery controls.
- Set project, stage, and reporting tolerances with sponsor agreement.
- Establish RAID, decision, and change handling mechanisms.
- Confirm governance calendar and highlight reporting cadence.
- Prepare and approve the initiation baseline with explicit assumptions.
- Start the first stage with authorised work packages and control rhythm.
Inputs needed
- Approved startup outputs and decision rationale.
- Business case lite and sponsor priorities.
- Initial constraints, dependencies, and risk view.
- Delivery capacity, supplier context, and operational readiness.
Outputs produced
- Approved initiation baseline (PID Lite and associated artefacts).
- Active project controls for reporting, risk, issues, and decisions.
- Authorised first-stage plan and work package approach.
- Shared baseline reference for change and tolerance management.
Common mistakes
- Creating a long baseline document nobody uses operationally.
- Skipping acceptance definitions and relying on implied quality.
- Not setting tolerances, then escalating inconsistently later.
- Deferring RAID and decision setup until problems appear.
Tailoring notes
- Lite projects can combine sections in one concise baseline pack.
- Enhanced projects should separate quality, assurance, and supplier controls.
- Recovery projects should re-initiate with reset assumptions and tighter cadence.
- Agile/hybrid projects should baseline governance outcomes while delivery remains iterative.
Related templates
Related tools
PRINCE2 mapping
Operational translation of PRINCE2 Initiating a Project, focused on creating a usable baseline for control and governance.