The project life cycle is the sequence of states through which temporary work moves from an unresolved need to an accepted result that can survive without the project team.

That sounds simple until we notice what a project must actually do. At the beginning, the team may not fully understand the problem. Later, it must commit resources. Then it must build. Then it must prove that what was built is acceptable. Then responsibility must move from a temporary delivery structure into a permanent operating structure. Each of those moments asks different questions, requires different evidence and carries different kinds of risk.

A useful life cycle is therefore not merely a row of boxes called initiation, planning, execution and closure. It is a map of changing uncertainty.

The One-Sentence Answer

The project life cycle works by moving the project through progressively more committed states, while requiring enough evidence at each transition to justify the next level of cost, consequence and irreversibility.

Why a Life Cycle Exists

A project should not spend as if the idea is proven before the idea is proven. It should not launch as if the product is tested before the product is tested. It should not close as if operations are ready before operations are ready.

The life cycle places structure between these states. It creates moments where the project asks whether it has earned the right to proceed.

In low-risk work, those moments may be informal. In a complex engineering, healthcare, infrastructure or regulated programme, they may be formal gates with substantial evidence. The principle is the same: commitment should rise as uncertainty falls.

The Life Cycle Is Not Always Linear

Many diagrams imply that a project moves neatly from left to right. Reality is more interesting.

Discovery may reveal that the original problem was wrong. Planning may expose an impossible dependency and force redesign. Testing may reveal a requirement gap. User feedback may send a product back into refinement. A construction project may advance physically while commissioning loops repeatedly through test and repair. A research project may revisit its hypothesis after new evidence.

A mature life cycle therefore allows controlled return paths. Going backward is not automatically failure. Sometimes it is exactly what prevents a larger failure.

A Nine-State Project Life Cycle

• 1. Need: a condition exists that may justify change.
• 2. Discovery: the team investigates the real problem and context.
• 3. Definition: the desired outcome, boundaries and success criteria are agreed.
• 4. Planning and Mobilisation: the route, capacity, governance and controls are made credible.
• 5. Delivery: the project converts resources into working outputs.
• 6. Verification and Validation: evidence tests whether outputs are correct and useful.
• 7. Transition and Handover: ownership moves into the receiving system.
• 8. Closure: temporary structures are formally released and residual matters are bounded.
• 9. Learning and Benefits: the organisation checks what changed and preserves what it learned.

State 1: Need — Before There Is a Project

Every project begins before the project exists. There is a need, opportunity, threat, obligation, failure, idea or ambition.

At this stage, the organisation should resist a common mistake: jumping immediately from problem to solution. “We need an app” may actually mean “customers cannot complete a process without assistance.” “We need a new building” may mean “our current space cannot support the required capacity.” “We need training” may mean “people lack knowledge,” but it may also mean the system is badly designed.

The first life-cycle question is therefore not “How do we deliver the solution?” It is “What condition are we trying to change, and is a project the right response?”

Exit Evidence from Need

• a credible problem or opportunity statement;
• a reason the matter deserves attention;
• an accountable sponsor or owner;
• permission to investigate further.

State 2: Discovery — Learn Before Committing

Discovery converts assumptions into questions and questions into evidence.

The team studies users, constraints, existing systems, data, stakeholders, regulations, technical feasibility, costs, alternatives and previous attempts. It looks for the shape of the problem rather than proving the first idea correct.

Good discovery has a paradoxical quality. It may feel slower because it delays building. Yet it often accelerates the whole project by preventing deep commitment to a weak solution.

Questions for Discovery

• Who experiences the problem?
• How do we know the problem is real?
• What has already been tried?
• Which constraints are fixed and which are assumptions?
• What would happen if we did nothing?
• Which unknown could overturn the entire solution?
• What is the cheapest experiment that could reduce that unknown?

Exit Evidence from Discovery

The team should be able to explain the problem, key stakeholders, major constraints, meaningful options, highest uncertainties and why the proposed direction deserves further investment.

State 3: Definition — Turn Ambition into a Bounded Promise

Definition is where the project decides what it is.

