Work patterns in project scheduling - CiteSeerX

Baltzer Journals

26.9.1996

Work patterns in project scheduling

Asa Hallefjord1 and Stein W. Wallace2 ;

Norske Shell A.S., Stavanger, Norway 2Department of Industrial Economics and Technology Management Norwegian University of Science and Technology N-7034 Trondheim, Norway 1

E-mail: [email protected]

In project planning and control it is of vital importance to take into account that dierent categories of resources have dierent work patterns. Algorithms for time analysis, resource smoothing and resource scheduling are almost always presented as if this has no importance. Practical planning tools, however, have dierent work patterns as a natural part of the data. In this paper, we discuss modelling aspects of introducing work patterns. Keywords: project scheduling, work patterns, calendars, modelling

1 Introduction Network analysis and planning techniques are frequently utilized today for project scheduling and control. A number of sophisticated software tools have been developed, based on methodologies represented by PERT and CPM, as designed in the late 50's by Malcolm et al. [14], and Kelley [11, 12]. A well-know example is Artemis. Cauwenberghs [5] reviews a total of 74 dierent software packages, and Assad [2] presents 13 systems for microcomputers. In parallel, we have seen a plethora of algorithmic developments on the subject. These developments are mainly on resource scheduling problems, which means that starting times are to be set for a number of activities such that total project completion time is minimized. Constraints on resource availability must be ful lled at each point in time. Attempts have been made to adapt results from combinatorial optimization (Fisher [9]) and parallel processing (Chaudhuri and Ghosh [6]). Both optimizing methods and heuristics have been suggested, for dierent versions of resource scheduling problems. In addition to this, new model formulations have appeared, for which more and more sophisticated methods are required, such as e.g. two-stage stochastic programming (Wollmer [17]) and time-cost analysis (Leachman [13]). Most of this work was done while both authors were at Chr. Michelsen Institute in Bergen, Norway. The paper was nished in 1989, but was never published. To account for what has happened since 1989, a new nal section has been added to the paper.

A. Hallefjord and S. W. Wallace / Work patterns in project scheduling

2

Norsk Data has developed a system for project planning and control, called Formula. The authors of this paper have been involved in the design of the actual network

algorithms and data structures for the system. After more than one year's work, the authors feel that there is an unusually large gap between the practical and theoretical developments in the network planning area. In this paper we focus on one problem that seems to have been totally neglected in modern methodological development as well as in most textbooks. The problem is that of dierent types of work force (or resources) having dierent work patterns. It is surprising that even books that are supposed to be practically oriented and " [of] bene t to the practising engineers/managers" (Bhatnagar [4]) have disregarded this important point. Also the most cited book on the subject | Elamghraby [7] | ignores this issue. It is well-known (see [7]) that the introduction of limits on resource availability, smoothing criteria and so on, makes the scheduling problems much more complicated. But in order to keep exposition simple here, we restrict ourselves to the problem of time analysis. That is, we want to solve the problem of minimizing total project time, subject to logical relations between activities. It will be seen that the presence of dierent work patterns complicates the picture, even if the resulting problem is simple from an algorithmic point of view. We are only concerned about when resources are available, not the amount of resources available. By resources we shall mean what is also referred to as services. Such a resource is de ned as being available in a certain quantity each time period. An example is the resource painter which is employed by a company. If the painter has nothing to do on a Monday, he is not available in duplicate on Tuesday. The other type of resources, often called goods, can be considered as inventory. For each time period the inventory can be saved until the next time period, it can be used in part, or more can be added to the inventory. Paint is an example of a good. If the painter has a bucket-full of paint on Monday morning, and uses no paint on Monday, the same bucket-full will be available on Tuesday morning. For each resource, de ned as above, a pro le for resource availability is given as a number for each period. There is a duration and resource requirement pro les for each activity. All work patterns are de ned relative to a basic calendar; time periods numbered consecutively from 1 up to an upper limit. A work pattern is described by assigning the value \work day" or \holiday" to each time period in the basic calendar. Normally, our usual calendar with 365 days/year is used, but a time period can also be for example a shift. No serious restriction is made by looking at only services when we are dealing with the problem of dierent work patterns, since these are the ones that usually follow a work pattern. It is natural to think of the painter as somebody who works Monday to Friday, but the bucket of paint might just as well be used on a Saturday or Sunday.

