ART ADMINISTRACION DE PROYECTOS_01

8/7/2019 ART ADMINISTRACION DE PROYECTOS_01

http://slidepdf.com/reader/full/art-administracion-de-proyectos01 1/11

Tools for Resource-Constrained Project Scheduling and Control: Forward and Backward Slack

AnalysisAuthor(s): P. Tormos and A. LovaSource: The Journal of the Operational Research Society, Vol. 52, No. 7 (Jul., 2001), pp. 779-788Published by: Palgrave Macmillan Journals on behalf of the Operational Research SocietyStable URL: http://www.jstor.org/stable/254124 .

Accessed: 17/03/2011 08:48

Your use of the JSTOR archive indicates your acceptance of JSTOR's Terms and Conditions of Use, available at .http://www.jstor.org/page/info/about/policies/terms.jsp. JSTOR's Terms and Conditions of Use provides, in part, that unless

you have obtained prior permission, you may not download an entire issue of a journal or multiple copies of articles, and you

may use content in the JSTOR archive only for your personal, non-commercial use.

Please contact the publisher regarding any further use of this work. Publisher contact information may be obtained at .http://www.jstor.org/action/showPublisher?publisherCode=pal. .

Each copy of any part of a JSTOR transmission must contain the same copyright notice that appears on the screen or printed

page of such transmission.

JSTOR is a not-for-profit service that helps scholars, researchers, and students discover, use, and build upon a wide range of

content in a trusted digital archive. We use information technology and tools to increase productivity and facilitate new forms

of scholarship. For more information about JSTOR, please contact [email protected].

Palgrave Macmillan Journals and Operational Research Society are collaborating with JSTOR to digitize,

preserve and extend access to The Journal of the Operational Research Society.

http://www.jstor.org/action/showPublisher?publisherCode=pal

http://www.jstor.org/action/showPublisher?publisherCode=ors

http://www.jstor.org/stable/254124?origin=JSTOR-pdf

http://www.jstor.org/page/info/about/policies/terms.jsp



http://www.jstor.org/page/info/about/policies/terms.jsp

http://www.jstor.org/stable/254124?origin=JSTOR-pdf

http://www.jstor.org/action/showPublisher?publisherCode=ors




Journal of the Operational Research Society (2001) 52, 779-788 p,2001 Operational Research Society Ltd. All rights reserved. 0160-5682/01 $15.00

www.palgrave-journals.comtjors

Tools for resource-constrainedproject schedulingand

control: forwardand backwardslack analysisP Tornos* and A Lova

Universidad Polit&nica de Valencia, Valencia, Spain

Project managers generally consider slack as a measure of the scheduling flexibility associated with the activities in the

project network. Nevertheless, when resource constraints appear, this information must be calculated and analysed

carefully. In this context, to handle project feasible schedules is very hard work for project managers. In order to develop

useful tools for decision making, the authors extend the concepts of activity slack and define a new activity criticality

index based on them that permits us to classify the activities in the resource-constrained project scheduling and control

context. Additionally, these new concepts have been integrated into standard project management software as new

commands. Hence the capabilities of project management software are improved. Finally, an example that illustrates the

use and application of the new activity classification is also included.

Keywords: project management; resource-constrained; project scheduling; project control; activity criticality

Introduction

The PrecedenceDiagrammingMethod(PDM) is a classicaltechnique for projectschedulingwhere activities have fourtypes of precedence relations (start-start(SS), start-finish(SF), finish-start(FS) and finish-finish (FF)) and assumesthat an unlimited quantity of all necessary resources areavailable for assignmentto individual activities whenever

they are required.The application of the PDM allows theProjectManager(PM) to know the earlyand late scheduleddates of each activity, the minimum project completiontime and the slacksof the activities.These latterparametersoffer very importantinformationto the PM and indicatetohim/her the degree of flexibility of the project scheduleobtained. With these data, PMs know the critical andnoncritical activities and thus can make decisions abouttheirrescheduling,maintainingtheprojectcompletiontime.

Among the several types of slacks (or floats) defined inthe literaturetwo are the most widely used, TotalSlackandFreeSlack. Free Slack of an activity is equalto the amount

of time that its completion time can be delayed withoutaffectingthe earlieststarttime of any other activity in theproject. Therefore, the activity is free to use this slackwithout affecting the dates of any other activity in theproject. TotalSlack of an activity is equal to the amountof time by which the completion time of the activity canexceed its earliest completion time without delaying theprojectcompletiontime (obtainedaccording to the PDM).In a context of unlimited resource availability, these

*Correspondence. P Tormos, Department of Statistics and OperationalResearch, Universidad Politecnica de Valencia, 46071 Valencia, Spain.E-mail: ptormosG)eio.upv.es

concepts of slacks are simple and unambiguous. Thus,there is a single total and free slack associated with eachactivity.

Nevertheless, in practicethe availabilityof the resourcesassigned to a project is limited and often not sufficient toconcurrentlyexecute the activities scheduledaccording tothe PDM. In this situation, decisions must be made abouttheir scheduling that in many cases imply an increase inprojectcompletion time.

In order to conceptually formulate the resource-constrainedproject scheduling problem with generalisedprecedence relations we assume a project representedinactivity-on-the-nodeproject format by a directed graphG -{N, A} in which N is the set of nodes or activitieswhich have to be processed. A is the set of precedencerelationshipsthat is dividedin four disjointsub-setswhere

Ass is the set of SS precedencerelations andASF,AFS,AFF

