What is project integration management and what does it include?

Project integration management is a knowledge area that determines how all the moving parts of a project fit together. When someone asks what is project integration management and what does it include, the short answer is that it includes the processes and activities needed to identify, define, combine, unify, and coordinate the various processes and project management activities within the Project Management Process Groups. But that short answer hides a much larger set of responsibilities. Project integration management is not a single task or a phase. It is the continuous act of making a project coherent.

In the project management context, integration includes characteristics of unification, consolidation, articulation, and integrative actions. These characteristics are crucial to project completion, successfully managing stakeholder expectations, and meeting requirements. The project manager carries much of this responsibility, but the entire project team participates. The integration effort involves making choices about resource allocation, making trade-offs among competing objectives and alternatives, and managing the interdependencies among the project management Knowledge Areas.

Project integration management also includes the activities needed to manage project documents to ensure consistency with the project management plan and product deliverables. That document management role is easy to overlook, but inconsistent documents create confusion during execution and closing. Integration keeps the project’s formal record aligned with what is actually being delivered. Experienced practitioners know there is no single way to manage a project, so integration management becomes the discipline of applying the right amount of coordination at the right time.

Project Integration Management: Key Topics at a Glance

What Does Project Integration Management Include in the PMBOK Framework?

At its core, project integration management includes the activities required to identify, define, combine, unify, and coordinate the various processes and project management activities within the Project Management Process Groups. This wording comes directly from standard project management guidance and points to something often missed: integration is not about doing more tasks. It is about making sure the tasks already planned in scope, schedule, cost, quality, resources, communications, risk, procurement, and stakeholder management work together as one system.

The six Project Integration Management processes are Develop Project Charter, Develop Project Management Plan, Direct and Manage Project Execution, Monitor and Control Project Work, Perform Integrated Change Control, and Close Project or Phase. Each process belongs to a different process group, from initiating through planning, executing, monitoring and controlling, and closing. That distribution is meaningful. Unlike a knowledge area such as Schedule Management that concentrates heavily in planning, integration management runs across the entire project life cycle.

Because integration management spans all process groups, it forces the project manager to think horizontally. A schedule change can affect cost, risk, quality, and stakeholder expectations at the same time. Integration management is the discipline of recognizing those connections before they become problems. For example, if a supplier delivers late, the project manager may adjust the schedule, accept additional cost, reduce scope elsewhere, or absorb more risk. That decision involves trade-offs, and integration management frames how those trade-offs are made.

This knowledge area also sits at the intersection of planning and doing. Many project failures are not caused by a single wrong estimate, but by a failure to connect planning artifacts to actual work. Integration management closes that gap. In PMBOK terms, it coordinates the project management processes, but in daily practice it means asking a simple question: if this changes, what else changes?

What Project Integration Management Includes in the Six Core Processes

The six processes are not isolated steps that happen once. Develop Project Charter formally authorizes a project or a phase and documents initial requirements that satisfy the stakeholder’s needs and expectations. Develop Project Management Plan documents the actions necessary to define, prepare, integrate, and coordinate all subsidiary plans. Direct and Manage Project Execution performs the work defined in the project management plan to achieve the project’s objectives. Monitor and Control Project Work tracks, reviews, and regulates progress to meet performance objectives. Perform Integrated Change Control reviews all change requests, approves changes, and manages changes to deliverables, organizational process assets, project documents, and the project management plan. Close Project or Phase finalizes all activities across all Project Management Process Groups to formally complete the project or phase.

Each of these processes creates an integration point. The charter links high-level expectations to authority. The plan links subsidiary baselines to a single performance measurement baseline. Execution links the plan to actual deliverables. Monitoring links progress to corrective action. Change control links requests to approved modifications. Closing links final results to organizational learning.

What often confuses new project managers is that integration is not a process they perform once a month. It is embedded in every decision. When a risk response changes the schedule, the project manager is integrating. When a stakeholder request alters scope, the project manager is integrating. The formal processes simply make that thinking visible and auditable.

Develop Project Charter as the First Integration Process

Develop Project Charter is the process of developing a document that formally authorizes a project or a phase and documents initial requirements that satisfy the stakeholder’s needs and expectations. This might sound bureaucratic, but the charter has a real integrating purpose. It gives the project manager the authority to apply organizational resources to project activities, and it aligns early stakeholder expectations before detailed planning begins.

Many project managers underestimate how much integration happens at charter stage. The charter does not simply list the project name and sponsor. It brings together high-level scope, initial budget, schedule constraints, assumptions, risks, and key stakeholders. Without that early integration, the team can start planning in different directions. The charter creates a common starting point.

