Buying time without wasting money
Rank activities by cost per day and work down the list, and you will keep paying for an activity that stopped governing the finish several steps ago.
The naive method and why it fails
The intuitive approach is to compute cost per day for every activity, sort ascending, and buy days from the cheapest until the target is met. It produces a confident answer and it is wrong.
After a few days are bought, the path that activity sits on may no longer be the longest. Every further day bought from it changes nothing about the finish, and the waste is invisible because the spreadsheet keeps showing a shorter plan.
The fix is to recompute the critical path after every single day. Where the path changes is usually the most interesting line in the whole analysis.
Parallel critical paths defeat compression
If two chains are critical at the same length, shortening one buys nothing — the other still governs. To gain a day you must shorten both, and the cost is the sum of the two.
This is the usual reason a compression exercise spends real money and moves the date by zero, with nobody afterwards able to explain what happened. Discovering it in a spreadsheet is considerably better than discovering it in month three.
Crashing is not fast-tracking
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 meant to be sequential — starting the build before the design is finished. It is often cheaper and it introduces real rework risk that no crashing arithmetic will show.
When someone asks for a compressed plan, it is worth knowing which one they mean, because the two have completely different failure modes.
The linear cost assumption
Cost per day is normally treated as constant, so the tenth day costs the same as the first. In practice the marginal day gets dearer: the first extra person helps most and the fifth may actively slow things down.
For a few days the approximation is fine. For a plan needing twenty percent removed, treat the calculated cost as a lower bound and expect the real figure to exceed it.
Arithmetically possible is not deliverable
A crashed schedule can be internally consistent and still unmanageable. Doubling a team mid-project costs weeks of onboarding that the model does not see, and sustained overtime reduces output within a fortnight.
The output is a costed option, not a plan. Whether it can actually be run is a judgement that belongs to the people who would have to run it.