are similarly defined. The non-preemptableactivities arenumberedfrom 1 to n, where the dummy activities 1 and nmarkthe beginningand the end of the project.The durationof an activity is denotedby di, being di equal to zero foractivities 1 andn anddi > 0 otherwise.The scheduledstarttime of each activity is denoted by SST1(1< i < n) and itsscheduled finish time by SFTi(1 < i - n). There are Krenewableresourcetypes, with rik( < i <, n, I < k < K)being the resourcerequirementsof activityi with respect toresourcetype k. Rk(I < k z K) is the constantavailabilityof resource type k throughout the project duration. Theactivities are subject to generalised precedence relationswith minimaltime lags SSij, SFi, FSi1and FFii,specifyingthat an activityj can only start (finish) when the prede-cessor activity i has alreadystarted(finished)for a certain

time period.



780 JournaloftheOperationalResearchSocietyVol.52,No.7

Based on the above definitions of the variables, theresource-constrained project scheduling problem with

generalised precedence relations can be formulated as

follows:

Optimise(function) (1)subject to:

SST - SSTi E0SSij (i,j) C Ass (2)

SFT1- SSTi ? SFij (i,j) c ASF (3)

SSTj- SFTi >FSij (iJ) c AFS (4)

SFT - SFTi FFij (i,j) CAFF (5)

Erik? ARk t- 1, ,T, k=1,...,K (6)P(t)

The objective is to obtain a feasible schedule (start/finish

scheduleddates for each activity of the project)in ordertooptimise an objective function(1) as projectduration,net

present value of the project or resource levelling amongothers. Constraints (2)-(5) enforce the precedenceconstraintsbetween activities. Constraints(6) ensure, foreach resource type k and each time period t, that theresource demand of the set of activities in process P(t) attime t does not exceed the capacity.Finally,T is an upperbound on the feasible completiontime of the project.

This problemcan be solved both with exact and heuristicmethods althoughthe combinatorialnatureof the problemmake the heuristic methods the only techniqueto apply in

order to solve it in practical size projects. The resource-constrainedproject scheduling problem with generalisedprecedencerelationshas been widely studied and in recentyears great advances have been made in the procedurestosolve it."'

In parallel, the practice of project management hasevolved closely related to that of software and hardware.Since the launch of HarvardProjectManagerin 1983 tensof programshave appearedon the marketandtodaypower-ful andinexpensiveprojectmanagementsoftware is readilyavailable.Theseprogramshave evolved in recentyearsandthey have improved their quality through successive

versions in which they have correctedflaws and deficien-cies detectedin previous ones.'2 Inparticular,relatedto thescope of this work, the professional project managementsoftware allows considering the generalised relations ofprecedencediagrammingtype and calculates bothtotal andfree slack values in the unlimitedcontext.

When resource constraintsarise some project manage-ment packagessubstitutescheduleddates for early dates inthe originaldefinitionsof total andfree slack. Nevertheless,the method for calculating total slack and free slackfrequently produces misleading results when activities

require common resources that are available in limitedquantities.

The standardproject managementsoftware uses heuris-tics based on priorityrules thatprioritisethe activities thatare competing for the use of the constrainedresources.Once the heuristicmethod has been appliedandthe feasiblescheduleobtained,it is consideredlike a 'blackbox' wheredoing changes in a controlled manner becomes very

complex. In fact, the PM needs tools thatallow reschedul-ing the activities when considering particular criteria.

Furthermore,parametersthat indicate the degree of criti-cality of the activities are also needed as a helpful tool forproject scheduling and control in the resource-constrainedenvironmentwith generalisedprecedence relations.Never-theless, there are few published works that offer to the

practitioner,once the feasible project schedule has been

obtained, the possibility of easily rescheduling activitiesconsideringparticularcriteriaand maintainingthe feasibil-ity and the durationof the project schedule.

In orderto fill thisgap, themainobjectiveof thispaperis

to extend the concepts of activity slack in the resourceconstrained context and to define an activity criticalityindex based on them. Additionally,these tools have beenintegrated into standard project management software.Hence the capabilities of project management softwareare improved.

The paperis organisedas follows: in the next section aliteraturereview is presented describing previous worksthattreat this problem. Afterthat, the methodologyused tobuild the new options for scheduling and control isdescribedthroughthe definition of slack concepts. Basedon these concepts, an activity criticality index adaptedto

the resource-constrainedcase is also introduced.The newtools thatpermit the PM to make theirwork more flexible,easier and faster are described. In order to illustratethecapabilities of these tools, new commands are integratedinto the standardprojectmanagementsoftware andappliedto an example. The last section is devoted to conclusionsand directions of futureresearch.

Literature review

Wiest13was the pioneer in the study of feasible schedulesin a resource-constrainedcontext. He pointed out that the

ordinarymethodsof calculating slack do not suffice in thelimited resources case. In this work Wiest proposed adefinition of slack appliedto activities on a feasible projectschedule. The calculation of this parameterstarts from aleft-justified project schedule, ie a feasible schedule inwhich, due to precedence relationships and/or resourceconstraints, no activity can be started at an earlier date.The early starttime (EST) of the activities is known andactivities are shiftedright as far as possible by local shiftsin descendingorderof theirearlyfinish times (EFT).In thisnew schedule the Latest StartTime (LST) of each activityis calculated and the slack of an activity in a resource-

constrainedcontext is calculated as LST-EST. Addition-



