PMP 2026 Study Vault

PMP Exam ↗

Project Life Cycles

14 min read

Project Life Cycles (PM Standard, Section 4)

A project life cycle is the series of activities and/or phases a project passes through from start to closure. It provides the foundational framework for managing the project regardless of the specific work or development approach. PMBOK 8 Standard Section 4 explores the life cycle through five factors:

  • Project phases
  • Project development approaches (predictive, adaptive, hybrid)
  • Considerations for selecting a development approach
  • Delivery cadence
  • Project Management Focus Areas (formerly known as Process Groups)

4.1 Project Phases

A project phase is a collection of logically related project activities that culminates in the completion of one or more deliverables and/or outcomes. Phases may be sequential, transitional, or overlapping — in some projects, a combination of these. Each phase may include one or more stages of the project life cycle.

Project life cycles are independent of product life cycles (the product life cycle can be part of the outcomes a project produces). Projects generate outputs which in turn enable outcomes that progressively realize the organization’s strategy.

Phase attributes

A phase can be described by attributes such as name, number, duration, resource requirements, entrance criteria (for moving into the phase), and exit criteria (for completing the phase).

Phase gates

A phase gate may occur after the end of a phase and before the beginning of the next. Phase gates often include a review — also known as stage gate, gate review, iteration review, or decision-point review — to check that desired outcomes or exit criteria have been achieved before proceeding.

Exit criteria may be tied to acceptance criteria for deliverables, contractual obligations, specific performance targets, or other tangible measures. Entry criteria are influenced by factors such as resource availability, verification of the project’s viability, and alignment with organizational goals.

At a phase gate, the project’s performance is compared against project and business documents that specify expectations. A go/no-go decision is made — possible outcomes include:

  • Continue to the next phase
  • Continue with modification
  • End the project or phase
  • Remain in the phase
  • Repeat the phase or elements of it
  • Park the project temporarily to address another urgent business initiative

Pre-phase gates (at the start of a phase, not just the end) can confirm proper alignment, sufficient resources and planning, and that risks have been addressed before progressing further.

Life cycle flexibility

Organizations with multiple projects often adopt a few standard life cycles. Where no standard exists, the PM and project team determine the best fit. The life cycle should be flexible enough to protect and enhance the value proposition — flexibility includes:

  • Selecting the development approach or mix of approaches
  • Identifying the types of processes and activities to perform
  • Adjusting the various attributes of an activity, phase, or process (name, duration, entrance criteria, exit criteria)

Characteristic patterns across the life cycle

PMBOK 8 (Figure 4-1) highlights how key variables typically move:

  • Cost and staffing — in many predictive scenarios, low at the start, increasing through execution, then dropping rapidly as the project or phase ends.
  • Risk and uncertainty — usually greatest at the start of the project or phase; decrease over the life cycle as decisions are reached and deliverables are accepted.
  • Stakeholder influence on change — in some scenarios, highest at the start (when scope can be influenced cheaply) and decreasing as the project progresses (when changes become costly). In other scenarios (adaptive), stakeholders participate actively during execution so feedback can detect risks and impacts earlier.

4.2 Development approaches

PMBOK 8 frames development approaches as a spectrum, not three discrete buckets:

Predictive ←——————— Hybrid ———————→ Adaptive
              Increasingly Iterative and Incremental

(Figure 4-2)

The project manager, in consultation with the project management team, chooses the approach based on the nature of the project. The main factors are the requirements, scope, timeline, and goals of the project; the organization’s culture and needs; and the level of stakeholder involvement, risk profile, technological considerations, and overall complexity.

When requirements are sufficiently clear and stable early, a predictive approach may be optimal — and the schedule + cost baselines are set against a defined scope. Scope + schedule + cost together form the Integrated Baseline.

When requirements are less clear or complexity is high, an adaptive approach may be optimal — work is reviewed periodically (often time-boxed) so feedback can be incorporated as the integrated baseline evolves. Different adaptive approaches yield different baseline sets, and adaptive projects often need to vary one set of constraints to hold others fixed — the inverted triangle concept (Figure 4-3): when scope is fixed, unexpected changes are managed by altering budget or schedule; when budget and schedule are fixed, unexpected changes are managed by varying scope. See Inverted Triangle.

