PMP Integrated Project Management Plan: Approach, Estimating and Plan Delivery

An integrated project management plan is the single, approved document that describes how a project will be executed, monitored, controlled and closed. It brings together the subsidiary management plans, the baselines and the decisions about the delivery approach, so that scope, schedule, cost, resources, risk, quality, procurement and communications work as one plan instead of ten separate ones. The word that matters is integrated: the project manager's job is to make sure the pieces fit together, not just that each piece exists.

The PMP Examination Content Outline (July 2026) makes this Task 1 of the Process domain, with nine enablers that this lesson follows in order:

1. Assess project needs, complexity and magnitude.
2. Recommend a development approach: predictive, adaptive/agile or hybrid.
3. Determine critical information requirements (for example, sustainability).
4. Recommend a project execution strategy.
5. Create an integrated project management plan.
6. Estimate work effort and resource requirements.
7. Assess consolidated plans for dependencies, gaps and continued business value.
8. Maintain the integrated plan.
9. Collect and analyze data to make informed project decisions.

The detailed content of individual plans belongs to sibling tasks: defining scope and the WBS, value-based prioritization, acquiring resources, procurement decisions, budgets, quality, schedule control and status reporting each have their own lesson. This lesson covers what ties them together.

Before recommending how to run a project, assess two different things: how big it is (magnitude) and how uncertain it is (complexity). They are easy to confuse and call for different responses. Understanding the situation comes first. Assessing project needs means confirming the business need and objectives the project serves, who the stakeholders are and what they expect, the constraints that bind it (deadlines, budget, regulation, contracts) and the organizational context (governance, culture, existing processes and capability). An approach chosen before this assessment is a guess.

A very large project can be highly predictable: resurfacing hundreds of kilometres of road to an established specification is big but routine. A very small project can be highly complex: a short proof of concept connecting two systems nobody has integrated before, for stakeholders who disagree on the goal. Adding more of well-understood work raises size; uncertainty and interdependence raise complexity. PMI's work on complexity groups its sources as system behaviour (interconnections and dependencies), human behaviour (conflicting interests and priorities) and ambiguity (uncertainty about requirements, technology or the environment).

Two kinds of uncertainty drive the approach most directly: requirements uncertainty (do stakeholders know and agree on what is needed?) and technical uncertainty (does the team know how to build it?). Both low points toward predictive planning; either high points toward adaptive elements.

The recommended development approach follows from two characteristics: how much the requirements are expected to change, and how often the customer needs to receive usable output. The Agile Practice Guide places life cycles on a continuum along those two dimensions:

The near-twins are iterative and incremental: each satisfies one dimension of agile and not the other. Iterative repeats work to get it right but delivers once; incremental delivers in pieces but each piece is built to a known requirement. Agile is both iterative and incremental.

Other factors refine the choice: the organization's culture and governance, the contract type, the team's experience with the approach, regulatory constraints and the cost of change. Tailoring means the approach is chosen from this assessment, and the recommendation is the project manager's to make and justify. The recommendation, the life cycle and the tailored processes are recorded in the project management plan's development approach component, the part of the plan that describes how the work will be managed, so the team and auditors can follow them.

A hybrid approach uses predictive methods for components that are well defined and adaptive methods for components that are uncertain, and integrates them through shared milestones, governance and reporting. It is chosen when one approach would force a poor fit on part of the work: a regulated equipment upgrade with a signed-off design alongside a learner portal whose content will be shaped by user feedback.

Tailoring can happen at component level and mid-project. If one component's requirements keep changing while the rest stay stable and contractually defined, tailor at that level: run the volatile component adaptively and keep the stable work predictive. The approach should fit each component, rather than one approach being forced on all of them.

The integration points are where hybrid plans succeed or fail:

• Dated dependencies. When a predictive stream needs something from an agile team by a fixed date, make it a dated milestone the product owner and team plan releases toward. The rest of the backlog stays flexible; the commitment is visible.
• Cost baselines without frozen scope. An agile component can be baselined on capacity (team cost per iteration multiplied by the number of iterations) rather than on a fixed list of stories. Velocity then forecasts which features fall into each milestone.
• Common governance. Phase gates, milestone reporting and the change control process apply across both streams, at the level of commitments rather than individual backlog items.

Integration means one plan and one set of baselines that include every component, so problems at the interfaces surface while they can still be fixed.

Critical information requirements are the data the project must produce reliably for decisions and obligations: what the steering committee needs at each gate, what a regulator or a sustainability commitment requires, and what the sponsor needs to judge continued value. Determining them during planning means defining, for each item, its definition (unit and calculation method), source, owner and cadence, and building its collection into the plan.

Two principles follow:

• Start from the consumer, not from the data you happen to have. Each decision-maker needs the facts their decision turns on, at the level of detail they use. A regulator or a disclosure framework needs figures in its own required definition.
• A known obligation is a requirement, not a risk. If the organization has committed to report something, the obligation is certain, so collecting its data is planned now as a requirement with an owner and a cadence. Information that is not designed into the plan rarely exists when it is needed.

Sustainability data is the ECO's named example. When contributing sources report the same measure inconsistently, for example several sites reporting water use in different units and over different periods, two separate properties have to be fixed: comparability (every source uses one agreed definition and calculation method) and availability (every source submits by a date that leaves time to compile before the reporting deadline). Consistency is fixed at the source; adjusting or displaying figures afterwards does not make them comparable.

An execution strategy is the way the work will be rolled out and sequenced under the project's real constraints: big bang or phased, which stream goes first, whether a pilot proves the solution, and how teams are arranged. Several strategies usually work in principle; the stated constraints eliminate them.

Strategies can also be combined. If training capacity means staff can only be prepared one department at a time, but a payroll rule requires everyone to move to a new timekeeping system on the same date, separate preparation from cutover: prepare in waves, then switch everyone on one date.

