---
title: "Choosing a delivery lifecycle: predictive, agile or hybrid"
description: "There is no single best lifecycle Delivery lifecycles sit on a spectrum. The right choice depends on how well requirements are understood, how quickly…"
url: https://optimizeall.com/learn/project-management-leadership-with-ai/choosing-a-lifecycle
updated: 2026-10-05
---

Project Management Leadership with AI · Project governance, lifecycles and the business case · lesson 3 of 21 · 14 min

# Choosing a delivery lifecycle: predictive, agile or hybrid

## There is no single best lifecycle

Delivery lifecycles sit on a spectrum. The right choice depends on how well requirements are understood, how quickly they may change, how costly change is late in the project, and the constraints of contracts and regulation.

| Lifecycle | How it works | Best when |
|---|---|---|
| **Predictive (plan-driven, "waterfall")** | Scope, schedule and cost defined upfront; phases in sequence | Requirements stable; change is expensive late (construction, hardware, regulated builds) |
| **Iterative** | Repeated cycles refine a solution through feedback | Solution uncertain; learning needed |
| **Incremental** | Deliver usable parts in stages | Early value needed; scope divisible |
| **Agile** | Iterative + incremental in short cycles with continuous prioritisation | Requirements evolve; fast feedback possible (software, digital products, marketing) |
| **Hybrid** | Mix of approaches across parts of the project | Different components have different uncertainty (e.g., building + app) |

## A decision framework

Score each factor from 1 (favours predictive) to 5 (favours agile):

```
Factor                                           Score (1–5)
Requirements clarity (clear = 1, emerging = 5)     __
Likelihood of change                               __
Cost of late change (high = 1, low = 5)            __
Ability to deliver in small, usable increments     __
Customer availability for frequent feedback        __
Team experience with agile practices               __
Contract/regulatory flexibility                    __
Average: 1–2 predictive | 2–3.5 hybrid | 3.5–5 agile
```

Use it to structure the conversation, not as a formula.

## Examples by industry

- **Construction of a hospital in Manchester:** predictive for the building, with agile methods for the patient-booking software and iterative design reviews with clinicians. Hybrid overall.
- **Mobile banking app in Karachi:** agile, with predictive elements for regulatory approvals and security testing milestones.
- **ERP rollout in Dubai:** often hybrid: phased (incremental) deployment by business unit, agile configuration sprints, predictive data migration and cutover plans.
- **Marketing campaign for a US retailer:** agile sprints for creative testing, fixed launch date for a seasonal event.

## Myths to avoid

- *"Agile means no planning."* Agile teams plan continuously, at several horizons (product vision, roadmap, release, sprint, day).
- *"Predictive means no change."* Predictive projects handle change through formal change control.
- *"Hybrid means doing both badly."* Well-designed hybrids assign each approach where it fits and define clear integration points.
- *"Agile is faster."* Agile can deliver value earlier and reduce the risk of building the wrong thing, but total effort is not automatically lower.

## Integration points in hybrid projects

When different parts use different lifecycles, define:

1. **Shared milestones** (e.g., building handover date that the software must meet).
2. **Interface contracts** (data formats, APIs, physical interfaces).
3. **Common governance and reporting** (one board, one risk register, consistent status definitions).
4. **Synchronisation cadence** (e.g., the agile team's quarterly planning aligns with the master schedule's monthly update).

## Worked example

*Illustrative.* A fictional logistics company in Jeddah is building a new warehouse with an automated sorting system and a warehouse management app. The team applies the framework: building (score ~1.5, predictive), sorting system hardware (~2, predictive with iterative testing), app (~4, agile). Governance uses one board with tolerances; the app team works in two-week sprints and aligns its release plan to three master-schedule milestones: system integration test, operational readiness, go-live. Dependencies are tracked in a single integrated risk and dependency log.

## Quick self-check

If someone asks why your project uses its lifecycle, can you answer with reasons tied to requirements clarity, cost of change and stakeholder availability? If the only answer is "that is how we always do it", revisit the choice.

## Explaining the choice to stakeholders

Stakeholders used to one approach may be uneasy with another. Executives accustomed to fixed plans may worry that agile means "no commitments"; engineers used to agile may resist gate reviews. Explain the choice in terms of risk: "We are fixing the building design early because changes after construction starts are very expensive, and we are developing the app in short cycles because we do not yet know exactly how warehouse staff will use it." Then show how each approach will be reported, so nobody feels they are losing visibility. Revisit the choice at major gates. If requirements stabilise, a component may move toward more predictive planning; if uncertainty grows, more iteration may be needed.

## Tailoring within a lifecycle

Every lifecycle can be tailored. A predictive project can use short feedback loops for design reviews, and an agile team can keep a lightweight milestone plan for external dependencies.

## Hands-on: a lifecycle scorecard in Excel

