Scope changed in week six. The graph absorbed it.

Every long rollout pivots at some point. The question is not whether scope will change. The question is what it costs you when it does.

Traditionally the cost is ugly. Replan the Gantt. Redo the task list. Reassign owners. Reverify evidence. Chase down which decisions were made against which assumptions and whether those assumptions still hold. The rollout loses a week. Sometimes two. Sometimes more. Just absorbing the change.

We watched this happen enough times that we made the graph absorb scope mutations as a first-class thing.

What that actually means

Six weeks into a rollout, scope changes. Three new systems added. One system dropped. Two tasks redefined. A compliance requirement tightened.

You edit the graph. The graph does the rest.

Tasks that are no longer relevant are marked superseded, with their evidence retained and linked to the decision that superseded them. Nothing gets deleted. The record stays intact.

Tasks that changed re-enter their dependency chain. Evidence tied to an earlier version gets flagged for re-capture, or carried forward if the change did not invalidate it.

New tasks drop into the right phase with the right prerequisites. The plan updates. The dependency graph recomputes. Stakeholders see the new shape of the rollout, not a confused hybrid of old and new.

Why this matters

Most tooling treats scope change as a failure mode. It is not. It is the normal condition of a real rollout. Requirements tighten. Systems get added. Priorities shift. The tooling should be designed for that.

If every scope change costs you a week of replanning, your tooling is fighting your reality.

The short version

Scope will change. Plan for it in the tool, not in a war room.