# Project Integration Management

> Chapter 5 of the Courseiva PMI-CAPM curriculum — https://courseiva.com/learn/pmi-capm/integration-management

**Official objective:** 1.5 — Explain project integration management including project charter and change control.

## Introduction

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.

## The House Renovation Analogy

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.

## Core explanation

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.

## Real-world context

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.

## Exam focus

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.

## Step by step

1. **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.
2. **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.
3. **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.
4. **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.
5. **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.
6. **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.

## Comparisons

### Project Charter vs Project Management Plan

**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 vs Preventive Action

**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 vs Work Performance Information

**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

## Diagram

_This flowchart shows how Project Integration Management processes flow from the charter through planning, execution, monitoring and control, change management, and closure._

```mermaid
flowchart TD
  A[Project Charter] --> B[Project Management Plan]
  B --> C[Direct and Manage Work]
  C --> D[Work Performance Data]
  D --> E[Monitor and Control Work]
  E --> F{Change Request?}
  F -- Yes --> G[Integrated Change Control]
  G --> H[CCB Approves?]
  H -- Yes --> I[Update Plan and Baselines]
  H -- No --> J[Reject Change]
  I --> C
  J --> C
  E --> K[Close Project or Phase]
```

## Common misconceptions

- **Misconception:** The project charter and the project management plan are the same thing. **Reality:** 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.)
- **Misconception:** Integrated change control means the project manager can approve any change they think is good for the project. **Reality:** 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.)
- **Misconception:** Project Integration Management is only about combining different software or tools. **Reality:** 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.)
- **Misconception:** Once the project management plan is approved, it should never change. **Reality:** 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.)
- **Misconception:** The project charter is only needed for large projects; small projects can skip it. **Reality:** 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.)

## Key takeaways

- 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.

## FAQ

**Do I really need a project charter for a small internal project?**

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.

**What is the difference between a change request and a defect repair?**

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.

**Can the project manager approve changes on their own?**

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.

**Is the project management plan a single document?**

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.

**What happens if we skip the closing process?**

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.

**How is Project Integration Management different from just managing scope?**

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.

## Check your understanding

1. **What is the primary purpose of the project charter?**

   Answer: The project charter formally authorises the project and gives the project manager the authority to use organisational resources to carry out project work.

2. **Who typically approves change requests in a formal integrated change control process?**

   Answer: The change control board (CCB), which includes stakeholders like the sponsor and key decision-makers, approves or rejects change requests.

3. **What is the difference between corrective action and defect repair?**

   Answer: Corrective action brings the project back in line with the plan when there is a deviation, while defect repair fixes a specific deliverable that does not meet its requirements.

4. **In which process group is the project management plan developed?**

   Answer: The project management plan is developed during the Planning process group.

5. **What is the final step performed during Close Project or Phase?**

   Answer: The final step is archiving the project information, getting formal acceptance of deliverables, releasing resources, and documenting lessons learned.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/pmi-capm/integration-management