```text
Rows 2–8: the seven factors | Columns C, E, G: scores per workstream (1–5) | D, F, H: one-line rationale
C10  Average           =AVERAGE(C2:C8)
C11  Indication        =IFS(C10<2,"Predictive",C10<=3.5,"Hybrid",TRUE,"Agile")
C12  Spread check      =MAX(C2:C8)-MIN(C2:C8)      (a spread ≥ 3 means the factors disagree: discuss before deciding)
Summary sentence       ="We will deliver "&C1&" using a "&LOWER(C11)&" approach because "&D2&"."
```

Thresholds follow the framework in the lesson; they structure discussion and are not a rule.

## Template: integration points for a hybrid project

| Integration point | What it contains | Owner | Cadence |
|---|---|---|---|
| Shared milestones | 3–6 dated events all workstreams plan towards | PM | Reviewed monthly |
| Integrated RAID | Risks, assumptions, issues, dependencies across workstreams | PM + leads | Weekly |
| Dependency board | Who needs what from whom, by when | Workstream leads | Weekly |
| Release-to-milestone confidence | Burnup converted to probability of meeting each milestone | Product owner | Each sprint |

## How to measure success

- Lifecycle choice documented with rationale for each workstream.
- Milestone confidence reported from agile burnups, not assumed.
- Dependency slips visible at least two weeks before they hit a milestone.

## Video lecture: Choosing a delivery lifecycle: predictive, agile or hybrid

Lecture coming soon · 10 chapters · about 9 minutes. Read the full transcript below.

1. Predictive, agile or hybrid?
2. Why it matters
3. The concept: seven factors
4. Worked example one: two contrasting projects
5. Worked example two: a Jeddah warehouse
6. Examples by industry
7. Watch me do it: scoring and explaining the choice
8. Myths and integration points
9. Explaining the choice to stakeholders
10. Recap and try this now

## Lecture transcript

### Predictive, agile or hybrid?

Here's an argument I've heard in many organisations. One camp says: we need detailed plans, fixed scope and proper control, so predictive is the only responsible approach. The other camp says: plans are fiction, we need agility, so everything should be Scrum. Both are right, sometimes. Both are wrong, often. The lifecycle is a tool, and the right tool depends on the work. In this lecture you'll learn a simple framework for choosing between predictive, agile and hybrid approaches, see how the choice differs across industries, bust some common myths, and learn how to integrate different lifecycles within one project. By the end, you'll be able to score a project and explain your choice to a sceptical sponsor in plain language.

### Why it matters

Why does it matter? Because the wrong lifecycle creates predictable pain. Use a predictive approach on work where requirements are genuinely uncertain, and you'll discover what users really need only at the end, when change is most expensive. Use a purely agile approach on work with fixed physical or regulatory constraints, such as a building or a certified system, and you'll get the illusion of flexibility where none exists. The good news is that the choice isn't all-or-nothing. Most real projects contain different kinds of work, and the best project leaders match the approach to each part.

### The concept: seven factors

Here's the framework from the lesson. Score each factor from one, which favours predictive, to five, which favours agile. How clear are the requirements? How likely are they to change? What's the cost of late change? High cost favours predictive. Can the work be delivered in small, usable increments? Is the customer available for frequent feedback? How experienced is the team with agile practices? And how flexible are the contract and regulatory constraints? Average the scores. Roughly one to two suggests predictive, two to three and a half suggests hybrid, and three and a half to five suggests agile. Think of it like choosing a route: a motorway when you know exactly where you're going, local roads when you need to explore. Use the scores to structure the conversation, not as a formula.

### Worked example one: two contrasting projects

Let's score two projects in the same organisation. First, a payroll change to meet a new legal requirement, with a fixed deadline. Requirements are defined by the regulation, so clarity scores one. Change is unlikely, one. Late change is costly, one. Increments aren't very useful, because the change is either compliant or it isn't, two. The business is available, three. Team experience, two. Regulatory flexibility, one. Average: about one point six. Predictive. Second, a new feature in the customer mobile app. Requirements are emerging, four. Change is likely, five. Late change is cheap, four. Small increments are easy, five. Customers can give feedback through testing, four. The team knows Scrum, four. Few external constraints, three. Average: about four point one. Agile. Same company, same month, different lifecycles, both correct.

### Worked example two: a Jeddah warehouse

Now the realistic example from the lesson. A fictional logistics company in Jeddah is building a new warehouse with an automated sorting system and a warehouse management app. The team scores each part. The building scores about one and a half: predictive. The sorting hardware scores about two: predictive, with iterative testing. The app scores about four: agile. So the project is hybrid. Governance uses one board with tolerances. The app team works in two-week sprints and aligns its release plan to three master-schedule milestones: system integration test, operational readiness and go-live. Dependencies between the building, the hardware and the app are tracked in one integrated risk and dependency log. Nobody has to pretend the building is agile, or that the app can be fully specified up front.

### Examples by industry

