Skip to content

Lesson 3 — Project Life Cycles and Development Approaches

At a glance

Learning objectives

By the end of this lesson you should be able to:

  1. Describe what a project life cycle is and explain the purpose of phases and decision gates.
  2. Distinguish a project life cycle from a development life cycle.
  3. Compare predictive, iterative, incremental, and adaptive approaches, and state what each is good for and what it costs.
  4. Select an approach for a given project and justify the choice using the conditions of the project rather than preference.

Prerequisites

Introduction

Every project has to answer the same question: in what order do we do the work? A life cycle is the answer — a defined sequence of phases with checkpoints between them.

The choice of life cycle is one of the earliest and most consequential decisions a project makes. It determines when the client sees working software, how change is handled, how risk is distributed, and what the plan even means. Get it wrong and no amount of good management recovers the position: you will be managing a project in a shape that does not fit its problem.

This lesson establishes the vocabulary of life cycles. Module 04 returns to the same choice in detail; here you learn the shapes and when each fits.

1. What a life cycle is

A life cycle is the sequence of phases a project passes through from start to finish. Each phase has a purpose, an output, and a decision about whether to continue.

A typical project life cycle looks like this:

flowchart LR
    accTitle: Life cycle phases and their decision gates
    accDescr {
    Concept leads to Initiation, Planning, Execution and Closure in sequence. Dashed gate links run
    backwards, one from Initiation to Concept and one from Planning to Initiation, showing where a
    phase can be rejected.
    }
    A[Concept] --> B[Initiation]
    B --> C[Planning]
    C --> D[Execution]
    D --> E[Closure]
    B -.->|gate| A
    C -.->|gate| B

The dashed arrows are decision gates — points where someone asks "is this still worth continuing?" and can stop, redirect, or fund the next phase. Gates exist because the cheapest moment to cancel a project is before you have spent most of its budget.

Phases are not the same as iterations

A phase is a stage of decision-making and control (are we still justified? is the plan sound?). An iteration is a repeated cycle of building and learning. Predictive projects typically run phases once; adaptive projects repeat them many times. Both can use gates.

2. Project life cycle versus development life cycle

Two different sequences are often confused, and the confusion causes real planning errors.

Project life cycle Development life cycle
What it governs The whole project, from concept to closure How the software is designed, built, and tested
Who owns it The project manager and sponsor The engineering team
Typical phases Concept, initiation, planning, execution, closure Requirements, design, implementation, testing, deployment
Change frequency Fixed once set; changing it reshapes the whole project Varies — waterfall, iterative, continuous

The project life cycle is a management structure. The development life cycle is a technical process. A project can use any development life cycle inside any project life cycle — and choosing one does not force the other. ISO/IEC/IEEE 12207 is an international standard that defines software life cycle processes at the technical level.

3. The four approaches

The order in which you build, and how often you re-plan, gives four recognisable approaches.

Approach What repeats What you get early Main cost
Predictive (plan-driven) Nothing — phases run once A complete plan and design Late feedback; change is expensive
Iterative Building and refining the whole product A rough version that improves Rework; harder to predict the finish
Incremental Adding finished pieces A working subset, complete Integration effort; needs good architecture
Adaptive (agile) Short cycles of plan–build–review Value, and knowledge Less predictable scope; needs engaged stakeholders

These are not four brands to pick and defend. Real projects combine them: you may deliver incrementally in adaptive cycles while running a predictive procurement phase.

Admission portal (illustrative)

The admission portal has a policy-fixed application window, an external and non-technical user base, and heavy integration with existing systems. Its requirements are largely knowable up front, and the launch date cannot move. That points toward a predictive project life cycle with incremental delivery, so that parts of the portal are verified well before the window opens.

Analytics dashboard (illustrative)

The analytics dashboard is the opposite case. Nobody can say precisely what they want until they see something, the data is messy, and the audience disagrees about priorities. A predictive approach would freeze the wrong requirements early. That points toward an iterative or adaptive approach, with a deliberately rough first version to provoke a useful conversation.

4. Choosing an approach

The choice is driven by the conditions of the project, not by taste. Four conditions do most of the work.

Condition Pushes toward predictive Pushes toward adaptive or iterative
Requirement stability Stable, knowable, regulated Unclear, changing, or contested
Consequence of failure Safety, regulatory, or financial exposure Recoverable, low-cost to change
Stakeholder availability Distant, approving at milestones Available to review frequently
Delivery constraint A fixed external date or contract Value delivered continuously

A useful rule: the more uncertainty you carry, the shorter your cycles should be. Adaptive approaches are a way of buying information early by accepting more re-planning.

Key terms

Term Meaning
Life cycle The defined sequence of phases a project passes through
Phase A stage of a project with a purpose, an output, and a decision gate
Gate A checkpoint where the project is authorised or stopped
Predictive Attempting to define requirements and plan fully before building
Iterative Repeating build-and-refine cycles on the whole product
Incremental Delivering complete pieces of the product one at a time
Adaptive Short cycles of planning, building, and review that absorb change
Hybrid Deliberately combining predictive and adaptive practices

