Your Training Partner
Techniques Toolbox
Three lanes showing crashing and fast tracking on the same Design, Development, Testing sequence: fast tracking overlaps the activities, crashing adds resources to them, both save three weeks.

Crashing and Fast Tracking

Crashing and fast tracking are the two schedule compression techniques that the PMBOK Guide names: they shorten a project's duration without reducing its scope. Crashing adds resources to activities and pays for the time saved in money. Fast tracking overlaps activities planned one after the other and pays for the time saved in rework risk. Both act only on the critical path. They are used when the project's calculated finish falls after the imposed date, whether the schedule is still being developed or the project is already running late.

Goal

Schedule compression shortens a project's duration through two levers without reducing its scope. By the PMBOK Guide's definitions, crashing seeks that gain at the lowest additional cost; fast tracking performs in parallel, for at least part of their duration, activities or phases planned in sequence.

The problem is a gap between two dates: the finish that the schedule's logic network calculates and the one that a contract, a law or a sponsor imposes. When the imposed date comes before the calculated finish, the total float of the critical path turns negative, and its absolute value gives the number of days to recover. With this technique the project manager decides which activities to shorten, by which lever and at what added cost and risk. The calculation can also show that the date is out of reach.

The deliverable is a compressed schedule: the shortened activities, the modified links, the added cost, the risks entered in the register and the new finish date. The PMBOK Guide places compression among the tools of schedule development (§2.3.2.2, adjustment step) and of schedule control (§2.3.2.3).

Usage

When to use it

  • Imposed date earlier than the calculated finish: negative total float on the critical path.
  • Delay observed during execution: get back to the date in the schedule baseline.
  • Delay charged by the day: a contractual penalty, double rent or an idle team, to be weighed against the cost of each week saved.
  • Fixed external window: a regulation entering into force, a road's summer closure, the year-end accounting close.
  • Prepared response to a delay scenario: price the compression before the scenario occurs, starting from what-if scenario analysis.

When not to use it

  • No calculated logic network: without a critical path, nothing says where to compress; build the network first with the critical path method.
  • Negotiable scope: compression keeps all of it; if the sponsor agrees to remove some, decide through prioritization.

Description

Quantifying the gap on the critical path

Compression starts from a calculated logic network: the activities, their dependency links, their durations and the forward and backward passes that derive the early and late dates from them. The critical path is the sequence of activities with the lowest total float. The PMBOK Guide ties compression to the analysis of the negative float that an imposed date creates on that path.

Shortening an activity off the critical path does not bring the project finish closer. The activity gains float that nothing uses. The project manager also lists the near-critical paths, whose float exceeds that of the critical path by only a few days: they become critical as soon as compression has used up that difference, and they bound what it can gain. Many scheduling tools let the user set the criticality threshold. The planner sets the threshold to the gain sought: with three weeks to recover, any path whose float exceeds the critical path's by less than three weeks shows as near-critical before the first reduction.

Two levers for one gap

In the network, crashing takes days off an activity; fast tracking replaces a finish-to-start link with an overlap. Both shorten the same path and combine on one project.

NormalDesignDevelopmentTestingFSFSFast trackingDesignDevelopmentTestingSS +2 wkSS +5 wkpossible reworkpossible reworkCrashingDesignDevelopmentTestingFSFSadded CHFadded CHF02468101214weeksnormal finish: 14 wkcompressed finish: 11 wk3 weeks saved
Three weeks saved in two ways on the same sequence. Crashing shortens development and testing by adding resources to them. Fast tracking keeps the durations and starts each activity before the previous one finishes. The overlap zones carry the risk of rework.

Crashing: adding resources

The PMBOK Guide gives overtime, additional resources and paying for expedited delivery as examples of crashing. Each of these works only on an activity whose duration depends on the resources working on it. Among the factors in estimating durations, the guide cites the law of diminishing returns: doubling the headcount does not always halve the duration, and beyond a threshold the added people lengthen it through knowledge transfer, the learning curve and coordination. An activity that only one specialist can do, the drying of a screed, a thirty-day appeal period or a one-month endurance test cannot be shortened by paying.

Hendrickson and Au, in their project management textbook from Carnegie Mellon University, note that going faster can cost more and degrade quality: overtime raises exposure to accidents and to errors that need correcting. Crashing therefore means checking the work done under compression more closely.

The cost slope

The PMBOK Guide's definition aims at the lowest additional cost without saying how to find it. Hendrickson and Au describe the classical method. For each critical activity the planner estimates two points: its normal duration with its direct cost, then its crash duration, the shortest that added resources can reach, with its cost. The crash cost includes checking and correcting the work done under compression; otherwise the slope understates the price of a week saved. The cost slope is the price of one unit of time saved:

slope = (crash cost − normal cost) / (normal duration − crash duration)

An eight-week development at CHF 96'000 that can come down to six weeks for CHF 108'000 costs CHF 6'000 per week saved.

