Integrated Planning and Delivery

A regulator hands your team a fixed compliance deadline, while the product owner three desks away still cannot say what the new mobile feature should actually do. Same project, two very different kinds of work, and the reflex to run both the way the organization always has is exactly the mistake this page exists to prevent. Good planning starts earlier than any Gantt chart or product backlog: you first size up the project, and only then let what you find decide how much planning rigor to apply and which development approach to recommend^[1]. Get that first step right and you can match predictive, adaptive, or hybrid delivery to the work in front of you instead of to habit.

Assess needs, complexity, and magnitude first

Before choosing anything, assess the project's needs, complexity, and magnitude so the planning effort stays proportional to the work. A small, low-risk change earns a light plan; a large, complex, high-stakes program earns deeper controls, more detail, and more review. The point of the assessment is to right-size the plan, not to generate paperwork: over-planning a trivial effort wastes the same capacity that under-planning a complex one puts at risk.

Three development approaches, chosen by requirement certainty

A development approach is the overall shape of delivery, and there are three. Predictive (plan-driven, still often called waterfall) fixes the scope and plans the work in detail up front; PMI describes it as the fit when requirements are stable and the business value is realized only once the full scope is delivered^[2]. Adaptive (agile) delivers in short, time-boxed iterations and lets requirements emerge, and it fits when there is requirement uncertainty and value that can be delivered in pieces^[2] rather than in one release. Hybrid is a blend of both. The spectrum in the figure below places them by requirement certainty: stable, well-understood requirements sit at the predictive end, volatile or emergent requirements at the adaptive end, and most real projects fall somewhere between.

The decision rule is the one the overview states: recommend the approach the project's characteristics point to, not the one the team already knows. Choosing predictive to lock scope while the requirements are still moving does not stabilize them; it just guarantees rework when they move anyway.

Choosing an approach settles how the team will work; the execution strategy settles how and when finished value actually reaches the customer. It is the delivery cadence and sequencing of the work: a single release at the end, a series of phased releases, or continuous increments delivered a little at a time. The timeline below lines up the three so the trade-off is visible.

Match cadence to when value can be absorbed

Base the cadence on when the customer can actually absorb the value and how their feedback will be used, not on internal convenience. A single release suits work whose value lands only once the whole scope is complete, such as a system that cannot go live in pieces. Phased releases carve delivery into a few meaningful milestones when parts of the scope can go live earlier. Continuous increments deliver a usable slice each iteration and fit when early, frequent feedback reduces risk^[2] and the customer can absorb small changes often.

Cadence and approach reinforce each other

Cadence and development approach are not independent choices. A predictive project, having planned scope up front, tends toward one or a few phased releases; an adaptive project delivers an increment every iteration by design. That is why PMI frames the choice of a delivery approach around whether value can be achieved in pieces rather than in a single release^[2]. Picking a cadence the approach cannot support, such as promising continuous increments on a project you are running predictively with a single integration at the end, is a plan that will not hold.

With the approach and cadence chosen, planning produces many separate plans, and the integrated project management plan is what makes them behave as one. It is not a folder of plans stapled together. PMI guidance is explicit that the project management plan integrates and consolidates all of the subsidiary plans^[3], so creating it means combining plans such as the scope, schedule, cost, resource, procurement, quality, and risk plans - along with the communications and stakeholder engagement plans this guide covers under People - into a whole that is internally consistent, and reconciling the conflicts between them rather than leaving them to collide during execution. The figure below shows a representative set of those subsidiary plans consolidating into one plan, with approved change flowing back out to every plan it touches.

Determine critical information requirements, including sustainability

What the plan must contain is set by the project's critical information requirements: the regulatory, stakeholder, technical, and sustainability data the project depends on. Identifying that set first is what decides how deep the planning has to go and keeps the team from planning around unknowns. Sustainability and ESG (environmental, social, and governance) belong in that set from the start. PMI treats sustainability as something integrated into the way a project is planned and run rather than considered after the fact^[4], so environmental impact, resource consumption, and social outcomes are planning inputs that shape the plan, not a report assembled at closure.

Check the consolidated plans, then keep them synchronized

Before committing, review the consolidated plans together for cross-plan dependencies, gaps, and continued business value. This is where a vendor lead time buried in the procurement plan is caught before it silently breaks the delivery timeline, and where a gap between two plans surfaces while it is still cheap to fix. Maintaining the plan is the same discipline in reverse: when a change is approved, re-integrate it across every affected subsidiary plan so the integrated plan stays a single source of truth. Updating only the plan that changed directly, and leaving the plans that depend on it stale, is the most common way an integrated plan quietly stops being integrated.

