Working out what a change really costs
Anyone can see that three weeks of extra work adds three weeks somewhere. What nobody can trace in their head is everything else that moves.
Never let the scenario become the baseline
The most common failure in change control is procedural rather than analytical: the proposed plan is saved over the agreed one, and a fortnight later nobody can answer "compared to what?"
That is the only question anyone asks about a change afterwards. Keeping the baseline immutable is what makes the answer available.
The knock-on is the finding
A change that looks small because it touches one activity can cost a month, because that activity fed two others through a chain nobody was thinking about.
The list worth reading is the activities that moved without being edited. That is the part human reasoning gets wrong, and the reason to run the analysis at all.
A change with no date impact can still hurt
A change absorbed entirely by float leaves the finish date untouched and makes the project materially riskier — the slack that was protecting the date has been spent.
Report only the date movement and this passes unnoticed, which is how a project absorbs four "no impact" changes and then slips on the fifth. Compare total float as well.
Watch for the critical path changing
A change can move the governing chain onto work that nobody was watching. Everyone keeps monitoring the old critical path, which now has slack, while the real constraint sits somewhere else entirely.
Schedule is not the whole impact
This kind of analysis covers duration, dependencies, float and the critical path. It says nothing about cost, resourcing, quality, or whether the change is a good idea.
Those need judgement and different data. A tool that scored them would be inventing numbers, and a change decision made on invented numbers is worse than one made on none.
Measure against what is left, not what was spent
The question a change impact answers is what happens from here, and that makes everything already completed irrelevant to it. Effort spent is not recoverable by any decision available now, so including it in the comparison can only distort the answer — usually towards continuing something because of what it has already cost.
In practice this means rebaselining the comparison on remaining duration and remaining effort before modelling anything. A change that adds two weeks to a project with two weeks left is a very different proposition from the same change on a project with a year to run, and the total elapsed so far tells you nothing about which situation you are in.
Small changes compound, and each one passes
The failure mode that catches projects is not the large change everybody argues about. It is the sequence of small ones, each individually within tolerance, each assessed on its own against the plan as it stood that week. Five changes of three days each are approved without difficulty and are, together, a three-week slip that nobody ever decided to accept.
The defence is to assess against the original baseline as well as the current one, and to keep a running total of accepted changes visible next to any new assessment. It costs almost nothing and it turns "this is only three days" into "this is three days, and the eighteenth working day we have added since March" — which is the same fact, stated in a way somebody can act on.