1.2Integration management and change control

Integration management is not a field of memorizing "what a project charter is"; it tests the ability to judge, when a change request (a specification change, an add-on request, a shift in assumptions) arises during project execution, through which procedure the PM should receive, assess, approve, and reflect it. It is more normal than not for a project to deviate from its plan, and the essence of integration management is not to prohibit change itself but to manage change through a controlled process. Accepting changes without discipline invites scope creep and degraded quality, while refusing all changes outright damages customer satisfaction and business value.

1.2.1The project charter and the overall plan

• The project charter is the document that formally authorizes a project's existence and grants the PM the authority to apply resources. It defines the project's purpose, overview, key constraints, and sponsor—the first point of agreement at project initiation. Without a charter, the PM would be operating without formal authority.
• The project management plan is the document that integrates the plans of each knowledge area—scope, schedule, cost, quality, resources, risk, and so on—serving as the baseline for how the project will be executed, monitored, and closed. Judgments made during execution, and whether a change is warranted, are assessed against the deviation from this plan (the baseline).

1.2.2Integrated change control and configuration management

• Integrated change control is the controlled sequence of steps for a change request that arises: (1) formally record it as a change request -> (2) assess its impact on scope, schedule, cost, quality, and risk -> (3) decide to approve, reject, or defer it via a change control board (CCB) or similar body -> (4) reflect only approved changes into the baseline. The principle is not to alter the plan through verbal agreement or informal handling.
• Configuration management manages the version and status of deliverables and documents, an activity that ensures only approved changes are reflected in the official configuration (baseline). It pairs with integrated change control, maintaining a state where "what is currently the official, latest version" can always be uniquely identified.

Suppose you are the PM of a system development project, and a development lead reports that "a customer's on-site contact directly and verbally asked to add one more field to this screen, and since it didn't look like much effort, I just handled it on the spot." Even though this may look harmless at first glance, several risks are lurking from the standpoint of integrated change control. First, because this change was not recorded as a formal change request, it is not reconciled against the scope statement or WBS, creating a risk of a later he-said/she-said dispute or a failure to account for it to other stakeholders. Second, the on-site, subjective judgment that "it didn't look like much effort" left the impact on the schedule, on other features, and on whether the test scope needs revisiting unassessed, and an accumulation of such small changes can later surface as scope creep, a classic pattern where delays and quality problems suddenly appear all at once right before release. The action the PM should take is to first retroactively record this change as a formal change request, perform an impact assessment, and then re-communicate to the team the operating rule that even a minor change must always go through the integrated-change-control process (record -> assess -> approve -> reflect). At the same time, in case urgency makes on-the-spot handling unavoidable, it is also effective to pre-agree with the CCB on a lightweight approval flow that can approve minor changes quickly (for example, changes below a pre-defined impact threshold can be approved same-day under the lead's authority). The core of integration management is neither "prohibit every change" nor "informally accept anything," but rather handling change within a controlled process.

1.2.3Section summary

• The project charter grants the PM authority; the project management plan is the document serving as the baseline for execution, monitoring, and change decisions
• Integrated change control is a controlled process of record -> impact assessment -> approval -> reflection into the baseline, and is not skipped even for a minor change
• Configuration management reflects only approved changes into the official configuration, preventing an accumulation of informal handling from inviting scope creep