Critical Path Analysis – Critical path analysis needs further discussion because of issues that have emerged in modern complex projects. Modern software scheduling tools automatically determine and show the critical path for a project schedule. However, it is not good practice to just accept the first result for a complex project.
The simple example schedule discussed in the previous sections is a deterministic schedule; each task has a planned duration, a predecessor task and a successor task. Therefore there is a deterministic critical path. It should be obvious that the time estimate for each task has a probability associated with it. That is, there is some probability that the task will be completed in the time estimated. Therefore there is also a probability that an overall project will be completed in the time estimated by summing the times for the tasks on the critical path. Unfortunately project schedules are sometimes treated by project leaders, managers and customers as though the schedule is deterministic and any overrun in schedule is the result of poor management rather than the result of real world variation due to probabilistic time estimates. Likewise the team management is given credit for excellent management should the project come in ahead of schedule due to the same variation phenomena. Of course there is usually some truth in assigning credit or blame to the project leaders because they have numerous tools for managing a project in order to maintain schedule in spite of variations in the time to complete individual tasks. However, using probabilistic time estimates in PERT scheduling, or the alternative recommended in Glen B. Alleman’s blog cited in the section on developing schedules, gives both the project leaders and those overseeing the projects a much better feel for the likelihood that the project will complete by a certain date.
Probabilistic time estimates are achieved by estimating an optimistic time, a pessimistic time and a most likely time for completing each task. The expected task duration is then defined as the mean of the distribution defined by the three estimates and is between the most likely and the pessimistic times for a beta distribution used in the standard probabilistic approach. One might expect that the critical path is the sum of tasks with zero slack in the resulting network using expected durations. But since there is a variance for each task estimate there is also a variance for the critical path schedule and therefore a probability associated with completing the project by any number of days less or more than the expected total. Since all tasks have a time to completion variance there is also probability that some path other than the most probable critical path becomes the critical path. Thus to get the most accurate probabilistic estimate of overall schedule it is necessary to analyze all paths and the probability that the project will complete by a certain date is actually the probability that all paths will complete by that date. Alternately simulations considering all paths can be carried out. A shortcut to analyzing all paths may be useful for some projects.
Consider the example of projects for developing systems with hardware and embedded software. There are often several candidates for the critical path in the early part of such projects. This is in contrast to complex projects in the past without embedded software. In the past there was typically some long lead part or assembly that drove the overall schedule so that the critical path usually turned out to be driven by the design and procurement of this long lead item. Modern digital electronics enable systems with complex data acquisition and analysis. Such systems often have special purpose digital circuits with embedded software involved in the acquisition and processing of data. The digital circuit design is usually a relatively high risk task so the designers want to build and test breadboard circuits as soon as possible so that designs can be refined and risk reduced before integrating these circuits with the overall electronics. However, these circuits require embedded software for carrying out their intended functions. Systems engineering must develop specifications for both the digital hardware and for the software. If the scheduling is done in the usual way these tasks end up driving the overall schedule in unsatisfactory ways. Managers may become confused if they expect the usual long lead parts to be driving the critical path, not risk reduction tasks.
To get estimates for scheduling the digital electronics and software tasks so that the risk reduction tasks aren’t on the critical path it is necessary to get the digital designers, the software engineers and the systems engineers to sit down together and work out plans to make these tasks fit together and complete as early as possible. Even with the best efforts of the engineers the resulting schedules often end up with digital electronics, embedded software and some long lead parts all having paths with zero or near zero slack. This says that it’s not possible to accurately tell which will end up the true critical path because of the variance in the time for each path is larger than the difference in slack. A way to handle such scheduling problems is to calculate the expected duration of each of these potential critical paths. It’s not necessary to calculate the expected duration for all paths on such projects because it is highly likely that these few paths with near equal durations drive the critical path. Determining the expected duration for each of these few paths also helps convince managers that the scheduling is sound even if their assumed critical path turns out to be not the most likely critical path.
The situation described for complex systems having special purpose digital electronics and embedded software seems likely to occur in other types of complex projects. If an organization is using deterministic schedules and is faced with a project schedule that has several paths with zero or near zero slack it is recommended to use probabilistic time estimates and to calculate the expected duration for the several candidate critical paths. It likely isn’t necessary to expend the effort and cost to calculate the expected durations for all paths. If an organization uses probabilistic scheduling routinely then spend the effort to involve all the personnel on the tasks that are candidates for the critical path so that they reach an understanding of the relationships of each other’s tasks and explore approaches to workarounds that may shorten schedules as well as result in a better estimate of the true critical path.
No comments:
Post a Comment