Build and Maintain the Integrated Project Management Plan

Introduction

This lesson continues Task 2.1 of the Process domain of the July 2026 PMP Examination Content Outline (ECO), a domain worth 41% of the scored questions. Lesson 1 chose the approach and the execution strategy. This lesson turns them into a plan that works. The remaining enablers of the task are: develop an integrated project management plan and its subsidiary plans; estimate work effort and resource requirements; assess consolidated plans for dependencies, gaps and continued business value; maintain the plan based on the analysis of project results; and use data-driven decisions, including analysis supported by artificial intelligence (AI).

Scenarios on the exam describe plans that do not fit together (a schedule that ignores the procurement lead time, a budget that does not include the quality plan), estimates that nobody believes, plans never updated after a change, or dashboards produced by an AI tool whose output needs checking. You are expected to choose the action of a project manager who integrates, challenges and keeps the plan alive.

After this lesson you will be able to assemble the integrated plan from its subsidiary plans and baselines, estimate effort and resources with several techniques, review a consolidated plan for dependencies, gaps and value, maintain it through change, and use data and AI tools critically.

Learning objectives

Explain what the integrated project management plan contains and how subsidiary plans relate to it.
Apply estimating techniques (analogous, parametric, bottom-up, three-point, relative sizing) to effort and resources.
Review a consolidated plan for dependencies, gaps and business value.
Maintain the plan through integrated change control and regular reviews.
Use data to decide, and evaluate the output of AI-assisted analysis critically.

1. The integrated project management plan

The project management plan is the single approved document (or set of linked documents and tools) describing how the project will be executed, monitored and controlled. "Integrated" means its parts agree with each other: a change in scope must show in schedule, cost, resources, quality, risk and procurement.

Component	Content
Subsidiary plans	Scope, requirements, schedule, cost, quality, resource, communications, risk, procurement, stakeholder engagement (and, in adaptive work, release and iteration plans)
Baselines	Scope baseline (scope statement, WBS, WBS dictionary), schedule baseline, cost baseline
Other components	Change management plan, configuration management plan, performance measurement baseline, project life cycle and development approach, management reviews

Project documents (risk register, issue log, assumptions log, lessons learned register, stakeholder register, requirements documentation) support the plan but are not part of it; they change often without formal approval of the plan itself.

In an agile project the plan is lighter and layered: a vision and roadmap, a release plan, iteration plans and a backlog. The principle is the same: coherent, shared and updated. In a hybrid project, the predictive frame (milestones, budget, governance) is integrated with the adaptive plans (backlog, iteration cadence). Integration is the project manager's role; no subsidiary plan owner can do it alone.

Example: a plan that does not integrate

A team builds a hospital scheduling system. The schedule assumes the data-migration specialists start in March. The resource plan shows them on another project until June. The cost plan funds only 2 months of their work, and the risk register does not mention the conflict. Each plan is internally correct; together they contradict. Integration review would have revealed it before execution.

2. Estimating work effort and resource requirements

Effort is the amount of work (person-hours); duration is the elapsed time; cost depends on effort and rates. Resource requirements follow from effort and constraints.

Technique	How it works	Use when	Limit
Analogous	Uses the actuals of a similar past project, adjusted	Early, little detail	Low accuracy; depends on true similarity
Parametric	Applies a unit rate to a measure (cost per square metre, hours per screen)	Data from history, scalable work	Needs valid statistics
Bottom-up	Estimates each work package, then sums	Detailed scope known	Time-consuming
Three-point	Combines optimistic (O), most likely (M) and pessimistic (P) values	Uncertainty	Needs good inputs
Expert judgement / Delphi	Experts estimate; anonymous rounds converge	Novel work	Bias
Relative sizing	Story points, T-shirt sizes, affinity grouping, planning poker	Agile backlogs	Converts to time only through velocity
Reserve analysis	Adds contingency for identified risks	Any	Must be justified

Three-point formulas. Triangular: (O + M + P) / 3. Beta (PERT): (O + 4M + P) / 6, with standard deviation (P − O) / 6.

