If you have ever watched a launch slip because of a task nobody was worried about, you have met the critical path.
The definition
The critical path is the longest chain of dependent tasks in a plan. Because each task on it waits for the one before, any delay on that chain moves the end date by the same amount.
Tasks off the critical path have slack: time they can slip without moving anything that matters. A task with four days of slack can be four days late and the launch still holds.
How to find it
- List tasks and durations. Estimates do not need to be perfect; they need to be consistent.
- Link dependencies. For each task, note what it waits on. “Payments API waits on Auth service.”
- Forward pass. Walk the graph from the start. Each task's earliest start is the latest finish of everything it depends on.
- Backward pass. Walk back from the launch date. Each task's latest finish is the earliest latest-start of everything that depends on it.
- Compute slack. Latest start minus earliest start. Tasks with zero slack form the critical path.
A worked example
Take five tasks: Auth service, Payments API, App integration, Mobile release, and Launch. Each waits on the one before. If Launch is due Nov 18 and the chain finishes Nov 14, the launch has four days of slack.
Now Auth service slips four days. Every task after it moves four days, Mobile release now lands on Nov 18, and the launch has zero slack. Nothing has missed a deadline yet, but the plan has no room left.
Why teams miss it
Boards show tasks as independent cards. A card that is “in progress” looks fine, even if three other teams are waiting on it. The critical path only becomes visible when dependencies are explicit.
It should also be computed by code, not estimated in a meeting. The same plan should always give the same answer, so nobody argues about whether the launch is at risk.
Common mistakes
- Treating the critical path as fixed. It changes every time a date moves. A task with slack today can be critical tomorrow.
- Ignoring hidden dependencies. Review, QA, and app store approval are tasks too. Leave them out and the path looks shorter than it is.
- Padding every estimate. Padding hides where the real risk is. Keep estimates honest and protect the launch with explicit buffer at the end.
- Calculating it once. A critical path computed at kickoff and never updated is a historical document, not a plan.
How to use it week to week
Look at the critical path first in every planning review. Ask what could slip on it, who owns each task, and whether any task off the path has less slack than you thought. When a delay is reported, check whether it is on the path before deciding how urgent it is.
Keel computes the critical path from your dependency graph and recomputes it when any date moves. See the dependency graph.