4.2.1 Predictive approaches

Also called waterfall, plan-driven, or traditional. Optimal when scope can be stabilized early and the cost of iterating exceeds its value — e.g., the build phase of construction projects, or heavily regulated environments like healthcare where phase gates let regulators assess (for instance) whether a new drug merits further development. Scope, schedule, cost, resources, quality, and risks are well defined up front and expected to remain relatively stable.

Incremental delivery within predictive. Even when overall scope is fixed up front, some predictive projects deliver in phases or increments — each increment builds on the previous, progressively adding features or completing parts of the product (Figure 4-5). Stakeholder value is realized earlier through partial delivery, but the overall scope and timeline remain largely fixed. This is still predictive, just with phased delivery.

See Predictive Development Approach for the deep dive.

4.2.2 Adaptive approaches

Also called change-driven or agile. Useful when requirements and technical solution are subject to high uncertainty and volatility and are likely to change significantly. A clear vision is set at the start; the initial known requirements are progressively elaborated, changed, or replaced in accordance with stakeholder feedback, environment, or unexpected events.

Adaptive approaches can be iterative (refining through repeated cycles) and/or incremental (delivering in small usable segments that build on one another).

Agile methods typically have 1- to 4-week iterations with a demonstration of accomplishments at the end. The team plans collaboratively from a prioritized product backlog (see Backlog Management), estimates the work, and develops the scope during the iteration.

Flow-based scheduling. Some adaptive methods focus on optimizing the flow of work rather than iterating in fixed time boxes:

  • Kanban — visual workflow management; limits work in process (WIP) based on lean principles; focuses on continuous delivery without overburdening the team.
  • Theory of constraints — identifies and addresses the most significant limiting factor (constraint) that stands in the way of achieving a goal.

Named agile methods — Figure 4-7 plots them by breadth of coverage × depth of guidance:

  • Team-level methods: Scrum, XP, Kanban, Crystal Methods, FDD (Feature-Driven Development), Lean
  • Scaled approaches: SAFe, DSDM, LeSS, Agile UP, Scrum of Scrums
  • Tool kit (not a method): PMI Disciplined Agile (DA)

A method prescribes steps to achieve an outcome; a tool kit offers a flexible collection of tools to support various methods. Disciplined Agile is explicitly a tool kit.

Suited project types:

  • Design projects — requirements not fully defined up front; partial deliveries and changes expected.
  • New product development — final features refined based on market needs (e.g., new mobile app, web service).
  • Digital projects — software with evolving scope, high uncertainty, and value from early or incremental delivery.

See Adaptive Development Approach for the deep dive.

4.2.3 Hybrid approaches

A hybrid development approach combines elements of adaptive and predictive. Appropriate when uncertainty varies across deliverables — e.g., a custom home where design is iterative but build is predictive after design is complete. Hybrid is also useful when deliverables can be modularized or when different teams develop different parts.

PMBOK 8 explicitly notes that most modern projects benefit from hybrid — pure predictive or pure adaptive rarely addresses today’s varied complexity.

Four common hybrid patterns (Figures 4-8 to 4-11):

  1. Adaptive development followed by predictive rollout — iterative build, plan-driven release.
  2. Adaptive and predictive used simultaneously throughout the life cycle on parallel workstreams.
  3. A small adaptive element within a primarily predictive project — predictive dominates; adaptive used to relieve specific pain points.
  4. A largely adaptive approach with a predictive component — adaptive dominates; some predictive scaffolding to satisfy business constraints.

PMI Disciplined Agile — three hybrid levels:

  • Hybrid Level 1 — predictive is the dominant contributor; some adaptive elements relieve specific pain points.
  • Hybrid Level 2 — predictive and adaptive each contribute significantly to project success.
  • Hybrid Level 3 — adaptive is the major contributor; some predictive elements satisfy business constraints.

Examples:

  • Construction with IT integration — a smart building (predictive shell) with complex IT systems that need flexibility during development (adaptive integration).
  • Healthcare solutions — an electronic medical records implementation where infrastructure setup is predictive but user-interface development and integration are adaptive.