PTormosandALova-Resource-constrainedprojectschedulingandcontrol 781

ally, in this work a critical sequence is definedas a set ofactivitiesthathave zero slack. This critical sequence is theanalogous concept of critical path used in the unlimitedresource case. After that, Woodworth and Shanahan'4

developed a procedureto identify those activities that arecritical regardingthe completion time of a project in the

environmentof limited resources.In 1995, Bowers1

proposeda revised method of calcu-lating resource-constrained(RC) float.The algorithmstartswith the applicationof the classical ForwardandBackwardpass computationssuch as Moderet at' described.Thenextstep consists of a forwardpass consideringthe limitationofthe resources and applying a parallel algorithmwith theMINLST rule (minimum latest start time) to establishpriorities. In this process a resourceusage history is notedadding resource links between activities of the project;abackwardpass is appliedconsideringthese resourcelinks.

Finally, in orderto calculate the slack of the activities the

earliest and latest scheduled dates are compared. Thedefinition of this resource-constrainedslack is similar tothat of total slack when resource availabilityis unlimited,that is, the time by which a single activity can be extendedor delayedwithoutaffectingthe projectcompletiontime.

Finally, Raz and Marshall'6 proposednew slack defini-tions (Scheduled Total and Free Slack) that retain the

original meaning while accounting for the effect ofresource availability on the schedule. Scheduled TotalSlack is calculated as the difference between early andlate scheduled dates-the latterareobtainedby a procedurethat includes the applicationof a resource levelling tech-

nique to 'eliminate' any instances in which resourcerequirements exceed total availability. Scheduled FreeSlack is defined as the number of time periods that theactivity can be delayed beyond its early scheduled datewithout affecting any of its immediate successors eitherdirectly through time dependencies, or indirectly throughresourcedependencies.On the otherhand, in practice it isimportantto make reference to the way in which a projectmanagementtool such as MicrosoftProjectcalculates totaland free slack, outlining that the results obtained aremisleading when activities compete for using commonresourcesthat are available in limited quantities.

All the above-mentionedworks coincide in pointingoutthe need for informationwhich can advise the PM where toconcentrateefforts in projectmanagement.Nevertheless,inthese works neither the problem of identifying the criti-cality of the activities in a resource-constrainedprojectschedule with generalisedprecedence relationswith mini-mal time lags nor the analysis of possible earlierexecutionof the activities are taken into account.On the otherhand,the analysis of extrahours and the use of idle resourcesinorder to solve the rescheduling of an activity are notconsidered either. Finally, none of these works-exceptthat of Raz and Marshall'6 analyse the response of

standardprojectmanagement softwareto this question. In

this sense, advances are needed both in parameters toidentify the criticality of the activities in the context of

resource-constrainedas well as in the improvementof theprojectmanagementsoftware capabilities.

MethodologyRecently, in order to analyse the extension of the projectscheduling techniquesusage, a survey has been designed.The survey has been carried out in the Valencian Region,Spain,'7 consideringcompanies fromthe areas of construc-

tion, textile, computersand informationsystems as well aspublicadministration.1000 surveys were sentout, of whichthe authorsreceived 202, a responserate of approximately20%. One of the main results of the survey highlights theuse of software scheduling tools in the allocation ofresources to project activities, improving project controland aidingdecision making.Nevertheless,companies indi-

cate thatproject-schedulingtechniquesneed to have moreflexibility for the practitioner.Specifically, what the PMwould need is a schedulingdevice thatcorrectlyscheduledthe activities and identified which of those activities arecriticalwith respect to precedencerelationsand/orresourceconstraints.

In order to satisfy these requirements, new tools forscheduling and controlproject activities are needed.

Previousdefinitionsand new concepts

In Lova et al18,19 the concepts of Backward Free Slack

(BFSi) and ForewardFree Slack (FFSi)are defined. In thepresent paper,these concepts (useful in order to reducethecompletion time of the multiprojectwhen activities arefinish-start related with zero time lag and the resourceavailabilityis limited) are adaptedto the generalisedprece-dencerelationcase. Then,the ForwardFree Slack(FFS,) ofan activityi into a feasible schedule is definedas the amountof time that the activity can be shifted right, allowing theremainingactivities to start on their scheduled dates. The

FFSi is calculatedas follows:

f SSTj- SSTI-SSj V(i,j) E Ass

FFS _ min SFT - SFTi - FF~i V(ij) EAFF IFFS ~SF1) SSTJ> SF71 V(i,j) E As~f

SSTj- SFT - FSi1 V(i,j) E AFS )

On the otherhand,the BackwardFreeSlack(BFS,) of anactivity i is the amount of time that the activity can beexecutedearlierallowing the remainingactivitiesto startontheir scheduled dates. The Backward Free Slack of anactivity i is calculatedas:

(SSTi- SSTj- SSji V(j, i) EA55s

S min SFTi-SFTj-FFji V(j, i) E AFF

BiS I SFT7- SST - SFji V(j, i) E AsE

SST7-SFTj-FS1l V(j, i) e AFS



782 JournaloftheOperationalResearchSocietyVol.52,No,7

In both definitions resource constraints are not considered.

These concepts would be complemented with the corre-

sponding Forward and Backward Total Slack. These new

parameters will indicate the amount of time that an activity

can be executed later or earlier without changing either the

start or the completion time of the project.

The Forward Total Slack (FTSi) of activity i in a feasibleschedule is the amount of time that the activity can be

executed later, maintaining both the feasibility and the

project completion time. The FTS, is calculated as follows.

Step 1. From the project feasible schedule, activities are

selected in decreasing order of their SF77, ie the

first activity considered is that with the greatest

SFT, the current Forward Free Slack (FFSj) is

evaluated and the Latest Feasible Start Time

(LST7) and Latest Feasible Finish Time (LF77)

are obtained as follows:

LS1; - max{t/SSTj < t< SS Tj+FFS> Irjk < Rk

VV X [tI... Xtd+ - ]} Vk E [I ... K}}

