Network Analysis - Cost_time Tradeoff

8/13/2019 Network Analysis - Cost_time Tradeoff

1/18

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.
http://people.brunel.ac.uk/~mastjjb/jeb/or/netanal.htmlhttp://people.brunel.ac.uk/~mastjjb/jeb/or/contents.htmlhttp://people.brunel.ac.uk/~mastjjb/jeb/or/rights.htmlhttp://people.brunel.ac.uk/~mastjjb/jeb/jeb.html


2/18

Introducing costs into this problem we have thepackageinput shown below. For activity 1, for example, the normal cost is 100

associated with a normal time of 6 weeks, and the crash cost is 240 associated with a crash time of 4 weeks.

The output from the package for this example is shown below.
http://people.brunel.ac.uk/~mastjjb/jeb/or/software.html


3/18

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:

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).

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.e. we wish to move from the normal time project duration of 24

weeks to a project duration of 23 weeks. 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 1-3-5-7-8-9-11. 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:

if we were to crash activity 1 by one week we would incur an additional cost of 70




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. This will reduce the length (duration) of the critical path 1-3-5-7-8-9-

11 by one week, i.e. from 24 weeks to 23 weeks.


4/18

The new situation is:

Suppose now we wish to reduce the project by a further week, i.e. to 22 weeks. 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 perfectlyuntil we reach a situation in which there are two or more critical paths. 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:

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. 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 incrementa

cost is guaranteedto be an optimal approach (i.e. we crash in the best possible way) providedwe have only a single critical

path. 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, namely 1-3-5-7-8-

9-11, as before. Of these activities only 1, 5, 8 and 9 are capable of being crashed



5/18




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. This will reduce the length (duration) of the critical path 1-3-5-7-8-9-

11 by one week, i.e. from 23 weeks to 22 weeks.

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 thepackagewould 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 discussedpreviouslywe 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.
http://people.brunel.ac.uk/~mastjjb/jeb/or/netlp.htmlhttp://people.brunel.ac.uk/~mastjjb/jeb/or/lp.htmlhttp://people.brunel.ac.uk/~mastjjb/jeb/or/software.html


6/18

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 820. This contrasts with the cost of 870 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 minimumcost 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 24). In general it is always true

that the cost/time tradeoff graph contains a number of distinct straight line segments (i.e. mathematically we would say that it is

piecewise linear). This arises because of the linear relationship that was assumed to hold between cost and completion time for

each activity.


7/18

Note there that the package merely provides information, in this case the cost of the project for all possible completion times

between 16 and 24 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!). What the package does is enable you, as the project

manager, to make an informed choice about the completion time to have.

Activity splitting

For the network considered above we have seen that the minimum possible completion time (associated with the maximum costis 16 weeks. But what if we really wanted a completion time of 15 weeks - is there any possible way of achieving that?

The simple answer is NO, but with a caveat, not with the project as currently represented by the network. It may be that

we can change our project network, opening up the possibility of (potentially) reducing the overall project completion time

below 16 weeks. A common approach to do this is activity splitting.

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. For example, for the network considered before

we might decide that activity 1, requiring 6 weeks can be split as below:

Here we have split this activity into 4 sub-activities 1a,1b,1c,1d (and their precedence relationships). It can be seen that by so

doing we have actually increased the time required to complete activity 1 to 7 weeks, from the original 6 weeks. However, itmay be that this subdivision of activity 1, when considered from the cost crashing point of view, gives us more flexibility.

For example before subdivision we could only crash activity 1 down from 6 weeks to 4 weeks. 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 - hence potentially

reducing the overall project duration below the 16 week barrier we previously encountered.

Obviously the practicality of subdividing, 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.

Exploring the package

Because cost crashing can be modelled and solved via linear programming we have a number of alternative options available, as

the package illustrates. 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. This is illustrated below using the package for a total cost of 550.


8/18

It can be seen above that the minimum completion time subject to a cost constraint of 550 is 21.5 weeks.

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.


9/18

It can be seen that the optimum (least cost) completion time in this situation is 18 weeks, leading to a total minimum cost of 530.

PERT/Cost

PERT/Cost is a way of showing the budgeted project cost based on the activity start times. 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. For example, let us return to the

original network we had before with the original crashing data as illustrated below.

Deciding to complete the project in 18 weeks gives the output below.

The basic assumption in PERT/Cost is that the cost of an activity is spread uniformly over its duration. So, for example, activity


10/18

1, with a suggested time of 6 costs us 100, i.e. 100/6 = 16.67 for each week during which activity 1 is done. Activity 2, with a

suggested time of 2 costs us 100, i.e. 100/2 = 50 for each week during which activity 2 is done.

We have stressed above the weeks during which an activity is done. Whilst any activities which are critical must be performed a

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, for example (which requires 2 weeks) is non-critical and has a slack of 6 weeks. 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. If we were to start it in week 4, for example, the cost of 50 per week associated with activity 2 would not be incurred until

week 4. This may potentially be of benefit (why incur a cost before you need to?).

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) timebased on each activity starting at its latest start (LS) time

