What results from the integrated change control process is often reduced in casual conversation to a simple approval or rejection. That shorthand misses the real outputs. The process is not just a decision gate. It is a formal mechanism that records what was requested, what was decided, how baseline documents changed, and what now must be executed. In the PMBOK framework, Perform Integrated Change Control sits inside the Monitoring and Controlling Process Group and the Integration Management Knowledge Area. It acts as the central nervous system for managing changes to project scope, schedule, cost, and other baselines. The results are specific, structured, and consequential for the remainder of the project.
The formal outputs include change requests status updates, project management plan updates, and project document updates. Each output has a different function. Status updates communicate the decision. Plan updates authorize the revised direction. Document updates preserve the record. When a change request is deemed feasible but outside the project scope, its approval requires a baseline change. If the change request is not deemed feasible, it will be rejected and possibly sent back to the requester for additional information. Approved changes later flow into the Direct and Manage Project Execution process. That handoff depends on all three outputs being accurate and complete.
Project managers who treat integrated change control as a bureaucratic formality often miss the protective role these outputs play. They protect the integrity of baselines and the historical data of past performance. They also provide the trail that explains why the project plan looks different in month six than it did in month one. Without that trail, stakeholders cannot distinguish between planned work and unauthorized scope creep. The outputs therefore act as both authorization and evidence.
Integrated Change Control Process: Key Results Summary
| Key Concept | Summary |
|---|---|
| Integrated Change Control | Perform Integrated Change Control belongs to the Monitoring and Controlling Process Group and the Integration Management Knowledge Area in the PMBOK Guide, where it governs how change requests are formally evaluated, approved, and tracked. |
| Central Role | It functions as the central decision point for maintaining control over project scope, schedule, cost, quality, and other baselines, ensuring that all changes align with project objectives and approved tolerances. |
| Common Mistake | Project managers who treat integrated change control as a bureaucratic formality often overlook its protective outputs, which preserve baseline integrity, document accountability, and prevent unauthorized changes. |
| Status Updates | The first output is the change request status update, which records the disposition of every submitted change, including conditional approvals that require baseline revisions before the change is implemented. |
| Evaluation Criteria | Requesters may need to provide stronger technical evidence, a more compelling business case, or clearer impact analysis; rejections often stem from high technical risk, excessive cost, or timing conflicts with critical deliverables. |
| Change Log | The change log serves as the single authoritative reference for auditors, sponsors, and team members who need to understand what changed, when it changed, and why, supporting traceability and accountability. |
| Timely Updates | Teams that postpone status updates until the end of the month typically discover that team members have already acted on informal approvals, creating undocumented changes and baseline drift. |
| Plan Updates | Subsidiary management plans and baselines subject to the formal change control process may be updated to ensure that approved changes are consistently integrated across the project management plan. |
What Change Request Status Updates Result from the Integrated Change Control Process
One of the first results from the integrated change control process is the set of change request status updates that record how each submitted change was handled. The project manager or an assigned team member processes change requests according to the change control system. That system may include a change control board, delegated authority thresholds, or specialized review workflows. The status update is the formal confirmation of the decision, whether approved, rejected, deferred, or sent back for more information. It is not a side note. It is the primary record that tells the requester and the project team what happens next.
A change request that is deemed feasible but outside the project scope receives a specific status path. The feasibility assessment confirms that the change can technically and practically be done. The scope assessment confirms that the change is not already covered by the approved scope baseline. In that case, approval is not automatic. The approval requires a corresponding baseline change. The status update will reflect that conditional nature, often indicating approval pending baseline revision or approval with an instruction to update the scope baseline. This distinction matters because the team should not start work until the baseline change is formally processed.
When a change request is not deemed feasible, the status update records a rejection. But the process does not always end there. The change request can be sent back to the requester for additional information. That is a meaningful result. It means the rejection is not necessarily final. The requester may need to provide better technical detail, a stronger business case, or clarification about the expected impact. The change request log then shows a status such as rejected or returned for more information. This status keeps the request visible instead of letting it disappear into an email thread.
Approved Changes Outside the Original Scope in the Integrated Change Control Process
Approved changes outside the original scope create one of the more important status outcomes. The integrated change control process does not forbid scope changes. It forces them to be recognized. A stakeholder may ask for an additional reporting feature in a software project after the scope baseline was approved. If that feature is technically possible but not part of the original scope, the change request can be approved. But the approval itself triggers a requirement to update the scope baseline. The status update will record the approval and reference the baseline change.
This is where many project teams stumble. They treat the verbal approval as the license to proceed. In a formal change control system, the approval is not complete until the baseline change request is logged and authorized. The status update provides that linkage. It tells the project manager that the approved change is now outside the original scope and that the plan must be adjusted. Without that linkage, the project scope baseline becomes a fiction. It no longer reflects the work the team is actually doing.
The phrase "outside the project scope" can also create confusion. Some practitioners assume it means the change is rejected because it is not in scope. That is incorrect. Outside the project scope simply means it is not part of the current approved scope baseline. It can still be approved if it is feasible and adds value. The integrated change control process exists precisely to handle such situations. The output is a status update that says approved with baseline change, not a simple yes.
Rejected Change Requests and Requests Sent Back for More Information
Rejected change requests are a normal and healthy output of integrated change control. Not every idea should be funded or scheduled. A change may be rejected because the technical risk is too high, the cost is too great, or the timing conflicts with critical deliverables. The status update records that rejection in the change request log. That record prevents the same request from being resubmitted months later without recognition. It also gives the requester a formal answer rather than an informal silence.
However, a rejection does not always close the matter. The source material notes that a nonfeasible change request may be sent back to the requester for additional information. This is a distinct status from a flat rejection. It signals that the change control authority could not evaluate the request properly because something was missing. Maybe the impact on quality was unclear. Maybe the resource estimate was absent. Maybe the risk assessment was incomplete. The requester gets an opportunity to strengthen the request and resubmit it through the same formal channel.
Project managers should treat this "sent back" status carefully. It is not the same as deferring the change. A deferred change has been evaluated but postponed. A request sent back for more information has not yet been fully evaluated. The change request log should capture that difference. If the log only has approved, rejected, and open as statuses, it will blur an important distinction. The status update output is most valuable when it reflects the actual state of the request with enough granularity.
The Change Request Log as the Central Status Record
The change request log is the natural home for change request status updates. Every change request, whether approved, rejected, or returned, gets its status recorded there. This log is updated as part of the project document updates, but the status itself is the result of the integrated change control decision. The log provides a single point of reference for auditors, sponsors, and team members who need to know what changed and why. It also shows the chronology of decisions.
In practice, the change request log often becomes the most consulted document after a project encounters trouble. A stakeholder may ask why a particular feature was added. The log shows the request, the feasibility assessment, the decision, and the date. The status update is the backbone of that record. If the status is not updated promptly, the log loses its reliability. Teams that wait until the end of the month to update change statuses usually find that people have already acted on informal approvals.
The status update also has a downstream consequence. The source says approved change requests will be implemented by the Direct and Manage Project Execution process. That implementation can only happen correctly when the status is clear. A team member seeing an approved status knows the change is authorized. A team member seeing a rejected or returned status knows not to proceed. The change request log therefore functions as a control mechanism, not just a historical archive.
Key Takeaways on Change Request Status Updates
- Formal Record of Change Decisions
- Each status update creates an auditable record of the disposition of every submitted change request, clarifying whether it was approved, rejected, deferred, or returned for further information.
- Processing Through the Change Control System
- Change requests are routed through the defined change control system by the project manager or a designated team member, relying on a change control board, delegated authority thresholds, or specialized review workflows as appropriate.
- Conditional Status for Out-of-Scope Changes
- A feasible request that falls outside the current project scope receives a conditional status, indicating approval pending a baseline revision or approval that requires an update to the scope baseline.
- Work Waits for Baseline Processing
- Work should not begin on a conditionally approved change until the baseline update has been formally processed, and the requester may need to supply stronger technical detail, a clearer business case, or a more precise statement of expected impact.
Project Management Plan Updates and Baseline Changes
The second major output from integrated change control is the set of project management plan updates that formalize the approved direction. Approved change requests often require revisions to the project management plan and its subsidiary components. The source material specifies that elements of the project management plan that may be updated include subsidiary management plans and baselines subject to the formal change control process. These updates are not optional housekeeping. They are the mechanism through which approved changes become part of the project's official plan.
When a change request is approved and affects the scope, the scope baseline changes. If it affects the schedule, the schedule baseline changes. If it affects the budget, the cost baseline changes. Each of those baselines is a controlled element. The project management plan updates reflect those new baselines. The old baseline is not erased. It is superseded. The new baseline governs from the point of approval forward. That is the core principle of baseline integrity.
The updates also extend to subsidiary management plans. A change in procurement strategy might update the procurement management plan. A change in quality requirements might update the quality management plan. A change in communication frequency might update the communications management plan. The integrated change control process does not limit itself to the triple constraint. It considers any subsidiary plan that is subject to formal change control. The output is a coordinated update, not a patchwork of isolated edits.
Updating Subsidiary Management Plans Through Integrated Change Control
Subsidiary management plans are the detailed guides for how different knowledge areas will be managed. When a change request is approved, one or more of these plans may need to be updated. Suppose a change request adds a new vendor relationship to a construction project. The procurement management plan may need to be updated to reflect the new vendor selection process or contract administration requirements. The change request status is approved, but the project management plan update translates that approval into operational guidance.
The source material explicitly includes subsidiary management plans as candidates for update. That inclusion is important because some project managers think only baselines change. In reality, a change may affect how the project is managed without changing scope, schedule, or cost. A new risk response strategy may update the risk management plan. A shift in stakeholder engagement requirements may update the stakeholder engagement plan. The integrated change control output captures those changes as project management plan updates.
Practitioners often overlook the difference between updating a plan and updating a baseline. A plan describes the approach. A baseline describes the approved reference point. Both can change through integrated change control, but they have different implications. Updating a subsidiary plan may adjust how the team works. Updating a baseline changes what the team is measured against. Both outputs must be documented and communicated, but the baseline change carries more governance weight.
Baselines Subject to Formal Change Control
Baselines are the approved versions of the project's key performance dimensions. The scope baseline, schedule baseline, and cost baseline are the most common. They are subject to the formal change control process. That means they cannot be changed informally. A project manager cannot simply decide to move a milestone or add a deliverable without going through integrated change control. When a change request affects one of these baselines, the output is a formal baseline revision.
The source material is explicit about baselines subject to formal change control. Changes to baselines should only show the changes from the current time forward. Past performance may not be changed. This is a critical protection. If a project is behind schedule, the project manager cannot go back and revise the original schedule baseline to make the variance disappear. The original baseline stays intact. The new baseline starts from the current point forward. This preserves the ability to measure how the project actually performed against the original plan.
This forward-only rule is often misunderstood. Some project teams think a baseline change means rewriting the entire history. That would destroy the data needed for lessons learned, performance reviews, and earned value analysis. Instead, the change creates a new version of the baseline that applies from the approval date onward. Historical data remains unchanged. The project management plan update records the new baseline, but it does not erase the old one. The result is a layered record of how the project's authorized direction evolved.
Why Baseline Changes Only Apply Forward
The restriction that baseline changes only apply from the current time forward protects the integrity of the baselines and the historical data of past performance. If project managers could alter past performance, they could artificially improve the project's performance record. That would make variances impossible to detect. Stakeholders would never know whether the project was truly on track or whether the baseline had been massaged after the fact.
Think of a project that was supposed to complete fifty percent of its scope by the third month but only completed thirty percent. If the project manager were allowed to change the original baseline to say thirty percent was the plan, the schedule variance would vanish. The forward-only rule prevents that. The original baseline remains as the reference for what was planned. The new baseline takes over for future measurement. The old variance remains visible as a historical fact. This is not just an accounting nicety. It is the foundation of trustworthy project reporting.
The same principle applies to cost and scope baselines. Past cost overruns cannot be hidden by adjusting the original cost baseline. Past scope omissions cannot be hidden by deleting prior scope commitments. The integrated change control process enforces that discipline. When a project management plan update is issued, it includes the new baseline and the date from which it applies. It does not rewrite the story of what came before.
Project Document Updates After Integrated Change Control
The third major output from integrated change control is the set of project document updates that keep the supporting records aligned with the formal decisions. The source material identifies the change request log and any documents that are subject to the formal change control process as examples. These updates are distinct from project management plan updates. The project management plan is a controlling document that guides how the project is executed. Project documents are the working records that support that plan. Both change through the same integrated change control process, but they serve different purposes.
The change request log is the most prominent project document update. It records the status of every change request, including approved, rejected, and returned requests. As a project document, the log is not a baseline. It does not require a formal baseline change to update. But it is still subject to the change control system because it documents formal decisions. The update happens as part of the integrated change control process, not as an afterthought.
Other project documents may also be updated. For example, a change to the requirements documentation may result from an approved scope change. A change to the risk register may result from a new risk response. A change to the assumption log may result from new constraints. Each of these documents is subject to the formal change control process when the change affects their content. The output is a coordinated set of document updates that reflects the approved change across the project's records.
Change Request Log and Other Formal Documents
The change request log serves as the primary repository for change request status updates. When a change request is processed, the log entry is updated to reflect the new status. If the change is approved, the log shows approved. If the change is rejected, the log shows rejected. If the change is sent back for more information, the log shows that status. The log also typically includes the date of the decision, the person or group that made the decision, and any reference to the baseline change or plan update.
Beyond the change request log, other project documents may need updates. Suppose an approved change modifies the acceptance criteria for a deliverable. The requirements documentation and the requirements traceability matrix may both require updates. Suppose an approved change adds a new risk to the project. The risk register will need to reflect that risk. The integrated change control process does not only update the plan. It also ensures that the working documents remain consistent with the new direction. Without those document updates, team members would be working from outdated information.
The phrase "subject to the formal change control process" is important. Not every project document is controlled at the same level. Some documents, such as meeting notes or informal logs, may not require formal change control. But documents that define requirements, risks, assumptions, or other controlled elements are subject to the same rigor as baselines. When an approved change affects those documents, the integrated change control output includes their update. The project manager is responsible for identifying which documents need to change and ensuring the updates are made.
Distinguishing Project Documents from the Project Management Plan
A common point of confusion is the difference between project document updates and project management plan updates. The project management plan is the formal, approved plan that says how the project will be executed, monitored, and controlled. It includes subsidiary plans and baselines. Project documents are the lower-level records that feed into the plan or support its execution. The change request log is a project document. The risk register is a project document. The requirements documentation is a project document.
Both types of updates can result from integrated change control. However, they have different approval implications. A project management plan update, especially a baseline change, requires formal approval through the change control system. A project document update may be less formal, but it is still performed as part of the integrated change control process to maintain consistency. The source material separates the two outputs precisely because practitioners need to understand which layer of the project's information is changing.
For example, if an approved scope change adds a new module to a software product, the scope baseline is updated as a project management plan update. The requirements documentation and the work breakdown structure dictionary are updated as project document updates. The scope baseline change cannot be implemented without those document updates. But the scope baseline itself is the controlled plan element. The project document updates support it. This layered view helps project teams avoid the mistake of updating only one layer and leaving the other stale.
Key Takeaways on Project Document Updates
- Project Documents Versus Plan
- Project documents function as the working records that support the project management plan, and even though they serve a distinct purpose from the plan, both are maintained through the same integrated change control process to preserve alignment.
- Change Request Log Centrality
- The change request log stands out as the most important project document update because it serves as the authoritative record of every change request, capturing approved, rejected, and returned requests with equal clarity.
- Details Captured in the Log
- Each entry in the change request log typically captures the decision date, the responsible decision maker or governing body, and any resulting references to baseline revisions or plan updates.
How Approved Changes Flow into Direct and Manage Project Execution
Approved change requests do not sit in a log forever. The source material states that approved change requests are implemented by the Direct and Manage Project Execution process. That handoff is a direct result of integrated change control. Once the status is approved and the relevant baselines and documents are updated, the execution process can incorporate the change into the ongoing work. The handoff is not automatic. It requires the outputs of integrated change control to be complete and communicated.
Direct and Manage Project Execution is the process where the work defined in the project management plan is performed. Approved changes become part of that work. The execution team receives the updated plan and the updated project documents. They then perform the new activities, produce the new deliverables, or adjust their approach according to the revised direction. Without the integrated change control outputs, the execution team would be working from an outdated plan. That leads to unauthorized work and rework.
The flow from integrated change control to execution also creates a feedback loop. As the execution team implements the approved change, they generate work performance data. That data is later fed into the Monitoring and Controlling processes, including another round of integrated change control if new issues arise. The cycle continues. Each iteration produces new change request status updates, new plan updates, and new document updates. The process is not a one-time event. It is a recurring rhythm throughout the project life cycle.
From Approval to Work Authorization
Approval is not the same as work authorization. In a disciplined project environment, a change request may be approved by the change control board, but the execution team still needs authorization to begin the work. The project management plan update and the change request status update together provide that authorization. The status update tells the team the change is approved. The plan update tells the team what the new baselines are. The document updates tell the team what specific requirements or risks have changed.
The source material connects approved change requests directly to the Direct and Manage Project Execution process. This implies that the execution process relies on the outputs of integrated change control to know what to do. A project manager who approves a change but fails to update the plan has not actually authorized anything. The team may still be confused about whether the old plan or the new plan governs. That confusion leads to delays and mistakes.
In practice, the work authorization may come through a work package assignment, a task order, or an updated sprint backlog in an agile environment. The exact mechanism varies. But the principle remains the same: the approved change request becomes executable only when the integrated change control outputs are complete. The status update, plan update, and document update together form the authorization package. Project managers should treat that package as the formal green light for execution.
The Role of Work Performance Data After Implementation
Once the execution team implements an approved change, the project begins producing work performance data about that change. That data shows whether the change is producing the expected result. It may show that the new feature is working as intended or that the revised schedule is holding. It may also show new variances, new risks, or new issues. That data flows back into the monitoring and controlling processes. If the change did not produce the desired effect, another change request may be raised.
This connection highlights why integrated change control outputs must preserve historical data. When a baseline change is made, the forward-only rule ensures that past performance remains intact. That allows the project manager to compare the new baseline performance against the original baseline. It also allows the team to evaluate whether the approved change actually improved the project or simply shifted the goalposts. If past performance had been altered, that comparison would be meaningless.
The implementation of approved changes also updates the project's records. The execution process produces new deliverables, new work results, and new data. Some of that data may feed back into project document updates. For example, a new risk identified during implementation may update the risk register. The integrated change control process may then be invoked again to address that risk. The result is a continuous cycle of plan, execute, monitor, and change. Each cycle produces its own set of integrated change control outputs.
Common Misunderstandings About Integrated Change Control Outputs
Several misunderstandings surround what results from the integrated change control process. One of the most persistent is the belief that every output is a decision. In reality, the integrated change control outputs include status updates, plan updates, and document updates. The decision is important, but it is only one part of the result. The documentation of the decision and the revision of the plan are equally important. Teams that focus only on the decision often fail to complete the other outputs.
Another misunderstanding is that integrated change control is only for large scope changes. In practice, the process applies to any change that affects baselines or controlled documents. A small adjustment to a milestone may require a baseline change. A minor update to a quality standard may require a change request. The threshold for formal change control depends on the project's change management plan, but the principle remains the same. Even small changes produce the same three categories of outputs: status, plan, and document.
Some practitioners also assume that rejected change requests produce no outputs. That is false. A rejected change request still receives a status update in the change request log. It may also be sent back for additional information, which creates a new status. The rejection becomes part of the project's historical record. That record is valuable for future decisions. It shows what was considered and why it was not approved. Ignoring that output makes it harder to explain past decisions to stakeholders.
Believing Every Change Request Updates the Baseline
Not every approved change request updates a baseline. Some changes are feasible and within the existing project scope. In that case, the change may not require a scope, schedule, or cost baseline change. It may simply require an update to a subsidiary plan or a project document. For example, a change in the risk response strategy may not alter the schedule baseline, but it could update the risk management plan. The integrated change control process still produces outputs, but those outputs may be limited to document updates and status updates.
The source material distinguishes between a change request that is outside the project scope and one that is within it. Only the former requires a baseline change upon approval. The latter may be approved without a baseline change. This distinction is important because some project managers treat every approved change as a baseline revision. That over-applies the baseline change concept and creates unnecessary churn. The output should match the nature of the change. If the change does not affect a baseline, there is no baseline update.
Understanding this distinction helps teams avoid overengineering the change control process. A simple adjustment to the communication plan may not need a full baseline revision. The project manager can update the communications management plan and the relevant project documents, record the status, and move on. The integrated change control outputs are then status update, project management plan update for the subsidiary plan, and project document update. No baseline change is required. That is a leaner but still formal result.
Treating the Change Log as the Only Updated Document
The change request log is the most visible document update, but it is not the only one. An approved change can ripple through many project documents. Requirements documentation, the risk register, the assumption log, the stakeholder register, and the lessons learned register may all need updates. Some of these updates happen immediately as part of integrated change control. Others happen later as the change is implemented. But the integrated change control process should identify which documents are affected.
Treating the change log as the only updated document leads to inconsistency. The log may show an approved change, but the requirements documentation may still reflect the old requirements. The team then works from conflicting sources. A tester may check against outdated acceptance criteria. A developer may code against old requirements. The project document update output is meant to prevent exactly that inconsistency. It aligns the formal records with the approved change.
Project managers should perform a document impact assessment as part of processing each change request. That assessment identifies which project documents need to be updated. The source material does not require a specific template for this assessment, but the logic is straightforward. If the change affects scope, the requirements documentation and the work breakdown structure dictionary likely change. If it affects cost, the cost estimates and the cost baseline may change. If it affects risk, the risk register changes. The integrated change control output includes those updates.
Overlooking Past Performance Protection
The rule that baseline changes only apply forward is easy to state but easy to overlook in practice. When a project is struggling, there is strong pressure to revise the baseline retrospectively. A project manager might be tempted to adjust the original schedule baseline to show that the project was actually on track. The integrated change control process explicitly forbids that. Past performance may not be changed. The baseline change applies only from the current time forward.
This protection is not just about honesty. It is about the usefulness of performance data. If past baselines could be altered, the project would lose the ability to measure variance. Earned value calculations would become meaningless because the planned value would shift after the fact. Historical comparisons would lose their value. The forward-only rule preserves the integrity of the baselines and the historical data of past performance, exactly as the source material states.
Project managers can reinforce this rule by maintaining version control on baselines. Each baseline change should be documented with the date it takes effect and the reason for the change. The previous baseline remains in the project archives. That way, anyone can see the original plan, the revised plan, and the variance between them. The integrated change control outputs then become a story of how the project evolved, not a sanitized version of what happened.
Key Clarifications on Change Control Outputs
- Three Output Categories Always Apply
- Every change that passes through integrated change control generates documented updates to project status, project plans, and project documents, even when the change itself appears minor.
- Documentation Equals Plan Revision
- A change is not fully processed until the decision and its rationale are documented, making that record as essential as the revision of the affected plan.
- Not Limited to Large Changes
- The process applies to any modification that could affect a baseline or a controlled document, meaning that even minor updates to quality standards or work procedures can trigger a formal change request.
- Thresholds Come From Change Plan
- The change management plan establishes the thresholds and approval routes that activate formal change control, while the underlying requirement to control baseline and document changes remains the same.
Framework Context and Cross-Methodology Views on Change Control Results
In the PMBOK framework, Perform Integrated Change Control is the process that produces these outputs. The formal change control process draws together change requests from all knowledge areas and ensures they are evaluated holistically. A change that looks small in isolation may have broad impacts. The integrated nature of the process means that one change request can trigger updates across multiple baselines and documents. The outputs reflect that integration. The status update captures the decision, the plan update captures the baseline revisions, and the document update captures the record.
PRINCE2 handles change through its change theme and issue management procedure. The results are analogous: issue registers, product description updates, and baseline revisions through configuration management. Agile environments often manage change less formally, using product backlog refinement, sprint planning, and continuous stakeholder feedback. But even in agile, a significant change to the release plan or the definition of done often requires a conscious update to the plan and the team's working agreements. The underlying need for clarity and record-keeping does not disappear.
The business value oriented project management perspective adds another layer. BVOPM introduces the idea of process damage as invisible organizational harm that accumulates when change control is poor or when repeated rejections discourage valuable feedback. It tracks business value points as a monitoring tool. If a persistent decline in those points appears, the project may need to be reconsidered. The integrated change control outputs can be seen as a way to make that damage visible before it becomes fatal. The status updates, plan updates, and document updates create a record that either supports value delivery or reveals where value is being lost.
PMBOK, PRINCE2, and Agile Perspectives on the Results
The PMBOK view is process-centric. The results of integrated change control are defined outputs with specific names and purposes. Change request status updates, project management plan updates, and project document updates form the formal record. The process belongs to the Integrating knowledge area because it coordinates changes from all other areas. This is not a siloed activity. A change to the scope baseline often affects the schedule baseline and the cost baseline. The integrated change control process ensures that all affected baselines are updated in a coordinated way.
PRINCE2 practitioners will recognize a similar outcome through the configuration management records and issue register. When a change is approved, the product descriptions and the stage plan are updated. Past stage performance is not altered. The focus is on controlling the current stage and the remaining work. The language differs, but the forward-only baseline principle appears in practice. Historical records remain intact for governance and audit purposes. The result is a controlled evolution of the project direction.
Agile teams may find the formal outputs heavy, but the intent is the same. A product backlog change is a type of change request. The product owner approves or rejects it. The sprint backlog and the release plan are updated accordingly. The team's Definition of Done may be revised if the change affects quality criteria. The change is not hidden. It is made visible in the backlog and the sprint review records. The integrated change control outputs have their agile equivalents, even if the terms are different. What matters is that the change is decided, documented, and reflected in the plan the team uses to execute.
A BVOPM Observation on Process Damage and Business Value
BVOPM's concept of process damage is particularly relevant to integrated change control. Poor change control can create invisible organizational harm. When change requests are lost, decisions are not recorded, or baselines are updated in secret, the project team experiences friction. They may do work that is later rejected. They may wait for approvals that never come. They may lose confidence in the plan. Each of these issues is a small injury to the project's value delivery capability. The integrated change control outputs help prevent that damage by making decisions explicit and plans current.
The same perspective tracks business value points over time. If change requests are repeatedly rejected without explanation, the team may stop proposing valuable improvements. The project's business value points may decline. The change request log then becomes a diagnostic tool. It shows not just what was approved, but also what was rejected and why. That record can reveal patterns of over-rejection or unclear feasibility criteria. The output of integrated change control is therefore not only about control. It is also about learning whether the project is still open to value-adding change.
Waste in BVOPM includes overwork, perfectionism, and rejected acceptable work. Poorly managed change control can create all three. Overwork occurs when teams implement changes that were never formally approved or that duplicate previous work. Perfectionism occurs when teams over-engineer a change because the requirements were unclear. Rejected acceptable work occurs when a change request is sent back for missing information that was actually available. The integrated change control outputs, when done properly, reduce that waste. They make the decision criteria clear and the documentation complete.
Practical Implications for Project Managers
For a practicing project manager, the results of integrated change control form a checklist. Did the change request receive a status update in the log? Was the project management plan updated, including any affected subsidiary plans and baselines? Were the project documents updated to reflect the new direction? If any of those three is missing, the change is not fully under control. The execution team may be working with incomplete information. The historical record may be incomplete. The baseline may no longer reflect reality.
Project managers should also protect the forward-only rule. It is one of the few hard boundaries in change control. When someone suggests adjusting a past baseline to make the project look better, the project manager should refuse. The integrity of the baselines and the historical data of past performance depends on that refusal. The alternative may feel easier in the short term, but it destroys the evidence needed for honest performance measurement.
Finally, the outputs of integrated change control are not the end of the process. They are the bridge to execution. Approved changes go to Direct and Manage Project Execution. Rejected changes may go back to the requester. Deferred changes wait for a future trigger. Each path produces a different status and a different set of downstream actions. The project manager's job is to make sure the outputs are complete, accurate, and communicated. When that happens, the integrated change control process does exactly what it is supposed to do: keep the project changing in a controlled, visible, and value-aware way.