The outcome becomes explicit. Scope boundaries are drawn. Success criteria are described. Stakeholder needs are translated into requirements or objectives. Major exclusions are recorded. Governance is established. The project gains an identity that can be defended against drift.

This is also the moment to distinguish output from outcome. A new portal is an output. Reduced customer effort may be the outcome. A new curriculum is an output. Improved learner capability is the outcome. A new production line is an output. Increased safe throughput may be the outcome.

The Definition Test

If five senior participants privately describe a different project, definition is incomplete.

Exit Evidence from Definition

• clear outcome and purpose;
• scope and exclusions;
• success and acceptance criteria;
• major stakeholders;
• initial risk picture;
• sponsor and decision rights;
• permission to plan and mobilise.

State 4: Planning and Mobilisation — Make the Route Credible

Planning turns the bounded promise into a coordinated route.

This is where the project develops work packages, sequence, dependencies, resource plans, procurement, budget, risk responses, quality plans, communication routes, change mechanisms, decision cadence and milestone logic.

Mobilisation is equally important. A project can possess a plan on paper without having the conditions needed to start. Contracts may not be signed. Access may not exist. Teams may not be allocated. Tools may not be configured. Data may not be available. The project is planned but not mobilised.

The Difference Between a Date and a Credible Date

A date becomes credible when it is supported by scope, sequence, capacity, dependencies, lead times, assumptions and margin. Before that, it is a wish with a calendar attached.

Exit Evidence from Planning and Mobilisation

• a coherent delivery plan;
• resource commitments;
• baseline scope and schedule appropriate to the method;
• budget and contingency logic;
• major dependencies owned;
• quality and acceptance approach;
• risk responses for material exposures;
• governance and communication working in practice.

State 5: Delivery — Convert Plans into Working Reality

Delivery is where the project spends most visibly. Teams design, build, configure, write, fabricate, integrate, train, install, migrate, test, revise and coordinate.

The management challenge changes. Early phases ask whether the project is worth doing and how it might work. Delivery asks whether the operating system of the project can keep truth, work and decisions moving at the required speed.

Three loops dominate:

• production loop: work moves from ready to done;
• control loop: actual state is compared with plan and forecast;
• learning loop: evidence changes assumptions, priorities or design.

Projects become brittle when one loop dominates. Pure production without control creates hidden drift. Control without production creates bureaucracy. Production and control without learning create elegant persistence in the wrong direction.

What Delivery Management Watches

• flow of completed work;
• blocked work and aging decisions;
• dependency movement;
• risk exposure;
• defects and rework;
• resource overload;
• forecast date and cost;
• scope change;
• stakeholder confidence;
• readiness for the next state.

State 6: Verification and Validation — Prove the Result

As delivery advances, the project must convert claims into evidence.

Verification asks whether the work conforms to requirements, specifications or standards. Validation asks whether the delivered solution actually works for the intended purpose in the real environment.

A system can pass functional tests and still fail users. A building can satisfy drawings and still create operational difficulty. A training package can include every required module and still fail to change capability. Verification protects correctness. Validation protects usefulness.

Test the Interfaces

Many failures occur not inside components but between them. Software meets data. New processes meet old teams. Equipment meets buildings. Contractors meet clients. Policy meets real behaviour. The interfaces deserve deliberate testing because each side may be correct locally while the connection fails globally.

Exit Evidence from Verification and Validation

• acceptance criteria tested;
• critical defects resolved or explicitly accepted;
• performance demonstrated in realistic conditions;
• documentation complete enough for transition;
• residual risk understood;
• receiving organisation prepared to take ownership.

State 7: Transition and Handover — Move Ownership Without Losing Capability

Transition is one of the most underestimated project states because the object may look finished.

But a finished object without a functioning owner is an orphan.

The receiving team may need knowledge, access, procedures, support contracts, monitoring, spare parts, budgets, training, escalation routes, source files, configuration records, security permissions or maintenance schedules. Users may need communication and onboarding. Finance may need asset records. Compliance may need evidence. Support teams may need known-issue lists.

A project should design handover from the beginning because many transition requirements affect what must be produced during delivery.

The Handover Test

If the project team disappeared tomorrow, could the receiving organisation operate, support and explain the delivered result safely? If not, transition is incomplete.

