Change Control Tools

Integration technique · See it on the map

Guide only — Names whatever change-control tooling the org runs.

Deciding whether a proposed change to an already-approved plan is accepted, and updating the plan only once it is.

When to use it

Once a Baseline exists with an approval date set, and someone wants to alter the scope, dates, or cost that baseline represents. Use it whenever the change would make current status reporting compare actuals to a plan nobody has actually agreed to anymore.

When to avoid it

Before a baseline is ever approved — a draft Baseline's lines can just be edited directly, because there is nothing frozen yet to protect. Also avoid routing every minor, in-tolerance adjustment through it: a board that rubber-stamps ten trivial requests a week stops reading the ones that matter. If the adjustment doesn't move an approved date or cost figure, it isn't a change to control.

Steps

1. Log the change as a ChangeRequest on the project — description and a raised date — with status left at its default, 'proposed'.
2. Before anyone decides, assess the real impact: walk the BaselineLine rows for the affected tasks and anything downstream of them, not just the task the requester named.
3. Bring the request and its assessed impact to whoever the project's change authority actually is, and record the decision as one of CHANGE_STATUSES.
4. If approved, build the new Baseline: bump version, carry forward unaffected BaselineLine rows unchanged, and write new lines for whatever the change moved.
5. Set the new Baseline's approval date, then link the ChangeRequest's resulting baseline id to it — the schema only allows that link once status is 'approved', so cause and consequence stay tied together.
6. Tell whoever reads the plan downstream (schedule views, cost baseline, milestones) that a new version exists, so nothing keeps citing the superseded one.

What it produces

• An approved ChangeRequest whose resulting baseline id names the version it produced.
• A new Baseline version with its own BaselineLine rows, sitting alongside every prior version rather than replacing it.
• A durable record of what was asked for, what it would have cost, and what was decided — including the requests that were rejected or withdrawn.

Common pitfalls

• The emergency change made in the field and never logged afterward: the work happens, no ChangeRequest is ever raised, and the baseline silently stops matching reality with no record of why.
• Approving a request before its schedule and cost impact has actually been assessed — the CHECK constraint only stops the resulting baseline id from being set on anything but an approved request; it has no way to verify the approval was informed.
• Re-baselining so often, and so readily, that 'approved' stops meaning anything — if every slip gets absorbed into a fresh version instead of being questioned, the plan chases the actuals instead of the actuals being measured against the plan.
• Discarding a rejected or withdrawn request instead of keeping it — it has no resulting baseline id, but it is still the record of what was asked for and refused, and why.

Worked example

A community-center renovation has an approved Baseline v1 four months in. The contractor finds the electrical panel needs replacing: +$18,000, +2 weeks on that one task. The PM logs a ChangeRequest, then walks the BaselineLine rows for the panel task and the inspection and drywall tasks that depend on it, and finds the real schedule hit is 3 weeks once the dependency chain is included, not 2. The sponsor approves it with the corrected number. The PM creates Baseline v2, carrying forward every unaffected line as-is and writing new lines only for the panel, inspection, and drywall tasks, sets its approval date, and points the ChangeRequest's resulting baseline id at v2.

Source

• PMBOK-6 §4.6.2.2

Where it comes from: this technique is named by the PMBOK Guide, 6th edition.