OR-Notes

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 were originally used by me in an introductory OR course I give at Imperial College. 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.

Network analysis - cost/time tradeoff One important extension to the basic network analysis technique relates to project cost/ project time tradeoff. 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 before, for which the network diagram is reproduced below.

the normal cost is 100 associated with a normal time of 6 weeks.Introducing costs into this problem we have the package input shown below. For activity 1. . The output from the package for this example is shown below. and the crash cost is 240 associated with a crash time of 4 weeks. for example.

This will reduce the length (duration) of the critical path 1-3-5-7-8-911 by one week. Clearly unless we crash an activity on this critical path we can never reduce the completion time of the entire project. 5.e.but which ones? The solution associated with 24 weeks has one critical path.e.so in this case we would choose to crash activity 8 by one week at an additional cost of 20. Crashing As seen above we can have any possible project completion time between 24 and 16 weeks . If we were to adopt the crash times for each and every activity we would have: indicating that the project can take anywhere between 24 and 16 weeks depending upon the activity completion time (which can vary between the normal time and the crash time).but which one shall we choose? To help us answer this question let us first consider 23 weeks. . i. 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 . namely 1-3-5-7-8-9-11. Plainly to achieve a project completion time of 23 weeks this we need to crash (reduce) the completion time of one (or more) activities . Of these activities only 1. from 24 weeks to 23 weeks.The above calculation is based upon the normal times for each activity. i. we wish to move from the normal time project duration of 24 weeks to a project duration of 23 weeks.

The new situation is: Suppose now we wish to reduce the project by a further week. choosing to crash the critical activity with the lowest incremental cost is guaranteed to be an optimal approach (i.e. In fact in this situation we would need to consider three options: crash both A and B by one time unit crash E by one time unit crash F by one time unit to determine the best approach. We would still need to crash one activity on B-E-F before we could reduce the completion time for the entire project. i. 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. 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 .e. Indeed we stressed the word perfectly above. 5. Returning for the moment to our network above the solution associated with 23 weeks has one critical path. to 22 weeks. However once we encounter two or more critical paths we cannot guarantee that we can still crash the project in an optimal way. as before. More technically. In such cases the activity with the lowest incremental cost may not be the best choice. Of these activities only 1. Plainly we will adopt the same approach as before: examine all activities in the current critical path which are capable of being crashed choose to crash the activity with the lowest incremental cost This procedure works perfectly until we reach a situation in which there are two or more critical paths. we crash in the best possible way) provided we have only a single critical path. namely 1-3-5-7-89-11. Clearly once there is more than one critical path the situation becomes more complicated.

