Fast Tracking vs Crashing: Schedule Compression

When a project falls behind, most managers face the same two choices: run tasks in parallel or throw more resources at the problem. Those two moves have formal names in project management: fast tracking and crashing. Understanding the difference between fast tracking vs crashing is one of the most practical skills a project manager can develop, because choosing the wrong one can turn a minor delay into a costly rework spiral.

This guide walks through both techniques, compares them directly, and gives you a practical framework for deciding which to use.

What Are Fast Tracking and Crashing?

Fast tracking is a schedule compression technique where activities that were originally planned to happen sequentially are instead performed in parallel or with overlapping timelines. No extra budget is spent. Instead, you accept more coordination overhead and a higher chance of rework if the earlier task changes after the later one has already started.

Crashing is a schedule compression technique where you add resources to critical-path tasks to shorten their duration. This costs money. You might bring in extra contractors, approve overtime, rent additional equipment, or purchase faster services. The schedule shortens, but the budget rises.

Both techniques target the critical path specifically. Applying either one to tasks that have float (slack) won't shorten the project end date. You have to hit the tasks that, if delayed, delay the entire project.

Key Facts

• According to PMI's Pulse of the Profession report, 47% of projects fail to meet their original schedule goals, making schedule compression a recurring reality rather than an edge case.
• Research from the Project Management Institute shows that projects that identify their critical path before applying compression have a measurably higher success rate than those that apply resources broadly.
• PMI's PMBOK Guide identifies fast tracking and crashing as the two primary schedule compression techniques available when a project's early completion date is required or a delay needs to be recovered.

Fast Tracking vs Crashing: Side by Side

When to Use Each

Use fast tracking when:

• Budget is tight and adding resources is not an option.
• Two sequential tasks share only a soft dependency. For example, writing a report section while the preceding section is in final review, not still being drafted.
• The rework cost is low. If the upstream task changes and the downstream task needs minor adjustments, the time saved still justifies the overlap.
• The team has strong communication and can coordinate the handoffs in real time.

Use crashing when:

• The project has a hard contractual or regulatory deadline and the gap cannot be closed by sequencing alone.
• Budget reserves exist specifically for schedule recovery.
• Tasks on the critical path cannot be split or overlapped safely. Hardware manufacturing, regulatory reviews, and load testing often fall into this category.
• You've already exhausted fast tracking options.

One practical rule: try fast tracking first, since it costs less. If the compression achieved isn't enough, layer in crashing on whichever critical tasks show the best time-cost ratio.

Common Mistakes

Applying compression off the critical path. Speeding up a task with five days of float and slack does nothing for the end date. Before touching anything, identify the critical path using your network diagram.

Crashing beyond the point of diminishing returns. Adding a third person to a two-person task doesn't cut duration by a third. Communication overhead grows, and at some point the extra resource adds no benefit. Always calculate the crash cost-slope: how much does each day saved actually cost?

Fast tracking tasks with hard dependencies. Some tasks genuinely cannot start until the predecessor is 100% done. Pouring a concrete slab cannot start while the foundation is still being excavated. Forcing parallelism on hard dependencies doesn't compress the schedule; it creates defects.

Forgetting the triple constraint. Schedule compression always trades one constraint for another. Fast tracking trades time for risk. Crashing trades time for cost. Neither move is free.

Not re-baselining. Once you apply compression, the original schedule is no longer the plan. Update the Gantt chart, communicate the new critical path to the team, and update the cost baseline if crashing changed the budget.

How to Compress a Schedule

Step 1: Map the Critical Path

Use a network diagram to find every sequence of tasks with zero float from start to finish. Only tasks on this chain are candidates for compression.

Step 2: Evaluate Fast Tracking Options

Review each critical-path task pair. Ask: does the second task truly need the first to be 100% complete before starting? If not, estimate how much overlap is feasible and how much rework risk that introduces. List the candidate overlaps and the time each would save.

Step 3: Evaluate Crashing Options

For each critical-path task that can't be fast tracked, calculate the crash cost-slope:

Crash cost-slope = (Crash cost - Normal cost) / (Normal duration - Crash duration)

This tells you the cost per day saved. Rank tasks from lowest to highest crash cost-slope and crash the cheapest ones first.

Step 4: Apply the Best Mix

Combine fast tracking (where rework risk is acceptable) and crashing (where it isn't) to close the schedule gap at the lowest total cost. Check the project cost estimation for your budget headroom before committing.

Step 5: Re-Baseline and Monitor

Update the schedule, reset the critical path, and recalculate earned value management (EVM) baselines. Track rework hours if you fast tracked, and watch cost performance if you crashed.

Fast Tracking vs Crashing Example

Imagine a software product launch scheduled for 20 weeks. At week 8, an audit reveals the project is 3 weeks behind on critical-path tasks.

The team recovers 3.5 weeks against the 3-week gap. The UI overlap introduces some rework risk on the backend integration, but the team accepts that because the development lead can review integration points daily. The crashing on QA and deployment is paid from the project reserve fund.

Before making these decisions, use three-point estimation to stress-test the compressed durations against optimistic and pessimistic scenarios.

Best Practices

Document your decision logic. If a sponsor asks why the budget increased, you need a clear record showing: the gap, the options evaluated, the cost-slopes calculated, and the chosen path. Vague "we needed more resources" explanations erode trust.

Set clear fast-tracking handoff rules. If you're overlapping Task A and Task B, define the exact condition under which Task B can start. "Task A is 70% complete and the interface specification is frozen" is a clear trigger. "When A looks mostly done" is not.

Track rework separately. Fast tracking hides rework in normal task effort unless you call it out. Logging rework hours lets you evaluate whether the compression actually saved time net of rework.

Communicate compression to stakeholders. Team members working on overlapping tasks need to know the risk they're absorbing. Sponsors need to know if the budget is increasing. Silence creates surprises.

Consider the human cost. Crashing with overtime works for a sprint. It doesn't work for four consecutive months. Burnout will slow the project more than the original delay did.

Frequently Asked Questions

What is the main difference between fast tracking and crashing? Fast tracking compresses a schedule by overlapping tasks that were planned sequentially, adding rework risk but little cost. Crashing compresses a schedule by adding resources to critical-path tasks, which shortens duration but increases budget. Both target the critical path only.

Which technique is cheaper: fast tracking or crashing? Fast tracking is generally cheaper because it doesn't add resources. But if the overlap causes significant rework, the hidden cost can exceed what crashing would have cost. The right choice depends on the specific tasks, their dependency types, and how much rework is likely.

Can you use both fast tracking and crashing on the same project? Yes. Most project managers combine them. Fast track the tasks where overlap is safe, crash the tasks where it isn't. This hybrid approach closes larger schedule gaps at a lower cost than crashing alone.

Does fast tracking increase project risk? It does. Running tasks in parallel means later tasks may need to be revised if earlier tasks change. The risk is manageable when teams communicate well and the dependency is soft rather than hard.

What happens if crashing doesn't recover enough time? You've likely hit the crash limit: the point where adding more resources doesn't shorten the duration further. At that point, scope reduction (removing deliverables) or a negotiated deadline extension are the remaining options.

---

When a deadline is fixed and the schedule is slipping, fast tracking and crashing give you a structured way to respond. Map the critical path first, price out both options, and combine them where it makes sense. The teams that recover lost time without blowing the budget are usually the ones who treat these decisions as engineering problems, not panic moves.

Related Reading

• Critical Path Method
• Float and Slack in Project Scheduling
• Network Diagram
• Triple Constraint
• What Is a Gantt Chart?
• Three-Point Estimation
• Project Cost Estimation
• Earned Value Management (EVM)