Sequencing matters when streams share scarce people. When one stream has a fixed external deadline and depends on scarce people the flexible stream also needs, protect the constrained work first, then let the flexible stream iterate; arranging teams so the scarce people are not split protects the deadline. Identify the binding constraints (deadlines, shared specialists, capacity, budget, contractual rules) before choosing.

The project management plan contains subsidiary management plans, baselines and additional components. Everything else produced during planning is a project document. The distinction decides how each item changes.

Creating the plan is itself a sequence: develop or tailor the subsidiary plans with their owners, consolidate them, resolve the conflicts and gaps that appear where they meet (see the assessment section below), obtain approval from the sponsor or governance body, and then set the baselines. From that point, changes to plan components go through change control.

Watch the near-twins. The schedule baseline is a plan component; the project schedule is a working document updated as work proceeds. The cost baseline is a component; cost estimates are documents. The change management plan is a component; the change log that records changes is a document.

The performance measurement baseline (PMB) is the integrated scope, schedule and cost baselines: what work was planned, when, and at what cost. Earned value analysis measures performance against it (that analysis is taught under evaluating project status). Quality, risk and resources are managed through their subsidiary plans; they are not parts of the PMB. On adaptive components, the equivalent anchors are the product vision, release plan, capacity-based budget and milestone dates rather than a story-level scope baseline.

Estimating effort means choosing the technique that matches how much is known, then converting effort into duration from the resources actually available. Each technique has a tell-tale situation:

Three-point formulas: the beta (PERT) estimate is (O + 4M + P) / 6, weighting the most likely value; the triangular estimate is (O + M + P) / 3. For O = 6, M = 9, P = 18 days, beta gives (6 + 36 + 18) / 6 = 10 days and triangular gives (6 + 9 + 18) / 3 = 11 days. Read which distribution the question names.

Effort is not duration. Effort is the total person-hours of work; duration is the working time it takes given how many people work on it and for how much of their day. 120 hours of effort shared by three people each allocated a quarter of an 8-hour day supplies 6 hours a day, so it takes 20 working days.

Capacity adjusts agile plans. Plan an iteration from average velocity scaled by the capacity actually available. A team of five averaging 40 points that loses one member for the whole iteration (keeping 4/5) and two of ten days to training (keeping 0.8) should plan about 40 × 0.8 × 0.8 ≈ 26 points; apply every reduction, not just one. The plan comes from capacity, not from demand.

Estimates belong to the people doing the work. If the people assigned are not the people who estimated, for example a contractor team takes over work sized by in-house specialists, re-estimate with the people actually assigned before baselining. A known estimating difference is resolved in the estimate itself; management reserve is held for unknown-unknowns.

Before baselining, the project manager consolidates the subsidiary plans and looks for problems that only appear where plans meet: dependencies that conflict, resources booked twice, gaps nobody owns, and whether the project still makes business sense.

Cross-plan conflicts and gaps

Typical integration problems: user training scheduled before the system it covers is installed; one specialist allocated full-time to two concurrent activities; a vendor delivery planned after the activity that needs it. A known conflict is an issue to resolve now, not a risk to log and baseline around. When no single plan can absorb the fix because each is held by a firm constraint, the integrating action is to bring the owners of the affected plans together and agree a feasible solution.

Not every finding is a defect. The assessment looks for conflicts that make the plan infeasible and work that nobody owns; deliberate planning choices, such as detail deferred under rolling wave planning, are accepted practice.

Dependency types

This is why fast tracking (overlapping activities normally done in sequence) targets discretionary dependencies: they are the only ones the team can relax. Schedule compression itself is taught in the schedule lesson.

Continued business value

Plans are also checked against the business case: does the project still deliver more than it costs? The decision test is forward-looking: compare the remaining cost to finish with the remaining benefit. Money already spent is a sunk cost and is excluded. If $5 million is spent, $1.5 million remains to spend and the benefit forecast falls to $2.5 million, finishing still returns $1 million more than it costs from here, even though the total spend now exceeds the benefit. Past spending is never by itself a reason to continue or to stop.

The project manager's role is to analyze and surface the change promptly, bringing the updated business case to the sponsor or governance body, who decides. On adaptive work, value already delivered by released increments is part of the picture: the forward-looking question is what the remaining backlog is worth relative to its remaining cost.

Maintaining the integrated plan means adding detail as work approaches and keeping it current, while sending only real baseline changes through integrated change control. Two techniques define the boundary:

• Progressive elaboration is the general principle that plans gain detail as more is known.
• Rolling wave planning applies it to time: near-term work is planned in work-package detail, later work stays at milestone or planning-package level, and detail is added as each period approaches. Decomposing later work held as a planning package into work packages that fit its existing budget and milestone dates is maintenance inside its control account: the schedule gains detail, the baseline does not change.

What needs integrated change control in a hybrid project

The test is whether the change alters a baseline or an external commitment. Ordering the backlog within the fixed budget and release dates is the product owner's normal decision.

Collecting and analyzing data

Informed decisions rest on choosing the analysis that answers the actual question:

EMV is probability × impact, added to the base value: a $480,000 option with a 40% chance of a $120,000 overrun has an expected cost of $480,000 + $48,000 = $528,000, slightly lower than a $500,000 option with a 20% chance of a $150,000 overrun ($530,000), even though its overrun is more likely.

Trends matter even inside thresholds. A variance still inside its threshold but worsening period after period, with most of the work ahead, calls for analyzing the cause and forecasting where it will end, so action can be taken before the threshold is reached. Likewise, when velocity is declining steadily, the long-run average overstates future throughput: forecast from the trend and explore its cause with the team before committing to dates.