Fast Tracking vs. Crashing: Which Schedule Compression Technique Fits?
admino
Fast Tracking vs. Crashing: Which Schedule Compression Technique Fits?
Accept more risk or spend more resources?
A project must finish earlier than the current schedule allows.
The sponsor asks the project manager to compress the schedule.
What should happen next?
Should the PM:
- overlap activities,
- add resources,
- authorize overtime,
- accelerate selected work,
- or revise the sequence?
This is where PMP® scenarios often test whether you understand the difference between fast tracking and crashing.
But the real question is not simply:
“Which technique should I use?”
It is:
“What actually controls the finish date, and which compression method can realistically shorten it?”
A useful Project Reasoning Lab principle is:
Schedule compression only matters if it affects the work controlling the project finish date.
1. Start With the Critical Path
Before fast-tracking or crashing anything, determine what drives the completion date.
Why?
Because shortening a non-critical activity may not improve the project finish date.
Suppose:
Activity A can be shortened by three days, but it has five days of available float.
Compressing it may consume float.
The project may still finish on exactly the same date.
So the first question is:
Which activities are actually controlling the finish date?
That usually means focusing on the critical path or other schedule constraints that are determining completion.
After compression, you should recalculate the schedule because the critical path can change.
Do not compress an activity just because it can be shortened. Compress work that actually matters to the finish date.
2. What Is Fast Tracking?
Fast tracking shortens the schedule by performing activities or portions of activities in parallel that would normally occur sequentially.
For example:
Original sequence
Design complete → Development begins
Fast-tracked sequence
Part of design complete → Development begins → Remaining design continues
The project gains time because work begins earlier.
But the trade-off is greater uncertainty.
Fast tracking can increase:
- coordination complexity,
- rework,
- dependency risk,
- communication demands,
- technical uncertainty.
A strong distinction is:
Fast tracking changes when work happens.
And:
Fast tracking gains time by overlapping work, usually at the cost of greater coordination and rework risk.
3. When Does Fast Tracking Fit?
Consider:
Development normally begins only after the entire design is complete, but several design components are already stable enough for development to begin early.
Fast tracking may be possible.
Before doing it, ask:
- Can the activities actually overlap?
- Are the dependencies flexible?
- Is enough information available?
- What happens if earlier work changes?
- Is the increased risk acceptable?
The key is feasibility.
Fast tracking does not mean ignoring dependencies. It means changing sequencing where overlap is realistically possible.
4. What Is Crashing?
Crashing attempts to shorten the schedule by applying additional resources or cost to activities where additional investment can actually reduce duration.
Examples may include:
- adding qualified resources,
- using overtime,
- adding equipment,
- paying for expedited services,
- using additional specialist capacity.
The central idea is:
Crashing changes what is applied to the work.
And:
Crashing gains time by applying additional resources or cost where those resources can genuinely reduce duration.
That final phrase matters.
Because adding resources does not automatically make an activity faster.
5. More Resources Do Not Automatically Mean Faster Work
Suppose:
A technical task is performed by one highly specialized engineer and cannot easily be divided.
Adding three more people may not shorten the task.
It could even slow the work if the specialist must spend time:
- training them,
- coordinating them,
- reviewing additional work,
- correcting errors.
Crashing may also fail when:
- the work is inherently sequential,
- specialist expertise is scarce,
- physical constraints limit concurrency,
- additional resources require significant onboarding,
- communication overhead increases.
A useful principle is:
Crashing works only when added resources can actually reduce the duration of the relevant activity.
6. Fast Tracking vs. Crashing
The distinction can be summarized:
| Question | Fast Tracking | Crashing |
|---|---|---|
| How is time gained? | Overlap activities | Add resources or cost |
| What changes? | Sequence/timing | Resource or cost input |
| Main trade-off | Greater coordination/rework risk | Greater cost/resource exposure |
| Additional budget required? | Not necessarily | Often |
| Requires overlap feasibility? | Yes | No |
| Requires compressible activity? | Yes | Yes |
| Guarantees schedule recovery? | No | No |
A useful Project Reasoning Lab line is:
Fast tracking changes when the work happens. Crashing changes what is applied to the work.
7. Scenario Comparison: Which Technique Fits?
Consider:
A critical-path activity normally begins only after another activity is complete, but part of the predecessor output will be stable two weeks earlier than planned.
If the work can safely overlap, fast tracking may be worth evaluating.
Now consider:
A critical-path activity can be shortened from ten days to seven by adding a second qualified team.
Crashing may be worth evaluating.
The correct question is not:
“Which technique is better?”
It is:
“Which technique fits the structure of this specific work?”
8. Crashing Should Consider Time Gained vs. Incremental Cost
Suppose two critical activities can be crashed.
Activity A
- Cost to crash: $20,000
- Time saved: 2 days
Activity B
- Cost to crash: $10,000
- Time saved: 3 days
All else equal, Activity B may offer a more attractive schedule reduction for the incremental cost.
The PM should compare:
- time gained,
- incremental cost,
- feasibility,
- risk,
- downstream consequences.
The goal is not simply to spend money.
It is to spend where schedule reduction is meaningful.
If several activities can be crashed, prioritize schedule reduction that provides useful time savings at acceptable incremental cost.
9. When Neither Technique Works
This is an important possibility.
Suppose:
- critical activities cannot overlap,
- additional resources will not reduce duration,
- required schedule reduction exceeds realistic compression.
Then neither fast-tracking nor crashing may solve the problem.
The PM may need to reassess:
- deadline expectations,
- scope,
- priorities,
- constraints,
- sequencing,
- governance decisions.
A strong principle is:
A deadline does not make impossible compression feasible.
Schedule compression has practical limits.
10. Fast Tracking and Crashing Can Be Used Together
The choice is not always either/or.
A project may:
- fast-track some critical activities,
- crash others,
- recalculate the schedule,
- reassess cost and risk,
- continue compression where appropriate.
For example:
Development begins early using stable portions of the design while an additional qualified testing team is added later.
That uses both techniques.
So:
Different activities may support different compression strategies.
11. Recalculate After Compression
Schedule compression should not be treated as a one-time action.
After changing sequencing or duration:
- update the schedule,
- recalculate the critical path,
- check whether another path has become critical,
- reassess risk,
- verify the new completion date.
Why?
Because shortening one critical activity can cause another path to become the new constraint.
A strong Project Reasoning Lab principle is:
Schedule compression is iterative. Shortening one activity can change what controls the project next.
12. Five-Question Schedule Compression Test
When a PMP scenario asks whether to fast-track or crash, ask:
1. What is driving the completion date?
Identify the critical path or other controlling constraint.
2. Can relevant activities overlap?
If yes, fast tracking may be feasible.
3. Can additional resources actually reduce duration?
If yes, crashing may be feasible.
4. Which trade-off is acceptable?
Compare:
- risk,
- rework,
- cost,
- resource availability,
- coordination complexity.
5. Does the revised schedule actually finish earlier?
Recalculate.
The logic becomes:
Critical Path → Feasibility → Trade-Off → Compress → Recalculate
13. Three Common PMP Traps
Trap 1: Project Is Late = Fast Track
No.
Activities must actually be capable of overlapping.
Trap 2: Project Is Late = Add More People
No.
Additional resources must actually reduce duration.
Trap 3: Shorten Any Activity = Shorten the Project
No.
If the activity does not affect the finish date, shortening it may provide no project-level schedule benefit.
Final Takeaway
When a project needs to finish earlier, do not jump immediately to:
“Fast track.”
or:
“Add more resources.”
First ask:
What controls the finish date?
Can relevant activities overlap?
Can added resources genuinely reduce duration?
Which risk or cost trade-off is acceptable?
Does the revised schedule actually finish earlier?
Then choose the compression approach that fits the work.
Fast tracking gains time by changing sequencing and accepting greater coordination or rework risk. Crashing gains time by applying additional resources or cost where doing so can actually reduce duration.
And the broader principle is:
Compress only the work that actually controls the finish date, using a technique that is feasible and whose trade-offs the project can accept.
