Fast-tracking vs crashing: differences, costs and a schedule example
Overlap work or pay to shorten it? Compare both on one project, then add rework and watch the other branch become critical.
Fast-tracking overlaps activities that were planned in sequence. Crashing shortens activity durations, often through extra resources or overtime. Both are schedule-compression methods: ways to finish the agreed work earlier.
A warehouse project is due to finish on working day eighteen. Operations asks for day sixteen. The team has two suggestions: start configuration while design is still being finished, or pay for help to complete configuration sooner.
Both can bring the finish forward. They change different things, and the rest of the schedule decides whether those changes are enough.
A PMI conference paper explains the distinction and the extra cost or rework exposure that can follow. Here, we'll compare the choices on one small network, keeping the tests and handover intact.
Schedule compression example: find the critical path
Our fictional project installs a warehouse label-and-scan flow. Durations are working days, counted from day zero. An activity can start as soon as its predecessor finishes, with no extra gap between them.
The configuration and site teams are separate and available when needed. This example has no shared staffing constraint, procurement delay or restricted installation window.
| ID | Activity | Duration | Baseline dependency |
|---|---|---|---|
| A | Agree interface design | 4 days | Start of project |
| B | Configure the application | 8 days | A finished |
| C | Prepare the site | 6 days | A finished |
| D | Test the integrated flow | 4 days | B and C finished |
| E | Handover and release | 2 days | D finished |
Configuration and site preparation run in parallel. Testing waits for both.
Baseline finish
4 + max(8, 6) + 4 + 2 = 18 working days
The configuration branch sets the finish. Site preparation finishes on day ten and has two days of total float: it can move two days later without delaying this project's finish. The critical-path worked example explains that calculation in detail.
Cutting a day from site preparation alone changes nothing at the end. Configuration would still keep testing waiting until day twelve.
Fast-tracking example: overlap design and configuration
Suppose configuration can begin after two days of design using a reviewed preliminary interface. It then runs from day two to day ten. Final design is still due on day four; any later change must be checked against the work already done.
Site preparation stays on days four to ten. Both branches are ready for testing on day ten, so testing runs to fourteen and handover finishes on sixteen.
The team has not made eight days of configuration become six. It has started two days earlier by overlapping the work. This depends on there being useful work that can safely start from the preliminary information.
If final design changes require two extra configuration days, B finishes on twelve instead. Testing and handover move back, and the project again finishes on eighteen.
We price that specific rework scenario at €600 per extra configuration day. Two days add €1,200. No probability is attached to it, so it is not an expected rework cost.
Crashing example: cost per day saved and critical paths
Now keep the original sequence. Assume a supplier offers a defined configuration package that reduces B by up to three days, at an incremental €900 per day removed. This fictional supplier has committed to those shortened durations for this package.
| Configuration duration | Extra direct cost | Project finish | What limits the finish? |
|---|---|---|---|
| 8 days | €0 | Day 18 | Configuration branch |
| 7 days | €900 | Day 17 | Configuration branch |
| 6 days | €1,800 | Day 16 | Configuration and site branches |
| 5 days | €2,700 | Day 16 | Site branch |
The third day removed from B costs another €900 and buys no further project reduction. Configuration finishes on day nine, but the site is not ready until ten.
The first two days cost €900 per project day saved. That ratio stops being useful when the saving becomes zero. To finish before sixteen, the team would need another feasible change on the path that now controls the finish.
Compare baseline, fast-tracked and crashed schedules
The baseline, overlap and crash options stay visible together below. Add configuration rework to the overlap option, or change the number of days removed from configuration in the crash option.
One project / same test and handover scope
Which change reaches day sixteen?
Fast-tracking overlaps two days of design and configuration. Crashing buys a shorter configuration duration. The site branch stays at six days.
Baseline finishDay 18€0 extra direct cost; same finish as baseline
Fast-track finishDay 16€0 extra direct cost; 2 days earlier than baseline
Crash finishDay 16€1,800 extra direct cost; 2 days earlier than baseline
Scroll sideways to compare all three schedules. All starts, finishes and float follow below.
Filled graphite: zero total float. Outline: positive float. Rust on configuration: selected rework. Vertical rust line: requested day sixteen finish. Hover a bar for its dates, or read the ledger.
| Plan | Finish / change vs baseline | Extra direct cost | Controls the finish |
|---|---|---|---|
| Baseline | Day 18 / same finish as baseline | €0 | Configuration branch |
| Fast-track | Day 16 / 2 days earlier than baseline | €0 | Both branches |
| Crash | Day 16 / 2 days earlier than baseline | €1,800 | Both branches |
Activity ledger, dependencies and cost assumptions
| Activity | Baseline: start / finish / float | Fast-track: start / finish / float | Crash: start / finish / float |
|---|---|---|---|
| A Interface design | 0 / 4 / 0 | 0 / 4 / 0 | 0 / 4 / 0 |
| B Configuration | 4 / 12 / 0 | 2 / 10 / 0 | 4 / 10 / 0 |
| C Site preparation | 4 / 10 / 2 | 4 / 10 / 0 | 4 / 10 / 0 |
| D Integrated testing | 12 / 16 / 0 | 10 / 14 / 0 | 10 / 14 / 0 |
| E Handover | 16 / 18 / 0 | 14 / 16 / 0 | 14 / 16 / 0 |
A starts at zero. C starts after A finishes. B starts after A finishes except in the fast-track plan, where it starts two days after A starts. D waits for both B and C to finish; E waits for D. Forward and backward passes recalculate starts and total float after every change. Both branches can be critical at once.
Fast-track B lasts eight days plus selected rework at €600 per rework day. Crashed B lasts eight minus the selected reduction, charged at €900 per day removed. No other extra direct charge is assumed. Other coordination and opportunity costs are unpriced. Separate teams are available and tests stay at four days, handover at two. The model explores rework scenarios without assigning their likelihood.
With no rework and a two-day crash, both alternatives finish on sixteen. Fast-tracking has no added direct charge in this scenario; crashing costs €1,800. That does not make overlap free in practice. Review effort, coordination, uncertainty and effects on other work have not been priced.
Check which branch controls each revised finish. In the two-day versions, both branches have no float. A late site-preparation task now delays the finish just as a late configuration does.
Choose a change the team can actually deliver
For overlap, identify the exact early work, the preliminary information it needs and who accepts the consequence if that information changes. Do not start an activity early merely because two bars can be moved over each other.
For crashing, get a credible shortened duration and price, with the people, access and supervision needed to achieve it. Check that the extra specialist is available during the required days. The resource levelling and smoothing note covers what happens when several activities need the same people.
Keep test coverage and release criteria visible in both options. Deleting a test or quietly reducing the deliverable changes scope. It is not equivalent to completing the same work sooner. Use change control if the requested date requires a different scope or acceptance decision.
For this project, day sixteen has two defined routes. Bring both to the decision with their assumptions, extra costs and response to rework. Once a route is agreed, update the full schedule and its owners rather than leaving the compressed date as a note beside the original plan.
Sources and example notes
- PMI: Managing a crashed and fast-tracked shortened project. Established definitions and cost/rework considerations; no performance benchmark is taken from the case.
All activities, durations, prices and rework scenarios are fictional. The visual recalculates dependencies and total float for each alternative. Shared staffing limits and the probability of a delay are outside this comparison.