Without a central nervous system, a project is just a collection of disconnected tasks that pull in different directions, causing delays, budget overruns, and missed deadlines. Project Integration Management is the discipline that stitches all those pieces together into a single, coherent effort, ensuring that every decision, every change, and every deliverable is aligned with the project’s overall goals. For the CAPM exam, understanding this topic is critical because it underpins the processes that make or break a project’s success — specifically how you get started with a project charter and how you handle changes without causing chaos.
Jump to a section
A simple way to picture Project Integration Management
A large house in the suburbs, mid-renovation. The homeowner, Sarah, has hired a team: electricians, plumbers, carpenters, and painters. Each team has its own to-do list and its own schedule. The electricians want to rewire the living room on Tuesday, but the painters need that room empty on Monday, and the plumbers are waiting for the carpenter to open a wall in the bathroom before they can install new pipes. Without a central plan, the house descends into chaos: the painters paint a wall that the electrician immediately needs to cut into, and the plumber floods a half-finished room because the carpenter built a frame over the wrong pipe.
Sarah’s cousin Liam steps in as the integration manager. He is not doing any of the work himself. His job is to see the entire project as one connected system. He creates a single master schedule that sequences every trade so that the carpenter opens the wall first, the plumber installs the pipe second, the electrician wires around it third, and the painter finishes last. He also sets up a change log: when the client decides they want a skylight in the kitchen halfway through, Liam doesn’t just say yes. He documents the request, assesses its impact on the budget and timeline, and then gets formal approval before the carpenter cuts a hole in the roof. This ensures every decision is coordinated, every trade knows the current plan, and the house is finished on time and on budget. This is exactly what Project Integration Management does for an IT project: it ties all the separate pieces together into one coherent, controlled effort.
Project Integration Management is the glue that holds a project together. It is the set of processes and activities that coordinate all the other knowledge areas — scope, schedule, cost, quality, resources, communications, risk, procurement, and stakeholders — into a unified whole. Think of it as the conductor of an orchestra: the conductor does not play any instrument, but without them, the violins, brass, drums, and woodwinds would each play their own tune, and the result would be noise instead of music.
In the real world of IT projects, teams work on different pieces of a system simultaneously. One team writes code for a new feature, another team tests the existing system, a third team sets up cloud servers, and a fourth team writes documentation. Without integration, these teams might produce code that doesn’t work on the servers the cloud team chose, or the documentation might describe a feature that was removed during testing. Project Integration Management prevents this by creating a single source of truth that everyone follows.
There are seven key processes in Project Integration Management, broken into five process groups:
Develop Project Charter (Initiating): This is the formal authorisation to start the project. The project charter is a document issued by a sponsor — usually a senior executive — that gives the project manager the authority to use organisational resources to carry out the project. It states the high-level purpose, key objectives, and the person responsible for success.
Develop Project Management Plan (Planning): The project management plan is the master plan that integrates all the subsidiary plans (scope, schedule, cost, etc.) into one coherent document. It defines how the project will be executed, monitored, controlled, and closed. It is not created in one go; it is progressively elaborated over time.
Direct and Manage Project Work (Executing): This is where the actual work gets done. The project manager leads the team, performs the work defined in the project management plan, and produces the project deliverables. It also includes managing any changes that arise during execution.
Manage Project Knowledge (Executing): This process ensures that lessons learned and organisational knowledge are captured, stored, and reused. It helps the team avoid repeating mistakes and builds on past successes.
Monitor and Control Project Work (Monitoring and Controlling): Here, the project manager tracks actual performance against the plan. They look at progress, costs, schedules, and quality. If something is off, they take corrective or preventive action to bring the project back on track.
Perform Integrated Change Control (Monitoring and Controlling): This is the formal process for managing changes. Any change request — whether about scope, schedule, cost, or anything else — goes through a structured review. The change is evaluated for its impact on the entire project, approved or rejected by a change control board (CCB), and then documented. No one can just decide to add a feature or change a deadline without going through this process.
Close Project or Phase (Closing): At the end of the project or a phase, everything is formally completed. Contracts are closed, final reports are produced, resources are released, and the project is archived. This ensures that nothing is left unfinished.
Why does Project Integration Management exist? Because projects are complex. Without it, you get scope creep (uncontrolled additions), schedule delays, budget overruns, and frustrated stakeholders. It provides a structured way to decide what to do, how to do it, what to change, and when to stop. It replaces the chaos of multiple people making uncoordinated decisions with a clear, repeatable framework.
For the CAPM exam, two parts of this topic are most heavily tested: the project charter and integrated change control. The charter must contain the business case, milestones, high-level risks, budget, and the assigned project manager. Integrated change control is tested through scenarios where you have to decide the correct sequence of steps after a change request is made.
Develop Project Charter
A sponsor issues a document that formally authorises the project. This step gives the project manager authority to use organisational resources and defines the high-level scope, objectives, and key stakeholders.
Develop Project Management Plan
The project manager and team create the master plan that integrates all subsidiary plans (scope, schedule, cost, quality, etc.). This plan is baselined and then updated as changes are approved.
Manage Project Work and Knowledge
The team executes the work defined in the plan. The project manager also ensures lessons learned from past projects are applied and new knowledge is captured for future use.
Monitor and Control Project Work
Actual performance data is compared against the plan. If there is a variance, the project manager decides on corrective or preventive actions to keep the project on track.
Perform Integrated Change Control
Every change request goes through a formal review. The impact is assessed across all constraints (cost, schedule, scope, quality). The change control board approves or rejects it, and the plan is updated accordingly.
Close Project or Phase
At the end of the project or a phase, deliverables are formally accepted, financial and procurement activities are closed, lessons learned are documented, and the project is archived.
A real IT professional — a project manager working for a mid-sized e-commerce company — uses Project Integration Management every day. Here is a concrete scenario.
Scenario: The company is building a new mobile app for their customers. The project has been running for three months. The project manager has a project management plan that includes a schedule, a budget of £150,000, and a list of features.
Step 1: Starting the project. Before any work began, the project manager received a project charter from the company’s chief technology officer (the sponsor). The charter authorised the project, gave the manager authority to form a team, and stated the high-level goal: launch a working iOS and Android app within six months, with a budget of £150,000. Without that charter, the project manager would have had no official right to hire developers or buy cloud services.
Step 2: Planning. The project manager created the project management plan, integrating input from the development lead, the marketing team, and the finance department. They wrote a scope statement defining exactly what features would be in version 1.0, a schedule showing milestones, and a risk register listing potential problems like third-party API failures or staff turnover.
Step 3: Execution and day-to-day integration. During week 4, the development team realised they needed a different database than the one planned because the existing one would not handle the expected customer traffic. Instead of simply buying a new database, the developer submitted a change request. The project manager evaluated the request: changing the database would cost an extra £8,000 and add two weeks to the schedule. They presented this to the change control board (the CTO and the finance director). The board approved the change, and the project manager updated the project management plan and communicated the new timeline to all stakeholders.
Step 4: Monitoring. Every week, the project manager runs a report comparing actual costs and tasks completed against the plan. In week 8, they see that the team is two weeks behind schedule because the database change took longer than expected. They take corrective action: they add one more developer for a week and reduce the scope of one low-priority feature. Both decisions are documented and approved through the change control process.
Step 5: Closing. After the app launches in month 7 (one month late), the project manager holds a lessons learned session. The team notes the database risk should have been flagged earlier. This lesson is stored in the company’s knowledge base for future projects. Contracts with freelancers are closed, final invoices are paid, and the project is officially archived.
Key actions an IT professional performs with Project Integration Management:
Drafting and getting approval for the project charter from the sponsor.
Creating and maintaining the project management plan, updating it whenever a change is approved.
Reviewing every change request, assessing its impact on all aspects of the project, and following the approved change control procedure.
Holding regular status meetings where progress is compared to the plan and decisions are made to correct deviations.
Conducting phase-end or project-end reviews to capture lessons learned and formally close the project.
The most important discipline is refusing to bypass the integration processes. Even a small change — like a team member wanting to use a different code editor — can be accommodated, but it must be noted and agreed upon, because if every small decision is taken informally, the plan becomes useless and the project drifts off course.
The CAPM exam tests Project Integration Management heavily. This topic appears in multiple questions across the exam, and it is one of the areas where beginners lose marks because they confuse it with other knowledge areas. Here is exactly what to expect.
Exam topics that appear most frequently:
Project charter contents: The exam loves to ask what must be in a project charter. Memorise this list: business case, high-level project description and product description, high-level milestones, high-level risks, high-level budget, project approval requirements, assigned project manager and their authority level, and the name of the sponsor. A common trap is asking if the detailed schedule is in the charter — it is not; the detailed schedule belongs in the project management plan.
When the project charter is created: The charter is developed during the Initiating process group. It is created before the project is formally started. A trick question might ask if the charter is created during planning — the answer is no.
Integrated change control process: You will be given a scenario where someone requests a change. The correct sequence is: 1) The change is documented as a change request. 2) The project manager evaluates its impact on the project (cost, schedule, scope, quality). 3) The change is submitted to the change control board (CCB) for approval or rejection. 4) If approved, the project management plan and other relevant documents are updated. 5) The approved change is communicated to all stakeholders. A common trap is choosing “the project manager approves the change on their own” — that is wrong unless the project manager has that authority in the charter, but the exam tests the formal process.
Role of the change control board: The CCB typically includes the sponsor, key stakeholders, and sometimes the project manager. They review change requests. The project manager does not make the final approval unless explicitly authorised.
Difference between corrective, preventive, and defect repair actions: Corrective action brings the project back in line with the plan (e.g., adding resources to catch up). Preventive action avoids future deviation (e.g., training a team member to reduce errors). Defect repair fixes a broken deliverable. The exam asks which type of action a specific scenario describes.
Closing process: The exam tests what happens during Close Project or Phase. This includes completing final reports, archiving documents, releasing resources, and getting formal acceptance of deliverables from the customer. A trap is answering “the team keeps working until all bugs are fixed” — closing happens when the deliverables meet the acceptance criteria, not when perfection is reached.
Key definitions to memorise:
Project Charter: A document issued by the sponsor that formally authorises the project and gives the project manager authority.
Project Management Plan: The master document that integrates all subsidiary plans. It is not a single document but a set of documents.
Work Performance Data: Raw observations and measurements taken during execution (e.g., actual hours worked).
Work Performance Information: Performance data analysed against the plan (e.g., hours worked vs. hours planned).
Work Performance Reports: Reports sent to stakeholders (e.g., status updates, dashboards).
Change Request: A formal proposal to modify any document, deliverable, or baseline.
The trap patterns to watch for:
Questions that ask “what is the FIRST thing the project manager does?” when a change is requested. The answer is almost always “evaluate the impact of the change” — not “approve it” or “reject it” immediately.
Questions that present a change that seems trivial. The exam wants you to apply the same formal process — no shortcuts.
Questions that confuse the project charter with a contract. The charter is not a contract; it is an internal authorisation. Contracts are external legal agreements.
Questions that ask about the project management plan and give an option that is a subsidiary plan (like the scope management plan) as if it were the whole plan. The project management plan includes all subsidiary plans, but each is a separate piece.
Questions that ask about “closing” and offer “deliverables are handed over” — that is part of closing, but closing also includes financial closure, procurement closure, lessons learned, and archiving. They often list just one action and expect you to know the full picture.
Project Integration Management coordinates all other knowledge areas; it is the single discipline that ensures every part of a project works together toward the same goal.
The project charter is the formal authorisation to start the project; without it, the project manager has no official authority to use resources or make decisions.
Integrated change control requires every change request to be evaluated for its impact on the entire project before being approved or rejected by the change control board.
The project management plan integrates all subsidiary plans into one coherent guide for executing, monitoring, and closing the project.
Corrective action brings the project back into alignment with the plan, while preventive action stops a deviation from happening, and defect repair fixes a broken deliverable.
Closing a project or phase includes getting formal acceptance, archiving documents, releasing resources, and capturing lessons learned — not just handing over deliverables.
These come up on the exam all the time. Here's how to tell them apart.
Project Charter
Created during Initiating process group
High-level and concise; authorised by sponsor
Grants authority to the project manager
Contains business case, high-level risks, milestones, budget
Project Management Plan
Created during Planning process group
Detailed and comprehensive; created by project manager and team
Describes how the project will be executed, monitored, and closed
Includes subsidiary plans for scope, schedule, cost, quality, etc.
Corrective Action
Addresses a variance that has already occurred
Brings the project back into alignment with the plan
Example: adding resources to catch up a delayed task
Preventive Action
Addresses a potential future variance
Reduces the probability of a deviation from the plan
Example: training a team member to avoid future errors
Work Performance Data
Raw, unprocessed observations from execution
Examples: actual hours worked, actual costs incurred
Collected during Direct and Manage Project Work
Work Performance Information
Processed data analysed against the plan
Examples: schedule variance, cost performance index
Produced during Monitor and Control Project Work
Mistake
The project charter and the project management plan are the same thing.
Correct
The project charter is a high-level document created during initiation that authorises the project. The project management plan is a detailed set of documents created during planning that describes how the project will be executed, monitored, and closed.
Beginners hear 'plan' and 'charter' and assume both refer to the same planning document. The names sound similar, and both are created early, so it is an easy mix-up.
Mistake
Integrated change control means the project manager can approve any change they think is good for the project.
Correct
Integrated change control is a formal process where changes are evaluated for impact on the whole project, and typically approved or rejected by a change control board (CCB) — not just the project manager — unless the project charter explicitly gives the manager that authority.
People assume the project manager, being in charge, has the power to make all decisions. In reality, change control is a governance process designed to protect the project from uncontrolled changes, so authority is distributed.
Mistake
Project Integration Management is only about combining different software or tools.
Correct
Project Integration Management is about coordinating all project management processes across all knowledge areas — scope, schedule, cost, quality, etc. It is not about technical integration of software systems.
The word 'integration' in IT often refers to connecting software systems (e.g., an API integration). Beginners mistakenly carry that meaning over to project management, where integration means unifying processes, not systems.
Mistake
Once the project management plan is approved, it should never change.
Correct
The project management plan is a living document. It is updated whenever a change is approved through the integrated change control process. The plan is baselined at the start, but changes are formally managed and reflected in updates.
Many beginners think a plan is fixed, like a blueprint. In reality, projects are dynamic, and the plan must evolve with approved changes. The discipline is in controlling changes, not preventing them.
Mistake
The project charter is only needed for large projects; small projects can skip it.
Correct
Every project should have a project charter, regardless of size. It provides formal authorisation and sets the high-level direction. Even a small internal project benefits from a charter to avoid confusion about goals and authority.
Beginners think formal documents are only for big, complex projects. They underestimate how easily misalignment can occur, even in small teams, without an explicit authorisation document.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes. Even a small project benefits from a charter because it clarifies the project's purpose, authorises the project manager to use resources, and prevents confusion about who is responsible for what.
A change request proposes a modification to the project scope, schedule, cost, or any baseline. A defect repair specifically fixes a deliverable that does not meet its requirements. Both go through integrated change control.
Only if the project charter specifically gives the project manager that authority. In most organisations, changes are reviewed and approved by a change control board to ensure the whole project is considered.
No. It is a collection of documents, including the scope management plan, schedule management plan, cost management plan, and others, all integrated into one coherent set.
Skipping closing means resources may not be formally released, contracts might remain open, lessons learned are lost, and the organisation does not get final acceptance from the customer, which can lead to legal or financial issues later.
Scope management focuses only on defining and controlling what is in the project. Integration management coordinates scope with schedule, cost, quality, risk, and all other areas to ensure decisions in one area do not harm another.
You've finished Project Integration Management. Continue through the CAPM study guide to build a complete picture of the exam.
Done with this chapter?