LFT7= LSTj + dX

where the leftover capacity of the renewable

resource k in period t is denoted by Rkt and

calculated as:

Rk - -EZ kP(t)

Step 1 is repeated for each activity , whose

Scheduled Start Time (SSTJ)is greaterthan theSFTi, following the established ordering. This

implies a dynamic calculation of the FFSj, where

the LSTand the LFTof its successor activities are

considered. Activities whose Scheduled Finish

Time (SFT7) is equal to SFTn (feasible project

completion time) cannot be executed later.

Step 2. Calculate the Forward Total Slack of activity i as:

LSTj - SSTI - SS,j V(ij) E Ass

FTS _ min LFTj - SET; - FF, V(i,) E AFFLFTj - SSTI -

S77i V(i,) EAsFf

LST -SFTi- FS1 V(i,j) E AF

Step 3. Activities are shifted in the reverse order of the one

used in Step 1. Each activity j (satisfying LS5T>

SFTi) is scheduled in the earliest feasible position

into the time window [SSTj... LFTI]. Their sched-

uled dates are then updated.

The Backward Total Slack (BTSi) of activit i is the

amount of time that the activity can be executed earlier

maintaining both the feasibility and the project start time.

The BTSi is calculated as follows:

Stp 1. From thieproject feasible schedule, ac vities geselected in increasingorderof the SS? ie the first

activityconsideredis thatwiththesmallestSST,thecurrentBackwardFreeSlack(BFS,)is calculatedandthe EarlyFeasibleStartTime (ESTj)and the EarlyFeasibleFinishTime(EFT) areobtainedas follows:

ES =min {t/SST- BFSj < SSTjIrjk R

vnc [t,..ItH+d - i1] VkE [ ...K]}EFT = EST)+ dj

Step I is repeatedfor each activityj (satisfyingSFT1<SST1)following the establishedordering.In the BFSjcalculation,the EST andthe EFTof itspredecessor activities are considered. Activitieswhose SSTIare equal to SST, (feasible projectstarttime) cannot be executed earlier.

Step2. Calculatethe BackwardTotal Slackof activityi as:

fSSI>ES?- SSjj V(j, i) E Ass

BTS-= min4SFTJ-

EFTj-

FFji V(j i) E AFFSFTi - ESI - SF~ V(j,i) CAsFE

1SST;-EFT -FSji V(J]i) E AFs)

Step3. Activities shiftedin Step I are shiftedin thereverseorder of the one used in Step 1. Each activity j(satisfying EFT,< SST1)is scheduled in the latestfeasible position into the time window [ESTj ...

SFTj].Its scheduled dates are then updated.

As in the definition of the FFS and BFS, the timewindows definedby FTSandBTScan include both feasibleand not feasiblepositions.

Cricalit index in the RCPSP

Once the concepts of total slack have been adaptedto thecontext of constrainedresources with generalised prece-dence relations, it is necessary to establisha classificationof the activities as critical or noncritical, depending onthese values. The classification additionally considerswhether the activities are critical only with respect toresources(ResourceCritical) or also with respectto prece-dence relationships(Absolutely Critical).

It is well knownthat the value of total slack indicates-in the unconstrainedcase-the degree of criticalityof theactivities related to the project completion time. In fact,regarding the value of the total slack, an activity can beclassified as critical when total slack is equal to zero andnoncritical when total slack is greaterthan zero. Never-theless in the resource-constrainedcase the degree ofcriticality is more difficult to establish. In this work thecriticality of an activity is consideredas depending on thevalue of the ForwardTotal Slack or BackwardTotal Slack.Hence, an activitycan be classifiedas Forward_AbsolutelyCritical Activity (F_ACA), Forward_Resource Critical

Activity (F_RCA) or Forward_Non Critical Activity




(F_NCA).Analogously,regardingBackwardTotal Slackthe

activities can be classified as:Backward_AbsolutelyCriticalActivity (B_ACA), Backward_ResourceCritical Activity(B_RCA) or Backward_NonCriticalActivity (B_NCA).

An activity is a ForwardAbsolutely Critical Activity

(FFACA)when its FTS is equal to zero. This activity

cannot be delayed maintainingboth the feasibility of theschedule and the project completiontime. An activity is aForward_ResourceCriticalActivity(F_RCA)when its FTS

is greater than zero and cannot be delayed into its FTS

maintainingthe feasibilityof the schedule. In this case thePM can delay the scheduleddatesof the activity solving the

unfeasible positions considering idle resources or extra

resources. Finally, an activity is a Forward_Non Critical

Activity(FJ_NCA)when its FTS is greaterthan zero andhas

new feasible positions into its FTS.

Regardingthe BackwardTotal Slack an activity can beclassified as a Backward_AbsolutelyCritical Activity

(B&ACA)when its BTS is equal to zero. This activitycannotbe scheduledin earlier dates maintainingthe feasi-

bility of the schedule as well as the projectstart time. An