2 Modelling questions In order to model work patterns there are, in our view, two major questions to be asked.


3

Question 1

Should work patterns be assigned to activities or resources?

As we have de ned work patterns, it is a direct consequence that they should always be assigned to resources, never to activities. This holds despite the fact that there are examples where it feels natural to claim that an activity is directly associated with a work pattern. It might be meaningful to assign a work pattern to an activity, but it is always meaningful to assign it to a resource. Therefore, in a computer system for project scheduling, when an unambiguous problem statement is needed, the modelling approach must be to attach work patterns to resources. We shall see under the next question how an activity obtains a work pattern of its own from the work patterns of the resources it uses. Some activities apparently require no resources. An example would be \leave the newly painted wall so that it can dry". In such cases, an activity is assumed to use the resource \time" that follows a work pattern which has every time period as \work day", i.e. it follows the basic calendar. Note however, that if you wish an activity to follow the basic calendar, and use no resources, you can as well enter this as a relation with a time lag. This is, in our view, better modelling. The reason is that we can now tell the user that whenever time is to elapse on a work pattern, use activities to describe it; whenever time is to elapse on the calendar, use relations with time lags. (A nish-start relation with time lag k means that at least k time periods must elapse from the nish of the rst activity to the start of the second.) Very often, however, an activity that is entered into a project scheduling system without resources does in fact use resources. It is just that the user did not bother to say it explicitly, most often because this is a resource with no limitations on availability. It is therefore convenient to de ne a basic work pattern, which is used whenever no explicit resource is given. Any work pattern can be the basic work pattern, but is will usually contain Monday through Friday every week, except public holidays.

Question 2

Can an activity use resources that are on dierent work patterns?

To be able to answer this question, we must decide on one major question, namely whether or not the resources must work together. If, for example, an activity needs a carpenter and his aid (and they work on dierent work patterns), and both must be present to get the job done, the activity can run only on those days that are in both work patterns. This means that the work pattern of the activity is the intersection of the work patterns of its dependent resources. If the relevant work patterns are those in Table 1, the work can take place only on Tuesdays and Wednesdays. On the other hand, if an activity requires resources that work independently, the activity will nish when the last resource has nished its job. If a job takes four days, we need resources on Work patterns 1 and 2 in Figure 1, and we start on a Monday, the resources using Work pattern 1 will nish on Monday night of the second week, whereas the other resources will nish Friday night of the rst week. Hence, the activity will nish when the resources on Work pattern 1 nish. We suggest to combine these two cases by replacing each activity by sub-activities in

A. Hallefjord and S. W. Wallace / Work patterns in project scheduling Table 1: Basic calendar for our example, plus two work patterns and the between them. W=work day. Basic calendar Mo Tu We Th Fr Sa Su Mo Tu Work Pattern 1 W W W W W Work Pattern 2 W W W W W Intersection W W W

4 intersection We W W W

parallel, one for each work pattern used by those of its resources that work independently, and one for each collection of resources that work together. Then let each sub-activity be assigned a work pattern which is the intersection of those used by its resources. This way the two cases can be treated the same way. This sort of uniformity is clearly an advantage when algorithms are to be written. It is never good to have to treat special cases.

3 Consequences of using work patterns Critical paths

As with time windows, when work patterns are used, there is no longer necessarily a critical path in the network, but rather separate critical sub-paths. The reason is that the project duration is not a continuous function of activity durations due to the work patterns. Job interruption

It is not the purpose of this paper to discuss job interruption as a general problem. We only want to point out a few diculties that can occur in the interpretation of job interruption if work patterns are used. Anyone making a project scheduling system must decide on whether or not to allow a job to be interrupted. By interruption is meant that a job is stopped at any time and then continued later on. There are clearly activities that cannot be interrupted, such as \pouring concrete". Others can be interrupted at speci c points in time. An example would be \paint the room". You might want to allow for interruptions in the corners of the room, but not anywhere else. (Anybody would be able to see where you stopped.) Some authors allow in nitely many interruptions, see e.g. Weglarz [15], but most don't. It is our view that if an activity can be interrupted a nite number of times, those points in time are in fact known. For example, when painting a room, as discussed above, we allow interruptions only in the corners, meaning that we allow no interruptions in the middle of a wall. We can therefore split the activity into sub-activities in series, such that each sub-activity cannot be interrupted. (This splitting can most eciently be done by the system, the user just tells you where the points in time are, he doesn't have to input all the sub-activities.) The only true alternatives are therefore to allow in nitely many interruptions or no interruptions. We see no additional problems arising from the use of


