Schedule Compression: Crashing vs Fast-Tracking (and When Each Backfires)

The deadline moved left. Scope did not. This is the conversation almost every PM has at some point in a project's life, usually delivered by a sponsor who found out about a market window, a regulatory date, or a competitor's launch after the schedule was already baselined. Schedule compression is the answer to that conversation, and the fastest way to get it wrong is reaching for the first lever available without understanding what it actually costs.

There are exactly two legitimate schedule compression techniques that don't cut scope: crashing (add resources to shorten task durations) and fast-tracking (overlap tasks that were sequential). Both work. Both have a specific failure mode that shows up only after the decision is already made, which is exactly when it's expensive to reverse.

TL;DR. Schedule compression means crashing or fast-tracking, and only tasks on the critical path shorten the project when compressed. Crashing adds resources to a critical task, which usually costs money but doesn't change the logic of the schedule; it hits diminishing returns once the cheapest capacity is used up and once parallel paths converge. Fast-tracking overlaps tasks that were sequential, usually without adding cost, but increases the risk that the downstream task has to be reworked once the upstream task's output changes. Most real compression efforts combine both: crash the tasks where added resources are cheap, fast-track the dependencies that were more flexible than a strict finish-to-start relationship required.

What Schedule Compression Actually Means

Schedule compression only works on tasks that sit on the critical path, the longest sequence of dependent tasks that sets the project's minimum duration, as covered in the critical path method. Shortening a task that isn't on the critical path doesn't move the finish date at all; it just gives that task more float than it already had. This is the first mistake in most failed compression attempts: someone speeds up a task because it feels urgent, not because the schedule math says it's the one holding the finish date hostage.

Once you've confirmed a task is actually on the critical path, there are two ways to shorten it. Crashing changes how much gets thrown at the task: more people, more equipment, more overtime, so the same work finishes faster. Fast-tracking changes when the task starts relative to its predecessor: instead of waiting for the predecessor to fully finish, the successor starts before that, overlapping work that used to be strictly sequential. Both compress the schedule. Neither is free, and the price each one charges is different enough that picking the wrong one for a given task backfires in a specific, predictable way.

Crashing: Buying Time by Adding Resources

Crashing takes a critical path task and reduces its duration by adding resources: a second developer on a coding task, a second crew on a construction task, expedited shipping instead of standard freight, mandatory overtime instead of a standard workweek. The logical order of the schedule doesn't change; the task still starts after the same predecessors and still feeds the same successors. It just finishes faster because more capacity was thrown at it.

The tradeoff is cost, and it's usually real cost, not hypothetical: a contractor's day rate, an overtime premium, an expedited shipping fee. Crashing is the compression technique to reach for when the schedule has real money behind it and the sponsor would rather pay than slip, which is common for launch-date-driven work, contractual penalty clauses, or anything with a hard external deadline.

Fast-Tracking: Buying Time by Overlapping Work

Fast-tracking takes two tasks with a Finish-to-Start dependency, where the second waits for the first to fully complete, and changes the relationship so the second starts before the first is fully done. Instead of API development finishing 100 percent before integration testing begins, testing starts once development is substantially complete, at 75 percent, for example, with a Start-to-Start relationship and an appropriate lag.

The tradeoff is coordination risk, not direct cost. If the upstream task's output is still changing when the downstream task starts consuming it, whatever the downstream task builds against that early, incomplete output may need rework once the upstream task's final version diverges from what was assumed. Fast-tracking is the compression technique to reach for when the dependency between two tasks is genuinely looser than a strict sequential relationship implies, and when the team can tolerate redoing some downstream work if the overlap doesn't pan out cleanly.

Why Crashing Hits Diminishing Returns

The diagram above shows the classic shape of a crash cost curve. The first day or two of compression is usually cheap, existing staff absorb modest overtime, or a task had headroom nobody had used yet. The next few days cost more, because the easy capacity is gone and the remaining options mean paying for a contractor or a rush order. The last days are the most expensive by far: weekend premiums, emergency staffing, expedited freight, or a second shift, each priced at a multiple of standard cost.

This curve is also why crashing a single critical path task only works until parallel paths converge. If a critical task has 3 days of margin over the next-longest parallel path, crashing that task by up to 3 days shortens the project one day for each day crashed. Crash a fourth day and the project doesn't get any shorter, because the parallel path is now just as long; both paths are critical, and further compression means crashing tasks on both paths at once, not just the one that used to be the sole bottleneck. This is the mechanism behind the well-known rule that only critical path tasks are worth crashing: the moment your crashing catches the schedule up to a second path, the easy, cheap phase of compression is over.

Why Fast-Tracking Creates Rework Risk

Fast-tracking's cost shows up later and less predictably than crashing's, which is what makes it easy to underestimate. Overlapping integration testing with the last quarter of development doesn't cost anything on the day you make the decision. It costs something on the day the API changes during that last 25 percent of development and the tests already written against the earlier version have to be redone.

The risk is proportional to how much the upstream task's output is still likely to change. A task that's genuinely 90 percent stable by the 75 percent completion mark, most of the remaining work is polish, not architecture, is a reasonable fast-tracking candidate. A task where the hardest, most uncertain decisions are still unresolved at 75 percent is a poor candidate; the overlap window is exactly when the downstream task will build on the exact thing most likely to still change. Judge fast-tracking candidates by how settled the interface is, not by how much of the task's duration has elapsed.