Let's look at typical patterns across industries, remembering they're tendencies, not rules. Construction and infrastructure are mostly predictive, because physical work is expensive to redo, but design stages often iterate with the client. Software products are mostly agile, because user needs emerge and releasing small increments is cheap. ERP implementations and regulated IT are often hybrid: configuration and user experience iterate, while data migration, integration and cut-over follow a tight plan. And events and marketing campaigns have an interesting shape: the date is fixed and immovable, but the content can flex, so teams often plan backwards from the date and prioritise content in short cycles. When you see your project in one of these patterns, ask where it differs, because those differences are exactly where a tailored choice pays off.

### Watch me do it: scoring and explaining the choice

Let me show you how I run this with a team. Workstreams across the top, the seven factors down the side. We score each cell together, and, this is important, I type a one-line reason next to each score, because the reasons are what convince a sponsor later. The spreadsheet averages each column and labels the zone. Then I write a two-sentence explanation for stakeholders. Something like: we'll build the warehouse and install the sorting system to a fixed plan, because their requirements are clear and changes are expensive; the app will be developed in two-week sprints, because user needs will emerge as operations staff try it, and all three will come together at three shared milestones. That's it. Two sentences, and nobody needs to know the word 'hybrid' to understand it.

### Myths and integration points

A few myths to retire. Agile doesn't mean no planning or no documentation; it means planning continuously at the right level of detail. Predictive doesn't mean no feedback; good predictive projects prototype, test early and iterate within phases. And hybrid doesn't mean doing both badly. It means being deliberate about where each approach applies and how they connect. The integration points are what make hybrid work: shared milestones that every workstream plans towards, one integrated risk and dependency log, a dependency board reviewed regularly, and one governance structure that respects different working rhythms. Remember too that tailoring happens within a lifecycle: a predictive project can still use short feedback loops, and an agile team can still keep a milestone plan for external commitments.

### Explaining the choice to stakeholders

Once you've chosen, you have to explain it, often to people who have no interest in methodology debates. My advice: talk about outcomes, not frameworks. Say what will stay fixed, such as the go-live date and the compliance scope. Say what can flex, such as app features beyond the must-haves, and who decides the trade-offs. And say how progress will be visible: for example, a working demo every two weeks and a milestone report every month. Executives mostly want to know three things: will we hit the date that matters, what are we committing to, and how will I know if it's going wrong? Answer those, and the lifecycle choice becomes obvious and uncontroversial. Lead with jargon, and you'll spend the meeting defending a word instead of agreeing a plan.

### Recap and try this now

Let's recap. There's no single best lifecycle. Predictive suits clear, stable requirements with a high cost of late change. Agile suits emerging requirements, cheap change, small usable increments and available customers. Hybrid combines them where a project contains different kinds of work, connected by shared milestones, an integrated risk and dependency log and one governance structure. Score the seven factors with your team, record the reasons, and explain the choice in plain language. Your try-this-now: score a current or recent project using the framework, workstream by workstream if it's mixed, and write a short justification for the approach you'd choose, in two sentences a non-specialist sponsor would understand.

## Video transcript

Which delivery approach should your project use: predictive, agile or hybrid? Let's make that choice deliberately. Start with four questions. How clear are the requirements today? How likely are they to change? How expensive is it to change things late? And can you deliver something useful in small pieces and get fast feedback from real users? If requirements are clear and late change is expensive, think of a bridge, a hospital building or a regulated hardware product, a predictive approach makes sense. You plan the scope, schedule and budget upfront and control change formally. If requirements are emerging and you can put small increments in front of users quickly, think of a mobile app or a digital service, agile makes sense. You plan continuously, deliver in short cycles, and let feedback steer priorities. Many real projects are both. A new warehouse needs a predictive plan for the building and an agile approach for the warehouse app. That is hybrid, and it works when you define the seams: shared milestones the app must meet, clear interfaces between systems, one board, one risk and dependency log, and a regular rhythm where the agile plan and the master schedule are synchronised. Watch out for a few myths. Agile does not mean no planning. Predictive does not mean no change. And agile is not automatically cheaper; its big advantage is reducing the risk of building the wrong thing. So choose on evidence, explain your reasons to stakeholders, and revisit the choice if conditions change.

## Key takeaways

- Choose lifecycles by requirements clarity, likelihood and cost of change, increment feasibility and stakeholder availability.
- Predictive suits stable, costly-to-change work; agile suits evolving requirements with fast feedback.
- Hybrid applies each approach where it fits, with defined integration points.
- Agile still plans continuously; predictive still handles change through change control.

## Try it

Score a current or recent project using the lifecycle decision framework and write a short justification for the approach you would choose.

- [Previous: Standards and methods: PMBOK 8, PRINCE2 7, ISO 21502 and Scrum](https://optimizeall.com/learn/project-management-leadership-with-ai/standards-and-methods-landscape)
- [Next: The business case and benefits realisation](https://optimizeall.com/learn/project-management-leadership-with-ai/business-case-and-benefits)
- [All lessons of Project Management Leadership with AI](https://optimizeall.com/learn/project-management-leadership-with-ai)