This will reduce the length (duration) of the critical path 1-3-5-7-8-911 by one week.e. and eventually we would have crashed the network down to its lowest possible completion time of 16 weeks. i. The advantage of using linear programming to crash a project is that we can automatically guarantee that. As discussed previously we can formulate a network problem using linear programming. for any particular project completion time.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 20. Hence we could continue as above. This formulation can be easily modified to deal with the problem of crashing (as will be seen later below). because of the difficulty of dealing with multiple critical paths. we have achieved that time by crashing in a minimum cost fashion. The package calculates the optimal (minimum cost) way to crash the project using linear programming. . 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. from 23 weeks to 22 weeks. not lead us to a minimum cost solution for each possible project completion time. Crashing using incremental costs may. 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 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). the minimum cost associated with achieving that completion time. By varying the number of weeks by which we crash the project we can construct the graph shown below. This contrasts with the cost of 870 associated with using all activities at their crash times.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. It can be seen that this can be done for a cost of 820.e. In general it is always true that the cost/time tradeoff graph contains a number of distinct straight line segments (i. 18 to 21. 21 to 24). activity 8 by three weeks and activity 9 by one week. . mathematically we would say that it is piecewise linear). The output below shows the minimum cost way of achieving the lowest possible overall project completion time of 16 weeks. This arises because of the linear relationship that was assumed to hold between cost and completion time for each activity. for each possible project completion time. Note here that this graph contains three distinct straight line segments (16 to 18. In that graph we have plotted.

1d (and their precedence relationships). Exploring the package Because cost crashing can be modelled and solved via linear programming we have a number of alternative options available. but with a caveat. A common approach to do this is activity splitting. from the original 6 weeks. Activity splitting For the network considered above we have seen that the minimum possible completion time (associated with the maximum cost) is 16 weeks. as the package illustrates.1c. . If we could now crash activity 1b by 2 weeks and activity 1c by 3 weeks then we could crash activity 1 down from 7 weeks to 3 weeks . opening up the possibility of (potentially) reducing the overall project completion time below 16 weeks. It does not tell you which completion time you should choose (as you can have any completion time between 16 and 24 weeks provided you are prepared to pay for it!).1b. for the network considered before we might decide that activity 1. For example before subdivision we could only crash activity 1 down from 6 weeks to 4 weeks. This is illustrated below using the package for a total cost of 550. But what if we really wanted a completion time of 15 weeks . For example we might be interested in finding the minimum time in which we can complete the project subject to a constraint (limitation) upon the total cost.is there any possible way of achieving that? The simple answer is NO. gives us more flexibility. requiring 6 weeks can be split as below: Here we have split this activity into 4 sub-activities 1a. What the package does is enable you. Obviously the practicality of subdividing. It can be seen that by so doing we have actually increased the time required to complete activity 1 to 7 weeks. In activity splitting we (typically) examine each critical activity (since critical activities are the determining factor in overall project completion) and see if they can be split into two (or more) separate activities.hence potentially reducing the overall project duration below the 16 week barrier we previously encountered. For example. and then crashing. critical activities depends upon the context but the above example does illustrate that sometimes close examination of critical activities with a view to subdivision can pay benefits. in this case the cost of the project for all possible completion times between 16 and 24 weeks. it may be that this subdivision of activity 1. when considered from the cost crashing point of view. as the project manager. not with the project as currently represented by the network. It may be that we can change our project network. However.Note there that the package merely provides information. to make an informed choice about the completion time to have.

5 weeks.It can be seen above that the minimum completion time subject to a cost constraint of 550 is 21. . The package also allows us to balance rewards in meeting a target desired project completion time as against penalties for missing this completion time. The example below illustrates this where the desired project completion time is 20 weeks. each week we are late (complete after week 20) costs us 50 and each week we are early (complete before week 20) earns us a reward of 75.

leading to a total minimum cost of 530. let us return to the original network we had before with the original crashing data as illustrated below.It can be seen that the optimum (least cost) completion time in this situation is 18 weeks. So. The assumption behind PERT/Cost is that cost per unit of time for an activity is constant between its start time and its finish time. Deciding to complete the project in 18 weeks gives the output below. For example. PERT/Cost PERT/Cost is a way of showing the budgeted project cost based on the activity start times. The basic assumption in PERT/Cost is that the cost of an activity is spread uniformly over its duration. for example. activity .

the cost of 50 per week associated with activity 2 would not be incurred until week 4. Whilst any activities which are critical must be performed at precise times in order to complete the overall project in 18 weeks is the same true of non-critical activities? For this project with a completion time of 18 weeks the Activity Criticality Analysis is Activity 2. i. If we were to start it in week 4. In PERT/Cost we can produce a graphic (as below) showing the cost of the project based on each activity starting at its earliest start (ES) time based on each activity starting at its latest start (LS) time This is shown below for the project considered above completing in 18 weeks. 100/2 = 50 for each week during which activity 2 is done. for example.e. We have stressed above the weeks during which an activity is done. It can potentially be started at any time between week 0 (its earliest start time) and week 6 (its latest start time) without affecting the overall project completion time. .e. 100/6 = 16. i. In that figure the ES line is shown in purple. This may potentially be of benefit (why incur a cost before you need to?).67 for each week during which activity 1 is done. Activity 2. for example (which requires 2 weeks) is non-critical and has a slack of 6 weeks.1. with a suggested time of 6 costs us 100. with a suggested time of 2 costs us 100. and the LS line in blue.

Supposing that we are using just normal times (and costs) and that it is currently week 10. Project progress monitoring The package contains two facilities for monitoring the progress of the project. It is important to note however that artificially delaying the start of non-critical activities (and hence incurring activity costs later) is not free. Rather it costs us. one with respect to time and the other with respect to cost.cost can be adjusted within the ES and LS limits by artificially delaying the start of non-critical activities. Then we can get an indication of the time progress of the project by Solve Critical Path Using Normal Times and then using Project Completion Analysis to get the . Simply put time lost by delaying the start of an activity cannot later be regained (if things do not turn out as planned) given the desired fixed completion time for the overall project.The gap between the cumulative ES and LS lines represents flexibility . To illustrate these we have expanded the input as below to include the actual cost incurred so far on each activity and the percentage by which it has completed.

Crashing by linear programming Recall that previously we formulated our network problem as a linear program. To remind you of it we briefly repeat this formulation below. This just makes the calculations we have to do easier to follow. However note that we have now added a dummy activity (12) with a completion time of zero to represent the end of the project. Using Project Cost Control we can get an indication of the cost progress of the project at the same time as below.output below. . Below we repeat the network diagram for the problem we considered before.

In order to analyse this network by linear programming let xi (>=0) represent the time at which we start activity i... Then the linear programming formulation of the above network problem is minimise x12 subject to x3 >= x1 + 6 x4 >= x2 + 2 x5 >= x3 + 3 x6 >= x4 + 2 x7 >= x5 + 4 x7 >= x6 + 1 x8 >= x7 + 1 x9 >= x8 + 6 x10 >= x8 + 6 x11 >= x9 + 3 x11 >= x10 + 1 x12 >= x11 + 1 xi >=0 i=1.2. Now to expand this formulation to include cost crashing let ci be the number of time units (weeks in this case) by which we choose to crash (reduce) the completion time of activity i...12 and note here that the activity completion times used here correspond to the normal times for our cost crashing example. Recalling the problem (as below) .

c8 x11 >= x9 + 3 .8. since the completion time for activity 1 has effectively changed to 6-c1.c1. Hence the first constraint x3 >= x1 + 6 which says that the start time for activity 3 must be at least as big as the start time for activity 1 plus 6 (the completion time for activity 1) is now changed to x3 >= x1 + 6 .c5 x7 >= x6 + 1 x8 >= x7 + 1 x9 >= x8 + 6 . Note that the cost associated with c1 is 70c1. since each week that we crash activity 1 costs us 70.2.c1 x4 >= x2 + 2 . These crash variables must satisfy 0 <= c1 <= 2 (activity 1 can be crashed by at most 2 time units) 0 <= c2 <= 1 (activity 2 can be crashed by at most 1 time units) 0 <= c5 <= 2 (activity 5 can be crashed by at most 2 time units) 0 <= c8 <= 3 (activity 8 can be crashed by at most 3 time units) 0 <= c9 <= 1 (activity 9 can be crashed by at most 1 time units) The key to amending the formulation is to note that wherever a completion time for an activity appears in the formulation above it must be changed to completion time .crash variable. Continuing in this vein the complete LP formulation of the problem of determining the minimum cost way of crashing the project to achieve a given completion time T is given by minimise 70c1 + 50c2 + 40c5 + 20c8 + 40c9 subject to x12 = T x3 >= x1 + 6 .5.9 can be crashed in this example so we need only define crash variables for those activities.we have that only activities 1.c9 x11 >= x10 + 1 x12 >= x11 + 1 0 <= c1 <= 2 .c2 x5 >= x3 + 3 x6 >= x4 + 2 x7 >= x5 + 4 .c8 x10 >= x8 + 6 .

This linear program (LP) can be solved using the package as below..12 To ease the notation below we will refer to all the constraints above (excluding the single constraint x12 = T) as the constraint set CS... The input (in part) needed to enter the LP is: with the solution being .2.0 <= c2 <= 1 0 <= c5 <= 2 0 <= c8 <= 3 0 <= c9 <= 1 xi >= 0 i=1. for T=19..

This is because it is commonly believed that the problem of finding the best project completion time when there were penalties for late completion and rewards for early completion can be correctly solved using just a single LP. but has a different structure. as the example below illustrates. More formally the LP associated with assuming that we finish "early" is minimise 70c1 + 50c2 + 40c5 + 20c8 + 40c9 . To achieve this we simply need the LP minimise x12 subject to the constraint set CS we had before and 70c1 + 50c2 + 40c5 + 20c8 + 40c9 <= cost limit The package also had the facility to find the best project completion time when there were penalties for late completion and rewards for early completion. not variables. Indeed this is the approach used by the package. Then to find the best project completion time the ONLY APPROPRIATE APPROACH is to solve two LPs. To formulate this let the desired completion time be D. This solution of two LPs as being the only appropriate approach is stressed above. Here we have decided to crash activity 5 by two weeks and activity 8 by three weeks. Comparing the cost of the optimal solutions to these LPs will give us the best project completion time.This has the same additional cost of 140 as before. Note that all these are known numbers. the penalty for late completion be P per time unit (week in this case) late. In the results from the package for crashing 19 weeks before we crashed activity 5 by one week. However this is simply incorrect.x12) subject to the constraint set CS we had before and x12 <= D (finish at or before the desired completion time) . In fact this original structural solution can be found by using Obtain Alternative Optimal to get The package also had the facility to find the minimum project completion time satisfying a cost constraint. activity 8 by three weeks and activity 9 by one week. the reward for early completion be R per time unit (week in this case) early.R*(D . One assuming we finish "early" and the other assuming we finish "late".

D) subject to the constraint set CS we had before and x12 >= D (finish at or after the desired completion time) With D=20. which was the case dealt with by the package before above. the LP for finishing early can be solved as below to give a solution with x12=16 and cost 20 (after adjusting the cost of the LP for the constant term -R*D = -75*20 = -1500 in this case) The LP for finishing late can be solved as below to give a solution with x12=20 and cost 100 (after adjusting the cost of the LP for the constant term -P*D = -50*20 = -1000 in this case) .Similarly the LP associated with assuming that we finish "late" is minimise 70c1 + 50c2 + 40c5 + 20c8 + 40c9 + P*(x12 . R=75 and P=50.

Note that in computing this cost figure of 20 we have not accounted for the total ordinary Normal Cost (since that must be incurred anyway) and so adding this in (total cost 500) we have that this solution is of value 520.300 = 520. In fact we could have detected that the package solution was in error before now. This was obtained using the (incorrect) single LP approach. The same cost as given by our correct two LP approach but contradicting the cost of 530 given by the package using the single LP approach. . Compare now the solution obtained by the package. Now finishing in 16 weeks incurs a reward of 4*75 = 300 giving a total cost of 820 .the best solution is to finish in 20 weeks at a cost of 100 Hence overall the best solution is to crash the project to complete in 16 weeks. which was of total cost 530 associated with a completion time of 18 weeks.the best solution is to finish in 16 weeks at a cost of 20 finishing "late" . at a total crashing cost (after rewards for early completion) of 20. We actually crashed the project to 16 weeks and had an associated cost of 820.Hence using our two LP approach it is clear that: finishing "early" .