See Hybrid Development Approach for the deep dive.

4.3 Considerations for development approach selection

PMBOK 8 organizes selection variables in three categories.

4.3.1 Deliverables

  • Degree of innovation — new/complex innovation favors adaptive.
  • Requirements certainty — well-known requirements favor predictive.
  • Scope stability — unstable scope favors adaptive.
  • Ease of change — costly or difficult change favors predictive.
  • Delivery options — incremental or progressively elaborated deliverables favor adaptive or hybrid.
  • Risk — adaptive approaches help manage uncertainty.
  • Safety requirements — rigorous safety requirements favor predictive (up-front planning for compliance).
  • Feedback — high value from frequent end-user feedback favors adaptive.
  • Regulations — heavy regulatory oversight favors predictive (documentation, demonstration).

4.3.2 Project

  • Stakeholders — adaptive methods typically require significant ongoing stakeholder involvement.
  • Schedule constraints — fixed end-date favors predictive; value from early delivery favors iterative/adaptive.
  • Financing uncertainty — adaptive or iterative may generate more value under financing uncertainty.
  • Project size and complexity — larger, complex, evolving projects favor more flexible approaches.
  • Team experience and skills — adaptive benefits from strong communication, collaboration, problem-solving.
  • Interdependencies — reliance on others for decisions/components/resources may favor iterative delivery.

4.3.3 Organization

  • Organizational structure — fixed functional/hierarchical structures favor predictive; network-oriented structures favor adaptive or hybrid.
  • Culture — managing-and-directing culture favors predictive; uncertainty-embracing, self-managed culture favors adaptive.
  • Organizational capability — policies, reporting structures, attitudes, and PM-process maturity influence reliability of the chosen approach.
  • Project team size and location — adaptive often works better with smaller teams (some frameworks recommend 3–9 members); some adaptive methods favor colocation.

Approach selection is the first step in Tailoring.

4.4 Delivery cadence

Independent of life cycle choice. A predictive project can have multiple deliveries; an adaptive project can have a single delivery. PMBOK 8 defines four cadences:

  • Single delivery — all outcomes at the end (e.g., process-reengineering project where the new process rolls out near the end).
  • Multiple deliveries — multiple components or elaborations delivered at different times. Sequential (e.g., drug development: preclinical → Phase 1 → Phase 2 → Phase 3 → registration → launch) or parallel (e.g., building-security upgrade: badges, key code pads, physical barriers — each a separate delivery, no required order).
  • Periodic deliveries — like multiple deliveries but on a regular fixed schedule (e.g., bi-weekly software releases). Common in adaptive.
  • Continuous delivery — incremental delivery to production on an ongoing basis. Leverages automation and a continuously prioritized backlog; production-ready at all times; fosters responsiveness to feedback and evolving market trends.

4.5 Project Management Focus Areas

Terminology note. PMBOK 6 called these five actions “Process Groups.” PMBOK 8 calls them Project Management Focus Areas — the same five, reframed. They are implemented through formal processes, informal practices, policies, procedures, or techniques. They are independent of approach (predictive, adaptive, hybrid), independent of application area (marketing, IT, accounting) and independent of industry (construction, aerospace, telecom). Detailed per-Focus-Area study notes live in 03-focus-areas.

The five Focus Areas:

4.5.1 Initiating

Processes, practices, or actions performed to define a new project or new phase. Often includes formal authorization. Aligns stakeholder expectations and the project’s purpose, informs stakeholders of scope and objectives, and discusses how their participation helps meet those expectations. Initial scope is defined; initial financial resources committed; stakeholders identified; PM roles assigned. Information often captured in artifacts such as a project charter and stakeholder register.

The key benefit: projects are only authorized when aligned with the organization’s strategic objectives — with the Business Case, benefits, and stakeholders considered from the start. Inputs to initiating often come from outside the project: the business case and the Benefits Management Plan.

4.5.2 Planning

Processes, practices, or actions that establish the intended scope, define and refine objectives, and develop the course of action. Artifacts may include a product backlog or a project management plan.