activity is a Backward_ResourceCriticalActivity(B_RCA)when its BTS is greaterthan zero and cannot change its

scheduleddates to earlierdates into its BTS maintainingthe

feasibilityof the schedule.This situationimplies again that

the PM can reschedulethe activity to earlierdates solvingthe unfeasible positions consideringidle resources or extraresources.Finally, an activity is a Backward_NonCritical

Activity(B_NCA)when its BTS is greaterthanzero andhasnew feasible positions into its BTS.

The total slack-when the resource availability is notlimited-is the index of its criticality indicatingto the PMthe different positions where the activity can be delayedwithout increasing the project completion time. In theresource-constrained context this criticality index is

misleading and an adapted activity criticality index isneeded. Therefore, in this work the activity criticalityindex is definedas the sumof the numberof earlierfeasiblepositions (into its BTS) where the activity can change itsscheduleddates plus the numberof later feasible positions(into its FTS)thatthe activity can delay its scheduleddates.Thus,with this activity criticality index, the PM can easilyand

quicklyknow the

possibilities of changing the sched-uled dates of the activities (not necessarily neighbourdates). The criticality index has been named Resource-ConstrainedActivity CriticalityIndex (R-C ACI), and canbe expressed as follows:

R-C Activity CriticalityIndex (R-C ACI)

= Number of new feasible positions into its BTS

+ Numberof new feasible positions into its FTS

In the case where resources are unlimited,the notion ofslack is unique and unambiguousdue to the fact that thereis a single slack value associatedwith each activity. When

resources are constrainedthe slack value and the R-C ACIdepends on the feasible project schedule considered.Despite this situation,the concepts described in this workarevery useful whenthe PM has obtaineda feasibleprojectschedule with a satisfactorycompletiontime.

Finally, it is importantto note that the new activity

criticality classification and the R-C activity criticalityindex are a generalisationof the ones used in the uncon-strainedcase. In fact, if the new activity criticalityclassi-fication is appliedto a projectschedulewhere activitiesarescheduled in their earliest dates and resources are not

constrained,activities will be F ACA (critical)or F NCA

(non critical) and all of them will be B_ACA. For each

activitythe amountof R-C ACI will be the value of its total

slack.Nevertheless,if the PM works with a schedule(in theconstrained or unconstrainedcase) where activities arescheduled in their latest dates or with a schedule whereactivities have consumedpartof their availableslacks, the

new definitionsandconceptsdescribedin this workgive tothe PM more complete information, indicating that someactivities are B_RCAor B_NCA with a R-C ACI differentfrom zero.

Integration of the new parameters into standardproject management software

Probablythe most popularproject managementpackage is

MicrosoftProject,which thoughfar frombeing the perfectprojectmanagementsoftware,has leaptto thetop of projectmanagementsoftwaresales. This is due, at least in part,tothe leveraging effect of being part of the vast array ofMicrosoft offerings but also to their persistentmarketingresearchand theirresponseto the marketin sucha way thatin the elapsedtime of eight years, 4 versions were broughtout. One of the most importantcharacteristicscommon toall versions is the continuousimprovementin ease of use,communication and workgroupworking, although flawsstill remain in other aspects such as resource capacitiesand schedulingand controlcapabilities.20

Despite these deficiencies, the customising possibilitiesof Microsoft Project offered through a programminglanguage like Visual Basic for Applications (VBA) makeit possible to integratenew tools into the system. Thus,MicrosoftProjectwith new commandsbecomes a powerfulmanagement tool that is able to manage resources andschedules efficiently considering particularcriteriaof theactivities and helping the projectto be completedon time.The new system enhancesand improves the capabilities ofthe project management software. Therefore, the para-meters describedin the previous section have been devel-oped and coded using VBA and integrated as newcommandsinto MicrosoftProject'98.




The new tools for resource-constrainedproject schedul-

ing and control are based on the concepts described in the

previous section and are classified dependingon whether

they are based on Forwardor Backward slacks:

* FFS/BFS Feasible Positions Analysis: these options

calculate and show the amount of Forward/BackwardFree Slack of the selectedactivity.A feasibilityanalysisin

each period includedin the Free Slack is performedfor

the selected activity.The correspondingreportsinformon

the feasibilityof each possible startdate andallowthePM

to change interactivelythe scheduled start time of the

activity in a controlledmannerto later/earlierdates.* FTS/BTS Feasible Positions Analysis: through these

commands the Forward/BackwardTotal Slack of the

selected activityis calculatedand a feasibility analysisin

each period included in the Forward/BackwardTotal

Slack is performed. As in the case of the FFS/BFSFeasible Positions Analysis

command,the PM can

interactively change the scheduled start time of the

activity. These commands are integratedin the proce-dure to calculate the FTSi/BTS1 described in the

previous section. In Step 2, when FTS/BTS is calcu-

lated, the user can change the start scheduled date and

automaticallythe finish scheduled date to a new posi-

tion, SST' and SFTJ. In Step 3 the old scheduled

finish/start date of the selected activity is considered.With the application of these commands, if the PM

changes the scheduled date of the selected activity,the

slacks of some activitiescan change and theirscheduleddates would be later/earlier.

* FS/BS Analysis: these commandsinform the user aboutthe activities of theproject that have Forward/BackwardFree Slack and/or Forward/BackwardTotal Slack differ-ent from zero and theiramounts.Additionally,the reportsindicatefor each of these activitieswhether or not thereare new feasible positions in the correspondingslacks.

