Interpreting float in resource constrained projects

Interpreting float in resource constrained projects

International Journal of Project Management 18 (2000) 385±392 www.elsevier.com/locate/ijproman Interpreting ¯oat in resource constrained projects J...

539KB Sizes 0 Downloads 3 Views

International Journal of Project Management 18 (2000) 385±392

www.elsevier.com/locate/ijproman

Interpreting ¯oat in resource constrained projects J.A. Bowers* Department of Management and Organization, Faculty of Management, University of Stirling, Stirling, Scotland FK9 4LA, UK Received 28 September 1999; received in revised form 31 January 2000; accepted 24 February 2000

Abstract The concept of ¯oat has been adapted for use in resource constrained projects. However, an important characteristic of such projects is that alternative resource allocations are often possible, resulting in a number of schedules with identical durations. An activity may be critical in one schedule but have considerable ¯oat in another. Alternative measures of ¯oat are explored which capture this ¯exibility of the resource constrained project. The practical interpretation of these measures is demonstrated in an analysis of a simpli®ed software development programme. 7 2000 Elsevier Science Ltd and IPMA. All rights reserved. Keywords: Resource; Scheduling; Float

1. Introduction Float and the critical path have long been central to the analyses of non-resource constrained project networks. However, when resource constraints are introduced a new measure of ¯oat is needed; the desirability of such a measure has been noted in reviews project network scheduling by Willis [1] and Ragsdale [2]. Weist [3] proposed the `critical sequence' as an extension of the critical path: the project duration is determined by a critical sequence of activities which re¯ects both the precedences of the network and also the interdependencies implied by the activities' sharing of resources. The concept was employed by Woodworth and Shanahan [4] in their study and it was also adopted by Bowers [5] in the development of a set of heuristics for determining resource constrained ¯oat. These developments captured the impact of the resource allocation on the schedule in a measure of resource constrained ¯oat re¯ecting the importance of activities which demand resources in short supply. However, this de®nition of ¯oat assumed a single * Tel.: +44-1786-467377; fax: +44-1786-467329. E-mail address: [email protected] (J.A. Bowers).

resource allocation resulting in a ®xed schedule and critical sequence. Even in a simple resource constrained network, alternative resource allocations are often possible resulting in a choice of schedules with identical project durations but di€erent critical sequences. An activity may be critical in one schedule but have considerable ¯oat in another. Raz and Marshall [6] explored a de®nition of resource constrained ¯oat involving the generation of two di€erent schedules; this paper examines multiple alternative schedules and proposes de®nitions of ¯oat which attempt to capture the ¯uid nature of the resource constrained network.

2. A de®nition of resource constrained ¯oat A basic de®nition of resource constrained ¯oat, assuming a single schedule and a ®xed critical sequence, has been described by Bowers [5] in detail. This de®nition provides the basis for the proposed developments of the measures of ¯oat, and is thus summarised here using the simpli®ed example of Fig. 1 to illustrate the main features. The software development has been divided into three major components (the interface, analyser and database) which can be

0263-7863/00/$20.00 7 2000 Elsevier Science Ltd and IPMA. All rights reserved. PII: S 0 2 6 3 - 7 8 6 3 ( 0 0 ) 0 0 0 1 7 - X

386

J.A. Bowers / International Journal of Project Management 18 (2000) 385±392

designed, coded and tested in parallel. The design activities require the use of a specialist team (resource R1) and the coding activities require a di€erent team (resource R2). Since only one of each team is available, the resource constraints have a substantial impact on the project duration and the activities' ¯oats are dependent on the sequence implied by the transfer of the resources. The activities' durations and resource requirements are recorded in Table 1. Determining the resource constrained ¯oats requires a series of analyses of the network: 1. A conventional resource constrained analysis is performed generating a schedule (e.g. the early start (ES) and early ®nish (EF) dates of schedule (1) in Table 1). The ¯ows of the resources between the activities are noted (e.g. the transfers of resources are noted in Fig. 1).

2. The resource ¯ows are incorporated as explicit precedence links in the network. The use of the activity-on-node representation simpli®es this process. 3. A further pair of forward and reverse passes of the network, including the links of step (2), are performed to determine the late start (LS), late ®nish (LF), and hence the ¯oats, as recorded in Table 1. Examining the ¯oats, the critical sequence can be identi®ed (1-2-4-7-6-8-11-12-13). Some of the activities (1, 2, 4, 11, 12, 13) lie in the critical sequence because of their technological importance in the project, but others (7, 6, 8) are included because of their mutual dependence on the scarce resource R2. The implications of the ¯oats are familiar: special attention should be paid to the critical activities and they may warrant additional assistance if the project is to be accelerated.

Fig. 1. The software development: schedule A.

J.A. Bowers / International Journal of Project Management 18 (2000) 385±392

387

Table 1 A schedule for the software development Activity

Duration (weeks)

Resource R1

1 2 3 4 5 6 7 8 9 10 11 12 13

Speci®cation System design Interface design Analyser design Database design Interface code Analyser code Database code Interface test Analyser test Database test Integration System test Resource availability

8 10 10 10 10 15 15 15 5 10 5 3 4

1 1 1

1

3. Multiple schedules The ¯oats noted in Table 1 are valid if schedule (A) is adopted. However, the resource allocation might be changed producing an alternative schedule with an

Schedule(A) R2

ES

EF

LS

LF

Float

1 1 1

0 8 28 18 38 43 28 58 58 43 73 78 81

8 18 38 28 48 58 43 73 63 53 78 81 85

0 8 33 18 48 43 28 58 73 68 73 78 81

8 18 43 28 58 58 43 73 78 78 78 81 85

0 0 5 0 10 0 0 0 15 25 0 0 0

1

identical duration. Figs. 1±4 illustrate four such equivalent schedules, each with a project duration of 85 weeks. It can be shown that the four schedules are the only distinct schedules which deliver the minimum duration of 85 weeks. Although there are more possible

Fig. 2. An alternative resource allocation: schedule B.

388

J.A. Bowers / International Journal of Project Management 18 (2000) 385±392

Fig. 3. An alternative resource allocation: schedule C.

permutations for the allocation of the resources, the others involve the analyser stream of activities being allotted the resources last; since the analyser stream involves longer activities, such allocations result in project durations >85 weeks. The ¯oats of each activity in the four schedules are noted in Table 2 and are depicted in Figs. 1±4 by grey shading. Some activities, such as ``interface design'' have a variable ¯oat dependent on the particular schedule chosen: in sche-

dule (B) it has a ¯oat of 10 weeks, whereas in schedule (C) the activity is critical. Considering just a single schedule produces a simple measure of ¯oat but this ignores the inherent ¯exibility of many resource constrained networks. Further, measures of ¯oat can be useful in revealing this valuable ¯exibility: 1. Float2 is de®ned as the maximum of the ¯oats for each schedule.

Table 2 Alternative measures of ¯oat for the software development Activity 1 2 3 4 5 6 7 8 9 10 11 12 13

Speci®cation System design Interface design Analyser design Database design Interface code Analyser code Database code Interface test Analyser test Database test Integration System test

Sched. (A) ¯oat

Sched. (B) ¯oat

Sched. (C) ¯oat

Sched. (D) ¯oat

Float2

EES

LLS

Float3

0 0 5 0 10 0 0 0 15 25 0 0 0

0 0 10 0 5 0 0 0 0 25 15 0 0

0 0 0 5 10 0 0 0 30 10 0 0 0

0 0 10 5 0 0 0 0 0 10 30 0 0

0 0 10 5 10 0 0 0 30 25 30 0 0

0 8 18 18 18 28 28 28 43 43 43 78 81

0 8 48 33 48 58 43 58 73 68 73 78 81

0 0 30 15 30 30 15 30 30 25 30 0 0

J.A. Bowers / International Journal of Project Management 18 (2000) 385±392

2. The early and latest start dates in each schedule are compared to determine the earliest early start (EES(i ) latest, latest start (LLS(i )) for each activity i. 3. Float3 is de®ned as LLS±EES. This is similar to the measure suggested by Raz and Marshall [6], though that was based on just two schedules. Often the EES and LLS of an activity are associated with di€erent schedules: Float3(i )=LLS (i ) ÿ EES(i ) Float3(i )rFloat2(i )

389

some uncertainty about starting the interface design on time. In addition to the specialist team R1, a representative from the users should be available throughout the duration of the activity. Given past experience, it is uncertain whether the users' representative will be free exactly when required.'' Float2 of `interface design' is 10 weeks suggesting it should be possible to ®nd a schedule which provides a substantial temporal contingency for this activity. Indeed, by adopting schedule (B) or schedule (D) the impact of this activity's uncertainty can be reduced. Thus, the project's risk can be reduced without any additional expenditure. 4.2. Problem 2: synchronising with another project

