Everyone is busy, several tasks finish early, and launch still slips. The missing distinction may be between local progress and the dependency that determines the finish date. The critical path method makes that constraint explicit. This guide starts with a six-task game, then explains slack, competing paths and the assumptions that keep a simple schedule useful without turning it into a promise.
A schedule begins with dependencies, not a priority list
List what must finish before each task can start. Two tasks that can run simultaneously contribute differently to elapsed project time from two tasks that must run sequentially. Adding every duration ignores parallel work; choosing the single longest task ignores dependencies. A project network represents those relationships so the earliest possible completion can be calculated under stated assumptions.
The critical-path game uses six tasks. Design A precedes Copy C and Build D. Permit B precedes Delivery E. Launch F waits for C, D and E. Each task has a certain duration, and resources are unlimited. The model therefore isolates dependency timing before introducing staffing conflicts or duration uncertainty.
The critical path is a longest dependency path
A critical path is a dependency chain whose total duration determines the earliest project finish. There can be several equally long critical paths. In the game, the initial longest chain is A–D–F at ten days. A–C–F takes seven, and B–E–F takes nine. Finishing Copy sooner does not change when Launch can begin if Build still finishes later.
The primary paper by Kelley and Walker on critical-path planning develops the method in its original scheduling setting. Modic's activity keeps its arithmetic small enough to check manually. A forward pass finds earliest finishes; a backward pass finds how late tasks can finish without delaying the project. The difference gives slack under the dependency-only schedule.
Worked example: spend acceleration where it matters
You have three fictional acceleration tokens. Each shortens one task by one day, with a minimum task duration of one. Tokens do not represent actual staffing or cost estimates. The goal is to understand why identical local time savings can have different effects on the launch date.
- Start with durations A=3, B=4, C=2, D=5, E=3, F=2. Verify A–D–F totals ten days and B–E–F totals nine.
- Spend a token on C. Its duration falls from two to one, but the longest path remains ten days. Reset and spend the token on D instead; the project falls to nine.
- Now A–D–F and B–E–F are both nine. Recalculate before using another token: shortening just one of these paths may leave the other path as the same launch constraint.
Slack is timing flexibility, not a statement of importance
A task with slack can be delayed within that allowance without changing the modelled completion date. That does not make the task unimportant or safe to neglect. It may carry quality risk, require scarce expertise or become a future constraint. Slack is a property of the current schedule and assumptions, not a permanent label attached to a person or department.
The game updates slack after each acceleration. This is why a static list of critical tasks quickly becomes stale. A change that removes one bottleneck may expose another. A useful team review asks which path now sets the finish, which tasks share that constraint and what new dependency information has appeared since the previous calculation.
A practical review of the next finish-date claim
Build the smallest network that supports the decision. You do not need a diagram containing every minor activity to discover that two major prerequisites determine launch. You do need to identify real handoffs and update estimates when the work changes. Use the schedule as a shared reasoning aid with a visible owner for each assumption.
- Define completion and list the prerequisites for each major task.
- Separate work that can overlap from work that must wait.
- Calculate current longest paths and slack.
- Evaluate acceleration against every path it affects.
- Recalculate after a duration or dependency changes.
- Record resource constraints and uncertainty that the simple network leaves out.
A deterministic finish date is not a delivery guarantee
The Project Management Institute's history of CPM offers context from the method's development. The game deliberately omits the time-cost and practical coordination complexity of larger projects. Real durations can be uncertain, tasks can compete for the same specialist and accelerating work can increase error or rework.
Treat a calculated earliest finish as conditional: if durations, dependencies and resources behave as assumed, this is the implication. Ask which assumption is most fragile and what contingency would help. A schedule becomes more useful when it exposes those conditions than when it supplies a precise-looking date with no explanation. The next good action is the one that changes the actual constraint while preserving the quality and purpose of the work.
Try the ideas for yourself.
These are teaching models. Follow the assumptions in each experiment; the results are not real-world forecasts.
Sources & further reading
Current-event context was checked on October 26, 2026. Follow the original source for newer updates. Worked scenarios are illustrative unless explicitly identified as reported data.
- Kelley and Walker — Critical-path planning and scheduling ↗
The original critical-path planning and scheduling paper.
- PMI — Origins of CPM: a personal history ↗
Historical account from the method's development.