Shashank Shastri
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.
PMP Integration Management: Processes, Examples & Exam Questions
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.
Why Integration Management Sits at the Centre
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.
The Seven Integration Processes at a Glance
Here is the quick map I drilled into my head before the exam.
| # | Process | Process Group | Primary Output |
|---|---|---|---|
| 1 | Develop Project Charter | Initiating | Project charter |
| 2 | Develop Project Management Plan | Planning | Project management plan |
| 3 | Direct and Manage Project Work | Executing | Deliverables, work performance data |
| 4 | Manage Project Knowledge | Executing | Lessons learned register |
| 5 | Monitor and Control Project Work | Monitoring & Controlling (M&C) | Work performance reports, change requests |
| 6 | Perform Integrated Change Control | Monitoring & Controlling (M&C) | Approved change requests |
| 7 | Close Project or Phase | Closing | Final product, final report |
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.
Process 1: Develop Project Charter
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.
Process 2: Develop Project Management Plan
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.
Process 3: Direct and Manage Project Work
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.
Process 4: Manage Project Knowledge
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.
Process 5: Monitor and Control Project Work
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.
| Variance Type | Likely Action |
|---|---|
| Within tolerance | Continue project work and monitor performance. |
| Outside tolerance, low impact | Take corrective action through a change request. |
| Outside tolerance, high impact | Escalate the issue and implement preventive action, along with a change request if needed. |
| New risk discovered | Update the risk register and submit a change request if mitigation requires changes. |
Process 6: Perform Integrated Change Control
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:
- Change request raised (documented in change log)
- PM performs impact analysis across scope, schedule, cost, quality, risk, resources
- Change Control Board (CCB) reviews
- Approved, deferred, or rejected
- If approved, baselines and subsidiary plans are updated
- Stakeholders notified
- 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.
Process 7: Close Project or Phase
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.
How a Change Control Board Actually Runs
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".
Key ITTOs You Must Recognise
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
Worked Mini-Scenarios
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.
Sample Exam Questions with Answers
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.
Common Exam Traps in Integration
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%.
Shashank Shastri is a PMP trainer with over 14 years of experience and co-founder of Oven Story. He is an inspiring product leader who is a master in product strategies and digital innovation. Shashank has guided many aspirants preparing for the PMP examination thereby assisting them to achieve their PMP certification. For leisure, he writes short stories and is currently working on a feature-film script, Migraine.
Questions people ask
Published