Finally,regardingFTS/BTS, a statistic of project activ-ities consideringthe new activity criticalityclassificationis included.

The low CPU time requiredby these commands thusmakes them powerful tools for decision making.

Other tools included in the system are the Due Datecommands that are classified in Project Due Date, Fixedand Clear.

* The Project Due Date command allows the PM toconsider a new due date different from the feasibleproject completion date obtained with the heuristic. Ingeneral, obtaining a feasible project schedule as short aspossible is very interestingto the PM, due to the fact thatresources are assigned to the project for a short time.Furthermore,reducing the project duration implies theimprovementof other criteriasuch as in-process inven-

tory or resource levelling.20 Nevertheless, this command

adds more flexibility to the schedule by considering a due

date greater than the feasible project completion time.

This fact can increase the Forward slack values and the

possibilities of rescheduling the project activities.

* The Fixed command fixes the scheduled dates of an

activity in the current dates. This activity cannot changeits scheduled dates when the practitioner is rescheduling

the activities of the project or is in the project control

phase. This situation can also modify the slack values of

the activities of the project because this activity cannot be

moved in the total slack calculation process.

* The Clear command allows the PM to consider changing

the scheduled dates of an activity previously fixed allow-

ing its scheduled dates to be modified.

The system developed includes other useful commands

such as Record Schedule that allows the user to record

every schedule obtained and to add a brief description of

the same. It is possible to save up to 10 different

schedules related to a project that can be reloaded using

the option Recover Schedule. These functions are espe-

cially interesting for making What-if analysis quickly and

easily. Finally, an undo command is included (Last

Schedule) in order to remove the last changes performed.

These last tools have been introduced and applied in

previous works.20

In conclusion, once the feasible project schedule has

been obtained, it becomes complex for the PM to make

changes using the standard project management software

because the information offered is not very useful when re-

sources are limited. In this sense, the commands described

Table 1 Projectinstanceto apply the new activity classification

ResourceDuration usage

Activity (days) Successors (r],r2,r3,r4)

Task 1 1 Task9, Task 10, Task 11 (4,4,1,4)Task2 2 Task6, Task 9 (3,3,1,6)Task3 7 Task 7, Task8, Task 9 (2,5,1,2)Task 4 6 Task 9 (1,3,6,5)Task5 5 Task 11, Task 12 (1,3,5,2)Task 6 4 Task 15, Task 17 (2,6,6,1)Task7 1 Task 17 (5,2,2,3)Task8 2 Task 14, Task 15, Task 18 (4,4,3,6)Task 9 9 Task 16, Task 18 (5,6,4,1)Task 10 1 Task 16 (2,3,2,6)Task 11 10 Task 13 (1,1,4,4)Task 12 1 Task 18 (6,1,3,3)Task 13 7 Task20 (6,2,5,1)Task 14 9 Task 19 (5,5,5,2)Task 15 1 (3,4,1,3)Task 16 1 (1,1,3,3)Task 17 4 Task 20 (4,1,1,6)Task 18 6 Task20 (6,5,4,2)Task 19 10 (4,6,3,4)Task 20 10 (4,6,2,5)



PTormosandALova-Resource-constrainedprojectschedulingandcontrol785

in this work are powerful tools for the decision making

process to schedule and control both resource-constrained

and unconstrainedprojects.

Application of the new tools for project schedulingand control

In orderto illustratethe use and performanceof these tools

they are appliedto a projectinstancewith 20 activities with

finish-start precedence relationships and zero time lags,

each activityusing 4 of 4 types of renewableresources.The

limited availability of the resources are 15, 16, 15 and

12units respectively. In Table 1 the duration, successor

activities and the resource usage for each activity are

included.

Figure l(a) shows the initial schedule of the project

obtained applying the Critical Path Method. The project

durationis 32 days and the schedule is not feasible. On therightof Figure 1 the toolbarsincludingthe new commands

are available. The command General Information gives

--------------

_----

i---_

|.|imAl!1"|f

U g , .:.:, - z . tJ ! :~~~... .. . .... . :. .. .... .... .. .... . ..:.. ';. '..:. ;.. ..!'. - ! : ...... . . .... ... . ............

Tusk I

; . ....;. i,........i:i................-}...'i--'.-:!}!t

Tnsi 4 | |

Tusks

Tusk?

Td*a| |3i | |

.. ...1. .. .. . I-| ii 1 | i l z

maollTa lk12 l

Tusi Is

Task2

(b)

Figure 1 Initial project schedule (PDM) (a) and Feasible Schedule (b) MicrosoftProject'98.

basic informationon the projectsuch as name and duration

of the project,numberof activitiesand numberof resource

types used by the project.This commandfurtherindicatesif

the currentprojectschedule is feasible or not.

From the initial schedule of the project instance a

feasible schedule applying the resource allocation algo-rithm that comes with Microsoft Project'98 has been

obtained. The resulting schedule has 39 days of duration

(Figure 1(b)).

In Table 2 all the informationthat can be obtainedwith

the new parametersand tools is summarised.In particular

the table includes the BFS, BTS, FFS, FTS and the

number of new feasible positions that each activity has

in order to change its scheduled dates. The last two

columns summarise highly importantinformationfor the

PM, that is, the resource-constrainedactivity classification

and the resource-constrainedactivity criticality index. For

instance, Task 10 is B_NCA and F_NCA and has a R-C

ACI of 10. These values imply that this activity can be

executed at earlier and later dates than the current ones




Table2

Backward

