Integrated change control is the process by which a change to a project baseline is requested, assessed, decided and recorded. A baseline is a record of what was agreed, and its entire value lies in the fact that it does not move quietly. PMI places the process under the Governance domain in PMBOK 8, and the examination tests it with scenarios in which somebody asks for something and the candidate must say what happens next. At the moment somebody edits the schedule so that it matches what is now happening, the difference between plan and reality vanishes, and every measurement that depended upon that difference vanishes with it.
The sections below explain why a baseline changes only by decision, follow a change request along its path, say who may approve one, describe what happens to the baseline afterwards and show where the same problem sits on adaptive work.
Why a baseline changes by decision
Variance is the gap between an agreed position and an observed one. Where the agreed position is moved to meet the observation, the gap closes without anything having improved. An unrecorded baseline edit is therefore the quiet destruction of the project's measurement.
Integrated is the half of the name that carries the weight. Every change that presents itself as scope will land somewhere else as well, so the analysis has to run across scope, schedule, cost, quality, resources and risk together. Where a request turns out to cost nothing and to take nothing extra, this usually means the analysis stopped at the first dimension.
The path a change request takes
The five dimensions are assessed together, because a change that presents itself as scope lands on the other four as well. On adaptive work the lower lane decides which route a request takes, so reshaping the remaining work stays with the team while anything touching the outer envelope joins the path above.
Anybody may submit a change request, in writing, describing what is wanted and why. It is logged whether or not it appears sensible, since the log is the evidence that a decision was taken.
Impact analysis is where the work sits. Someone competent assesses what the change does to scope, to the schedule and the critical path, to cost and the reserves, to the quality characteristics that were agreed and to the risk position. What comes out of this is a statement of what accepting the change would cost. Whether the change is a good idea is a separate question, answered next.
A decision follows, and it is to approve, to reject or to defer. Deferral is a real answer, since a change that is right for the next release and wrong for this one is a sequencing decision that happens to be recorded as a refusal today.
Approval then triggers two steps that are routinely forgotten. First, the affected baselines and plans are updated. Second, the people whose work has just changed are told. Where a change is approved and never communicated, the organisation has paid for something it never received.
Who may approve a change
The decision step has an owner, and for changes that cross agreed thresholds the owner is the change control board. Its composition follows the money and the risk, so it usually includes the sponsor, the customer or their representative and whoever will own the operational consequences.
Below those thresholds the project manager decides alone, and the thresholds themselves are set deliberately at the point where the change management plan is written. Small changes that sit inside contingency and inside agreed tolerance are settled there, because routing everything to a committee produces a board that rubber stamps. Anything touching the cost baseline, the delivery date, contracted scope or the benefits case belongs to the board however small it appears.
How an approved change resets the baseline
Once a change has been approved the baseline is reissued to include it. Where a project takes on three extra weeks of work and continues to measure against the old plan, it will report a variance for the remainder of its life that nobody is able to act upon, since the gap being reported is the approved change itself, and no delivery action can close it.
Reissuing restores the meaning of every measurement built upon the baseline. It also leaves a record of how the plan grew, and this is often a more interesting account than the variance figures. Four approved changes that together added twenty per cent to the budget are a governance finding, and that finding stays invisible for as long as each change is absorbed without being baselined.
Where adaptive delivery puts the same problem
On adaptive work the boundary moves, and it does not disappear. Inside an iteration the team is expected to learn, so reordering, reshaping and dropping items on the strength of what the last increment revealed is the method working as designed. To demand a change request for this would defeat the reason for iterating at all.
What remains baselined is the outer envelope. Funding, the release commitment given to a customer, contracted scope, regulatory obligations and the architecture the organisation has to live with all continue to change by decision. Hybrid delivery runs both arrangements at once, with an iteration that absorbs change freely sitting inside an envelope that does not. The common failure here is a team that treats the envelope as negotiable because the iteration is.