The project lifecycle is a loop, not a sequence

The textbook draws five boxes. Real projects redraw them every two weeks.

The standard project lifecycle diagram has five boxes: Initiation → Planning → Execution → Monitoring & Controlling → Closure. It has been on the cover of every PMBOK edition since the 1996 first. It is a useful diagram. It is also a misleading model.

The diagram suggests sequence. Real projects do not run in sequence. They loop — multiple times, at multiple levels — and the discipline of project management is the discipline of running those loops well. A project that completes once, end to end, without revisiting earlier phases, is either trivial or dishonest.

This piece is the long-form anchor for the Project Lifecycle pillar. It walks the five phases as they actually behave on real engagements, names the dominant failure mode in each phase, and ends with the loop dynamic that the textbook diagram quietly omits.

§1 — Initiation: where projects are won or lost

Initiation is the most under-invested phase on most teams and the highest-leverage one. The decisions made here — what the project is, who owns it, what "done" means, and who decides on changes — set the cost basis for every later phase. A project initiated badly costs ten times more to repair at the planning phase than it would have cost to initiate well in the first place.

Initiation has two outputs that matter. The first is a written charter — a one-to-three-page document the sponsor signs that names the problem, the desired outcome, the scope boundaries, the named decision-maker for scope changes, and the budget envelope. The second is the named decision-maker. Most charters get the first half right and skip the second; the gap is where most political conflict in execution comes from.

§2 — Planning: the phase that lies most often about being done

Planning is where the textbook gets the most credit and where real projects diverge from it the most. The textbook implies a single planning phase that produces a single plan. Real projects produce a baseline plan in week one, then re-plan continuously — sometimes in standup, sometimes in a quarterly steering review, sometimes in a 2 a.m. Slack message.

The practical question is not "is the plan done" but "what kind of planning are we doing right now." Three kinds matter.

Top-down planning — the executive sets a delivery date, the team works backward to stuff the work into the date. Common in enterprise contexts where the date is the variable that cannot move. Honest top-down planning ends with a written list of trade-offs the executive has accepted; dishonest top-down planning ends with the team quietly absorbing the gap.

Bottom-up planning — the team estimates the work, the estimates roll up to a date. Common in software contexts where the work is genuinely hard to scope from the top. Honest bottom-up planning ends with a date that the team can defend; dishonest bottom-up planning ends with a date that gets quietly compressed before it leaves the room.

Rolling-wave planning — the team plans the next phase in detail, the rest at high resolution, and re-plans on each phase boundary. The pattern that survives most contact with reality. Almost always the right choice for projects longer than one quarter.

§3 — Execution: where the plan meets the calendar

Execution is the longest phase and the most boring to write about. It is also where the loop dynamic first becomes obvious. Within a week of starting execution, the team learns something the plan did not anticipate — a dependency arrives later than expected, a stakeholder asks for a change, a key contributor leaves. The textbook calls this change management and treats it as an exception. It is not an exception. It is the median condition.

The practical work of execution is a continuous re-baselining loop:

1. The team executes against the current plan. 2. Reality produces a deviation. 3. The deviation is logged, evaluated, and either absorbed (small) or surfaced as a change (significant). 4. The plan is updated — formally if it is significant, informally if it is not. 5. The team continues, executing against the updated plan.

The difference between projects that ship and projects that drift is almost entirely about steps 3 and 4. Projects that ship have a habit of evaluating deviations against the charter (the document the sponsor signed) rather than against the most recent informal commitment. Projects that drift evaluate deviations against the most recent expectation, which means every deviation looks small and the cumulative drift is invisible until it is too late.

§4 — Monitoring & Controlling: the phase that does not exist as a separate phase

The textbook draws Monitoring & Controlling as a separate fourth phase. In practice, it runs concurrently with Execution from week one. Earned Value Management is the canonical instrument here, but the most useful monitoring on most projects is far simpler than EVM: a weekly status that names three things — what shipped this week, what slipped, and what is at risk for next week.

The purpose of monitoring is not surveillance. It is signal. A monitoring discipline that produces a 12-page status document nobody reads is worse than no monitoring at all, because it produces the appearance of control without the substance. The teams that ship reliably tend to have shorter status updates, not longer ones.

§5 — Closure: the phase that gets skipped

Closure is the most-skipped phase in project management. The team ships, the executive moves on, the contractors roll off, and the lessons-learned document — if it exists — gets pasted into a wiki page nobody reads. This is a mistake, but it is a cultural mistake more than a process mistake. The fix is not a better template; the fix is a leadership decision that closure is part of the work.

A closure phase that earns its keep produces three things:

• A retrospective the team participated in — not a slide deck the PM wrote alone after the fact. The retrospective surfaces the patterns that would otherwise be re-learned on the next project at full cost.
• A written record of what the project actually delivered versus what was originally chartered. The variance is the most valuable artifact for the next initiation phase the org runs.
• A formal handoff to operations — a named owner for everything the project produced, a runbook for the parts that were not in scope to fully document, and a date by which the operations team takes over.

§6 — The loop the diagram does not show

The textbook diagram has an arrow from Closure back to nothing — the project ends, and the diagram closes. Real projects have an arrow from Closure back to Initiation: every project the org runs is shaped by the lessons of the previous one, whether the org captures those lessons deliberately or absorbs them as folklore.

The loop runs at three timescales:

• Within a project: the daily/weekly re-baselining loop in execution.
• Across a quarter: the rolling-wave re-planning loop at phase boundaries.
• Across the org: the lessons-learned loop from closure back into the next initiation.

Mature project organizations are good at all three loops. Most organizations are good at the first one (execution), passable at the second (rolling-wave), and bad at the third (lessons-learned). The gap between a competent PMO and a great one lives almost entirely in the third loop.

§7 — Where the loop most often breaks

Four patterns account for the majority of lifecycle failures we see across customer engagements.

The unsigned charter. The project starts without a sponsor signature on a written charter. Every later disagreement about scope traces back to the absence of this document. The fix is structural: do not let initiation close without the signature, even if it costs a week of calendar time.

The frozen plan. The team produces a beautiful plan in week two and then refuses to update it as reality intrudes. The plan becomes a fiction the team maintains for the steering committee while the actual work runs on a separate informal track. The fix is rolling-wave planning with a hard re-plan cadence the steering committee enforces.

The silent absorption. Every change request gets absorbed by the team rather than surfaced through the named decision-maker. By month three, the project is delivering something materially different from the chartered scope, and nobody on the steering committee knows. The fix is a written change log that surfaces every deviation above a stated threshold (e.g., one engineer-week).

The skipped closure. The project ships and the team drifts onto the next thing. No retrospective, no variance documentation, no operations handoff. The lessons get re-learned on the next project. The fix is leadership: the executive explicitly closes the project, in a meeting, with the team present.

§8 — How to use this pillar

The rest of the Project Lifecycle pillar walks each phase in depth. If you are starting a new project, read the initiation and planning pieces first; come back for the execution and closure material when you reach those phases. If you are inheriting a project mid-flight, read the execution piece on re-baselining and the §7 patterns above — most inherited-project failures trace to one of those four.

The lifecycle is a loop. Treat it as one, run the loop deliberately, and the project mostly takes care of itself. Treat it as a sequence and pretend the diagram is the model, and the gap between the diagram and reality becomes the project's biggest risk.