The conversation about fast tracking vs crashing usually happens under pressure. The project is behind schedule, the client wants the original completion date, and someone in the room says “can we just add more people?” Someone else says “can we overlap some of these activities?” Both are valid questions — but they’re asking for different things, with different costs and different risks. Understanding which schedule compression technique to use, and when neither is appropriate, is one of the more practically useful things a project manager can know.
Table of Contents
Fast Tracking vs Crashing: What Are Schedule Compression Techniques?
Fast tracking and crashing are schedule compression techniques applied during the develop schedule process to shorten an already developed schedule. The purpose of schedule compression is to reduce project duration without changing the original project scope. If the project falls behind schedule, scope stays fixed, and the completion date is non-negotiable, compressing the remaining schedule is the only path forward.
Projects fall behind for all kinds of reasons — some genuinely unforeseen, many not. Schedule compression is also applied when stakeholders want to accelerate a project that’s on schedule, usually because finishing early has commercial value. The techniques are the same either way. This article focuses on fast tracking vs crashing, the two techniques that come up most often when the pressure is on.
One constraint applies to both techniques: they only work on activities on the critical path. Compressing an activity with float doesn’t shorten the project — it just increases the float on that activity. Before applying any schedule compression, identify the current critical path — which specific activities are actually driving the end date. Compressing something off the critical path wastes time and money and changes nothing.
What Is Fast Tracking?
As per the PMBOK Guide, fast tracking is a schedule compression technique in which activities or phases normally done in sequence are performed in parallel for at least a portion of their duration.
The figures below illustrate two activities. Activity A is the predecessor of Activity B. On the left, there is a Finish-to-Start relationship between them — Activity B starts after Activity A completes. Total duration: 10 days.
After applying fast tracking, there is a 3-day overlap between Activity A and Activity B. Total duration is now 7 days.
The first step in fast tracking is to analyze the project schedule and identify critical path activities — because activities with float don’t affect project duration regardless of how they’re sequenced. After identifying the critical path, the team changes network logic to allow activities to run in parallel instead of sequentially.
The critical constraint in fast tracking: the activities must actually be capable of overlapping. Some finish-to-start relationships exist because of genuine physical or technical dependency — you cannot pour concrete before the formwork is in place, you cannot test software before any code exists. These dependencies can’t be fast-tracked without creating defects or rework. The activities that can be fast-tracked are those where the FS relationship was set for convenience or planning conservatism rather than hard logic — testing beginning while the last development tasks are still running, design development overlapping with procurement for long-lead items.
Fast tracking is free in budget terms — the cost is in risk, not money. Parallel work means that if Activity A changes or encounters problems in the portion that overlaps with Activity B, rework on B is likely. The overlap that saved 3 days at planning can cost 8 days in rework during execution. This is why fast tracking is described as increasing risk — it trades schedule buffer for execution risk, and whether that trade is worth making depends on how well the predecessor activity is understood.
What Is Crashing?
As per the PMBOK Guide, crashing is a technique used to shorten the schedule duration for the least incremental cost by adding resources.
In crashing, the team assigns extra resources to critical path activities to reduce their duration. More resources on an activity means it finishes sooner — which shortens the critical path and the project end date. But extra resources cost money, and the relationship between resources and duration is not always linear.
The key word in the PMBOK definition is “least incremental cost.” Crashing isn’t just about adding resources — it’s about finding the most cost-efficient compression available. Not all activities crash at the same cost per day saved, and the correct approach is to crash in order of cost-slope: start with the activity that gives the most compression for the least additional cost, then move to the next, and so on until the target duration is reached or no further compression is available.
On a project I worked on — a commercial fit-out, 11 floors, city-centre office tower — we were 3 weeks behind at the halfway point, and the client’s position was non-negotiable: the tenants had a lease start date and were not moving it. The site manager’s first response was to throw bodies at it. “More joiners, more electricians, more of everything.” We pushed back on that and did the cost-slope analysis instead. Electrical rough-in and joinery installation had much lower crash costs than the other critical path activities; crashing those two first recovered 11 days. The remaining 10 days required flying in a specialist subcontractor from another city — expensive, and the team didn’t know the site, which caused its own headaches in the first week. We hit the date. The last three weeks were not enjoyable. And the honest version of the lesson is that we should have done this analysis at week four when the delay was first becoming visible, not week six when we finally couldn’t ignore it.
Crashing Cost-Slope: Which Activities to Crash First
Cost-slope is the cost per unit of time saved by crashing an activity. The formula:
Cost-slope = (Crash cost − Normal cost) ÷ (Normal duration − Crash duration)
An activity with normal cost $10,000, crash cost $16,000, normal duration 10 days, and crash duration 7 days has a cost-slope of ($16,000 − $10,000) ÷ (10 − 7) = $2,000 per day. Another activity with normal cost $8,000, crash cost $18,000, normal duration 8 days, and crash duration 5 days has a cost-slope of $3,333 per day. Crash the first activity before the second — you get the same day of compression for $1,333 less.
The process: list all critical path activities, calculate the cost-slope for each, rank them from lowest to highest, then crash in that order until the target duration is achieved. After each crash step, re-check the critical path — crashing one activity may shift the critical path to a different sequence, at which point you’re working with a new set of activities.
Every activity also has a crash limit — the minimum duration achievable regardless of how many resources are added. This is the “crash point.” Beyond the crash point, adding more resources doesn’t reduce duration further; it just adds cost. The nature of the work determines the crash point: some activities have hard limits based on physics, process, or sequential dependencies within the activity itself. A concrete cure time can’t be crashed regardless of resources. A document review can only go so fast regardless of how many reviewers you add.
Fast Tracking vs Crashing: Which to Use?
Project schedules and execution strategies change as projects progress. The choice between fast tracking vs crashing depends on several factors:
| Fast tracking | Crashing | |
|---|---|---|
| Cost impact | None directly | Increases cost |
| Risk impact | Increases rework risk | Coordination risk from added resources |
| When applicable | Activities with soft FS dependencies | Activities where resources reduce duration |
| Budget constraint | Preferred when budget is fixed | Requires available budget |
| Amount of compression | Limited by overlap feasibility | Limited by crash point of each activity |
In practice most recovery plans use both — fast-track whatever the logic genuinely allows, crash the rest if there’s budget for it. The order matters: fast tracking first because it’s free, crashing second because it costs money you may need elsewhere. Don’t use either on activities that aren’t driving the end date.
One thing the comparison tables in most guides don’t say: crashing is subject to diminishing returns in a way that goes beyond the crash point of individual activities. Adding a second crew to a task often doesn’t give you half the duration — coordination overhead, congestion, and handoff inefficiencies eat into the gain. Brooks’s Law (adding people to a late software project makes it later) is an extreme version of this, but the underlying principle — that more resources don’t translate linearly into less time — applies to most project work. Build that into the crash duration estimate, not just the cost estimate.
The Limits of Schedule Compression
Fast tracking is limited by how many critical path activities have soft dependencies that actually allow overlap — on a realistic schedule, often two or three at most. Crashing is limited by crash points and budget. When you’ve exhausted both, the honest conversation is about scope or deadline, not technique. A project manager who tells the client “we’ll find a way” when the math doesn’t support it is just deferring a worse conversation to a later date.
Schedule compression techniques are useful for recovering manageable slippage. They are not a substitute for a realistic original schedule, and they can’t fix a project that was never going to finish on time.
When Neither Schedule Compression Technique Is the Right Answer
There are situations where both fast tracking and crashing should be declined even when they’re technically available. If a project is behind because of a fundamental execution problem — poor quality causing systematic rework, a key subcontractor underperforming, a design that keeps changing — compression doesn’t fix the underlying issue. Fast tracking into a design that’s still unstable creates rework. Crashing onto an underperforming contractor just costs more money for the same output.
I’ve watched project managers apply compression in these situations because it feels like doing something. The schedule shows green for a few weeks. Then the underlying problem reasserts itself and you’re back where you started, except now you’ve spent the budget that would have given you options later. It’s one of the more frustrating patterns in project management to observe — the technique being used correctly in a technical sense, applied to the wrong problem.
Similarly, if the project is behind because the original schedule had no realistic float, compression may recover a week or two but leaves nothing in reserve. Know when to save these options. A project manager who burns all available fast tracking and crashing in month three arrives at the final phase with no tools left and a client who’s been told twice already that the project is “back on track.”
Irma Gilda is chief executive of Sonic Training and Consultancy Co., the training platform offers project planning and scheduling More than 60 k learners have used the platform to attain professional success. Irma is a professional Primavera P6 Trainer.
It shold be “In Crashing technique” instead of “In Fast Tracking technique” under relevant picture