5678990'00095'000100'000105'000110'000115'000activity duration (weeks)direct cost (CHF)2 weeks savedCHF 12'000often convex relationslope: CHF 6'000 per weekcrash durationnormal duration
The cost slope of the development in the example is CHF 6'000 per week: two weeks saved for an extra CHF 12'000. The straight line assumes a constant price per week. The dotted curve shows the convex relation, in which the last weeks cost more.

The straight line between the two points assumes that each intermediate week costs the same. The actual relation is often convex, with the last weeks costing more than the first. Sometimes it is a staircase: an activity given to one team or to two has only two possible durations. At step 2 of the procedure, such an activity shortens by the whole jump, at the cost of the whole jump.

Compressing step by step

  1. Rank the critical-path activities by increasing slope, leaving out those already at their crash duration.
  2. Shorten the cheapest one by one unit of time.
  3. Recalculate the network: finish date and critical path.
  4. If several paths have become critical, shorten an activity they share or one activity on each of them, comparing the sum of the slopes.
  5. Repeat until the target is reached.

The recalculation in step 3 is the one people skip. Each reduction narrows the gap between the critical path and the parallel paths. After a few reductions another path becomes critical, and a further reduction on the old one gains nothing. Hendrickson and Au present this procedure as a heuristic: it gives good schedules without guaranteeing the optimum, which only an examination of combinations of reductions can ensure. When each duration-cost relation is approximated by a straight line, a linear programming solver finds that optimum.

The procedure stops short of the target when no critical activity can come down any further: this lever cannot reach the date. The sponsor then receives the project's shortest duration, which Hendrickson and Au call the project-crash time: the duration that the critical path calculation gives when every activity is at its crash duration. The procedure also stops when the next week costs more than it returns, in penalty avoided or in project indirect costs saved.

Setting every activity to its crash duration gives the shortest duration at the highest cost. The same duration can be had for less, because the activities that do not become critical can keep a duration above their crash duration. Compression pushed to the limit also makes several paths critical at once, so that the slightest delay on any of them pushes out the finish. The project manager reviews the schedule reserve at the point where these paths converge.

Fast tracking: overlapping activities

The PMBOK Guide's example is building a structure's foundations before all the architectural drawings are complete. In the network, a full dependency becomes a partial one: a finish-to-start (FS) link becomes, for instance, a start-to-start (SS) link. The lag on the SS link sets how long after the predecessor's start the successor starts. The overlap equals the predecessor's duration minus that lag. An FS link with a lead, the number of days by which the successor starts before the predecessor finishes, has the same effect. Scheduling tools often enter a lead as a negative lag.

Only discretionary links lend themselves to overlapping. A mandatory dependency, imposed by law, by contract or by the nature of the work, stays in place: the roof framing waits for the walls. A discretionary dependency is a preferred sequence among other possible ones, based on good practice. The PMBOK Guide flags these dependencies as the ones to review when fast tracking. The reason recorded for such a sequence tells what breaking it puts at risk.

The successor starts on inputs that are still provisional. Any later change to the predecessor lands on work already done, which has to be redone. The exposed share is the work that the successor completes during the overlap. Expected rework is calculated like a risk, probability times impact: the exposed share multiplied by the probability that a change to the predecessor invalidates it. Two weeks of exposed development with a one-in-two chance of change give one week of expected rework. A design whose structural decisions are settled tolerates an overlap that a design still under discussion does not.

Overlapping demands more coordination between the teams, which adds a quality risk, and it can increase project costs. It also creates resource overallocations: two overlapped activities sometimes need the same people at the same time. Each change to the predecessor's provisional output must reach the successor before the successor builds on it. Across several sites that information arrives later, and the exposed work grows. Each overlap goes into the risk register with its expected rework, tracked through risk analysis and management. An overlap that saves three weeks and costs four in rework has lost a week.

Choosing the lever

The PMBOK Guide sets no order between the two levers. The choice follows what the project can absorb: an available budget and divisible activities for crashing, discretionary dependencies and inputs that are already stable for fast tracking. When one activity is both overlapped and crashed, the risks of the two levers add up.

CrashingFast tracking
What changes in the networkThe duration of an activityAn FS link becomes SS or receives a lead
What is paidOvertime, added resources, expedited deliveryExpected rework, coordination, resource overallocation
ConditionA critical activity whose duration depends on the assigned resourcesA discretionary critical link, predecessor inputs stable enough
Decision measureCost slope, in CHF per unit of time savedExpected rework: work exposed during the overlap, weighted by the probability of change
LimitCrash duration of each activityMandatory dependencies
The two levers compared. Crashing changes the duration of an activity and is paid for in money; fast tracking changes a link between two activities and is paid for in rework risk.

Getting the compressed schedule approved

The compressed schedule remains a proposal until it is approved. The people assigned to the modified activities check that the new dates fit their calendars and their other commitments. The project manager then looks for logic conflicts and for any need to level resources, as the PMBOK Guide calls for before the schedule baseline is set. The sponsor approves the added cost and the recorded risks. During execution, the compressed schedule goes through a change request.

