Schedule compression is the process of shortening a project's timeline without reducing its scope. There are exactly two techniques defined in PMBOK: Crashing — adding resources (people, budget, equipment) to critical path tasks to complete them faster; and Fast Tracking — performing tasks in parallel that were originally planned in sequence. Crashing increases cost but keeps risk low. Fast tracking increases risk but costs nothing extra. You identify which technique to use based on whether you have budget available and how much rework risk your project can tolerate.
2
PMBOK-defined schedule compression techniques
Critical path
Only tasks here can actually compress the schedule
Cost ↑
Crashing always trades time for money
Risk ↑
Fast tracking always trades time for rework risk
Every project manager faces it eventually: a stakeholder walks in and says "we need this done three weeks earlier." The scope hasn't changed. The resources haven't changed. But the deadline has moved — and it's your problem to solve.
This is exactly what schedule compression techniques exist for. Defined formally in the PMBOK Guide as part of the Schedule Management knowledge area, these are structured methods for reducing your project duration without cutting deliverables or quality. Used correctly, they give you a legitimate, defensible way to recover lost time. Used incorrectly, they can spike your costs or introduce rework that makes things worse.
This guide covers both PMBOK techniques in full depth — crashing and fast tracking — with a worked numerical example, a decision framework for choosing between them, and the risks most project managers underestimate.
📌
Where this fits in PMBOK: Schedule compression is part of the Control Schedule process within the Schedule Management knowledge area. It is applied when a schedule variance (SV) is negative — meaning the project is behind plan — or when an externally imposed deadline requires the original plan to be shortened. Understanding it is also essential for the PMP exam, where crashing and fast tracking scenario questions appear regularly across all three ECO domains.
01 — Foundation
What Is Schedule Compression in Project Management?
Schedule compression is a technique for shortening the project schedule duration without reducing the project scope. The PMBOK Guide defines it within the Develop Schedule and Control Schedule processes — you may use it during initial planning or later when monitoring reveals a schedule variance that needs correction.
The key constraint schedule compression works within is the critical path. The critical path is the longest sequence of dependent tasks that determines the minimum possible project duration. Any task that is not on the critical path has float — spare time that means compressing it will not change the overall end date. Schedule compression only works when applied to critical path tasks.
Compressing a non-critical-path task is one of the most common and costly mistakes junior project managers make — they burn budget or introduce risk on tasks that don't actually move the finish date.
🔗
Before you compress, identify your critical path. Use our free critical path calculator to determine which tasks have zero float and are therefore your compression targets. Applying crashing or fast tracking to tasks with float wastes resources and achieves nothing. See also the Critical Path Method guide for a full explanation of forward pass, backward pass and float calculations.
02 — The Two Techniques
Crashing vs Fast Tracking — The Two PMBOK Schedule Compression Techniques
PMBOK defines exactly two schedule compression techniques. Every other method you might encounter — scope reduction, technology acceleration, resource reallocation — either falls under one of these two categories or is technically scope reduction (which is not compression). Understanding the difference is foundational for both real project management and PMP exam questions.
💰 Crashing
Definition: Adding resources to critical path activities to complete them in less time.
Resources added can include:
Additional people (overtime or new hires)
Additional equipment or technology
Outsourcing work to a specialist contractor
Paying for premium-speed material delivery
Trade-off: Crashing always increases cost. It never reduces cost. The question is whether the cost increase is worth the time saved.
⚡ Fast Tracking
Definition: Performing activities in parallel that were originally planned in sequence.
Examples include:
Starting construction before full design is complete
Beginning testing before all development is finished
Starting procurement before scope is fully baselined
Running user training in parallel with UAT
Trade-off: Fast tracking always increases risk of rework. Rework is the hidden cost — if the parallel work turns out to be wrong, you redo it.
03 — Crashing in Depth
Crashing — How It Works and When to Use It
Crashing (also called resource crashing or cost crashing) means adding resources to shorten duration. It is the most controllable form of schedule compression because the outcome is more predictable — add a resource, get measurable time reduction — at a known cost.
The Crash Cost per Day Formula
Crashing is a financial decision. Before you crash a task, you calculate the crash cost per day — how much it costs to buy each additional day of time savings:
Crash Cost Formula
Crash Cost per Day = (Crash Cost − Normal Cost) ÷ (Normal Duration − Crash Duration)
Term
Definition
Example Value
Crash Cost
Total cost of the task after adding resources
£18,000
Normal Cost
Original planned cost of the task
£12,000
Normal Duration
Original planned duration in days
10 days
Crash Duration
Shortest possible duration with added resources
7 days
Crash Cost per Day
(£18,000 − £12,000) ÷ (10 − 7) = £2,000/day
£2,000
This tells you: buying each day of time reduction on this task costs £2,000. If you need to save 3 days, you spend £6,000 extra. Compare this crash cost per day across all crashable critical path tasks and crash the cheapest ones first.
The Optimal Crashing Rule
When multiple critical path tasks are crashable, always crash in order of ascending crash cost per day. This gives you the maximum schedule reduction for the minimum additional spend. Stop crashing when either:
You have recovered the required time
A parallel path becomes the new critical path (further crashing this path does nothing)
The crash cost per day exceeds what the time saving is worth to the business
⚠️
Brooks' Law applies: Adding people to a late software project makes it later. This is because new team members require onboarding, communication overhead increases with team size, and work often cannot be divided infinitely. Crashing has limits — beyond a certain point, adding more resources produces diminishing returns or negative returns. Always calculate the crash duration limit before assuming more resources always equals faster delivery.
When Crashing Is the Right Choice
You have available budget to spend on the time saving
The cost of delay (penalties, lost revenue, opportunity cost) exceeds the crash cost
The parallel work in fast tracking carries unacceptable rework risk
The tasks involved are resource-constrained, not technically constrained (i.e. more people genuinely helps)
04 — Fast Tracking in Depth
Fast Tracking — How It Works and When to Use It
Fast tracking means overlapping activities that were planned to run sequentially. Instead of finishing Task A completely before starting Task B, you begin Task B while Task A is still in progress. The schedule gets shorter — but the dependency between A and B means there is now a risk that B has to be redone if A changes.
The Core Risk: Rework
The reason tasks were sequenced in the first place is that B depends on the output of A. When you fast track, you start B on the basis of partial or preliminary outputs from A. If those preliminary outputs change — and they often do — you rework part of B. In some cases, the rework costs more than the time saved.
Example: A software team fast tracks testing by starting test case design before development is complete. When a core architectural decision changes late in development, 60% of the test cases need to be rewritten. The team has saved two weeks on the schedule but spent three weeks on rework — a net loss.
Fast Tracking Is Not Always Possible
Some task dependencies are mandatory (hard logic) — they cannot be overlapped regardless of risk tolerance:
A building's foundation must be complete before the frame is erected — this is physics, not a planning choice
A software deployment cannot happen before the code is written and tested
A contract cannot be signed before it is drafted and legally reviewed
Fast tracking only works on tasks with discretionary (soft logic) dependencies — sequences that were chosen for convenience or best practice, not because of a physical or technical requirement.
When Fast Tracking Is the Right Choice
You have no additional budget for crashing
The dependency between the parallel tasks is discretionary, not mandatory
The rework risk is manageable — partial outputs of Task A are unlikely to change significantly
You have strong communication channels to coordinate the parallel workstreams
The deliverable from Task A is stable enough to base Task B work on
05 — Worked Example
Schedule Compression Worked Example — With Real Numbers
Here is a realistic worked example showing how to choose between crashing and fast tracking. The project is a software implementation with a 12-week schedule. The project sponsor has asked for delivery in 10 weeks — you need to recover 2 weeks (10 working days).
Critical Path Tasks (only these affect the end date)
Task
Normal Duration
Normal Cost
Crash Duration
Crash Cost
Cost/Day Saved
A — Requirements Analysis
15 days
£8,000
12 days
£12,500
£1,500/day
B — System Design
10 days
£6,000
8 days
£9,500
£1,750/day
C — Development
25 days
£40,000
20 days
£55,000
£3,000/day
D — User Acceptance Testing
10 days
£5,000
8 days
£8,500
£1,750/day
Fast Tracking Options
Option
Tasks Overlapped
Days Saved
Additional Cost
Rework Risk
FT-1: Start Design during Requirements
A + B overlap by 5 days
5 days
£0
Medium — design may need revision if requirements change late
FT-2: Start Dev during Design
B + C overlap by 3 days
3 days
£0
High — development rework if design changes
Decision: How to Save 10 Days
Option
Days Recovered
Extra Cost
Risk Level
Verdict
Crash Tasks A + B only
5 days
£6,250
Low
Not enough — only 5 days recovered
Fast Track FT-1 + Crash Task A
8 days
£4,500
Medium
Close but not quite 10 days
Fast Track FT-1 + Crash Tasks A + B
10 days ✓
£8,750
Medium
Recommended — 10 days recovered at manageable risk
Crash Development (Task C) only
10 days
£30,000
Low
Too expensive — 3x the cost of the hybrid option
Recommendation: Use Fast Tracking Option FT-1 (overlap Requirements and Design by 5 days — medium risk, manageable) combined with Crashing Tasks A and B (5 days recovered at £8,750 additional cost). Total savings: 10 days. Total extra cost: £8,750. Accept the medium rework risk on Design by ensuring Requirements sign-off milestones are tightly managed.
06 — Decision Framework
How to Choose Between Crashing and Fast Tracking
In practice, the choice between crashing and fast tracking — or combining both — comes down to three factors: budget availability, rework risk tolerance and dependency type. Use this decision framework to guide your choice.
Use Crashing
You have available budget and the delay cost exceeds the crash cost
If missing the deadline costs more than crashing costs — contract penalties, lost revenue, SLA breach — crashing is the financially rational choice even if expensive.
Use Crashing
The rework risk in fast tracking is unacceptably high
On high-complexity technical projects or safety-critical systems, the rework from overlapping dependent tasks can cascade into far more time lost than was saved.
Use Fast Tracking
You have no additional budget to crash with
Fast tracking is the zero-additional-cost option. If the project is already at budget ceiling, it is the only compression tool available — provided the dependency is discretionary.
Use Fast Tracking
The overlapping tasks have a stable, discretionary dependency and low rework probability
If Task A's outputs are unlikely to change once B begins — or B can tolerate working from preliminary outputs — fast tracking is low risk and costs nothing extra.
Use Both
You need large time savings and have partial budget available
Most real-world schedule recovery uses a combination — fast track the lower-risk task overlaps for free, then crash the cheapest critical path tasks to make up the remaining gap.
Neither Works
All dependencies are mandatory AND you have no budget to crash
If technical constraints prevent fast tracking and there is no budget to crash, the only remaining options are scope reduction (removing deliverables) or negotiating a revised deadline — neither of which is schedule compression.
07 — Risk Comparison
Crashing vs Fast Tracking — Full Risk and Trade-Off Comparison
Factor
Crashing
Fast Tracking
Impact on cost
Always increases — crash cost must be calculated and approved
No direct increase — rework is the hidden cost
Impact on risk
Low to moderate — resource management risk only
Always increases — rework and coordination risk
Impact on scope
None — scope is preserved
None — scope is preserved
Impact on quality
Moderate risk — rushed new resources may produce lower quality
Higher risk — parallel work based on incomplete inputs
Budget required
Yes — crash cost must be available
No — only rework cost if parallel work goes wrong
Communication overhead
Moderate — new resources need onboarding and coordination
High — parallel workstreams require tight daily coordination
Dependency type required
Works on any task type — mandatory or discretionary
Only works on discretionary dependencies
Predictability of outcome
High — cost and time savings are calculable in advance
Lower — rework probability is an estimate, not a certainty
Often no — if no budget impact, may be within PM authority
Best project environment
Projects with firm deadlines, budget flexibility and low rework tolerance
Projects with hard budget constraints, discretionary dependencies and experienced teams
08 — Process
How to Apply Schedule Compression — Step by Step
1
Identify your critical path
Use forward pass and backward pass calculations (or the critical path calculator) to find every task with zero float. These are the only tasks you can compress. Compressing tasks with float wastes resources. Record each critical path task with its duration, cost, predecessors and resource assignments.
2
Calculate how many days you need to recover
Subtract the required end date from the planned end date to get your compression target in working days. This is the number you need to eliminate from the critical path. Be precise — compressing more than needed wastes money and risk.
3
Assess each critical path task for fast tracking potential
For each consecutive pair of critical path tasks, ask: is this dependency mandatory (physical or technical) or discretionary (chosen for convenience)? If discretionary, how much overlap is feasible, and what is the rework risk if the predecessor's outputs change? Document the days saved and the rework probability for each fast tracking option.
4
Calculate crash cost per day for each critical path task
For each critical path task where resources can be added, calculate: Crash Cost per Day = (Crash Cost − Normal Cost) ÷ (Normal Duration − Crash Duration). Rank all crashable tasks from lowest to highest crash cost per day. This is your crashing priority order.
5
Build a compression plan combining both techniques
Start with the cheapest combination of fast tracking options (sorted by rework risk, lowest first) and crashing options (sorted by crash cost per day, lowest first). Build a plan that recovers the required days at minimum cost and risk. Check that your compression plan does not create a new critical path elsewhere in the network.
6
Raise a change request if cost increases
Any crashing that increases the project budget requires a formal change request through your change control process. Fast tracking with no budget impact may be within your delegated PM authority — check your project governance framework. Document the decision either way, including the risks accepted.
7
Update the schedule baseline and communicate
Once approved, update your project schedule with the revised task durations, resource assignments and dependencies. Communicate the changes to all affected team members — particularly in fast-tracked workstreams where daily coordination is now critical. Update your risk register to reflect any new risks introduced.
💡
After compression — watch for the new critical path. When you crash or fast track tasks, the original critical path changes. A previously non-critical path may now become the longest path through the network and therefore the new critical path. Always recalculate critical path after applying any schedule compression to avoid a nasty surprise near the project end date. Use the critical path calculator to recheck after changes.
09 — PMP Exam
Schedule Compression on the PMP Exam — What You Need to Know
Schedule compression questions are a reliable fixture of the PMP exam. Here is exactly what the exam tests, and the most common traps candidates fall into.
The Key Distinctions the Exam Tests
Crashing always increases cost — if an answer option says crashing reduces cost, it is wrong
Fast tracking always increases risk — if an answer says fast tracking reduces risk, it is wrong
Only critical path tasks can compress the schedule — any compression of non-critical tasks is a distractor
Fast tracking requires discretionary dependencies — it cannot be applied to mandatory (hard logic) dependencies
Scope reduction is not compression — removing scope to shorten the schedule is a different technique
Common PMP Exam Scenario Pattern
A typical PMP scenario: "The project is 2 weeks behind schedule. The project sponsor has confirmed the deadline cannot move. The project budget has no contingency remaining. What should the project manager do?"
The correct answer will be fast tracking (no budget required) rather than crashing (requires budget). The exam frequently tests your ability to choose the right technique given budget and risk constraints — not just whether you know what the techniques are.
Schedule compression is a set of techniques used to shorten the project schedule duration without reducing the project scope. The PMBOK Guide defines two schedule compression techniques: crashing (adding resources to critical path activities to reduce their duration) and fast tracking (overlapping activities that were originally planned in sequence). Both techniques are applied only to critical path tasks — compressing tasks with float does not change the project end date. Schedule compression is used either during planning to meet an imposed deadline or during project execution to recover from schedule variances.
Crashing and fast tracking are the two PMBOK schedule compression techniques and they work differently. Crashing adds resources (people, budget, equipment) to critical path tasks to reduce their duration — it always increases cost but keeps risk relatively low and predictable. Fast tracking overlaps tasks that were planned to run in sequence — it costs nothing extra but always increases the risk of rework, because work is started based on incomplete or preliminary inputs from predecessor tasks. The key decision rule: use crashing when you have budget; use fast tracking when you have no budget but the dependency between tasks is discretionary (not a physical or technical requirement).
The crash cost per day formula is: Crash Cost per Day = (Crash Cost − Normal Cost) ÷ (Normal Duration − Crash Duration). For example, if a task normally costs £10,000 and takes 10 days, but can be crashed to 7 days for £16,000, the crash cost per day is (£16,000 − £10,000) ÷ (10 − 7) = £6,000 ÷ 3 = £2,000 per day. When multiple critical path tasks can be crashed, always crash the task with the lowest crash cost per day first to get the maximum schedule reduction at minimum additional spend.
No — schedule compression can only shorten the project end date when applied to critical path tasks. The critical path is the longest sequence of dependent tasks that determines the minimum project duration. Tasks that are not on the critical path have float (spare time) — compressing them does not change the project end date, it simply increases their float. Before applying any compression, identify your critical path using the critical path method (CPM) and confirm which tasks have zero float. Crashing or fast tracking non-critical tasks wastes budget and introduces unnecessary risk with no schedule benefit.
No — by definition, schedule compression does not change the project scope. Both crashing and fast tracking maintain the full scope of deliverables. This is what distinguishes schedule compression from scope reduction. If a project manager removes features, deliverables or work packages to shorten the timeline, that is scope reduction — a separate and distinct action that goes through change control. Schedule compression is specifically the approach used when a deadline must be met without removing anything from scope.
The primary risk of fast tracking is rework. When you overlap tasks that were originally planned in sequence, the later task starts based on incomplete outputs from the earlier task. If those outputs change — which is common — the later task's work must be partially or fully redone. Additional risks include: increased coordination complexity (parallel workstreams need tighter daily communication), quality risk (work based on incomplete information may miss requirements), and morale risk (teams working on overlapping tasks may conflict or duplicate effort). Fast tracking should only be applied to discretionary dependencies where the rework probability is low and the outputs of the predecessor task are relatively stable.
Schedule compression as formally defined in PMBOK (crashing and fast tracking) is primarily a predictive (waterfall) project management concept. In Agile, the equivalent of schedule compression is re-prioritising the product backlog to deliver the most important features within a fixed sprint or release timeline — essentially accepting scope flexibility rather than compressing fixed scope. However, the concepts translate: in hybrid environments, crashing (adding sprint capacity via contractors or overtime) and fast tracking (starting development before design is fully complete, which Agile normalises) are both used. The terminology differs but the underlying trade-offs — time vs cost, time vs risk — are the same.
After applying schedule compression, you must: (1) Recalculate the critical path — compression changes task durations and dependencies, which may create a new critical path from a previously non-critical sequence; (2) Update the schedule baseline through the formal change control process; (3) Update the project budget baseline if crashing was used; (4) Update the risk register to reflect any new risks introduced by fast tracking; (5) Communicate the revised schedule and new coordination requirements to all affected team members; (6) Increase monitoring frequency on fast-tracked workstreams to catch rework early. Failing to recalculate the critical path after compression is the most common error — it leaves project managers tracking the wrong tasks as they approach the revised deadline.