Every project management course teaches fast tracking vs crashing in the same order and with the same moral: if the date is at risk, fast track first, because overlapping tasks costs nothing but risk, and crash second, because crashing costs money. I have repeated that advice myself. Then I put both through a solver on the same plan and got the opposite of what the order implies.
Fast tracking pulled eight working days off the schedule and one day off the job. Crashing pulled six off the schedule and eleven off the job. Same 21-task renovation, same solver, same afternoon.

The two levers, in one paragraph each
Fast tracking changes the logic. Two tasks that were planned end to end now overlap: start the electrical rough-in when framing is half done rather than waiting for the last stud. Durations do not change, nobody gets paid extra, and in Microsoft Project you do it by entering negative lag — lead time — on the link, or by switching a finish-to-start dependency to start-to-start with a lag. The price is rework risk: you are building on top of something that is not finished, and if it changes you tear out what you built.
Crashing changes the method. The dependencies stay exactly as drawn, and a task gets shorter because you bought something — prefabricated panels, a spray rig, a subcontractor with their own crew. The price is money, and I went through what that buys on this plan in the post on project crashing.
Textbook order follows the prices: risk is cheaper than money, so fast track first. That reasoning is fine right up until you notice it never asks what the schedule is actually constrained by.
The plan, and the two dates it has
Twenty-one tasks, a house renovation, five trades. Three general crew, two electricians, two plumbers, two painters, one excavator. It has two finish dates and the gap between them is the whole story.
Run the critical path arithmetic and it finishes 25 November 2026. That calculation assumes anything the dependencies allow to run in parallel does run in parallel, which on the busiest day of this job means five general crew. There are three. Schedule it so that no day ever exceeds what exists and the finish is 2 December — five working days that the network never mentions.
Every number below is reported twice: against 25 November, which is what a fast-tracking exercise in any CPM tool will show you, and against 2 December, which is when the keys actually change hands.
Five overlaps a site manager would defend
I did not invent aggressive overlaps to make a point. These are the five a builder would propose in the meeting, each one a trade starting partway into its predecessor rather than after it.
| The overlap | 25 Nov becomes | 2 Dec becomes |
|---|---|---|
| Interior painting starts 3 days into drywall | 19 Nov | 1 Dec |
| Drywall starts 1 day into insulation | 23 Nov | 2 Dec |
| Rough electrical starts 5 days into framing | 24 Nov | 2 Dec |
| Rough plumbing starts 5 days into framing | 25 Nov | 2 Dec |
| Roofing starts 7 days into framing | 25 Nov | 2 Dec |
| All five together | 13 Nov | 1 Dec |
The right-hand column is the one to sit with. Overlapping rough electrical with framing looks like a clear day saved. On site it is worth zero, and it stays worth zero when you add the plumbing overlap on top of it. All five together, the most aggressive version of this plan anyone would sign, move the finish from 2 December to 1 December.
One working day, in exchange for five separate trades starting on top of unfinished work.
Why overlapping tasks does almost nothing here
Because overlapping two tasks does not create anybody to work on them.
A dependency is not the only thing that can stop a task from starting. On this job most of the waiting is not “the wall is not up yet” — it is “the three people who would do this are on the other task”. Fast tracking deletes the first kind of constraint and leaves the second untouched. So the solver takes your permission to run drywall and insulation side by side, looks at the crew sheet, discovers that side by side needs six general crew where there are three, and puts them back one after the other. You have not compressed the schedule. You have removed a rule that was not binding and left the one that was.
The one overlap that did move the real date is the exception that proves it: interior painting is done by painters, drywall by general crew. Overlapping those two puts two different sets of hands to work at the same time, so there is nobody to fight with, and the day is real. Every overlap that saved nothing was an overlap between two tasks that wanted the same people.
This is also why the network view is so persuasive and so misleading. On paper the five overlaps compound beautifully — 25 November to 13 November, eight working days, more than the individual savings add up to, because unblocking several points on a chain lets the whole thing telescope. The picture is genuinely of a job finishing much sooner. It is a picture of a job with unlimited people.
And why crashing does the opposite
Give the same plan six alternative methods instead of five overlaps and the solver picks three: prefabricated framing, a roofing subcontractor, a drywall subcontractor. Finish 17 November. That is eleven working days off 2 December.
Now do the same comparison in reverse. On the unlimited-crew network, crashing is worth only six working days — less than fast tracking’s eight. It is the weaker of the two levers in the view most tools show you, and nearly twice as strong in reality. That inversion is not a quirk of this plan. Two of the three changes the solver chose are subcontractors, and what a subcontractor really sells you is not a shorter task. It is a task that consumes none of your crew, which frees those people to be somewhere else that same week. Crashing relieves the constraint that was actually binding. Fast tracking relieves the one that was not.
There is a nice postscript. The two levers are not rivals — do both, and the finish goes to 10 November, another five working days beyond crashing alone. But it now takes five changes rather than three, because once the overlaps have rearranged the plan, two more tasks become worth buying. Fast tracking on its own bought one day. Fast tracking underneath crashing unlocked five more. It is a multiplier, not a substitute, which is a much better reason to use it than the one in the textbook.
When fast tracking is the right call
I am not telling you fast tracking does not work. I am telling you it works on logic-constrained schedules and does very little on resource-constrained ones, and that nothing in the standard advice tells you which of those you have.
The test is cheap. Compare your critical-path finish with your finish under real crew caps. If they are the same date, your schedule is constrained by its logic, and overlapping tasks will genuinely compress it. If there is a gap — five working days on this plan — that gap is people, and fast tracking will chip at the wrong wall until you close it. You can see the same thing task by task in the difference between a task’s float on the network and its float under real crews; where the two disagree, the crew is what is holding it.
Worth saying plainly: this is one plan. A software project where the constraint is a dependency on someone else’s API, or a job with far more slack in its trades than this one, will come out differently, and I would expect fast tracking to shine there. What I would not do again is assume the ordering. The reason it is worth measuring rather than reasoning about is that both levers are expensive in ways that are hard to reverse — five trades starting on unfinished work is not a decision you unwind halfway through, and neither is a signed subcontract.
Testing it on your own plan
Both experiments took about a minute each in the free scheduler, on the same workbook the rest of this series uses.
- To fast track, edit the predecessors column. Writing
12SS+1instead of12means “start one day after task 12 starts” rather than “start after task 12 finishes”. Solve it once with your real crew numbers and once with the resource sheet set high enough not to bind, and compare the two finishes. The difference between those two runs is the entire argument above. - To crash, fill in the alternatives sheet and set Mode to
crash. One row per option: task ID, shorter duration, crew per day — zero if a subcontractor brings their own people.
Both answers come back proved optimal in a fraction of a second, which matters more than the speed suggests: when the tool says fast tracking bought you one day, it is not reporting the best arrangement it stumbled across before giving up. It has established that no arrangement of those tasks does better. That is a claim a priority rule cannot make, and when seven commercial packages were benchmarked against it, the median answer came back 3.6% above optimal and got worse as crews got tighter — which is exactly the condition under which you would be reaching for either of these levers in the first place.
Things that I use, like, and am affiliated with:
Mint Mobile offers great cell phone service for $15 flat, get $15 off using the link. Get discounted phones with service activation and no contract.
I never spend money before I check Mr Rebates or Rakuten to get cashbacks, rebates, discounts, coupons or cheaper gift cards.
