Abstract: A project is a combination of interrelated activities that must be performed in certain order of its completion. To cut development cost and meet tight deadlines in software projects, managers need to understand some key reservations about the standard Scheduling methods and how to use a schedule risk analysis to provide information crucial to a project’s success, before they embark on their project. This study deals with benefit of conducting schedule risk analysis on a project. Three case studies, using simple schedule of two activities or four activities on parallel paths, are represented in this research. It is shown that such risk analysis has the potential of providing key information for project managers in advance so that risk mitigation plans can be developed and implemented in time.
INTRODUCTION
To cut development cost and meet tight deadlines in short staffed software projects, managers must optimize the project schedule. Scheduling a software project is extremely difficult as the time needed to complete a software development activity is hard to estimate. Process simulation is an important technique to evaluate the impact of proposed changes (Kellner et al., 1999) in the process. System dynamics simulations have been around for years, some of them addressing the problem of project staffing (Abdel, 1991; Collofello et al., 1998) and show how to use process simulation to support software project managers in scheduling (Neumann, 1990; Padberg, 2002 a, b).
The critical path method of scheduling a project is a key tool for project management. A schedule network represents the project strategy. Activities, where the work is accomplished, are linked by relationships (e.g., finish-start, start-start, finish-to-finish) showing how the work is planned. In face of uncertainties in activity duration, one attempts to obtain best possible estimate. This paper deals with key constraints of project scheduling and benefits of conducting schedule risk analysis on a project. Three case studies, using simple schedule of two activities or four activities on parallel paths, are presented in this paper. Through these, it is shown that such risk analysis has the potential of providing key information for project managers in advance so that risk mitigation plans can be developed and implemented.
PARALLEL PATHS AND MERGE BIAS
Strings of linked predecessor and successor activities constitute paths through the network. When two or more paths are to be done simultaneously, they are described as parallel paths.
Some of the most important points in the project are where several parallel paths converge (Karolak, 1996). At these merge or join points, the paths must all be completed before a milestone is recorded ab achieved. An inspection can be done, sub-assemblies can be integrated for testing or the project can be recorded as complete.
Critical path method computes the shortest project completion duration and or completion date from the longest path through the network. The longest pole in the tent is called the critical path. Any delay on the critical path will delay the project. Conversely, critical path method shows that paths that are not critical can be delayed or lengthened, if they have enough float or scheduling flexibility, without necessarily delaying the project.
On the one hand, the critical path method of scheduling is traditional and well-accepted. It is essential for developing the logic of the project work and for managing the day-to-day project activities.
On the other hand, the critical path method schedule is only accurate if every activity is started as soon as possible and takes just as long as its duration estimate indicates. Project managers understand that projects do not ever go entirely according to plan, which is one reason for frequent status reviews (Capers, 1998). Since real projects do not work this way, critical path method is just the beginning of project schedule management.
SOME KEY CONSTRAINTS OF PROJECT SCHEDULING
Project managers need to understand some key Constraints about the standard critical path method and how to use a schedule risk analysis to provide information crucial to a project’s success, before they embark on their project:
| • | The project duration calculated by critical path method is accurate only if everything goes according to plan. This is rare in real projects. |
| • | In many cases the completion dates critical path method produces are unrealistically optimistic and highly likely to be overrun, even if the schedule logic and duration estimates are accurately implemented. |
| • | The critical path method completion date is not even the most likely project completion date, in almost all cases. |
| • | The path identified as the critical path using traditional critical path method techniques may not be the one that will be most likely to delay the project and which may need management attention. |
SCHEDULE RISK ANALYSIS
To help achieve this goal, three case studies are presented in this study. Using simple schedules of two activities or four activities on two parallel paths, these case studies show both the pitfalls of relying on critical path method and the benefits of a schedule risk analysis.
These case studies show that it may not be feasible to complete even simple projects by their critical path method -determined date, given risk characteristics that are similar to those often found in real, everyday projects. critical path method does not identify these overrun problems very well, or at all. In fact, critical path method shows that the project will finish on a certain date. If critical path method does not work well in such simple projects and the problems are multiplied many times for the complex projects facing project managers every day, the benefits of conducting a risk analysis on every project become obvious.
Case 1-two activity project scheduling: The three steps to a successful risk analysis are described. They are:
| 1 | create the critical path method schedule for the project, |
| 2 | estimate the uncertainty in the activity durations and |
| 3 | perform a risk analysis of the schedule, usually with a Pert Simulation method (Kellner et al., 1999). |
Critical path method schedule-the foundation of a risk analysis: Critical path method analysis of the project schedule is the key building block of a quantified risk assessment. Case 1 presents a very simple project and a typical schedule risk analysis. It illustrates how the critical path method completion date can easily be overrun. It shows how a risk analysis can illuminate the issues in critical path method and point to their resolution. For the first step, a project with two activities and a finish milestone is used.
Suppose the durations are set at 50 working days for A1 and 80 working days for A2. Suppose, further, that this project is scheduled to start on July 10, 2006. critical path method shows that this simple project will take 130 working days (50+80 = 130) for completion.
There are several considerations in developing a successful risk analysis network. For a risk analysis to be successful the critical path method network should be developed at a level of detail that shows the important project structure, i.e. the parallel paths and key merge points where the risk is often increased. There are three features to watch for in determining the correct level of a schedule:
| • | First, the network should not be developed at too high a level of detail, for instance at a level where most of the activities summarize important underlying detail. Summary activities are often characterized by start-to-start or finish-to-finish relationships. |
| • | Second, the schedule should show clearly the parallel paths that could cause the project to be late if not coordinated. Case 2 below shows the merge bias that occurs when parallel paths converge. |
| • | Third, the network should not be developed in such great detail that it requires too much information, since that would be unworkable and overly burdensome. |
When building the risk analysis network, the temptation is to schedule only those paths assessed as the longest poles in the tent. This is a dangerous practice that should be avoided. It is best to show more paths rather than fewer, since the shorter poles might actually have more risk than the long poles identified by critical path method. Case 3, below shows that a shorter path with more risk can actually be the highest risk path, i.e., the path most likely to actually delay the project. If shorter paths are not included in the network to begin with, their risk might not be explored at all.
If there are scarce resources that make scheduling some activities in parallel infeasible, they ought to be identified and included in the schedule risk analysis. If constraints are included in the critical path method network, however, these must be deleted in the risk analysis.
Determine the activity duration ranges: The activity durations that are used to calculate the critical path are often thought of as the best guess or most likely amount of time needed to complete the work given the planned resources. Experienced project managers know that the work might take more or less time than the estimate they have assumed for the critical path method calculation. These times make up the low and high ranges for a risk analysis.
Duration ranges for each activity are the low (optimistic) and high (pessimistic) durations that the work on the activity might take under different possible extreme scenarios. High ranges, for instance, can be determined by examining the various things that could go wrong i.e., Factors which are often called risk drivers.
Risk drivers are identified and explored in interviews with the managers or team leaders of the project’s activities who are the most knowledgeable people on risk in the work under their management and control (Jones, 1998). They are most familiar with the risk issues in each activity and can best assess their impact on the possible duration of each activity. Experienced guidance is often needed to develop the duration ranges.
The risk interview starts with a description of what could go wrong with the work in an activity. It then turns to the likelihood of that scenario and how long the activity might take if everything goes wrong. This duration is the high-range duration for that activity. A serious and honest airing of the issues involved in doing an activity will soon uncover possible, though perhaps unlikely, pessimistic scenarios.
Conversely, exploring with the managers what could go right should yield an optimistic scenario and the low estimate of duration for each activity. Sometimes, with aggressive or success-oriented schedule estimation, the critical path method duration for many activities are already the shortest possible durations conceivable.
Often the critical path method duration is viewed as the most likely duration for most of the activities in the project. This may not be true, however. The risk analyst should, with the project manager, seek to describe the most likely scenario and determine if the critical path method duration, or some other duration, will accommodate it.
There may be problems in collecting data about project schedule risk. For instance, project managers may be reluctant to commit their activity managers time to develop the information needed for a risk analysis, since they are the very people who are most busy managing the project itself. Alternatively, some project managers avoid examining risk at all because it poses difficult issues, highlights bad news, exposes embarrassing problems or raises issues that would have to be disclosed to the owner or customer.
Even if a project manager wants to explore risk honestly, it is often challenging to develop realistic ranges, particularly for unlikely but possible extreme events. But, gathering duration range data has the major benefit of making everyone aware of the problems facing the project. A risk analysis usually reveals important problems that had not been appreciated or communicated fully before the gathering of the duration range data.
Sometimes projects have many activities, perhaps thousands. How should the ranges be developed for such a large project In this case, risk banding is often used. The project manager organizes the activities into groups with common risk characteristics. For each of these risk types the low and high duration ranges would be expressed in percentages, e.g., minus 15%, plus 25%, from the critical path method duration. With large networks there is little alternative but to use critical path method durations as the most likely in the activity distributions.
Once the ranges, often called 3-point estimates, are determined, the project manager must adopt a probability distribution shape for each risky activity. A probability distribution takes the three possible durations (low, most likely and high) and expresses the relative likelihood of alternative outcomes within that overall range. That is, there are some possible duration which are more likely than others.
Simulate the project schedule: Once the activities duration ranges and distributions have been determined, the schedule risk analysis can determine how risky the entire project schedule is. The most common method of determining schedule overrun risk is to simulate the project by solving (or iterating) it hundreds or thousands of times on the computer.
The simulation results for Case 1, for instance, will answer such important project management questions as:
| • | Is the completion date estimate reasonable? |
| • | Is date estimated even the most likely duration of this simple project? |
| • | How many days are needed for a contingency to reduce the overrun risk exposure to an acceptable level? |
The method, usually used is called Pert Simulation, has several steps:
| • | Every iteration begins by selecting duration for each risky activity at random from its range and distribution. for generating random numbers Box Muller Transformation is used |
| • | The total project and key milestone completion dates for that iteration are calculated using critical path method for that particular configuration of durations. Those are only possible dates for completion of the project and its milestones and they may not be representative of all possible solutions. |
| • | To determine the entire pattern of possible completion dates for the project and its important milestones, the risk analyst iterates the project many times. At the end of every iteration, the completion dates for the total project and for any important milestone are collected and stored. The program also records which activities were on the critical path for that iteration. |
| • | At the end of the entire simulation, project completion and important milestone dates computed from all iterations are collected and arrayed in graphs and tables showing the probability distribution, or relative frequency, of all possible dates. |
Suppose that the risk analyst examining Case 1 determines that 2, 500 iterations will be sufficient for the accuracy needed. The result of that simulation is a cumulative likelihood distribution that represents the likelihood of the project completing on or before each possible date.
This distribution is shown in Fig. 1.
Figure 1 includes a likelihood distribution (bell-curve).
| • | Placing confidence in completion by December 11 is very likely to get the contractor and customer in trouble. |
| Fig. 1: | Two activity project scheduling |
| • | A look at the bell-shaped distribution reveals that the most likely completion date is close to December 24, not December 11. If this simple project were done 500 times, its average completion would be a about a 2-week overrun of the critical path method duration, providing for the holidays. |
| • | Critical path method clearly establishes December 11 as the project end-date. Just as clearly, the risk analysis establishes that December 11 is highly optimistic. Any owner/customer or contractor that agrees to that date is in trouble now on this project. Without a risk analysis, the existence or degree of trouble is unknown. |
Two issues common to scheduling should be resolved before the simulation is begun. These are the handling of constraint dates and limited resource requirements.
The first issue is the treatment of constraint dates such as not later than or must finish on dates. Constraints are often implemented in the critical path method schedule to represent key dates contained in a contract or some other requirement. Constraints are used to highlight key contract dates because these dates must be met or the project is in trouble.
Constraint dates have no place in a risk analysis, however. One main goal of a risk analysis to determine whether the important contract dates, those established in the network with constraint dates, are in jeopardy. If constraint dates were implemented in the simulation, every iteration would be forced to meet those dates. Simulation with constraints operating during each iteration cannot possibly investigate the feasibility of meeting the dates because success is enforced. Constraints must be taken off the schedule before doing a risk analysis because they invalidate a risk analysis.
The second issue is the treatment of limited resources. If several activities using the same resource are potentially scheduled at the same time, they may require more of that resource than is available. Resource leveling in critical path method pushes one or another resource-using activity out in time so that a resource’s usage does not exceed its availability in any time period.
Because each solution in a risk analysis must at least be feasible, it should not violate any resource limitations that exist. Each iteration must be resource-leveled if some resource(s) is (are) limited. The risk analysis software package should be able to level resources as it is, iterating. This increases run time substantially.
The three steps of a schedule risk analysis can be used in more complicated cases than Case 1. For instance, most projects have activities planned simultaneously along parallel paths. At the end of the project and often at important internal milestones, these paths converge.
At path convergence (or merge) points, projects can be delayed if the probability distributions of the converging paths’ durations overlap because a delay on any one of the paths will delay the work.
Of course, some merge points have several paths converging and the opportunity for delay at such points is thus magnified. Clearly, path merge points can never be good news for a risk analysis. The increase in project risk at merge points, called the merge bias, is the subject of Case 2.
Case 2: project network with parallel paths: In Case 2, a simple parallel path project is assumed (four activities). Suppose, B1 is exactly like A1 and B2 is exactly like A2 in all respects. critical path method durations and their low and high ranges, as illustrated in case 1.
The critical path method result for this schedule is exactly the same as for Case 1; 130 working days to a completion date scheduled at December 11. Both Path A and Path B are identified as critical paths by critical path method.
A project with parallel paths like Case 2 is almost always more likely to be overrun than the simple single-path schedule such as that in Case 1. The cause of this pessimistic result is the merge bias which has been known for some 25 years.
| Fig. 2: | Parallel Path (four activity) project Scheduling |
The distribution of possible completion dates from a Pert Simulation of Case 2, shown in Fig. 2, reflects the impact of the merge bias:
| • | The critical path method date, which is still December 11, is now not even 5% likely to occur. |
| • | This project has an average or expected overrun of 2 calendar weeks from the critical path method estimate. |
| • | The conservative company requiring an 80% likelihood of success now requires a Shift in completion date. |
The critical path method schedule did not reveal these problems at all. Even with parallel critical paths, the critical path method analysis forecasted the same completion date of December 11 in both cases. The risk analysis showed that the risk of overrun and necessary schedule contingency were materially higher in Case 2 over those in Case 1.
This study has shown that two simple projects, one with 2-activities and another with 4-activities on 2 parallel paths, can be in trouble. It follows that real projects, which are infinitely more complex, are even more likely to be infeasible because they have more parallel paths and merge points. A risk analysis identifies and quantifies the difficulties faced by the project manager.
Case 3: risk management and the highest risk path: Suppose the project manager who received these risk analysis results took steps to mitigate the risk forecasted in Case 2, above. Several steps might be taken.
First, the project manager might reduce the risk in activities A1 and A2, perhaps through different strategies, e.g., buy rather than make a tricky component or utilize a different supplier thought to be more reliable.
Second, the project manager could shorten the duration of activity B1 by 5 days, to 45 working days, perhaps by adding a second shift to part of the work.
Experienced schedulers will recognize that shortening activity B1 makes Path B a near-critical path which has critical path method duration of 125 days and a float of 5 working days.
| Fig. 3: | Risk abatement project scheduling |
Path A is now the only critical path with a total critical path method duration of 130 working days. The completion date is still scheduled for December 11.
But, is Path A the most likely to delay the project? Is it the highest risk path? A risk analysis is now required not only to estimate the possible durations of this project after risk management but also to identify the highest risk path.
As mentioned above, the simulation software identifies which activities are on the critical path for each iteration. At the end of the simulation, the percentage of the iterations in which the activities were critical indicates the relative likelihood that delays in their completion will delay the project, their relative criticality.
In Case 3, path A may be the critical path using critical path method durations, but that is not the end of the story. The results indicate that Path B is the highest risk path, the one with the greatest likelihood to delay the project.
Figure 3 shows that the risk management actions have reduced the risk of the total project. The average completion time was more as in Case 2 before risk management.
Will the project complete on time after these risk management actions? The critical path method date of December 11 is still less than 5% likely and further risk management steps are needed to reduce the risk to an acceptable level. Those steps might most profitably be applied to Path B, the highest risk path, at this time. Certainly, the project manager should look closely at the progress in B1 and B2 for those are high-risk activities.
CONCLUSIONS
The simple examples shown above highlight the benefits of risk assessment and the pitfalls of relying on a critical path method analysis alone. Some of these benefits are: (1) finding out how likely the critical path method completion date is, (2) determining the contingency needed to reduce the overrun risk to an acceptable level, (3) identifying the highest risk path for project risk management and (4) evaluating the effect of risk management actions.
The risk analysis has the potential of providing key information for project managers in advance so that risk mitigation plans can be developed and implemented now. The experience with risk analysis shows also that developing the data and reviewing the results enables the participants to understand and to manage their project better.
There is risk in every project. Ignoring risk doesn’t make it go away. A three-step schedule risk analysis should be conducted for every important project.