I HAVE THE GOOD FORTUNE of conducting a large number of Project Mentors’ project management Tools and Techniques classes at high-tech companies. While these companies differ substantially in the nature and scope of their products and in their cultures, one of the common themes I have noticed is the difficulty in estimating both effort and duration for “bleeding edge,” unprecedented tasks. Since manual and low-end project management software products routinely rely on single-point estimates to generate the critical path, schedules developed with these tools rarely reflect reality While using single-point CPM techniques is essential at the fundamental level, some more advanced techniques may be required to give the project manager a more realistic project plan. This article illustrates how using the Microsoft Project add-in product, Risk+ by PMSI, can give a project planner important information to consider.
Let's take a simplified software development project. The Gantt chart in Exhibit 1 shows that the project will last about one year, and that the critical path (indicated with the diagonal lines in the task bars) consists of tasks A1, B1, C3, D3, E1, and E2. Tasks C1, D1, C2, and D2 are non-critical and have slack, as indicated by the small line extending from the right side of each task bar.
Using single-point CPM calculations, we can determine the project end date, the critical path, the start and end dates of each task, and the amount of slack on the noncritical paths. All of this information is useful only if our ability to estimate is accurate, and only if we have a uniformly high degree of confidence in the overall schedule. But what happens if we believe that some tasks are riskier than others? How do we handle different probabilities of completing tasks as scheduled? How do we accommodate the greater risk associated with “merge bias,” the increasing uncertainty associated with a task that has multiple predecessors?
Here's a suggested four-step approach to answer these questions:
First, determine an overall “minus and plus range” for the entire project. In other words, consider establishing a “best case” and and a “worse case” for all the tasks. On this project, we might say, “Best case is that we finish 5 percent sooner than our estimated duration on each task, and worst case is that we finish 5 percent later than our estimated duration on each task.” The estimated duration is the single point estimate known as Most Likely. We'll call this minus 5 percent/plus 5 percent variance the norm for this project. For schedule calculations, Risk+ calls the best case “Risk Minimum Duration” and the worst case “Risk Maximum Duration.” Risk+ allows you to specify either percentages or units of time for these calculations.
Second, identify individual tasks that vary from this project norm. We can assign individual best case-worst case ranges to each individual task, or we can select a group of tasks to assign a best case–worst case range that differs from the norm. For unfamiliar, unprecedented tasks associated with developing new technology, we would assign a higher degree of risk. In our example, we'll pretend that the noncritical tasks—C1, D1, C2, and D2—are new tasks representing work we've never done before. After doing our research and comparing the deliverables with arguably similar deliverables from earlier projects, we developed a rough (“most likely”) estimate of the duration for each task. Because our confidence level in these estimates is lower than from the rest of project, we can assign a higher degree of risk. For this group, we'll say that best case is minus 2 percent and worst case is plus 35 percent. (Risk+ allows you to specify the pattern of distribution for any set of tasks in the project, but this is beyond the scope of this article.)
Third, run a set of Monte Carlo simulations of the project. After we finishing assigning best case–worst case ranges for all the tasks, we can run a designated number of simulations of the project. For example, we can direct Risk+ to simulate this project 300 times; Risk+ will randomly assign task durations within the ranges and the distribution patterns we specified 300 times. At the conclusion, it will display the Earliest project end date (the earliest completion date occurring during the simulation), an Expected project duration, and the Latest project end date (the latest completion date generated by the simulation). The Expected date is not the most probable, it is simply the number before which 50 percent of the end dates occurred and after which 50 percent of the end dates occurred.
Exhibit 1. This simple CPM chart gives enough information to calculate the project end date, the critical path, and the start and end dates of each task—IF the estimator was competent, and IF the data that the overall schedule is based on can be relied upon.
In Exhibit 2 we see that the Earliest completion date is 2/25/98, the Expected date is 3/11/98, and the Latest is 4/10/98. These numbers are revealing: First, the current CPM most likely end date of 3/4/98 (from Exhibit 1) is a full week earlier than the Expected end date, which means that the project has less than a 50 percent chance of finishing by its currently scheduled end date. Second, if everything went swimmingly, we could finish as early as 2/25, but only a fool would promise this delivery date, as the likelihood of meeting it is virtually zero. Third, if everything imaginable goes wrong, we could finish as late as 4/10, but that's pretty unlikely. Clearly, the most probable project end date lies somewhere between 3/11 and 4/10. If we specified a “normal distribution,” the standard deviation of 5.8 days indicates that 68 percent of the projects finished 5.8 days either side of 3/11, and 95 percent of the simulated projects finished within 11.6 days either side of 3/11.
Fourth, evaluate the “percentage on the critical path” figures and adjust the task duration. One of the most useful calculations performed by Risk+ is the “percentage on the critical path” calculation. Exhibit 3 shows that in our example, path C3-D3, originally on the CPM-determined critical path, turned out to fall on the critical path in only 30 percent of the simulations! In other words, there is a much greater likelihood that other paths in this project will end up determining the ultimate end date. In this case, path C2-D2 has the highest likelihood of determining the project end date. With this knowledge in hand, we can make manual adjustments to the high-risk paths. Exhibit 3 shows the project after we have manually adjusted the Duration field for the high-risk tasks. The new durations now create a new critical path and a new project end date of 4/1/98 (April Fool's Day).
Is 4/1/98 the most likely project end date? Probably not. Is it more likely than 3/4/98? I’d say so. Notice that task C2 is scheduled to take only three days less than its worst case. Maybe that's too pessimistic. As a project manager, I could be persuaded to adjust the estimate, given a strong argument. In the absence of such argument, I have a lot more confidence in a 4/1 delivery date than I do in a 3/4 delivery date, and I have a much clearer picture of the tasks that are ultimately responsible for determining the end date. That means that my control efforts are more likely to be spent on the right group of tasks.
Exhibit 2. After simulating the project 300 times, Risk+ determined that the earliest possible end date for the project is 2/25/98, the latest possible end date is 4/10/98, and the most likely end date is 3/11/98. “Most likely” means that 150 end dates occurred before 3/11/98, and 150 end dates occurred after 3/11/98. It is one full week later than the original 3/4/98 end date shown in Exhibit 1. The CPM date of 3/4/98 has less than a 50 percent chance of occurring.
Exhibit 3. This Gantt chart shows that after 300 simulations, the original critical path segment C3-D3 ended up on the critical path in only 30 percent of the simulations. The chart also shows a new end date of 4/1/98 after manually adding duration to Tasks C2 and D2 to accommodate the lower degree of certainty/higher risk assigned to these tasks. The 4/1/98 end date projection may be too pessimistic, but seems far more likely than the original 3/4/98 CPM end date.
FOR A MORE DETAILED look at schedule risk, see David Hulett's two articles, “Schedule Risk Analysis Simplified” in PM Network, July 1996, and “Project Schedule Risk Assessment” in Project Management Journal,March 1995. ■