Worked example

Task: choose a life cycle for two projects and justify each choice.

Step 1 — Establish the conditions. For the admission portal (illustrative): requirements come from published policy and are mostly stable; the application window is fixed by regulation; failure is highly visible to the public; the admissions staff are available but applicants cannot be consulted continuously.

Step 2 — Map the conditions to the table. Stable requirements and a fixed external date both point to a predictive cycle. Public visibility and regulatory context raise the cost of failure.

Step 3 — Check what predictive would fail to handle. A purely predictive cycle still needs a way to test with real applicants. That gap is closed by delivering incrementally: a working application form, then document upload, then payment.

Step 4 — State the decision. Predictive project life cycle with incremental delivery, in three releases, each verified before the application window opens. This is defensible because each choice is tied to a stated condition.

Step 5 — Repeat for the dashboard. Requirements are contested and unknowable at the start; failure is cheap and reversible; stakeholders are available weekly. That points to adaptive or iterative delivery with short cycles, so the first release exists mainly to generate feedback.

Common misconceptions

“Agile means no planning”

Agile changes when and how often you plan, not whether. Adaptive projects plan more frequently and in more detail about the near term; what they avoid is committing to a detailed plan for a distant, uncertain future.

“Predictive is the safe choice”

Predictive planning is safe when requirements are genuinely stable. When they are not, a fixed plan is not safety — it is a commitment to build the wrong thing confidently. The safe choice depends on the uncertainty, not on the label.

“You must pick one approach for the whole project”

Procurement, regulatory approval, and safety-critical subsystems often suit predictive treatment inside an otherwise adaptive project. Hybrid delivery is normal, and pretending otherwise makes projects harder to run than they need to be.

Practical activity

Choose a life cycle. Pick two of the example projects — one that looks stable and one that looks uncertain.

  1. Fill in the four conditions in the table above for each project.
  2. State your chosen approach for each, in one sentence, naming the cycle and the delivery style.
  3. Write two sentences justifying each choice by reference to specific conditions, not preference.
  4. Name one thing your chosen approach handles badly, and say how you would mitigate it.

What "good" looks like: each choice is justified by a condition of the project, and each acknowledges a weakness. A justification that says "agile is better" or "waterfall is more controlled" is not yet an answer.

Self-assessment

  1. A project has stable, regulated requirements but users who can only review work twice a year. Which approach would you choose, and what is the main risk in your choice?
  2. Why is it useful to separate the project life cycle from the development life cycle?

  3. Your team is under pressure to "go agile" on a fixed-price contract with a fixed scope. What is the honest response, and why?

  4. Apply it — admission portal. The application window is fixed by policy, the form fields and fee rules are set by regulation and will not change during the project, and last year's attempt failed during integration with the student records system. The vice-chancellor wants the portal live for the coming cycle.

    Hint: A strong answer names the criteria it used to choose, and the assumption that would have to hold before it would choose differently.

Show answers
  1. Most likely predictive, with deliberate, well-planned review points to compensate for the infrequent user access. The main risk is that errors in requirements are found late, when they are expensive — so mitigation would focus on early prototyping and thorough verification at each gate.
  2. Because they answer different questions and are owned by different people. Confusing them leads to planning technical process where management decisions belong, and vice versa — for example, assuming that a predictive project requires a waterfall development process.
  3. Point out that a fixed scope with a fixed price removes the mechanism adaptive delivery depends on: the ability to vary scope as learning accumulates. The honest options are to negotiate scope flexibility, run an adaptive internal process with a predictive contractual boundary, or accept that changes will be handled as formal variations.
  4. Choose a predictive, staged delivery with an early integration spike and a decision gate after it. The criteria point that way: the requirements are knowable and fixed by policy, the delivery date is immovable, and the consequence of a late discovery is severe — last year's failure was an integration failure, not a requirements failure. An adaptive approach would require the assumption that the requirements can be discovered late and that incrementally releasable slices exist; for a regulated form plus a fixed integration, that assumption fails. Keep the gate: it lets the project be stopped cheaply if the integration spike shows the date is not achievable.

Summary

  • A life cycle is the ordered set of phases and gates a project passes through; gates exist so that projects can be stopped cheaply.
  • The project life cycle is a management structure; the development life cycle is a technical process. They are chosen separately.
  • Predictive, iterative, incremental, and adaptive approaches differ in what repeats, and each trades early certainty against the cost of change.
  • The choice is driven by requirement stability, consequence of failure, stakeholder availability, and delivery constraints — not by preference, and not once for the whole project.

Further learning

  • Module 04 — Agile, Scrum & Lean Delivery develops the adaptive end of this spectrum in detail.
  • ISO/IEC/IEEE 12207 — Systems and software engineering — Software life cycle processes. See Standards & Further Reading.
  • A Guide to the Project Management Body of Knowledge (PMBOK® Guide), Project Management Institute — life cycle and development approach concepts.

Next

Continue to Module 02 — Project Initiation & Stakeholders, which covers the work that happens before planning begins.