OMEGA Int. J. of Mgmt Sci., Vol. 17, No. 1, pp. 69-79, 1989 Printed in Great Britain. All rights r--~rved
0305-0483/89 $3.00+0.00 Copyright ~ 1989 Pergamon Press pie
Resource Constrained Project Crashing RF D E C K R O The University of Wyoming, USA
JE H E B E R T The University of Akron, USA (Received December 1987; in revisedform August 1988) The resource constrained project crashing problem is reviewed. Models for two specific cases are developed by extending traditional project scheduling models. The development of the model for the resource critical crashing case is based on the Pritsker, Watters, and Wolfe model [16]. The model developed for the activity duration crashing case is based on Bowman's model 121.The paper concludes with several suggestions for future research.
(1) the project is composed of a fixed set of mutually exclusive and exhaustive activities, which cannot be altered;
1. INTRODUCTION THE DEVELOPMENT of PERT and CPM in the late 1950's the modeling of the project scheduling environment has been a classic optimization problem. Starting with the simple, unconstrained critical path model, a number of programming approaches have been developed. One track of this modeling effort has centered upon resource constrained project scheduling (see [6, 8], among others). A second major modeling track has concentrated on crashing individual project durations by accelerating specific activities by some exogenous method. These 'crashing' models have not typically included resource constraints (see [6, 8], among others). Very little published research is available on the resource constrained project crashing model [3, 9-11, 14]. In this paper, we will review two general approaches to modeling resource constrained project crashing. The first approach is a resource critical approach, where critical resources are increased in order to crash the project. The second approach is an activity duration critical approach. The paper concludes with several suggestions for further research in this area. SINCE
(2) the precedence relationships between activities are fixed and cannot be altered; (3) each activity has two deterministic attributes, namely, duration and per period resource requirements, (these attributes are known and cannot be altered); (4) the project has a given due date; (5) there is at least one feasible unconstrained activity schedule that results in project completion on or before the project due date; (6) the initial availability of each resource type in each period is known, and is, in the aggregate, less than the level required to allow all activities to be started within their early start/late start window. Thus, the resource critical crashing model is focusing on the lack of (critical) resources in one or more periods, which impedes the timely completion of the project. The resource critical model may be developed from any of several traditional resource con-
2. RESOURCE CRITICAL C R A S H I N G
The development of the resource critical crashing model begins with the following assumptions: 69
Deckro, Hebert--Resource Constrained Project Crashing
70
strained project scheduling models. The model developed here is based upon the Pritsker, Watters, Wolfe (PWW) model [16]. The PWW model was selected to take advantage of its unique variable definition [16, p. 94] which will reduce the number of variables required in certain settings. We have redefined the principle 0/1 variable to reflect the period in which an activity starts, rather than when it is completed [3, p. 16], and have dropped the project subscript in order to concentrate on a single project. Given these minor modifications, the variables and constants may be defined as follows [15, pp. 94-95] and [3, pp. 16-17]:
required.) These activity start constraints are special order sets of type 1 (SOS l). They may be exploited by some zero-one codes with considerable savings in computational time.
(B) Seqaencing constraints To maintain the precedence relationships between the activities of the project, an activity may not be started until all of its predecessors have been completed. There will be a sequencing constraint for each precedence relationship. Given any two activities, m and n, where m directly precedes n, the PWW model defines the sequencing constraints as follows [16, p. 98]:
X~j = 1 if activity i is started in period j; zero otherwise; X, = I if the project is completed in period t; zero otherwise; g = project due data; ei = the earliest possible period in which activity i can be started; 1~= the latest possible period in which activity i can be started which will still allow the project to be completed by g; T~ = time required to perform activity i; k = resource index; k = I, 2 . . . K; K = number of different resources; r~ = amount of resource k used per period by activity i; Rkj= amount of resource k available in period j.
This constraint may be simplified. Let Gi be the set of possible start times for activity i; that is G, = {e,, e,+ 1... li_ t, li}. Let IIGill be the cardinality of the set Gi, then it has been shown [15] that the sequencing constraint may be written as:
By using the earliest start and latest start times of an activity, the PWW model only requires variables for the window of possible start times, rather than for each period that an activity could be in process. If the 'start window' for an activity is relatively small in relation to the activity duration, a substantial saving can be made in the number of variables required to model each activity. The major constraints in the PWW model are briefly reviewed below. For a complete description of these constraints, the reader is directed to [16].
(C) Project completion The project completion constraints are optional. They allow the specification of the period in which the project is completed. There will be one project completion variable, X,, and one constraint for each feasible finish time of the project. (This can be determined from the earliest finish of the terminal activity(s) and the maximum time horizon of the project.) If there is more than one terminal node in the project, it is convenient to add a dummy terminal node. Let N, represent the set of terminal activities and IIN, [I be the cardinality of set N,, then
j=e~
or
x,j=l
for all i
t..
l.
i=eM
s~e~
tl G~ II
-- ~
I1G~ II
jX.~.(..+j_O+
j-I
~
s X . . , . . . . . ,)>~0
(2)
s=l
Either form of the sequencing constraints may be used in modeling the project.
t,
(,4) Activity start Each activity may be started only once. i,
s=en
~ X~j-IIN, tlX,>~O
forall
tfF
(3)
i • N, i = ei
(!)
J", If job splitting is desired, the activity is represented as two (or more) activities. (This will, however, increase the number of variables
where
X,= i if the project is completed in period t and zero otherwise; F is the set of all possible completion times of the project.
Omega. Vol. 17, No. 1 In addition, the project may be completed only once:
The
71
resource
constraints
are re-written
as:
~ r~,Xv<~Rkj+W~j f o r a l l k a n d j i~lj-ei
Xt = I
(4)
or
t~F
~ ~. r~X,j-- Wkj<~R~j
(D) Resource constraints
A resource constraint is developed for each time period within the project horizon for each type of available resource. If the horizon is large and/or there are many resource types, a substantial number of resource constraints may be required. If, for example, a project has a 20 period horizon with five resource types, up to 100 resource constraints could be required. A judicious review of start and stop times, as well as sequencing requirements, can reduce the number of resource constraints required in a model. We have varied somewhat from the resource constraint presented in the PWW model [16, p. 99] to develop the following constraint:
~ r~XO<~Rkj for a l l k a n d j i n t h e h o r i z o n
for all k and j
i = l j-¢i
(5)
(The Pritsker et al. constraint may be utilized with no difficulty.) (E) Extending the P W W model
With these basic constraints and variables, a resource constrained project may be scheduled. We can now extend this basic model to deal with the situation where insufficient resources are available in one or more periods. This is done by adding an additional variable type, and the corresponding constraints. Let Wkj = amount of additional resource of type k made available in period j Ckj = the cost/unit of additional resource type k made available in period j #kj = the maximum amount of additional resource type k which can be obtained in period j
The critical resource variable, Wkj, may be integer or continuous, as the particular operational setting dictates. It is desirable, however, to keep the total number of critical resource variables at a minimum.
and W,j ~<#kj for all k and j
One simple objective for the resource critical crashing model can be stated as M i n Z -- E E C,, Wk, k 1
This objective will have the effect of minimizing the cost of acquiring and allocating additional resources. Recall that we have assumed that the due date could not be met because of a shortage of critical resources in some periods. This would effectively mean that the unaltered PWW model, without the critical resource variables, is infeasible. One possible approach would be to simply add resources to the infeasible constraints. However, by using the critical resource variables and their costs, the proposed model can simultaneously evaluate a number of alternative schedules. It should be noted that it is not necessary to add a critical resource variable for every possible resource type and/or period. If particular equipment, materials or personnel are only temporarily available, one would only add the appropriate variables to the resource constraints in the window of availability. The critical resource model can be extended to consider penalty and bonus payments as follows [4, p. 134]: Redefine g to be absolute horizon deadline (the latest possible period the project could be completed.) Let d be the target due date which will trigger penalty or bonus payments. If the project completion constraints and variables are used, a new objective may be developed: Min
z = Z Z c ~ j w , i- Z B,X,+ k
j
I=EF
P,X, t=d*l
where B , = b o n u s available for completing the project early in period t, E F <~t <~d P,--- penalty due for completing the project late in period t , d + l ~ < t ~ < g
72
Deckro, Hebert--Resource Constrained Project Crashing E F = earliest possible finish of the project if
all possible additional resources were utilized. This objective will balance the cost of additional critical resources against the consequences of any bonus or penalty payments.
3. RESOURCE CRITICAL CRASHING EXAMPLE An example of the resource critical crashing problem has been developed from an example modified from [18, p. 108]. The problem is summarized in Fig. 1. Two resources, A and B, were used. Additional units of A were limited to five per period (WAs~< 5), while additional units of B were limited to three per period (WB/<~ 3). (Both the initial availabilities and the period by period additional resource limits need not be constant from period to period.) A due date of period 13 was established. The project could be completed in 11 periods, if there were no resource constraints. The model contains 38 zero-one variables and 26 integer critical resource variables (one for each period for each resource type). No completion variables were used in this example. The model contained eight activity completion constraints, six sequencing constraints and 26 resource constraints. There were also 26 upper bounds on the critical resource variables. The objective was to minimize the cost of additional resources. The model was solved in 6.6 seconds on the CYBER 760 at the University of Wyoming using the MPOS routine BBMIP, which is a branch and bound algorithm. Table 1 summarizes the solution of this example. X/j equal to one signifies that activity i was started in periodj. Activities two and three will be started in period one, for example, while the start of activity one will be postponed until period five and activity four will be postponed to period ten. To meet the due date of period 13, additional resources of type A are needed in period one, two, five, six, seven, eight, nine and ten. The total cost of these additional resources 'The actual duration of each activity is a variable that is defined as the normal duration minus the amount of crashing, where the amount of crashing is constrainedto be greater than or equal to zero and less than or equal to the differencebetween the normal duration and the crashed duration.
will be $286. The project can be completed by the due date, but additional resources will be required. By allowing the optimizing code to investigate branches with equivalent objective values (i.e. bound on greater than rather than greater than or equal) multiple optimal schedules can be enumerated.
4. ACTIVITY DURATION CRASHING The development of the activity duration crashing model begins with the following assumptions:
(1) the project is composed of a fixed set of mutually exclusive and exhaustive activities, which cannot be altered; (2) the precedence relationships between activities are fixed and cannot be altered; (3) the following attributes are specified for each activity, and cannot be altered~: (a) normal duration, (b) crashed duration, (c) per period resource requirements; (4) the project has a given due date;
(5) with all activity durations set at their 'normal' value, there are no feasible activity schedules that result in projection completion on or before the project due date; (6) the availability of each resource type in each period is known, and is, in the aggregate, less than the level required to allow all activities to be started within their 'extended' early start/late start window. Thus, the activity duration crashing model is focusing on the selection of the most cost effective 'crashing program' under the additional restrictions imposed by resource constraints, which prevent the timely completion of the project. The major computational advantage of the
Omega, Vol. 17, No. 1
73
t1
r;._L;;:?
(9,2) Due date = e n d of period 13 RAj = 10
W,,Ij<~5
Re~i = 7 for all/"
Ws,i <~ 3 for all j
MinZ=T.T~C,iW, k i CA,=10 CA,=15 Ce, = 7
Activity 1 2 3
Nodes (1,2) (1,3) (1,4)
4 5 6 7 8
(1,6) (2,5) (3,4) (4,5) (5,6)
Fig. 1. R e s o u r c e critical c r a s h i n g e x a m p l e
Table 1. Resource crashing example solution Start periods-X,~ where i is the activity, j is the period Xl.~ = I Xs.7 = I Xz) = 1 X6.~ = I X3., = I X7.5 = I X,.io = I
Xs.lo = I
Critical resource variables k
Resource A Yka
Resource B Yka
I
3
0
2 3 4 5 6 7 8 9 I0 I1 12 13
3 0 0 5 5 3 4 4 3 0 0 0 Total cost = 286
0 0 0 0 0 2 2 2 2 0 0 0
Run time was 6.578 seconds using the BBMIP r o u t i n e from MPOS o n the CYBER 760 at the University of Wyoming.
PWW model stems from its unique variable definition, which defines a zero--one variable for each period in the 'start window' of every activity. If activity duration crashing is allowed, these 'start windows' are generally increased, for
i
k = 1 to 10 k = 1 1 to 13 k= 1 to13
from [18, p. 108].
every activity in the project. Even if an activity duration cannot be crashed, if any activity in its predecessor chain may be crashed, the activity's earliest time will occur at an earlier point in the schedule. If crashing is allowed in a project, a zero-one variable will be needed for every time period in the window for each activity from its earliest crash start time (calculated with all activities I crashed by MI, the maximum allowable crashing of activity 1) to its latest possible start time (with no activities crashed). This could substantially increase the number of zero-one variables in a model that already can grow very rapidly. A more serious problem, however, concerns the resource constraints themselves. For each activity which utilizes a particular resource k, the start variables for the activity must be included in the constraint for resource k, beginning with the earliest start period and for each subsequent period in the activity's duration. The introduction of crashing effects the resource constraints in two ways. First, with the increased start window, the variables appear in more constraints. This could increase the total project time horizon, which would require addi-
74
Deckro, Hebert--Resource Constrained Project Crashing
tional constraints. Secondly, when crashing is allowed, the duration becomes a variable. If an activity is crashed, it will not use resources in some of the latter periods. Somehow, these resources must be 'added' back so that they are available in the later periods. This will require a flagging variable to restore the unused resource. Such a mechanism will substantially increase the number of required variables to prohibitively high levels unless the amount of crashing allowed is very limited. Therefore, the P W W model is not practical when activity crashing is considered in the presence of resource constraints. Thus, we will base the development of this resource-constrained activity duration crashing model on the early model developed by Bowman [2]. In the Bowman model [2], the zero--one decision variables are defined by whether an activity is worked on in a specific period or not. A zero-one variable is required for each period from the earliest possible start of an activity to the latest possible finish of the activity. The variable, with slight modifications to allow crashing, will be defined, as will the constraints. The model will then be developed by presenting each Bowman constraint and its extension to allow for activity crashing.
T~ minimum crashed duration of activity i (with crashing); Mi r i - z ~ ; maximum crashing allowing for activity i; Pi set of all activities which immediately precede activity i; Ki the cost of crashing activity i one period; ra amount of resource 1 needed for activity i per period; Rtj total availability of resource 1 in period j; n number of activities in the project; c number of activities which may be crashed; c ~
Variables
Xq = 1 if activity i is worked in period j; zero otherwise Y~> 0 if i is crashed. Yi is an integer variable where Yi ~< M; and is the number of periods activity i is crashed. Constraints ESi crashed early start of activity i; the earliest possible start for activity i with all activities crashed to their maximum limit; LFi late finish of activity i; the latest possible finish for activity i with no activity crashed; Di set of variables representing the maximum possible window for activity i. One variable is required for each period from ES~ to LFx; IID, U cardinality of set D~; number of variables required to represent activity i; zi normal duration of activity i (without crashing);
~' X,/-- ~ for all i The sum of the periods worked on activity i must equal the activity's uncrashed duration. If crashing is allowed, however, the sum of the periods worked need not be the uncrashed duration. Instead, the sum must be the normal duration (ri) less the number of periods crashed,
ri. This can be expressed as: Xii -- ~ , -
Yi
for all
i
1~ D,
or Xo+Yi--r~ for alli Resource constraint. The resource constraint for the Bowman model is stated as: ~ r~lX~<
The beauty of the Bowman model in the crashing case is that it does not affect the resource constraint. If an activity i is not in progress
Omega, Vol. 17, No. 1
during period j, X~ 0. No resource will be used unless activity i is in progress during period j. Since the appropriate X~jvariables will appear in every constraint for periods in activity i's window, the resources are accounted for, regardless of activity i's duration. Precedence constraint. To maintain precedence the Bowman model uses the following set of constraints: =
d-I
~pX~< ~ Xpj for a l l p ~ P , d a n d i j-I
In order for activity i to be worked on in period d, all of its predecessors (p ~ P;) must have been completed by period d - 1. Therefore, the sum of the XpTs from period 1 (the start of the project) through period d - 1 must be greater than or equal to activity p's duration, %. (While Bowman has expressed this relation as an inequality, it may be stated as a strict equality.) When crashing is allowed, an activity can be started earlier if one or more of its predecessors, (pEPs) have been crashed. The model is modified to account for this change by 'adding back' the crashed time to the performance time. d-I
~pX~a<<.~ Xpj + Yp for all p e P,, d and i i-I
or d-I
75
Of course, the usual non-negativity and integrality conditions are also required. Project duration. Depending upon the operational setting, a project duration constraint may be required. In the simple crashing model, without resource constraints, this was accomplished by requiring the event time of the terminal node to be less than or equal to the project due date. If an absolute project due date exists in a project, no variables need exist for periods beyond the due date. Such an arrangement has the same effect as establishing a due date constraint. If the due date cannot be met, the problem will be infeasible, just as it would have been if a due date constraint was developed. If a final due date is desirable, but not a necessary requirement, those X o variable representing periods beyond the desired due date could be minimized. Other constraints. The constraints considered to this point may be considered 'necessary' to formulate the basic resource constrained, time/cost trade off model. One of the most obvious 'optional' constraints would be a budget limitation, either for the total project or for a specific activity. (Various other 'optional' constraints have been discussed in the literature.)
~pX~ - ~ Xpj- Yp~<0 for all p e P~, d, and i j-I
No activity splitting. This constraint type is required to assure that once an activity is started it is worked on continuously until completed. If 'splitting' is acceptable for certain activities, the constraint may be omitted for those activities. Bowman has given the constraint as: /.f,
r,Xu-%X~+t)+
~
X~<.¢,i---1,2...n
d-j+2
Objectives The resource constrained crashing model suggests the possibility of several objectives. Some of the most common objectives are outlined below: Project duration. The standard Bowman model developed the following objective to minimize project duration: Min Z = I
~X~+4~Xi(d+l) i~l
i=l
(j = ES, . . . . . L F , - r , - I) + 16 ~. X , ( d + 2 ) + ' " + R : ~ Xi:
At first glance, it would appear that job splitting would be effected by crashing as activity durations are varied. However, this is not the case. Any constant may be used for ~ in this constraint. The relative weights are not important, only their interaction in preventing gaps or splits. Crashing limits. Each of the crashing variables Y~ should be limited to the maximum number of allowable crashing periods, Mr. Y, ~
i--I
i--I
where k is some number such that the minimum project completion time is less than k and k is less than the maximum project duration, z. In general R.. = 4R._ ~. If this objective were used in a model which included a budget constraint on total crashing, the project duration would be minimized within some budgetary and precedence limits. Crashing costs. Another possible objective for the resource constrained crashing model would
Deckro, Hebert--Resource Constrained Project Crashing
76
be to minimize the cost of crashing. Using Ki as the cost of crashing activity i for one period, this objective would be stated as Min = ~ K~ Y~ t-I
If the model were specified with an absolute due date, as described above, such an objective would develop the minimum crash cost budget which meets the project due date. Performance penalty/crash cost. Many projects are characterized by a specific performance penalty being changed for each period the project exceeds a specified due date. It is economical to crash the project only as long as the cost of crashing per period is less than the performance penalty per period. If a project can be represented with a single terminal activity, t, a penalty crashing cost trade offcan be expressed with the following objective assuming activity t is begun at or before the due date: Z
MinV=
E jmO+l
ejxo+ ~ K, Y, ira|
where D is the target due date after which penalties accrue
Z is the absolute due date Pj is the marginal penalty assessed if the project is not completed by period j and the other constraints and variables are defined as before. If there are several terminal nodes, the formulation becomes a bit more complex. One possible approach is to use completion constraints similar to those developed for the PWW model [16, p. 94]. If T represents the set of terminal activities, then the completion constraints can be expressed as:
Z x,,~ii r)l~ teT
for all j in the interval from D + 1 to Z.
If any of the terminal activities are worked on in period j, Xj must be one. The objective then becomes: Z
Min Z =
E J-D+I
P/~+~K~Y, t--I
again assuming the terminal activities are begun at or before the due date. An additional con-
straint and an additional zero-one variable will be required for each time period in the interval fromD+l toZ. This same constraint and objective formulation may be used to express overhead considerations. The only variation required would be to replace D + 1 with the full crash earliest finish (EFj) in the interval definition. This would, however, increase the interval size. Activity early start..In some operational settings, particularly where there may be a great deal of uncertainty about activity durations, it is desirable to start every activity as soon as resource limitations will allow. An activity early start objective can be expressed as follows: Min Z = ~ ~jX~ I - I Jet DI
Other weights may be used in the objective instead o f j to prevent unit trade offs among the variables. One possibility would be the Rj weights used by Bowman in the original project duration objectives. A number of other objectives are possible. Essentially any of the linear objectives used with the Bowman model or the crashing model can be considered. Selection of an appropriate objective will depend upon the specific requirements of a given project.
Example of activity crashing with resource constraints. An illustrative example of the single objective, resource constrained crashing model has been solved. A model, taken from Anderson, Sweeney, and Williams [1, pp. 359-362] is given in Fig. 2. A single resource type has been added. This information is summarized in Fig. 2. Table 2 summarizes the solution to the resource constrained crashing problem. This problem was solved in 2.232 seconds using Version 4.0 of the Multi-Purpose Optimization System (MPOS) on the CYBER 760 at the University of Wyoming. The BBMIP routine in the MPOS package was again used to solve the problem. The bounded variable option was used to establish the upper bounds on the variables. A review of Table 2 indicates that activity A was crashed for two periods, while activity D was crashed for one period. The total crashing cost for the project was $350. Activities A and C were begun in period one. Activity B was begun in period six, while activity D was begun in period seven. Activity E began in period nine
Omega,
Vol. 17, N o .
1
77
,
=Q
2-1
Activity
¢1
MI
Ki
rl
A
7
3
100
2
B
3
1
1 50
1
C D E
6 3 2
2 2 1
20O 150 250
1 1 3
Variables Activity operations Crashing
R =3 D =10
Constraints 30 5
Activity performed Resource constraints Precedence constraints No splitting constraints
5 10 16 20 51
Fig. 2. Resource constrained activity crashing example.
and was completed in period ten, completing the project by its due date. No slack exists in the network with this schedule. Utilizing the Bowman model as a base, activity crashing and resource crashing may be combined into a third model. This hybrid approach, however, could require a substantial increase in variables and would depend on the large variable count model given by Bowman. (It might be desirable in some specific settings, however.) 5. SUMMARY CONCLUSION AND SUGGESTIONS FOR FUTURE RESEARCH Resource constrained project modeling is an existing operational problem. The basic models developed here can be used to formulate the
resource contrained crashing environment. Two separate approaches have been developed utilizing two common project programming models as a basis. The two general models presented here possess all of the computational deficiencies which exist in the standard resource constrained models. Table 3 summarizes the variable and constraint requirements for both models. In each case, the maximum requirements have been given. A number of these constraints may prove to be nonbinding and need not be included in the model. In addition, unless additional resources are allowed in every period for every resource type, the total number of variables will be less. The variable reduction possible in the Pritsker, Watters, Wolfe model is highly de-
Table 2. Resource constrained activity crashing example solution Activity A Y) = 2
Activity B
Activity C
Activity D
Crashing variables Y2 ==O Y3 = O Y4 = l Activity variables (variables not listed equal zero)
Activity E Y5= 0
X,., = I
Xz6 = I
X3., = I
X,.7 = I
X~,9 = I
X). 2 = I X~.3 = I
)(2.) = I Xz. = I
X3a = I X3. ~ : I
X4. s = 1
X,.)o = !
X~.~ = l Xi. ~ = I
X3. , : I )(3. ~ = I X3,~ = I
Crashing cost = 350 Run time was 2.232 seconds using the BBMIP package from MPOS on the CYBER 760 at University of Wyoming
78
Deckro, Hebert--Resource
Table 3. Problem size Resource crashing via PWW Variables for n activities
Activity start
r ~ (I,- e,)
Project completion
n
A d d i t i o n a l resource v a r i a b l e s "
m a x i m u m o f K ~" (I i - e i ) i-i
i-I
Constraints
Activity start constraints
n
Predecessor constraints
~. IIP~tl
Project completion constraint
g - EF + I
Resource constraints
K ~ l (1~- e~)
Actirity crashing via Bowman
Activity variables Crashing variables
~ I1D,II
i-I
c
Constraints
Activity completion ResourCe constraints b
n maximum of K(g)
Precedence constraints b
maximum of n(g) t
Non-splitting constraints Crashing limit constraint (upper bound constraint)
n c
t-I
I1P, I[
° Crashing may not be allowed for every activity and/or time period. b Some constraints will be redundant or non-binding.
pendent upon the width of the possible window of start times for an activity (1~-e~). This window, in turn, is dependent upon the interrelationship between activity predecessors, activity durations and the ultimate project deadline. The window width also effects the model's constraint requirements. The PWW model will be preferred in situations where the activity start windows are small relative to the activity durations. As the start windows widen, the advantage of the PWW model diminishes. The Bowman model tends to be dependent upon the size of the total horizon. By preprocessing the model, redundant constraints can be removed. Projects modeled via the Bowman approach can get very large very rapidly. Weist and Levy [18, p. 131] point out that a standard project scheduling problem (without crashing) having 50 activities with 100 precedence relations and requiring four resources over a 30 period horizon could have 1500 variables and over 6500 constraints. Clearly, such problems become computationally intractable for all but the most sophisticated software and hardware. Crashing merely complicates this problem. If job splitting is allowed, the Bowman model would be preferred. Each job split would have
C o n s t r a i n e d Project Crashing
to be represented as a separate job in the PWW model, with the commensurate increase in variables. In the Bowman model, it would only be necessary to relax (or remove) the appropriate non-splitting constraints for those activities which may be split. Operationally, jobs are often split to allow better utilization of resources. As the Bowman model may be used as a base in resource crashing, it would be preferred in either resource or activity crashing if any extensive job splitting is allowed. Both approaches appear to create natural opportunities for improving calculation through decomposition. The problem naturally divides between the project activity variables, X,j, and the crashing variables, either W~jor ]'is. Without the crashing variables, the problem reverts to a resource constrained project network. This suggests a network solution approach, perhaps similar to the approach suggested by Talbot and Patterson [17] or by utilizing a network model with side constraints, as suggested by McBride [I 3] and others. The crashing variable portion of the model becomes a relatively simple bounded variable program. If no budget constraint is included, the model constraints would simply be the upper bounds on the crashing variables. A decomposition approach, such as Bender's which can bifurcate on the variables would be an effective solution technique, particularly if the network structure could be exploited. Even with multiple projects, it should be possible to decompose and solve the model [5]. The authors are currently pursuing research along these lines. If a work package hierarchy/aggregation approach is used to model the project environment, the resource constrained crashing models will prove to be effective in allocating critical resources. Such an approach would be a simple extension to the hierarchial planning already utilized in project and production scheduling. The smaller, aggregated project network given at each level could be modeled and solved. Aggregation and disaggregation would be carried out along the same principles used in aggregate production scheduling. This, or other approaches, may be enhanced through the use of prioritization. The formulations presented here provide a method to model resource constrained project crashing. The resource critical model indicates the period and type of resource required. It has
Omega, Vol. 17, No. I
the advantage of utilizing the variable reduced approach suggested by Pritsker et al. [16]. The activity crashing approach, while utilizing the Bowman model [2], does provide a method to investigate activity crashing resource constraints. While both approaches suffer from the weakness of general zero-one models, they do provide a method to model and analyze moderate sized operational settings and aggregated models. In addition, given the underlying network structures of the models, they provide an initial starting point for future research. As with all modeling approaches, the computational expense must be balanced against the potential operational gain.
5. 6. 7. 8. 9. 10. 11. 12. 13.
ACKNOWLEDGMENTS This research was supported in part by a Summer Research Grant from the University of Wyoming. The authors would also like to thank their faithful graduate assistants, Shigeru Tsubakitani and James L Corner, who each contributed to some part of this study. They are also indebted to the anonymous reviewer and the journal's editor for their helpful comments.
14. 15. 16. 17.
REFERENCES 1. Anderson DR, Sweeney DJ and Williams TA. (1982) An Introduction to Management Science, 3rd edn. West Publishing Co., St Paul. 2. Bowman, E. H. (1959) 'The scheduling--sequencing problem'. Ops Res. 7, (5), 621-624. 3. Deckro RF and Hebert JE (1986) Multiple objective project crashing. Working Paper, University of Wyoming. 4. Deckro RF, Hebert JE and Verdini WA (1987) Non-linear multiple criteria time/cost tradeoff. Decision
OME
17 I - - F
18.
79
Science Institute Sixteenth Annual Meeting Western Regional Conference Proceedings, pp. 134--I37, Deckro RF, Winkofsky EP, Hebert JE and Gagnon R A decomposition approach to project scheduling. Work in progress. Elmaghraby S (1977) Activity Networks: Project Planning and Control by Network Models. Wiley, New York. Fulkerson D (1961) A network flow computation for project cost curves. Mgmt Sci. 7(2), 167-178. Gray C (1981) Essentials of Project Management. Petrocelli Books. Hannan EL (1978) The application of goal programming techniques to the CPM problem. Socio-Econ. Plann. Sci. 12(5), 267-270. Hebert JE and Deckro RF (1982) Multi-objective project planning and budgeting. Joint National TIMS/ORSA Meeting, Detroit, Mich. Hebert JE and Deckro RF (1983) The multipleobjective, resource constrained time/cost trade-off problem. Joint National TIMS/ORSA Meeting, Chicago, I11. Kelly J (1961) Critical-path planning and scheduling: mathematical basis. Ops Res. 9(3), 296-320. McBride R (1985) Solving embedded generalized network problems. Eur. J. Ops Res. ll(l), 82-92. Moore LJ, Taylor BW, Clayton ER and Lee SM (1978) Analysis of a multi-criteria project crashing model. AIIE Trans. 10(2), 163-169. Patterson JH and Albract JJ (1975) Assembly-line balancing: zero-one programming with fibonacci search. Ops Res. 23(1), 166-172. Pritsker AA, Watters LJ and Wolfe DM (1969) Multiproject scheduling with limited resources: a zero-one programming approach. Mgmt Sci. 16(I ), 93-108. Talbot B and Patterson JH (1978) An efficient integer programming algorithm with network cuts for solving resource-constrained sequencing problems. 3[gmt Sci. 24(22), 1163-1174. Weist JD and Levy FK (1977) A Management Guide to PERT/CPM, 2nd edn. Prentice--Hall, Englewood Cliffs, NJ.
FOR CORRESPONDENCE: Professor RF Deckro, Department of Business Administration. College of Commerce and Industry, University of Wyoming, Laromie, WY 82071, USA.
ADDRESS