From a value-oriented perspective, formal stakeholder input validation before authorization helps reduce later rework. Business Value-Oriented Project Management, or BVOPM, suggests using a Transparent Board of Project Issues where all roles can raise concerns before the project is formally approved. This kind of early integration prevents hidden conflicts from surfacing later when they are more expensive to address.

What Project Integration Management Includes When Authorizing a Project

When authorizing a project, the integration manager, often the project manager working with the sponsor, must analyze and understand the scope. This includes the project and product requirements, criteria, assumptions, constraints, and other influences related to the project. It also includes determining how each of those influences will be managed or addressed within the project. A charter that skips this analysis may authorize a project that looks clear on paper but contains unresolved contradictions among stakeholders.

The charter process also includes documenting initial requirements that satisfy the stakeholder’s needs and expectations. Needs are often broader than wants, and expectations can differ sharply from both. Integration at this stage means surfacing those differences and making sure the project’s purpose is not built on a single stakeholder’s assumption. The project manager may need to facilitate conversations between sponsors, users, and operational managers before the charter is approved.

In PRINCE2 environments, the closest equivalent to this early integration appears in the starting up and initiating a project processes. While the terminology differs, the underlying need is the same: a formal authorization point that establishes a shared view of the project’s purpose, constraints, and decision-making authority.

Building the Project Management Plan Through Integration

Develop Project Management Plan is the process of documenting the actions necessary to define, prepare, integrate, and coordinate all subsidiary plans. This is where integration management becomes highly visible. The project management plan is not one document. It is a collection of subsidiary plans for scope, schedule, cost, quality, resources, communications, risk, procurement, and stakeholder engagement, all held together by an integrated baseline and a change management approach.

A common mistake is treating the project management plan as a static binder of templates. In practice, a well-integrated plan is a dynamic reference that shows how changes in one area ripple into others. For example, if the risk management plan identifies a high probability of supply chain disruption, the schedule and cost baselines should reflect that risk. The integration happens by linking those plans through common assumptions, constraints, and performance measurement baselines.

Project managers often spend too much time formatting the plan and too little time reconciling its contradictions. The real work of integration is not producing the document; it is resolving the trade-offs that the document exposes. If the scope baseline requires more work than the schedule baseline allows, no template will fix that. The project manager must go back to stakeholders, adjust the scope, extend the schedule, or accept a higher risk threshold.

What Project Integration Management Includes in Coordinating Subsidiary Plans

Coordinating subsidiary plans requires more than combining documents. The project management team must understand how to take identified information and transform it into a project management plan using a structured approach. That approach includes reconciling conflicting subsidiary plan elements. Scope may call for a deliverable that requires a longer schedule than the sponsor expects. Cost may need to increase if quality thresholds are high. Resource availability may limit how fast work can proceed. Integration means resolving these conflicts formally instead of letting them surface later as surprises.

Practitioners often note that the plan’s value lies in the conversations it forces, not the pages it produces. A schedule that does not reflect risk responses will fail during execution. A cost plan that ignores quality requirements may look optimal but will produce more rework. The integrated project management plan aligns these elements so the team can execute with a shared understanding.

In Agile environments, planning is often less predictive, but integration still occurs. The product backlog, release plan, and team working agreements must remain mutually consistent. Iteration reviews and retrospectives create frequent integration checkpoints. The formality is lower, but the underlying need to connect scope, schedule, cost, and quality does not disappear.

Directing and Managing Project Execution as Integrated Work

Direct and Manage Project Execution is the process of performing the work defined in the project management plan to achieve the project’s objectives. Execution is where the integration plan meets reality. The project manager and team perform activities to produce project deliverables, but they also manage technical and organizational interfaces that the plan may not have fully anticipated.

During execution, integration management includes coordinating people, resources, and work streams. The project manager may need to balance the need to follow the plan with the need to adapt when actual conditions differ. For example, if a key team member becomes unavailable, the project manager may reassign work, adjust the schedule, or bring in external help. Each choice affects cost, quality, and risk. Integration management provides the framework for making those choices with awareness of the whole project, not just one knowledge area.

Execution also produces information that feeds back into planning. As work progresses, the team learns more about the product, the stakeholders, and the environment. Integration means capturing that learning and using it to refine the plan. A project that executes without updating its assumptions is not really integrated; it is simply following a script that becomes less accurate every week.

What Project Integration Management Includes During Project Execution

