Project Crashing and Time-Cost Trade-Off Project crashing is a method for shortening the project duration by reducing the time of one (or The linear relationships between crash cost and crash time and between normal cost and normal. Time and Cost Minimizing for Successful Completion of a Large Scale Project by Applying Project Crashing Method. Article (PDF Path Method (CPM) and Project Crashing Method are .. at event j, the relationship can be expressed as t he. Keywords: Project Management, Critical Path, Crashing, Time-Cost Trade-Off 1. Two of the most widespread methodologies to project managing are . Plot the time-cost trade-off graph by linear interpolation between the.
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 can be crashed by the total amount of 5 weeks without another path becoming critical, since activity is included in all four paths in the network.
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.
Activity 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 by only 1 week. Crashing activity by 1 week does not result in any other path becoming critical, so we can safely make this reduction. Crashing activity to 7 weeks i. 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 is 7 weeks, activity is 5 weeks, is 3 weeks, and so on. The critical path of this totally crashed network is with a project duration of 24 weeks.
This is the least amount of time the project can be completed in. 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.
Chapter 17, Head 5
Since the possibility exists that an additional path might become critical each time the network is reduced by even one unit of time e. 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 J E Beasley OR-Notes are a series of introductory notes on topics that fall under the broad heading of the field of operations research OR.
They are now available for use by any students and teachers interested in OR subject to the following conditions.
A full list of the topics available in OR-Notes can be found here. In this extension to the basic method we assume that, for each activity, the completion time can be reduced within limits by spending more money on the activity. Essentially each activity now has more than one possible completion time depending upon how much money we are willing to spend on it.
This use of cost information is the CPM technique.
A common assumption is to say that for each activity the completion time can lie in a range with a linear relationship holding between cost and activity completion time within this range as illustrated below. Reducing an activity completion time is known as "crashing" the activity and to illustrate this concept consider the activity on node network we had beforefor which the network diagram is reproduced below.
Introducing costs into this problem we have the package input shown below. For activity 1, for example, the normal cost is associated with a normal time of 6 weeks, and the crash cost is associated with a crash time of 4 weeks.
The output from the package for this example is shown below. The above calculation is based upon the normal times for each activity. If we were to adopt the crash times for each and every activity we would have: Crashing As seen above we can have any possible project completion time between 24 and 16 weeks - but which one shall we choose?
To help us answer this question let us first consider 23 weeks, i. Plainly to achieve a project completion time of 23 weeks this we need to crash reduce the completion time of one or more activities - but which ones? The solution associated with 24 weeks has one critical path, namely Clearly unless we crash an activity on this critical path we can never reduce the completion time of the entire project.
Of these activities only 1, 5, 8 and 9 are capable of being crashed: This will reduce the length duration of the critical path by one week, i. The new situation is: Suppose now we wish to reduce the project by a further week, i.
Plainly we will adopt the same approach as before: In such cases the activity with the lowest incremental cost may not be the best choice. For example if there are two critical paths A-E-F and B-E-F in a network and activity A has the lowest incremental cost then crashing activity A will have no effect on the critical path B-E-F, and hence no effect on the overall project completion time. We would still need to crash one activity on B-E-F before we could reduce the completion time for the entire project.
In fact in this situation we would need to consider three options: Clearly once there is more than one critical path the situation becomes more complicated. Indeed we stressed the word perfectly above. More technically, choosing to crash the critical activity with the lowest incremental cost is guaranteed to be an optimal approach i.
However once we encounter two or more critical paths we cannot guarantee that we can still crash the project in an optimal way. Returning for the moment to our network above the solution associated with 23 weeks has one critical path, namelyas before.
Of these activities only 1, 5, 8 and 9 are capable of being crashed if we were to crash activity 1 by one week we would incur an additional cost of 70 if we were to crash activity 5 by one week we would incur an additional cost of 40 if we were to crash activity 8 by one week we would incur an additional cost of 20 if we were to crash activity 9 by one week we would incur an additional cost of 40 Clearly the best choice is to crash the activity with the lowest incremental additional cost - so in this case we would choose to crash activity 8 by one week at an additional cost of Hence we could continue as above, and eventually we would have crashed the network down to its lowest possible completion time of 16 weeks.
Package crashing Whilst you might expect that the package would crash the project in the same manner as considered above look at incremental costs in fact it uses a totally different approach. The package calculates the optimal minimum cost way to crash the project using linear programming.
As discussed previously we can formulate a network problem using linear programming. This formulation can be easily modified to deal with the problem of crashing as will be seen later below. The advantage of using linear programming to crash a project is that we can automatically guarantee that, for any particular project completion time, we have achieved that time by crashing in a minimum cost fashion.
Crashing using incremental costs may, because of the difficulty of dealing with multiple critical paths, not lead us to a minimum cost solution for each possible project completion time.
The package output giving the cost associated with crashing the project from its normal completion time of 24 weeks to 19 weeks for example is given below. It can be seen that the minimum cost way to achieve an overall project completion time of 19 weeks is by crashing activity 5 by one week, activity 8 by three weeks and activity 9 by one week. The output below shows the minimum cost way of achieving the lowest possible overall project completion time of 16 weeks.
It can be seen that this can be done for a cost of This contrasts with the cost of associated with using all activities at their crash times.
The difference arises because it is not necessary to crash all activities to their maximum extent to achieve an overall project completion time of 16 in this case activity 2 does not need to be crashed. By varying the number of weeks by which we crash the project we can construct the graph shown below.
In that graph we have plotted, for each possible project completion time, the minimum cost associated with achieving that completion time. Note here that this graph contains three distinct straight line segments 16 to 18, 18 to 21, 21 to