5

work patterns if one has chosen to allow in nitely many job interruptions. The reason is

that when any number of interruptions is allowed, the extra interruptions caused by the work pattern is of no concern. We shall therefore discuss only the case when interruptions are not allowed, as that results in some principal diculties. Again consider Table 1. Assume we are faced with an activity that uses resources on both work patterns, and that these resources must work together. The work pattern of the activity is therefore the intersection. Assume the activity takes three days and start on a Tuesday. It then nishes in the evening of the following Tuesday. The question is; has this job been interrupted? Seen from the calendar it certainly has. After two days work on the activity, ve days elapsed when nothing happened before the activity was nished on the following Tuesday. If a worker on Work pattern 1 is asked the same question, he will also say it was interrupted. After working for two days, he spent one working day (Monday) on some other activity before he returned to the activity in question. A worker on Work pattern 2 would have a similar statement to make. However, within the work pattern of the activity (the intersection) there were no interruptions. So the question remains; was this an interruption? At this point it is important to remember that we are discussing a computer system that is going to be used by people out in the real world. It is to a large extent up to them to decide if our de nition of interruption makes sense. In this case they would most probably feel that an interruption took place. Then it would not help if we de ned this not to be an interruption. We would just end up with a system the user did not like. On the other hand, if we de ne interruptions to be relative to the calendar, this activity will never take place; the problem is infeasible since there are no three consecutive days available. This is de nitely not a reasonable approach. As a conclusion we see no alternative but to de ne interruptions relative to the work pattern of the activity. However, we must be careful about what we tell the user. What we really mean is not that interruptions cannot take place, but that whenever an activity is started, it will nish as quickly as possible within its own work pattern.

4 Suggestions and conclusions In spite the fact that there are problems with having work patterns associated with dierent resources, we clearly suggest that they are included in a computer system. No system can be of bene t to serious users without them. We believe that what we have suggested in this paper is sucient for attacking practical project planning problems. Our guidelines are as follows: 1. Work patterns should basically be associated with resources, not activities. 2. One and only one work pattern should be used in connection with each activity. In some cases this work pattern is derived from those used by its resources. If, on input, an activity has resources on dierent work patterns, duplicate it into parallel sub-activities, one for each collection of resources that must work together, and one for each work pattern used by resources that work independently of each other. After this creation of sub-activities, one can assume that an activity always gets a work pattern that is the intersection of those used by its resources.


6

3. Be aware that when work patterns are used, there is no longer a critical path in the network, only critical sub-paths. 4. A basic work pattern should be de ned. Any activity that does not use any resources is associated with this work pattern. If the user wants time to elapse on the calendar rather than the basic work pattern, he should use relations with positive time-lags. 5. If the maker of the project scheduling system does not wish to allow in nitely many job interruptions, he should do the following: (a) Whenever it is clear that an activity can be interrupted at a nite number of points, partition the activity into sub-activities in series. New relations are introduced at those points in time where interruptions can take place. Then require that these sub-activities cannot be interrupted. (b) Be aware that it can be dicult to interpret the results as being without interruptions. It is better to interpret the requirement of "no interruptions" as "as soon as an activity is started, nish it as quickly as possible."

