Lesson 3 — Project Delivery Methodologies

Module 3, Unit 2 | Lesson 3 of 3

By the end of this lesson, you will be able to:

• Explain why delivery methodology is a governance choice rather than a workflow preference (K7, K24)
• Compare Agile, Waterfall, and Hybrid approaches as control systems for AI initiatives (K13, S3)
• Translate a chosen methodology into a credible roadmap, timeline, and governance cadence (S4)
• Recognise the AI-specific failure modes that each methodology helps or hurts (B1, B2)

Why delivery method is a governance decision

By the time a project reaches delivery, most teams believe the hard work is behind them. The problem is defined, the scope feels stable, the value case is starting to sound persuasive. This is exactly when delivery failure becomes most likely — not because the idea is weak, but because the delivery architecture is not credible.

Methodology is not a workflow preference. It is the structure that turns an initiative into something governable. It determines how uncertainty is handled, when decisions are made, what evidence is produced to demonstrate progress, and how quickly leadership can intervene if delivery starts drifting. Choose a methodology by habit, and you have not chosen a workflow — you have chosen a governance rhythm by accident.

AI and automation initiatives make this choice harder, because they combine two different realities. Part of the work is exploratory: data quality, model feasibility, and integration behaviour often cannot be confirmed without testing. Another part of the work is highly accountable: organisations still require plan discipline, budget control, documented assumptions, and decision gates. Responsible AI guidance increasingly treats oversight as a lifecycle obligation rather than a one-time sign-off, which means delivery needs built-in review points — not just a final launch moment.

🔑 Key term: Delivery methodology — the structure through which a project's work is organised, reviewed, and controlled over time. Methodology determines governance rhythm: how uncertainty is handled, when decisions are made, what counts as evidence of progress, and where sponsors can intervene.

Methodology as a control system

Underneath the labels — Agile, Waterfall, Hybrid — every methodology is doing four governance jobs. Comparing methodologies productively means comparing how each one does each job, not which one is fashionable.

The first job is handling uncertainty. Some methodologies attempt to reduce uncertainty up front through detailed requirements and design. Others accept uncertainty as inevitable and design the work to absorb it through learning cycles. Neither is inherently right; the question is which strategy fits the uncertainty you actually have.

The second job is demonstrating progress. In some approaches, progress is measured by completion of phases and approved documents. In others, progress is demonstrated by working outputs that change and improve. The choice matters because it determines what a sponsor can see when they ask "where are we?"

The third job is shaping stakeholder engagement. Some methodologies expect periodic review at major milestones; others require continuous collaboration. AI initiatives are particularly sensitive here, because operational and governance stakeholders are often not available for the kind of constant engagement that pure Agile assumes.

The fourth job is enabling intervention. Methodology determines how quickly leadership can pause, redirect, or stop a project when risk exposure changes. A methodology that produces no decision points until launch is a methodology that produces no opportunities to govern.

Most AI initiatives sit between extremes. The technical work needs experimentation; the organisational environment expects defined milestones, budgets, and checkpoints. That is why hybrid approaches have become so common — but choosing hybrid as a default, without thinking about which parts need control and which need iteration, recreates the same governance gap in disguise.

The Agile family

Agile is not one methodology. It is a family of approaches built on a shared idea: when requirements are uncertain, don't try to define the whole solution up front — instead, deliver in short iterative cycles, learn from each one, and adjust priorities as the picture clarifies.

The most widely used Agile frameworks are Scrum, Kanban, Extreme Programming (XP), and the Crystal family.

Scrum organises work into fixed-length sprints (typically two to four weeks). Each sprint produces a working increment that stakeholders review. A Product Owner manages priorities through a backlog; a Scrum Master facilitates the process; the development team delivers. Sprint reviews and retrospectives create predictable points where both the product and the way of working can be inspected and adapted. Scrum's strength is the regular cadence — for AI work, those review points double as governance checkpoints.

Kanban focuses on the flow of work through a visual board: tasks move from To do through In progress to Done. Instead of fixed iterations, Kanban limits work in progress — the team can only have so many items in flight at once — which forces prioritisation and exposes bottlenecks. Kanban suits steady streams of similar work (operational support, model retraining cycles, ongoing data quality fixes) where new sprints add ceremony without adding control.

