Scenario Analysis
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Scenario Analysis as PDF for free.
More details
- Words: 6,830
- Pages: 13
PROJECT PLANNING UNDER UNCERTAINTY USING SCENARIO ANALYSIS BRUCE POLLACK-JOHNSON, Department of Mathematical Sciences Villanova University, Villanova, PA MATTHEW J. LIBERATORE*, Department of Decision and Information Technologies Villanova University, Villanova, PA
ABSTRACT An important component of risk management relates to project schedule uncertainty. To address this issue, a scenario (i.e., macro-level approach) for modeling and analyzing projects with significant uncertainty in their network structure and/or durations of some activities is presented. This approach requires that a set of project network scenarios is able to be identified, each with an assessed probability of occurrence. These scenarios might differ according to the results of uncertain events that could occur during the course of the project, uncertain activity durations (whether independent or dependent), finite loops where repeated activities can have different durations, or a combination of these. Advantages of our approach include the use of standard methods and software, as well as greater accessibility to, and likelihood of, the use of uncertainty analysis in project planning. Several examples are used to illustrate the suggested approach. Keywords: Project scheduling; risk management; project network analysis ©2005 by the Project Management Institute Vol. 36, No. 1, 15-26, ISSN 8756-9728/03
Background isk management is one of the nine Knowledge Areas within the Project Management Institute’s A Guide to the Project Management Body of Knowledge (PMBOK® Guide) (Project Management Institute [PMI], 2000). An important component of risk management relates to project schedule uncertainty. Traditionally, project schedule uncertainty has been addressed by considering the uncertainty related to activity duration. The most wellknown technique is Program Evaluation and Review Technique (PERT), developed by the U.S. federal government in the late 1950s (Malcolm, Rosenboom, Clark, & Fazar, 1959). PERT models uncertain activity durations by collecting optimistic, most likely, and pessimistic duration estimates of all activities. Although PERT is sometimes used to estimate the expected length of the critical path, Monte Carlo simulation is more commonly used to estimate the criticality of different activities and paths, as well as the probability distribution of the project duration. The importance of addressing uncertainty related to activity duration can be seen by considering the results of surveys regarding available project management software and practitioner use of project network analysis methods. For example, a 1999 software survey by the Project Management Institute showed that about 20% of project management software packages had Monte Carlo simulation capability (PMI, 1999). Also, a more recent survey of project management professionals (Pollack-Johnson & Liberatore, 2003) found that nearly 70% of the respondents used critical path analysis, and 17% used probabilistic analysis and/or simulation within project management software. However, project management professionals responding to this survey also reported a need for research on how to better address uncertain network structures (Pollack-Johnson & Liberatore, 2003). Uncertain project network structures can arise in a variety of ways. For example, in a new product or process development project, it may be uncertain whether quality requirements will lead to one or more re-work cycles. In a new technology-implementation project, it may be uncertain whether formal staff training activities are required. In a research project, depending upon the results obtained in the first stage, different sequences of activities may follow. In a pharmaceutical development project, additional testing may be
R
*corresponding author March 2005 Project Management Journal • 15
required if certain pending legislation passes. Simulation packages such as the Graphical Evaluation and Review Technique, or GERT, (Pritsker & Happ, 1966; Wiest & Levy, 1977) were developed to model some probabilistic networks similar to the examples presented above. Even when GERT was produced and supported, however, it assumed that repeated activities within loops had identical duration distributions (i.e., the same average duration for each repetition) (Neumann, 1990). It also assumed independence of duration distributions (i.e., the time one activity takes does not influence the time another takes). The approach we propose in this paper can handle all of these situations. GERT is no longer produced and supported, but many of its capabilities are now available in related, general-purpose simulation software packages called Visual SLAM and AweSim (Pritsker & O’Reilly, 1999). These packages enable the user to develop GERT-type project simulation models, but are not specifically designed for project management as GERT was, can be difficult to use, and become even more challenging as the project network size and complexity increase. In addition, the simulation approach itself is micro-oriented, since it models the uncertainty at the activity level. There are situations where the uncertainty is related to different sequences or combinations of events occurring or not occurring, such as in the pharmaceutical pending legislation example, and, therefore, can be conceived as relating to different project scenarios rather than individual activities. For these reasons, a simpler approach is needed when there are important project network uncertainties that must be addressed as part of the project risk analysis and assessment process. Existing methods are especially inadequate for loops where repeated activities do not have identical duration distributions; for dependent duration distributions; and for obtaining detailed and summary (expected) early/late start/finish times,
16 • Project Management Journal March 2005
criticalities, and total slack (float) values for individual activities, as well as for common or aggregated activities across probabilistic branches or within loops. The purpose of this paper is to present a scenario, or macro-level approach, for modeling and analyzing projects with significant uncertainty in their network structure and/or the durations of some activities. This approach is applicable for project schedule risk analysis and contingency planning. An advantage of our approach is the use of standard methods, such as critical path analysis and probability analysis, and popular software packages, such as Microsoft Project® and Excel®, to solve projectplanning problems with uncertain network structures. The benefits of our approach are its ability to identify the same activities in different scenarios and summarize results for them overall, with modest data requirements, greater simplicity, and comprehensibility. This would lead to a greater likelihood of the use of uncertainty analysis, and some additional insights into the impact of uncertainty. First, we present our scenario approach. Next, some examples of uncertain networks are presented and analyzed using our approach. Conclusions and suggestions for future study follow. Project Networks and the Critical Path A traditional project network in Activity on Node (AoN) form is defined as a set of nodes representing activities that are connected by directed arcs to represent precedence relationships. If one activity must occur directly before a second activity, we say that the second activity is an immediate predecessor of the first. Cycles (loops) of activities within the project network are not allowed. We assume that there is only one activity without predecessors (possibly an artificially constructed dummy activity) and is called the start activity. We also assume that there is only one activity without successors (possibly a dummy), which is called the finish activity. If the original project network does not have unique start
or finish activities, we add dummy activities (with zero duration) for this purpose. The length of the longest (but not necessarily unique) path from the start activity to the finish activity is the minimum project completion time. Such a path is called a critical path, the activities along it are called critical path activities, and we will denote the length of the path as LCP. Let us define: j activity j aj = activity j Pj = set of all immediate predecessors of activity j ESj = earliest possible start time for activity j EFj = earliest possible finish time for activity j LSj = latest possible start time for activity j (that would not delay the project finish date) LFj = latest possible finish time for activity j (that would not delay the project finish date) TSj = total slack for activity j (the time it could be individually delayed without delaying the entire project) The critical path can be determined by performing forward and backward passes through the project network. The forward pass includes computing the earliest start (ES) and the earliest finish (EF) times for each activity, while the backward pass requires computing the latest start (LS) and latest finish (LF) times. Once both passes are completed, the total slack (TS) for each activity can be computed. The total slack of each activity is the difference between its ES and LS. Any path from the start activity to the finish activity consisting only of activities with a total slack of 0 is called a critical path. Any activity with a total slack of 0 is called a critical activity, since any delay in that activity alone will delay the whole project (the soonest it can be completed) by the same
amount of time. We say that a critical activity has a criticality of 1, and any other activity has a criticality of 0. The Scenario Approach In this paper, we focus on a scenario approach for analyzing uncertain project networks. The uncertain network structure is expressed through a set of network scenarios, each having a specified probability of occurrence. For example, if a finite loop is present, the problem cannot be represented directly using the standard project network described in the previous section. However, using a network scenario approach, a set of project networks without loops can be constructed and analyzed using conventional techniques. A similar approach can be used when considering probabilistic branching. In what follows, we initially assume that the activity durations are known with certainty, although the approach presented can be easily extended to the case of probabilistic durations, especially if only a limited number of activities have significant uncertainty in their durations. Let us define: i network scenario i N(i) = network scenario i p(i) = probability of network scenario i oj = probability that activity j will actually occur — d j = expected duration of activity j (considering its duration to be 0 if it does not occur) LCP(i) = critical path length for network scenario i — LCP = expected critical path length over all network scenarios The probability that each activity will occur is just the sum of the probabilities of all scenarios in which that activity occurs. The calculations of expected quantities are standard expected value calculations: the value in each scenario is multiplied by the probability of that scenario, and then all of the results are added together.
Let us also define: cj (i) = criticality of activity j in
network scenario i
=
1 if activity j is critical in network scenario (only if aj occurs) 0 if not (including if aj does not occur)
— c j = expected criticality of activity j over all network scenarios — = expected criticality of c j|occur
activity j, given that aj actually occurs The expected criticality is calculated in the same way as the expected value calculations described earlier. We will use the subscript “j|occur” notation to refer to conditional means (conditioned on activity j actually occurring) for other quantities as well. These are standard conditional expected values, and are calculated in a manner similar to the other expected value calculations (the sum of the values times the probabilities of their occurring), but only for the scenarios in which activity j occurs. This total is then divided by the probability that activity j occurs to get the conditional expected value or mean. We will use similar notation and calculations to define:
ditional, as above.) Some projects (see example 2) could be conceived of as involving finite loops, so we can use double subscript notation to indicate multiple iterations of the same activity, following the pattern below: aj,k = iteration k of activity j In such a case, we can define the following: — dj,k = average duration of aj,k (considering the duration to be 0 when it does not occur) — dj,• = average total duration of all iterations of activity j (again, considering the duration to be 0 when it does not occur)
— ES = average ES of the first of all j,•
iterations of activity j
— EF = average EF of the last of all j,•
iterations of activity j
— LS = average LS of the first of all j,•
iterations of activity j
— LF = average LF of the last of all j,•
iterations of activity j (Again, these could be made conditional if necessary.) The calculations are straightforward, consistent with the earlier discussion. Examples
— LF j = expected late finish time for activity j
1. Random Event Consider the project network given as Table 1. Suppose that this problem includes a random event, such as the result of pending legislation that could require an additional testing activity, a4. There are three possible scenarios: (Denoted as N(1))—no additional testing (legislation does not pass), with a probability of 0.5 (Denoted as N(2))—minimal additional testing, duration of 4, with a probability of 0.3 (Denoted as N(3))—significant additional testing, duration of 11, with a probability of 0.2 In scenarios 2 and 3, a4 has immediate predecessors of a2 and a3, and is an immediate predecessor of a6.
(If aj did not occur in some scenarios, we could also make these con-
We can represent this situation schematically with a modified version
— TS j|occur = expected total slack of activity j, given that aj actually occurs If activity j occurs in all scenarios, we can also similarly define and calculate: — ESj = expected early start time for activity j — EFj = expected early finish time for activity j — LSj = expected late start time for activity j
March 2005 Project Management Journal • 17
aj
Pj
dj
a0 a1 a2 a3 a5 a6 a7 a8
--{a 0} {a 1} {a 1} {a 2} {a 3} {a 5 ,a 6} {a 7}
0 7 8 6 12 9 5 0
Table 1: Random event network: base case
of an Activity on Node (AoN) network, where arrows represent precedence relations and dotted arrows indicate uncertain precedence relations (ones that exist in some scenarios, and not others), as shown in Figure 1. One way of depicting our approach is through the modified project network shown as Figure 2, where a circular node is a probabilistic branch. Using our notation defined in the previous section, as shown in Figure 2, the scenario probabilities are: p(1) = 0.5, p(2) = 0.3, and p(3) = 0.2. Note that activity 4 (a4) is the only activity that does not always occur: — d4 =(0.5)(0)+(0.3)(4)+(0.2)(11)=3.4
A critical path analysis of each of the three scenarios was performed using Microsoft Project 2002. After analyzing the base case, the remaining two scenarios were analyzed by modifying the base case (adding a4, and adjusting the predecessors). The results were then copied to Excel, and the Total Slack column was transformed into numbers for future analytic purposes1. The preceding calculations were then performed for each scenario, with the results given in Tables 2 through 4. Now we can do the calculation of the expected critical path length: — LCP =0.5(32)+0.3(33)+0.2(40)=33.9 We can also calculate the expected criticalities and total slack for each activity over all of the scenarios, as defined earlier. These are given in Table 5. The results show that if a4 occurs, it is critical, and if significant additional testing is required, there will be a substantial project delay. Notice that in the baseline case (Scenario 1), a5 is critical, but if a4 occurs, then a5 is not critical, with a total slack of 1 in Scenario 2 and 8 in Scenario 3. This suggests that planning for the project can be conditional; once it is known whether the pending legislation passes or not, and therefore whether a4 occurs or not, appropriate priority can be given to a5. We should also point out
a2
a0
a1
2. Loops Let us now consider an example that involves finite loops. We start again with a base case project definition, as depicted in Table 6. To understand the full problem situation, imagine that a2 involves producing some kind of prototype, and a3involves testing it. If the test fails (which we will assume has a probability of 0.2), then both activities will have to be repeated, but the durations will be shorter (1 for a2 and 2 for a3, as opposed to initial durations of 3 and 4, respectively), since we will just be refining the production process. The other 80% of the time, we assume the prototype passes the test (we assume the probability of failing twice is negligible). In a somewhat similar
a5
a7
a4
a3
Figure 1: Schematic micro-approach project network graph for the random event example
18 • Project Management Journal March 2005
that if the situation had been represented by including a4 in the network diagram for all three cases, and just giving it a duration of 0 in Scenario 1, then the results for Scenario 1 would be incorrect, because the network structure would force a2 to be a predecessor of a6 (when, in reality, it is not). Since the duration of a2 is 8 and the duration of a3 is 6, the faulty model would indicate that the early start time of a6 is 2 weeks later than it is in reality. This observation points out the importance of specifying each scenario as accurately as possible, and highlights the value of the scenario approach.
a6
a8
a2
a0
a5
a1
a3
a6
a2
a5
a7
a8
a7
a8
a7
a8
p(1)=.5
d4(2)=4
p(2)=.3 a0
a1
a4
a3
a6
a2
a5
p(3)=.2
d4(3)=11 a0
a1
a4
a3
a6
Figure 2: Scenario macro-approach diagram for random event example
March 2005 Project Management Journal • 19
a2
a0
a1
a3
a4
a5
a6
a8
a9
a6
a8
a9
a7
Figure 3: Schematic micro-approach diagram of the loop example
a2,1
a0
a1
a3,1
a4,1
a2,2
a3,2
a4,2
a4,3
a5
a7
Figure 4: Alternative schematic micro-approach diagram for loop example
N
(1)
N
(2)
N (3) N
(4)
N
(5)
N
(6)
Figure 5: Macro-approach diagram for looping and uncertain durations examples
20 • Project Management Journal March 2005
a2 d0 =0
d1=4
a0
a1
a4
a5
d2 =1 a3 d6 =9
d7 = 5
a6
a7
Figure 6: Basic network diagram for uncertain activity duration example
d8 = 6
d9 = 0
a8
a9
4
Random Event – Senario 1
5
Task Name
prob =
0.5
6
Random Event Example
7
A0
0
8
A1
7
2
9
A2
8
3
10
A3
6
11
A5
12
12
A6
9
5
13
A7
5
6,7
14
A8
0
8
15
A4
Duration (wks) Predecessors 32
Early Start
Early Finish
Late Start
Late Finish
5/19/2003 8:00 12/26/2003 17:00
5/19/2003 8:00 12/26/2003 17:00
5/19/2003 8:00
5/19/2003 8:00
5/19/2003 8:00
5/19/2003 8:00
7/4/2003 17:00
7/7/2003 8:00
8/29/2003 17:00
3
7/7/2003 8:00
8/15/2003 17:00
4
9/1/2003 8:00 11/21/2003 17:00
Total Slack (wks) Criticality
5/19/2003 8:00
0
1
5/19/2003 8:00
7/4/2003 17:00
0
1
7/7/2003 8:00
8/29/2003 17:00
0
1
8/11/2003 8:00
9/19/2003 17:00
5
0
9/1/2003 8:00 11/21/2003 17:00
0
1
8/18/2003 8:00 10/17/2003 17:00
9/22/2003 8:00 11/21/2003 17:00
5
0
11/24/2003 8:00 12/26/2003 17:00
11/24/2003 8:00 12/26/2003 17:00
0
1
12/26/2003 17:00 12/26/2003 17:00 12/26/2003 17:00 12/26/2003 17:00
0
1
Table 2: Random event network: calculations for scenario 1 ( LCP(1) = 32 )
fashion, a4 involves a casting process that may not work (the cast may break if the materials are not thick enough). The original activity is a “quick and dirty” attempt to do the casting, with an estimated 60% chance of success. If the process fails, the activity will be repeated, but more time will be taken to do it right (duration of 7 vs. 5). Even then, we assume a 10% chance of failure the second time around, forcing a third repetition of the casting activity, this time with a duration of 9. We assume the chances of a third failure are negligible. This problem could be diagrammed most directly as shown in Figure 3. Because of these types of looping, certain activities may end up being repeated once or twice in this example. We could always give these repetitions different activity number names, but this would not reflect their
connections to each other. As mentioned at the end of the previous section, we will use double subscripts, where the first subscript represents the original initial activity from the base case, and the second subscript represents which iteration of that activity we are discussing. This notation will apply to all definitions we have made that involved a subscript of j, where applicable. (For activities that are not involved in looping, we could make all of them have a second subscript of 1, but that seems unnecessarily cumbersome.) One way to represent this problem schematically, similar to what we did for our first example, is shown in Figure 4. Let us assume that the two cases for the first loop (whether the test fails or not) and the three cases for the second loop (whether the casting does
prob =
not fail the first time, fails only the first time, or fails twice) are assumed to be independent of each other2. Then there are six different scenarios to consider (three cases in the second loop for each of the two cases of the first loop). The probability for each scenario is just the product of the corresponding two probabilities for the two loops in that scenario. Thus, the project could also be conceived as shown in Figure 5, where N(1), N(2),…, N(6) are the standard network diagrams for the six scenarios. This way of thinking of the problem again makes it clear that we can do the overall analysis by simply analyzing each scenario, then combining the results. We will number the scenarios so that they have the following interpretations: • Scenario 1: First loop test is successful the first time; second loop
17
Random Event – Senario 2
0.3
18
Task Name
19
Random Event Example
20
A0
0
21
A1
7
2
22
A2
8
23
A3
6
24
A5
12
4
9/1/2003 8:00 11/21/2003 17:00
9/8/2003 8:00 11/28/2003 17:00
1
0
25
A6
9
5,10
9/29/2003 8:00 11/28/2003 17:00
9/29/2003 8:00 11/28/2003 17:00
0
1
26
A7
5
6,7
12/1/2003 8:00
1/2/2004 17:00
12/1/2003 8:00
1/2/2004 17:00
0
1
27
A8
0
8
12/2/2004 17:00
1/2/2004 17:00
1/2/2004 17:00
1/2/2004 17:00
0
1
28
A4
4
4,5
9/1/2003 8:00
9/26/2003 17:00
9/1/2003 8:00
9/26/2003 17:00
0
1
Duration (wks) Predecessors 33
Early Start
Early Finish
Late Start
Late Finish
Total Slack (wks) Criticality
5/19/2003 8:00
1/2/2004 17:00
5/19/2003 8:00
1/2/2004 17:00
5/19/2003 8:00
5/19/2003 8:00
5/19/2003 8:00
5/19/2003 8:00
0
1
5/19/2003 8:00
7/4/2003 17:00
5/19/2003 8:00
7/4/2003 17:00
0
1
3
7/7/2003 8:00
8/29/2003 17:00
7/7/2003 8:00
8/29/2003 17:00
0
1
3
7/7/2003 8:00
8/15/2003 17:00
7/21/2003 8:00
8/29/2003 17:00
2
0
Table 3: Random event network: calculations for scenario 2 ( LCP(2) = 33)
March 2005 Project Management Journal • 21
30
Random Event – Senario 3
31
Task Name
prob =
0.2
32
Random Event Example
40
5/19/2003 8:00
2/20/2004 17:00
5/19/2003 8:00
2/20/2004 17:00
33
A0
0
5/19/2003 8:00
5/19/2003 8:00
5/19/2003 8:00
5/19/2003 8:00
34
A1
7
2
5/19/2003 8:00
7/4/2003 17:00
5/19/2003 8:00
7/4/2003 17:00
0
1
35
A2
8
3
7/7/2003 8:00
8/29/2003 17:00
7/7/2003 8:00
8/29/2003 17:00
0
1
36
A3
6
3
7/7/2003 8:00
8/15/2003 17:00
7/21/2003 8:00
8/29/2003 17:00
2
0
37
A5
12
4
9/1/2003 8:00 11/21/2003 17:00
10/27/2003 8:00
1/16/2004 17:00
8
0
38
A6
9
5,10
11/17/2003 8:00
1/16/2004 17:00
11/17/2003 8:00
1/16/2004 17:00
0
1
39
A7
5
6,7
1/9/2003 8:00
2/20/2004 17:00
1/19/2004 8:00
2/20/2004 17:00
0
1
40
A8
0
8
2/20/2004 17:00
2/20/2004 17:00
2/20/2004 17:00
2/20/2004 17:00
0
1
41
A4
11
4,5
9/1/2003 8:00 11/14/2003 17:00
0
1
Duration (wks) Predecessors
Early Start
Early Finish
Late Start
9/1/2003 8:00 11/14/2003 17:00
Late Finish
Total Slack (wks) Criticality
0
1
Table 4: Random event network: calculations for scenario 3 ( LCP(3) = 40)
3
Activity
Prob. Occur
Exp. Crit.
Exp. Crit. Occur
Exp. TS Occur
4
A0
1
1
1
0
5
A1
1
1
1
0
6
A2
1
1
1
0
7
A3
1
0
0
3.5
8
A5
1
0.5
0.5
1.9
9
A6
1
0.5
0.5
2.5
10
A7
1
1
1
0
11
A8
1
1
1
0
12
A4
0.5
0.5
1
0
Table 5: Random event network: probability of occurrence, expected criticalities, and expected total slack for each activity
casting is successful the first time. • Scenario 2: First loop test is successful the first time; second loop casting fails the first time, but is successful the second time. • Scenario 3: First loop test is successful the first time; second loop casting fails the first and second times, but is successful the third time. • Scenario 4: First loop test fails the first time, but is successful the second time; second loop casting is successful the first time. • Scenario 5: First loop test fails the first time, but is successful the second time; second loop casting fails the first time, but is successful the second time. • Scenario 6: First loop test fails the first time, but is successful the second time; second loop casting fails the first and second times, but is successful the third time. Again, we used Microsoft Project
22 • Project Management Journal March 2005
2002 to analyze each of these scenarios, and passed the results to Excel. Rather than providing the complete results for each individual scenario as in the Random Event example above,
aj
Pj
dj
a0 a1 a2 a3 a4 a5 a6 a7 a8 a9
--{a0} {a1} {a2} {a1} {a1} {a3} {a4,a5} {a6 ,a7} {a8}
0 6 3 4 5 10 11 8 13 0
Table 6: Loop network: base case
we will instead simply summarize the results in Table 7. Notice, for example, that activities a2,1 and a3,1 (the first occurrence of the prototype production and testing activities) are critical in scenarios 1, 4, and 5, but not in scenarios 2, 3, and 6 (in which both activities have total slack values of 2, 11, and 8, respectively). On the other hand, a4,1 (first occurrence of the casting activity) is exactly the opposite: it is critical in scenarios 2, 3, and 6, but not in scenarios 1, 4, and 5 (where total slack values of that activity are 5, 8, and 1, respectively). Using the probabilities given in Table 7, we can now do the calculation of the expected critical path length: — LCP =0.480(37)+0.288(39)+ (0.120+0.072)(40)+(0.032+0.008) (48)=38.592 We can also calculate the expected criticalities and total slack for each activity over all of the scenarios, as defined earlier. These are given in Table 8. In the base case, the first loop is critical. If the first loop is successful, whether or not the second loop fails once or twice, the second loop is critical. If the first loop fails, it is critical unless the second loop fails twice (a very low-probability event). Notice that the loop nature of this example means that activities 2 and 3 sometimes occur twice, and activity 4 can occur as many as three times. Based on the original data, we can compute the average total time spent
2
Scenario
3
Probability
1
2
3
4
5
6
0.480
0.288
0.032
0.120
0.072
0.008
4
Critical Path Length
5
Activity
37
39
48
40
40
48
6
A0
0
1
0
1
0
1
0
1
0
1
0
1
7
A1
0
1
0
1
0
1
0
1
0
1
0
1
8
A2, 1
0
1
2
0
11
0
0
1
0
1
8
0
9
A3, 1
0
1
2
0
11
0
0
1
0
1
8
0
10
A4, 1
5
0
0
1
0
1
8
0
1
0
0
1
11
A5
0
1
2
0
11
0
3
0
3
0
11
0
12
A6
0
1
2
0
11
0
0
1
0
1
8
0
13
A7
0
1
0
1
0
1
3
0
1
0
0
1
14
A8
0
1
0
1
0
1
0
1
0
1
0
1
15
A9
0
1
0
1
0
1
0
1
0
1
0
1
16
A2, 2
0
1
0
1
8
1
17
A3, 2
0
1
0
1
8
0
18
A4, 2
1
0
0
1
19
A4, 3
0
1
Total Slack Criticality Total Slack Criticality Total Slack Criticality Total Slack Criticality Total Slack Criticality Total Slack Criticality
0
0
0
1
0
1
Table 7: Loop network: calculations for scenarios 1-6
on each of these activities: — d 2 =d2,1+(0.2).d2,2=3+(0.2).1=32 — (d 2,2 =0.2) — d 3 =d3,1+(0.2).d3,2=4+(0.2).2=44 — (d 3,2 =0.4) — d 4 =d4,1+(0.4).d4,2+(0.1).d4,3= 5+(0.4).7+(0.1).9=8.7 — — (d 4,2 =2.8, d 4,3=0.9 )
Prob. Occur
In other words, the total expected time spent on producing prototypes is 3.2 weeks, the total expected time spent on testing prototypes is 4.4 weeks, and the total expected time spent on casting is 8.7 weeks. Using the calculations done for our analysis, we can also calculate figures such as expected early start and late start times (the earliest and latest points in time when the first repetition Exp. Crit.
Exp. Crit. Occur
Exp. TS Occur
of that activity can start, averaged over the scenarios, weighted by their probabilities), as well as early finish and late finish times (the earliest and latest points in time when the last repetition of that activity can finish, averaged over the scenarios, weighted by their probabilities) for each of these loop activities. These calculations were discussed at the end of the Modeling Approach section. — — — ES2,.=6, ES3,.=9, ES4,.=6
3
Activity
4
A0
1
1.000
1
0
5
A1
1
1.000
1
0
6
A2, 1
1
0.672
0.672
0.992
7
A3, 1
1
0.672
0.672
0.992
8
A4, 1
1
0.328
0328
3.432
9
A5
1
0.480
0.48
1.592
10
A6
1
0.672
0.672
0.992
— EF4,.=(0.480+0.120).(11)+ (0.288+0.0720).(18)+(0.032+0.008).(27)
11
A7
1
0.808
0.808
0.432
=14.16
12
A8
1
1.000
1
0
13
A9
1
1.000
1
0
14
A2, 2
0.2
0.192
0.96
0.32
15
A3, 2
0.2
0.192
0.96
0.32
16
A4, 2
0.4
0.328
0.82
0.18
17
A, 3
0.04
0.040
1
0
Table 8: Network: probability of occurrence, expected criticalities, and expected total slack for each activity
— EF2,.=(0.480+0.288+0.032).(9)+ (0.120+0.072+0.008).(14)=10.0 — EF3,.=(0.480+0.288+0.032).(13)+ (0.120+0.072+0.008).(16)=13.6
Using analogous calculations, we obtain: — — — LS2,.=6.992, LS3,.=9.992, LS4,.=9.432, — — LF 2, . =10.992, LF3,.=14.592, — and LF4,.=17.592
March 2005 Project Management Journal • 23
d3
d4
Probability
6
3
.6
11
4
.3
11
5
.1
Table 9: Uncertain durations of activities 3 and 4
This means, for example, that the expected earliest time we can start prototype production is 6 weeks into the project, the expected earliest time we can complete all prototype production is 10 weeks into the project, the expected latest time we can start prototype production is just under 7 weeks into the project, and the expected latest time we can complete prototype production is just under 11 weeks into the project. If desired, the actual ES, EF, LS,
(conditional) expected criticalities; therefore, they must be given high priority if they occur. 3. Dependent Activity Durations In this example, we assume that there is a network scenario for every combination of discrete random durations. The basic structure of this example is shown in Figure 6. In this case, there are no activities that occur in some scenarios and not others. The uncertainty lies only in the durations of activities 3, 4,
d5
Probability
8
.8
10
.2
Table 10: Uncertain duration of activity 5
and LF times for each activity in each scenario could also easily be generated and reported in a table, for a more detailed risk analysis. Activities 0, 1, 8, and 9 (a0, a1, a8, and a9, respectively) are always critical,
and 5. These durations are not assumed to be totally independent, as an illustration of a more general case. The durations of activities 3 and 4 are assumed to be dependent, with the probability distribution given in Table 9. For exam-
Scenario
d3
d4
d5
Probability
1
6
3
8
.48
2
6
3
10
.12
3
11
4
8
.24
4
11
4
10
.06
5
11
5
8
.08
6
11
5
10
.02
Table 11: Scenarios for uncertain duration example
due to the structure of the project network. Notice that a4,1 has low expected criticality (both unconditional and conditional) and the highest expected total slack, so it could be given the lowest priority in scheduling. a5 is similar, but not as extreme, so it could be given the second-lowest priority in scheduling. Also, note that any of the repeated activities (i.e., the last four activities in Table 8), if they occur, have very high
24 • Project Management Journal March 2005
ple, the three outcomes/probabilities could correspond to no precipitation, light precipitation, and heavy precipitation. Activities 3 and 4 will be performed at approximately the same time, but activity 3’s duration may just depend on whether or not there is precipitation (e.g., pouring concrete), while activity 4’s duration is more sensitive to the severity of the precipitation. The duration of activity 5 is
assumed to be independent of the combination of values of activities 3 and 4, with the probability distribution given in Table 10. Since the two probability distributions are independent, we have a total of six different possible scenarios, with probabilities given in Table 11. Since this example has six scenarios, like the previous example, Figure 5 also represents the macro-level approach for this problem. From Table 11, we can calculate the expected durations of the three uncertain activities: — d 3 =(0.48+0.12).(6)+(0.24+0.06+ 0.08+0.02).(11)=8.0 — d4 =(0.48+0.12).(3)+(0.24+0.06).(4)+ (0.08+0.02).(5)=3.5 — d5 =(0.48+0.24+0.08).(8)+(0.12+0.06+ 0.02).(10)=8.4 Table 12 shows a summary of the results for each of these scenarios. Now we can do the calculation of the expected critical path length: — LCP =(0.48+0.12).24+(0.24+0.06+ 0.08+0.02).27=25.2 We can also calculate the expected criticalities and total slack for each activity over all of the scenarios, as defined earlier. These are given in Table 13. Activity 3 is critical in all cases where its duration is longest (11), regardless of the duration of activities 4 and 5. Activities 4 and 5 are critical only when activity 3’s duration is shortest (6), and activity 5’s duration is longest (10). Note that, in this example, the conditional expected total slack is also unconditional, since all activities occur in every scenario. Conclusions and Managerial Implications This paper presents an alternate macro-level or scenario approach for modeling and analyzing projects with uncertain networks. This approach is applicable for project schedule risk
2
Scenario
3
Probability
1
2
3
4
5
6
0.480
0.120
0.240
0.060
0.080
0.020
4
Critical Path Length
5
Activity
24
24
27
27
27
27
6
A0
0
1
0
1
0
1
0
1
0
1
0
1
7
A1
0
1
0
1
0
1
0
1
0
1
0
1
8
A2
2
0
0
1
0
1
0
1
0
1
0
1
9
A3
2
0
2
0
0
1
0
1
0
1
0
1
10
A4
2
0
0
1
4
0
2
0
3
0
1
0
11
A5
2
0
0
1
4
0
2
0
3
0
1
0
12
A6
0
1
0
1
3
0
3
0
3
0
3
0
13
A7
0
1
0
1
0
1
0
1
0
1
0
1
14
A8
0
1
0
1
0
1
0
1
0
1
0
1
15
A9
0
1
0
1
0
1
0
1
0
1
0
1
Total Slack Criticality Total Slack Criticality Total Slack Criticality Total Slack Criticality Total Slack Criticality Total Slack Criticality
Table 12: Uncertain activity durations network: calculations for scenarios 1 - 6
analysis and contingency planning. During the project planning process, a series of project network scenarios can be identified, each with an assessed probability of occurrence. These scenarios might differ according to the results of uncertain events that could Exp. Crit.
and conditional activity criticality and slack, as well as aggregated expected durations, and early and late start and finish times for repeated activities resulting from looping or stochastic branching. A second benefit is greater accessibility and likelihood of the use
3
Activity
4
A0
5
A1
1
1
0
6
A2
0.52
0.52
0.96
7
A3
0.4
0.4
1.2
8
A4
0.12
0.12
2.3
9
A5
0.12
0.12
2.3
10
A6
0.6
0.6
1.2
11
A7
1
1
0
12
A8
1
1
0
13
A9
1
1
0
1
Exp. Crit. Occur
Exp. TS Occur
1
0
Table 13: Uncertain activity durations network: overall expected criticalities and total slack for each activity
occur during the course of the project, uncertain (possibly dependent) activity durations, finite loops, or any combination of these three. We have presented a scenario approach for modeling and analyzing these uncertain project situations. An advantage of our approach is that it generalizes standard project network analysis methods, such as critical path analysis, to the network scenario level. Our approach also leads to the development of new project network uncertainty measures, including expected
of uncertainty analysis in project planning, since the modest data needs and straightforward analysis are focused on key scenarios driving schedule uncertainty. Examples were presented to illustrate the approach, including random events, loops, and dependent random activity times. The scenario method proposed here is a direct extension of existing project scheduling procedures, and uses software and techniques familiar to (and easily accessible by) almost all project managers. This approach pro-
vides exact results, as well as simplicity, and offers advantages in analyzing and interpreting the impact of uncertainty, especially when the number of critical uncertainties is relatively small. The proposed approach can handle uncertain activity durations and finite loops with varying durations for each repetition, allows the durations of activities to be dependent upon others, and provides the ability to summarize critical path analysis information about repeated and uncertain activities. For these reasons, we believe that our approach is more manageable and comprehensive than existing methods for project managers analyzing the effects of uncertainty on their project schedule. References and Notes Malcolm, D. G., Rosenboom, J. H., Clark, C. E., & Fazar, W. (1959). Application of a technique for research and development project evaluation. Operations Research, 7(5), 646-669. Neumann, K. (1990). Stochastic project networks: Temporal analysis, scheduling, and cost minimization. Berlin: Springer-Verlag. Pollack-Johnson, B., & Liberatore, M. J. (2003). Analytical techniques in project planning and control: Current practice and future research directions. Unpublished manuscript, Villanova, PA: Villanova University, Department of Decision and Information Technologies.
March 2005 Project Management Journal • 25
Pritsker, A. A. B., & Happ, W. W. (1966). GERT: Graphical evaluation and review technique — part 1. Fundamentals. Journal of Industrial Engineering, 17, 267-274. Pritsker, A. A. B., & O’Reilly, J. J. (1999). Simulation with Visual SLAM and AweSim, New York: John Wiley & Sons. Project Management Institute. (2000). A guide to the project manage-
ment body of knowledge (PMBOK® guide). Newtown Square, PA: Author. Project Management Institute. (1999). Project management software survey. Newtown Square, PA: Author. Wiest, J. D., & Levy, F. K. (1977). A management guide to PERT/CPM with GERT/PDM/DCPM and other networks (2nd ed.). Englewood Cliffs, NJ: Prentice-Hall.
1 For details about any of the Microsoft Project or Excel calculations performed in this article, please contact the authors. 2 These could also be made dependent using the proposed approach, as the third example demonstrates.
BRUCE POLLACK-JOHNSON earned a BA in sociology with a minor in education from Brandeis University, an MA in Applied Mathematics from Temple University, and an MS and PhD in Operations Research from the University of Pennsylvania. He has taught at Oberlin College, and is currently an Associate Professor of Mathematical Sciences at Villanova University. He has published dozens of papers on project management, forecasting, educational modeling, and on teaching applied mathematics, as well as a two-volume text on business calculus and finite mathematics (partially funded by grants from FIPSE, NSF, and Prentice Hall). His current research is on modeling uncertainty in project scheduling. He is a member of INFORMS and MAA.
MATTHEW J. LIBERATORE, PhD, is the John F. Connelly Chair in Management and Professor of Decision and Information Technologies at Villanova University. He previously served as Chair of the Department of Management and as Associate Dean. Dr. Liberatore has published over sixty journal articles in the fields of project management, management science, information systems, and research and engineering management. He recently co-authored a text, Decision Technology: Modeling, Software, and Applications, published by Wiley. Dr. Liberatore serves on the editorial boards of the American Journal of Mathematical and Management Sciences and IEEE Transactions on Engineering Management. He is a member of PMI, INFORMS, and the Decision Sciences Institute.
26 • Project Management Journal March 2005
ABSTRACT An important component of risk management relates to project schedule uncertainty. To address this issue, a scenario (i.e., macro-level approach) for modeling and analyzing projects with significant uncertainty in their network structure and/or durations of some activities is presented. This approach requires that a set of project network scenarios is able to be identified, each with an assessed probability of occurrence. These scenarios might differ according to the results of uncertain events that could occur during the course of the project, uncertain activity durations (whether independent or dependent), finite loops where repeated activities can have different durations, or a combination of these. Advantages of our approach include the use of standard methods and software, as well as greater accessibility to, and likelihood of, the use of uncertainty analysis in project planning. Several examples are used to illustrate the suggested approach. Keywords: Project scheduling; risk management; project network analysis ©2005 by the Project Management Institute Vol. 36, No. 1, 15-26, ISSN 8756-9728/03
Background isk management is one of the nine Knowledge Areas within the Project Management Institute’s A Guide to the Project Management Body of Knowledge (PMBOK® Guide) (Project Management Institute [PMI], 2000). An important component of risk management relates to project schedule uncertainty. Traditionally, project schedule uncertainty has been addressed by considering the uncertainty related to activity duration. The most wellknown technique is Program Evaluation and Review Technique (PERT), developed by the U.S. federal government in the late 1950s (Malcolm, Rosenboom, Clark, & Fazar, 1959). PERT models uncertain activity durations by collecting optimistic, most likely, and pessimistic duration estimates of all activities. Although PERT is sometimes used to estimate the expected length of the critical path, Monte Carlo simulation is more commonly used to estimate the criticality of different activities and paths, as well as the probability distribution of the project duration. The importance of addressing uncertainty related to activity duration can be seen by considering the results of surveys regarding available project management software and practitioner use of project network analysis methods. For example, a 1999 software survey by the Project Management Institute showed that about 20% of project management software packages had Monte Carlo simulation capability (PMI, 1999). Also, a more recent survey of project management professionals (Pollack-Johnson & Liberatore, 2003) found that nearly 70% of the respondents used critical path analysis, and 17% used probabilistic analysis and/or simulation within project management software. However, project management professionals responding to this survey also reported a need for research on how to better address uncertain network structures (Pollack-Johnson & Liberatore, 2003). Uncertain project network structures can arise in a variety of ways. For example, in a new product or process development project, it may be uncertain whether quality requirements will lead to one or more re-work cycles. In a new technology-implementation project, it may be uncertain whether formal staff training activities are required. In a research project, depending upon the results obtained in the first stage, different sequences of activities may follow. In a pharmaceutical development project, additional testing may be
R
*corresponding author March 2005 Project Management Journal • 15
required if certain pending legislation passes. Simulation packages such as the Graphical Evaluation and Review Technique, or GERT, (Pritsker & Happ, 1966; Wiest & Levy, 1977) were developed to model some probabilistic networks similar to the examples presented above. Even when GERT was produced and supported, however, it assumed that repeated activities within loops had identical duration distributions (i.e., the same average duration for each repetition) (Neumann, 1990). It also assumed independence of duration distributions (i.e., the time one activity takes does not influence the time another takes). The approach we propose in this paper can handle all of these situations. GERT is no longer produced and supported, but many of its capabilities are now available in related, general-purpose simulation software packages called Visual SLAM and AweSim (Pritsker & O’Reilly, 1999). These packages enable the user to develop GERT-type project simulation models, but are not specifically designed for project management as GERT was, can be difficult to use, and become even more challenging as the project network size and complexity increase. In addition, the simulation approach itself is micro-oriented, since it models the uncertainty at the activity level. There are situations where the uncertainty is related to different sequences or combinations of events occurring or not occurring, such as in the pharmaceutical pending legislation example, and, therefore, can be conceived as relating to different project scenarios rather than individual activities. For these reasons, a simpler approach is needed when there are important project network uncertainties that must be addressed as part of the project risk analysis and assessment process. Existing methods are especially inadequate for loops where repeated activities do not have identical duration distributions; for dependent duration distributions; and for obtaining detailed and summary (expected) early/late start/finish times,
16 • Project Management Journal March 2005
criticalities, and total slack (float) values for individual activities, as well as for common or aggregated activities across probabilistic branches or within loops. The purpose of this paper is to present a scenario, or macro-level approach, for modeling and analyzing projects with significant uncertainty in their network structure and/or the durations of some activities. This approach is applicable for project schedule risk analysis and contingency planning. An advantage of our approach is the use of standard methods, such as critical path analysis and probability analysis, and popular software packages, such as Microsoft Project® and Excel®, to solve projectplanning problems with uncertain network structures. The benefits of our approach are its ability to identify the same activities in different scenarios and summarize results for them overall, with modest data requirements, greater simplicity, and comprehensibility. This would lead to a greater likelihood of the use of uncertainty analysis, and some additional insights into the impact of uncertainty. First, we present our scenario approach. Next, some examples of uncertain networks are presented and analyzed using our approach. Conclusions and suggestions for future study follow. Project Networks and the Critical Path A traditional project network in Activity on Node (AoN) form is defined as a set of nodes representing activities that are connected by directed arcs to represent precedence relationships. If one activity must occur directly before a second activity, we say that the second activity is an immediate predecessor of the first. Cycles (loops) of activities within the project network are not allowed. We assume that there is only one activity without predecessors (possibly an artificially constructed dummy activity) and is called the start activity. We also assume that there is only one activity without successors (possibly a dummy), which is called the finish activity. If the original project network does not have unique start
or finish activities, we add dummy activities (with zero duration) for this purpose. The length of the longest (but not necessarily unique) path from the start activity to the finish activity is the minimum project completion time. Such a path is called a critical path, the activities along it are called critical path activities, and we will denote the length of the path as LCP. Let us define: j activity j aj = activity j Pj = set of all immediate predecessors of activity j ESj = earliest possible start time for activity j EFj = earliest possible finish time for activity j LSj = latest possible start time for activity j (that would not delay the project finish date) LFj = latest possible finish time for activity j (that would not delay the project finish date) TSj = total slack for activity j (the time it could be individually delayed without delaying the entire project) The critical path can be determined by performing forward and backward passes through the project network. The forward pass includes computing the earliest start (ES) and the earliest finish (EF) times for each activity, while the backward pass requires computing the latest start (LS) and latest finish (LF) times. Once both passes are completed, the total slack (TS) for each activity can be computed. The total slack of each activity is the difference between its ES and LS. Any path from the start activity to the finish activity consisting only of activities with a total slack of 0 is called a critical path. Any activity with a total slack of 0 is called a critical activity, since any delay in that activity alone will delay the whole project (the soonest it can be completed) by the same
amount of time. We say that a critical activity has a criticality of 1, and any other activity has a criticality of 0. The Scenario Approach In this paper, we focus on a scenario approach for analyzing uncertain project networks. The uncertain network structure is expressed through a set of network scenarios, each having a specified probability of occurrence. For example, if a finite loop is present, the problem cannot be represented directly using the standard project network described in the previous section. However, using a network scenario approach, a set of project networks without loops can be constructed and analyzed using conventional techniques. A similar approach can be used when considering probabilistic branching. In what follows, we initially assume that the activity durations are known with certainty, although the approach presented can be easily extended to the case of probabilistic durations, especially if only a limited number of activities have significant uncertainty in their durations. Let us define: i network scenario i N(i) = network scenario i p(i) = probability of network scenario i oj = probability that activity j will actually occur — d j = expected duration of activity j (considering its duration to be 0 if it does not occur) LCP(i) = critical path length for network scenario i — LCP = expected critical path length over all network scenarios The probability that each activity will occur is just the sum of the probabilities of all scenarios in which that activity occurs. The calculations of expected quantities are standard expected value calculations: the value in each scenario is multiplied by the probability of that scenario, and then all of the results are added together.
Let us also define: cj (i) = criticality of activity j in
network scenario i
=
1 if activity j is critical in network scenario (only if aj occurs) 0 if not (including if aj does not occur)
— c j = expected criticality of activity j over all network scenarios — = expected criticality of c j|occur
activity j, given that aj actually occurs The expected criticality is calculated in the same way as the expected value calculations described earlier. We will use the subscript “j|occur” notation to refer to conditional means (conditioned on activity j actually occurring) for other quantities as well. These are standard conditional expected values, and are calculated in a manner similar to the other expected value calculations (the sum of the values times the probabilities of their occurring), but only for the scenarios in which activity j occurs. This total is then divided by the probability that activity j occurs to get the conditional expected value or mean. We will use similar notation and calculations to define:
ditional, as above.) Some projects (see example 2) could be conceived of as involving finite loops, so we can use double subscript notation to indicate multiple iterations of the same activity, following the pattern below: aj,k = iteration k of activity j In such a case, we can define the following: — dj,k = average duration of aj,k (considering the duration to be 0 when it does not occur) — dj,• = average total duration of all iterations of activity j (again, considering the duration to be 0 when it does not occur)
— ES = average ES of the first of all j,•
iterations of activity j
— EF = average EF of the last of all j,•
iterations of activity j
— LS = average LS of the first of all j,•
iterations of activity j
— LF = average LF of the last of all j,•
iterations of activity j (Again, these could be made conditional if necessary.) The calculations are straightforward, consistent with the earlier discussion. Examples
— LF j = expected late finish time for activity j
1. Random Event Consider the project network given as Table 1. Suppose that this problem includes a random event, such as the result of pending legislation that could require an additional testing activity, a4. There are three possible scenarios: (Denoted as N(1))—no additional testing (legislation does not pass), with a probability of 0.5 (Denoted as N(2))—minimal additional testing, duration of 4, with a probability of 0.3 (Denoted as N(3))—significant additional testing, duration of 11, with a probability of 0.2 In scenarios 2 and 3, a4 has immediate predecessors of a2 and a3, and is an immediate predecessor of a6.
(If aj did not occur in some scenarios, we could also make these con-
We can represent this situation schematically with a modified version
— TS j|occur = expected total slack of activity j, given that aj actually occurs If activity j occurs in all scenarios, we can also similarly define and calculate: — ESj = expected early start time for activity j — EFj = expected early finish time for activity j — LSj = expected late start time for activity j
March 2005 Project Management Journal • 17
aj
Pj
dj
a0 a1 a2 a3 a5 a6 a7 a8
--{a 0} {a 1} {a 1} {a 2} {a 3} {a 5 ,a 6} {a 7}
0 7 8 6 12 9 5 0
Table 1: Random event network: base case
of an Activity on Node (AoN) network, where arrows represent precedence relations and dotted arrows indicate uncertain precedence relations (ones that exist in some scenarios, and not others), as shown in Figure 1. One way of depicting our approach is through the modified project network shown as Figure 2, where a circular node is a probabilistic branch. Using our notation defined in the previous section, as shown in Figure 2, the scenario probabilities are: p(1) = 0.5, p(2) = 0.3, and p(3) = 0.2. Note that activity 4 (a4) is the only activity that does not always occur: — d4 =(0.5)(0)+(0.3)(4)+(0.2)(11)=3.4
A critical path analysis of each of the three scenarios was performed using Microsoft Project 2002. After analyzing the base case, the remaining two scenarios were analyzed by modifying the base case (adding a4, and adjusting the predecessors). The results were then copied to Excel, and the Total Slack column was transformed into numbers for future analytic purposes1. The preceding calculations were then performed for each scenario, with the results given in Tables 2 through 4. Now we can do the calculation of the expected critical path length: — LCP =0.5(32)+0.3(33)+0.2(40)=33.9 We can also calculate the expected criticalities and total slack for each activity over all of the scenarios, as defined earlier. These are given in Table 5. The results show that if a4 occurs, it is critical, and if significant additional testing is required, there will be a substantial project delay. Notice that in the baseline case (Scenario 1), a5 is critical, but if a4 occurs, then a5 is not critical, with a total slack of 1 in Scenario 2 and 8 in Scenario 3. This suggests that planning for the project can be conditional; once it is known whether the pending legislation passes or not, and therefore whether a4 occurs or not, appropriate priority can be given to a5. We should also point out
a2
a0
a1
2. Loops Let us now consider an example that involves finite loops. We start again with a base case project definition, as depicted in Table 6. To understand the full problem situation, imagine that a2 involves producing some kind of prototype, and a3involves testing it. If the test fails (which we will assume has a probability of 0.2), then both activities will have to be repeated, but the durations will be shorter (1 for a2 and 2 for a3, as opposed to initial durations of 3 and 4, respectively), since we will just be refining the production process. The other 80% of the time, we assume the prototype passes the test (we assume the probability of failing twice is negligible). In a somewhat similar
a5
a7
a4
a3
Figure 1: Schematic micro-approach project network graph for the random event example
18 • Project Management Journal March 2005
that if the situation had been represented by including a4 in the network diagram for all three cases, and just giving it a duration of 0 in Scenario 1, then the results for Scenario 1 would be incorrect, because the network structure would force a2 to be a predecessor of a6 (when, in reality, it is not). Since the duration of a2 is 8 and the duration of a3 is 6, the faulty model would indicate that the early start time of a6 is 2 weeks later than it is in reality. This observation points out the importance of specifying each scenario as accurately as possible, and highlights the value of the scenario approach.
a6
a8
a2
a0
a5
a1
a3
a6
a2
a5
a7
a8
a7
a8
a7
a8
p(1)=.5
d4(2)=4
p(2)=.3 a0
a1
a4
a3
a6
a2
a5
p(3)=.2
d4(3)=11 a0
a1
a4
a3
a6
Figure 2: Scenario macro-approach diagram for random event example
March 2005 Project Management Journal • 19
a2
a0
a1
a3
a4
a5
a6
a8
a9
a6
a8
a9
a7
Figure 3: Schematic micro-approach diagram of the loop example
a2,1
a0
a1
a3,1
a4,1
a2,2
a3,2
a4,2
a4,3
a5
a7
Figure 4: Alternative schematic micro-approach diagram for loop example
N
(1)
N
(2)
N (3) N
(4)
N
(5)
N
(6)
Figure 5: Macro-approach diagram for looping and uncertain durations examples
20 • Project Management Journal March 2005
a2 d0 =0
d1=4
a0
a1
a4
a5
d2 =1 a3 d6 =9
d7 = 5
a6
a7
Figure 6: Basic network diagram for uncertain activity duration example
d8 = 6
d9 = 0
a8
a9
4
Random Event – Senario 1
5
Task Name
prob =
0.5
6
Random Event Example
7
A0
0
8
A1
7
2
9
A2
8
3
10
A3
6
11
A5
12
12
A6
9
5
13
A7
5
6,7
14
A8
0
8
15
A4
Duration (wks) Predecessors 32
Early Start
Early Finish
Late Start
Late Finish
5/19/2003 8:00 12/26/2003 17:00
5/19/2003 8:00 12/26/2003 17:00
5/19/2003 8:00
5/19/2003 8:00
5/19/2003 8:00
5/19/2003 8:00
7/4/2003 17:00
7/7/2003 8:00
8/29/2003 17:00
3
7/7/2003 8:00
8/15/2003 17:00
4
9/1/2003 8:00 11/21/2003 17:00
Total Slack (wks) Criticality
5/19/2003 8:00
0
1
5/19/2003 8:00
7/4/2003 17:00
0
1
7/7/2003 8:00
8/29/2003 17:00
0
1
8/11/2003 8:00
9/19/2003 17:00
5
0
9/1/2003 8:00 11/21/2003 17:00
0
1
8/18/2003 8:00 10/17/2003 17:00
9/22/2003 8:00 11/21/2003 17:00
5
0
11/24/2003 8:00 12/26/2003 17:00
11/24/2003 8:00 12/26/2003 17:00
0
1
12/26/2003 17:00 12/26/2003 17:00 12/26/2003 17:00 12/26/2003 17:00
0
1
Table 2: Random event network: calculations for scenario 1 ( LCP(1) = 32 )
fashion, a4 involves a casting process that may not work (the cast may break if the materials are not thick enough). The original activity is a “quick and dirty” attempt to do the casting, with an estimated 60% chance of success. If the process fails, the activity will be repeated, but more time will be taken to do it right (duration of 7 vs. 5). Even then, we assume a 10% chance of failure the second time around, forcing a third repetition of the casting activity, this time with a duration of 9. We assume the chances of a third failure are negligible. This problem could be diagrammed most directly as shown in Figure 3. Because of these types of looping, certain activities may end up being repeated once or twice in this example. We could always give these repetitions different activity number names, but this would not reflect their
connections to each other. As mentioned at the end of the previous section, we will use double subscripts, where the first subscript represents the original initial activity from the base case, and the second subscript represents which iteration of that activity we are discussing. This notation will apply to all definitions we have made that involved a subscript of j, where applicable. (For activities that are not involved in looping, we could make all of them have a second subscript of 1, but that seems unnecessarily cumbersome.) One way to represent this problem schematically, similar to what we did for our first example, is shown in Figure 4. Let us assume that the two cases for the first loop (whether the test fails or not) and the three cases for the second loop (whether the casting does
prob =
not fail the first time, fails only the first time, or fails twice) are assumed to be independent of each other2. Then there are six different scenarios to consider (three cases in the second loop for each of the two cases of the first loop). The probability for each scenario is just the product of the corresponding two probabilities for the two loops in that scenario. Thus, the project could also be conceived as shown in Figure 5, where N(1), N(2),…, N(6) are the standard network diagrams for the six scenarios. This way of thinking of the problem again makes it clear that we can do the overall analysis by simply analyzing each scenario, then combining the results. We will number the scenarios so that they have the following interpretations: • Scenario 1: First loop test is successful the first time; second loop
17
Random Event – Senario 2
0.3
18
Task Name
19
Random Event Example
20
A0
0
21
A1
7
2
22
A2
8
23
A3
6
24
A5
12
4
9/1/2003 8:00 11/21/2003 17:00
9/8/2003 8:00 11/28/2003 17:00
1
0
25
A6
9
5,10
9/29/2003 8:00 11/28/2003 17:00
9/29/2003 8:00 11/28/2003 17:00
0
1
26
A7
5
6,7
12/1/2003 8:00
1/2/2004 17:00
12/1/2003 8:00
1/2/2004 17:00
0
1
27
A8
0
8
12/2/2004 17:00
1/2/2004 17:00
1/2/2004 17:00
1/2/2004 17:00
0
1
28
A4
4
4,5
9/1/2003 8:00
9/26/2003 17:00
9/1/2003 8:00
9/26/2003 17:00
0
1
Duration (wks) Predecessors 33
Early Start
Early Finish
Late Start
Late Finish
Total Slack (wks) Criticality
5/19/2003 8:00
1/2/2004 17:00
5/19/2003 8:00
1/2/2004 17:00
5/19/2003 8:00
5/19/2003 8:00
5/19/2003 8:00
5/19/2003 8:00
0
1
5/19/2003 8:00
7/4/2003 17:00
5/19/2003 8:00
7/4/2003 17:00
0
1
3
7/7/2003 8:00
8/29/2003 17:00
7/7/2003 8:00
8/29/2003 17:00
0
1
3
7/7/2003 8:00
8/15/2003 17:00
7/21/2003 8:00
8/29/2003 17:00
2
0
Table 3: Random event network: calculations for scenario 2 ( LCP(2) = 33)
March 2005 Project Management Journal • 21
30
Random Event – Senario 3
31
Task Name
prob =
0.2
32
Random Event Example
40
5/19/2003 8:00
2/20/2004 17:00
5/19/2003 8:00
2/20/2004 17:00
33
A0
0
5/19/2003 8:00
5/19/2003 8:00
5/19/2003 8:00
5/19/2003 8:00
34
A1
7
2
5/19/2003 8:00
7/4/2003 17:00
5/19/2003 8:00
7/4/2003 17:00
0
1
35
A2
8
3
7/7/2003 8:00
8/29/2003 17:00
7/7/2003 8:00
8/29/2003 17:00
0
1
36
A3
6
3
7/7/2003 8:00
8/15/2003 17:00
7/21/2003 8:00
8/29/2003 17:00
2
0
37
A5
12
4
9/1/2003 8:00 11/21/2003 17:00
10/27/2003 8:00
1/16/2004 17:00
8
0
38
A6
9
5,10
11/17/2003 8:00
1/16/2004 17:00
11/17/2003 8:00
1/16/2004 17:00
0
1
39
A7
5
6,7
1/9/2003 8:00
2/20/2004 17:00
1/19/2004 8:00
2/20/2004 17:00
0
1
40
A8
0
8
2/20/2004 17:00
2/20/2004 17:00
2/20/2004 17:00
2/20/2004 17:00
0
1
41
A4
11
4,5
9/1/2003 8:00 11/14/2003 17:00
0
1
Duration (wks) Predecessors
Early Start
Early Finish
Late Start
9/1/2003 8:00 11/14/2003 17:00
Late Finish
Total Slack (wks) Criticality
0
1
Table 4: Random event network: calculations for scenario 3 ( LCP(3) = 40)
3
Activity
Prob. Occur
Exp. Crit.
Exp. Crit. Occur
Exp. TS Occur
4
A0
1
1
1
0
5
A1
1
1
1
0
6
A2
1
1
1
0
7
A3
1
0
0
3.5
8
A5
1
0.5
0.5
1.9
9
A6
1
0.5
0.5
2.5
10
A7
1
1
1
0
11
A8
1
1
1
0
12
A4
0.5
0.5
1
0
Table 5: Random event network: probability of occurrence, expected criticalities, and expected total slack for each activity
casting is successful the first time. • Scenario 2: First loop test is successful the first time; second loop casting fails the first time, but is successful the second time. • Scenario 3: First loop test is successful the first time; second loop casting fails the first and second times, but is successful the third time. • Scenario 4: First loop test fails the first time, but is successful the second time; second loop casting is successful the first time. • Scenario 5: First loop test fails the first time, but is successful the second time; second loop casting fails the first time, but is successful the second time. • Scenario 6: First loop test fails the first time, but is successful the second time; second loop casting fails the first and second times, but is successful the third time. Again, we used Microsoft Project
22 • Project Management Journal March 2005
2002 to analyze each of these scenarios, and passed the results to Excel. Rather than providing the complete results for each individual scenario as in the Random Event example above,
aj
Pj
dj
a0 a1 a2 a3 a4 a5 a6 a7 a8 a9
--{a0} {a1} {a2} {a1} {a1} {a3} {a4,a5} {a6 ,a7} {a8}
0 6 3 4 5 10 11 8 13 0
Table 6: Loop network: base case
we will instead simply summarize the results in Table 7. Notice, for example, that activities a2,1 and a3,1 (the first occurrence of the prototype production and testing activities) are critical in scenarios 1, 4, and 5, but not in scenarios 2, 3, and 6 (in which both activities have total slack values of 2, 11, and 8, respectively). On the other hand, a4,1 (first occurrence of the casting activity) is exactly the opposite: it is critical in scenarios 2, 3, and 6, but not in scenarios 1, 4, and 5 (where total slack values of that activity are 5, 8, and 1, respectively). Using the probabilities given in Table 7, we can now do the calculation of the expected critical path length: — LCP =0.480(37)+0.288(39)+ (0.120+0.072)(40)+(0.032+0.008) (48)=38.592 We can also calculate the expected criticalities and total slack for each activity over all of the scenarios, as defined earlier. These are given in Table 8. In the base case, the first loop is critical. If the first loop is successful, whether or not the second loop fails once or twice, the second loop is critical. If the first loop fails, it is critical unless the second loop fails twice (a very low-probability event). Notice that the loop nature of this example means that activities 2 and 3 sometimes occur twice, and activity 4 can occur as many as three times. Based on the original data, we can compute the average total time spent
2
Scenario
3
Probability
1
2
3
4
5
6
0.480
0.288
0.032
0.120
0.072
0.008
4
Critical Path Length
5
Activity
37
39
48
40
40
48
6
A0
0
1
0
1
0
1
0
1
0
1
0
1
7
A1
0
1
0
1
0
1
0
1
0
1
0
1
8
A2, 1
0
1
2
0
11
0
0
1
0
1
8
0
9
A3, 1
0
1
2
0
11
0
0
1
0
1
8
0
10
A4, 1
5
0
0
1
0
1
8
0
1
0
0
1
11
A5
0
1
2
0
11
0
3
0
3
0
11
0
12
A6
0
1
2
0
11
0
0
1
0
1
8
0
13
A7
0
1
0
1
0
1
3
0
1
0
0
1
14
A8
0
1
0
1
0
1
0
1
0
1
0
1
15
A9
0
1
0
1
0
1
0
1
0
1
0
1
16
A2, 2
0
1
0
1
8
1
17
A3, 2
0
1
0
1
8
0
18
A4, 2
1
0
0
1
19
A4, 3
0
1
Total Slack Criticality Total Slack Criticality Total Slack Criticality Total Slack Criticality Total Slack Criticality Total Slack Criticality
0
0
0
1
0
1
Table 7: Loop network: calculations for scenarios 1-6
on each of these activities: — d 2 =d2,1+(0.2).d2,2=3+(0.2).1=32 — (d 2,2 =0.2) — d 3 =d3,1+(0.2).d3,2=4+(0.2).2=44 — (d 3,2 =0.4) — d 4 =d4,1+(0.4).d4,2+(0.1).d4,3= 5+(0.4).7+(0.1).9=8.7 — — (d 4,2 =2.8, d 4,3=0.9 )
Prob. Occur
In other words, the total expected time spent on producing prototypes is 3.2 weeks, the total expected time spent on testing prototypes is 4.4 weeks, and the total expected time spent on casting is 8.7 weeks. Using the calculations done for our analysis, we can also calculate figures such as expected early start and late start times (the earliest and latest points in time when the first repetition Exp. Crit.
Exp. Crit. Occur
Exp. TS Occur
of that activity can start, averaged over the scenarios, weighted by their probabilities), as well as early finish and late finish times (the earliest and latest points in time when the last repetition of that activity can finish, averaged over the scenarios, weighted by their probabilities) for each of these loop activities. These calculations were discussed at the end of the Modeling Approach section. — — — ES2,.=6, ES3,.=9, ES4,.=6
3
Activity
4
A0
1
1.000
1
0
5
A1
1
1.000
1
0
6
A2, 1
1
0.672
0.672
0.992
7
A3, 1
1
0.672
0.672
0.992
8
A4, 1
1
0.328
0328
3.432
9
A5
1
0.480
0.48
1.592
10
A6
1
0.672
0.672
0.992
— EF4,.=(0.480+0.120).(11)+ (0.288+0.0720).(18)+(0.032+0.008).(27)
11
A7
1
0.808
0.808
0.432
=14.16
12
A8
1
1.000
1
0
13
A9
1
1.000
1
0
14
A2, 2
0.2
0.192
0.96
0.32
15
A3, 2
0.2
0.192
0.96
0.32
16
A4, 2
0.4
0.328
0.82
0.18
17
A, 3
0.04
0.040
1
0
Table 8: Network: probability of occurrence, expected criticalities, and expected total slack for each activity
— EF2,.=(0.480+0.288+0.032).(9)+ (0.120+0.072+0.008).(14)=10.0 — EF3,.=(0.480+0.288+0.032).(13)+ (0.120+0.072+0.008).(16)=13.6
Using analogous calculations, we obtain: — — — LS2,.=6.992, LS3,.=9.992, LS4,.=9.432, — — LF 2, . =10.992, LF3,.=14.592, — and LF4,.=17.592
March 2005 Project Management Journal • 23
d3
d4
Probability
6
3
.6
11
4
.3
11
5
.1
Table 9: Uncertain durations of activities 3 and 4
This means, for example, that the expected earliest time we can start prototype production is 6 weeks into the project, the expected earliest time we can complete all prototype production is 10 weeks into the project, the expected latest time we can start prototype production is just under 7 weeks into the project, and the expected latest time we can complete prototype production is just under 11 weeks into the project. If desired, the actual ES, EF, LS,
(conditional) expected criticalities; therefore, they must be given high priority if they occur. 3. Dependent Activity Durations In this example, we assume that there is a network scenario for every combination of discrete random durations. The basic structure of this example is shown in Figure 6. In this case, there are no activities that occur in some scenarios and not others. The uncertainty lies only in the durations of activities 3, 4,
d5
Probability
8
.8
10
.2
Table 10: Uncertain duration of activity 5
and LF times for each activity in each scenario could also easily be generated and reported in a table, for a more detailed risk analysis. Activities 0, 1, 8, and 9 (a0, a1, a8, and a9, respectively) are always critical,
and 5. These durations are not assumed to be totally independent, as an illustration of a more general case. The durations of activities 3 and 4 are assumed to be dependent, with the probability distribution given in Table 9. For exam-
Scenario
d3
d4
d5
Probability
1
6
3
8
.48
2
6
3
10
.12
3
11
4
8
.24
4
11
4
10
.06
5
11
5
8
.08
6
11
5
10
.02
Table 11: Scenarios for uncertain duration example
due to the structure of the project network. Notice that a4,1 has low expected criticality (both unconditional and conditional) and the highest expected total slack, so it could be given the lowest priority in scheduling. a5 is similar, but not as extreme, so it could be given the second-lowest priority in scheduling. Also, note that any of the repeated activities (i.e., the last four activities in Table 8), if they occur, have very high
24 • Project Management Journal March 2005
ple, the three outcomes/probabilities could correspond to no precipitation, light precipitation, and heavy precipitation. Activities 3 and 4 will be performed at approximately the same time, but activity 3’s duration may just depend on whether or not there is precipitation (e.g., pouring concrete), while activity 4’s duration is more sensitive to the severity of the precipitation. The duration of activity 5 is
assumed to be independent of the combination of values of activities 3 and 4, with the probability distribution given in Table 10. Since the two probability distributions are independent, we have a total of six different possible scenarios, with probabilities given in Table 11. Since this example has six scenarios, like the previous example, Figure 5 also represents the macro-level approach for this problem. From Table 11, we can calculate the expected durations of the three uncertain activities: — d 3 =(0.48+0.12).(6)+(0.24+0.06+ 0.08+0.02).(11)=8.0 — d4 =(0.48+0.12).(3)+(0.24+0.06).(4)+ (0.08+0.02).(5)=3.5 — d5 =(0.48+0.24+0.08).(8)+(0.12+0.06+ 0.02).(10)=8.4 Table 12 shows a summary of the results for each of these scenarios. Now we can do the calculation of the expected critical path length: — LCP =(0.48+0.12).24+(0.24+0.06+ 0.08+0.02).27=25.2 We can also calculate the expected criticalities and total slack for each activity over all of the scenarios, as defined earlier. These are given in Table 13. Activity 3 is critical in all cases where its duration is longest (11), regardless of the duration of activities 4 and 5. Activities 4 and 5 are critical only when activity 3’s duration is shortest (6), and activity 5’s duration is longest (10). Note that, in this example, the conditional expected total slack is also unconditional, since all activities occur in every scenario. Conclusions and Managerial Implications This paper presents an alternate macro-level or scenario approach for modeling and analyzing projects with uncertain networks. This approach is applicable for project schedule risk
2
Scenario
3
Probability
1
2
3
4
5
6
0.480
0.120
0.240
0.060
0.080
0.020
4
Critical Path Length
5
Activity
24
24
27
27
27
27
6
A0
0
1
0
1
0
1
0
1
0
1
0
1
7
A1
0
1
0
1
0
1
0
1
0
1
0
1
8
A2
2
0
0
1
0
1
0
1
0
1
0
1
9
A3
2
0
2
0
0
1
0
1
0
1
0
1
10
A4
2
0
0
1
4
0
2
0
3
0
1
0
11
A5
2
0
0
1
4
0
2
0
3
0
1
0
12
A6
0
1
0
1
3
0
3
0
3
0
3
0
13
A7
0
1
0
1
0
1
0
1
0
1
0
1
14
A8
0
1
0
1
0
1
0
1
0
1
0
1
15
A9
0
1
0
1
0
1
0
1
0
1
0
1
Total Slack Criticality Total Slack Criticality Total Slack Criticality Total Slack Criticality Total Slack Criticality Total Slack Criticality
Table 12: Uncertain activity durations network: calculations for scenarios 1 - 6
analysis and contingency planning. During the project planning process, a series of project network scenarios can be identified, each with an assessed probability of occurrence. These scenarios might differ according to the results of uncertain events that could Exp. Crit.
and conditional activity criticality and slack, as well as aggregated expected durations, and early and late start and finish times for repeated activities resulting from looping or stochastic branching. A second benefit is greater accessibility and likelihood of the use
3
Activity
4
A0
5
A1
1
1
0
6
A2
0.52
0.52
0.96
7
A3
0.4
0.4
1.2
8
A4
0.12
0.12
2.3
9
A5
0.12
0.12
2.3
10
A6
0.6
0.6
1.2
11
A7
1
1
0
12
A8
1
1
0
13
A9
1
1
0
1
Exp. Crit. Occur
Exp. TS Occur
1
0
Table 13: Uncertain activity durations network: overall expected criticalities and total slack for each activity
occur during the course of the project, uncertain (possibly dependent) activity durations, finite loops, or any combination of these three. We have presented a scenario approach for modeling and analyzing these uncertain project situations. An advantage of our approach is that it generalizes standard project network analysis methods, such as critical path analysis, to the network scenario level. Our approach also leads to the development of new project network uncertainty measures, including expected
of uncertainty analysis in project planning, since the modest data needs and straightforward analysis are focused on key scenarios driving schedule uncertainty. Examples were presented to illustrate the approach, including random events, loops, and dependent random activity times. The scenario method proposed here is a direct extension of existing project scheduling procedures, and uses software and techniques familiar to (and easily accessible by) almost all project managers. This approach pro-
vides exact results, as well as simplicity, and offers advantages in analyzing and interpreting the impact of uncertainty, especially when the number of critical uncertainties is relatively small. The proposed approach can handle uncertain activity durations and finite loops with varying durations for each repetition, allows the durations of activities to be dependent upon others, and provides the ability to summarize critical path analysis information about repeated and uncertain activities. For these reasons, we believe that our approach is more manageable and comprehensive than existing methods for project managers analyzing the effects of uncertainty on their project schedule. References and Notes Malcolm, D. G., Rosenboom, J. H., Clark, C. E., & Fazar, W. (1959). Application of a technique for research and development project evaluation. Operations Research, 7(5), 646-669. Neumann, K. (1990). Stochastic project networks: Temporal analysis, scheduling, and cost minimization. Berlin: Springer-Verlag. Pollack-Johnson, B., & Liberatore, M. J. (2003). Analytical techniques in project planning and control: Current practice and future research directions. Unpublished manuscript, Villanova, PA: Villanova University, Department of Decision and Information Technologies.
March 2005 Project Management Journal • 25
Pritsker, A. A. B., & Happ, W. W. (1966). GERT: Graphical evaluation and review technique — part 1. Fundamentals. Journal of Industrial Engineering, 17, 267-274. Pritsker, A. A. B., & O’Reilly, J. J. (1999). Simulation with Visual SLAM and AweSim, New York: John Wiley & Sons. Project Management Institute. (2000). A guide to the project manage-
ment body of knowledge (PMBOK® guide). Newtown Square, PA: Author. Project Management Institute. (1999). Project management software survey. Newtown Square, PA: Author. Wiest, J. D., & Levy, F. K. (1977). A management guide to PERT/CPM with GERT/PDM/DCPM and other networks (2nd ed.). Englewood Cliffs, NJ: Prentice-Hall.
1 For details about any of the Microsoft Project or Excel calculations performed in this article, please contact the authors. 2 These could also be made dependent using the proposed approach, as the third example demonstrates.
BRUCE POLLACK-JOHNSON earned a BA in sociology with a minor in education from Brandeis University, an MA in Applied Mathematics from Temple University, and an MS and PhD in Operations Research from the University of Pennsylvania. He has taught at Oberlin College, and is currently an Associate Professor of Mathematical Sciences at Villanova University. He has published dozens of papers on project management, forecasting, educational modeling, and on teaching applied mathematics, as well as a two-volume text on business calculus and finite mathematics (partially funded by grants from FIPSE, NSF, and Prentice Hall). His current research is on modeling uncertainty in project scheduling. He is a member of INFORMS and MAA.
MATTHEW J. LIBERATORE, PhD, is the John F. Connelly Chair in Management and Professor of Decision and Information Technologies at Villanova University. He previously served as Chair of the Department of Management and as Associate Dean. Dr. Liberatore has published over sixty journal articles in the fields of project management, management science, information systems, and research and engineering management. He recently co-authored a text, Decision Technology: Modeling, Software, and Applications, published by Wiley. Dr. Liberatore serves on the editorial boards of the American Journal of Mathematical and Management Sciences and IEEE Transactions on Engineering Management. He is a member of PMI, INFORMS, and the Decision Sciences Institute.
26 • Project Management Journal March 2005
Related Documents
Scenario Analysis
July 2020 4
Budget Scenario Analysis
November 2019 4
Scenario Analysis Assignment
April 2020 8
Scenario
October 2019 65
Scenario
October 2019 70