Planning is progressive — as more project information is gathered, additional planning may be required. Predictive approaches tend to front-load planning (though plan updates throughout the life cycle are normal). Highly iterative approaches perform brief high-level planning up front (“roadmapping”), followed by frequent planning and replanning throughout. This ongoing refinement is called progressive elaboration. Rolling-wave planning is one form, where near-term work is detailed and far-term work stays at a higher level.

The output collection is often called the project management plan — in some organizations it is formally approved and used as the authoritative reference.

4.5.3 Executing

Processes, practices, or actions that complete the work consistent with the currently agreed-upon course of action. Includes coordinating resources, managing stakeholder engagement, and performing project activities. The choice of development approach (adaptive, predictive, hybrid) is often most evident here. The plan can and should be changed whenever a change would enhance the value proposition.

4.5.4 Monitoring and Controlling

Actions to track, measure, review, and regulate project progress and performance; identify areas where plan changes are required; and initiate corresponding changes. Monitoring includes comparing actual to planned performance, producing performance measures, and reporting. Controlling includes analyzing variances, assessing trends to drive process improvements, evaluating alternatives, and recommending course corrections.

M&C runs in parallel with the other Focus Areas — it is not a separate, stand-alone step. For projects with a stable plan, M&C effort is fairly consistent; for projects with frequent and significant change (typical of adaptive), M&C effort is less consistent.

4.5.5 Closing

Actions to formally complete or close a project, phase, or contract — including early termination when canceling becomes the best way to maximize the return on (or minimize the negative return from) the project investment. May include verifying that specific actions are complete for other Focus Areas before declaring the project or phase closed. Verifies outputs, outcomes, and benefits to confirm the project met or exceeded intended value and stakeholder expectations. Transitions deliverables to operations.

4.5.6 Focus Areas as a whole

  • Not project phases. Even when a Focus Area name matches a phase name, they are different concepts. Within a phase, the Focus Areas interact.
  • Not strictly sequential. They overlap within a single phase — planning and monitoring frequently happen simultaneously.
  • Independent of approach — predictive, adaptive, and hybrid all honor these five in some manner. Iteration of activities within a Focus Area is common.
  • Predictive interaction pattern (Figure 4-13) — the five Focus Areas have characteristic levels of effort that rise and fall across project phases (e.g., Engineering, Procurement, Construction, Commission, Handover).
  • Adaptive interaction pattern (Figure 4-14) — each iteration cycles through Initiating, Planning, Executing, and M&C; Closing tends to come at the end of the project (or, for an iteration, at iteration end for that iteration’s deliverable).

Exam angle

  • Life cycle is chosen, not assumed. Wrong answers default to “agile because it’s modern” or “waterfall because it’s safe.” Right answers justify the choice from scenario context — requirements clarity, change rate, regulatory pressure, stakeholder availability.
  • Hybrid is frequently correct. PMBOK 8 explicitly states most modern projects benefit from hybrid. Scenarios with mixed certainty often eliminate pure predictive or pure adaptive.
  • “Process Groups” is PMBOK 6 language. If an answer choice talks about “the five Process Groups,” that’s the old name. PMBOK 8 says Focus Areas.
  • Focus Areas are not phases. A question that treats Initiating-Planning-Executing-M&C-Closing as a sequential phase model is wrong. They overlap; M&C runs in parallel with the others.
  • Iterations are time-boxed. When the time-box ends, the iteration ends regardless of what’s done. Unfinished work returns to the backlog — wrong answers extend the iteration to fit the work.
  • Delivery cadence is independent of life cycle. A predictive project can deliver multiple times; an adaptive project can deliver once. Wrong answers automatically conflate “agile” with “frequent delivery.”
  • Incremental ≠ adaptive. Predictive projects can deliver incrementally (e.g., a building’s floors completed one at a time) while still being predictive. Incremental describes delivery cadence; adaptive describes how requirements are managed.
  • Disciplined Agile is a tool kit, not a method. Methods prescribe steps; tool kits offer choices. Questions that treat DA as a prescriptive method are testing this distinction.

Graph View

Backlinks