identifying critical activities in stochastic resource constrained networks

10
~ Pergamon Omega, Int. J. Mgmt Sci. Vol. 24, No. 1, pp. 37---46, 1996 Copyright © 1996 Elsevier Science Ltd 0305-0483(95)00046-1 Printed in Great Britain. All rights reserved 0305-0483/96 $15.00 + 0.00 Identifying Critical Activities in Stochastic Resource Constrained Networks J BOWERS University of Stirling, Stirling, UK (Received April 1995; accepted after revision September 1995) The analysis of the stochastic project network can provide indications of both the magnitude of temporal risk and the sources of that risk. In a project dominated by technological dependencies rather than resource constraints, the sources of risk can he identified by examining the probabilities of each activity lying on a critical path. Similar criticality probabilities can also be derived for resource constrained stochastic networks if the definition of the critical path is revised. The use of this revised criticality probability is illustrated in an analysis of an example project and other possible measures of identifying the important activities are considered. A quantitative test of the value of the information provided by the criticality probability is developed and applied to a set of 100 randomly generated project networks, comparing the possible measures. This test indicates that the criticality probability provides valuable management information, extending the familiar concept of the critical path to the resource constrained stochastic network. Key words--project management, resource management, risk, simulation, control INTRODUCTION RISK MANAGEMENT is now regarded as central to the management of major projects [11]. Definite milestones and budgets are still needed for routine management control but the existence of risk is no longer denied. Various techniques [13] have been developed to help manage project risk but one common tool is the stochastic project network. The analysis of the unconstrained stochastic network has been the subject of many studies [1] with the emphasis on analytical solutions and methods for increasing the computational efficiency of Monte Carlo ap- proaches. However, the increased availability of greater computing power has encouraged the use of simple Monte Carlo simulation rather than an analytic approach. A simulation facility is now provided in several commercial project management software packages [9]. Such risk analyses serve a number of roles but they always attempt to answer two basic questions: how risky is the project and what can we do to improve our chances of success? The risk analyses provide the distribution of the project completion date indicating the probability of meeting temporal objectives. However, ad- ditional output is needed to help management reduce the project risk: a measure is required to identify the activities contributing most to both the project's duration and risk to determine the priorities for management action. One approach is to extend the conventional concept of the critical path to the stochastic network, using the probability of a given activity lying on a critical path. Some project management software includes estimates of the criticality probabilities based on simple Monte Carlo simulations. More efficient methods of estimating the criticality probabilities have been examined [7, 8] and an algorithm has been developed [10] to determine the 'most critical path'. This is defined as the path such that the OME24~1--D 37

Upload: j-bowers

Post on 30-Aug-2016

213 views

Category:

Documents


0 download

TRANSCRIPT

~ Pergamon Omega, Int. J. Mgmt Sci. Vol. 24, No. 1, pp. 37---46, 1996 Copyright © 1996 Elsevier Science Ltd

0305-0483(95)00046-1 Printed in Great Britain. All rights reserved 0305-0483/96 $15.00 + 0.00

Identifying Critical Activities in Stochastic Resource Constrained Networks

J B O W E R S

University of Stirling, Stirling, UK

(Received April 1995; accepted after revision September 1995)

The analysis of the stochastic project network can provide indications of both the magnitude of temporal risk and the sources of that risk. In a project dominated by technological dependencies rather than resource constraints, the sources of risk can he identified by examining the probabilities of each activity lying on a critical path. Similar criticality probabilities can also be derived for resource constrained stochastic networks if the definition of the critical path is revised. The use of this revised criticality probability is illustrated in an analysis of an example project and other possible measures of identifying the important activities are considered. A quantitative test of the value of the information provided by the criticality probability is developed and applied to a set of 100 randomly generated project networks, comparing the possible measures. This test indicates that the criticality probability provides valuable management information, extending the familiar concept of the critical path to the resource constrained stochastic network.

Key words--project management, resource management, risk, simulation, control

INTRODUCTION

