1.2. How Projects Deliver Value
Knowing what a project is doesn't tell you how to run one. That's where approach comes in — and this is the decision that quietly shapes almost every other topic in this guide, because Domains 2 and 3 are essentially "predictive, in depth" and "adaptive, in depth."
💡 First Principle: A project delivers value by moving through a life cycle — a sequence of phases from start to finish — but how much is planned in advance versus discovered along the way is a choice, not a fixed rule. That choice is what separates predictive from adaptive approaches.
The project life cycle, at a high level. Every project, regardless of approach, moves through some version of: starting the work (initiating), figuring out how it will get done (planning), doing it (executing), keeping it on track (monitoring and controlling), and wrapping it up (closing). Predictive and adaptive approaches both contain these ideas — they just distribute when and how often planning happens very differently.
Predictive vs. adaptive, conceptually. A predictive (plan-based, "waterfall") approach front-loads detailed planning: scope, schedule, and budget are defined in detail up front, and change is managed through a formal control process because the plan is the baseline everything gets measured against. An adaptive approach — the umbrella term for agile ways of working — plans just enough to start the next short iteration, delivers a working increment, gets feedback, and replans. Change isn't a deviation to control in adaptive work; it's an expected input the next iteration is designed to absorb.
| Predictive | Adaptive | |
|---|---|---|
| When is detailed planning done? | Mostly up front | Continuously, iteration by iteration |
| How is change handled? | Formal change control against a baseline | Expected and welcomed each iteration |
| Best fit when... | Requirements are well understood, stable, and the cost of late change is high (e.g., construction, regulated industries) | Requirements are expected to evolve and stakeholder feedback needs to shape the product early and often (e.g., new software features) |
| Progress is visible as... | % complete against the baseline plan | Working increments delivered each iteration |
⚠️ Exam Trap: Do not assume every question set describes a purely predictive or purely agile project. The CAPM tests hybrid thinking on purpose — a single scenario can blend a predictive schedule baseline with an adaptive product backlog. Read what the scenario is actually describing (a sprint and a backlog vs. a Gantt chart and a change request) rather than assuming the whole exam, or even the whole question block, stays in one lane. Consecutive questions can switch approach entirely.
Projects as a vehicle for change. One more first-principles idea ties this phase together: organizations don't run projects for their own sake. A project exists because the organization wants something to be different afterward — a new capability, a fixed problem, a market opportunity captured. That's what "a project is a vehicle for change" means on the exam: every project should trace back to an intended benefit. This is also why benefit realization and value delivery show up as recurring phrases across all four domains — PMI wants associate-level practitioners thinking past "did we finish the deliverable?" toward "did the deliverable actually produce the change we set out to make?"
Why Care
If you only remember one thing from Phase 1, make it this: almost every wrong answer choice on this exam is wrong because it either (a) misclassifies the type of work (project vs. operations vs. program vs. portfolio) or (b) applies the wrong approach's logic to a scenario (treating an adaptive backlog like a fixed baseline, or vice versa). The domain-specific content in Phases 2 through 5 gives you the vocabulary; this phase gives you the filter for deciding which vocabulary applies.
