1 Project Delivery Approaches and Decision Criteria

How delivery approaches differ

Project delivery approaches differ in how they plan work, handle uncertainty, and incorporate feedback. No single approach is best for every project: select and tailor one to fit the deliverables, constraints, and project environment. Planning is part of every approach; what varies is how much planning happens up front and how often plans are revisited.

Four approaches to delivery

A Predictive approach defines much of the scope and plan up front, then delivers through planned phases or a largely sequential process. Changes are assessed against the approved plan. It may suit work with well-understood requirements and solutions, plannable dependencies, or important cost, schedule, and formal approval baselines.

An Adaptive approach develops the solution through repeated cycles of learning, feedback, and adjustment. Scope or plans can be refined as knowledge grows. It may suit projects with uncertain requirements, unfamiliar technology, or an uncertain best solution, provided stakeholders can give feedback during delivery.

Agile is a way of working within the adaptive family, not simply another word for adaptive. It emphasizes collaboration, response to change, and frequent usable increments. Agile approaches generally combine iteration—learning and improving through repeated cycles—with incremental delivery, which adds usable portions of the result.

A Hybrid approach combines predictive and adaptive practices, such as predictive planning and governance around adaptive development, or different approaches for different components. It may fit projects where some parts are stable or tightly constrained while others are uncertain and benefit from iteration. It is a tailored combination, not necessarily an equal split between methods.

Conditions that shape the choice

Consider the project as a whole, then examine its components. The following factors should be considered together rather than treated as a single decisive test.

• Requirements and uncertainty: Stable, well-defined requirements support predictive planning. Volatile requirements, unresolved user needs, or unfamiliar technology favor adaptive work and early experiments.

• Nature of the deliverable: Products that can be built, tested, and released in useful increments may benefit from agile practices. Work that must be integrated into a single, tightly sequenced deliverable may need more predictive coordination.

• Risk, safety, and regulation: Mandatory approvals, traceability, testing, or documentation can require defined controls and evidence. These obligations do not automatically rule out adaptive development; required gates and records can be combined with iterative work inside them.

• Dependencies and external commitments: Long-lead procurement, fixed handoffs, contractual milestones, and interdependent teams may require early plans and coordinated milestones. Where feasible, uncertain portions can still be developed adaptively.

• Time, cost, and scope constraints: A fixed deadline or budget may make prioritization essential. If the solution is uncertain, adaptive delivery can help reveal what is feasible sooner, but it does not guarantee a fixed scope or eliminate risk.

• Stakeholder access and decision speed: Adaptive and agile approaches depend on timely feedback and decisions. If users or decision-makers are rarely available, stronger upfront definition, delegated decision authority, or a hybrid approach may be needed.

• Team and organizational capability: Consider team experience, collaboration, governance, tools, and the organization’s ability to support frequent review and change. Tailor the approach rather than choosing a label that the environment cannot sustain.

An uncertain solution alone does not make a project suitable for agile if users cannot review increments or the work cannot be divided meaningfully. Likewise, a regulated project may use adaptive development while retaining predictive approval points. Approach selection is a fit-for-purpose decision based on project characteristics and organizational needs.

Apply the criteria to project decisions

The examples show how different project conditions can lead to a tailored approach.

• Office renovation: The design, scope, permits, procurement, and construction sequence are largely defined, and work depends on inspections and contractors. A predictive approach may suit the main delivery plan. If occupants are unsure about workspace preferences, the team could test layouts or finishes with users before finalizing those elements.

• New customer-facing software: User needs and the most useful features are uncertain, and users can review working versions regularly. An adaptive, agile approach can deliver and test prioritized features in increments, using feedback to adjust the backlog.

• Regulated digital service: The release date, security controls, and audit evidence are fixed, but some user-facing functionality is still being discovered. A hybrid approach could use predictive governance, approval gates, and release planning while developing suitable features iteratively. The team must still meet all required controls.

A practical decision sequence is to ask:

1. How much is known?

2. Can the result be delivered in useful increments?

3. How quickly can stakeholders give feedback?

4. Which obligations or dependencies must remain fixed?

Select the approach, or combination of approaches, that handles uncertainty without compromising essential controls. Review the choice as project knowledge changes.

Putting the approaches together

Predictive approaches rely more on upfront definition and planned sequencing. Adaptive approaches learn and adjust through repeated cycles. Agile is an adaptive way of working centered on collaboration and frequent usable increments. Hybrid approaches combine practices to fit different parts or constraints of a project.

Choose based on uncertainty, deliverable structure, risk and compliance, dependencies, stakeholder availability, and team and organizational capability—not on the project label alone.