RISK MANAGEMENT is n o w regarded as central to the management of major projects [11]. Definite milestones and budgets are still needed for routine management control but the existence of risk is no longer denied. Various techniques [13] have been developed to help manage project risk but one common tool is the stochastic project network. The analysis of the unconstrained stochastic network has been the subject of many studies [1] with the emphasis on analytical solutions and methods for increasing the computational efficiency of Monte Carlo ap- proaches. However, the increased availability of greater computing power has encouraged the use of simple Monte Carlo simulation rather than an analytic approach. A simulation facility is now provided in several commercial project management software packages [9]. Such risk analyses serve a number of roles but they always attempt to answer two basic questions: how

risky is the project and what can we do to improve our chances of success? The risk analyses provide the distribution of the project completion date indicating the probability of meeting temporal objectives. However, ad- ditional output is needed to help management reduce the project risk: a measure is required to identify the activities contributing most to both the project's duration and risk to determine the priorities for management action.

One approach is to extend the conventional concept of the critical path to the stochastic network, using the probability of a given activity lying on a critical path. Some project management software includes estimates of the criticality probabilities based on simple Monte Carlo simulations. More efficient methods of estimating the criticality probabilities have been examined [7, 8] and an algorithm has been developed [10] to determine the 'most critical path'. This is defined as the path such that the

OME 24~1--D 37

38 Bowers--Stochastic Project Networks

probability of completing its activities by a given time is less than the probability for every other path. None of these approaches is applicable when resource constraints are intro- duced. However, developments [3, 16] in measures of criticality in deterministic networks offer the opportunity for extending the concept of criticality probability to the resource constrained network. This paper discusses a revised method for determining criticality probability and compares the value of the measure with an alternative examined by Williams [15]: the correlation between an activity's duration and the project completion.

As in the large majority of studies of project risk, this paper just considers temporal risk. While time is a critical dimension of project success, in practice the manager has to address the additional, interdependent of cost, scope and quality [11].

CRITICALITY IN DETERMINISTIC RESOURCE CONSTRAINED NETWORKS

The need for a practical measure of criticality in deterministic resource constrained networks has been noted before. Wiest [12] suggested an amended definition of the critical path: the critical sequence of activities. This sequence reflects both the traditional technological dependencies, as depicted explicitly in the project network, and the dependencies implied by the sharing of scarce resources. This concept was first implemented by Woodworth and Shanahan [16] while Bowers [3] described a more succinct algorithm and examined the attributes of the measure, comparing it to other possible measures of criticality.

Resource constrained criticality can be determined by explicitly including the links implied by the sharing of resources. A conventional resource constrained analysis of the network is undertaken first. In addition to the usual information describing the start and end dates of activities, the flows of the resources between activities are also noted. These flows are then incorporated as explicit precedence links, using an activity-on-node representation. A further pair of forward and reverse passes of the network is performed, but now with these new links reflecting the resource constraints, and the floats of each activity may be noted in the usual manner. One concern with this

definition of resource constrained float is that it uses the history of the flows of the resources between activities and hence the resultant floats are peculiar to the particular resource allocation employed. However, studies [3] suggest that the resource constrained float is a reasonably robust measure and should provide a useful basis for identifying the critical activities in stochastic project networks.

CRITICALITY IN STOCHASTIC NETWORKS

Criticality probabilities

The extension of the concept of resource constrained criticality to the stochastic network is superficially simple. A Monte Carlo frame- work is employed with each iteration providing a set of sampled activities' durations for input to the above resource constrained criticality algorithm to identify resource constrained critical activities. The process is repeated in classic Monte Carlo fashion to estimate the criticality probabilities of all the activities. However, this simple embedding within a Monte Carlo framework implies a model of the project manager as a director of resources with perfect information. The simulation model involves sampling all the activities' durations at the start of each iteration and hence a complete set of information is available permitting an optimal allocation of resources. In practice there would be many unresolved uncertainties with the durations of some activities remaining unknown until close to their completion. However, it appears [3] that this assumption of perfect knowledge is a reasonable approxi- mation and that the use of a simple Monte Carlo framework can be justified.

