The Project Lifecycle
Every project runs through the same four movements, whether or not anyone names them: deciding to do it, working out how, doing it, and stopping properly. Naming them matters because each one fails in its own way — and because the failures show up one phase later than the mistake.
In short
- The four phases are initiation, planning, execution and closing. Each answers one question and leaves one artefact behind.
- What separates them isn’t the calendar — it’s a decision someone has to make out loud before the next phase starts.
- Agile doesn’t remove the phases; it runs them in short loops instead of one long pass.
- Most visible project problems started one phase earlier than where they showed up.
The phases are decisions, not dates
It’s tempting to read the lifecycle as a timeline: a month of planning, four months of building, a week of wrapping up. That reading is what makes phases feel like paperwork.
The more useful reading is that each boundary is a commitment point. Moving from initiation to planning means somebody has decided this project is worth spending planning effort on. Moving from planning to execution means somebody has accepted a plan and is now measuring against it. Moving to closing means somebody has agreed the thing is finished. Take away those decisions and the phases collapse into one long stretch of activity where nobody can say what has been settled and what is still open.
What a weak lifecycle looks like from the inside
You rarely hear a team say “we skipped initiation”. You hear the symptoms instead. If any of these sound like your current project, the fix is usually one phase upstream of where the pain is.
| What people say | Where it started | What was missing |
|---|---|---|
| “Nobody can tell me who actually wants this.” | Initiation | A named sponsor and a stated business reason |
| “Every week something new turns out to be in scope.” | Planning | An agreed scope with written exclusions |
| “We’re busy, but I couldn’t tell you if we’re on track.” | Planning | A baseline to measure progress against |
| “The same decision keeps getting re-opened.” | Execution | A record of what was decided and by whom |
| “It shipped months ago and the team still supports it.” | Closing | A handover with a named owner |
| “We made the exact same mistake as last time.” | Closing | A retrospective anyone reads afterwards |
The pattern is consistent: the cost lands one or two phases after the omission. That delay is exactly why skipping a phase feels efficient at the time. Nothing bad happens on the day you skip it.
How much lifecycle does your project need?
The opposite failure is real too. A two-week internal tool does not need a charter document, a formal gate review and a signed baseline — that’s the process eating the work. The phases don’t change; the weight of each one does.
Small — days to a few weeks
Initiation is a conversation and two sentences in a task description. Planning is a task list with dates. Closing is a demo and a note about what you’d do differently. Total overhead: under an hour.
Medium — one to six months
Write the goal and the exclusions down. Have a real baseline. Hold a short go/no-go with the sponsor before planning gets expensive, and a genuine handover at the end.
Large — many teams or many months
Formal gates earn their cost here, because the money committed between them is large enough that stopping is a legitimate outcome. This is what phase gates were invented for.
A useful test: how much would we lose if we discovered in month three that this was the wrong project? The bigger that number, the more the early phases deserve.
Where Agile fits
A common misreading is that Agile abolishes the lifecycle. It doesn’t — it changes its grain. A Waterfall project runs the four phases once, at project scale. An Agile project runs them repeatedly at feature scale: each iteration decides what’s worth doing, plans it, builds it and reviews it, while the project as a whole still has a beginning, a funding decision and an end.
What genuinely differs is when uncertainty is resolved. Waterfall front-loads the resolving into a long planning phase and pays for late discoveries. Agile resolves continuously and pays in re-planning overhead and a fuzzier long-range date. Neither is free. 5.4 Agile vs Waterfall works through choosing between them.
The dashed loop in the diagram above is the honest part of both models. Execution constantly discovers things that invalidate part of the plan. A team that treats every one of those as a planning failure will stop reporting them.
How this looks in AB
In AB Projects, the lifecycle is mostly expressed through state rather than through separate documents:
- Initiation lives in the project record itself — dates, members, and a description that should answer “why now?”. If that field is empty, initiation didn’t really happen.
- Planning becomes tasks with estimates and dependencies; the Gantt view is where an unrealistic plan becomes visible before it becomes late.
- Execution is task status plus the change history on each task — the record of what moved and when, which is what makes the re-plan loop reviewable instead of anecdotal.
- Closing is the part that needs deliberate effort in every tool, including this one: a project with all tasks complete is not the same as a project that has been handed over.
A practical habit: put the gate decisions in the project Wiki as three short entries — approved to plan, baseline agreed, accepted, each with a date and a name. It takes minutes and it is the single cheapest defence against a project that quietly never ends.
What this chapter covers
The Initiation Phase
Turning “someone thinks we should” into a project with a sponsor, a purpose and a rough size — and knowing when the right answer is no.
The Planning Phase
Producing something you can actually be measured against: scope, schedule, people, budget and the risks you already know about.
The Execution Phase
Keeping work moving, decisions recorded and surprises surfaced early — the phase where most of the calendar and most of the drama live.
The Closing Phase
Acceptance, handover and the lessons that only exist if someone writes them down. The most skipped phase and the cheapest one to do well.
Terms used on this page
- Project lifecycle
- The sequence of phases a project passes through from start to finish. The names vary between frameworks; initiation, planning, execution and closing is the most common four-phase version. More →
- Phase gate
- A decision point between phases where someone with authority confirms the project should continue, change or stop. The point is that stopping is a real option. More →
- Project charter
- The short document that authorises a project: its purpose, its sponsor, its rough scope and budget. On a small project it can be a paragraph, but it should exist. More →
- Baseline
- The approved version of scope, schedule and cost that actual progress is compared against. Changing it is fine; changing it silently is not. More →
- Sponsor
- The person who wants the project to exist, funds it, and decides trade-offs the team cannot. A project without one has no way to resolve a conflict between scope and date. More →
- Deliverable
- A specific, verifiable output the project hands over. Deliverables are nouns; the activities that produce them are verbs. More →
- Iteration
- A short, fixed-length cycle in which a team plans, builds and reviews a small slice of work. Agile’s way of running the lifecycle repeatedly at a smaller grain. More →
Related reading
3.0 Project Planning Basics
What the planning phase actually produces: scope, schedule, resources and risk, as one connected system.
5.4 Agile vs Waterfall
Running the four phases once versus running them repeatedly — and how to pick.
7.0 Project Closure
The last phase in depth, and why the final five percent is where value gets left behind.