Schedule Compression: Fast-Tracking vs Crashing
Sooner or later a sponsor asks the question every planner dreads: can we finish two weeks earlier? There are exactly two honest ways to shorten a schedule without cutting scope, and each buys you time at a price. Fast-tracking pays in risk. Crashing pays in money. Knowing which lever to pull, and where, is the difference between a confident yes and a promise you cannot keep.
What schedule compression is
Schedule compression means shortening the project duration without reducing its scope. That last part matters: dropping features is not compression, it is a different plan. Compression keeps all the work and finds a way to fit it into less time. There are only two mechanisms for it, and everything else is a variation on them: fast-tracking and crashing.
Both are aimed at the critical path, because only the critical path sets the finish date. Compressing a task with float shortens nothing.
Fast-tracking: overlap the work
Fast-tracking takes tasks that were planned in sequence and runs them in parallel, or overlaps them with lead time. Instead of finishing design before development starts, you start development on the finished parts while design continues. No extra money changes hands, so fast-tracking is the first lever to reach for.
The cost is risk. Tasks that overlap can now clash: if design changes after development began, you rework. Fast-tracking trades certainty for speed, and it works best where the overlap is genuinely safe.
Crashing: add resources
Crashing throws resources at a task to make it shorter: two developers instead of one, a second crew, paid overtime. The duration drops, but the cost rises, and rarely in proportion, five people almost never finish a five-day task in one day. Crashing is subject to hard limits: nine women cannot make a baby in a month.
Crash where you get the most days per dollar, which is usually the longest critical-path tasks that genuinely split across more people. Crashing a task that cannot be parallelised just burns money.
Side by side
| Fast-tracking | Crashing | |
|---|---|---|
| Method | overlap tasks | add resources |
| Costs you | risk and rework | money |
| Direct cash cost | usually none | yes |
| Try it | first | if overlap is not enough |
How to choose
Work the levers in order:
- Find the critical path, it is the only place compression helps.
- Fast-track first: look for sequential critical tasks that could safely overlap.
- If that is not enough, crash the critical tasks where extra people genuinely shorten the work.
- Re-check the critical path after each change, compressing one chain often makes another one critical.
A worked example
- Fast-track: start Build on the finished modules while Design wraps, overlapping 4 days. Total drops to 16 days at no cash cost, but a late design change means rework.
- Crash instead: add a second developer to Build, cutting it from 12 to 8 days. Total is 16 days, safely, but the labour bill goes up.
Watch the new critical path
The catch that surprises people: compress one chain and a different one can become critical. If you crash Build down far enough, some other path you were ignoring, with its own tasks, may now be the longest route to the finish, and compressing Build further saves nothing. After every change, recalculate the critical path. A tool that highlights it for you turns this from guesswork into a glance.
The short version
To shorten a schedule without cutting scope, compress the critical path, and only the critical path. Fast-track first by overlapping sequential tasks, which costs risk but no money; crash second by adding resources, which costs money but not risk. Recheck the critical path after each move, because compression shifts it. Model the options free in the gantts.app editor and watch the finish date respond.
Templates that use this
Keep reading
- Critical Path Method (CPM): Steps, Formula & Example
- What Is Float (Slack) in a Project Schedule?
- Lead Time vs Lag Time in Project Scheduling
Frequently asked questions
What is the difference between fast-tracking and crashing?
Fast-tracking overlaps tasks that were planned in sequence, shortening the schedule at the cost of added risk and possible rework, with no direct cash cost. Crashing adds resources to a task to shorten it, which costs money but not risk. Both target the critical path.
Which should I try first, fast-tracking or crashing?
Fast-tracking, because it usually costs no money, only risk. Look for critical-path tasks that can safely overlap. If overlapping is not enough or not safe, then crash by adding resources to the tasks where extra people genuinely shorten the work.
Why does schedule compression only work on the critical path?
Because only the critical path determines the finish date. Tasks that are not on it have float, so shortening them does not move the end date, it just increases their slack. Compressing effort anywhere but the critical path saves no time.
Does crashing always shorten a task proportionally?
No. Adding resources rarely cuts duration in proportion: five people almost never finish a five-day task in one day, and some tasks cannot be split at all. Crashing has diminishing returns, so crash where you get the most days saved per unit of cost.
What happens to the critical path after compression?
It can change. Compressing one chain enough can make a different path the longest route to the finish, so further compression of the first chain stops helping. Always recalculate the critical path after each compression step.