2.3 Project Life Cycles and Extended Life Cycles
Key Takeaways
- A project life cycle covers temporary project work through to completion of deliverables and handover; an extended life cycle also addresses operation, adoption, benefits realisation, and often disposal or decommissioning.
- Outputs are what the project creates, outcomes are the changed state they enable, and benefits are the measurable improvements that follow — usually owned in business-as-usual.
- A project can succeed in project-life-cycle terms and still fail in extended-life-cycle terms if outputs are never adopted.
- Extended-life-cycle thinking starts at initiation: design, requirements, contracts, and transition planning all set what is possible after closure.
- The extended life cycle does not replace project closure; both are still required.
Learning outcome 1b asks for knowledge of the differences between a project life cycle and an extended life cycle. It looks like a definition question and is often answered as one — which is why it is a reliable source of dropped marks. The difference is not merely that one is longer; it is that the two models measure different kinds of success and hand accountability to different people.
Project life cycle versus extended life cycle
APM teaching distinguishes the temporary project life cycle from a broader extended life cycle that connects delivery to lasting organisational value.
Project life cycle
The project life cycle is the managed path of the temporary organisation from initiation through delivery and project closure. It focuses on creating agreed outputs (deliverables) and completing project processes: defining work, deploying the solution, transitioning it to users or operations, capturing lessons, releasing the project team, and closing contracts and accounts as appropriate.
In a project-life-cycle view, success is often framed as delivering the agreed scope, to quality, within time and cost, and handing over cleanly. That is necessary but not always sufficient for organisational value.
Extended life cycle
An extended life cycle looks beyond project closure into the period when outputs are used. It typically includes:
- Adoption and embedding — people actually use the new process, system, or facility as intended.
- Operation / business-as-usual — the receiving organisation runs and supports the product or asset day to day.
- Outcomes and benefits realisation — measurable improvements (for example cost savings, safety performance, revenue, service quality) are tracked against the business case.
- Disposal or decommissioning (where relevant) — end-of-life retirement, data deletion, site restoration, or asset replacement planning.
The extended view matters because many projects "finish on time" yet fail to deliver benefits if training is weak, operations are unready, or no one owns post-handover measurement. For PMQ answers, say clearly that the extended life cycle links project outputs to outcomes and benefits, not that it removes the need for project closure.
Comparison
| Focus | Project life cycle | Extended life cycle |
|---|---|---|
| Time horizon | Temporary project duration | Beyond project closure into use and often end of life |
| Primary concern | Outputs, project controls, handover, closure | Adoption, operations, benefits, disposal/decommissioning |
| Typical end point (project view) | Project closed after transition/handover | Value realised (and later asset/service retired if applicable) |
| Key accountability shift | Project manager / project team during delivery | Sponsor and operational owners for ongoing benefits |
| Business case link | Justification to start and continue the project | Confirmation that intended value is actually achieved |
Where the two models disagree about success
Set the two definitions side by side and the examinable tension appears immediately.
A project can be completely successful in project-life-cycle terms and a failure in extended-life-cycle terms: delivered to scope, on time, within budget, handed over — and then barely used, because training was thin, the operating model never changed, or nobody owned the outcome. The reverse also happens: a project that overran and overspent can still be judged a success once benefits land far above forecast.
That is why APM separates outputs, outcomes, and benefits:
| Concept | What it is | Who typically owns it | When it appears |
|---|---|---|---|
| Output | The deliverable the project creates (a system, a building, a trained team) | Project manager | By project closure |
| Outcome | The changed state the output makes possible (staff work a new way) | Operational / business owner | During and after transition |
| Benefit | The measurable improvement that the outcome delivers (cost per case falls 12%) | Benefit owner, usually in business-as-usual | Often long after closure |
The project life cycle is built to deliver outputs. The extended life cycle is what carries them through outcomes to benefits, and often on to disposal or decommissioning at end of life.
Why this matters before closure, not after
The practical trap is treating the extended life cycle as something that begins when the project ends. It does not. Decisions taken early in the project determine whether the extended phases are even possible:
- Design choices set operating and maintenance cost for decades — the economic sustainability of the outcome.
- Requirements decide whether the benefit is measurable at all; if no baseline is captured before go-live, the improvement can never be evidenced.
- Contract terms decide who holds support and end-of-life obligations.
- Transition planning decides whether operational owners are named and ready rather than discovered at handover.
For an exam answer: say that the extended life cycle links project outputs to outcomes and benefits, and often to disposal, that it does not remove the need for project closure, and that planning for it starts at initiation — not at handover.
Why is an extended project life cycle useful compared with a project life cycle that ends at handover and closure?
A new case-management system is delivered on time and within budget, and the project closes cleanly. Twelve months later, caseworkers still use the old spreadsheets and no efficiency saving has appeared. How is this best described in APM life-cycle terms?