Sei sulla pagina 1di 7

Rutgers University 33:623:386 Operations Management

Professor Eckstein jeckstei@rci.rutgers.edu

Lecture Notes: Chapter 10

Project Scheduling

In this class, we will examine the analytical basics of project scheduling. Of all the ideas

presented in this class, this may be the one you are most likely to be able to apply, since projects are common undertakings for almost all organizations.

Diagramming a Project

Refer to the part I of the problem described on page 130. The project consists of 7 tasks, labeled

A through G. It is possible to do more than one task simultaneously for instance, we can make

subassembly 1 and subassembly 2, that is, perform tasks C and D, at the same time. However, as

noted in the “requires” column, some tasks cannot start until others have been completed. For instance, task C cannot start unless both A and B are complete.

We can depict these relationships using a diagram that looks superficially like the network diagrams we used for some earlier problems. To do so,

We create a node for each task, plus two extra nodes for “start” and “done”.

If task X is required by task Y, we draw and arrow from X to Y. Each arrow in the diagram means that the task at the end of the arrow cannot start until the task at the beginning of the arrow is complete.

If a task does not require any other tasks, we draw an arrow to it from “start”.

If no other tasks depend on a task X, we draw an arrow from X to “done”.

For this project, we obtain the diagram A C F Start Done B D E
For this project, we obtain the diagram
A
C
F
Start
Done
B
D
E
G

This kind of diagram is called an “activity on node” or “AON” diagram. In some of the textbook excerpts in the coursepack, you may see different kinds of diagrams called “activity on arc” or “AOA”. These diagrams can be more compact, but are more complicated to draw, so we will not cover them in this course.

Although the AON diagram resembles the network diagrams we have drawn earlier in the course, they are quite different. The arrows represent the sequencing relationships (also called

precedence relationships) between the tasks, and you should not envision any kind of fluid or substance flowing through the diagrams, as we had in our earlier examples.

When constructing such diagrams, you should not get distracted by the alphabetical coding of the tasks. A common error is to put an arrow to “done” only from the last task in the alphabet (in this case, G), when there are other arrows to done might be necessary. In principle, every task should have an arrow from “start” and arrow to “done”, because you cannot start a task without starting the project, and the project cannot be done unless all its tasks are done. All those arrows, however, would clutter up the diagram, and only a few of them are truly necessary. For example, we don’t need to add an arrow from E to “done”, because the arrows we have already drawn in the diagram indicate that being done requires G, and G in turn requires E. Thus, an arrow from E to “done” would be redundant, because the arrows we have already drawn ensure that we could never declare the project done without completing E. But if we were to omit the arrow from F to “done”, it would be a mistake, because we would be saying that task F isn’t actually needed, and we could declare “done” without finishing F.

Similarly, we don’t need an arrow from “start” to C, because (for example) the arrows already in the diagram say that C requires A, which in turn requires “start”.

Modeling the Project with Linear Programming

We would like to know how quickly we can complete the project, that is, how soon we can declare “done”. This problem may be approached in several different ways, but, for consistency with the rest of this course, we will use linear programming. We define the following decision variables:

x

x

A

B

=

=

We define the following decision variables: x x A B = = x d = =

x

d =

=

G

time in days that we start task A time in days that we start task B

time in days that we start task B

time in days that we declare “done”.

In the network diagrams we’ve seen before, the arcs (arrows) corresponded to variables, and the nodes generally corresponded to constraints. In this setting, the correspondence is reversed. We have defined variables corresponding to the nodes, and it turns out that our constraints correspond to the arcs, because the arcs indicate how the events should be sequenced. Let us assume that “now” or “start” is time 0; then the first arrow in the diagram, which says that A comes after “start”, can simply be interpreted as the constraint

x A

0

Similarly, the arrow for “start” to B may be interpreted as

x B

0

The other arrows in the diagram correspond to more interesting constraints. In half-English-half- math, we could express the arrow from A to C as

(time we start C) ≥ (time A is complete).

Now the time we start C is simply x C ; the time that A is complete, using the information in the problem that A takes 6 days, should be x A + 6. Thus, we may write the constraint

x C

x A + 6.

We can make constraints for all the other arrows in diagram similarly, obtaining

x

x

x

x

x

x

x

d

d

C

D

D

E

F

F

G

x B + 9

x A + 6

x B + 9

x D + 7

x C + 8

x E + 10

x E + 10

x F + 12

