Choosing a delivery lifecycle: predictive, agile or hybrid

0:00 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.

0:53 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.

1:35 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.

2:33 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.

3:29 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.

4:25 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.

5:22 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.

6:19 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.

7:12 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.

8:09 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.