Study guide
The Process domain carries the largest share of the exam (41% under the outline effective July 2026), and this chapter covers its planning half: choosing an approach, building the project management plan, defining scope or a backlog, sequencing work by value, and setting up resourcing and procurement. The recurring judgment being tested is fit: does the chosen method, plan, or decision actually fit this project's context.
Choosing Predictive, Agile, or Hybrid
No single delivery approach is universally correct, and PMI's current outline expects candidates to recognize which approach, or blend of approaches, suits a given project's characteristics. A predictive, or plan-driven, approach works well when requirements are stable and well understood, the solution is largely known in advance, and regulatory or contractual needs favor detailed upfront planning, such as constructing a bridge to an engineering specification. An agile or adaptive approach fits better when requirements are expected to change, the problem is complex or poorly understood at the outset, and frequent stakeholder feedback can meaningfully improve the product, such as building a new customer-facing app in a competitive market. A hybrid approach combines elements of both, which is common in practice: a project might use predictive planning for hardware procurement with long lead times while running the software component in short iterations. The decision is not about which method is more modern; it is about matching the method to the level of uncertainty, the need for flexibility, and organizational or contractual constraints. Consider Nadia, tasked with a project to migrate a bank's core ledger system. The migration steps are well defined and heavily regulated, but the new customer-facing reporting layer built on top of it needs rapid user feedback. Nadia recommends a hybrid approach: a predictive plan for the ledger migration and iterative sprints for the reporting layer. On the exam, when a scenario describes changing requirements or a need for early feedback, agile or hybrid elements are usually the better recommendation; when it describes fixed, well-understood requirements with heavy compliance needs, predictive elements usually fit better.
Building the Integrated Project Management Plan
Whatever approach is chosen, the project manager assembles a project management plan that integrates the subsidiary plans and baselines needed to guide the work, such as scope, schedule, cost, quality, resource, communication, risk, procurement, and stakeholder engagement components. Integration means these pieces must be consistent with each other, not just individually complete: a schedule that assumes five developers is not integrated with a resource plan that only secures three. The plan is not created once and frozen; it evolves through progressive elaboration, especially in adaptive environments where detailed plans for later iterations are deliberately left less defined until more is known, a concept sometimes called rolling wave planning. A common exam trap is treating the plan as a static document that, once approved, cannot change; in reality, an integrated management plan is a living set of agreements that gets updated through a defined change process as the team learns more. Consider Raj, planning a product launch, who initially bases his schedule on a vendor's promised delivery date. When the vendor later revises that date, an integrated plan means the schedule, the resourcing plan for the launch team, and the communication plan to stakeholders all get updated together, not just the schedule in isolation. On the exam, look for answers where a change in one part of the plan is checked against its ripple effects on other parts, rather than being handled as an isolated fix.
Defining and Decomposing Scope or Backlog
In predictive work, scope is typically defined through a scope statement and broken down into a work breakdown structure, a hierarchical decomposition of the total work into smaller, more manageable components down to a level where work packages can be estimated and assigned. In adaptive work, the equivalent artifact is a product backlog: an ordered list of features, fixes, and other work items, each often written as a user story describing who wants something, what they want, and why. Decomposition in agile happens continuously, as large backlog items, sometimes called epics, are broken into smaller stories that can be completed within a single iteration. Both approaches share a purpose: making work small enough to estimate, assign, and track, while keeping it traceable back to the overall objective. A frequent point of confusion is assuming a backlog is unplanned; in fact, backlog refinement, where the team clarifies and re-estimates upcoming items, is itself a planning activity, just one that recurs throughout the project rather than happening once upfront. Consider Aiden, a product owner for a mobile banking feature, who keeps a backlog item labeled 'improve login experience' sitting near the top for three sprints without breaking it down. The team cannot estimate or commit to it until Aiden decomposes it into specific stories, such as adding biometric login or reducing password reset time. On the exam, when a scenario shows a team stalled because work is too large or vague to start, the answer usually involves further decomposition, whether that means splitting a work package or refining a backlog item into smaller stories.
Value-Based and Incremental Delivery Prioritization
Modern project management, whether predictive, agile, or hybrid, is oriented around delivering value early and often rather than delaying all benefit until a single final release. Prioritization frameworks help decide what to build first. Common techniques include ranking backlog items by business value against effort or risk, and structured methods such as MoSCoW, which sorts requirements into Must have, Should have, Could have, and Won't have this time. The goal is to sequence work so that the highest-value, highest-risk-reduction items are addressed earliest, since early delivery of a working increment both provides real benefit sooner and generates feedback that improves later work. This connects directly to incremental delivery: rather than building an entire system and releasing it once, teams release usable increments, such as a minimum viable product, to start capturing value and learning from real usage. Consider Sofia, prioritizing a backlog for a new expense-reporting tool. Stakeholders want a polished analytics dashboard, but Sofia recognizes that a basic receipt-upload feature delivers value to far more users far sooner, so she sequences it first and defers the dashboard. A classic exam trap is prioritizing by whichever stakeholder is loudest or most senior rather than by demonstrated value and risk; the situational answer favors a transparent prioritization method applied consistently, with re-prioritization revisited regularly as new information arrives rather than decided once and left untouched.
Resource Planning and Procurement Strategy
Resource planning identifies what people, equipment, materials, and facilities a project needs and when, then works out how to acquire them, whether by assigning existing staff, hiring, training, or renting equipment. In agile contexts, resourcing often emphasizes stable, cross-functional teams that stay together across multiple efforts rather than being reassembled project by project, since team cohesion itself improves delivery speed. When a project needs goods or services from outside the organization, procurement strategy comes into play: deciding what to buy versus build, what contract type fits the situation, and how to select and negotiate with sellers. Contract type matters because it allocates risk differently. A fixed-price contract puts most cost risk on the seller and suits well-defined, stable requirements. A cost-reimbursable contract puts more risk on the buyer but offers flexibility when requirements or scope may change, useful in research-heavy or uncertain work. A time-and-materials contract sits between the two and suits smaller, less-defined engagements such as staff augmentation. Negotiation decisions should reflect these tradeoffs; agreeing to a fixed-price contract for poorly defined requirements typically shifts unfair risk onto the seller and invites disputes or corner-cutting later. Consider Wen, procuring a specialized sensor component whose final design specifications are still evolving. Choosing a fixed-price contract here would pressure the vendor to lock in specs prematurely; a cost-reimbursable or incentive-based structure better matches the uncertainty. On the exam, match the contract type to how well-defined the requirement is and who should reasonably bear the risk of change.
Key terms
- Predictive approach
- — A delivery approach that plans scope, schedule, and cost in detail upfront, suited to stable, well-understood requirements.
- Adaptive (agile) approach
- — A delivery approach using short, iterative cycles and frequent feedback, suited to evolving or poorly understood requirements.
- Hybrid approach
- — A delivery approach that combines predictive and adaptive elements within a single project, applied to different components as their needs differ.
- Work breakdown structure (WBS)
- — A hierarchical decomposition of total project scope into smaller components down to manageable work packages.
- Product backlog
- — An ordered, evolving list of features, fixes, and other work items for an adaptive project, refined continuously throughout delivery.
- Backlog refinement
- — The recurring activity of clarifying, decomposing, and re-estimating upcoming backlog items so they are ready to be worked on.
- MoSCoW prioritization
- — A prioritization technique that sorts requirements into Must have, Should have, Could have, and Won't have this time.
- Minimum viable product (MVP)
- — The smallest version of a product that can be released to start delivering real value and generating usable feedback.
- Rolling wave planning
- — Progressive elaboration in which near-term work is planned in detail while later work remains at a higher level until more information is known.
- Fixed-price contract
- — A contract type that sets a firm price for defined work, placing most cost risk on the seller.
- Cost-reimbursable contract
- — A contract type that pays the seller's allowable costs plus a fee, placing more cost risk on the buyer, suited to uncertain scope.
- Time-and-materials contract
- — A hybrid contract type paying for labor hours and materials used, suited to smaller or less-defined engagements.
Exam tips
- Match approach to uncertainty: stable, well-defined requirements point toward predictive elements; evolving requirements or a need for early feedback point toward agile or hybrid elements.
- If a scenario shows a plan component changing without checking its effect on other parts of the plan, that is a red flag — integrated planning means updates ripple across dependent components.
- When work is stalled because it is too big or vague to estimate or start, decomposition (splitting the WBS or refining the backlog) is usually the right next step, not more discussion.
- Prioritization questions test whether you sequence by value and risk reduction rather than by stakeholder seniority or volume; look for the answer describing a consistent, transparent method.
- For contract-type questions, ask how well-defined the requirement is: fixed-price for stable scope, cost-reimbursable for uncertain scope, time-and-materials for small or short-term work.