# Project Crashing and Time-Cost Trade-Off

The project manager is frequently confronted with having to reduce the scheduled completion time of a project to meet a deadline. In other words, the manager must finish the project sooner than indicated by the CPM/PERT network analysis. Project duration can often be reduced by assigning more labor to project activities, in the form of overtime, and by assigning more resources (material, equipment, and so on). However, additional labor and resources increase the project cost. Thus, the decision to reduce the project duration must be based on an analysis of the trade-off between time and cost. Project crashing is a method for shortening the project duration by reducing the time of one (or more) of the critical project activities to less than its normal activity time. This reduction in the normal activity time is referred to as crashing. Crashing is achieved by devoting more resources, usually measured in terms of dollars, to the activities to be crashed.

## Project Crashing

To demonstrate how project crashing works, we will employ the CPM/PERT network for constructing a house in Figure 17.3. This network is repeated in Figure 17.12, except that the activity times previously shown as months have been converted to weeks. Although this sample network encompasses only single-activity time estimates, the project crashing procedure can be applied in the same manner to PERT networks with probabilistic activity time estimates.

We will assume that the times (in weeks) shown on the network activities are the normal activity times. For example, 12 weeks are normally required to complete activity 1-2. Further, we will assume that the cost required to complete this activity in the time indicated is \$3,000. This cost is referred to as the normal activity cost. Next, we will assume that the building contractor has estimated that activity 1-2 can be completed in 7 weeks, but it will cost \$5,000 instead of \$3,000 to complete the activity. This new estimated activity time is known as the crash time, and the cost to achieve the crash time is referred to as the crash cost.

Activity 1-2 can be crashed a total of 5 weeks (normal time - crash time = 12-7 = 5 weeks) at a total crash cost of \$2,000 (crash cost - normal cost = \$5,000-3,000 = \$2,000). Dividing the total crash cost by the total allowable crash time yields the crash cost per week:

If we assume that the relationship between crash cost and crash time is linear, then activity 1-2 can be crashed by any amount of time (not exceeding the maximum allowable crash time) at a rate of \$400 per week. For example, if the contractor decided to crash activity 1-2 by only 2 weeks (reducing activity time to 10 weeks), the crash cost would be \$800 (\$400 per week ¥ 2 weeks). The linear relationships between crash cost and crash time and between normal cost and normal time are illustrated in Figure 17.13.

The objective of project crashing is to reduce project duration while minimizing the cost of crashing. Since the project completion time can be shortened only by crashing activities on the critical path, it may turn out that not all activities have to be crashed. However, as activities are crashed, the critical path may change, requiring crashing of previously noncritical activities to reduce the project completion time even further.

 EXAMPLE17.4 Project Crashing

Recall that the critical path for the house building network in Figure 17.12 encompassed activities 1-2-3-4-6-7 and the project duration was 9 months, or 36 weeks. Suppose the home builder needed the house in 30 weeks and wanted to know how much extra cost would be incurred to complete the house by this time.

The normal times and costs, the crash times and costs, the total allowable crash times, and the crash cost per week for each activity in the network in Figure 17.12 are summarized in the following table:

SOLUTION:

We start by looking at the critical path and seeing which activity has the minimum crash cost per week. Observing the preceding table and the following figure, we see activity 1-2 has the minimum crash cost of \$400 (excluding the dummy activity 3-4, which cannot be reduced). Activity 1-2 will be reduced as much as possible. The table shows that the maximum allowable reduction for activity 1-2 is 5 weeks, but we can reduce activity 1-2 only to the point where another path becomes critical. When two paths simultaneously become critical, activities on both must be reduced by the same amount. If we reduce the activity time beyond the point where another path becomes critical, we may be incurring an unnecessary cost. This last stipulation means that we must keep up with all the network paths as we reduce individual activities, a condition that makes manual crashing very cumbersome. For that reason we will rely on the computer for project crashing; however, for the moment we pursue this example in order to demonstrate the logic of project crashing.

It turns out that activity 1-2 can be crashed by the total amount of 5 weeks without another path becoming critical, since activity 1-2 is included in all four paths in the network. Crashing this activity results in a revised project duration of 31 weeks at a crashing cost of \$2,000. The revised network is shown in the following figure.

Since we have not reached our crashing goal of 30 weeks, we must continue and the process is repeated. The critical path in the preceding figure remains the same, and the minimum activity crash cost on the critical path is \$500 for activity 2-3. Activity 2-3 can be crashed a total of 3 weeks, but since the contractor desires to crash the network only to 30 weeks, we need to crash activity 2-3 by only 1 week. Crashing activity 2-3 by 1 week does not result in any other path becoming critical, so we can safely make this reduction. Crashing activity 2-3 to 7 weeks (i.e., a 1-week reduction) costs \$500 and reduces the project duration to 30 weeks.

The total cost of crashing the project to 30 weeks is \$2,500. The contractor could inform the customer that an additional cost of only \$2,500 would be incurred to finish the house in 30 weeks.

Suppose we wanted to continue to crash this network, reducing the project duration down to the minimum time possible; that is, crashing the network the maximum amount possible. We can determine how much the network can be crashed by crashing each activity the maximum amount possible and then determining the critical path of this completely crashed network. For example, activity 1-2 is 7 weeks, activity 2-3 is 5 weeks, 2-4 is 3 weeks, and so on. The critical path of this totally crashed network is 1-2-3-4-6-7 with a project duration of 24 weeks. This is the least amount of time the project can be completed in. If we crashed all the activities by their maximum amount, the total crashing cost is \$35,700, computed by subtracting the total normal cost of \$75,000 from the total crash cost of \$110,700 in the preceding table. However, if we followed the crashing procedure outlined in this example, the network can be crashed to 24 weeks at a cost of \$31,500, a savings of \$4,000.

## Project Crashing with POM for Windows

The manual procedure for crashing a network is cumbersome. It is basically a trial-and-error approach useful for demonstrating the logic of crashing. It quickly becomes unmanageable for larger networks. This approach would have become difficult if we had pursued even the house building example to a crash time greater than 30 weeks, with more than one path becoming critical.

When more than one path becomes critical, all critical paths must be reduced by an equal amount. Since the possibility exists that an additional path might become critical each time the network is reduced by even one unit of time (e.g., 1 week, month), this means that a reduction of one time unit is the maximum amount that can be considered at each crashing step. Exhibit 17.2 shows the POM for Windows solution screen for crashing the house building network in Example 17.4 the maximum amount possible to a minimum project duration of 24 weeks.

## The General Relationship of Time and Cost

In our discussion of project crashing, we demonstrated how the project critical path time could be reduced by increasing expenditures for labor and other direct resources. The objective of crashing was to reduce the scheduled completion time to reap the results of the project sooner. However, there may be other reasons for reducing project time. As projects continue over time, they consume indirect costs, including the cost of facilities, equipment, and machinery, interest on investment, utilities, labor, personnel costs, and the loss of skills and labor from members of the project team who are not working at their regular jobs. There also may be direct financial penalties for not completing a project on time. For example, many construction contracts and government contracts have penalty clauses for exceeding the project completion date.

In general, project crashing costs and indirect costs have an inverse relationship; crashing costs are highest when the project is shortened, whereas indirect costs increase as the project duration increases. This time-cost relationship is illustrated in Figure 17.14. The best, or optimal, project time is at the minimum point on the total cost curve.

17-16. What is the purpose of project crashing analysis?

17-17. Describe the process of manually crashing a project network.

17-18. Discuss the relationship of direct and indirect costs in project management.

17-19. Describe the limitations and disadvantages of CPM/PERT.