Schedule Compression Without Self-Sabotage: Crashing and Fast-Tracking Done Right
When a deadline starts slipping, the instinct is to push harder: add people, start tasks in parallel, work the weekends. In project management this falls under schedule compression, and it comes in two recognized forms. Crashing means adding resources to critical-path activities to finish them faster, usually at extra cost. Fast-tracking means running activities in parallel that were planned in sequence, which adds risk and rework. Both are legitimate techniques. Both are routinely botched.
In early 2022, the pressure to compress is unusually high. Material lead times are unpredictable, skilled labour is hard to keep, and budgets are squeezed by inflation. That mix tempts teams to compress reflexively rather than deliberately. The result is a schedule that looks shorter on paper and runs longer in practice. The good news is that the failures are predictable, which means they are avoidable.
The mistakes that quietly cost you
Compressing tasks that aren't on the critical path. Spending money or taking on risk to speed up an activity with float buys you nothing. Only compression on the critical path moves the finish date. Confirm the path first, and re-confirm it after every change, because compression can shift the critical path to a route you weren't watching.
Assuming added people equals added speed. Crashing has diminishing returns. The fifth person on a task often slows the first four through coordination, onboarding, and crowding. Some work simply cannot be parallelized no matter how many hands you add.
Fast-tracking work with hard dependencies. Overlapping a design activity with the construction it feeds almost guarantees rework when the design changes. Fast-track only where the dependency is soft or partial, and accept that you are buying time with risk.
Ignoring the cost and quality trade-off. Crashing raises cost; fast-tracking raises risk and rework. If you compress without pricing the trade-off, you are simply hiding the bill until later, when it lands as overtime, defects, or a blown contingency.
Not refreshing the plan after compressing. A compressed plan is a new plan. If the baseline, resource assignments, and risk register don't reflect the change, your reporting drifts from reality and the next decision is made on bad data.
How to compress on purpose
Start with the network, not the calendar. Identify the true critical path and the activities with the steepest cost-per-day-saved when crashed; compress those first, in small increments, checking after each step whether the critical path has moved. For fast-tracking, map the dependencies honestly and overlap only where a partial handoff is genuinely workable, then add a buffer for the rework you are knowingly inviting.
Quantify the trade-off before you act: how many days saved, at what added cost or risk.
Compress in the smallest useful increment, then re-evaluate the path.
Protect quality gates rather than deleting them to save days.
Update the baseline, resource plan, and risks so the schedule stays honest.
Tell sponsors what compression bought and what it cost, in the same breath.
Done this way, compression becomes a controlled lever rather than a panic move. You will sometimes find the deadline simply cannot be met within acceptable cost and risk, and saying so early is worth far more than discovering it at the end. A short, defensible schedule beats an optimistic one that quietly unravels.
If a key project is under deadline pressure and you want compression decisions grounded in evidence rather than optimism, XNM's program & project delivery advisory can help you find the safest, lowest-cost way to bring it in.