There are many reasons that you may need to compress a schedule at some point in a project. It may be that you have been delayed and are missing an important deadline; it may be that new factors have arisen that change a customer’s requirements or it may be that you can realise additional benefits if you complete a deliverable earlier than planned.

Whatever the circumstances that cause you consider schedule compression, beware! Both of the approaches described here reduce the inherent flexibility of your existing schedule and probably come with increased costs and risk. Before you compress a schedule, make sure that it is definitely necessary and the benefits outweigh the additional costs and risk.

Broadly speaking, there are two approaches to schedule compression – both assume that your schedule is based on a network diagram and both focus on the critical path. These are ‘fast-tracking’ and ‘crashing’:

Fast tracking

This technique simply plans some activities on the critical path to be performed in parallel rather than in series.
For example, you may be digging a trench, laying a cable and then backfilling the trench. For the sake of simplicity, let’s say that these activities take 10 days each. Obviously, when performed in series, the whole package takes 30 days.

Alternatively, you could start laying the cable once the people digging the trench have had a 5 day head start. Similarly, you could start backfilling the trench 5 days after the cable layers have started. The result is that the whole package is finished in 20 days.

Crashing

Crashing an activity means applying extra resource and cost to get it done as quickly as possible. So in the cable laying example, you may choose to bring in some extra equipment and additional labour or you may decide to bring in floodlights and work shifts. Either way the same amount of effort is performed in a shorter period of time.

In simple terms, if additional resources and/or shifts result in each of the three activities being performed in 7 days rather than 10, then then the work would be done in 21 days.

Other considerations

Fast-tracking and crashing are not mutually exclusive and could conceivably be combined to complete this job in even less time. But you would have to be convinced that the risk was worth it. The tighter the schedule, the more chance there is of things going wrong. This sort of extreme schedule compression should only be considered in exceptional circumstances and only for short periods of time.

You also need to be very aware of other paths in your network that have low amount of float.

If our three activities are on the critical path but there is another path that only has two days of float, then whatever compression you apply to the critical path, it will only reduce the project duration by two days before it simply shifts the critical path elsewhere.