Most development approach decisions happen in a single meeting, driven by whoever talks loudest. The team that just finished a Scrum project votes for Scrum. The PMO that has a waterfall template votes for waterfall. The result gets labeled "hybrid" if neither side wins. Then the project pays for that non-decision for the next twelve months.
PMBOK 8 Section 4.3 treats approach selection as a structured analysis, not a preference poll. It introduces three distinct dimensions that must be evaluated together before you commit to a delivery model. Miss any one of them and you're building your plan on a false assumption.
The traditional question is binary: Is this project agile or waterfall? That framing collapses three separate problems into one, which means you can't solve any of them properly.
Consider a construction firm building a data center for a financial services client. The physical infrastructure is highly sequential — you can't pour the raised floor after the cooling units are installed. But the monitoring software running on that infrastructure has requirements that won't stabilize until the hardware is in place. Calling the whole engagement "waterfall" forces the software team into a requirements freeze they can't honor. Calling it "agile" creates chaos for the civil contractors who need firm specs six weeks out. Neither label fits because the project has multiple delivery realities happening simultaneously.
Section 4.3 doesn't ask you to pick a label. It asks you to evaluate three dimensions and let the approach emerge from the evidence.
The first lens is the product itself. PMBOK 8 directs you to examine factors including:
On Monday morning, this translates to a specific question you ask before the kickoff: If we delivered 60% of this product at the halfway point, would the client get measurable value? If yes, adaptive is on the table. If no, you need a very good reason not to go predictive.
The second lens is the organization delivering the project — not the organization it aspires to be, but the one that exists right now.
| Capability Area | Questions to Answer Honestly |
|---|---|
| Governance structure | Can the organization approve funding in increments, or does it require a full budget upfront? |
| Contracting models | Are vendor contracts fixed-price with defined scope, or do they support time-and-materials with flexible scope? |
| Tooling and process maturity | Does the organization have the infrastructure to support continuous integration, sprint ceremonies, and iterative reviews? |
| Culture of transparency | Will stakeholders accept incomplete work-in-progress reviews, or will every demo become an approval battle? |
This is where many hybrid approaches are actually born — not from strategic thinking, but from organizational constraints that nobody wanted to confront. A team that genuinely wants to work adaptively inside an organization with fixed-price contracts and quarterly budget cycles can't go fully adaptive. That's not a hybrid strategy; that's a constraint that needs to be named and managed explicitly.
The honest PM documents the constraint, communicates its impact, and selects an approach that works within the real system. The political PM calls it "hybrid" and hopes nobody notices the contradiction.
The third lens examines the human system doing the work. Section 4.3 directs attention to:
The last point is critical and routinely ignored. You cannot run genuinely adaptive delivery if the people who validate the output aren't available to validate it frequently. This is a project team factor that disqualifies adaptive approaches regardless of what the product characteristics suggest.
The power of this framework is that it forces you to look at conflicts between dimensions, not just score each one independently.
A product with highly volatile requirements (signals adaptive) inside an organization with fixed-scope contracts (signals predictive) with a team that's never worked iteratively (signals predictive) produces a clear answer: go predictive, invest heavily in requirements discovery upfront, and negotiate contract flexibility as a separate workstream. That's a real decision with a documented rationale.
A genuine hybrid is appropriate when different parts of the project genuinely score differently across dimensions — not when the organization can't make up its mind. For example, a product rollout where the core platform is built predictively against stable specifications, but the user experience layer is developed iteratively with end-user feedback, is a legitimate hybrid. The hybrid boundary maps to a real difference in the product, not to internal politics.
Section 4.3 won't do the work for you, but it gives you a structure to run a real analysis. Here's how to apply it in practice:
Organizations that default to the same approach on every project aren't being consistent — they're avoiding a hard conversation about what each project actually needs. That avoidance is expensive. Predictive projects that needed to be adaptive discover critical requirement gaps late, when change is most costly. Adaptive projects that needed to be predictive drift without boundaries, accumulating scope and burning budget with no clear completion criteria.
The three-dimensional framework in Section 4.3 isn't bureaucracy. It's the minimum analysis required to make an informed decision. Projects don't fail at delivery. They fail at selection.
PM Master generates a Charter, WBS, Risk Register and 20+ PMBOK® 8 documents from your notes.
Try it free →