Project initiation
Starting Up a Project
Turn a vague mandate into a decision-ready project start with clear outcome, sponsor accountability, and a practical go or no-go recommendation.
What this helps you do
Move from idea to controlled initiation without pretending certainty too early.
Use this when
- A sponsor proposes work but the problem, scope edge, or decision rights are still unclear.
- A project request arrives as a preferred solution instead of a defined outcome.
- The organisation needs a triage gate before spending initiation budget.
- The team is under pressure to start delivery before governance is in place.
What good looks like
- Sponsor accountability is explicit and accepted in writing.
- The project outcome is measurable and linked to user or service value.
- The first decision is clear: initiate, reframe, defer, or stop.
- Known constraints and assumptions are visible rather than implied.
- Initial risks, dependencies, and stakeholder impacts are logged early.
Minimum viable version
- One-page project brief with outcome, scope edge, owner, and decision ask.
- Initial business case lite with value statement, broad cost/time range, and key risks.
- Named sponsor and delegated PM responsibility.
- Initial diagnostic result to guide the next control move.
Stronger version
- Short options view showing do nothing, minimum change, and preferred path.
- Early stakeholder map identifying supporters, blockers, and decision influencers.
- Initial governance rhythm (who meets, what decisions are expected, and when).
- Public-sector or assurance checks where policy, privacy, safety, or spend risk is high.
Step-by-step operating flow
- Capture the mandate in plain English and remove solution-first language where needed.
- Confirm sponsor ownership of value, funding intent, and major decisions.
- Define the intended outcome, in-scope, out-of-scope, and first success indicators.
- Draft the project brief and business case lite using ranges, not false precision.
- Run a practical diagnostic to identify likely control level and first artefacts.
- Record key assumptions, dependencies, and immediate risks in a starter RAID view.
- Prepare the initiation recommendation with explicit options and decision request.
- Take the decision to initiate, reframe, defer, or stop and log rationale.
Inputs needed
- Project mandate, request, or sponsor brief.
- Sponsor and operational stakeholder conversations.
- Known policy, legal, procurement, or delivery constraints.
- High-level cost, time, and capability assumptions.
- Current service pain points, baseline metrics, or user needs.
Outputs produced
- Decision-ready project brief.
- Business case lite with recommendation.
- Starter RAID and stakeholder map where useful.
- Initiation decision and recorded approval trail.
- Clear next step into initiation or controlled stop.
Common mistakes
- Starting delivery activity to compensate for unclear purpose.
- Treating sponsor endorsement as implied instead of explicit.
- Using optimistic dates or budgets without tolerance language.
- Ignoring operational readiness and change impacts this early.
- Skipping the stop/reframe option when evidence is weak.
Tailoring notes
- For Lite work, keep artefacts short but still decision-quality.
- For public-sector or regulated work, increase evidence on assurance, privacy, and approvals.
- For urgent delivery, shorten cycles but do not skip sponsor decision clarity.
- For supplier-heavy ideas, surface dependency and contract risk before initiation.
Related templates
Related tools
PRINCE2 mapping
Operational translation of PRINCE2 Starting Up a Project, with explicit focus on mandate validation, executive ownership, and initiation decision quality.