Extreme Programming (XP) is the most engineering-intensive of the four. It pairs short iterations with strong technical practices — test-driven development, continuous integration, pair programming, refactoring. XP is most useful when the technical risk is high and the cost of brittle code over time would dominate the project. For AI work, the same logic applies to ML pipelines, where reproducibility and tested data flows matter more than feature velocity.

Crystal is a family of methodologies that scale practices to the size and criticality of the project. A small low-criticality project uses Crystal Clear; a larger or higher-criticality project uses Crystal Yellow or Orange, with progressively more documentation and review. Crystal makes explicit something the others leave implicit: that the right amount of process depends on the cost of failure.

Doing this with AI

Ask the model to compare the four Agile frameworks against your specific project context rather than in the abstract: "Given a six-month project to build a customer-support classifier with two data scientists, weekly governance reviews, and a fixed pilot deadline, which Agile framework fits best — and what would I have to compromise to make each of the others work?" Forcing the comparison through your constraints exposes which framework is actually plausible.

Waterfall: sequential phases and stage gates

Waterfall organises work into a sequence of phases — typically requirements, design, development, testing, deployment, maintenance — where each phase is completed and formally approved before the next begins. Between phases sit stage gates: governance checkpoints where sponsors review evidence and decide whether the project should continue, adjust, pause, or stop.

That structure is sometimes mocked as outdated, but it is doing real governance work. Stage gates produce explicit continuation decisions backed by documented evidence. In environments with large financial commitments, regulatory obligations, or significant operational risk, that visibility is exactly what governance requires.

Waterfall is most appropriate when requirements are stable and well understood, when the cost of post-development changes is high, and when traceability and auditability matter — regulated reporting systems, infrastructure builds, enterprise platform implementations. Where it struggles is in projects that depend on experimentation: a strictly sequential plan locks in design choices before the team has learned what is feasible, which in AI work is usually a recipe for late-discovered failure.

Did you know?

The Waterfall model is widely attributed to a 1970 paper by Winston Royce, but Royce himself argued against using a strictly sequential approach. He presented the linear model as a strawman to introduce the problems with it, and his actual recommendation was to build prototypes early and iterate based on what they revealed. The famous diagram of "Waterfall" that propagated for decades was lifted from his paper without the surrounding warning. It is one of software engineering's most successful cases of a footnote becoming the canon.

Hybrid: governance rhythm separate from development rhythm

Hybrid delivery takes the move that AI initiatives almost always need: it separates the governance rhythm from the development rhythm. Stage-gated planning at the front (feasibility, architecture approval, funding decisions); iterative Agile development through the build and pilot phases; defined gates again at deployment.

The defining characteristic is therefore not "some Waterfall, some Agile" but a deliberate decision about which rhythm each phase needs. Sponsors retain the structured checkpoints they need to allocate budget and approve scope. Delivery teams retain the flexibility to adapt as data, models, and integrations reveal what is actually possible.

A typical hybrid structure for an AI initiative runs through six phases with four gates: an Initiation and Feasibility phase ending in a feasibility gate; a Planning and Architecture phase ending in a delivery-architecture gate; Iterative Development through Agile cycles; a Pilot phase ending in a pilot evaluation gate; Deployment ending in a go-live gate; and ongoing Continuous Improvement.

Hybrid delivery is now the dominant pattern for AI and digital transformation work for a reason: leadership still expects budget accountability and clear decision gates, but the solution itself often only emerges through iterative experimentation. The risk in hybrid is the opposite of the risk in pure methods — without clear boundaries, it can drift into "Agile until convenient, Waterfall when something breaks." The discipline is in defining, in advance, which phases are governed how.

💬 Reflection

Which methodology does your current project actually need — and which one is it currently using? If those two answers differ, the gap usually shows up in one of three places: missed governance reviews, scope expansion that no one formally approved, or pilot results that arrive too late to influence the build. Pick the one that worries you most and trace it back to a methodology choice.

From methodology to plan: roadmaps, timelines, schedules

