0.2Lifecycle & phases of a project
The essentials in 30 seconds
- 4 phases: initiation (the why), planning (the how), execution (deliver + steer), closure (deliver + capitalize).
- Milestone = duration-free decision point: it validates and authorizes what follows ("scoping validated", "acceptance pronounced").
- Reflex: you scope and plan before executing — upfront time pays back later.
Running mini-case — Bilal wants to code right away
For the showcase site redesign, Bilal wants to launch developers on Monday. His owner stops him: why this site, for whom, with what content? Bilal takes two days to scope (initiation), one week to plan (who does what, when), then executes by milestones: validated mockup, staging site, client acceptance, go-live and lessons learned.
Sequel to case 0.1 — Bilal discovers you scope before you execute.
1. Four phases
Every project follows a lifecycle: a sequence of phases structuring the work. The classic breakdown has four: initiation (scoping the why), planning (organizing the how), execution (delivering and steering), closure (delivering and capitalizing).
Each phase has its own objectives and deliverables.
2. Milestones
Between phases sit milestones: key checkpoints, with no duration, marking a decision or validation ("specifications validated", "acceptance pronounced").
This mental map keeps you from jumping into execution without scoping or planning.
🔎 Concrete example — 🔎 Concrete example — Scope before executing
The phase order.
Skipping initiation to "save time" → executing in a blur.
Scoping + planning first → fewer reworks, fewer drifts.
→ time invested upfront pays back generously later.Outcome: a true mental map of the project.
Reflex: place decision milestones between phases.
Section vocabulary
- Project lifecycle
- The chain of project phases, from launch to closure.
Simple example: Bilal's showcase site: from initial scoping to go-live and review.
What it is not: a single isolated task with no start or end.
Reflex: place every ongoing project within its 4 phases.
- Phase
- A project stage grouping activities and yielding deliverables (initiation, planning…).
Simple example: Bilal's planning yields a client-validated schedule.
What it is not: a duration-free milestone (that's a control point, not a phase).
Reflex: each phase = objective + key deliverable.
- Milestone
- Key, duration-free checkpoint marking a deadline or an important decision (validation, go/no-go).
Simple example: "Mockup validated" then "acceptance pronounced" for Bilal's site.
What it is not: a two-week development task.
Reflex: place 2 to 3 decision milestones between phases.
- Initiation
- First phase: define the why, rough scope, stakeholders; decide whether to launch.
Simple example: Bilal clarifies why redesign the site, for whom, with what content.
What it is not: coding straight away without knowing what the client wants.
Reflex: no execution without written, validated scoping.
- Closure
- Last phase: deliver, get validated (acceptance), archive and capitalize lessons learned.
Simple example: Bilal gets acceptance pronounced, goes live, archives and notes 3 lessons.
What it is not: leaving the site online "roughly finished" with no validation or review.
Reflex: close properly: acceptance + archives + lessons learned.
In practice — In practice — Mapping a project's lifecycle
- Take a known project and break it into 4 phases: initiation, planning, execution, closure.
- For each phase, note its main objective and a key deliverable (e.g. planning → validated schedule).
- Place 2–3 major milestones between phases (e.g. "scoping validated", "delivery", "closure pronounced").
- Spot which phase a current project around you is in: is it sufficiently scoped before executing?
Ready-to-say script — enforcing scoping before coding (30s)
"Before coding, we scope in two days: why this site, for whom, with what content. Then we plan: who does what, by when. We'll set three milestones: validated mockup, staging, acceptance. That will save us rework."
Say to team and client: sell upfront time as a gain, not a delay.
Copy-paste template — 4-phase and milestone map
PROJECT: _______________
INITIATION (why + deliverable): _______________
MILESTONE 1: _______________
PLANNING (how + deliverable): _______________
MILESTONE 2: _______________
EXECUTION (deliver + steer): _______________
MILESTONE 3 / CLOSURE (acceptance + lessons): _______________Small business / tight budget
No heavy file: one page per phase and three dated milestones in a spreadsheet are enough to scope.
Algerian SME
Bilal sets milestones around real client availability (mockup before holidays, acceptance with the owner) to avoid ghost validations.
IT project
Break into visible milestones: mockup, staging, acceptance — each with a named validator.
Event project
Milestones dated backwards: venue booked, vendors confirmed, dress rehearsal — no closure without a financial review.
✓ Best practices
- Scope and plan before executing (upfront time pays back).
- Place clear decision milestones between phases.
- Close properly (acceptance + capitalization), don't "let it slide".
✗ Common pitfalls
- Skipping initiation to "save time" (false economy).
- Confusing milestone (duration-free, decision) with task (with duration).
- Forgetting the closure phase and its lessons learned.
Key takeaways
- A project runs in phases: initiation, planning, execution, closure.
- Each phase has its own objectives and deliverables.
- Milestones are duration-free control/decision points.
- Scoping and planning BEFORE executing avoids many drifts.
48h Challenge — apply tomorrow
Take 1 ongoing project, break it into 4 phases and place 2 dated milestones (template above). Check: is it really scoped before being executed?
- I can name the 4 phases in order and their role.
- I know what a milestone is (duration-free, decision).
- I've mapped 1 real project into phases + milestones.
Frequently asked questions
Do phases always chain linearly?
In a predictive (waterfall) approach, largely yes. But in an agile approach, you iterate: you plan, execute and deliver in repeated small cycles. The lifecycle still exists (there is a start and an end), but execution and planning intertwine. The predictive/agile methods section details these differences. The key point is that a project always has a start (scoping) and an end (closure), however you organize the middle.
Can you skip initiation to save time?
It is a frequent, costly false economy: without scoping (why, for whom, what scope), you execute in a blur, leading to drifts, misunderstandings and rework. Time invested upfront in initiation and planning pays back generously in execution. A poorly scoped project costs far more to fix along the way than it would have cost to prepare properly.
Bilal wants to code the site with no scoping "to save time". What does he risk?