Integration Management: the PM’s “connective tissue” job
Integration Management is the work of keeping the project coherent as reality changes. It connects objectives to plans, plans to execution, execution to measurement, and measurement to decisions. If scope, schedule, cost, quality, resources, and risk are separate “organs,” integration is the nervous system that coordinates them.
On the PMP exam, Integration is less about memorizing documents and more about choosing the right integration action: align, decide, authorize, escalate, or communicate—at the right level of authority.
What the PM integrates (in plain language)
- Objectives → Work: translate business need into deliverables and outcomes people can execute.
- Plans → Reality: keep the project management plan and subsidiary plans usable as the team learns.
- Work → Information: consolidate status, forecasts, and performance into decision-ready insights.
- Changes → Control: ensure changes are evaluated for impacts and approved by the right authority before implementation.
- Stakeholders → Decisions: route decisions to the correct owner (PM, sponsor, customer, CCB) and document them.
Charter vs. Project Management Plan vs. Subsidiary Plans
Project Charter (authorization + high-level direction)
The charter is the project’s “permission slip” and north star. It authorizes the project and the PM, and it sets the high-level intent.
| Charter answers… | Examples |
|---|---|
| Why are we doing this? | Business case, problem/opportunity, success criteria |
| What are we aiming for (at a high level)? | High-level scope, key deliverables, major milestones |
| Who has authority and funding? | Sponsor, initial budget, PM authority level |
| What constraints matter most? | Fixed deadline, regulatory requirement, budget cap |
Integration angle: If a decision changes the charter-level intent (e.g., success criteria, funding, major scope), it is typically sponsor/customer territory, not a PM-only decision.
Project Management Plan (the integrated “how we will manage”)
The project management plan is the integrated set of baselines and management approaches. It is not just a schedule or a Gantt chart; it is the master playbook for how the project will be executed, monitored, and controlled.
- Listen to the audio with the screen off.
- Earn a certificate upon completion.
- Over 5000 courses for you to explore!
Download the app
| Plan component | What it does |
|---|---|
| Baselines | Scope baseline, schedule baseline, cost baseline (used to measure variance) |
| Management plans | How you will manage scope, schedule, cost, quality, resources, communications, risk, procurement, stakeholders |
| Change management plan | How changes are requested, evaluated, approved, and implemented |
| Configuration management plan | How product documents/components are versioned and controlled |
Integration angle: The PM is accountable for keeping the plan integrated and current. When something changes, you don’t “just update the schedule”—you evaluate impacts across baselines and subsidiary plans.
Subsidiary plans (specialized “how we manage X”)
Subsidiary plans are the specialized playbooks (risk management plan, communications management plan, etc.). They must align with each other and with the integrated project management plan.
Common exam trap: A team member updates a subsidiary plan (like the schedule) without going through change control when the baseline is affected. If the baseline changes, it’s a change request; if you are only refining details within approved tolerances, it may be a plan update without formal change approval (depending on the change management plan).
Handling conflicts between constraints (trade-offs)
Constraints conflict because optimizing one often harms another. Integration is the discipline of making trade-offs explicit, deciding at the right authority level, and documenting the decision.
Typical constraint conflicts and how a PM integrates them
| Conflict | What integration requires | Example PM action |
|---|---|---|
| Schedule vs. Cost | Quantify options and impacts; get approval if baseline changes | Analyze crashing vs. fast-tracking; submit change request if budget/schedule baseline changes |
| Scope vs. Schedule | Clarify must-have vs. nice-to-have; protect success criteria | Facilitate scope trade-off workshop; propose phased delivery; escalate if charter success criteria threatened |
| Quality vs. Schedule | Ensure quality requirements are not silently reduced | Reject “skip testing” as an informal change; raise change request or escalate to sponsor/customer |
| Risk vs. Cost | Decide risk response funding and contingency use | Use contingency per plan; if reserves are insufficient, escalate and propose options |
Step-by-step: a practical trade-off method (PMP-friendly)
- State the conflict in one sentence: “We can meet the deadline only by adding two contractors or reducing scope.”
- Identify what is fixed vs. flexible: Is the deadline contractual? Is scope negotiable? Is budget capped?
- Generate 2–4 options: e.g., crash, fast-track, re-sequence, reduce scope, add automation, extend deadline.
- Quantify impacts: cost delta, schedule delta, quality impact, risk exposure, procurement lead times.
- Check authority: Can the PM decide within tolerances? If not, route to sponsor/customer/CCB.
- Document decision and update artifacts: update plan, baselines (if approved), communications, and work authorization.
Who approves what (Sponsor vs. Customer vs. CCB vs. PM)
Integration is also governance: knowing who can authorize what. The exam often tests whether you route decisions correctly.
Typical approval boundaries
| Decision type | Usually approved by | Notes |
|---|---|---|
| Project initiation / charter authorization | Sponsor (and sometimes customer) | Charter authorizes the PM and funding at a high level |
| Changes to baselines (scope/schedule/cost) | Change Control Board (CCB) or designated change authority | Defined in the change management plan; may include sponsor/customer reps |
| Product acceptance of deliverables | Customer or customer representative | Acceptance criteria defined; PM facilitates but does not “accept” on customer’s behalf |
| Use of contingency reserves | PM (if allowed by plan) or sponsor/CCB (if beyond authority) | Management reserves are typically sponsor-controlled |
| Day-to-day work assignments | PM (or functional manager in matrix) | Depends on organizational structure and resource agreements |
| Process changes (how the team works) | PM within project; organizational process changes may require management approval | Project-level process tweaks may be handled as plan updates; major changes may require formal approval |
Exam cue: If the scenario mentions “baseline,” “contract,” “customer acceptance,” or “charter objectives,” assume you need formal approval and/or escalation rather than an informal update.
Decision flow: Issue vs. Risk vs. Change Request
Many integration questions boil down to categorizing the situation correctly. Use this decision flow to choose the right next action.
Fast decision flow (text-based)
1) Has it already happened (is it impacting work now)? → YES: It's an ISSUE (or a defect/nonconformance as a type of issue) → go to 2a/3a/4a. → NO: It's a potential future event → It's a RISK → go to 2b/3b/4b. 2a) ISSUE: Does resolving it require changing an approved baseline or contract? → YES: Create a CHANGE REQUEST (with impact analysis) and submit to CCB/change authority. → NO: Handle within authority (corrective action), update logs/plan as needed, communicate. 2b) RISK: Is it already identified? → NO: Add to risk register, analyze, plan response. → YES: Review triggers, response owner, and reserves. 3a) ISSUE: Is it outside PM authority or threatens charter success criteria? → YES: Escalate to sponsor/management with options. → NO: Implement approved corrective action and update documentation. 3b) RISK: Does the response require baseline changes or additional funding beyond reserves? → YES: Raise change request / escalate per governance. → NO: Implement risk response per plan. 4a/4b) In all cases: Communicate to stakeholders per communications plan and update relevant artifacts.How the three categories differ (quick reference)
| Category | Definition | Primary tool | Typical integration action |
|---|---|---|---|
| Issue | Something is happening now (problem, blocker, defect) | Issue log | Corrective action; may require change request; escalate if needed |
| Risk | Something might happen in the future (uncertainty) | Risk register | Plan/implement risk response; use reserves; change request if baselines impacted |
| Change request | A formal proposal to modify baselines, scope, or approved plans | Change log + impact analysis | Submit to CCB/change authority; implement only after approval |
The PM’s integration actions (what to do next)
When the exam asks “What should the PM do next?”, it’s often testing one of these integration moves.
1) Update the plan (without changing baselines)
Use when you are refining how you will do the work within approved boundaries.
- Examples: updating the communications cadence, adding more detail to a work package approach, clarifying roles, updating risk response owners.
- Artifacts: project management plan (relevant subsidiary plan), issue log, risk register, lessons learned register.
2) Process a change request (formal change control)
Use when you need to change an approved baseline, contract terms, or a controlled configuration item.
- Examples: adding a feature, moving a milestone, increasing budget, changing acceptance criteria, changing a vendor deliverable date that affects the schedule baseline.
- Artifacts: change request, impact analysis, change log, updated baselines (after approval).
3) Escalate (route a decision beyond PM authority)
Use when the decision exceeds the PM’s authority, threatens charter objectives, or requires organizational intervention.
- Examples: sponsor decision needed on funding, customer decision needed on acceptance trade-off, functional manager refusing resources in a way that jeopardizes commitments.
- Artifacts: escalation note with options, decision log, updated stakeholder communications.
4) Communicate (align stakeholders and prevent surprises)
Use when the primary need is alignment, expectation management, or awareness—especially when no baseline change is required.
- Examples: informing stakeholders of a resolved issue, sharing forecast changes within tolerance, confirming decisions and next steps.
- Artifacts: status report, meeting notes, updated RAID items (Risks, Assumptions, Issues, Dependencies).
Practice items: identify the correct integration action
Choose the best next integration action: (A) Update plan, (B) Process change request, (C) Escalate, or (D) Communicate.
Item 1
A developer reports that a key API endpoint is returning errors in the test environment today. The fix is expected to take one day and does not affect any baseline milestones.
- Best action: A (Update plan)
- Why: This is an issue requiring corrective action within authority; update issue log and coordinate fix. Communicate as needed, but the integration move is to manage it within the plan.
Item 2
The customer requests an additional report in the product that was not in the approved requirements. The team estimates it will add two weeks and $15,000.
- Best action: B (Process change request)
- Why: New scope with schedule/cost impacts; requires formal evaluation and approval before implementation.
Item 3
A supplier notifies you that a component will arrive three weeks later than planned, which will push the critical path beyond the committed launch date. Your contract allows no schedule slip without customer approval.
- Best action: B (Process change request)
- Why: The baseline/contract commitment is affected; submit change request with options (alternate supplier, expediting, re-sequencing). Escalation may follow, but first route through formal change control per governance.
Item 4
The sponsor tells you the launch date is fixed due to a public announcement. The team proposes skipping performance testing to meet the date.
- Best action: C (Escalate)
- Why: This is a major quality trade-off that can threaten success criteria and organizational risk exposure. The PM should escalate with options (crash, reduce scope, phased release) rather than silently reducing quality.
Item 5
You discover that the communications plan does not specify how to handle urgent production incidents during rollout. No baselines are affected.
- Best action: A (Update plan)
- Why: This is a planning gap; update the communications management plan and stakeholder expectations.
Item 6
A team member suggests a new internal workflow that would reduce rework, but it requires changing the organization’s standard QA gate used across multiple projects.
- Best action: C (Escalate)
- Why: Cross-project organizational process changes typically require management/PMO approval; the PM can propose it but must escalate to the appropriate authority.
Item 7
A risk trigger occurs: a regulatory review is announced that could delay approvals next month. Your risk response plan includes reserving a compliance consultant and using contingency funds already approved for this risk.
- Best action: A (Update plan)
- Why: Implement the planned risk response within approved reserves; update the risk register and relevant plans. No new baseline change is implied.
Item 8
During execution, you notice schedule variance trending negative, but still within the tolerance thresholds defined in the project management plan. Stakeholders are unaware.
- Best action: D (Communicate)
- Why: No formal change is required yet; integration requires proactive communication and expectation management while continuing to monitor.
Mini-scenarios: issue vs. risk vs. change request (classification drill)
- Scenario A: “There is a 30% chance the data migration tool will fail on large datasets.” → Risk
- Scenario B: “The data migration tool failed during today’s run.” → Issue
- Scenario C: “To prevent future failures, we want to replace the tool, which adds $20,000 and two weeks.” → Change request
Integration checkpoints the PM should run routinely
- Alignment check: Are we still optimizing for the charter success criteria, or drifting toward local team preferences?
- Baseline integrity check: Are teams making “silent changes” to scope/schedule/cost without approval?
- Decision ownership check: Is the decision being made by the right authority (PM vs. sponsor vs. customer vs. CCB)?
- Documentation check: Are decisions reflected in the plan, logs, and communications so the project stays coherent?