Crashing vs Fast-Tracking: A Side-by-Side Comparison

Dimension	Crashing	Fast-Tracking
Mechanism	Add resources to shorten a task's duration	Overlap tasks that were sequential
Primary cost	Direct: overtime, contractors, expedited shipping	Indirect: rework risk if upstream output changes
Changes task logic?	No, dependencies stay the same	Yes, a Finish-to-Start relationship becomes Start-to-Start or gains negative lag
Diminishing returns?	Yes, sharply, as cheap capacity runs out and paths converge	Less predictable; risk compounds rather than cost rising steadily
Best used on	Tasks with real budget behind the deadline	Tasks with a looser dependency than the schedule assumed
Reversibility if it doesn't work	Easy: stop paying for the extra resource	Hard: rework already happened, or is already baked in
Typical sponsor reaction	"How much will that cost?"	"Why didn't we just do this from the start?"
Risk to quality	Low, if capacity added is competent	Higher, if the overlap forces decisions before information is ready

Neither technique is inherently better. The comparison exists to make the tradeoff visible per task, not to pick a house favorite. A single compression effort routinely uses both: crash the tasks with cheap, available capacity, and fast-track the dependencies that turn out to be looser than the original schedule assumed.

A Worked Example: Compressing a 26-Day Critical Path

Take the same schedule from the critical path method guide: tasks A through H, with the critical path A → B → D → F → G → H running 26 days, and a parallel path A → C → E → F running 3 days shorter, which is why C and E each carry 3 days of float. The sponsor needs the project done in 20 days, a 6-day compression.

1. Crash Task D first, because it's the sole reason the critical path is 3 days longer than the parallel path. Adding a second developer cuts D from 8 days to 5 days, at a real but affordable cost. The critical path drops from 26 to 23 days, a clean 1-for-1 saving, because the 3 days crashed exactly matches the 3-day margin D held over the parallel path.
2. Recognize that both paths are now tied at 23 days, which ends the cheap phase of crashing. Crashing D further no longer shortens the project alone; the parallel path through C and E is now equally long, so both would need to compress together to gain another day the same way.
3. Look downstream of the merge point for tasks that are still cheap to crash. Tasks F, G, and H sit on the single combined path after the two branches rejoin, so crashing them doesn't require touching both upstream branches at once. Crashing G (user acceptance testing) from 3 days to 2 days, by adding a second QA reviewer, saves another day at low cost: 23 to 22 days.
4. Fast-track the remaining gap instead of continuing to crash. Deployment prep (H) doesn't strictly need G to be 100 percent complete before it starts; a Start-to-Start relationship with a 1-day lag lets deployment prep begin while the last acceptance tests wrap up. That overlap saves a further day: 22 to 21 days.
5. Close the final day with a small, targeted crash rather than another overlap. One day of weekend work on the last mile of deployment, paid at premium rates because it's the last lever left, brings the schedule to the sponsor's 20-day target.

Six days compressed, using two crashes and one fast-track, in that order, cheapest and lowest-risk options first. Compressing this same schedule by reaching for a fast-track on Task D-E (the earliest, least-settled work in the project) instead would have carried the highest rework risk for the least certain payoff. Sequencing the levers, not just picking one, is most of the skill here.

How Do You Decide Which Lever to Pull?

1. Confirm the task is actually on the critical path before doing anything to it. Compressing a task with float wastes effort and, for fast-tracking, adds risk for zero schedule benefit.
2. Check whether cheap crash capacity exists for that specific task. Existing staff with headroom, equipment already available, a vendor with slack capacity, these are cheap. A cold-start hire or expedited freight are not; save those for the deadline you can't miss any other way.
3. Check whether the dependency into that task is genuinely a hard Finish-to-Start, or just modeled that way out of habit. Many schedules default every dependency to Finish-to-Start even when the real-world relationship tolerates overlap. That's free fast-tracking hiding in an over-conservative schedule.
4. Rank candidate compressions by cost per day for crashing and by rework risk for fast-tracking, then take the cheapest, lowest-risk options first. Diminishing returns mean the order matters as much as the total amount compressed.
5. Re-run the critical path calculation after each change. Crashing or fast-tracking a task can shift which path is critical, exactly as it did in the worked example above, and the next cheapest lever depends on knowing the current critical path, not the original one. If the compressed schedule still carries real duration uncertainty on the tasks you didn't touch, a Monte Carlo simulation of the new network will show whether the compression actually bought the confidence the sponsor thinks it did, or just moved the median date without shrinking the risk.
6. Tell the sponsor what each unit of compression actually costs, in dollars for crashing and in risk for fast-tracking, before committing. A schedule compression technique chosen without that conversation tends to surface its real cost later, in a change order or a rework cycle, when it's harder to have the conversation calmly.

Verify the critical path before you spend a dollar compressing the wrong task The free Schedule Health Check computes the real critical path from your .mpp or MSPDI file's actual dependency graph, so you can confirm which tasks are worth crashing or fast-tracking before committing budget or risk to the wrong one. → Run the Schedule Health Check

Microsoft Project Online™ is a trademark of Microsoft Corporation. Onplana is not affiliated with Microsoft.