x G + 6.

Our objective, of course, is to declare “done” as soon as possible, so we obtain the formulation

min

ST

x i

d

=

=

d

x C

x

x

x

x

x

x

x

G

d

d

x A , x B ,…, x G , d

x A + 6.

x B + 9

x A + 6

x B + 9

x D + 7

x C + 8

x E + 10

x E + 10

x F + 12

x G + 6

C

D

D

E

F

F

time in days that we start task i = A, B,…,G

time in days that we declare “done”.

0

At the end of the formulation, we have included nonnegativity constraints for every variable – the logical equivalent of drawing an arrow from “start” to every other node in the diagram – but only the first two of these constraints, x A , x B ≥ 0, are really necessary.

A Spreadsheet Version of the Model

Unlike many of the other models we have encountered, the linear program we have just formulated can quite plausibly be solved without a computer. There is in fact a fairly simple manual procedure that would allow us to solve the model above in a few minutes without having to use a computer, at least for a model of this size. It involves a “forward” pass through all the

nodes to figure out the earliest time each can start, and then a “backward” pass to determine the latest time each can start.

For consistency, however, we will just solve the problem with Excel and Solver. Pages 99-100

of the course pack show one possible spreadsheet model. Cells D5:D11 hold the variables x A ,

x B ,…, x G , respectively, and cell D12 holds d. Note that this cell is both a changing cell and the target cell.

Columns F and G are used to enforce the precedence constraints. Row 7, for example, corresponds to task C. F7 contains = E5, the completion time of task A, and G7 contains = E6, the completion time of task B. The Solver has the constraints D5:D11 >= F5:F11 and D5:D11 >= G5:G11, which in the case of row 7 mean that D7 >= F7 and D7 >= G7, that is, task

C cannot start until tasks A and B are done. For tasks that have only one predecessor, we simply

put a 0 in column G, generating a redundant constraint. For tasks A and B, which have no predecessors, we put 0 in both columns F and G. Note that if we had a task with three predecessors (something like L requiring H, J and K) then we would have to expand the spreadsheet and add another “cannot start until” column, with corresponding extra constraints in Solver.

This spreadsheet is not ideal, in that the precedence data is “hardwired” into the formulas in columns F and G. It would be better to be able to express the precedence relationships in the “data” section of the spreadsheet, rather than with formulas. Doing so is in fact possible, but is somewhat complicated, and will not be covered in this lecture.

Page 99 of the course pack shows an optimal solution to the model. The earliest we can finish the project is 38 days from now.

Critical Paths

For a given feasible solution to an optimization model, a constraint is called binding if holds with equality, that is, even though the constraint may be of the ≤ or ≥ form, the two sides are actually equal for the particular solution we are looking at. If a constraint is not binding (that is, it’s still satisfied, but holds with < or >), then it is said to have slack. Let’s examine the solution on page 131 and see which constraints are binding and which have slack. If a constraint is binding, let’s “bold” the corresponding arrow in the diagram:

A C F Start Done B D E G Notice that there is a connected
A
C
F
Start
Done
B
D
E
G
Notice that there is a connected path of bolded arrows from “start” to “done”, namely
start→B→D→E→F→done. Every constraint on this path is binding, meaning that every task
along it starts as soon as possible, given the completion time of the previous task. There is no
slack anywhere along the path, and thus if any task on the path takes longer than expected, the

completion time of the project will be delayed. For this reason, it is called a critical path (this term has become a common business “buzzword” that is often used without regard for its true, original meaning). You may often hear people refer to “the critical path”, as in “that’s not on the critical path”. Often, as above, there is just one critical path, but sometimes there can be more than one. So, technically it is usually safer to say “a critical path”.

Note that if a task not on any critical path, such as A or C, takes longer than expected, there is still a possibility that the project can be completed in the originally determined minimum time.

Note that every path from “start” to “done” that one can trace in the network corresponds to a

sequence of tasks that must be done in order, without overlap. Therefore, the project must take

at least as long as the length of any such path, obtained by adding up the durations of its tasks.

The critical paths are in fact the longest paths, since there is no reason to take any longer than longest path. Shorter paths (that is, ones that aren’t critical) usually exist, but we cannot choose them as “routes” for getting to “start” to “done” – every task in the project has to be done; we cannot avoid any of them.

“Crashing”

