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, each phase running its own process groups — 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. A life cycle is the series of phases a project passes through from start to finish, and phases are named after the work or the deliverable — feasibility, design, build, test, deploy — not after project-management activity.

Those five familiar words — initiating, planning, executing, monitoring and controlling, closing — are the Process Groups, and they are a different axis entirely: groupings of processes that repeat within each phase. A build phase has its own initiating, its own planning, its own closing. Predictive and adaptive approaches both use the process groups; what differs is when and how often planning happens.

⚠️ Exam Trap: Do not answer "what are the phases of the project life cycle?" with initiating/planning/executing/monitoring/closing. Those are the Process Groups. Phases are named for the work being done, and every phase contains all five process groups.

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.

⚠️ 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.