This is shown below for the project considered above completing in 18 weeks. In that figure the ES line is shown in purple, and

the LS line in blue.


11/18

The gap between the cumulative ES and LS lines represents flexibility - cost can be adjusted within the ES and LS limits by

artificially delaying the start of non-critical activities.

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. 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.

Project progress monitoring

The package contains two facilities for monitoring the progress of the project, one with respect to time and the other with

respect to cost. 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.

Supposing that we are using just normal times (and costs) and that it is currently week 10. 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


12/18

output below.

Using Project Cost Control we can get an indication of the cost progress of the project at the same time as below.

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.

Below we repeat the network diagram for theproblem we considered before. However note that we have now added a dummy

activity (12) with a completion time of zero to represent the end of the project. This just makes the calculations we have to do

easier to follow.
http://people.brunel.ac.uk/~mastjjb/jeb/or/netanal.html


13/18

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+ 4x7>= 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,...,12

and note here that the activity completion times used here correspond to the normal times for our cost crashing example.

Now to expand this formulation to include cost crashing let cibe the number of time units (weeks in this case) by which we

choose to crash (reduce) the completion time of activity i. Recalling the problem (as below)


14/18

we have that only activities 1,2,5,8,9 can be crashed in this example so we need only define crash variables for those activities.

These crash variables must satisfy

0 = x8+ 6 - c8

x10>= x8+ 6 - c8

x11>= x9+ 3 - c9

x11>= x10+ 1

x12>= x11+ 1

0


15/18

0


16/18

This has the same additional cost of 140 as before, but has a different structure. Here we have decided to crash activity 5 by

two weeks and activity 8 by three weeks. In the results from the package for crashing 19 weeks before we crashed activity 5 by

one week, activity 8 by three weeks and activity 9 by one week.

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. To achieve this we

simply need the LP

minimise x12

subject to the constraint set CSwe had before and

70c1+ 50c2+ 40c5+ 20c8+ 40c9


17/18

Similarly the LP associated with assuming that we finish "late" is

minimise 70c1+ 50c2+ 40c5+ 20c8+ 40c9+ P*(x12 - D)

subject to the constraint set CSwe had before and

x12>= D (finish at or after the desired completion time)

With D=20, R=75 and P=50, 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)


18/18

Hence using our two LP approach it is clear that:

finishing "early" - the best solution is to finish in 16 weeks at a cost of 20

finishing "late" - 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, at a total crashing cost (after rewards for early

completion) of 20. Note that in computing this cost figure of 20 we have not accounted for the total ordinary Normal Cost (sinc

that must be incurred anyway) and so adding this in (total cost 500) we have that this solution is of value 520.

Compare now the solution obtained by the package, which was of total cost 530 associated with a completion time of 18

weeks. This was obtained using the (incorrect) single LP approach.

In fact we could have detected that the package solution was in error before now. We actually crashed the project to 16 weeks

and had an associated cost of 820. Now finishing in 16 weeks incurs a reward of 4*75 = 300 giving a total cost of 820 - 300 =

520. 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.

Network Analysis - Cost_time Tradeoff

Documents

Transcript of Network Analysis - Cost_time Tradeoff