Schedule compression is a technique used in project management to shorten an already developed schedule. This might be done to meet an updated delivery date, a new opportunity, or catch up to the existing timeline due to a schedule delay. Schedule compression is done without changing the scope of the program.

Project delays can happen for many reasons:

• An unrealistic initial schedule

• Unavailability of promised resources

• Occurrence of unidentified risks

• Unexpected disaster/events

Other reasons for using schedule compression techniques include:

• The client or sponsors wants the project to be completed earlier than what was agreed

• You have an opportunity to work on another project if the current one completes early

• You want to reduce the product time to market in order to beat competitors

You can use one of two schedule compression techniques; ‘fast-tracking’ and ‘ project crashing’, to decrease the project’s duration without changing the project  scope. 

The PMBOK Guide, 6th edition, defines fast-tracking as a schedule compression technique in which activities or phases normally performed in a sequence are done in parallel for at least a portion of their duration.

Activities can be overlapped, started earlier than proposed, start activities that require different resources, and maybe combined activities in the schedule. This process does add some risk to the schedule and program and must be executed with care.

The PMBOK Guide, 6th edition, defines crashing as a technique used to shorten the schedule duration for the lowest incremental cost by adding resources.

Crashing is done by increasing the resources to the project, which helps make tasks take less time than what they were planned for. Of course, this also adds to the cost of the overall project. Therefore, the primary objective of project crashing is to shorten the project while also keeping costs at a minimum. In some cases the addition of new resources may not help to expedite the task as the newly added resources may not have the necessary skills and knowledge to execute the task as effectively as expected. 

Lead Vs Fast-Tracking

In a graphical diagram, a lead and fast tracking may look similar but in actual practice they are very different. Lead is a type of dependency that you use while developing a network diagram. It is already factored into the schedule. On the other hand, fast-tracking is a forced overlap that is carried out to shorten the schedule. Fast-tracking increases risks and potential rework, while lead is a dependency type on the network diagram and does not affect the risk.

Fast Tracking vs Crashing

The following are a few differences between fast-tracking and crashing:

• In fast-tracking, activities are rescheduled to be performed partially or fully in parallel, while in crashing, you add extra resources to the activities to finish them early.

• Fast-tracking does not cost you extra money; crashing does.

• Fast-tracking increases risks. Crashing does not, significantly.

• You use fast-tracking when activities can be overlapped to decrease their duration, while you use crashing on those where adding extra resources can decrease their duration.

Choosing between fast-tracking and crashing would depend on your situation and requirements. For example, if the client wants to complete the project early and is willing to pay, crashing may be much more suitable. Generally, you will start with fast-tracking to shorten the schedule but if fast-tracking doesn’t yield the desired results, crashing would be considered as it would start to incur additional costs.

Sometimes you may use both techniques. For example, the client may be threatening to issue a fine for the delay. To avoid this, you will need to compare the cost of crashing with the fine. If the crashing cost outweighs the fine, you will use it with fast-tracking for maximum schedule compression. You may also use crashing if the project delay will negatively affect the company’s image or credibility.

The schedule is based on the critical path which is the longest path of the network diagram and its duration is that of the project. Reducing other paths won’t reduce the duration of your project; it simply gives those paths more float. If you want to reduce the schedule duration, you have to shorten the duration of the critical path.