Keel
  1. Keel
  2. Blog
  3. Planning for delays

Slack, slips and what-ifs: planning for delays before they happen

Every plan will slip somewhere. Learn how slack works, how slips propagate through dependencies, and how to test a delay safely with a what-if simulation.

Cover: Slack, slips and what-ifs: planning for delays before they happen

Every plan slips somewhere. The teams that ship on time are not the ones with no delays; they are the ones who see the cost of a delay early and decide what to do.

Slack is your budget

Slack is how long a task can slip without moving anything that matters. Tasks on the critical path have none. Others have days or weeks. Knowing where the slack is tells you which delays you can absorb.

How slips propagate

When a task moves, everything that depends on it may move too, but only as far as their own slack allows. A four-day slip can disappear into a task with a week of slack, or ripple all the way to the launch.

Working that out by hand across dozens of tasks is slow and error-prone. It should be computed.

Ask “what if?” first

A what-if simulation lets you try a delay without changing the plan. “What if Auth service is four days late?” The answer: three tasks move, and the launch loses all of its slack.

That turns a vague worry into a concrete decision: cut scope, add help, or accept the risk.

Make the result a proposal

If the delay becomes real, the simulation is already done. Turn it into a proposal that shifts the affected tasks together, with the reason attached, and let the team approve it.

Rules for safe simulations

  • Never write to the real plan during a what-if.
  • Adding a delay should never move any date earlier.
  • Simulating then undoing should give back exactly the original plan.

When to run a what-if

  • When someone says a task “might” slip.
  • Before agreeing to new scope mid-project.
  • When a key person is about to be away.
  • In every planning review, on the riskiest task of the critical path.

Turning the answer into a decision

A simulation result usually leads to one of four moves: absorb the delay in slack, cut or move scope, add help to the critical task, or accept a later date and tell people early. The value of the what-if is that you choose deliberately, with the numbers in front of you, instead of finding out at launch.

Keel's what-if works this way on the dependency graph. Try the delay on the graph.

Questions

What is a what-if analysis in project planning?

A simulation of a change, such as a task being four days late, that shows every affected date without changing the real plan.

How do delays propagate in a project?

Through dependencies. Each task waiting on the delayed one may move, as far as its own slack allows; on the critical path, the delay reaches the end date.