Buying days, cheapest first
One day at a time, from the cheapest activity on every critical path — recomputing after each, because shortening one activity usually makes a different path critical.
Buying time, cheapest day first
The critical path is recomputed after every single day bought — which is the entire difficulty, and where most crashing calculations go wrong.
Activities
Leave the crash columns blank for anything that cannot be shortened.
Every day bought, in order
What ended up crashed
The algorithm, and its limits
cost per day = (crash cost − normal cost) ÷ (normal duration − crash duration)
One day at a time: find the activities that lie on every critical path and can still be shortened, take the cheapest, buy one day, then recompute the critical path from scratch and start again.
Recomputing is the whole point. Shortening an activity frequently makes a different path critical. A calculator that ranks activities once by cost per day and works down the list keeps spending on an activity that stopped mattering several steps ago, and the output looks like progress.
Only activities on every critical path are eligible. Where two paths are critical at once, shortening one leaves the other governing the finish, and the day bought saves nothing.
Limits. This assumes crash cost is linear in days saved, which is a convention rather than a fact — the fifth day is usually dearer than the first. It also takes no view on whether the compressed plan is deliverable, and a schedule that is arithmetically possible can still be unmanageable.
Why the naive method wastes money
The intuitive approach is to rank every activity by cost per day, then buy days from the cheapest until the target is met. It produces a confident schedule and it is wrong.
After a few days are bought from one activity, the path it sits on may no longer be the longest. Every further day bought from it changes nothing about the finish date, and the spend is invisible because the plan on paper keeps getting shorter.
Recomputing after each day catches the handover exactly. The step list here shows where the critical path changed, which is usually the most interesting line in the table.
Parallel critical paths defeat compression
If two chains are critical at the same length, shortening one of them buys nothing at all — the other still governs. Compression exercises routinely spend real money and move the date by zero for this reason, and everyone involved is left unable to explain it.
To gain a day when two paths are critical you must shorten both, and the cost is the sum. That is often the moment a compression plan stops being worth it, and it is much better discovered in a spreadsheet than in month three.
Crashing and fast-tracking are different
Crashing buys time with money: more people, overtime, expedited delivery. The sequence of work is unchanged and the risk profile is broadly the same.
Fast-tracking buys time by overlapping work that was meant to be sequential — starting the build before the design is finished. It is often cheaper and it adds genuine risk of rework, which no arithmetic here will show you. This tool does crashing only, and the distinction is worth keeping clear when someone asks for a compressed plan.
The linear cost assumption
Cost per day is treated as constant, so the tenth day costs the same as the first. In reality the marginal day gets dearer — the first extra person helps most, and the fifth may slow things down.
For a few days of compression the approximation holds well enough. For a plan that needs twenty percent removed, expect the real cost to exceed this figure, and treat the output as a lower bound.