Sometimes it may be possible, by spending extra money, to accelerate some or all of the tasks in a project. For example, refer to Part II of the problem on page 130. We see that task A can be shortened at a cost of $10 per day, B shortened at a cost of $20 per day, and so forth. Investing extra funds or effort to get a project completed sooner is called “crashing”.

Setting aside the problem’s putative deadline of 25 days for the moment, let’s consider what we might do if we wanted to complete the project in just one less day, that is, 37 days. How could we do that most cheaply?

It is tempting to say that we should shorten task C by one day, since that would only cost $3.

But that would not work, because task C is not on the critical path. Even if C takes 7 days instead of 8, the path start→B→D→E→F→done remains unchanged in the network, and has a length of 38 days, so the project will still take at least 38 days, and our $3 will be wasted.

To make a project shorter, we must shorten all critical paths. In this case, there is just one critical path, and we note that among tasks on the critical path start→B→D→E→F→done, task

B

is the cheapest per day to shorten, so we shorten B by one day at a cost of $20.

If

we wanted to reduce the project by another day, we could repeat this same analysis, and

reduce B by an additional day. We can continue doing this until one of two things happens:

either we run out days to shorten the task (in this example, all tasks can be shortened by at most 5 days), or we produce another critical path. In this case, once we have shortened task B by three days, it takes the same time as A, and we now have a second critical path start→A→D→E→F→done. If we want to make the project shorter after this happens, we have

to remember to simultaneously shorten all critical paths; if we shorten B further, the project will

stay the same length, because the path start→A→D→E→F→done will remain unchanged. We have to find the cheapest way to shorten both start→B→D→E→F→done and start→A→D→E→F→done, meaning that we must shorten A and B together, or one of D, E, or

F. As one tries to “crash” a project more and more, critical paths tend to proliferate and manual

analysis becomes increasingly complicated. So, to get down to 25 days, a reduction of 13 days total, it is preferable to formulate an LP model and let Solver take care of the details for us.

To formulate the crashing problem, we have to introduce some additional decision variables, namely

y i

=

number of days that we shorten start task i = A, B,…,G

The problem posed in the coursepack is to find the cheapest way to meet the deadline of 25 days. Thus, we have a different objective, namely

min

10y A + 20 y B +

a different objective, namely min 10 y A + 20 y B + + 15 y

+ 15 y G .

The precedence constraints are much the same as in the earlier model, but we need to take the y i variables into account. For example, the duration of task A is no longer necessarily 6, but instead 6 y A . So, we write the constraints

x

x

C

C

x A + 6 y A , x B + 9 y B ,

and so forth. Since we are now “pegging” the end of the project to the 25-day deadline, we no longer need the variable d: in the constraints involving the project completion date, we can just use 25 instead of d, obtaining:

25

x F + 12 y F

25

x G + 6 y G .

Thus, the full model is

min

ST

x

y

i

i

=

=

time in days that we start task i = A, B,…,G number of days that we shorten start task i = A, B,…,G

10y A + 20 y B +

start task i = A, B,…,G 10 y A + 20 y B + + 15

+ 15 y G

x

C

x A + 6 y A

x

C

x B + 9 y B

x

D

x A + 6 y A

x

D

x B + 9 y B

x

E

x D + 7 y D

x

F

x C + 8 y C

x

F

x E + 10 y E

x

G

x E + 10 y E

25

x F + 12 y F

25

x G + 6 y G

0

y A , y B ,…, y G

5

x A , x B ,…, x G , d

0.

In the last line, only x A , x B ≥ 0 are really necessary.

Pages 101-102 of the coursepack show a spreadsheet version of this model, whose construction is similar to the previous spreadsheet, although there are more changing cells and some of the calculations are slightly more complicated.

More generally, we can think of the crashing situation as involving two objectives: finishing the project quickly and holding down costs. When there are two possible objectives, one standard approach (although there are others) is to treat one as a constraint, and see how well one can do on the other. Here, we treated the completion time as a constraint and tried to spend as little money as possible. But in some cases one might want to take a complementary approach: set a budget, and see how quickly the project can be completed within that budget. This approach would result in a somewhat different model that retains the variable d, although the precedence constraints would look the same.

We have only scratched the surface of project management. There are many more issues, both technical and otherwise, that can be explored in this area. For example, our model assumes that sufficient labor is available to simultaneously work on any combination of tasks that might arise. If our labor pool is limited, we would need a more complicated model. However, the basic techniques we have covered are the foundations of project management software such as Microsoft Project.