4. The meaning of ¯oat The measures, Float2 and Float3 can help the project planner identify useful ¯exibility in the schedule. The interpretation of these two measures of ¯oat is illustrated by considering two possible problems with the activities `interface design' and `database code'. 4.1. Problem 1: the availability of a users' representative A manager has expressed some concern, ``There is

At a review it was noted that, ``The database code has to be compatible with another new system XX, which is being developed in a separate project. It could cause problems if the database is coded before system XX is complete. Although the planned completion date of system XX is week 20, this date could slip. Is there any chance of ®nding some ¯oat for the database coding?'' The Float2 of all of the coding activities is zero indicating that they are always critical whatever schedule is chosen. However, the Float3 of the data-

Fig. 4. An alternative resource allocation: schedule D.

390

J.A. Bowers / International Journal of Project Management 18 (2000) 385±392

base coding activity is 30 weeks implying a considerable ¯exibility about the timing: the EES of ``database code'' is week 28 and the LS is week 58 suggesting that the possible slippage in system XX might be accommodated. Adopting a di€erent schedule can solve the problems of one activity but create diculties for others. In this example project schedule (B) o€ers a solution which dramatically reduces the potential impact of the uncertainties on the project duration. In schedule (B) both `interface design' has a ¯oat of 10 weeks and also 'database code' does not start until week 40, see Fig. 2. In general the interpretation of the various measures of ¯oat can be summarised as: Float2=0 Float2=x Float3=y

``This activity is always critical, whichever schedule is adopted.'' ``A schedule exists in which this activity has some ¯oat x.'' ``This activity may be scheduled to start at a variety of times within a range of y.''

Particular care should be taken with the measure Float3. Although there may be a wide range between the earliest ES and latest LS, it is not necessarily true that the activity may start at any time between these values.

test networks but the algorithm is not exhaustive. The stages of the algorithm are noted below.

5.1. Stage 0 (0)

A resource constrained analysis was performed generating one schedule (e.g. schedule (A) in the example above) and the associated early start, latest start times and ¯oats. The selection of this initial schedule depends on the particular resource allocation heuristics employed. However, the complete analysis (stages 0±5) is independent of the choice of the allocation heuristics, as long as they are capable of identifying an optimal schedule. The results corresponding to this initial schedule j=0 were recorded for each activity i. ES(i, 0) early start for activity i in schedule j =0 LS(i, 0) latest start for activity i in schedule j =0 F1(i, 0) resource constrained ¯oat of activity (i ) in schedule j = 0.

5. Identifying alternative schedules

5.2. Stage 1

In the illustrative example of the software development it would have been quite practical to identify the practical permutations of the sharing of the resources R1 and R2 and hence, the four equivalent schedules by inspection. The preferred schedule could well have been chosen without recourse to the measures Float2 and Float3. However, as the network becomes more complex, the number of possible schedules tends to increase dramatically: more permutations of resource allocations are possible and there are more equivalent schedules. This results in two practical diculties: the identi®cation of the equivalent schedules is no longer trivial and the output describing the range of alternatives is likely to overwhelm the project planner. The measures of Float2 and Float3 were designed to provide a succinct summary of the areas of temporal ¯exibility, avoiding the need for the project planner to examine each equivalent schedule in detail. The identi®cation of equivalent schedules in more complex networks was achieved by adopting an algorithm based on perturbations of the original network. The algorithm was tested with a variety of resource constrained networks, ranging from 12 to 57 activities. It appeared successful in generating equivalent schedules for these

The resource constrained analysis was repeated with each activity i in turn subject to the constraint: LS…i, j†r LS…i, 0†: This constraint probed the boundary of the solution identi®ed in stage 0 potentially generating another n (the number of activities in the network) schedules. Many of these schedules were identical to that of stage 0 but some were distinct equivalent schedules o€ering the same project duration but with di€erent critical sequences.

5.3. Stage 2 More challenging constraints were introduced, testing the boundary of the solution further: LS…i, j†rLS…i, 0† ‡ 1 Again, another n schedules may be generated, but many of these were rejected since the overall project duration was increased. In order to schedule such an

J.A. Bowers / International Journal of Project Management 18 (2000) 385±392

activity at a later time, as implied by this constraint, some other activities must take place at an earlier time: often at times earlier than those suggested by the ES of stage 0. Thus, this perturbation can identify alternative schedules with both later LS and earlier ES. 5.4. Stage 3 The network was reversed such that an activity's predecessors became its successors, and a resource constrained analysis was performed as in stage 0. The reversal of the network was also employed in the de®nition of resource constrained ¯oat developed by Raz and Marshall [6]. The e€ect of analysing the network in reverse was to schedule the high priority activities as late as possible, while still minimising the project duration. This implies that other, lower priority activities were scheduled earlier, and hence, the analysis of the reversed network provided useful information about both the latest LS and earliest ES. Assuming e€ective resource allocation heuristics, the same project duration D should be achieved as in the previous stages. The early and late times produced by this analysis of the reversed network (LF ', EF ') were related to early and latest times for the original network (ES, EF):

391

The measures Float2, Float3, EES and LLS provide a summary of the temporal ¯exibility guiding the project planner to an improved schedule. Having determined the areas of ¯exibility of potential value, the project planner then examines just the particular equivalent schedules of interest. 6. Practical application

LS ˆ D ÿ EF 0

The success of the algorithm in identifying equivalent networks allows the concepts of the equivalent networks and the various measures of ¯oat to be applied to any network, however, large or complex. The procedures for determining the equivalent schedules and the measures of ¯oat were encoded in a Pascal program: a development of a standard activity-on-node resource constrained network scheduling routine. This program can then be provided as an add-on tool as part of a conventional project network analysis package. Although the measures of ¯oat have been designed to enhance understanding about projects' ¯exibilities, the program has so far only been implemented as part of a specialised piece of analysis with expert support; the full interpretation of the output demands considerable insight. Converting such a specialised procedure into a practical, common tool accessible to any project planner would require the design of an interface which guides the user to a better plan, without overwhelming with excessive data.

5.5. Stage 4

7. Conclusions

The constraints of stage 1 were introduced to the reversed network.

The de®nition of ¯oat can be extended to capture the ¯exibility inherent in many resource constrained projects. This involves identifying the various alternative schedules which deliver the same project duration, but o€er di€erent critical sequences of activities. In a small network, it is possible to identify and explore these alternatives by a simple inspection but in larger networks this is impractical. An algorithm incorporating perturbations of the network can generate these schedules in a systematic manner providing a basis for new measures for each activity:

ES ˆ D ÿ LF 0

5.6. Stage 5 The constraints of stage 2 were introduced to the reversed network. 5.7. Deducing Float2, Float3, EES and LLS Having identi®ed the equivalent schedules j, the ES, LS and ¯oats of the activities were compared:  EES…i † ˆ minimum ES…i, j†  LLS…i † ˆ maximum ES…i, j†  Float2…i † ˆ maximum F1 …i, j† Float3…i † ˆ LLS…i † ÿ EES…i †

Float2=the maximum ¯oat possible EES=the earliest, early start date LLS=the latest, latest start date Float3=the spread of possible dates LLS±EES These measures can guide the project planner to areas of useful ¯exibility helping to identify an alternative schedule in which problematic activities have greater ¯oat or start at a more convenient time. Thus, the potential impact of some activities' uncertainties may be reduced at no additional expense.

392

J.A. Bowers / International Journal of Project Management 18 (2000) 385±392

References [1] Willis RJ. Critical path analysis and resource constrained scheduling Ð theory and practice. Eur J Opl Res 1985;23:149±55. [2] Ragsdale C. The current state of network simulation in project theory and practice. Omega 1989;17:21±5. [3] Weist JD. Some properties of schedules for large projects with limited resources. Opns Res 1964;12:395±418. [4] Woodworth BM, Shanahan S. Identifying the critical sequence in a resource constrained project. Int J Proj Man 1988;6:89±96. [5] Bowers JA. Criticality in resource constrained networks. J Opl Res Soc 1995;46:80±91. [6] Raz T, Marshall B. E€ect of resource constraints on ¯oat calculations in project networks. Int J Proj Man 1996;14:241±8.

John Bowers worked for several years in the Operational Reaserch Executive of British Coal before joining BaeSema as a consultant specialising in project risk management. He was involved in developing risk assessment methodologies and their application in a number of major projects. He is now at the University of Stiring where he is invertigating new approaches to modelling projects.