Project Crashing and TimeCost Trade-off


[Page 352]

Project Crashing and TimeCost Trade-off

To this point we have demonstrated the use of CPM and PERT network analysis for determining project time schedules. This in itself is valuable to a manager planning a project. However, in addition to scheduling projects, a project manager is frequently confronted with the problem of 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 or PERT network analysis.

Project duration can be reduced by assigning more labor to project activities, often in the form of overtime, and by assigning more resources (material, equipment, etc.). However, additional labor and resources cost money and hence increase the overall 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 project duration by reducing the time of one or more of the critical project activities to a time that is less than the normal activity time. This reduction in the normal activity times is referred to as crashing . Crashing is achieved by devoting more resources, measured in terms of dollars, to the activities to be crashed.

Project crashing shortens the project time by reducing critical activity times at a cost .


To demonstrate how project crashing works, we will employ the network for constructing a house shown in Figure 8.8. This network is repeated in Figure 8.19, except that the activity times previously shown as months have been converted to weeks. Although this example 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.

Figure 8.19. The project network for building a house


In Figure 8.19, we will assume that the times (in weeks) shown on the network activities are the normal activity times . For example, normally 12 weeks are required to complete activity 1. Furthermore, 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 can be completed in 7 weeks, but it will cost $5,000 to complete the activity instead of $3,000. This new estimated activity time is known as the crash time , and the revised cost is referred to as the crash cost .


[Page 353]

Activity 1 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 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 by only 2 weeks (for an activity time of 10 weeks), the crash cost would be $800 ($400 per week x 2 weeks). The linear relationships between crash cost and crash time and between normal cost and normal time are illustrated in Figure 8.20.

Figure 8.20. Timecost relationship for crashing activity 1.


Crash cost and crash time have a linear relationship.


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 8.19 are summarized in Table 8.4.

Table 8.4. Normal activity and crash data for the network in Figure 8.19
(This item is displayed on page 354 in the print version)

Activity

Normal Time (weeks)

Crash Time (weeks)

Normal Cost

Crash Cost

Total Allowable Crash Time (weeks)

Crash Cost per Week

1

12

7

$ 3,000

$ 5,000

5

$ 400

2

8

5

2,000

3,500

3

500

3

4

3

4,000

7,000

1

3,000

4

12

9

50,000

71,000

3

7,000

5

4

1

500

1,100

3

200

6

4

1

500

1,100

3

200

7

4

3

15,000

22,000

1

7,000

     

$75,000

$110,700

   

Recall that the critical path for the house-building network encompassed activities 1 2 4 7, and the project duration was 9 months, or 36 weeks. Suppose that the home builder needed the house in 30 weeks and wanted to know how much extra cost would be incurred to complete the house in this time. To analyze this situation, the contractor would crash the project network to 30 weeks, using the information in Table 8.4.

As activities are crashed, the critical path may change, and several paths may become critical .


The objective of project crashing is to reduce the project duration while minimizing the cost of crashing. Because 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 further reduce the project completion time.


[Page 354]

We start the crashing process by looking at the critical path and seeing which activity has the minimum crash cost per week. Observing Table 8.4 and Figure 8.21, we see that on the critical path, activity 1 has the minimum crash cost of $400. Thus, activity 1 will be reduced as much as possible. Table 8.4 shows that the maximum allowable reduction for activity 1 is 5 weeks, but we can reduce activity 1 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 incur 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. Later we will demonstrate an alternative method for project crashing, using linear programming; however, for the moment we will pursue this example in order to demonstrate the logic of project crashing.

Figure 8.21. Network with normal activity times and weekly activity crashing costs


It turns out that activity 1 can be crashed by the total amount of 5 weeks without another path's becoming critical because activity 1 is included in all four paths in the network. Crashing this activity results in a revised project duration of 31 weeks, at a crash cost of $2,000. The revised network is shown in Figure 8.22.


[Page 355]
Figure 8.22. Revised network with activity 1 crashed


This process must now be repeated. The critical path in Figure 8.22 remains the same, and the new minimum activity crash cost on the critical path is $500 for activity 2. Activity 2 can be crashed a total of 3 weeks, but because the contractor desires to crash the network to only 30 weeks, we need to crash activity 2 by only 1 week. Crashing activity 2 by 1 week does not result in any other path's becoming critical, so we can safely make this reduction. Crashing activity 2 to 7 weeks (i.e., a 1-week reduction) costs $500 and reduces the project duration to 30 weeks.

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

As indicated earlier, the manual procedure for crashing a network is very cumbersome and generally unacceptable for project crashing. It is basically a trial-and-error approach that is useful for demonstrating the logic of crashing; however, 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.

Project Crashing with QM for Windows

QM for Windows also has the capability to crash a network completely . In other words, it crashes the network by the maximum amount possible. In our house-building example in the previous section, we crashed the network to only 30 weeks, and we did not consider by how much the network could have actually been crashed. Alternatively, QM for Windows crashes a network by the maximum amount possible. The QM for Windows solution for our house-building example is shown in Exhibit 8.16. Notice that the network has been crashed to 24 weeks, at a total crash cost of $31,500.


[Page 356]
Exhibit 8.16.

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 direct resources. The implicit objective of crashing was to reduce the scheduled completion time for its own sakethat is, to reap the results of the project sooner. However, there may be other important reasons for reducing project time. As projects continue over time, they consume various indirect costs , including the cost of facilities, equipment, and machinery; interest on investment; utilities, labor, and 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.


[Page 357]

Management Science Application: Reconstructing the Pentagon After 9/11

(This item is displayed on page 356 in the print version)

On September 11, 2001, at 9:37 A.M. , American Airlines flight 77, which had been hijacked by terrorists, was flown into the west face of the Pentagon in Arlington, Virginia. More than 400,000 square feet of office space was destroyed, and an additional 1.6 million square feet was damaged. Almost immediately, the "Phoenix Project" to restore the Pentagon was initiated. A deadline of 1 year was established for project completion, which required the demolition and removal of the destroyed portion of the building, followed by the building restoration, including restoration of the limestone facade. The Pentagon consists of five rings of offices (housing 25,000 employees ) that emanate from the center of the building; ring A is the innermost ring, and ring E is the outermost. Ten corridors radiate out from the building's hub, bisecting the ring, and forming the Pentagon's five distinctive wedges. At the time of the attack, the Pentagon was undergoing a 20-year, $1.2 billion renovation program, and the renovation of Wedge 1, which was demolished in the 9/11 attack, was nearing completion. As a result, the Phoenix Project leaders were able to use the Wedge 1 renovation project structure and plans as a basis for their own reconstruction plan and schedule, saving much time in the process. Project leaders were in place and able to assign resources on the very day of the attack. The project included more than 30,000 activities and a 3,000-member project team and required 3 million person-hours of work. Over 56,000 tons of contaminated debris was removed from the site, 2.5 million pounds of limestone was used to reconstruct the facade (using the original drawings from 1941), 21,000 cubic yards of concrete was poured, and 3,800 tons of reinforcing steel was placed. The Phoenix Project was completed almost a month ahead of schedule and nearly $194 million under the original budget estimate of $700 million.

Source: N. Bauer, "Rising from the Ashes," PM Network 18, no. 5 (May 2004): 2432.


Crash costs increase as project time decreases; indirect costs increase as project time increases .


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

Figure 8.23. The timecost trade-off





Introduction to Management Science
Introduction to Management Science (10th Edition)
ISBN: 0136064361
EAN: 2147483647
Year: 2006
Pages: 358

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net