and

forward

slack

analysis

of

the

project

feasible

schedule

Number

of

Number

of

Numberof

Number

of

Activity

R-C

Activity

Activity

new

feasible

new

feasible

new

feasible

new

feasible

duration

Criticality

R-C

Name

BFS

positions

BFS

BTS

positions

BTS

FFS

positions

FFS

FTS

positions

FTS

(days)

Classification

B/F

Criticality

Task1

5

0

5

0

0

0

0

0

1

B_RCA/F_ACA

0

Task2

6

0

6

0

0

0

3

3

2

B_RCA/F_NCA

3

Task3

0

0

0

0

1

1

4

4

7

B_ACA/F_NCA

4

Task4

0

0

0

0

2

0

5

3

6

B_ACA/F_NCA

3

TaskS

0

0

0

0

1

0

1

0

5

B_ACA/F_RCA

0

Task6

2

0

2

0

9

0

10

6

4

B_RCA/F_NCA

6

Task7

8

0

8

0

7

0

8

3

1

B_RCA/F_NCA

3

Task8

1

0

1

0

7

0

10

6

2

B_RCA/F_NCA

6

Task9

0

0

0

0

6

0

6

3

9

B_ACA/F_NCA

3

Task

0

21

7

21

7

0

0

10

3

1

B_NCA/F_NCA

10

TaskI1

0

0

0

0

0

0

0

0

10

B_ACA/F_ACA

0

Task

12

9

0

9

0

8

0

8

3

1

B_RCA/F_NCA

3

Task

13

0

0

0

0

6

0

6

0

7

B_ACA/F_RCA

0

Task

14

7

0

7

0

0

0

3

3

9

B_RCA/F_NCA

3

Task

15

14

9

14

9

10

10

10

10

1

B_NCA/F_NCA

19

Task

16

0

0

7

7

10

10

10

10

1

B_NCA/F_NCA

17

Task

17

7

7

7

7

2

0

2

2

4

B_NCA/F_NCA

9

Task

18

6

0

6

0

0

0

0

0

6

B_RCA/F_ACA

0

Task

19

0

0

0

0

3

3

3

3

10

B_ACA/F_NCA

3

Task

20

0

0

0

0

0

0

0

0

10

B_ACA/F_ACA

0

BFS

New

feasible

BTS

New

feasible

FFS

New

feasible

FTS

New

feasible

Activities

<

>

positions

<

>

positions

<

>

positions

<

>

positions

with:

0

in

its

BFS

0

in

its

BYTS

0

in

its

FFS

0

in

its

FTS

%

activities

55

15

60

20

65

20

80

70




while maintaining the feasibility of the schedule. These

changes can be done in 10 new feasible positions. If the

PM needs a higher level of detail, Table 2 informs thatTask 10 can be executed earlier in 7 new feasible

positions or can be delayed to 3 new feasible positions.The least critical activities are those with a high value of

R-C ACI such as Task 15 and Task 16 with 19 and 17new feasible positions respectively. On the otherhand themost critical activities are Task 11 and Task 20, having a

criticality index (R-C ACI) equal to zero. These twoactivities are B ACA and F_ACA. However, Task 1,Task 5, Task 13 and Task 18 have a R-C ACI equal to

zero, but with respect to the Forward or Backward

analysis are RCA. That is to say, the PM can changetheir scheduled dates but must solve the unfeasibilitywith

idle or extraresources.At the end of Table 2 a statistic ofthe project activities is presented, showing that 55 % ofthe activities have BFS differentfrom zero but only 15%

of the project activities have new feasible positions intheir BFS. 60 %of the activities have BTS and 20 % havenew feasible positions. On the other hand, 65 % of theactivities have FFS and 20 % have new feasible positions.Finally, it is important to outline that 80% of theactivities have FTS and 70 % can delay their scheduleddates to feasible positions. The user can obtainthese dates

every time it is necessary to make decisions in projectschedulingor control pointing out that in the context of

resource constraintsthereare many possibilities of makingchanges in a controlled manner.Additionally, it is possi-ble to include in the reportsthe amount of conflict hours

and idle hours for each nonfeasible position and for eachresource,during the execution of the activity. In this way,the PM has more complete information about the resche-duling of this activity.

Finally, when projects are in execution and the projectcontrol is performed,activities that have been finished canbe considered in the schedule as fixed and activitiesscheduled in the future can be shifted in orderto considerparticularcriteriaof the activities.

Conclusions

Project Managers have been educated with the idea ofcritical paths and slacks but as soon as resources areincorporated this information is no longer available.Despite this, they requireadvice as to where to concentrateefforts and often look to the project analysis to provide alist of priorities. For this purpose, in this work the authorshave defined and developed new project scheduling andcontrol parameters. These parameters are very usefulregarding the process of rescheduling activities, in thecontext of constrained resources with generalised prece-

dence relations and in orderto considerparticularcriteriaof activities.

The basic concepts used have been the Forward/Back-

BackwardFree/Total Slackas well as an activity criticalityindex based on them that has been established in ordertoclassify theactivitiesin theresourceconstrainedcase. These

new tools have been integrated into the standardprojectmanagement software Microsoft Project'98 thus allowingthe Project Managerto reschedule the resource constrainedproject activities and to determine new activity start andfinishtimesin a controlledmanner.Therefore,thisworkfillsthe existing gap in the lack of information and what-ifanalysis tools in the practiceof project management.

Finally,it is importantto pointout that these tools can be