State 8: Closure — End the Temporary System Deliberately

Closure is not simply the moment people stop charging time to the project.

Formal closure confirms acceptance, resolves contracts, closes financial matters, archives records, releases resources, transfers residual actions, records lessons and makes ownership explicit. It also distinguishes what is complete from what has merely been deferred.

Projects that never close continue to consume attention. People remain vaguely responsible. Old risks stay open. Suppliers remain uncertain. Documentation never becomes canonical. A clean ending is a management service to the organisation.

Residual Work Must Have a Home

Closure does not require every imperfection to disappear. It requires every remaining matter to have a conscious disposition: accepted, transferred, scheduled, funded, waived or explicitly rejected. An unresolved item without an owner is not closure.

State 9: Learning and Benefits — Ask Whether the Change Was Worth It

The project may close before its benefits are fully visible.

A new system may take months to affect productivity. A curriculum change may take a school year to reveal outcomes. A transport project may need operational data across seasons. A publishing architecture may need time to show discovery, navigation or search effects.

This is why benefits often belong partly to operations after the project ends. Someone must own the measurement.

Learning also deserves a stronger standard than “lessons learned meeting held.” The organisation should convert useful lessons into changed templates, standards, estimates, checklists, training, governance or architecture. Otherwise it has documented memory without installing it.

Stage Gates: Decisions Between States

A stage gate is a decision point between meaningful states. It asks whether the project should proceed, pause, change direction, repeat work or stop.

Good gates are based on evidence appropriate to the decision. A discovery gate should not demand detailed construction certainty. A launch gate should not accept the same level of ambiguity tolerated during exploration.

Possible gate decisions include:

• proceed;
• proceed with conditions;
• return for more evidence;
• re-scope;
• pause;
• stop.

The existence of a genuine stop option makes a gate more than theatre.

Why Early Phases Feel Slow and Late Failures Feel Sudden

Good early project work often produces invisible value. It removes bad options, clarifies assumptions, exposes dependencies, secures decisions and creates shared understanding.

Because no building has risen and no software has launched, the work can appear slow. Yet this is where many future crises are prevented.

Late failures feel sudden because earlier uncertainty was hidden rather than removed. The final test merely reveals the accumulated condition.

The Cost of Change Usually Rises with Commitment

Changing a sketch is cheaper than changing fabricated steel. Changing a prototype is cheaper than migrating millions of records twice. Correcting a policy draft is cheaper than retraining an entire organisation. Rewriting one article outline is cheaper than repairing a hundred published pages built on the wrong taxonomy.

The project life cycle exists partly to place learning before irreversible commitment whenever possible.

Rolling-Wave Planning: Detail Arrives When It Becomes Useful

Not every future task needs equal detail on day one.

Rolling-wave planning keeps near-term work detailed and future work at an appropriate level until more information exists. This prevents false precision while preserving strategic direction.

The principle is especially valuable in long programmes. A project may know the major milestones for next year while planning next week’s work in detail. Precision should match decision need.

Agile Iterations Are Mini Life Cycles Inside the Larger Life Cycle

Adaptive teams often repeat smaller loops of selection, build, test, review and learning. These iterations sit inside a larger project or product context.

The larger system still needs purpose, funding, governance, architecture, strategic alignment, risk treatment and eventual transition. The iteration reduces the distance between action and evidence; it does not eliminate the surrounding life cycle.

Life Cycle for a Software Migration

Consider a company replacing an old customer platform.

• Need: the current system is costly, slow and unsupported.
• Discovery: map users, integrations, data quality, regulations and pain points.
• Definition: agree target capabilities, migration scope, service levels and exclusions.
• Planning: sequence environments, data cleansing, integrations, testing, training and cutover.
• Delivery: configure, develop, migrate samples, train, fix and iterate.
• Verification: test functions, security, performance, integrations and data reconciliation.
• Transition: rehearse cutover, prepare support and move production data.
• Closure: retire project governance and transfer residual actions.
• Benefits: measure adoption, support load, cycle time and cost.

The life cycle reveals why “install the new software” is not an adequate project plan.

Life Cycle for a School Learning Programme

A school programme follows the same deeper logic.

