Choosing a delivery approach

Lesson 1 described why agile approaches exist. This lesson asks the practical question every project faces early: how should this work be delivered? The answer is rarely "all predictive" or "all agile". It is usually a deliberate mix, chosen part by part and revisited as the project learns. The PMBOK Guide, eighth edition, calls this tailoring, and the 2026 exam rewards answers that tailor thoughtfully instead of applying one method everywhere.

A spectrum of life cycles

It helps to think of delivery approaches as a spectrum defined by two questions: how often are requirements revisited, and how often is something usable delivered? A predictive life cycle defines requirements early and delivers once at the end. An iterative life cycle repeats cycles of building and refining a solution to improve it, but may still deliver once. An incremental life cycle delivers usable pieces in sequence, each adding to the last, while the overall scope may be fixed. An adaptive (agile) life cycle is both iterative and incremental: requirements are refined every cycle and usable increments are delivered frequently.

The second edition of PMI's Agile Practice Guide encourages thinking about this as a continuum rather than four boxes, and avoids treating "hybrid" as a single method. A team can be mostly predictive with a few adaptive practices, such as frequent stakeholder demonstrations, or mostly agile within a predictive governance frame, such as stage gates for funding. The exam often describes such mixtures and asks what to do next, so recognizing where on the spectrum a situation sits is a useful first step.

Factors that shape the choice

No single factor decides the approach. Several pull in different directions, and the project manager weighs them with the sponsor, the team and other stakeholders. The most important are the following.

Regulation deserves a careful reading. Heavily regulated work is not automatically predictive. A medical device or a payroll system can be developed in iterations, provided the evidence that regulators require is produced along the way. What regulation does demand is traceability, documented verification and controlled releases, which agile teams can build into their definition of done. What makes something genuinely predictive is when a physical or legal step cannot be undone, such as pouring a slab or filing a permit application.

A simple suitability assessment

Many organizations use a short scored questionnaire, sometimes called a suitability filter, to start the conversation. Each component of the work is scored on a few criteria; low scores suggest predictive, high scores adaptive and middling scores a tailored mix. The scores are not a verdict. Their value lies in making assumptions visible so that the people involved can discuss them. The Project Compass team scored its four main components on five criteria, using 1 for conditions that favour predictive and 5 for conditions that favour adaptive.

# Suitability scores (1 = suits predictive, 5 = suits adaptive) for each Compass component.
criteria = ["Requirements clarity", "Cost of change late", "Feedback available early",
            "Regulatory and contract limits", "Team and stakeholder availability"]
scores = {
    "Fit-out":            [2, 1, 1, 1, 3],
    "RFID tagging":       [2, 2, 3, 3, 3],
    "Kiosks and gates":   [2, 2, 2, 2, 3],
    "Mobile app":         [5, 4, 5, 3, 4],
}
for part, s in scores.items():
    avg = sum(s) / len(s)
    lean = "adaptive" if avg >= 3.5 else "predictive" if avg <= 2.5 else "either; tailor"
    print(f"{part:<18} average {avg:.1f} -> {lean}")

Fit-out            average 1.6 -> predictive
RFID tagging       average 2.6 -> either; tailor
Kiosks and gates   average 2.2 -> predictive
Mobile app         average 4.2 -> adaptive

The results match intuition but add nuance. The fit-out scores lowest: once walls are framed and conduit is run, changes are expensive, and nobody can use half a library. The app scores highest. RFID tagging lands in the middle: the work is well defined, but it can be delivered collection by collection with feedback after each, so the team tailored it as an incremental rollout with a predictive plan and short weekly reviews. Kiosks lean predictive because they are bought under a fixed-price incentive contract, with acceptance testing at delivery.

Complexity: why some work cannot be fully planned

A useful way to explain the choice to stakeholders uses two dimensions: how much agreement there is about what is needed, and how certain the technology or method is. When both are high, the work is simple and a plan works well. When both are low, the situation is chaotic and the first job is to stabilize it. In between lies complicated work, where experts can analyse the problem in advance, and complex work, where cause and effect are only clear in hindsight and the best strategy is to probe, sense and respond. Agile methods are designed for the complex zone.

The Cynefin framework, developed by Dave Snowden, uses similar categories (clear, complicated, complex, chaotic) and is often cited in agile literature. For the exam you do not need the details of any one model; you need the idea that the right approach depends on how predictable the work is, and that predictable and unpredictable parts can sit inside the same project.

Tailoring within a chosen approach

Choosing a life cycle is only the first tailoring decision. Within it, the team tailors processes, artifacts and ceremonies to the project's size, criticality and context. A small internal project might use a one-page charter and a simple Kanban board. A large, high-risk program might add architecture runways, formal risk reviews and integrated release planning across teams. The PMBOK Guide describes tailoring as selecting, adjusting and combining practices, and it expects the tailoring decisions themselves to be recorded and revisited.

The project manager's role in tailoring is to facilitate the decision, not to impose a favourite method. That means involving the team, which knows how the work actually gets done, the sponsor, who owns the risk appetite and funding model, and any governance bodies, such as a PMO that sets minimum reporting standards. Tailoring decisions are revisited at retrospectives and phase reviews; if the RFID rollout's weekly reviews add no value after the first two collections, the team can drop them.

Organizational readiness

An approach that suits the work may still fail if the organization is not ready for it. Agile approaches assume a product owner with real decision authority who is available to the team, team members dedicated to the work rather than spread across five projects, managers comfortable with teams planning their own work, and funding that can follow capacity rather than fixed scope. When these conditions are missing, the project manager can either adapt the approach, for example a hybrid with shorter planning horizons, or work with leaders to build readiness gradually, often starting with a pilot.

Project Compass faced exactly this. The library had never run an agile project, and its procurement rules assumed fixed-price contracts. The project manager worked with the sponsor and the purchasing office to justify a time and materials contract with a ceiling for the app (PMP-131, lesson 8), and arranged for the digital services manager, Amara Osei, to spend most of her week as product owner. Without those two changes, the app would probably have been forced into a fixed specification written before anyone had seen a prototype.

Transitioning between approaches

Delivery approaches can change during a project. A product might be explored iteratively through prototypes, then built incrementally, and finally moved into a stable, predictive maintenance phase. A project that started predictively may switch to iterations when it becomes clear that requirements are far less stable than assumed. Such changes should be explicit decisions, recorded with their reasons and communicated to stakeholders, because they change how progress is measured and how decisions are made.