Before a project manager can run Perform Integrated Change Control effectively, it helps to understand exactly what you need before starting integrated change control. The process does not begin in a vacuum. It relies on a defined set of inputs that establish the baseline, describe actual performance, capture requests for change, and reflect the environment and organizational rules that shape how those requests are evaluated. Getting these inputs in place first prevents confusion later and reduces the chance that a change decision will be made without the full context.
Integrated Change Control: Key Requirements Summary
| Key Concept | Summary |
|---|---|
| Integrated Change Control | Effective execution of the Perform Integrated Change Control process starts with a complete, validated set of inputs so every change request is assessed against reliable project context. |
| Required Inputs | Change decisions depend on inputs that define the performance baseline, document actual results, capture formal change requests, and reflect organizational policies and environmental factors that govern evaluation. |
| Project Management Plan | The project management plan integrates subsidiary management plans and baselines to define how the project will be executed, monitored, controlled, and formally closed. |
| Baselines | Baselines must remain current because an outdated schedule baseline may cause the change control board to assume the original end date remains valid. |
| Work Performance Data | Raw work performance data must be analyzed and placed in context before they can reliably support a change decision. |
| Work Performance Information | Work performance information converts raw observations into actionable metrics, including a schedule variance of negative five days and a forecast that a milestone will slip by two weeks. |
| Variance Analysis | Reviewing current status reports, variance analyses, and forecasts enables decision makers to distinguish between temporary fluctuations and underlying performance problems that require formal action. |
| Decision Making | Integrated change control is most effective when work performance information is tailored to each decision maker's role, so they see the specific evidence needed to make their part of the change decision. |
What do you need before starting integrated change control: the project management plan
The project management plan is not just a single document; it is a collection of subsidiary plans and baselines that define how the project will be executed, monitored, controlled, and closed. Before starting integrated change control, the project manager must have this plan current and accessible. The project management plan baseline provides the reference point against which all proposed changes are evaluated. Without it, there is no way to determine whether a change request would alter the project's scope, schedule, cost, or approach. In many respects, the project management plan is the contract between the project team and the organization about what the project is supposed to deliver.
The baselines within the plan matter most for change control. Scope baseline includes the scope statement, WBS, and WBS dictionary. Schedule baseline includes the approved start and finish dates. Cost baseline includes the approved budget. When a change request arrives, the change control process compares the request against these baselines to understand the impact. A request that touches only how work is performed, without changing scope, schedule, or cost, is usually treated as a corrective action. A request that changes the baselines themselves triggers a more formal approval path.
Subsidiary plans also play a role. The change management plan, for example, describes how changes will be managed and controlled. It may define the change control board, the approval levels, and the documentation required. Other plans, such as the scope management plan and schedule management plan, set out tolerances and thresholds. These components tell the team when a variance is significant enough to warrant a formal change request. So the project management plan is both the yardstick for measuring change and the rulebook for processing it.
Why the project management plan matters before starting integrated change control
Some practitioners treat the project management plan as a static artifact that gets filed away after planning. That is a mistake. Before integrated change control begins, the plan must reflect the current approved state of the project. If previous changes were approved but not yet incorporated, the plan is out of date and the next change decision will be based on stale information. The project manager should verify that the baselines and subsidiary plans are current. This simple check prevents a cascade of errors later.
A practical scenario makes this clearer. Suppose a construction project has an approved change that adds two weeks to the schedule. If the schedule baseline is not updated before the next change request is reviewed, the change board might believe the original end date still applies. They could reject a request that is actually necessary because the new work has already shifted the critical path. Keeping the plan current is not an administrative nicety; it is a prerequisite for meaningful change control.
Key Takeaways on the Project Management Plan
- A collection of plans and baselines
- Rather than a single document, the project management plan is an integrated set of subsidiary plans and baselines that collectively govern how the project is executed, monitored, controlled, and closed.
- Baselines as the change reference point
- These baselines serve as the formal reference point for assessing every change request, enabling the team to determine its potential impact on scope, schedule, cost, or delivery approach.
- Scope baseline components
- Comprising the scope statement, work breakdown structure, and WBS dictionary, the scope baseline is the standard against which change requests are measured to understand how they affect project scope and related constraints.
- The plan must stay current
- When approved changes are not promptly incorporated, the plan loses currency and subsequent change decisions may be based on outdated information rather than the project's true state.
Work performance information: knowing where the project actually stands
The next input is work performance information. This is the analyzed data about how the project is performing against the plan. Work performance information comes from monitoring and controlling processes that compare actual results to planned results. It includes variance analysis, forecast data, and status on deliverables. Without this information, the change control process would be operating blind. You cannot evaluate whether a change is needed if you do not know how far the project has drifted from its baselines.
It helps to distinguish work performance data from work performance information. Raw data might show that a task started late. Work performance information transforms that data into something useful, such as a schedule variance of negative five days and a forecast that the milestone will slip by two weeks. The distinction matters because integrated change control needs information, not raw observations. Raw data alone does not tell the change board whether the variance is within tolerance or whether corrective action is required.
Work performance information is produced by several processes before integrated change control is invoked. Control Scope, Control Schedule, Control Costs, Control Quality, and others generate performance measurements. These processes may also generate change requests when variances exceed thresholds. So by the time a project manager assembles the inputs for Perform Integrated Change Control, there should already be a clear picture of actual performance. If that picture is missing or incomplete, the change review will be speculative.
In practice, this means the project manager should review the latest status reports, variance analyses, and forecasts before submitting any change request for decision. For example, if a cost variance is negative but the trend shows rapid improvement, the change board might decide that no corrective action is needed. If the project manager fails to include that trend information, the board might approve a costly change that was not necessary. Work performance information gives decision makers the context they need to separate a temporary blip from a real problem.
One common error is treating work performance information as a single dashboard that everyone understands. In reality, different stakeholders need different slices of the same information. The change control board may need cost and schedule forecasts. The sponsor may need impact on business value. The technical team may need defect trends. Integrated change control works best when the relevant work performance information is packaged so that each decision maker can see the part of the picture that matters to their role.
Change requests: corrective action, preventive action, and defect repairs
Change requests are the third input. They are produced by many monitoring and controlling processes and also by many executing processes. A change request is a formal proposal to modify a document, deliverable, or baseline. When someone identifies a variance or an opportunity, they document a change request. The Perform Integrated Change Control process then evaluates that request and decides whether to approve, reject, or defer it. Without a clear, documented request, the change control process has nothing to act on.
Change requests can be classified into corrective action, preventive action, and defect repairs. Corrective action realigns performance with the plan after a variance has occurred. Preventive action addresses a potential future variance before it happens. Defect repairs fix nonconforming products or components. The source material makes an important point here: corrective and preventive actions do not normally affect the project baselines. They adjust how the work is performed against the existing baselines. Only a change request that intentionally modifies a baseline will rewrite the approved plan.
Types of change requests before starting integrated change control
This distinction trips up many project teams. A corrective action to add weekend work to recover a schedule slip does not change the schedule baseline; the end date remains the same. A preventive action to order extra materials before a supplier shortage does not change the cost baseline unless the extra materials push the budget over the approved amount. Defect repairs also do not typically change baselines unless the repair requires new scope or additional funding. Understanding these categories before starting integrated change control helps the team prepare the right documentation and route the request to the right approval level.
Because change requests can originate from so many processes, they vary widely in quality and completeness. A team member might submit a one-line request that says "we need more time." Another might submit a detailed analysis with impact estimates. The project manager should not simply forward every request to the change control board in whatever form it arrives. Part of preparing for integrated change control is reviewing each request, ensuring it describes the problem, the proposed change, the expected impact, and any alternatives considered. This does not mean the project manager makes the decision, but rather that the request is ready for a proper evaluation.
It is also worth remembering that change requests are not always about fixing problems. Some propose opportunities, such as adopting a new technology that could reduce future costs. In Agile environments, change requests often take the form of product backlog items or user stories prioritized for upcoming iterations. But in predictive projects, the formal change request remains the standard vehicle. Regardless of terminology, the input principle is the same: someone has to document what is being proposed before the integrated change control process can assess it.
Key Takeaways on Change Request Types
- Formal proposal to modify
- A change request serves as the formal mechanism for proposing modifications to any document, deliverable, or baseline, providing the Perform Integrated Change Control process with a defined artifact to evaluate, approve, reject, or defer.
- Three categories of change requests
- Change requests are categorized as corrective actions, preventive actions, or defect repairs, and accurate classification enables teams to prepare appropriate documentation and route each request to the correct approval authority.
- Corrective and preventive actions
- Corrective and preventive actions typically do not affect project baselines; for example, adding weekend work to recover a schedule slip leaves the end date unchanged, and ordering extra materials does not alter the cost baseline unless the approved budget is exceeded.
Enterprise environmental factors influencing integrated change control
Enterprise environmental factors are the conditions not under the control of the project team that can influence the change control process. The source material specifically names the project management information system as an enterprise environmental factor to consider on most projects. The project management information system supports the collection, distribution, and storage of project information. If the PMIS is slow, cumbersome, or not configured for change workflows, it will affect how smoothly integrated change control runs.
The project management information system often includes the tools used for scheduling, cost tracking, document management, and communication. Before starting integrated change control, the project manager should understand what the PMIS can and cannot do. Some systems have built-in approval workflows that automatically route change requests to the right reviewers. Others require manual emails and spreadsheets. Knowing these capabilities prevents wasted time and ensures that change requests are logged and tracked consistently.
Other enterprise environmental factors, while not listed in the source material as an exhaustive list, also matter. Organizational culture, stakeholder risk tolerance, and the physical distribution of the team can all influence how change requests are processed. A company with a low risk tolerance may require more documentation and more approvals. A highly distributed team may rely more heavily on the PMIS for asynchronous review. The key point is that these factors are external to the project team but still shape the change control environment.
A practical example helps. Suppose an organization uses a project management information system that automatically timestamps every change request and tracks its status from submitted to approved. That makes auditability easy. In another organization, change requests might be managed through shared documents and email threads. Before integrated change control starts, the project manager should identify which environment they are operating in. If the PMIS lacks a formal change workflow, the project manager may need to create a manual process or escalate the need for better tooling.
Ignoring enterprise environmental factors can lead to a mismatch between the formal process and the reality on the ground. A change control procedure might say that all requests must be entered into the PMIS, but if the PMIS is inaccessible to certain team members, they will bypass the process. That creates undocumented changes, which are exactly what integrated change control is meant to prevent. So understanding the enterprise environmental factors is not an academic exercise; it is a practical step that determines whether the process will actually be followed.
Organizational process assets required for integrated change control
Organizational process assets are the plans, processes, policies, procedures, and knowledge bases specific to the organization. The source material lists several that influence Perform Integrated Change Control. These include change control procedures, procedures for approving and issuing change authorizations, a process measurement database, project files, and a configuration management knowledge base. Each of these assets provides structure and historical context for change decisions.
Change control procedures define the steps by which official company standards, policies, plans, and other project documents will be modified. They spell out how changes will be approved, validated, and implemented. Before starting integrated change control, the project manager must locate and understand these procedures. Some organizations have a simple two-step process for low impact changes. Others have multi-level boards for changes that affect baselines. The procedure tells the team exactly what to do and who has authority to approve.
Reviewing organizational process assets before starting integrated change control
Procedures for approving and issuing change authorizations are closely related. Once a change is approved, someone must formally authorize the work to proceed and the plans to be updated. If the organization has a standard change authorization form or system, that asset should be used. Without a clear authorization step, teams may start implementing changes before the baseline is updated, which leads to confusion about what was actually approved. The project manager should confirm that the authorization procedure is in place and understood.
The process measurement database is another asset. It collects measurement data on processes and products. This database can tell the team whether similar changes on past projects improved performance or introduced new risks. For example, if the organization has data showing that a particular type of schedule compression technique rarely recovers more than five days, the change board can use that evidence when evaluating a request to compress the schedule. The project files also provide historical records of previous projects, including old change logs and lessons learned.
The configuration management knowledge base contains the versions and baselines of all official company standards, policies, procedures, and project documents. This is essential for integrated change control because it allows the team to know which version of a document is current and what changes have been made to it over time. If a proposed change would alter a deliverable, the configuration management system shows the history of that deliverable. Without this knowledge base, the team risks approving changes based on outdated specifications, which can lead to rework and conflicting versions.
Key Takeaways on Change Control Process Assets
- Organizational Process Assets Overview
- Organizational process assets are the organization-specific plans, processes, policies, procedures, and knowledge bases that guide project execution and governance.
- Assets Influencing Integrated Change Control
- Key assets influencing integrated change control include change control procedures, change authorization procedures, a process measurement database, project files, and a configuration management knowledge base.
- Change Control Procedures Role
- Change control procedures outline the required steps for modifying official company standards, policies, plans, and other project documents.
- Formal Change Authorization Need
- Once a change is approved, formal authorization is required to prevent teams from starting work before the baseline and associated plans are updated.
- Process Measurement Database Value
- A process measurement database provides historical evidence, such as schedule compression rarely recovering more than five days, which helps the change board evaluate requests.
How the inputs interact before a change decision is made
The five inputs do not exist in isolation. They form a chain of reasoning. The project management plan establishes the baselines and rules. Work performance information reveals whether actual performance has deviated from those baselines. A change request proposes a response to that deviation. Enterprise environmental factors shape the tools and constraints around the decision. Organizational process assets provide the procedures and historical data for evaluating the request. This is the core of the integrated change control workflow.
Think of it as a feedback loop. The executing processes produce work performance data. Monitoring processes turn that data into work performance information. If the information shows a variance beyond tolerance, a change request is generated. That request enters the integrated change control workflow, where it is assessed against the baselines and filtered through the organization's procedures. The output is either an approved change, a rejected change, or a request for more information. The loop then continues with implementation and updated baselines.
What this really means in practice is that the quality of the decision depends on the quality of each input. A solid project management plan but no current work performance information leaves the change board guessing. A well-documented change request but no clear change control procedures leads to inconsistent handling. An excellent PMIS but no configuration management knowledge base makes it hard to verify the impact on existing versions. The inputs are mutually reinforcing, and missing one weakens the entire process.
A small example illustrates this interaction. Suppose a software project is running behind schedule. Work performance information shows a negative schedule variance of ten days. A team member submits a change request to add two developers to the team. The project management plan shows that the schedule baseline was approved with the current resource levels. The change control procedures require a cost-benefit analysis. The PMIS tracks the request through the approval workflow. The process measurement database shows that adding developers late in a project often has a learning curve that offsets the intended benefit. Only when all these inputs are available can the change board make a sound decision.
The interaction also explains why integrated change control is called "integrated." It is not a standalone approval step. It pulls together scope, schedule, cost, quality, risk, resources, and stakeholder considerations. A change that looks good from a schedule perspective might be terrible from a cost perspective. The inputs provide the multi-dimensional view needed to evaluate that trade-off. If the project manager assembles the inputs carefully, the change board can see the full picture instead of a narrow slice.
Common mistakes when assembling inputs for integrated change control
There are several recurring mistakes that project managers make before starting integrated change control. The most common is skipping work performance information entirely. Some project managers submit a change request based on a stakeholder's opinion that the project is behind, without checking the actual variance data. That leads to change decisions driven by anecdote rather than evidence. This is one of the most damaging common mistakes in integrated change control inputs. The change board may approve a change that does not address the real problem or reject one that is genuinely needed.
Another mistake is treating all change requests as if they were baseline changes. As the source material notes, corrective and preventive actions do not normally affect the project baselines. If a project manager escalates a simple corrective action through a full baseline change process, it creates unnecessary delay and committee overhead. Conversely, if a genuine baseline change is treated as a mere corrective action, the project manager may implement it without the proper approvals, undermining governance. Misclassifying the request type is a frequent source of trouble.
A third mistake is ignoring organizational process assets. Some teams try to run change control based on informal memory of how it was done last time. They do not check the current change control procedures, the process measurement database, or the configuration management knowledge base. This can lead to using an outdated approval threshold or skipping a required authorization step. The result is a change that is implemented but not properly documented, which creates problems during audits and future planning.
There is also the mistake of not updating the project management plan after previous changes. If the baselines are stale, every subsequent change decision is built on a flawed foundation. For example, if a scope change was approved but the WBS was not updated, the next change request may be evaluated against an obsolete scope baseline. The project manager should treat baseline updates as part of completing a previous change, not as an optional follow-up.
Finally, teams sometimes overlook the enterprise environmental factor of the PMIS until it is too late. They plan a change control process that assumes a capable system, only to discover that the system cannot route approvals or store attachments. This forces them to improvise at the moment a decision is needed. Before starting integrated change control, a quick check of the PMIS capabilities can prevent this kind of last-minute scramble. It is a small step that pays off in smoother execution.
Key Takeaways on Common Input Mistakes
- Skipping work performance information
- The most common mistake is omitting work performance data altogether, which deprives the change control process of the factual basis needed for sound decisions.
- Anecdote replacing variance evidence
- When stakeholders submit change requests based on a perceived schedule slip without consulting actual variance data, the change board ends up making decisions on opinion rather than objective evidence.
- Corrective actions and baselines
- Since corrective and preventive actions typically do not alter project baselines, they should not be forced through the full baseline change procedure.
- Mishandling the level of change
- Escalating a simple corrective action creates unnecessary delay and committee overhead, while treating a genuine baseline change as a mere corrective action bypasses required approvals and undermines governance.
- Ignoring governance and documentation inputs
- Neglecting the change control procedures, process measurement database, or configuration management knowledge base leads to poorly documented changes that create audit findings and weaken future planning.
Integrated change control across PMBOK, PRINCE2, and Agile environments
In the PMBOK framework, Perform Integrated Change Control sits in the Project Integration Management knowledge area and the Monitoring and Controlling Process Group. Its purpose is to review all change requests, approve or reject them, and manage changes to deliverables, documents, and baselines. The inputs described here are part of that process definition. Understanding where the integrated change control process group sits helps project managers know when in the lifecycle to apply it. It is not a one-time event; it runs throughout the project as changes arise.
PRINCE2 has a similar but distinct approach through its change control theme. PRINCE2 uses issue and change control procedures to manage requests for change, off-specifications, and problems. The change authority reviews requests against the project's tolerances and the business case. While PRINCE2 uses different terminology, the underlying inputs are conceptually similar. There is always a baseline or plan, some form of performance information, a documented request, and organizational procedures for making the decision.
In Agile environments, change control looks different. Agile teams expect requirements to evolve, so they do not typically run a formal change request process for every backlog refinement. Instead, the product owner prioritizes changes against value, and the team incorporates them into upcoming iterations. Work performance information in Agile might come from velocity, burn-down charts, and cumulative flow diagrams. The project management plan equivalent is often a product roadmap and release plan. Even though the formality is lower, the need to understand what is being changed and why remains.
Business Value-Oriented Project Management (BVOPM) adds another angle. BVOPM treats process damage as invisible organizational harm that can accumulate when change decisions are poorly managed. It also tracks Business Value Points, where a persistent decline signals that a project may need closure rather than more corrective changes. This perspective reminds project managers that integrated change control is not just about approving requests; it is about protecting the value the project is meant to deliver.
The common thread across these frameworks is that change decisions require a clear baseline, evidence of current performance, and a structured way to evaluate proposed adjustments. The specific forms differ, but the fundamental question is the same: should we change what we planned, and if so, how? Preparing the right inputs before starting integrated change control is what makes the answer trustworthy in any methodology.
Practical preparation steps for project managers before initiating integrated change control
Before a project manager convenes a change control board or routes a request through the PMIS, several practical steps can make the process much more effective. First, confirm that the project management plan and all baselines are current. If there are approved changes that have not been incorporated, update them now. This ensures the evaluation starts from the real baseline, not an outdated one. This first check is the foundation of integrated change control readiness.
Second, gather the most recent work performance information. Do not rely on memory. Pull the latest variance reports, forecasts, and status updates. Check whether the information covers the areas affected by the proposed change. If a change request concerns scope, the schedule and cost implications should also be visible. If the information is thin in a key area, ask the relevant control process owner for a current update before the decision meeting.
Readiness checklist before starting integrated change control
Third, review each change request for completeness and classification. Determine whether it is a corrective action, a preventive action, a defect repair, or a baseline change. Corrective and preventive actions may not need the same approval level as baseline changes. A quick classification pass can route requests to the right authority and avoid over-processing. If a request is unclear, send it back for more detail rather than letting it stall in the process.
Fourth, check the relevant organizational process assets. Locate the current change control procedures and the authorization templates. Review the process measurement database for similar past changes. Confirm that the configuration management knowledge base has the current versions of any documents that might be affected. These assets are not optional; they are the rules and evidence base for the decision.
Fifth, verify the enterprise environmental factors. Confirm that the project management information system is accessible to all relevant reviewers and that it supports the required workflow. If the PMIS cannot handle the approval routing, set up a manual parallel process before the meeting, not after. Also consider organizational culture and risk tolerance, which may affect how much documentation is expected.
These steps do not guarantee that every change decision will be easy, but they remove the avoidable friction. A project manager who has assembled the right inputs can present the change request with confidence and answer the change board's questions. The alternative is a meeting where half the time is spent searching for the current baseline or questioning the variance data. That is a waste of the team's time and a sign that integrated change control was started prematurely.
One more consideration: preparation is not a one-time event. Every time a new change request enters the process, the project manager should repeat these checks. The baseline may have changed, new work performance information may have emerged, and the organizational procedures may have been updated. Treating preparation as an ongoing discipline is what separates mature change control from ad hoc decision making.
Key Takeaways on Change Control Preparation
- Confirm plan and baselines are current
- Verifying that the project management plan and all baselines are current before evaluating any change request ensures the assessment is anchored to the project's actual state rather than an outdated snapshot.
- Gather the latest performance information
- A current set of variance reports, forecasts, and status updates gives the change control team objective evidence, reducing reliance on assumptions or stale data.
- Make scope impacts fully visible
- For scope-related change requests, presenting the linked schedule and cost impacts together gives decision makers a complete view of the trade-offs before approval.
- Ask process owners for updates
- When critical information is missing, the project manager should request an updated input from the relevant process owner before the decision meeting to prevent delays and uninformed approvals.
- Classify requests for proper routing
- A quick classification step separates corrective and preventive actions from baseline changes, ensuring each request reaches the appropriate authority and avoiding unnecessary overprocessing.