5 New references Since this paper was written in 1989, there is a need to update the references. This is taken care of by a new section, rather than by changing the original text. First, of course, a number of newer descriptions and evaluations of software has emerged. The most solid one seems to be by De Wit and Herroelen [16] from 1990. They analyze in detail ten of the most popular packaged. Newer, but less deep descriptions, can be found in for example Jungbluth [10], and Allnoch [1]. New textbooks have also been publisher. A very thorough one is \Comprehensive project management" by Badiru and Pulat [3] from 1995. In addition it is worth mentioning the article by Elmaghraby [8] as a source for understanding where the eld is going. First, we note that in the new textbook [3], the issue of calendars and work patterns are still ignored. In the software packages, according to [16, pp. 110{111], some packages treat what they refer to as dierent calendars (which mostly correspond to our work patterns), and that one may, for these packages, associate activities with calendars (work patterns). As we have pointed out in this article, such an approach may cause quite a bit of diculties in both modeling and solution approaches. This should show that the issues discussed in this article have not become obsolete since 1989. In fact, to the extent that calendars and similar issues are included in software, they are included in exactly the way we here ague against. Finally, it is relevant to add one more reference to the list, namely that of Zhan [18] from 1992. Zhan discusses the issue of calendars in the light of job interruptions and time lags. The concerns are several. He points out that time lags can be in dierent units. He therefore distinguishes between absolute and relative time lags. This corresponds to our suggestion that if time is to elapse on the basic calendar, it can as well be represented by a time lag, whereas if time is to elapse relative to a work pattern, use an activity to describe it. A second concern of the article is that of the interpretation of job interruptions. Is


7

a job to be non-interrupted relative to the basic calendar, or relative to a work pattern (which he calls a calendar)? The article develops procedures for resolving these issues. Hence, this article extends our discussions in Section 3. The article is not concerned with our main issue, namely that of associating work patterns with resources rather than activities.

Acknowledgements We have been aware of the presented practical problems after involvements in interesting discussions with Norman Sanders (Asker Consult a/s), Per Maastad (MIPS a/s) and ystein Amland and Jan Helge Norekval (Norsk Data a/s). Thanks are due to Salah Elmaghraby and Klaus Neumann for useful input to the 1997 update of references to this article.

References [1] A. Allnoch. Choosing the right project management software for your company. IIE Solutions, pages 38{45, March 1997. [2] A. A. Assad. Project management using a microcomputer. Computers and Operations Research, 13:231{260, 1986. [3] A. B. Badiru and P. S. Pulat. Comprehensive Project Management. Prentice Hall PTR, Englewood Clis, NJ, 1995. [4] S. K. Bhatnagar. Network Analysis Techniques. Wiley Eastern Limited, New Delhi, India, 1986. [5] M. Cauwenberghs. Project management | een overzicht van softwarepakketten. Revue Belge de Statistique, d'Informatique et de Recherche Operationelle, pages 72{89, 1984. [6] P: Chaudhuri and R. K. Ghosh. Parallel algorithms for analyzing activity networks. BIT, pages 418{429, 1986. [7] S. Elmaghraby. Activity Networks: Project Planning and Control by Network Models. John Wiley & Sons, New York, 1977. [8] S. Elmaghraby. Activity nets: A guided tour through some recent developments. European Journal of Operational Research, 82:383{408, 1995. [9] M. Fisher. Optimal solution of scheduling problems using lagranges multipliers: Part i. Operations Research, pages 1114{1127, 1973. [10] V. Jungbluth. Teamarbeit. Projectmanagement-Systeme im Vergleich. c't, 10:238{252, 1995. [11] J. E. Kelley Jr. Computers and operations research in road building. In Operations Research, Computers and Management Decisions. Case Institute of Technology, 1957. [12] J. E. Kelley Jr. Critical path planning and scheduling, mathematical basis. Operations Research, 9:296{320, 1961. [13] R. C. Leachman. Multiple resource leveling in construction systems through variation in activity intensities. Naval Research Logistics Quarterly, pages 187{198, 1983. [14] D. G. Malcolm, J. H. Roseboom, C. E. Clark, and W. Fazar. Applications of a technique for R&D program evaluation. Operations Research, 7:646{696, September-October 1959. [15] J. Weglarz. Project scheduling with continuously-divisible, doubly constrained resources. Management Science, pages 1040{1053, 1981.


8

[16] J. D. Wit and W. Herroelen. An evaluation of microcomputer-based software packages for project management. European Journal of Operational Research, 82:103{139, 1990. [17] R. D. Wollmer. Critical path planning under uncertainty. Mathematical Programming Study, 25:164{171, 1985. [18] J. Zhan. Calendarization of time planning in MPM networks. ZOR | Methods and Models of Operations Research, 36:423{438, 1985.