PMP Integration Management: Processes, Examples & Exam Qs

When I first started preparing for the PMP exam, I treated Integration Management as the "boring glue" knowledge area. That was a mistake I had to unlearn quickly. Integration is where the project manager actually lives - it is the only knowledge area that sits on top of every other one, deciding which trade-offs to make when scope, schedule, cost, risk and stakeholder priorities collide. The exam knows this, and roughly one in eight situational questions I encountered touched Integration directly.

In this guide I want to walk you through pmp integration management the way I wish someone had walked me through it: by anchoring the seven processes in real project moments, not abstract definitions. I will share worked examples for each process, the inputs/tools/outputs (ITTOs) that actually matter, how a Change Control Board (CCB) really runs, and the exam traps that catch even experienced PMs.

By the end you should be able to answer integration questions on instinct, recognise when the exam is testing your judgement versus your memory, and use this knowledge area as the spine for everything else you study. Let us get into it.

Integration Management is the only knowledge area that has processes in every single process group - Initiating, Planning, Executing, Monitoring and Controlling, and Closing. That is not an accident. PMI designed it this way because the project manager's primary job is integration: balancing competing demands and making decisions when no single subsidiary plan has a clean answer.

I like to describe integration as the "shock absorber" of the project. When the schedule slips, integration is where you decide whether to crash, fast-track, descope, or escalate. When a stakeholder demands a new feature, integration is where the change request enters, gets evaluated, and either becomes baseline or gets rejected.

Exam tip I wish I had earlier: if a question describes a tension between two knowledge areas and asks what the PM should do first, the answer almost always lives in Integration - usually Perform Integrated Change Control or Monitor and Control Project Work.

If you internalise that mental model, dozens of "what would you do next" scenarios stop feeling ambiguous.

Here is the quick map I drilled into my head before the exam.

Notice that two processes sit in Executing and two in Monitoring and Controlling. That symmetry matters. Executing produces data; M&C turns data into reports and decisions.

The charter is the document that formally authorises the project and gives the PM authority to apply organisational resources. Without a charter, you are not a project manager, you are a volunteer.

Key inputs include the business case, benefits management plan, agreements (especially for external projects), and enterprise environmental factors (EEFs). Common tools are expert judgement, data gathering (brainstorming, focus groups, interviews), and interpersonal and team skills like facilitation.

Worked example. A retail bank wants to launch a digital onboarding app. The business case shows a 14-month payback. The sponsor signs a charter naming me as PM, listing high-level requirements (KYC compliance, sub-5-minute onboarding), high-level risks (regulatory delay, vendor dependency), measurable success criteria (40% reduction in branch visits), and a preliminary budget of 1.8 crore INR. That single page now lets me requisition staff and procure tools.

A charter should always include the assumption log as a companion output. Assumptions documented now save arguments later.

I think of the project management plan as the binder containing every subsidiary plan (scope, schedule, cost, quality, resource, communications, risk, procurement, stakeholder) plus the three baselines (scope, schedule, cost) and additional components like the change management plan and configuration management plan.

The plan is progressively elaborated. Early in the project it is sparse; by the time executing begins, it should be detailed enough that a new PM could pick it up and run.

Tools include expert judgement, data gathering (brainstorming, checklists, focus groups, interviews), interpersonal and team skills (conflict management, facilitation, meeting management), and meetings - notably the kick-off meeting which formally signals transition from planning to executing.

Trap to avoid: the PMI-correct answer is rarely "start executing immediately". If the plan is incomplete, the answer is usually to finish planning the relevant subsidiary plan first, then proceed.

This is the "do the work" process. Its outputs are deliverables, work performance data (raw measurements), issue log updates, change requests, and updates to the project management plan and documents.

I treat this process as where the PM spends most working hours during executing: holding team huddles, removing blockers, authorising work, and producing tangible outputs.

A subtle but important distinction:

• Work performance data = raw observations (e.g., "12 of 20 user stories done")
• Work performance information = analysed data (e.g., "we are 60% complete, on track for SPI 0.95")
• Work performance reports = formatted information ready for stakeholders

The exam loves this distinction. If a question asks what comes out of Direct and Manage Project Work, the answer is data, not information or reports.

Added in PMBOK 6, this process formalises something good PMs already did: capture and reuse both explicit knowledge (documents, data) and tacit knowledge (experience, insights).

Tools include knowledge management (networking, communities of practice, work shadowing, storytelling) and information management (knowledge libraries, lessons learned register, web searches).

The primary output is the lessons learned register, which is updated throughout the project - not just at the end. I keep mine open during every retrospective and risk review.

Worked example. During a cloud migration, my team discovered that a particular database vendor's licensing model triggered surprise costs when scaling read replicas. We logged that lesson immediately and shared it with two other PMs running similar workstreams. Six weeks later one of them avoided the same trap. That is Manage Project Knowledge in action.

Here the PM compares actual performance to the project management plan, identifies variances, and decides whether corrective or preventive action is needed.

Key tools include data analysis techniques - alternatives analysis, cost-benefit analysis, earned value analysis, root cause analysis, trend analysis, and variance analysis. Outputs are work performance reports and change requests.

Notice that change requests originate here. The PM does not just spot variances; they translate them into formal change requests that feed Process 6.

This is arguably the most tested process in Integration. Every change request - whether it originates from a stakeholder, a team member, or the PM - must pass through this process before any baseline is altered.

The flow I memorised:

1. Change request raised (documented in change log)
2. PM performs impact analysis across scope, schedule, cost, quality, risk, resources
3. Change Control Board (CCB) reviews
4. Approved, deferred, or rejected
5. If approved, baselines and subsidiary plans are updated
6. Stakeholders notified
7. Work performed against new baseline

Critical exam point: you NEVER implement a change before it is approved, even if the sponsor verbally agrees. The PMI-correct path is always through Integrated Change Control.

Closing is more than archiving. The PM must verify acceptance, transfer the product to operations, release resources, finalise procurements, capture final lessons learned, and produce a final report.

Outputs include the final product/service/result, the final report, and updates to organisational process assets (OPAs).

I have seen projects "go live" without ever being formally closed, and the consequences are real: unreleased contracts, unpaid vendors, lessons never captured, and PMs blamed months later for issues that were never their responsibility. Close every phase, every time.

A CCB is a formally constituted group responsible for reviewing, evaluating, approving, deferring, or rejecting changes. Membership typically includes the sponsor, key stakeholders, the PM, technical leads, and sometimes finance or legal representatives.

A healthy CCB has:

• A documented charter defining authority and quorum
• A standing meeting cadence (weekly is common)
• A standardised change request template
• A change log maintained by the PM
• Defined service-level expectations (e.g., emergencies decided within 24 hours)

The PM is usually the secretary, not the decision-maker. Knowing that distinction matters for exam questions where the answer hinges on "who approves the change".

You do not need to memorise every ITTO, but a handful appear repeatedly on the exam:

• Project charter - input to almost every planning process
• Project management plan - input to nearly every executing and M&C process
• Work performance data - output of executing processes
• Work performance information - output of controlling processes in each knowledge area
• Work performance reports - output of Monitor and Control Project Work
• Change requests - output of many processes, input to Integrated Change Control
• Approved change requests - output of Integrated Change Control, input to Direct and Manage Project Work
• Lessons learned register - touched by most executing and M&C processes
• Organisational process assets updates - output of Close Project or Phase

Scenario A. A senior stakeholder emails you demanding a new feature be added "by Friday". What do you do first? Document the request as a change request, perform impact analysis, route through Integrated Change Control. Do not implement, do not promise, do not refuse outright.

Scenario B. During executing you notice the SPI has dropped to 0.82. Variance analysis shows two activities slipping due to a vendor delay. The next step is to raise a change request with proposed corrective action (e.g., crashing or fast-tracking), then route through Integrated Change Control.

Scenario C. Your sponsor asks you to skip the closing phase because "we are moving to the next project". The PMI-correct response is to insist on formal closure: acceptance verification, lessons learned, resource release, procurement closure, and archiving.

Q1. A stakeholder requests an urgent scope change. What should the PM do first?

A. Implement the change immediately
B. Document the change in the change log and assess impact
C. Reject the change
D. Add the change to the next sprint backlog

Answer: B. All changes flow through Integrated Change Control, starting with documentation and impact analysis.

Q2. Which process produces work performance data?

A. Direct and Manage Project Work
B. Monitor and Control Project Work
C. Perform Integrated Change Control
D. Close Project or Phase

Answer: A. Executing produces data; M&C produces information and reports.

Q3. A project charter is signed by whom?

A. The project manager
B. The sponsor or initiator external to the project
C. The CCB
D. The functional manager

Answer: B. The charter is signed by someone with authority to authorise the project and fund it.

Q4. Which document formally authorises the existence of a project?

A. Project management plan
B. Business case
C. Project charter
D. Statement of work

Answer: C.

Q5. The PM discovers that a deliverable does not meet quality criteria. What is the next step?

A. Accept the deliverable
B. Reject it and rework outside the change control system
C. Raise a change request via Integrated Change Control
D. Escalate to the sponsor

Answer: C. Defects requiring rework typically generate change requests for defect repair.

Q6. Lessons learned should be captured:

A. Only at project closure
B. At the end of each phase
C. Throughout the project lifecycle
D. Only when problems occur

Answer: C. Manage Project Knowledge happens continuously.

Q7. Which is NOT an output of Close Project or Phase?

A. Final report
B. Project charter
C. OPA updates
D. Final product, service, or result

Answer: B. The charter is an input to closing, not an output.

Q8. A CCB has approved a change. What does the PM do next?

A. Update baselines and subsidiary plans, then communicate to stakeholders
B. Start implementing immediately
C. Re-validate with the sponsor
D. File the change request

Answer: A. Update plans and baselines, then communicate, then execute.

Q9. Work performance reports are inputs to which process most directly?

A. Direct and Manage Project Work
B. Perform Integrated Change Control
C. Develop Project Charter
D. Manage Project Knowledge

Answer: B. Reports inform change decisions.

Q10. Which of these is part of the project management plan?

A. Risk register
B. Stakeholder register
C. Scope baseline
D. Issue log

Answer: C. Baselines (scope, schedule, cost) are part of the PM plan. Registers are project documents.

I want to highlight the traps that personally caught me during practice exams.

• "Implement first, document later" answers. Never correct. Integrated Change Control comes first.
• Confusing data, information, and reports. Memorise which process outputs which.
• Charter vs PM plan. Charter is high-level and authorising; PM plan is detailed and guiding.
• Sponsor vs PM authority. The sponsor authorises; the PM executes. Sponsor signs charter; PM owns the plan.
• Closing being "optional". Never optional on the exam. Always close formally.
• CCB authority. The CCB approves; the PM facilitates and implements approved changes.
• Lessons learned timing. Continuous, not end-of-project only.

If you can avoid these seven traps, you will likely outperform on integration questions by 15-20%.