easily generalisedand then applied to other environmentswhere resource availability varies over time and whenseveral projects are executed concurrently sharing acommon pool of constrainedresources.

Acknowledgements-We are grateful to the editor and the two anonymous

referees for their helpful comments and valuable suggestions to improve the

manuscript.

Appendix

Notation

SST: Scheduled StartTime

SFT: ScheduledFinishTimeEST: Early Scheduled StartTime

EFT: Early ScheduledFinishTimeLST: LatestScheduledStartTimeLFT: LatestScheduledFinishTimeFFS: ForwardFree SlackFTS: ForwardTotal SlackBFS: BackwardFree SlackBTS: BackwardTotal SlackF_ACA: ForwardAbsolutelyCriticalActivityF_RCA: ForwardResourceCriticalActivityF_NCA: ForwardNon CriticalActivityB_ACA: BackwardAbsolutely CriticalActivityB_RCA: BackwardResource CriticalActivity

B_NCA: BackwardNon CriticalActivity

References

1 Moder J, Phillips C and Davis E (1983). ProjectManagementwith CPM,PERTand PrecedenceDiagramming,3rdedn. VanNostrandReinhold:NewYork.

2 ElmaghrabySE and KamburowskiJ (1992). The analysis ofactivity networks under generalized precedence relations.MngmntSci 38: 1245-1263.

3 BrinkmannK and NeumannK (1996). Heuristicproceduresforresource-constrainedproject scheduling with minimal andmaximal time lags: the minimum project-duration andresource-levellingproblem.J Decision Syst 5: 129-156.




4 Zhan J (1994). Heuristics for scheduling resource-

constrained projects in MPM networks. Eur J Oper Res 76:

192-205.

5 Neumann K and Zhan J (1995). Heuristics for the minimum

project-duration problem with minimal and maximal time

lags under fixed resource constraints. J Intell Manufac 6:

145-154.

6 Schwindt C and Neumann K (1996). A new branch-and

bound-based heuristic for resource-constrained projectscheduling with minimal and maximal time lags. In: Weglarz

J (ed). Proceedings of the Fifth International Workshop on

Project Management and Scheduling, April 11-13, Poznan.

Scientific Publishers: Poznan, Poland, pp 212-215.

7 Franck B and Neumann K (1996). Priority-rule methods

for the resource-constrained project scheduling problem

with minimal and maximal time lags-an empirical analysis.

In: Weglarz J (ed). Proceedings of the Fifth International

Workshop on Project Management and Scheduling, April 11-

13, Poznan. Scientific Publishers: Poznan, Poland, pp 88-91.

8 De Reyck B, Demeulemeester E and Herroelen W (1998).

Algorithms for scheduling projects with generalized precedence

relations. In: Weglarz J (ed). Project Scheduling. Recent

Models, Algorithms and Applications. Kluwer: Amsterdam,

pp 77-106.9 Mohring S, Stork F and Uetz (1998). Resource-constrained

project scheduling with time windows: a branching scheme

based on dynamic release dates. Proceedings of the Sixth

International Workshopon Project Management and Schedul-

ing, July 7-9, Istanbul. Bogazici University Printing Office:

Istanbul, pp 98-101.

10 Domdorf U and Pesch E (1998). Constraint-based project

scheduling. In: Matarazzo B (ed). Proceedings of the 16th

European Conference on Operational Research, 12-15 July,Brussels. Belgium OR Society: Brussels, Belgium, p 59.

11 De Reyck B and Herroelen W (1998). A branch-and-bound

algorithm for the resource-constrained project scheduling

problem with generalized precedence relations. Eur J Opl Res

111: 152-174.

12 Maroto C, Tormos P and Lova A (1998). The evolution of

software quality in project scheduling. In: Weglarz J (ed).

Project Scheduling. Recent Models, Algorithms and Applica-

tions. Kluwer: Amsterdam, pp 239-259.

13 Wiest JD (1964). Some properties of schedules forlarge projects with limited resources. Oper Res 12: 395-

418.

14 Woodworth BM and Shanahan S (1988). Identifying the critical

sequence in a resource constrained project. Project Mngmnt6: 89-96.

15 Bowers JA (1995). Criticality in resource constrained networks.

J Opl Res Soc 46: 80-91.

16 Raz T and Marshall B (1996). Effect of resource constraints on

float calculations in project networks. Int JProject Mngmnt 14:

241-248.

17 Lova A (1997). Programaci6n de multiproyectos con recursos

limitados: un enfoque multicriterio. PhD thesis, Universidad

Politecnica de Valencia.

18 Lova A, Maroto C and Tormos P (1998). Resource constrained

multiproject scheduling: a multicriteria heuristic algorithm.In: Barbarosoglu G, Karabati S, Ozdamar L and Ulusoy G

(eds). Proceedings of the Sixth International Workshop on

Project Management and Scheduling, July 7-9, Istanbul. Boga-

zici University Printing Office: Istanbul, pp 90-93.19 Lova A, Maroto C and Tormos P (2000). A multicriteria

heuristic method to improve resource allocation in multiproject

scheduling. Eur J Oper Res 127: 408-424.

20 Tormos P and Lova A (1999). An interactive decision supportsystem integrated into standard project management software.

Technical Report, Universidad Politecnica de Valencia.

Received November 1999;

accepted January 2001 after two revisions

ART ADMINISTRACION DE PROYECTOS_01

Documents

Transcript of ART ADMINISTRACION DE PROYECTOS_01