change is inevitable; scope creep is a choice

The scope agreed at the start of a project rarely survives untouched all the way to the end — new information, a shifting market, or a stakeholder realizing they need one more thing are all normal. The difference between healthy change and scope creep isn't whether requests come in; it's whether they go through a process before they're accepted.

the change control process

A formal change control process gives every request the same treatment instead of an ad hoc yes or no:
  • Submit — the request is written down: what's being asked for, and why.
  • Analyze impact — assess the effect on scope, schedule, cost, quality, and risk. A change that looks small in isolation can still blow up the critical path.
  • Decide — a Change Control Board (CCB) (on a small project, this might just be the sponsor and PM; on a large one, a standing committee) approves, rejects, or defers the request.
  • Update baselines — if approved, the WBS, schedule, and budget baselines are formally updated so everyone is working from the same revised plan, not silently absorbing the change into "informal" scope.
The point of the process isn't to say no to everything — it's to make every change a visible, deliberate decision instead of scope quietly expanding one favor at a time.

internal vs. external dependencies

The task dependencies covered when sequencing a project plan are internal — both sides are inside the project, under the PM's own scheduling control. An external dependency is different: the project needs something from outside its own control — another team's deliverable, a vendor's shipment, a regulatory approval — and the PM can influence it but can't directly command it.
External dependencies deserve their own tracking, similar to a risk register: what's needed, from whom, by when, and who inside the project owns following up on it. Treating an external dependency the same as an internal task — a bar on the Gantt chart and nothing else — hides how much less control the team actually has over whether it lands on time.

escalation: raising it before it's too late

Escalation is asking someone with more authority or reach to help resolve a problem the project team can't solve on its own — a stalled external dependency, a conflict between stakeholders, a resource conflict the PM can't unblock alone. The goal is to escalate early enough that options still exist, not as a last resort once the deadline has already been missed.
Deciding this in the moment, under pressure, tends to go badly. Agreeing on an escalation path ahead of time — who gets contacted, at what threshold, through what channel — removes the hesitation that usually causes escalation to happen too late.

a short example

Midway through a project, a stakeholder asks for an additional dashboard view that wasn't in the original scope. It goes through change control: impact analysis shows it would add a week to the critical path with no available slack, so the CCB defers it to a phase-2 release instead of accepting it into the current one. Separately, the project depends on an external data provider delivering an updated API by a certain date; when that date passes with no update, the PM doesn't wait and hope — per the agreed escalation path, they raise it with the sponsor at the one-week-late mark, while there's still time to find a workaround before it threatens the launch date.

practical notes

Not all change is bad — a change control process exists to evaluate requests fairly, not to reflexively reject anything that wasn't in the original plan.
"I thought it would resolve itself" is the most common reason escalation happens too late. If a dependency is already past its committed date with no clear resolution in sight, that's usually the moment to escalate, not the moment to wait one more week.

related topics

reference