Project Integration Management is the PMBOK knowledge area that ties the entire project together. It coordinates all other knowledge areas — scope, schedule, cost, quality, resource, communications, risk, procurement and stakeholder management — ensuring they work as a coherent whole rather than isolated silos. It contains seven processes: Develop Project Charter, Develop Project Management Plan, Direct and Manage Project Work, Manage Project Knowledge, Monitor and Control Project Work, Perform Integrated Change Control, and Close Project or Phase. The project manager owns integration management entirely — it is the one knowledge area that cannot be delegated. Every decision that affects the whole project, every change that touches a baseline, every lesson worth capturing — all of it flows through integration management.
Open PMBOK 6 to Chapter 4 and you find Project Integration Management listed first. That placement is deliberate. PMI is making a statement about what project management actually is: before you manage scope, or schedule, or risk, you must have a mechanism for making them all work together. That mechanism is integration management.
The word "integration" here means something specific. It does not mean "doing everything at once." It means recognising that every project decision creates ripple effects across all other areas — and managing those interdependencies consciously. When a stakeholder requests a scope change, integration management asks: what does this do to the schedule? To the cost baseline? To the risk register? To the communications plan? Only when all of those questions have answers does the PM make a decision.
This guide covers all seven integration management processes in depth — what each process does, what goes into it, what comes out of it, and what the exam tests about each one. It also covers how integration management is reframed in PMBOK 7 and what an experienced PM needs to know about applying these concepts in Agile and hybrid environments.
What Is Project Integration Management?
Project Integration Management is the knowledge area responsible for identifying, defining, combining, unifying and coordinating the various processes and project management activities within the project management process groups. In plain English: it is how a project manager holds everything together.
Every other knowledge area manages a specific aspect of the project in relative isolation — scope management focuses on scope, schedule management on time, risk management on uncertainty. Integration management is the connective tissue between all of them. It ensures that when the risk register changes, the schedule reflects it. When a change is approved, all affected plans are updated. When the project closes, all knowledge is captured and handed over.
PMBOK is explicit about who owns integration management: the project manager. Unlike scope management (where the sponsor approves the scope baseline) or procurement management (where the procurement team handles contracts), integration management sits entirely with the PM. This is the role's unique accountability — the big picture, the whole system, the final call on trade-offs that affect the project as an integrated entity.
Why Integration Management Is Placed First in PMBOK
PMBOK lists Integration Management as Knowledge Area 1 because everything else depends on it. Without a project charter, there is no authorised project. Without a project management plan, there is no coherent framework for executing scope, schedule, cost and all the rest. Without integrated change control, approving a change to scope without updating the schedule leads to conflicting baselines. Integration management is the skeleton on which all other project management knowledge hangs.
The Seven Integration Management Processes — Overview
The seven processes span the complete project lifecycle — from the first act of authorising the project to the final act of closing it.
Process 1 — Develop Project Charter
The project charter is the document that formally authorises the project to exist and gives the project manager authority to apply organisational resources to project activities. Without a signed project charter, the project does not officially exist within the organisation's governance framework.
Developing the project charter means working with the sponsor to document the project's purpose, measurable objectives, high-level requirements, assumptions, constraints, initial risks, stakeholder list, project approval requirements and the PM's authority level. The charter does not go into detail — that comes later in planning. It establishes the why, the who, and the rough shape of the what.
- Business documents (business case, benefits management plan)
- Agreements (contracts, MOUs)
- Enterprise environmental factors (EEFs)
- Organisational process assets (OPAs) — previous project charters, templates
- Expert judgement — from stakeholders, PMO, subject matter experts
- Data gathering — brainstorming, focus groups, interviews
- Interpersonal and team skills — conflict management, facilitation
- Meetings — with sponsor, key stakeholders
- Project charter — the primary and most important output
- Assumption log — initial assumptions documented
Who signs the project charter? The project sponsor — not the project manager. The PM may draft it, but the sponsor authorises it. A charter signed by the PM is not a valid authorisation. This is one of the most tested facts about the charter on the PMP exam.
What about Agile projects? Agile projects still benefit from a project charter at initiation — it establishes the PM's authority, the business case and the high-level objectives. In some Agile frameworks a lighter artifact called a project brief serves the same purpose. In hybrid environments, the charter covers governance and authorisation while the product backlog covers scope definition.
Process 2 — Develop Project Management Plan
The Project Management Plan (PMP — confusingly the same acronym as the certification) is the master document that defines how the project will be executed, monitored, controlled and closed. It is not a single document but a collection of subsidiary plans and baselines integrated into one coherent whole.
Creating the PMP is itself an integration exercise. The scope management plan, schedule management plan, cost management plan and every other subsidiary plan must be internally consistent — if the scope plan says changes to scope require CCB approval but the schedule plan says the PM can approve schedule changes independently, there is a contradiction that needs resolving. The Develop PMP process is where all of those interdependencies are ironed out.
- Project charter — sets the authorised scope and objectives the plan must address
- Outputs from other planning processes — scope baseline, schedule baseline, cost baseline
- Enterprise environmental factors
- Organisational process assets — PM plan templates, lessons learned from previous projects
- Expert judgement
- Data gathering — brainstorming, checklists, focus groups, interviews
- Interpersonal and team skills — conflict management, facilitation
- Meetings — planning sessions with the team and key stakeholders
- Project management plan — the master planning document
- Includes all subsidiary plans: scope, requirements, schedule, cost, quality, resource, communications, risk, procurement, stakeholder engagement management plans
- Includes all baselines: scope baseline, schedule baseline, cost baseline (collectively the performance measurement baseline)
The Subsidiary Plans
The project management plan contains up to ten subsidiary management plans — one for each knowledge area. Each defines how that knowledge area will be managed throughout the project:
- Scope Management Plan — how scope will be defined, validated and controlled
- Requirements Management Plan — how requirements will be elicited, documented and traced
- Schedule Management Plan — scheduling methodology, tool, update frequency and variance thresholds
- Cost Management Plan — estimating approach, budget aggregation method, EVM thresholds
- Quality Management Plan — quality standards, QA activities, QC metrics
- Resource Management Plan — how physical and human resources will be acquired and managed
- Communications Management Plan — who receives what information, how often, through which channel
- Risk Management Plan — risk categories, probability/impact scales, risk appetite, review frequency
- Procurement Management Plan — what will be procured, when, through which contract type
- Stakeholder Engagement Plan — strategies for engaging each stakeholder group
Alongside the plans sit the three baselines: scope baseline (scope statement + WBS + WBS dictionary), schedule baseline (approved project schedule), and cost baseline (time-phased budget). Together these three form the Performance Measurement Baseline used in EVM.
Process 3 — Direct and Manage Project Work
This is the process of actually doing the project. All the planning in processes 1 and 2 produces plans — Direct and Manage Project Work is where those plans are executed. The PM leads the team to perform the activities defined in the project management plan, manages external stakeholders, resolves issues as they emerge, and keeps the work progressing toward the project objectives.
The key integration role here is that the PM is not just executing their own tasks — they are integrating the work across all knowledge areas simultaneously. On any given day, the PM might be resolving a scope question (scope management), unblocking a resource constraint (resource management), responding to a stakeholder concern (communications and stakeholder management) and reviewing a risk response (risk management) — all of which connect back to the project management plan and may generate work performance data that feeds the monitoring processes.
- Project management plan — all subsidiary plans and baselines
- Project documents — activity list, assumption log, lessons learned register, milestone list, project communications, risk register, risk report, stakeholder register
- Approved change requests — only approved changes are implemented
- Enterprise environmental factors
- Organisational process assets
- Expert judgement
- Project management information system (PMIS) — scheduling, cost, reporting tools
- Meetings — status meetings, team standups, stakeholder reviews
- Deliverables — completed outputs from project work packages
- Work performance data — raw measurements: tasks completed, costs incurred, defects found
- Issue log updates
- Change requests — arising from execution (discovered issues, scope questions)
- Project management plan updates
- Project document updates
Change requests during execution: Issues discovered while doing the work often trigger change requests — a requirement that is ambiguous, a technical constraint that was not anticipated, a risk that has materialised. These change requests go to the Perform Integrated Change Control process. Critically, work does not stop while a change request is being assessed unless the change affects currently in-progress work. The PM continues executing approved work while the change goes through the process.
Process 4 — Manage Project Knowledge
Manage Project Knowledge was added as a named process in PMBOK 6 — recognising that knowledge management had become a critical but often neglected project management activity. The process covers using existing organisational knowledge to improve current project outcomes, and creating new knowledge that can benefit future projects.
Knowledge exists in two forms that require different management approaches. Explicit knowledge — documents, procedures, specifications — can be captured in databases, wikis and lessons learned registers. Tacit knowledge — experience, expertise, judgement — is much harder to capture and transfer. A veteran engineer's intuition about where technical risks lurk cannot be written down in a lessons learned document. Tacit knowledge transfers through mentoring, job shadowing, workshops and team conversations. Both types matter, and the PM must create conditions for both to flow.
- Project management plan — especially the resource and stakeholder plans
- Project documents — lessons learned register, project team assignments, resource breakdown structure
- Deliverables — the outputs of project work that carry embedded knowledge
- Enterprise environmental factors — organisational culture, knowledge sharing norms
- Organisational process assets — existing lessons learned databases, knowledge repositories
- Expert judgement
- Knowledge management — lessons learned meetings, communities of practice, knowledge repositories
- Information management — PMIS, document management systems, wikis
- Interpersonal and team skills — active listening, facilitation, networking, leadership
- Lessons learned register — the primary output; documents what worked, what did not, and what should be done differently
- Project management plan updates
- OPA updates — contributions to the organisation's knowledge base
Why tacit knowledge matters more than organisations realise: When an experienced project manager or technical lead leaves a project mid-delivery, the explicit knowledge (documents, plans) remains. The tacit knowledge — their relationships with stakeholders, their understanding of the political landscape, their instincts about where the risks are — leaves with them. The PM's job is to create as many forums as possible for tacit knowledge to be shared and embedded in the team before any key person departs.
Process 5 — Monitor and Control Project Work
Monitor and Control Project Work is the process of tracking, reviewing and reporting overall project progress against the performance objectives defined in the project management plan. It is continuous throughout the project lifecycle — running in parallel with execution from the moment work begins until the project closes.
The integration role here is critical: while individual knowledge areas monitor their own metrics (the schedule management processes monitor schedule performance, cost management monitors cost performance), Monitor and Control Project Work takes an integrated view — how is the whole project performing? Are the cost and schedule variances moving in the same direction? Is a risk that is materialising affecting multiple knowledge areas simultaneously? The PM synthesises all of these signals into an integrated assessment of project health.
- Project management plan — all baselines and subsidiary plans
- Project documents — assumption log, basis of estimates, cost forecasts, issue log, lessons learned register, milestone list, quality reports, risk register, risk report, schedule forecasts
- Work performance information (WPI) — analysed performance data from executing processes
- Agreements (for procurement-related monitoring)
- Enterprise environmental factors
- Organisational process assets
- Expert judgement
- Data analysis — alternatives analysis, cost-benefit analysis, earned value analysis, root cause analysis, trend analysis, variance analysis
- Decision making — voting, autocratic decision making, multi-criteria decision analysis
- Meetings — status meetings, retrospectives (Agile)
- Work performance reports — status reports, progress reports, trend reports, forecasts; distributed to stakeholders
- Change requests — corrective actions, preventive actions, defect repairs
- Project management plan updates
- Project document updates
Types of change requests from Monitor and Control: When monitoring reveals a deviation from plan, the PM has three categories of response: Corrective actions (realign current performance with the plan — e.g. add resources to a slipping task), Preventive actions (reduce the probability of future negative events — e.g. add testing steps to prevent quality issues), and Defect repairs (fix a product defect identified during monitoring). All three are submitted as change requests to Perform Integrated Change Control.
Process 6 — Perform Integrated Change Control
Perform Integrated Change Control is the process of reviewing all change requests, approving or rejecting them, and managing changes to deliverables, project documents and the project management plan. It is one of the most critical processes in the entire PMBOK framework — and the word "integrated" is doing significant work in the name.
The reason change control must be integrated rather than managed by each knowledge area independently is that every change on a project has cross-cutting implications. A scope change almost certainly affects the schedule (more work = more time). It probably affects cost (more work = more money). It may affect quality (rushed additions may reduce quality), risk (new scope introduces new uncertainty) and resources (more work may require more people). Managing these changes through separate processes — scope change here, schedule update there — would inevitably create inconsistencies in the project management plan. Integrated change control ensures that when any change is approved, all affected elements are updated simultaneously.
- Project management plan — change management plan, configuration management plan, scope/schedule/cost baselines
- Project documents — basis of estimates, requirements traceability matrix, risk report
- Work performance reports
- Change requests — from executing processes, monitoring processes, stakeholders
- Enterprise environmental factors
- Organisational process assets
- Expert judgement
- Change control tools — change management software, PMIS
- Data analysis — alternatives analysis, cost-benefit analysis
- Decision making — Change Control Board (CCB) is the primary decision-making body
- Meetings — CCB meetings to review and decide on change requests
- Approved change requests — changes approved by the CCB
- Project management plan updates — baseline updates for approved changes
- Project document updates — all documents affected by the approved change
The Change Control Board (CCB)
The Change Control Board is the governance body responsible for reviewing and deciding on change requests. Its composition varies — on small projects the CCB might be the PM and sponsor; on large programs it might include representatives from all key stakeholders, the PMO and technical leads. The CCB's decisions are documented in the change log.
Key CCB principles:
- The PM does not typically have sole authority to approve changes that affect baselines — the CCB does
- The PM may have authority to approve minor changes within pre-defined thresholds (as defined in the change management plan)
- Emergency changes may follow an expedited CCB process — but they still go through the process
- Rejected changes are still documented in the change log, along with the reason for rejection
The exam will repeatedly test whether you know the correct sequence: (1) change request submitted, (2) impact assessed, (3) CCB reviews and decides, (4) if approved — implement and update all project documents and baselines, (5) communicate outcome to requestor. The most common wrong answers are implementing first and documenting after, or the PM approving a baseline change without CCB review. Neither is ever correct on the exam.
Process 7 — Close Project or Phase
Close Project or Phase is the process of finalising all activities across all project management process groups to formally complete the project or phase. It is the final integration act — bringing together all threads of the project into a clean, documented close that hands value to the organisation and knowledge to the future.
Project closure is far more than filing paperwork. Done properly, it includes obtaining formal acceptance of deliverables, releasing project resources, archiving project records, completing procurement closures, capturing final lessons learned, and formally communicating that the project is complete. Done poorly — or skipped — it leaves the organisation with unresolved contracts, ambiguous deliverable ownership, missing documentation and lost knowledge.
- Project charter — to confirm all project objectives were met
- Project management plan — all components, to verify all planned work is complete
- Project documents — assumption log, basis of estimates, change log, issue log, lessons learned register, milestone list, project communications, quality control measurements, quality reports, requirements documentation, risk register, risk report
- Accepted deliverables — formally accepted outputs from Validate Scope
- Business documents — business case, benefits management plan
- Agreements — contracts to be closed
- Procurement documentation
- Organisational process assets
- Expert judgement
- Data analysis — document analysis, regression analysis, trend analysis, variance analysis
- Meetings — final retrospective, lessons learned session, close-out meeting with sponsor
- Project documents updates — all project documents finalised and archived
- Final product, service or result transition — formal handover to operations
- Final report — summary of project performance against objectives, scope, schedule, cost, quality and risk
- OPA updates — lessons learned added to organisational process assets; templates updated
Phase closure vs project closure: On large projects with multiple phases, each phase ends with a phase gate — a formal review where the sponsor decides whether to proceed to the next phase. Close Project or Phase applies to both — each phase closure confirms the phase's deliverables, updates lessons learned, and formally authorises progression. Project closure at the end confirms the entire project is complete and delivers the final handover.
Administrative closure vs contract closure: Administrative closure refers to closing the project's internal governance processes — archiving documents, releasing team members, completing performance evaluations. Contract closure refers to closing each vendor contract — verifying deliverables were received, invoices are settled and obligations are fulfilled. Both must be completed before the project can be considered truly closed.
How PMBOK 7 Frames Integration Management
PMBOK 7 does not organise knowledge into knowledge areas and processes the way PMBOK 6 does — instead it defines 12 principles and 8 performance domains. Integration management does not appear as a named entity in PMBOK 7. But its spirit is embedded throughout.
For PMP exam purposes: The current PMP exam blends PMBOK 6 and PMBOK 7 content. Knowledge of the PMBOK 6 integration management processes — all seven, with their inputs, tools and outputs — is still relevant for scenario-based questions that reference specific processes, artifacts and the change control framework. The PMBOK 7 principles provide the underlying rationale for why those processes exist and how they connect.
Key Integration Management Artifacts — Reference
Integration Management on the PMP Exam — What Is Actually Tested
Integration management questions appear in all three ECO domains — People, Process and Business Environment. They are frequently embedded in scenarios rather than tagged explicitly as "integration management." Here is what to watch for.
Preparing for the PMP Exam?
Integration management concepts appear throughout the PMP exam across all three ECO domains. The free study guide covers the complete 16-week preparation plan — and the 200 free practice questions include integration management scenarios.