Schedule Crashing Calculator

Schedule crashing is the technique of shortening a project by adding resources to the right activities at the lowest possible added cost.

This schedule crashing calculator takes each activity’s normal and crash times and costs, computes the cost slope and maximum crash for every activity, then runs the least-cost crashing algorithm along the critical path — recomputing the critical path after each step — to reach a target duration or the shortest feasible schedule.

It returns the crash sequence, the added cost of each step, the running project duration and cost, and the full time–cost trade-off curve. Enter your activities above and read the cheapest way to finish sooner.

What the schedule crashing calculator computes

Every project has a normal schedule, the plan you would follow if cost were the only concern, and a set of ways to buy time by spending money. Crashing quantifies that trade-off. For each activity you provide a normal time and its normal direct cost, and a crash time — the shortest the activity can be compressed to — with its higher crash cost. From those four numbers the calculator derives two quantities that drive every crashing decision: the cost slope, which is the extra cost per unit of time saved, and the maximum crash, which is how many units the activity can be shortened at all.

The tool then compresses the project. Starting from the normal schedule it repeatedly finds the critical path, identifies the cheapest way to shorten it by one time unit, applies that crash, and recomputes — because crashing one activity can change which path is critical. It continues until it reaches the target duration you set, or, if you leave the target blank, until no critical activity can be crashed any further. At each step it records which activity was crashed, the cost of that step, the new project duration and the new total cost, and it plots the resulting time–cost trade-off curve. The output is a complete, auditable compression plan rather than a single number.

The cost slope: crash cost per unit of time

The cost slope is the heart of crashing. It answers the question every project manager asks when a deadline slips: what will it cost to buy back a day? For a single activity it is the difference between the crash cost and the normal cost, divided by the number of time units saved between the normal and crash durations:

Cost slope = (crash cost − normal cost) / (normal time − crash time)

An activity with a normal time of five days at a cost of fifty and a crash time of three days at a cost of seventy has a cost slope of (70 − 50) / (5 − 3) = 10 per day. That is the price of each of the two days this activity can save. The cost slope is assumed constant over the crashable range, which is the standard linear approximation; it turns a messy trade-off into a simple unit price that can be compared directly across activities. The activity with the lowest cost slope is the cheapest place to buy time, and crashing always starts there.

Maximum crash and the crash limit

The maximum crash of an activity is simply its normal time minus its crash time — the total number of units it can be compressed. An activity that cannot be shortened at all has a maximum crash of zero and an infinite cost slope, and the calculator will never choose it.

The maximum crash matters because it bounds how much time any one activity can contribute, and because the project’s own shortest possible duration is reached when every activity on the binding path has been crashed to its limit. Beyond that point, spending more money buys no more time, and the calculator stops.

Knowing each activity’s crash limit up front tells you where the schedule’s hard floor lies before you spend anything.

The least-cost crashing algorithm

Crashing is governed by two rules that this calculator follows exactly. The first is that only critical-path activities matter: shortening an activity that has float does nothing for the project finish date, it merely consumes that activity’s slack. So crashing dollars must be spent on the critical path. The second rule is to spend them in order of cost slope, cheapest first, because that extracts the most schedule compression per unit of money.

The algorithm therefore proceeds in single-unit steps. It finds the current critical path, lists the critical activities that still have crash capacity, and selects the least-cost way to shorten the project by one unit. It then crashes that activity by one unit, adds its cost slope to the running total, and recomputes the network. Recomputation is essential: as the critical path shortens, a previously non-critical path can catch up and become critical too, at which point the binding constraint changes. The process repeats until the target is met or no further compression is possible. Each iteration is a row in the step table, so you can trace exactly how the schedule and cost evolved.

When more than one path is critical

The subtlety that trips up most hand calculations is parallel critical paths. Once two paths through the network are both critical, shortening the project by one unit requires shortening every critical path by one unit at the same time. There are two ways to do that: crash a single activity that lies on all of the critical paths, or crash one activity on each path simultaneously.

The calculator evaluates both options and chooses whichever is cheaper — a shared activity is often the bargain, but sometimes two separate cheap activities beat one expensive shared one. This is exactly the calculation that is tedious and error-prone by hand, and getting it right is where an automated tool earns its keep.

When no combination can shorten every critical path, the project has reached its crash limit and the calculator stops.

Worked examples

Example 1 — the built-in network. The example loads a small network: A (start), then B and C both after A, then D after B and C. Normal times give a project duration of ten, with the critical path running A–B–D. The cheapest critical activity to crash is A, at a cost slope of four, so the first steps crash A. As A reaches its limit and the network is recomputed, the algorithm moves to the next-cheapest critical option, and if B and C become jointly critical it evaluates crashing a shared activity versus one on each path. The step table shows the whole sequence, ending at the minimum feasible duration with the total added cost. Press “Load example” and read it row by row.

