Schedule Compression

Schedule technique · See it on the map

Runnable here

Shortening a schedule without cutting scope, by adding resources or overlapping tasks.

When to use it

Use it when a real, specific deadline pressure exists and the schedule as planned doesn't meet it — never as a default first move, but as a deliberate response to a stated need to pull the finish date in.

When to avoid it

Don't use it as a routine planning step ("compress everything a bit just in case") — both techniques carry real, specific costs, and paying them without a concrete deadline forcing the tradeoff wastes money or adds risk for nothing.

Steps

1. Confirm the compression is needed against the critical path specifically — shortening a task that isn't on the critical path doesn't shorten the project at all.
2. For crashing: identify which critical-path tasks can be shortened by adding resources, and compute the cost of each option per day saved (the cost-per-day slope), then choose the cheapest options first.
3. For fast-tracking: identify critical-path tasks currently sequenced finish-to-start that could instead overlap, and check what rework risk that overlap introduces — you're now starting the successor on unfinished, potentially-changing input from the predecessor.
4. Apply the chosen compression, then re-run critical path method — compression frequently creates a new critical path, and a second round of compression aimed at the old path wastes effort.

What it produces

• A shortened schedule for a stated cost (crashing) or a stated rework risk (fast-tracking), with the tradeoff explicit rather than implied.

Common pitfalls

• Crashing adds cost and coordination overhead — more people on a task means more communication paths, onboarding time for the newly added resource, and sometimes negative returns past a point (Brooks's-law-style diminishing or reversing returns) — and rarely returns the linear time-for-money tradeoff the plan assumed going in.
• Fast-tracking trades schedule time for rework risk that shows up later and gets attributed to something else — the successor task built on the predecessor's unfinished output has to be partly redone once the predecessor's real output lands, and that rework cost rarely gets traced back to the fast-tracking decision that caused it.
• Compression is applied and the finish date is reported as fixed, without carrying forward the added cost or risk it was purchased with — the deadline looks met and the bill (in cost or in later rework) arrives separately.

Worked example

A product launch date moves up by two weeks. The team crashes "integration testing" by adding a second QA engineer, cutting it from ten days to six at roughly 1.5x the original cost for that task, and fast-tracks "write release notes" to start once the feature list is 80% locked rather than waiting for final code freeze — accepting that a late feature cut will mean rewriting part of the notes.

Source

• PMBOK-6 §6.5.2.6

Where it comes from: this technique is named by the PMBOK Guide, 6th edition.