Worked example (PERT). A task has O = 10, M = 14, P = 24 days. Beta estimate = (10 + 56 + 24) / 6 = 15 days; standard deviation = (24 − 10) / 6 = 2.33 days. Triangular = 16 days. Within one standard deviation, the task is expected between about 12.7 and 17.3 days.

Progressive elaboration means estimates become more accurate as information increases. A typical accuracy range might be −25% to +75% in early concept, narrowing to −5% to +10% in definitive estimates. Exam answers usually favour giving a range and refining it, not a single early number.

Estimating in agile projects

Teams estimate backlog items in story points (relative size). Velocity is the number of points completed per iteration. If the remaining backlog is 240 points and the average velocity is 30 points per two-week sprint, the forecast is 240 / 30 = 8 sprints, 16 weeks. Velocity belongs to the team and must not be used to compare teams or to pressure them. A range (using the slowest and fastest of the last six sprints) is more honest than a single date.

Estimating resources

Resource requirements include people (skills, quantity, time), equipment, materials, licences, facilities and tools. Consider productivity, learning curves, availability, calendars, and the effect of adding people (Brooks's law: adding people to a late project can delay it further because of communication overhead and onboarding).

Worked example: from effort to resources

Statement. A backlog for a client portal is estimated at 1,800 person-hours of build and test work. A developer is productive 5.5 hours per day on project work (meetings and support included), and the team has 4 developers. The sponsor asks when it will be ready and how many people are needed to finish in 12 weeks (60 working days).

Reasoning.

Capacity of 4 developers: 4 × 5.5 × 60 = 1,320 hours in 12 weeks.
Gap: 1,800 − 1,320 = 480 hours.
Options: add people, extend the time, or reduce scope. To finish in 12 weeks with the same productivity: 1,800 / (5.5 × 60) = 5.45, so 6 developers (or 5.5 FTE).
Allow for onboarding: two new developers need two weeks to become productive, which costs about 2 × 5.5 × 10 = 110 hours of reduced output plus mentoring time. So the effective gain is lower, and the best answer may combine a modest increase with a reprioritised scope.
Recommendation: present the three options with cost and risk, and let the sponsor decide.

Why not simply add two developers? The calculation shows they would not close the gap in time, and the project would risk quality and coordination problems.

3. Assessing consolidated plans: dependencies, gaps and business value

After assembling the plan, challenge it as a whole.

Dependencies. Four types between activities: finish-to-start, start-to-start, finish-to-finish, start-to-finish. Their drivers are:

Mandatory (hard logic): physical or contractual necessity.
Discretionary (soft logic): best practice or preference.
External: outside the project (regulator approval, supplier delivery).
Internal: within the team's control.

Also look for dependencies between projects, with operations (a change freeze at year end), shared resources, and between plans (a procurement lead time that affects the schedule).

Gaps. Missing items, such as requirements without a work package, risks with no response in the schedule, training with no budget, acceptance criteria with no tester, a stakeholder group with no communication.

Business value. The plan must still deliver the benefits that justify the project. Check periodically: is the business case still valid, are the benefits still achievable, has the market, regulation or priority changed? If the value has eroded, the right action is to raise it to the sponsor and governance body, who can continue, change or stop the project.

A practical review checklist:

Question	Where to look
Does every requirement trace to a deliverable, an activity, a test?	Requirements traceability matrix, WBS
Do dates, resources and costs agree?	Schedule, resource and cost plans
Are risks reflected in reserves and activities?	Risk register, baselines
Are external dependencies and lead times in the schedule?	Procurement plan
Are quality and acceptance activities included?	Quality plan
Does the plan still meet the business case?	Business case, benefits plan

Example: a dependency gap found at consolidation

For a retail store-opening programme, the construction plan shows handover on 1 March and the IT plan shows till installation from 3 March. The permit plan shows the fire-safety certificate is needed before any stock is delivered, and the authority needs 15 working days to inspect after request. Nobody scheduled the request. The consolidated review reveals that opening on 20 March is not feasible unless the request is submitted by 9 February. The project manager adds the activity, informs the sponsor of the risk to the date, and adjusts the baseline through change control.

4. Maintaining the plan

A plan is a living tool. Maintain it by:

Comparing actuals to the baseline and analysing variances at each reporting cycle.
Using integrated change control: changes to baselines are submitted, assessed for all impacts, approved or rejected by the right authority, then implemented and communicated.
Updating the plan and documents after approved changes, after risk events, at stage gates and after retrospectives.
Keeping version control and a record of decisions.
Re-baselining only through approval, when the old baseline is no longer a meaningful measure (for example after a large approved scope change); do not re-baseline to hide a poor performance.
Reviewing the approach and tailoring when results show that something is not working.

In adaptive projects, the backlog is refined continuously, release plans are updated after reviews, and the roadmap changes with feedback; this requires no formal change request for scope changes inside the agreed boundaries, but changes to budget, date or constraints go through governance.

Do not confuse corrective action (bringing performance back to plan), preventive action (reducing the probability of a future deviation), and a change request (a formal proposal to change a baseline). Corrective and preventive actions that need a baseline change come through a change request.

5. Data-driven decisions and AI-assisted analysis

The ECO states that the project manager makes data-driven decisions. This means decisions rest on measured information — status data, forecasts, trends, risk analyses, benefits tracking — and not on assumptions or the loudest opinion.

Good practice:

Define the decision first, then the data that would change it.
Check data quality: source, completeness, timeliness, definitions, bias.
Use suitable analysis: trend, variance, earned value, Monte Carlo simulation, sensitivity analysis, cumulative flow, velocity ranges.
Present options with consequences, not only numbers.
Record the decision and its rationale, and revisit if the data changes.

AI in project management

The July 2026 outline lists AI as part of the context in which projects run. AI tools can summarise status, draft reports and plans, forecast completion dates, detect schedule or budget anomalies, classify risks, and analyse lessons learned. The project manager remains accountable for the result.

When evaluating an AI-supported analysis:

Check the data used (is it complete and current? is confidential data allowed to be shared with the tool?).
Validate the output against known facts and with a human expert; AI output can be wrong or invented.
Understand limits and bias: a forecast trained on past projects may not suit a project with a new approach.
Respect policies: privacy, intellectual property, security, organisational rules for approved tools.
Keep human judgement for decisions, especially with ethical, legal or people consequences.
Document how the tool was used and how its output was verified.

The exam does not test product names; it tests judgement about benefits, trade-offs and implications.

Example: an AI forecast that looks too good

An AI assistant analysing the sprint history of a payment platform forecasts completion in 9 sprints. The project manager notices that the model assumed the average velocity of 42 points, but the last three sprints were 31, 29 and 33 because two developers left, and that the backlog grew 15% since the last data export. Re-running with the current velocity and backlog gives 14 to 17 sprints. The project manager presents both forecasts, explains the cause of the difference to the sponsor, and proposes options (backfill staff, reduce scope, move the date). The AI saved time on the analysis; human validation prevented a wrong promise.

Worked example: using data to choose between options

Statement. A project is 40% through its schedule. Planned value (PV) is EUR 400,000, earned value (EV) is EUR 340,000 and actual cost (AC) is EUR 380,000. The sponsor asks you whether to ask for more budget.

Reasoning.

Cost performance index CPI = EV / AC = 340 / 380 = 0.89. Schedule performance index SPI = EV / PV = 340 / 400 = 0.85.
The project is over budget and behind schedule. At the current rate, estimate at completion EAC = BAC / CPI. If BAC = EUR 1,000,000, EAC = 1,000,000 / 0.89 = EUR 1,123,596 (about EUR 124,000 over budget).
Before asking for funds, find the cause (rework, staffing, wrong estimates, scope growth) and options (re-plan, reduce scope, add capacity, improve quality), then present the forecast and options with their consequences to the sponsor, using the change process if the baseline is to change.

Why not ask for money straight away, or ignore it? A request without analysis lacks credibility; ignoring the variances breaks governance and transparency.

6. Common pitfalls and exam tips

Pitfalls

Treating subsidiary plans as separate documents owned by different people with no integration.
Estimating with a single number, no range, no reserves, no stated assumptions.
Using one technique for everything, or relying on the estimate of the most optimistic person.
Adding people to a late project without allowing for onboarding.
Never revisiting the business case after approval.
Re-baselining to hide poor performance.
Updating the plan informally, without change control.
Trusting AI output without verification, or sharing confidential data with an unapproved tool.

Exam tips

"Integrated" means checking the impact of a change on all plans and baselines; the best answer often begins with analysing the impact.
Choose the estimating technique from the context: early and little detail, analogous; historical data, parametric; detailed scope, bottom-up; uncertainty, three-point; agile backlog, relative sizing.
Memorise PERT (O + 4M + P) / 6 and EAC = BAC / CPI.
Changes to baselines go through integrated change control, never by informal agreement.
Business value is checked throughout; if it has disappeared, escalate to the sponsor.
With AI, the best answer validates the output, protects data and keeps human accountability.
Prefer facts and data over opinions and assumptions.

7. Mini case study

Situation. You manage the replacement of the booking platform of a ferry operator, 14 months, EUR 5.2 million, hybrid approach: milestones for regulatory approval and port-system integration, two-week sprints for the customer web app. After month 5 you consolidate the plans for the first major review. Findings: the port-system integration depends on a supplier release promised for month 8, but the schedule shows integration testing in month 7; the budget does not include a security penetration test that the new data-protection policy requires; two senior developers are planned for 100% on this project but also on a maintenance contract at 40%; the backlog has 520 points, velocity is 26 points per sprint, with 22 sprints left in the schedule; a new competitor has launched a similar app, and the marketing director now asks for a loyalty module.

Question. What do you do?

Model solution.

Calculate the forecast. 520 / 26 = 20 sprints, which fits in 22 sprints but leaves little margin; with the loyalty module (estimated 60 points) it becomes 580 / 26 = 22.3 sprints, which does not fit.
Resolve dependencies. Move integration testing after the supplier release or negotiate an earlier test version; add the dependency and its risk to the register; replan the milestone.
Fill gaps. Add the penetration test (cost estimate by quotation, activity and acceptance criteria) to the plan and the cost baseline.
Correct resources. Reflect the real 60% availability of the two developers (reducing capacity); present options: backfill, extend, reduce scope.
Re-check value. Meet the sponsor and product owner: the competitor changes the business case. Evaluate the loyalty module against the other backlog items by value and cost, not as an automatic addition.
Use change control. Prepare change requests for baseline changes (schedule, cost), with analysis of impacts on all plans and risk; get decisions from the steering committee.
Communicate and update. Update the integrated plan, the risk register, the stakeholder communication and the roadmap; record decisions.
Use data and AI carefully. If an AI tool is used to simulate forecasts, validate its input data and assumptions and document them.

Key terms

Project management plan: the approved description of how the project is executed, monitored and controlled.
Subsidiary plan: a component plan (scope, schedule, cost, quality, resources, communication, risk, procurement, stakeholders).
Baseline: the approved version of scope, schedule or cost against which performance is measured.
Analogous / parametric / bottom-up estimating: techniques based on similar projects, unit rates, or summing detail.
PERT: (O + 4M + P) / 6.
Velocity: story points completed per iteration.
Progressive elaboration: refining estimates and plans as information increases.
Integrated change control: assessing and deciding changes across all components of the plan.
Data-driven decision: a decision grounded in validated project data.

Summary checklist

I assemble an integrated plan whose subsidiary plans and baselines agree with each other.
I choose the right estimating technique and give ranges with stated assumptions.
I translate effort into resource needs, allowing for productivity and onboarding.
I review consolidated plans for dependencies, gaps and continued business value.
I maintain the plan through integrated change control and regular reviews.
I base decisions on validated data and evaluate AI-assisted analysis critically, protecting data and keeping accountability.

Official sources

PMI, PMP Examination Content Outline (July 2026), Process domain, Task 2.1: https://www.pmi.org/-/media/pmi/documents/public/pdf/certifications/new-pmp-examination-content-outline-2026.pdf (opens in a new tab)
PMI, New PMP exam (AI and sustainability within scenarios): https://www.pmi.org/certifications/project-management-pmp/new-exam (opens in a new tab)