Example 2 — a simple series project. If three activities run strictly in sequence, every one is critical, and crashing simply picks the lowest-slope activity repeatedly until that activity hits its crash limit, then the next-lowest, and so on. Suppose A can save two days at 5 per day, B one day at 8, and C one day at 6. To cut two days you crash A twice for an added cost of ten; to cut a third day you crash C for a further six. The order is always cheapest-slope-first, and the running total climbs the time–cost curve one step at a time. This is the pure case that shows the logic without the complication of parallel paths.

Example 3 — reading the trade-off curve. The chart plots total direct cost against project duration, starting at the normal point on the right and stepping up and to the left as the project is compressed. Its slope at each segment is the cost slope of the activity crashed in that step, so the curve gets steeper as cheap options are used up and only expensive ones remain. That rising steepness is the visual signature of diminishing returns: the first days bought are cheap, the last days are dear. Reading where the curve bends sharply tells you where further compression stops being worthwhile.

How to read the results

The headline states the duration the project was crashed to and the total added cost to get there. The metric grid gives the normal duration and normal direct cost, the crashed duration, the total added cost and the resulting total cost.

The activity table lists every activity with its normal and crash times, its computed cost slope and its maximum crash, so you can see at a glance which activities are cheap to compress and which cannot be compressed at all.

The step table is the compression plan: each row names the activity or activities crashed in that step, the cost of the step, and the project duration and total cost after it. The chart draws the time–cost trade-off curve. Export the step table to CSV to attach to a recovery plan, or save the page as a PDF for a change request.

Crashing versus fast-tracking

Crashing is one of two classical schedule-compression techniques, and it is important to know when to reach for the other. Fast-tracking shortens a project by overlapping activities that were planned in sequence — starting a successor before its predecessor fully finishes.

Its great advantage is that it costs no money; its cost is risk, because activities now run in parallel that were separated for a reason, and rework becomes more likely if the earlier activity changes. Crashing, by contrast, keeps the sequence intact and buys time by adding resources, so it always costs money but does not increase logical risk in the same way.

The usual practice is to fast-track first, where overlapping is safe, and to crash second, spending money only where fast-tracking cannot help or would be too risky. This calculator models crashing; the fast-tracking decision is a matter of judgement about which dependencies are truly mandatory.

Direct cost, indirect cost and the optimum duration

Crashing as computed here tracks direct cost — the cost of the activities themselves — which rises as the project is compressed. But a project also carries indirect costs: overheads, supervision, equipment rental, financing and sometimes liquidated damages, all of which accrue per unit of time and therefore fall as the project gets shorter.

The economically optimal duration is the one that minimises the total of direct plus indirect cost, and it usually lies somewhere between the normal and the fully crashed schedule. The direct-cost curve this calculator produces is exactly the input you need for that analysis: add your per-day indirect cost, sum the two curves, and the minimum of the total is the least-cost duration.

Crashing all the way to the minimum feasible schedule is rarely the cheapest choice once indirect savings and any deadline penalties are weighed, which is why the trade-off curve, not just the minimum point, is the valuable output.

Crashing in agile and hybrid delivery

It is sometimes assumed that crashing belongs only to traditional, plan-driven projects, but the underlying idea — spending to buy time on the constraint — reappears in every delivery model. In an agile programme with a fixed release date, the equivalent of crashing is adding a team or paying for expedited work on the specific dependency that gates the release, exactly the critical-path logic applied to coarse-grained increments rather than individual tasks.

Hybrid delivery, which plans milestones traditionally while executing the detail iteratively, uses crashing precisely at the milestone level: when a gated date is at risk, the question is still which of the feeding workstreams offers the cheapest acceleration. Even the agile practice of swarming — concentrating the whole team on the most urgent item — is a form of crashing, trading the efficiency of parallel work for speed on the bottleneck.

The vocabulary changes but the economics do not, which is why the cost-slope way of thinking is worth carrying into any project regardless of its methodology.

Crashing and the project budget baseline

A crash decision is also a budget decision, and the two should be reconciled explicitly. The added cost the calculator reports is a direct increase to the project’s cost baseline, and if the crash is approved it should flow through a formal change so the new baseline reflects both the shorter schedule and the higher cost.

Where the money comes from matters too: a crash driven by the project team’s own slippage is usually funded from contingency, whereas a crash requested by the customer to pull in a date is normally funded by the customer as a scope-or-schedule change.

