Why you should simulate every delay before accepting it

A supplier calls: they need two more weeks. Your instinct says it is fine, there is slack somewhere. Your programme board wants certainty. Between instinct and certainty sits simulation.

Delay simulation means entering a hypothetical delay against one or more tasks and letting the tool propagate it through the full dependency network without saving anything. The Gantt chart shifts, the impact matrix recalculates, and the critical path re-forms in front of you. You see the real cost of those two weeks: which delivery groups are hit, which milestones move, and whether the programme end date survives.

The compound scenario is where simulation earns its keep. One delay might be absorbable. Two delays on parallel chains that converge on a shared integration task are a different story: the downstream task inherits the worst of both, and float you thought you had evaporates. Modelling compound delays by hand across a 600-task programme is practically impossible. A simulator does it in under a second.

The practical workflow is simple. Enter the requested delay. Read the cascade summary: affected tasks, propagated days, root cause chain. If the end date holds, accept with confidence. If it does not, you now have specifics to negotiate with: "we can absorb one week, not two" or "we can accept two weeks if the testing window compresses". Either way, you walk into the conversation with the numbers.

Never commit a simulated scenario until the decision is made. Keeping what-if strictly separate from the live plan means everyone trusts the plan of record, and simulation stays what it should be: a safe space to be wrong.