AI considerations

A language model takes on the repetitive work: it extracts from the network the FS links between critical activities and flags those that look discretionary, for the team to confirm. It prepares the cost slope table from the estimates and the quotes, drafts a risk register entry for each overlap and formats the compressed schedule for the sponsor. It also writes the linear programming model that the solver will solve.

The calculation belongs to the scheduling tool or the solver. An addition error in a critical path recalculation does not show in a well-presented table. Only the people doing the work know whether it can be split among more people and whether a predecessor's inputs are stable enough to start on. The price of an added resource comes from a quote or a contract. A prompt sent to a hosted service carries hourly rates, supplier quotes and contractual penalties outside the organisation.

Examples

A municipality is launching an online service desk for the day a cantonal regulation enters into force. The network calculates 17 weeks; 14 remain. Two paths branch after the requirements analysis and merge again at go-live. The cost slope table ranks the activities of the initial critical path by increasing slope.

ActivityPathNormal duration (wks)Normal cost (CHF)Crash duration (wks)Crash cost (CHF)Slope (CHF/wk)Rank on the initial critical path
A. Requirements analysis1 and 2440'000352'00012'0003
B. Development1896'0006108'0006'0001
C. Integration testing1436'000345'0009'0002
D. Data migration21070'000880'0005'000off the critical path
E. Go-live1 and 218'00018'000incompressibleexcluded
Cost slope table. The slope of each activity is the added cost divided by the weeks saved. The rank orders the activities of the initial critical path, A-B-C-E, by increasing slope. D is off that path. Go-live cannot be compressed.
ReductionActivity shortenedPath 1: A-B-C-E (wks)Path 2: A-D-E (wks)Project finish (wks)Cumulative added cost (CHF)
Startnone1715170
1B, from 8 to 71615166'000
2B, from 7 to 6, crash duration reached15151512'000
3A, from 4 to 3 (C and D together: 14'000)14141424'000
The successive reductions. Once two weeks have been taken off development, both paths are critical; the third reduction falls on requirements analysis, which shortens both.

Two faulty rankings miss the third reduction. Frozen on the initial critical path, the ranking proposes C, the next slope after B: C gains nothing on its own, because path A-D-E is also at 15 weeks. Extended to the whole table, it proposes D, the lowest slope, which also shortens only one of the two paths. A costs more than C or D alone but shortens both paths at once, for CHF 12'000 against CHF 14'000 for the pair C and D. The municipality meets the date for an added cost of CHF 24'000.

Visualisations

The example network after the second reduction shows why the third falls on A: A and E belong to both paths, B, C and D to one only. E cannot be compressed.

A4 wkB6 wkC4 wkD10 wkE1 wkon both paths2nd in the initial ranking,one path onlylowest slope,one path onlyincompressible4 + 6 + 4 + 1 = 15 wk4 + 10 + 1 = 15 wkA Requirements analysis B Development C Integration testing D Data migration E Go-live
The example network after the second reduction: both paths, A-B-C-E and A-D-E, are critical at 15 weeks. C and D each shorten only one path. A, on both paths, shortens them together. E is incompressible.

Cost

PhaseLevelJustification
PreparationMediumA calculated, up-to-date network, then a crash duration and its cost for each critical activity, taken from the teams and the quotes.
ExecutionLowA few reductions and recalculations in the scheduling tool, once the cost slope table is in place.
DocumentationMediumCompressed schedule, risks entered in the register, sponsor approval and new schedule baseline.

Tooling

Scheduling software such as MS Project, Primavera P6 or ProjectLibre holds the network, recalculates the critical path after each change and handles SS links and leads. Its comparison with the schedule baseline shows the sponsor, activity by activity, what the compressed schedule changes. A spreadsheet is enough for the cost slope table and for a network of about ten activities. Beyond that, recalculating the critical path by hand after each reduction becomes the source of errors.

The Solver in Excel or LibreOffice Calc solves the linear model: when each duration-cost relation is approximated by a straight line, it finds the least-cost combination of reductions for a target duration.

Sources

  • Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK Guide), 8th ed., PMI: schedule compression among the tools of schedule development (§2.3.2.2) and schedule control (§2.3.2.3); the definitions of compression, crashing and fast tracking, negative float, the criticality threshold, mandatory and discretionary dependencies, leads, the factors in estimating durations and the schedule reserve where several paths converge (Section 5 and §2.3.2.2).
  • Chris Hendrickson and Tung Au, Project Management for Construction, §11.4 "Crashing and Time/Cost Tradeoffs", Carnegie Mellon University: the relation between an activity's duration and its direct cost, the crash duration, the ranking of critical activities by the cost of one unit of time saved, the procedure of successive reductions and its limits, the project-crash time and the effect of speed on cost and quality.
Cost-Benefit Analysis
All techniques
Critical chain method