Keeping the crash cost visible as its own line, rather than absorbing it silently, preserves the integrity of earned-value tracking later — the cost variance that earned-value analysis reports only means something if the baseline it compares against was updated when the crash was approved. Crashing, in other words, does not end when the cheapest sequence is found; it ends when the resulting cost and date are written back into the plan everyone is measured against.

When to crash a project

Crashing is a response to a schedule problem, and it pays to be clear about the trigger. The most common is a committed deadline that the normal schedule cannot meet, whether imposed by a contract, a market window, a regulatory date or a downstream dependency. Another is recovery: the project has slipped and must be brought back to its baseline finish.

A third is opportunity: finishing early is worth more than it costs, perhaps because of an early-completion bonus or because the resources are needed elsewhere. In every case crashing answers the same question — what is the least-cost way to reach the required date — and the cost slope is the currency of the decision.

Crashing is not a routine optimisation to be applied to every project; it is a deliberate purchase of time, justified when the value of the time bought exceeds its cost.

Timing the decision matters as much as making it. Crashing early, while most of an activity’s duration still lies ahead, buys the full compression the cost slope promises; crashing an activity that is already half complete can only compress its remaining portion, so the same money buys less time.

This is why recovery decisions taken late in a slip are so expensive — the cheap, long, early activities that would have been the natural place to buy time are already behind you, leaving only the short, dear activities near the deadline. The lesson is to watch the critical path continuously against the baseline and to act on a threatened date while the cheap options are still available, rather than waiting until the slip is undeniable.

A crashing analysis run early, before it is needed, tells you where that cheap flexibility sits and how long it will remain reachable, turning crashing from a panicked end-game measure into a planned contingency you can trigger at the right moment.

Reading the time–cost trade-off curve in depth

The trade-off curve is the single most informative output of a crashing analysis, and it repays careful reading. Its rightmost point is the normal schedule: the longest duration at the lowest direct cost. Each step to the left is one time unit bought, and the vertical rise of that step is exactly the cost slope of the activity crashed to buy it. Because the algorithm always spends the cheapest money first, the steps rise gently at first and steeply later, giving the curve its characteristic convex, upward-bending shape. That convexity is not an accident; it is the mathematical expression of diminishing returns, and it means the marginal cost of time is always increasing as you compress.

Two readings follow directly. First, the slope of the curve at any duration is the current marginal cost of a further unit of time — useful when negotiating a deadline, because it tells you precisely what the next day of acceleration will cost.

Second, the point where the curve turns sharply upward marks the practical limit of economical crashing: beyond it each unit costs far more than the last, and unless the value of time is very high it is rarely worth going further. When you overlay the falling indirect-cost line on the same axes, the total-cost curve becomes U-shaped and its lowest point is the least-cost duration.

Even without that overlay, the shape of the direct-cost curve alone tells a manager how much cheap flexibility the schedule holds and where buying more time stops making sense.

Common mistakes when crashing

The most frequent error is crashing a non-critical activity, which spends money and saves no time; always confirm an activity is on the current critical path before crashing it. The second is failing to recompute the critical path after each crash, which leads to over-crashing one path while another quietly becomes the binding constraint — the calculator recomputes automatically, but hand calculations often skip it.

The third is ignoring parallel critical paths and crashing only one of them, which again buys no project time because the other path still governs. The fourth is crashing past the point where indirect savings justify the direct cost, treating the minimum feasible duration as the goal rather than the least-total-cost duration.

The fifth is trusting the constant-cost-slope assumption too far; real crash costs can rise non-linearly as an activity approaches its physical limit, so the last unit may cost more than the model says. Keeping these in mind turns crashing from a blunt instrument into a precise one.

Where crashing is used

Schedule crashing appears wherever deadlines are firm and money can buy speed. In construction it is routine: adding a second shift, extra crews or overtime to bring a milestone forward, with the cost slope of each trade guiding where the money goes. In event production and plant turnarounds, where the end date is immovable, crashing decides how to compress interdependent work into the fixed window at least cost.

In manufacturing ramp-ups and new-product launches it accelerates the long-lead activities that gate the launch. In software and IT it justifies adding people or paying for expedited procurement on the specific tasks that sit on the critical path.

It is also a core topic in project-management certification: the cost-slope calculation, the cheapest-first rule and the critical-path recomputation on this page are exactly what the PMP and CAPM examinations expect candidates to perform.

What unites all of these settings is a firm date and a measurable price for speed. Crashing is most valuable precisely where those two conditions meet: a fixed, consequential deadline on one side, and a menu of activities whose durations can be bought down at known cost slopes on the other.