Choosing a methodology is necessary but not sufficient. Sponsors do not fund methodologies; they fund a plan they can read, track, and intervene in. Roadmaps, timelines, and schedules are the artefacts that make a methodology choice into a visible sequence of commitments.

A roadmap is the high-level picture of direction and sequencing — the outcomes you intend to deliver, the order they arrive in, and the assumptions behind that order. It is the document that aligns multiple stakeholders around what comes next and why that order.

A timeline attaches dates to the roadmap. It forces the question that matters most for delivery credibility: what has to be true by when. A Gantt chart is one common timeline representation — bars across time, with dependencies and the critical path made visible. A sprint schedule does the equivalent job for Agile delivery: a fixed calendar of time-boxed cycles, with the ceremonies that create governance rhythm sitting on top.

These artefacts are not interchangeable. Roadmaps communicate direction; timelines commit to dates; Gantts expose dependencies; sprint schedules define cadence. Trying to satisfy sponsors, delivery teams, and governance with a single artefact usually satisfies none of them.

Three principles tend to separate plans that hold from plans that don't. First, define phases around decisions, not activities — what does each phase enable the organisation to decide? Second, make milestones binary and evidence-based — "data access approved and pipeline running" is a milestone; "data work progressing" is not. Third, attach assumptions and tolerances explicitly: a credible plan states what it assumes about access, resourcing, stakeholder availability, and approval timelines, and what it will do if those assumptions fail.

In AI initiatives, the most common planning failure is scheduling only the build. Data access slips. Feature engineering takes longer than expected. Evaluation requires iteration. Governance work — documentation, controls, sign-off — is real work that has to be in the plan. A plan that schedules only development is not a plan; it is an optimism statement.

Doing this with AI

Once you have a draft roadmap, paste it back to the model with this prompt: "Identify any milestone here that is not binary, any phase that describes activity rather than a decision, and any dependency that is implied but not stated. Then list the three assumptions most likely to break this plan." The model is reliably better at stress-testing a plan than at writing one — use it accordingly.

Project Activity — Complete sections 4.1 and 4.2: delivery method and timeline

Open the Module 3 Project workbook and complete section 4.1 Choose methodology and section 4.2 Timelines.

1. Choose a methodology or hybrid approach and name the variant clearly: for example, Scrum with two-week sprints, Kanban with monthly governance review, Waterfall with formal stage gates, or Hybrid with Agile delivery inside governance gates.
2. Explain why that methodology fits the uncertainty, regulatory context, stakeholder availability, and decision rhythm of your initiative.
3. Name the compromise. Every methodology makes something harder; write how you will compensate.
4. Build the timeline as a Gantt chart, sprint schedule, or roadmap. Define phases around decisions and milestones around evidence.
5. Add the assumptions most likely to break the timeline and what you will do if they do.

Project Checklist

• Section 4.1 names the methodology and variant, not only "Agile" or "Waterfall".
• The methodology choice is justified as a governance decision.
• I have named what the methodology makes harder and how I will manage that compromise.
• Section 4.2 contains a timeline appropriate to the methodology.
• Phases are framed around decisions the organisation can make.
• Milestones are binary and evidence-based.
• The plan includes data access, evaluation, documentation, sign-off, training, and rollout work, not only build activity.
• The timeline includes assumptions and tolerances for slippage.

Quick Check

Unit 2 KSB summary

By the end of Unit 2, you can write a goal that holds up, draw scope boundaries that prevent drift, and translate the work into a delivery methodology and timeline that makes the project governable.

Knowledge: K3 (project definition), K7 (delivery methodologies), K13 (governance rhythms), K21 (scope frameworks), K24 (success metrics for AI)

Skills: S3 (scope management), S4 (translating goals into measurable deliverables), S5 (methodology selection), S15 (timeline construction), S22 (assumption documentation), S24 (sprint and stage cadence)

Behaviours: B1 (commitment to falsifiable goals), B2 (scope discipline), B3 (proportionality in process choice), B4 (transparent estimation)

⏭️ Up next — Unit 3: Unit 2 has equipped you with the structures that make an AI initiative deliverable. Unit 3 turns to the analyses that test whether it is worth doing — risk identification and response, whole-life budget construction, and the impact and financial evaluation metrics that decide which AI initiatives get funded.