Estimates are the numbers the plan stands on, and the exam tests when to commit to a precise one and when to stay deliberately rough. One rule ties the section together: estimate with the precision the available information supports, and no more.

Progressive elaboration and rolling-wave planning

Early estimates are coarse and get refined as detail emerges, an idea PMI calls progressive elaboration. Rolling-wave planning applies it to the schedule: the near-term work is planned in detail while more distant work is planned at a more general level^[5], and the detail extends forward as the work approaches and more becomes known. The figure below contrasts the finely detailed near term with the single rough block that stands in for far-term work. The exam consequence is direct: do not demand precise, hour-by-hour estimates for far-future work that is still poorly defined; leave it coarse and elaborate it later.

Adaptive teams size in relative units

Adaptive delivery estimates differently. Instead of committing to up-front hours, the team sizes work in relative units such as story points, because the exercise measures relative size, not time^[6], and then observes its empirical velocity, the number of points completed per iteration, to forecast. Velocity is learned over successive iterations rather than assumed, and PMI cautions that it is a within-team forecasting measure, not a way to compare productivity across teams^[6]. This is the same rolling-wave idea in agile clothing: forecasts are revised each iteration as real velocity comes in.

Spikes de-risk an unknown before you size it

Sometimes a backlog item cannot be sized because something about it is genuinely unknown. A spike is a short, time-boxed investigation, a piece of research or a throwaway prototype, that an adaptive team runs to reduce that uncertainty so the item can be understood and estimated. PMI describes teams using spike solutions to reduce uncertainty risk^[7] through rapid feedback. A spike de-risks an unknown; unlike a minimum viable product it does not deliver shippable value, and it must stay time-boxed rather than drifting into open-ended research. Commissioning a spike to settle a business-value question, rather than a technical or feasibility unknown, is a misuse of it.

Effort drives resources, and data drives the decision

Estimating work effort is not an end in itself: the effort estimate produces the resource requirements, the skills, roles, and quantities the work needs, which then feed resource planning. Effort estimation and resource estimation are linked, not separate, activities. Underneath all of it, planning choices rest on collected and analyzed data rather than intuition or hierarchy. Analytical and AI tools can accelerate that analysis, and PMI notes that machine learning can help project managers look beyond common intuitive biases^[8]. They remain an input, though: the project manager validates their output and stays accountable for the decision, because AI informs an informed decision, it does not make it.

PMP planning questions rarely ask for a definition. They drop you into a situation and ask for the best next action, and the tempting wrong answers are usually a default habit or a commitment made before the project has been assessed.

What the stems look like, and the answer that wins

• A new project starts and you must decide how to run it. Right: assess the project's needs, complexity, and magnitude and the stability of its requirements, then recommend predictive, adaptive, or hybrid to fit. Wrong: apply the organization's standard method, or the one the team last used, without assessing.
• Requirements are volatile or expected to change. Right: recommend an adaptive, iterative approach so feedback can reshape the work. Wrong: choose predictive to lock the scope while it is still emerging.
• The project mixes fixed, compliance-heavy work with uncertain work. Right: recommend hybrid and run each component the way it fits. Wrong: force one cadence across the whole project.
• A stakeholder asks for a precise estimate of far-future, ill-defined work. Right: give a rough estimate now and elaborate it later by rolling wave. Wrong: commit to a detailed number the information does not yet support.
• An adaptive team cannot size a backlog item because of a technical unknown. Right: run a time-boxed spike to reduce the uncertainty, then size it. Wrong: force an estimate anyway, or open an untimed research effort.
• An approved change lands on one subsidiary plan. Right: re-integrate it across every affected plan so the integrated plan stays consistent. Wrong: update only the plan that changed and move on.
• An AI tool produces an estimate or a recommendation. Right: validate it against the data and your judgment and stay accountable for the call. Wrong: accept the AI output as the decision.

The through-line

Two habits resolve most of these. First, assess before you commit: size the project and read its requirements before choosing an approach, a cadence, or a precise estimate. Second, keep the plan whole and current: reconcile the subsidiary plans into one integrated plan, re-integrate every approved change, and treat tailoring as something you revisit as the project learns rather than a decision frozen at kickoff. When two answers both look reasonable, prefer the one that assesses the project over the one that applies a default.