Where the date is soft, the discipline of computing cost slopes still clarifies thinking, but the urgency is lower; where speed cannot be bought at any sensible price, crashing simply confirms the schedule floor and points you back to fast-tracking or scope reduction.

Recognising which situation you are in is itself part of the analysis, and the activity table on this page — with its slopes and crash limits laid out side by side — is designed to make that judgement quick.

A step-by-step walkthrough of the example

The built-in network makes the algorithm concrete. Activity A starts the project and takes three time units at a normal cost of ten, crashable to two units at a cost of fourteen, so its cost slope is four and it can save one unit. Activity B follows A, five units normal crashable to three, slope ten, two units available. Activity C also follows A, four units crashable to three, slope three, one unit available. Activity D follows both B and C, two units crashable to one, slope seven, one unit available. With normal times the path A–B–D runs three plus five plus two, or ten units, while A–C–D runs three plus four plus two, or nine; the project duration is ten and the critical path is A–B–D.

To shorten the project the algorithm looks only at the critical path A–B–D and its crashable activities: A at slope four, B at slope ten, D at slope seven. The cheapest is A at four, so it crashes A by one unit. Now A is two, the path A–B–D is nine and A–C–D is eight, and A is at its crash limit. Recomputing, A–B–D is still critical at nine. The crashable critical activities are now B (ten) and D (seven), so the algorithm crashes D at seven. The project is eight, but watch what happens to the parallel path:

A–C–D was eight and D is shared, so crashing D shortened both paths at once — a shared activity is the efficient cut. After D reaches its limit the only remaining critical activity is B, and crashing B shortens A–B–D but not A–C–D, so once A–B–D falls to the length of A–C–D both become critical and further cuts must shorten both. The step table records every one of these moves with its cost, and the running total is the height of the time–cost curve at each duration.

Working through it once by hand makes the automated plan far easier to trust.

Crashing as a linear programming problem

The greedy cheapest-first rule this calculator uses is the classical hand method, and for the linear, independent-activity model it gives the optimal least-cost compression to each duration. It is worth knowing that the same problem can be posed formally as a linear program: minimise the total crash cost subject to each activity’s crash amount lying between zero and its maximum, and to the event-time constraints that enforce the network logic and the target duration.

Solving that program for a range of target durations traces out exactly the time–cost curve the greedy method produces step by step. The linear-programming view matters when the simple assumptions break — when crash costs are non-linear, when crashing several activities interacts, or when the network is very large — because a solver handles those cases where the hand method becomes unwieldy.

For the teaching-scale networks this calculator targets, the transparent step-by-step greedy method is both correct and far easier to follow, which is why it is the one implemented here.

Resource limits and practical constraints

The time–cost model assumes that time can always be bought if you are willing to pay the crash cost, but reality imposes limits the arithmetic does not see. There may simply be no more skilled workers to add, no more shifts the site permits, or a physical process — concrete curing, paint drying, a chemical reaction — whose duration cannot be shortened at any price.

Those hard limits are captured by an activity’s crash time: set the crash time equal to the normal time for anything that genuinely cannot be compressed, and the calculator will correctly refuse to crash it. Beyond that, adding resources can hit diminishing or even negative returns, the phenomenon that the tenth worker on a task adds far less than the second and can get in the way.

The linear cost slope is an approximation that holds over a sensible range; when you push an activity toward its physical floor, verify the crash cost against a real quote rather than trusting the straight-line extrapolation. Crashing is a planning aid, and the plan it produces should always be checked against what the site and the crews can actually deliver.

A brief history of the time–cost trade-off

The crashing method grew directly out of the Critical Path Method, which Morgan Walker of DuPont and James Kelley of Remington Rand developed in the late 1950s specifically to manage the cost of time on plant maintenance and construction. From the outset CPM was built around the time–cost trade-off: Kelley and Walker’s original work framed the problem as finding the cheapest way to achieve any given project duration, and the cost slope was central to it.

That is a point of contrast with PERT, developed at almost the same moment for the Polaris programme, which focused on uncertainty rather than cost. Crashing is therefore the older technique’s original purpose rather than a later add-on, and the cheapest-first algorithm has been taught essentially unchanged for more than sixty years.

Its longevity reflects how well the simple cost-slope idea captures the real decision a manager faces when a deadline must be met.

Sensitivity: which activity is worth de-risking

Beyond finding the least-cost plan, the calculator’s activity table is a map of where flexibility lives in your schedule. An activity with a low cost slope and several units of available crash is a cheap source of time you can call on if the project slips; one with a high slope or zero crash capacity offers no help under pressure.