• Need: learners are struggling with a transferable skill.
• Discovery: analyse work, teacher observations and learner misconceptions.
• Definition: define the capability change and evidence of learning.
• Planning: design sequence, teacher support, materials and measurement.
• Delivery: teach, observe, adapt and support.
• Validation: test whether learners can transfer the skill beyond rehearsed examples.
• Transition: embed successful practices into ordinary teaching.
• Learning: revise the programme based on evidence.

Life Cycle for a Publishing Series

A publishing series also benefits from a life-cycle view.

• Need: identify a knowledge gap or authority opportunity.
• Discovery: scan existing estate content, external references, search intent and collision risk.
• Definition: establish canonical owner, series boundaries, voice, audience and article architecture.
• Planning: sequence hero article, pillars, feeders, metadata, internal links and update rules.
• Delivery: research, draft, edit, fact-check and publish.
• Verification: check links, duplication, metadata, taxonomy, readability and factual integrity.
• Transition: wire the series into the wider knowledge ecosystem and define maintenance ownership.
• Learning: use search, navigation and reader evidence to improve the next wave.

The Life Cycle and Risk

Different risks dominate different states.

During discovery, the greatest risk may be solving the wrong problem. During definition, it may be ambiguous scope. During planning, it may be false assumptions about capacity or lead time. During delivery, it may be coordination, defects and change. During verification, it may be insufficient evidence. During handover, it may be operational unreadiness. During closure, it may be ownerless residual work.

This is why one static risk register cannot represent an entire project well. The risk landscape changes as the project changes state.

The Life Cycle and Team Shape

The dominant capabilities also change.

Discovery needs listeners, analysts and subject experts. Definition needs integrators and decision-makers. Planning needs architects, estimators and coordinators. Delivery needs builders and operators. Verification needs testers and independent reviewers. Transition needs trainers, documenters and operational owners. Closure needs disciplined administrators and memory keepers.

The whole team does not need to change at every stage, but the project should recognise that the capability shell around its stable mission core will evolve.

The Life Cycle and Decision Quality

Good project decisions match the evidence available at the current state.

Early decisions should preserve options when uncertainty is high. Later decisions can become more committed because evidence has accumulated. This creates a useful principle: do not demand false certainty early, and do not tolerate avoidable ambiguity late.

The Life Cycle and AI

AI can accelerate work in every state, but the type of assistance should change with the state.

• During discovery, AI can search, compare and classify evidence.
• During definition, it can expose ambiguous requirements and missing stakeholders.
• During planning, it can check schedules, dependencies and risk language.
• During delivery, it can generate drafts, code, test cases and summaries.
• During verification, it can assist comparison and anomaly detection.
• During transition, it can help create training and documentation.
• During learning, it can compare patterns across many projects.

The governance requirement is constant: generated output is not automatically accepted evidence. Human accountability, source integrity and domain verification remain essential where consequence is meaningful.

A Simple Gate Checklist

• What state are we leaving?
• What state are we entering?
• What evidence should exist before that transition?
• Which uncertainty remains material?
• What becomes more expensive or irreversible after this gate?
• Who has authority to accept the remaining risk?
• What conditions must be carried into the next state?

This checklist turns a phase boundary into a real management decision.

The Most Important Life-Cycle Question

At any moment, ask:

What must be true before this project should be allowed to enter its next state?

That question immediately improves planning, governance, risk thinking, quality and handover. It replaces vague progress with state readiness.

The Project Management Series

• What Is Project Management?
• How Project Management Works
• The Project Life Cycle
• Why Projects Fail

Final Answer

The project life cycle is the project’s map through changing uncertainty.

It begins before the solution is fixed. It investigates the real need. It defines a bounded promise. It turns that promise into a credible route. It delivers. It converts claims into evidence. It transfers ownership. It closes temporary structures. Then it checks whether the intended benefits actually appeared and whether the organisation learned anything worth keeping.

The purpose of the life cycle is not ceremonial compliance with phases. It is disciplined commitment: spend more, lock more and risk more only when the project has accumulated enough evidence to justify the next state.

That is how a project moves from possibility to reality without losing the ability to think on the way.