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

Start

Done
B

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

Page 1 of 7

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 dont 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 isnt
actually needed, and we could declare done without finishing F.
Similarly, we dont 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:
xA
xB

=
=

time in days that we start task A

time in days that we start task B

xG
d

=
=

time in days that we start task B

time in days that we declare done.

In the network diagrams weve 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
xA 0
Similarly, the arrow for start to B may be interpreted as
xB 0
The other arrows in the diagram correspond to more interesting constraints. In half-English-halfmath, we could express the arrow from A to C as

Page 2 of 7

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

Now the time we start C is simply xC; the time that A is complete, using the information in the
problem that A takes 6 days, should be xA + 6. Thus, we may write the constraint
xC xA + 6.
We can make constraints for all the other arrows in diagram similarly, obtaining
xC xB + 9
xD xA + 6
xD xB + 9
xE xD + 7
xF xC + 8
xF xE + 10
xG xE + 10
d xF + 12
d xG + 6.
Our objective, of course, is to declare done as soon as possible, so we obtain the formulation
xi
d

=
=

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

time in days that we declare done.

min d
ST xC xA + 6.
xC xB + 9
xD xA + 6
xD xB + 9
xE xD + 7
xF xC + 8
xF xE + 10
xG xE + 10
d xF + 12
d xG + 6
xA, xB,, xG, d 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, xA, xB 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

Page 3 of 7

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 xA,
xB,, xG, 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, its still
satisfied, but holds with < or >), then it is said to have slack. Lets examine the solution on page
131 and see which constraints are binding and which have slack. If a constraint is binding, lets
bold the corresponding arrow in the diagram:
A

Start

Done
B

Notice that there is a connected path of bolded arrows from start to done, namely
startBDEFdone. 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

Page 4 of 7

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 thats 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 arent 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 problems putative deadline of 25 days for the moment, lets 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 startBDEFdone 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 startBDEFdone, 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
startADEFdone. 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 startADEFdone will remain unchanged. We
have to find the cheapest way to shorten both startBDEFdone and
startADEFdone, meaning that we must shorten A and B together, or one of D, E, or

Page 5 of 7

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
yi

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 10yA + 20 yB +

+ 15 yG.

The precedence constraints are much the same as in the earlier model, but we need to take the yi
variables into account. For example, the duration of task A is no longer necessarily 6, but
instead 6 yA. So, we write the constraints
xC xA + 6 yA,
xC xB + 9 yB,
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 xF + 12 yF
25 xG + 6 yG.
Thus, the full model is
xi
yi

=
=

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

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

min 10yA + 20 yB +
+ 15 yG
ST xC xA + 6 yA
xC xB + 9 yB
xD xA + 6 yA
xD xB + 9 yB
xE xD + 7 yD
xF xC + 8 yC
xF xE + 10 yE
xG xE + 10 yE
25 xF + 12 yF
25 xG + 6 yG
0 yA, yB,, yG 5
xA, xB,, xG, d 0.

Page 6 of 7

In the last line, only xA, xB 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.

Page 7 of 7