2.1 Linear Life Cycles and Why Work Is Phased

Why life cycles matter on the PMQ

In the APM Project Management Qualification, life cycles sit in Area A (Setting up for success). A project life cycle is the structured series of phases or iterations through which a temporary endeavour moves from idea to completion of project work. Life-cycle design shapes planning, governance, risk handling, stakeholder engagement, change control, and how benefits are later realised.

PMQ long-response and scenario questions often ask you to recommend a life cycle, justify it against project context, or compare features. Memorising labels is not enough: you must explain distinctive features, when each is applicable, and why linear work is phased.

Linear life cycles

A linear life cycle (also called sequential or phase-gate) moves the project through ordered phases. Typical high-level sequence in APM-aligned thinking is along the lines of concept/initiation → definition/design → deployment/development → transition/handover → closure, with local tailoring. Work in a later phase is intended to start only when earlier phase objectives and decision criteria have been met.

Distinctive features of linear life cycles

• Sequential progression — phases run largely one after another rather than as many overlapping learning loops.
• Decision gates (stage gates) — formal reviews decide whether to continue, stop, re-scope, or re-plan before major further commitment.
• Front-loaded definition — requirements and solution design are intended to be understood well before full-scale build or construction.
• Predictive planning — baselines for scope, schedule, and cost are established early and controlled through change control.
• Clear phase deliverables — each phase has defined outputs (for example a business case, design package, completed asset, or handover pack).

Why projects are structured as phases in linear life cycles

Phasing is not bureaucracy for its own sake. In a linear model, phases support progressive commitment: the organisation invests relatively little early (concept and definition) and only commits large funds, suppliers, and operational disruption after confidence has improved. Phases also:

1. Reduce risk by forcing early work on feasibility, requirements, and design before irreversible spend.
2. Create governance checkpoints so sponsors and boards can re-test the business case, compliance, and strategic fit.
3. Improve quality through phase-end reviews, assurance, and configuration of approved baselines.
4. Clarify accountability — different skills and contracts can dominate different phases (for example designers early, constructors later).
5. Enable controlled stop/go — a gate can kill a weak project before deployment waste multiplies.

If requirements are still unstable at late gates, a pure linear approach becomes fragile: change is expensive once detailed design and build are underway.

When linear is applicable

Linear suits contexts where requirements are relatively stable, the solution is well understood, interfaces are known, and regulators or funders demand formal stages. Classic examples include construction of a known building type, heavy civil infrastructure with fixed standards, or pharmaceutical manufacturing facility work with prescribed validation stages. Linear also fits organisations whose culture values detailed upfront approval and fixed budgets.

Naming the phases without over-committing

APM does not mandate one universal set of phase names, and exam scenarios use whatever labels the organisation uses. What examiners reward is that you can describe what a phase is for, not that you recite a particular five-word sequence. A workable mental model:

Two traps follow. First, do not claim phases never overlap. In practice a linear project may start long-lead procurement during definition; the point is that major commitment follows the gate, not that no activity crosses a boundary. Second, do not equate "phase" with "gate." A phase is a block of work; a gate is a decision event at its boundary. A scenario that says "the project passed into build without a review" describes a missing gate, not a missing phase.

What goes wrong when phasing is weak

PMQ scenarios frequently describe symptoms rather than naming the cause. Learn to read backwards from the symptom to the phasing failure:

• "Design changes are still arriving during construction." Definition finished before requirements were stable, or the gate approved an immature design.
• "Nobody can say whether the project is still worth doing." Gates exist on paper but the business case is not re-tested at them.
• "The supplier was appointed before the specification was agreed." Procurement ran ahead of definition, transferring requirement risk to a contract that cannot absorb it.
• "We are 80% spent and 40% complete." Progressive commitment failed: money was released without evidence that earlier phase objectives were met.

In a long response, name the phase boundary that was crossed too early, state which decision should have been taken there, and say who owned that decision.