Execution is not just about producing deliverables. It also includes implementing approved changes, corrective actions, preventive actions, and defect repairs. Many of these activities cut across knowledge areas. A change to a product requirement may affect scope, schedule, cost, and quality simultaneously. The project manager must ensure

Cross-functional collaboration is especially important here. BVOPM, for example, treats cross-functional teams as a core success factor. When execution requires input from design, development, operations, and compliance, integration management ensures those functions do not work in silos. The project manager acts as the integrator, translating between different perspectives and resolving conflicts before they stall progress.

In Agile execution, integration often happens through the daily standup, backlog refinement, and iteration planning. The product owner, development team, and stakeholders continuously align the work with changing needs. The integration process is less about formal documentation and more about frequent, transparent communication. Still, the absence of heavy documentation does not mean integration is absent. It simply moves into the team’s daily rhythm.

Monitoring, Controlling, and Integrated Change Control

Monitor and Control Project Work and Perform Integrated Change Control work together. The first process tracks, reviews, and regulates progress to meet performance objectives. The second process is responsible for reviewing all change requests, approving changes, and managing changes to the deliverables, organizational process assets, project documents, and the project management plan. These two processes are where integration management prevents small local adjustments from creating large systemic problems.

Monitoring and controlling is not simply checking status against the plan. It includes measuring and monitoring all aspects of the project’s progress and taking appropriate action to meet project objectives. When a variance appears, the project manager must determine whether to correct the work, adjust the plan, or request a formal change. That decision requires integrated analysis. A cost overrun might be caused by a scope gap, a schedule compression, or a quality issue. Treating the symptom without understanding the integration point will usually lead to repeated problems.

Change control is often seen as a gatekeeping function. The real purpose is to evaluate changes from the perspective of the entire project, not just the requesting party. A change that benefits one stakeholder may harm another or introduce new risks. The change control process reviews all change requests, approves or rejects them, and manages their implementation across all affected baselines and documents. This ensures that the project management plan, project documents, and deliverables remain consistent.

What Project Integration Management Includes in Integrated Change Control

Integrated change control requires discipline. Every change request must be evaluated against the project baseline, not just its immediate effect. If a stakeholder asks for an additional feature, the project manager must consider the impact on schedule, cost, quality, risk, and other scope items. Approving the feature may be the right decision, but only after understanding the full trade-off. That is what makes the control process integrated rather than isolated.

Invisible organizational harm can occur when change control is bypassed or applied inconsistently. BVOPM refers to this kind of subtle damage as process damage, and it can accumulate without obvious signs. When teams regularly make informal scope changes without updating the plan, the baseline loses credibility, stakeholders receive conflicting information, and future decisions become harder to defend. Integrated change control exists to prevent that slow erosion of project coherence.

Practitioners often note that change control is not about saying no. It is about making change visible and deliberate. A project with no change requests may be a project where changes are hidden. A healthy integrated change control process records the decision, updates the plan, and communicates the impact. That transparency protects the project manager and the team from later disputes about what was and was not approved.

Key Takeaways on Monitoring and Change Control

Two Integrated Processes

Monitoring and controlling continuously measures progress against performance objectives and drives corrective action, while integrated change control evaluates, approves, and governs all change requests across project baselines and documents.

Integration Prevents Systemic Problems

Together, these processes enable integration management to intercept localized adjustments and prevent them from cascading into systemic project failures.

Beyond Simple Status Checks

Effective monitoring and controlling extends well beyond plan versus actual comparisons by measuring all dimensions of progress and triggering timely actions that keep project objectives within reach.

Responding to Variances

When variances emerge, the project manager must determine whether to correct the work, revise the plan, or initiate a formal change, because addressing symptoms without understanding the underlying integration point tends to create recurring issues.

Assessing Change Impact

Every proposed change, including added features, must be assessed for its potential effects on schedule, cost, quality, risk, and remaining scope before approval is granted.

Closing the Project or Phase as an Integrative Activity

Close Project or Phase is the process of finalizing all activities across all Project Management Process Groups to formally complete the project or phase. Closing is not just administrative cleanup. It verifies that all work is done, that deliverables are accepted, and that lessons learned are captured. From an integration standpoint, closing ensures that every open thread from every knowledge area is resolved before the project ends.

Project managers sometimes rush through closing because the main deliverables are already delivered. But incomplete closure can leave unresolved contracts, unarchived decisions, or unmeasured benefits. Integration management requires confirming that all project documents are updated, that organizational process assets are transferred, and that stakeholders have formally accepted the results. This prevents future confusion about what was and was not within the project’s scope.

