5.1. When to Use a Predictive Approach
💡 First Principle: Predictive approaches trade flexibility for certainty — they fit best when requirements are well understood up front and the cost of discovering a problem late (after a foundation is poured, after a regulatory submission is filed) is much higher than the cost of extra upfront planning.
Organizational structure fit. This mirrors Phase 4.1's adaptive suitability table, flipped:
| Organizational Structure | Predictive Suitability | Why |
|---|---|---|
| Hierarchical/functional | High | Clear approval chains match predictive's formal change-control philosophy |
| Matrix structure | Moderate-to-high | Works well when governance and reporting lines stay clear despite shared resources |
| Colocated/virtual team | Neutral | Location matters less when the plan itself, not proximity, drives coordination |
Activities within each process. Predictive work still moves through the same five process groups introduced in Phase 1, just with heavier upfront weight in planning:
| Process Group | Typical Activities |
|---|---|
| Initiating | Developing the project charter, identifying initial stakeholders |
| Planning | Building the WBS, schedule, cost baseline, risk register, quality plan |
| Executing | Producing deliverables according to the plan |
| Monitoring & Controlling | Measuring variance against baselines, processing change requests |
| Closing | Formal acceptance, releasing resources, capturing lessons learned |
Distinguishing project components. A recurring associate-level skill is telling apart the levels of a predictive project's breakdown:
| Component | What It Is |
|---|---|
| Phase | A major grouping of related project activities, usually ending in a milestone or deliverable |
| Deliverable | A specific, verifiable product or result produced by the project |
| Work package | The smallest unit of the WBS — a piece of work that can be reliably estimated and assigned |
| Activity/task | A specific action performed to produce a work package |
⚠️ Exam Trap: Don't let a 17% domain weight talk you into under-preparing this content. Critical path questions, schedule and cost variance calculations, and WBS/work-package distinctions show up embedded inside scenario questions tagged to other domains just as often as they show up in Domain 2 questions directly.
A monitoring gap hides behind good planning. A common scenario pattern: a project has a detailed upfront plan, a hierarchical approval structure, and every predictive artifact you'd expect — yet stakeholders are still blindsided by a cost overrun that only surfaces at closeout. This isn't a contradiction. Good planning establishes the baseline to measure against; it doesn't automatically mean anyone is consistently checking actual performance against that baseline throughout execution. A well-planned project can still fail at monitoring and controlling if variance analysis isn't happening regularly and consistently — the plan being solid doesn't guarantee the ongoing discipline of comparing reality to it, and the exam expects you to recognize these as two separate failure points worth distinguishing, not one combined problem.
Predictive does not mean feedback-free. Choosing a predictive approach fixes scope and sequencing up front, but it still builds in structured feedback moments: phase-gate reviews, milestone sign-offs, and variance reports all exist to test the plan against reality. The difference from adaptive is where the feedback lands — in a predictive project it informs corrective action against a fixed baseline, while in an adaptive project it reshapes the backlog itself. A scenario describing a team that ignores new information until closure isn't describing predictive discipline; it's describing a monitoring failure.