Reading the table before you need it tells you, in advance, which activities you could lean on to recover a delay and roughly what that recovery would cost. It also flags the opposite risk: if your only crashable critical activities are expensive, the project has little cheap flexibility, and a slip will be costly to recover — a reason to build more schedule buffer into the baseline or to fast-track where you can.

Used this way, crashing analysis is not only a compression tool but a way to understand the resilience of a schedule before it is tested.

A short glossary of crashing terms

Normal time — an activity’s duration under the normal, lowest-cost plan. Crash time — the shortest the activity can be compressed to. Normal cost — the direct cost at normal time. Crash cost — the higher direct cost at crash time. Cost slope — the extra cost per unit of time saved, (crash cost − normal cost) / (normal time − crash time). Maximum crash — the units an activity can be shortened, normal time − crash time. Crashing — shortening the project by adding resources to critical activities. Fast-tracking — shortening by overlapping sequential activities, at no cost but higher risk. Direct cost — the cost of the activities, which rises with crashing. Indirect cost — time-related overheads, which fall as the project shortens. Crash limit — the shortest feasible project duration, reached when the binding path cannot be shortened further. Keeping these straight is most of what it takes to read any crashing analysis with confidence.

How to use this calculator

List your activities one per line as ID, predecessors, normal time, crash time, normal cost, crash cost — for example D, B;C, 5, 3, 50, 70. Separate multiple predecessors with a semicolon or space, and leave the predecessor field blank for start activities. Optionally enter a target duration; leave it blank to crash all the way to the minimum feasible schedule. Press calculate, or press “Load example” to populate a four-activity network.

Read the headline for the outcome, the activity table for each activity’s cost slope and crash limit, and the step table for the compression plan in order. Keep your time and cost units consistent across activities, make sure each line has normal time ≥ crash time and crash cost ≥ normal cost, and export the plan to CSV or PDF for your records.

If you enter a target below the minimum feasible duration, the calculator crashes as far as it can and tells you the schedule cannot be shortened further.

Five worked examples of schedule crashing

Example 1: the crash cost slope

Activity A: normal 10 days at 10,000, crash 7 days at 16,000. Slope = (16,000 − 10,000) ÷ (10 − 7) = 2,000 per day. This is the cost of buying back one day on A.

Example 2: choosing the cheapest day

A costs 2,000/day to crash, B costs 3,500/day. Both are on the critical path, so crash A first — always buy the cheapest day on the critical path.

Example 3: crashing to a target

To cut 3 days, crash A its full 3 days at 2,000 = 6,000 extra. Total project cost rises by 6,000 to save 3 days — worth it only if the delay penalty exceeds that.

Example 4: when a second path becomes critical

After crashing A by 3 days, a parallel path that was one day shorter is now critical too. Beyond this point you must crash both paths at once, so the cost per day saved jumps.

Example 5: the optimum stopping point

Keep crashing while the daily crash cost is below the daily delay penalty (say 5,000/day). Once the cheapest available day costs more than 5,000, stop — further crashing loses money.

Three expert tips for crashing

Only crash activities on the critical path

Shortening a non-critical activity spends money without moving the finish date. Always confirm an activity is critical before paying to crash it.

Watch for the path switching

Each day you crash can make a parallel path critical. Recompute the critical path after every crash, or you will pay to shorten a path that no longer controls the finish.

Compare crash cost to the delay penalty

Crashing is worth it only while the cost per day is less than the liquidated damages or opportunity cost of being late. Stop at the point where they cross.

Frequently asked questions

Sources, disclaimer and editorial transparency

This calculator applies the standard time–cost trade-off method: cost slope = (crash cost − normal cost) / (normal time − crash time), maximum crash = normal time − crash time, and an iterative least-cost algorithm that crashes the lowest-slope critical-path activities one unit at a time, recomputing the critical path (and handling multiple critical paths) after each step until a target duration or the crash limit is reached.

This is consistent with standard project-management and operations references such as the PMBOK Guide. This calculator and guide are created and reviewed by the OpsCalculators team; see our Editorial Policy for how each tool is researched, built, and tested.

Results are accurate estimates for planning and education, not certified scheduling or cost-engineering advice, and they assume finish-to-start dependencies and a constant (linear) cost slope over each activity’s crashable range. Validate the final crash steps against real quotes, and weigh indirect costs and any deadline penalties to choose the least-total-cost duration rather than simply the shortest. OpsCalculators.com is operated by MAFHH INTERNATIONAL LTD. Your data is processed in your browser and never stored; see our Privacy Policy.