Risk-based scheduling and analysis
by Chris Weiler
HAVEYOU EVER been assigned to a project that missed its deadline? Ever wished you could do a better job estimating task durations or wonder if the critical path you are so carefully managing really is the critical path? Have the overall risk and uncertainty inherent in your projects substantially increased over the last several years? Ever wish you had some tools to identify and focus your management's attention on the high-risk components of your project?
In software development, the industry trends of joint ventures, partnering, and relying on third-party components have greatly exacerbated the already difficult tasks of task duration estimation, plan development and risk management. Industry studies indicate that over 80 percent of software development projects exceed their scheduled time. While there are certainly a number of contributing factors, problems with creating the initial development schedule often start projects under a handicap from which many never recover. Even worse, project schedules that are unrealistic can foster poor morale on the part of the development team since almost any result they can produce will be considered a failure.
As if that weren't enough, project managers are engaged in a constant tug-of-war with their customers and senior management when it comes to setting project completion dates. Experienced project managers often have an intuitive “feel” for how much contingency time should be included in a schedule but are often unable to communicate that “feel” to management; therefore, the pressure to squeeze another 10 percent from any schedule is intense, unrelenting and often persuasive. If the project subsequently misses its “aggressive” date, the project manager is further castigated for ineffective management; any prior protests against compressing the schedule are forgotten. So how does one not only measure and account for the inevitable risks to schedule, but also communicate that information in a way that management can understand?
Exhibit 1. Each task is assigned a number from 1 to 5 that determines the spread of best and worst case duration for each task. The assignment of best and worst case range values was not done in a scientific, statistically valid manner, but there was some historical precedent. They were based on actuals from three previously completed projects. This exhibit shows an example of case durations for a single task with an expected duration of 10 days.
The Risk-Based Scheduling and Analysis (RBSA) system described in this article is a powerful yet easy to use system for identifying risk at the individual task level, adjusting the project schedule to account for that risk and identifying the real critical path based on the risk-adjusted schedule. It also helps focus management attention on project risk, both by task and collectively over time. The system uses Microsoft Project and Microsoft Excel, popular tools available to nearly everyone with access to a personal computer.
The Pros and Cons of PERT. One of the techniques for measuring and accounting for risk in a schedule is the Program Evaluation and Review Technique (PERT). Developed by the U.S. Navy in 1958, PERT is most useful on projects with substantial uncertainty. The power of PERT comes with a price tag, however—principally the time and effort required to complete the estimating models. Because of this it is generally used only when project offices and scheduling experts are available and has not been widely used in software development projects.
PERT combines the relationships and dependencies of Critical Path Method (CPM) charts (including those which many commercial scheduling packages refer to as “PERT”) with the additional power of measuring and allowing for the variability of task durations, even distinguishing between two tasks that may have the same duration but different risks. Often you do not have sufficient historical information to even determine the “average” duration for a task or you have outside dependencies, such as the delivery of customized third-party software, over which you have little or no control.
To account for these uncertainties, PERT measures the variability of task durations by defining “Best Case” and “Worst Case” task durations in addition to the “Expected Case” (generally the average). The best and worst case durations are defined as the durations for which there is only a 1 percent likelihood that the actual duration could be better or worse. Once the best, worst and expected case durations are defined for each task, PERT calculates the weighted average duration and variance for each task, and totals these values for all tasks on the critical path. Using a normal distribution function table, the probability for actually completing the schedule within the expected case durations is determined. The same tables can then be used to determine the overall project duration for any desired probability value.
While this technique is powerful, it is also cumbersome and complex. Determining the best and worst case durations for every task in a project of any size takes considerable time and effort and it is always difficult to find the time and enforce the discipline required to define those cases. So how do we get the benefits of PERT while reducing the overhead and using popularly available tools? Commercially available tools such as Primavera and others help manage the complexity, but there is still the time required to enter all the information. In addition, a project manager needs tools to help identify and manage those particular sections of projects that are higher risk than others. This was my dilemma.
The Risk-Based Scheduling and Analysis System. The RBSA system was initially developed through a convergence of three factors. First, I was given a project management assignment on a large, highly visible project important to the company's competitive situation. I found myself during the Christmas holidays trying to integrate schedules from eight subprojects, accounting for dependencies and relationships. I knew that management would be pressing very hard on improving whatever schedule we came up with and I wanted a means to communicate why the schedule was reasonable, and in fact, already very aggressive. Second, I was taking an operations course in my MBA program and was again studying PERT. Third, it was mid-December and the office was nearly deserted, as everyone was taking holiday vacation. Therefore, I had the time to spend on exploring the application of PERT to this particular project.
I first determined the critical path using a project management package called Auto-PLAN. I adjusted this path slightly so that all the critical path tasks were contained within one subproject. That allowed me to work with the engineer responsible for those tasks and determine the best and worst case durations. I then built a simple spreadsheet using Lotus 1-2-3 to determine the weighted average and total variance for the critical path tasks. Using the normal distribution function table, I determined that the original schedule had less than a 5 percent probability of being successful. Frankly, this did not surprise me as probably less than 5 percent of the projects within the company were actually completed on time.
I then calculated that the project would have to be extended by an additional six weeks to reach a 90 percent probability. I added these six weeks as the last task and called it “Probability Enhancement.” When I presented the schedule to senior management, I took them through a very quick tour of the PERT process employed and specifically pointed out the probability enhancement task. This explanation seemed to satisfy them and they did not further challenge the schedule. I considered this a major success for the process.
While the use of this very simple PERT chart defined the time to be added to the project to create a 90 percent schedule goal, it fell short on some very key points. First, as implemented, the use of PERT only allowed me to add time to the end of the schedule, it did not help adjust the time of individual tasks based on their individual risk. Second, I selected only the critical path as defined by the project management package I was using for the schedule. I was not sure that, adjusted for risk, it really was the critical path. Third, even this simple implementation was cumbersome and time-consuming. Lastly, it did not help me identify the key parts of the project that had the most affect on the schedule due to their risk.
Exhibit 2. The Activity Risk Breakdown report consists of two pie charts showing the overall risk breakdown of the tasks in the project. The first chart shows the percentage of tasks by Risk Factor. The second shows the percentage of total risk-adjusted duration (High Confidence Case) by Risk Factor. In this example, tasks with Risk Factors of 4 and 5, while they make up only 34 percent of the total number of tasks, account for 53 percent of the total project duration adjusted for risk.
Exhibit 3. The Time Risk Analysis breaks the High Confidence plan into 25 equal time slices. The number of active tasks, their total Risk Factors and the average Risk Factor for each time slice is calculated and graphed. This chart identifies the high-risk time periods for a project and helps the project manager budget time, plan vacations and determine when the project is falling seriously behind.
Exhibit 4. The Activity Successor Analysis report takes each task, totals the number of activities with successor linkages to that task and totals the duration, slack, critical duration (duration minus slack) and percentage slack. These are sorted in descending order by critical duration. The highest-risk tasks on the list, while not necessarily high risk in themselves, merit special attention from the project manager due to the possible negative affects on the dependent tasks. For instance, in this example, Activity 1, while itself is low risk, becomes high risk due to the critical duration of its successor tasks.
The Next Step. I began to develop a fullblown system to overcome these limitations. I switched from AutoPLAN to Microsoft Project and from Lotus 1-2-3 to Microsoft Excel. The system described here is the result of over three years of trial and error, refinement and enhancements. The current system, while continuing to evolve, has been used successfully on 12 projects within my department with no project missing the 90 percent probability date. By the way, the original project for which the system was developed was completed after four of the six weeks of “probability enhancement” time had been consumed. Using the system helped the project to be judged a “success” rather than four weeks late. This had a marked effect on the morale of the team.
The key to the system was to reduce the complexity and time required to employ PERT; specifically to attack the ponderous process of defining best and worst case durations for each task. The solution I developed was the concept of “Risk Factors.” A Risk Factor is a number between 1 and 5 that is assigned to each individual task and represents the risk to schedule for that task. A Risk Factor of 1 is used for tasks that are highly standardized and performed within the company on a regular basis and, therefore, have low variability in their actual durations. A Risk Factor of 5 would be assigned to tasks that require invention or involve systems and technologies that are not known within the company. Each task is assigned a number from 1 to 5 that determines the spread of best and worst case duration for each task. This single number (integers only) greatly simplifies the assignment of risk for each task.
Once the project plan is complete, the RBSA system processes the schedule, calculates the critical path, total weighted average, total weighted variance and determines the adjusted durations for the desired probabilities. The adjusted plan is then managed normally using Microsoft Project. At any time the plan may be modified or updated and the RBSA process repeated.
Managing the Project With RBSA. Now, how can that schedule be analyzed so that scarce management time is put to best use? The RBSA system provides numerous risk analysis reports that help to identify those tasks, paths, and time periods that have the most impact on the overall project schedule. I will briefly discuss several of those reports below.
The Activity Risk Breakdown report (Exhibit 2) consists of two pie charts showing the overall risk breakdown of the tasks in the project. The first chart shows the percentage of tasks by Risk Factor. The second shows the percentage of total risk-adjusted duration (High Confidence Case) by Risk Factor. In this example, tasks with Risk Factors of 4 and 5, while they make up only 34 percent of the total number of tasks, account for 53 percent of the total project duration adjusted for risk. Obviously, as the percentage of high-risk tasks and durations increase, so does the overall risk of the project.
The Time Risk Analysis (Exhibit 3) breaks the High Confidence plan into 25 equal time slices. The number of active tasks, their total Risk Factors and the average Risk Factor for each time slice is calculated and graphed. This chart identifies the high-risk time periods for a project and helps the project manager budget time, plan vacations and determine when the project is falling seriously behind. How often have you been halfway through a project, found yourself two weeks behind but the project team was determined to make up that time? In our example you can see that the average risk of the project actually increases over time. If the last half of the project is relatively higher risk than the first half, it is very unlikely that the negative schedule variance can be recovered.
The Activity Successor Analysis report (Exhibit 4) takes each task, totals the number of activities with successor linkages to that task and totals the duration, slack, critical duration (duration minus slack) and percentage slack. These are sorted in descending order by critical duration. This shows which individual tasks are most critical due to other tasks dependent upon their completion. The highest-risk tasks on the list, while not necessarily high risk in themselves, merit special attention from the project manager due to the possible negative affects on the dependent tasks. For instance, in this example, Activity 1, while itself is low risk, becomes high risk due to the critical duration of its successor tasks.
You can see that the concept of Risk Factors not only greatly simplified the process of using PERT for adjusting schedules for risk, but also permits project risk to be analyzed in numerous dimensions. You can probably think of other ways of analyzing Risk Factors to help you manage your particular project.
When to Use the RBSA System. In practice, I have been able to apply the RBSA system at almost any point in a project. Because the system measures and adjusts for uncertainty in the schedule, it can provide a schedule that reflects the “best guess” based on how much is known about the project at that particular time. Often, in order to evaluate projects for funding, a project manager is asked to provide a high-level “SWAG” of the project duration and cost based on a one-page concept statement (sometimes even less). I have used the RBSA system, identifying only highlevel project phases such as Requirements, Design, Implementation and Certification, assigning estimates of time to each phase with a (generally high) Risk Factor. The Risk Factor reflects the degree of uncertainty at that period of time and helps to establish more objective measures of project cost for funding decisions. As the project is funded and proceeds through the project phases, you would expect the number and granularity of scheduled tasks to increase and the Risk Factor for those tasks to decrease as more information is available. At some phase, often the beginning of the Implementation Phase, specific, committed dates and costs are given to the customer, which must be satisfied.
ONE OF THE KEY FUNCTIONS of project management is identifying and managing risk. I have found the RBSA system to be the missing-link between improved risk identification, management, and ease of use. Risk Factors greatly reduce the overhead of employing PERT to account for risk and uncertainty in project schedules while preserving the integrity and power of PERT. The risk analysis reports help focus precious management attention on the truly critical parts of the project. The RBSA system also facilitates communication between all the project stakeholders and provides a basis for setting and rewarding stretch objectives.
For a user's manual on the RBSA system contact Christopher.Weiler@Lexis-Nexis.com or phone 937/865-7759. ■
Chris Weiler is a software development manager at Lexis-Nexis, a division of Reed-Elsevier a full-text electronic publishing company. He manages a group of software engineers developing desktop software for a number of platforms including MS-Windows, DOS, Macintosh, VAX Unix and the Internet.
Reader Service Number 5027
PM Network • February 1998