An alternative measure: cruciality

An alternative method of identifying the most important activities in a stochastic network uses the correlation of an activity's duration with the project's duration; Williams describes this as the 'cruciality' of an activity [15]. Cruciality is a concept readily applicable to resource con- strained projects and offers useful guidance to those activities contributing to the variability in the project duration. However, it can be quite distinct to that of the criticality probability metric. Williams [15] discusses the differences

Omega, Vol. 24, No. 1

Fig. 1. A s o f t w a r e d e v e l o p m e n t project .

~ l ~ system [ int~lmlio¢~ te~

39

between the two measures in the analysis of a non-resource constrained project: the criticality probability reflects the marginal change in the expected project duration resulting from a small variation in an activity's duration while the cruciality measure refers only to the effect of an activity's uncertainty on the project duration. The distinction may be highlighted by consider- ing an activity with zero uncertainty that always lies on the critical path; its criticality probability would be 1.000 but its correlation and cruciality would be zero. Whether such an activity should be deemed important depends on the possibili- ties for management action. Management may have some control over uncertainties, e.g. by implementing special reporting procedures or including substantial incentive payments in a sub-contract. Where there is such potential control over the uncertainties, cruciality can provide an adequate measure of an activity's importance. However, if management believe that the expected duration of the activity might be reduced, even if its uncertainty is less easily controlled, then the criticality probability should be a more relevant measure of import- ance.

APPLICATION IN A SOFTWARE DEVELOPMENT PROJECT

The value of the criticality probabilities as management information is demonstrated in the analysis of the simplified network of Fig. 1 describing a software development project. The network is based on the high level plans of some actual projects but the particular values of durations and resources have been selected especially in order to illustrate aspects of the criticality probability measure. Table t includes the estimated duration in months (dur), the uncertainty level (unc) and the requirements for two key resources for each activity (res 1, res 2); two units of resource 1 and just one unit of resource 2 were available. A deterministic resource constrained analysis of the software project, assuming the estimated durations, produced the set of resource constrained early and late starts and finishes (ES, EF, LS, LF) and hence the resource constrained floats (float). This analysis suggests that the only non-critical activities, in the resource constrained sense, are the design and coding of the analyser and database.

Table 1. Analyses of the software development project

Activity dur unc res 1 res 2 ES EF LS LF Float crit cruc

Requirements spec 10 0 2 0 0 10 0 10 0 1.000 0.000 System design 10 0 2 0 l0 20 10 20 0 1.000 0.000 I/O design 8 2 l 0 20 30 20 30 0 0.226 0.07 l Analyser design 10 1 1 0 20 31 24 35 4 0.476 0.149 Database design 10 2 I 0 30 41 40 51 10 0.336 0.077 I/O code 13 3 0 0 30 46 30 46 0 0.218 0.215 Analyser code 15 2 0 0 31 49 35 53 4 0.476 0.12 I Database code 12 3 0 0 41 53 51 63 10 0.336 0.256 I/O test 5 4 0 1 46 53 46 53 0 0.996 0.392 Analyser test 8 3 0 1 53 63 53 63 0 1.000 0.435 Database test 6 3 0 1 63 71 63 71 0 0.996 0.373 Integration 3 5 2 1 71 75 71 75 0 1.000 0.374 System test 2 4 2 1 75 78 75 78 0 1.000 0.113

40 Bowers--Stochastic Project Networks

Table 2. Definition of uncertainty levels as percentages of estimated duration

Uncertainty level Optimistic Most likely Pessimistic SD

0 100 100 100 0.0 I 100 100 120 4.7 2 100 100 150 11.8 3 100 100 180 18.9 4 100 100 210 25.9 5 100 100 250 35.4

Uncertainty levels

The uncertainties in the activities' durations were described by triangular distributions, as in many project risk analyses [14]. An 'uncertainty leVel' was used to specify the appropriate parameters of the distribution, as in other similar analyses [2]. The uncertainty levels provide an unambiguous language for the discussion of activities' uncertainties and ex- pedite the combining of quantitative and qualitative information that is characteristic of many risk assessments. The uncertainty level defines the optimistic, most likely and pessi- mistic values for each activity, expressed as proportions of the estimated duration. This assumes that the estimated duration can be interpreted as the most likely value, a common though not inevitable assumption [14]. The definition of the uncertainty levels is noted in Table 2 together with their implied standard deviations expressed as a proportion of the estimated duration. In general:

tr - (b2 + bc + c ~') (1) 18

where: optimistic = A - b; most likely = A; pessimistic = A + c.

Using the criticality probabilities to determine priorities

A Monte Carlo simulation of 500 iterations was performed to determine the effect on the project and date of the component uncertain- ties. Previous experiments with a range of networks have indicated that 500 iterations are usually sufficient to ensure a robust output. Similarly with this network: there was little change in any of the activities' criticality probabilities or crucialities as the number of iterations was increased from 200 to 500. The resource constrained criticality probabilities (crit) are included in Table 1. These criticality probabilities were used to draw up the list of priorities for management action in Table 3: a similar concept to the criticality list discussed by Dodin and Elmaghraby [7]. Many of the high priorities suggested by this list are readily explained as reflections of a combination of large uncertainty and conventional determinis- tic criticality or a demand for scarce resources. For example, the 'system test' has a large uncertainty combined with a conventional deterministic float of zero and a requirement for two units of resource 1. The criticality probability combines several aspects of an activity's character within a single measure. The criticality probability also has the merit of being a natural extension of the conventional notion

Table 3. Using criticality probabilities to identify activities warranting reduction in duration

Activity

Original Revised

Criticality Estimated Uncertainty Assistance Estimated Uncertainty probability duration class required duration class

System test 1.000 2 4 0.018 1 4 Integration 1.000 3 5 0.045 2 5 Analyser test 1.000 8 3 0.116 5 3 Requirements spec 1.000 l0 0 0.205 6 0 System design 1.000 l0 0 0.295 6 0 I/O test 0.996 5 4 0.339 5 4 Database test 0.996 6 3 0.393 6 3 Analyser design 0.476 l0 l 0.482 l0 1 Analyser code 0.476 15 2 0.616 15 2 Database design 0.336 10 2 0.705 10 2 Database code 0.336 12 3 0.813 12 3 I/O design 0.226 8 2 0.884 8 2 I/O code 0.218 13 3 1.000 13 3

Omega, Vol. 24, No. I

Table 4. Using "cruciality" to identify actvities warranting reduction in duration

41

Activity

Original Revised

Criticality Estimated Uncertainty Assistance Estimated Uncertainty probability duration class required duration class

I/O test 0.392 Integration 0.374 Database test 0.373 Database code 0.256 I/O code 0.215 Analyser design 0.149 Analyser code 0.121 System test 0.113 Database design 0.077 I/O design 0.071 Requirements spec 0.000 System design 0.000

5 4 0.116 3 4 3 5 0.143 2 5 6 3 0.196 4 3

12 3 0.304 7 3 13 3 0.420 13 3 10 1 0.509 10 1 15 2 0.643 15 2 2 4 0.661 2 4

10 2 0.750 10 2 8 2 0.821 8 2

10 0 0.911 10 0 10 0 1.000 10 0

of the critical path familiar to all management. Experience suggests that management are initially uncomfortable with cruciality as a single measure of importance since it suggests that the old critical activities can be forgotten; the criticality probability overcomes this reser- vation.

Using activities' crucialities to determine priorities

A similar list of priorities can be constructed using the activities' crucialities, as in Table 4. Again cruciality seems to combine many aspects of a given activity in a single measure. However, while there are many similarities between cruciality and criticality probability, there are some important differences between the two priority lists, most notably the inclusion of 'requirements specification' and 'system design' as high ranking activities in Table 3 while they appear at the bottom of the priority list of Table 4. Both of these activities have zero uncertainty and hence a zero correlation and cruciality. However, both activities always lie on the critical path and hence have criticality probabilities of 1.000. This difference in the treatment of critical activities with zero uncer- tainties, as noted by Williams [15], appears to be the main cause of the variations between the two measures. Many of the activities exhibit a poor agreement between the measures: the correlation between the activities' criticality probabilities and crucialities is just 0.117.

When assessing activities' variabilities it can be important to distinguish between the uncontrollable and controllable. In the software development example, a subcontract has been let for the requirements specification and systems design work. The subcontractor is large

and very experienced in this type of work and has agreed, after considerable initial studies, to a fixed duration contract. If any problems arise, the subcontractor has enough skilled staff and finance, to divert additional resources to ensure the completion of the activities. It is reasonable that the management have interpreted this as implying that the activities have zero uncer- tainty since there is no uncontrollable element to the activities' variabilities about their durations. However, the activities might have a large controllable variability: it may be possible to agree a revised contract reducing the activities' durations, though no doubt at a greater cost. The ideal list of priorities should help management identify such activities as candidates for action in striving to produce a better project plan.

A TEST OF THE VALUE OF STOCHASTIC CRITICALITY

Modelling the planning process

If the criticality probability is a reliable piece of management information it should help management determine their priorities when revising the project plan in their efforts to reduce risk. A quantitative assessment of the value of the criticality probability was devel- oped based on a simple model of this stage of the planning process. The test is first described within the context of the example of the software development project and later general- ized. An initial stochastic analysis of the software project was performed to provide the basis for a priority list identifying those activities most worthy of any additional resources that management might provide. These additional resources could be money,

42 Bowers--Stochastic Project Networks

staff or just the attention of senior personnel during the project's implementation. In a first analysis it was assumed that deploying such additional resources to an activity could reduce its estimated duration by 40%; such additional assistance could have other beneficial effects, explored in the alternative planning model described later. Various degrees of additional assistance, ct, were explored: 0 ~< ~ ~< 1. ~ = 0 implies that no further assistance is available for any activity while ~ = 1 implies that senior management have recognized the importance of the project and secured plentiful additional resources allowing all activities to be assisted. The more practical case is when 0.1 < ~ < 0.6 and only selected, higher priority activities may receive the assistance.

The activities were ordered using a chosen measure of priority, such as the criticality probability. The first m activities were selected with m being maximized while respecting the condition:

d~ <~ ~ ~ d, (2) i = 1 J = l

where the project consists of a set of n activities with durations di and priorities p,, i = 1,2 . . . . ,n such that p~+~ ~<p~. This allocation procedure assumes that the quantity of additional assistance required for each selected activity is proportional to its duration: a simple model of the notion that a big activity will require more assistance than a smaller one.

Exploring the effects of management's actions

Having identified the m activities, their durations were reduced by 40% and a further stochastic analysis was performed to examine the effect of the changes. A set of experiments was undertaken, repeating this analysis, explor- ing two factors:

factor A the different measures of import- ance (the criticality probability, cruciality and randomized priority) to order the activities in a priority list;

factor B the amount of additional assistance available 0 ~< ~ ~< 1.

The randomized priority was used as a basis for comparison, representing a decision maker

with no useful information about the relative importance of any of the activities. While such a situation is unrealistic, any real project manager would have some information and experience to help prioritize activities, the use of a randomized priority provides a rigorous base case. A new set of random priorities was generated for each of the 500 iterations of the simulation.

Table 3 illustrates a particular experiment: the criticality probabilities were used to determine priorities (factor A) and ~ is 0.3 (factor B). There is sufficient additional assistance to supply the first five activities since the sum of their estimated durations is 33 or 0.295 of the total of all the activities' durations. The revised estimated durations are noted, together with the unchanged uncertainty levels, provided the input for a revised stochastic analysis. The revised analysis suggested a mean project duration of 63.4 months, compared to an original mean of 78.4 when no additional assistance was employed. Similar experiments were performed examining the range of values of ~, and the results are noted in the graph of Fig. 2.

Comparing the value of criticality probability and cruciality

Alternative measures of importance were employed in the selection process, resulting in different priority lists and hence different activities having their durations reduced. Table 4 depicts the priorities for a single experiment (~ = 0.3) using cruciality to deter- mine priorities. The priority list is quite different to that of Table 3 and a different set of 5

8O

o ~ 7o

65

6o

~: ss

5O

45 ; ; : : : : : : : = : 0 .00 0 .20 0 .40 0 .60 0 .80 1 .00

add i t i ona l assistance

- = - r a n d o m .,,,-crit p rob - ~ c r u c i a l i t y

Fig. 2. Controlling activities' durations.

Omega, Vol. 24, No. 1 43

activities are identified for action. Figure 2 records the results of using cruciality and a randomized priority as the basis for selection. The graph just displays the effects on the mean duration of the project but a similar pattern is observed in the 90 percentile duration and standard deviation. Figure 2 indicates that the criticality probability offers substantial reductions in the mean project duration suggesting that it is a better basis for deciding priorities than the cruciality or a random selection. The cruciality measure performs worse than the random in some circumstances, but such results are not unexpected in this particular network. Cruciality measures the relationship between the variability of an activity and that of the whole project but does not necessarily reflect the dependence of the project duration on the activity's duration, as in the case of the zero uncertainty but critical activity. In the software project, the cruciality measure fails to identify 'requirements specifi- cation' and 'system design' as worthy of management attention, even though any re- duction in their durations will inevitably reduce the project duration. At least the random selection occasionally selects these activities as warranting a share of the additional assistance. The results of these experiments, with this one project, suggest that the criticality probability is the better method of deciding management's priorities.

An alternative planning model

While additional assistance may have the effect of reducing activities' estimated durations, it has also been suggested [15] that the uncertainties might be reduced instead. An alternative planning model was explored follow- ing the same basic procedure: a priority list of the activities was constructed but the selected activities had their uncertainty levels reduced by 3 rather than their estimated durations reduced. As with the first planning model, various degrees of additional assistance were explored: 0 ~< ~ ~< 1 and where only a limited number of activities might be assisted, the first m were chosen with the highest priority. In this case m was maximized while respecting the condition:

min(u,,3)di <~ o~ ~ min(ui,3)di (3) i = l i = l

78 . . . . . . . . . . . . . . . . . . .

~76 . . . . . . . . . . . . .

72 t . . . . . . . . . . . . . 1

0.00 0.20 0.40 0.60 0.80 1.00 additional assistance

-,,-random -*-crit prob -o-cruciality

Fig. 3. Controlling activities' uncertainties.

where ui is the uncertainty level of activity i. It is assumed that the additional assistance required to achieve such a reduction is proportional to the duration of the activity and also to the amount of reduction in the uncertainty level. Some activities may have an initial uncertainty level below 3 and can only be reduced to a level of zero. Thus the assistance required for a chosen activity is proportional to min(u,,3)d~.

The experiments exploring the effects of the different measures of importance and the values of ~ were repeated with this alternative planning model and the results noted in Fig. 3. The reduction in the mean project duration for all practical values of ~ compared to the random base case, suggests that both the criticality probability and the cruciality measure offer useful information.

Extending the test to a set of randomly generated projects

While the software development network may be a reasonably typical small network, it was carefully chosen in order to illustrate particular features of criticality probability and cruciality. A more rigorous test of the value of the criticality probability was undertaken by repeat- ing the analyses for 100 randomly generated networks. The main requirement in this examination of criticality probability was for networks at least superficially resembling those found in practice rather than an unbiased sample representative of the set of all theoreti- cally feasible networks. Thus a 'weakly' randomized network generator was employed rather than the strongly randomized network described by Demeulemeester et al. [6]. Statistics

44 Bowers--Stochastic Project Networks

Table 5. Statistics of the 100 randomly generated networks

Mean SD Minimum Maximum

Nodes (activities) 48.86 18.10 20 107 Arcs/nodes 1.45 0.10 1.15 1.83 Strength 1.00 0.38 0.29 2.16 Constrained/unconstrained duration 1.63 0.39 1.00 2.97 Stochastic/deterministic duration 1.18 0.05 1.06 1.31

of the 100 networks generated are summarized in Table 5. The importance of the resource constraints in a network is indicated by two measures:

Strength, summarizing the relative demand and availability of the resources, as described by Davis and Patterson [5]. Strength may be defined as:

R strength = DB (4)

where

nr

R = ~ dirij i = 1 j = ]

nr

B = ~ ' r j j=l

D = unconstrained project duration rj = available units of resource j r~ = requirement for resource j by activity i n = number of activities n, = number of resources

Constrained~unconstrained, the ratio of the resource constrained: unconstrained project durations.

Other analyses [4, 5] using randomly gener- ated networks have limited networks' strengths to between 0.5 and 1.5 and a similar range was respected in this study. The uncertainties of the activities in each of the networks were also randomly generated; as a measure of the uncertainty of each generated network, the ratio of the mean stochastic deterministic project duration was noted.

Each randomly generated network was analysed in a similar manner to that employed

in the examination of the software development project but assuming a single figure for the amount of additional assistance with ct = 0.3. The results of each network's analysis were expressed as a percentage of the duration assuming the use of the random priority list to permit the comparison of the 100 projects. Table 6 summarizes the statistics of the 100 project analyses, assuming that it is the activities' durations that are the subject of control rather than their uncertainties. The table also includes the corresponding figures for the software development project for comparison. The mean of 88.0% suggests that the criticality probability typically offers a 12.0% reduction in project duration compared to a random choice of priorities. The cruciality measure performs very similarly. If it is assumed that it is the uncertainties of the activities which will be the main beneficiaries of the additional assistance, the results of Table 7 are obtained. In this case both measures again performed better than a random metric, with a 4.5% improvement when using the criticality probability to determine priorities. Under either assumption the critical- ity probability and cruciality appear to be useful measures for directing management's efforts.

The influence of a network's characteristics

While the aggregated results summarized in Tables 6 and 7 suggest that there is little to choose between the two measures, closer examination of the individual results of the analyses of the 100 synthesized networks reveals a variation in the performances of the two measures. The relative performance of the criticality probability and cruciality as measures of importance may be summarized as the ratio

Table 6. The 100 network experiment: controlling durations

Random Criticality probability Cruciality

Software project 100.0 92.6 96.0 Mean (100 projects) 100.0 88.0 88.8 SD 0.0 3.5 3.4 Minimum 100.0 77.6 79.0 Maximum 100.0 97.1 98.2

Omega, Vol. 24, No. 1

Table 7. The 100 network experiment: controlling uncertainties

Random Criticality probability Cruciality

Software project 100.0 96.0 97.0 Mean (100 projects) 100.0 95.5 94.7 SD 0.0 1.7 1.5 Minimum 100.0 90.4 90.7 Maximum 100.0 100.0 100.0

45

of the mean project durations for each synthesized network:

xi = mean duration of network i using criticality probabilities to determine priorities;

y i = mean duration of network i using activities' crucialities to determine pri- orities;

rl = x / y i , the performance ratio comparing the two measures for network i.

In the case of the control of the activities' durations, this performance ratio had a mean value of 0.99 and a standard deviation of 0.04, based on the analyses of the 100 randomly generated networks. When the activities' uncer- tainties were the subject of control, the mean performance ratio was 1.01 with a standard deviation of 0.01. In general there is little to choose between the two measures. The possi- bility of a systematic variation in the perform- ance of the two measures was also explored. It had been expected that a network's character- istics would influence the relative performance. For example, it had been proposed that the criticality probability should be a more reliable measure in highly resource constrained projects. However, the correlation coefficients of Table 8 suggest that there is no simple association between the performance ratio and the various network parameters describing size, complexity and the strength of the resource constraints. The table records p { r , v j } where v0 = j th parameter of network i, e.g. vH is the number of nodes in the first generated network. Examination of scatter plots confirmed the lack of any simple, significant relationship between the perform- ance ratio and the network parameters.

CONCLUSIONS

The criticality probability, using the revised definition of criticality to include the effects of resources, provides useful guidance to the important activities in a stochastic resource constrained network. However, another simple measure can also supply such guidance: the correlation of an activity's duration with that of the complete project, dubbed an activity's 'cruciality'. Examination of a typical network and a more extensive assessment based on analyses of 100 randomly generated networks suggest that both measures provide a useful basis for the allocation of management's priorities. Cruciality offers an easily calculated and, in most circumstances, very successful measure of an activity's importance. However, the cruciality measure cannot identify the critical activity with zero uncertainty. It can be argued that if such an activity truly has zero uncertainty it has no need of any special management attention. However, such omis- sions can reduce management confidence in the output from the stochastic analyses and also preclude the possible existence of some con- trolled variability as well as uncertainty. Where there is controlled variability management may have the scope to take special action and reduce the activity's duration in a controlled manner, even though uncertainty remains at zero.

The criticality probability identifies all critical activities, even those with zero uncertainty. It provides a more reliable measure, relevant where there is genuine uncertainty or control- lable variability. The criticality probability offers a natural extension from the deterministic definition of criticality, applicable both to networks with very few, or even zero, uncertain- ties and to those with considerable uncertain- ties. The only significant disadvantage of the

Table 8. Correlations of the relative performance with key network parameters

Nodes Arcs/nodes Strength Constrained/unconstrained

Performance ratio when controlling uncertainties -0.017 -0.025 -0.009 -0.081 Performance ratio when controlling durations -0.059 -0.168 -0.087 -0.056

46 Bowers--Stochastic Project Networks

criticality probability is the need for the more sophisticated network analysis routine.

R E F E R E N C E S

1. Adlakha VG and Kulkarni VG (1989) A classified bibliography of research on stochastic PERT networks: 1966-1987. INFOR 27, 272-296.

2. Bowers JA (1994) Data for project risk analyses. Int. J. Proj. Mgmt 12, 9-16.

3. Bowers JA (1995) Criticality in resource constrained network. J. Opl Res. Soc. 46, 80-91.

4. Christofides N, Alvarez-Valdes R and Tamarit JM (1987) Project scheduling with resource constraints: a branch and bound approach. Eur. J. Opl Res. 29, 262-273.

5. Davis EW and Patterson JH (1975) A comparison of heuristics and optimum solution in resource-con- strained project scheduling. Mgmt Sci. 21, 944-955.

6. Demeulemeester E, Dodin B and Herroelen W (1993) A random activity network generator. Opns Res. 41, 972-980.

7. Dodin BM and Elmaghraby SE (1985) Approximating the criticality indices of activities in PERT networks. Mgmt Sci. 31, 207-223.

8. Fishman GS (1985) Estimating critical path and arc probabilities in stochastic activity networks. Naval Res. Logist. Q. 32, 249-261.

9. Simister SJ (1994) Usage and benefits of project risk analysis and management. Int. J. Proj. Mgmt 12, 5-8.

10. Soroush HM (1994) The most critical path in a PERT network. J. Opl Res. Soc. 45, 287-300.

11. Turner JR (1993) The Handbook of Project-Based Management. McGraw-Hill, London.

12. Weist JD (1964) Some properties of schedules for large projects with limited resources. Opns Res. 12, 395-418.

13. Wideman RM (1992) Project and Program Risk Management. Project Management Institute, U.S.A.

14. Williams TM (1992) Practical use of distributions in network analysis. J. Opl Res. Soc. 43, 265-270.

15. Williams TM (1992) Criticality in stochastic networks. J. Opl Res. Soc. 43, 353-357.

16. Woodworth BM and Shanahan S (1988) Identifying the critical sequence in a resource constrained project. Int. J. Proj. Mgmt 6, No. 2, 89-96.

ADDRESS FOR CORRESPONDENCE: Mr John Bowers, Depart- ment of Management and Organization, School of Management, University of Stifling, Stifling FK9 4LA, UK.