The close phase also includes managing project documents to ensure consistency with the project management plan and product deliverables. Final documentation becomes an organizational process asset. If the documentation is inconsistent, future projects may inherit poor assumptions or incorrect baselines. Integration management at closure protects the organization’s learning loop.

What Project Integration Management Includes When Closing a Project or Phase

Closing includes finalizing all activities across the process groups, and that requires looking backward and forward at the same time. Looking backward means verifying that change requests were implemented, risks were retired or accepted, and procurement contracts were closed. Looking forward means documenting lessons that can improve future projects. The integration manager also considers program-level benefits. Some benefits are not financial. For example, improved employee engagement or reduced future risk may appear after the project closes. BVOPM recognizes these non-financial program benefits as part of the broader value picture.

The final project report, if one is produced, should reflect the integrated history of the project. It should show how the original baseline changed over time, why decisions were made, and what outcomes resulted. A closing report that only includes final metrics misses the integrative story. Stakeholders need to understand not just what was delivered, but how the project navigated trade-offs and uncertainty.

In PRINCE2, the closing a project process shares a similar purpose: confirming that the project has met its objectives, that products are accepted, and that lessons are recorded. The terminology differs, but the integrative responsibility remains. Closure is not a clerical task; it is the final act of pulling the whole project together into a coherent record.

Common Misconceptions and Practical Pitfalls in Integration Management

Most experienced project management practitioners know there is no single way to manage a project. They apply project management knowledge, skills, and required processes in a different order and with varying rigor to achieve the desired project performance. This statement is often repeated but rarely internalized. Integration management is not a rigid template. It is a set of decision-making principles that must be tailored to each project’s environment.

A common misconception is that integration management is only the project manager’s job. The project manager carries primary responsibility, but the project team must address every process to determine the level of implementation for each process for each specific project. When team members do not understand how their work connects to other areas, they may make locally rational decisions that undermine the whole. Integration requires shared ownership.

Another misconception is that more integration documentation equals better integration. Teams can produce enormous integrated plans that no one reads or updates. Integration is not measured by the thickness of the plan. It is measured by whether the project’s decisions consistently reflect a whole-project view. A lean plan that is actually used beats a comprehensive plan that sits on a shelf.

What Project Integration Management Includes When Tailoring Processes

Tailoring integration management means deciding how much formality each process needs. A small internal project may not need a detailed integrated change control board. A highly regulated project may require extensive documentation. The key is to address every process, not skip it. Even if a process is lightweight, the project team should consciously determine its level of implementation. Skipping a process by default is not tailoring; it is neglect.

Another pitfall is treating the integrated project management plan as a one-time artifact. Plans that are not updated during execution become disconnected from reality. Then integration management becomes difficult because decisions are based on stale assumptions. Regular plan reviews, tied to monitoring and change control, keep the integrated plan relevant. The project manager should ask after every significant change whether the plan still represents the project accurately.

A practical way to think about integration management is to compare it to air traffic control. Individual flights have their own plans, but the control tower ensures they do not collide. Project integration management does the same for scope, schedule, cost, quality, resources, risk, and stakeholders. The control tower does not fly the planes, and the project manager does not perform every specialty task. Instead, the project manager coordinates the interactions, resolves conflicts, and keeps the whole system moving toward the same destination.

Integration management also grows more important as projects become more complex. A simple project with one deliverable and a small team may need very little formal integration because the team can see the whole picture easily. A large program with multiple work streams, external vendors, and competing stakeholder priorities cannot rely on informal coordination. The project manager must deliberately create integration points through plans, reviews, change control, and reporting rhythms. Without that deliberate effort, the project fragments into separate efforts that happen to share a name.

At the same time, integration should not become a burden. The goal is not to create more administrative work, but to reduce surprises and rework. When integration works well, stakeholders see fewer unexplained delays, teams experience fewer conflicts, and the project’s trajectory feels coherent even when individual decisions are complex. That coherence is the real deliverable of project integration management.

Key Takeaways on Integration Pitfalls

Integration Is a Shared Responsibility

While the project manager holds primary accountability, the entire team must collectively decide how rigorously each integration process is applied to a given project.

Tailor Formality to Fit the Project

Tailoring integration management involves matching the degree of formality to the project's scale and risk, so a small internal initiative typically does not require a formal integrated change control board.

Local Logic Can Undermine the Whole

When team members fail to see how their work connects to other areas, they can make locally sensible decisions that undermine the project as a whole, so a lean plan that is actively used outperforms a comprehensive plan that remains unused.