| The spreadsheet displayed in Table8-1 provides all the information needed to determine the size of a risk factor to be inserted. The task overrun possibilities totaling 46.5 days are balanced against the likelihood that the tasks will not overrun by using the D times Y formula. The result of the calculation of contributions and adding them together is 7.55 days. Rounding up to eight days, this would be the risk factor to use for this string of tasks if there is no need for step-function adjustments. There are five tasks in the list that have step-function characteristics. In four cases (3, 9, 13, and 34), the step functions (Ds) are small when compared to the risk factor. Their occurrences will average out just as the tasks with creep characteristics average out. No special adjustments are called for. Task 17 is a different case, however: There is a 15 percent likelihood that a problem causing overrun will occur here, and wherever the problem occurs there will be a seven-day delay. This is different from Task 29 where there is a 10 percent likelihood of a problem causing overrun to occur, but this problem does not instantly cause a nine-day delay; 29 is a creep overrun task, only in a very few cases will this delay (which has only a 10 percent chance of occurring at all) reach nine days. The likelihood of this happening is very, very small. It is not realistic or economical to try to protect a project from it. But for Task 17, there is a full 15 percent likelihood that the seven-day delay will impact the project and use of seven of the days provided for overrun by the risk factors. If this happens, the project time buffer represented by the risk factor has only one day to protect the project from all other sources of overrun. (We have used some elaborate calculations to try to determine a satisfactory time buffer size for the risk factor in this case. We have found that a simple rule of thumb works well.) If the step function D is larger than half of the risk factor as calculated, subtract half of the original risk factor from the step function D, and add the difference to the original risk factor. In the situation being examined: 1/2 of 8 = 4, 7 - 4 = 3, and the new risk factor is 8 + 3 = 11, or eleven days is the revised risk factor. This is a conservative approach. The project may finish a little earlier than predicted this way, but it will not be heavily buffered and it will not overrun the predicted finish date. Such is the condition that you can look forward to in all cases of IPM time buffer calculations. Basically, risk analysis is a process that helps the project leader and the team make a good judgment call. Judgment is called for because project planners always know more about tasks than simple numbers can describe. Note: Two tasks are at "0" risk in Table 8-1. Project managers are warned to beware of such estimates. Nevertheless, some jobs are successfully and repeatedly accomplished and additional resources are easily procured should problems arise. If history supports no more than a 1 or 2 percent likelihood of overrun, treat it as a "0" contribution. Note: It is impossible to run a business successfully trying to cover all apparent 1 or 2 percent risks. The string of tasks used in Table 8-1 reflects a Gantt chart timeline of 132 days with no risks considered. It produces a 178.5-day sequence if every task runs over to its worst case amount; that is, the sum of the overrun possibilities is 46.5 days. Risk analysis of the data described in the table shows that an 11-day risk factor inserted after Task will cover all the overruns that can reasonably be expected to take place during this sequence. The next task on the critical path the one that begins the next task sequence of the project can be confidently scheduled to start immediately after the risk factor task. Here is a general question for all task leaders: If a delay is foreseeable during the early period of the task, is it possible to plan overtime and recruit more help or seek expert input, and thus avoid or reduce the delay? If yes, this piece of information should be included in the task notes of the project manager's diary, written into the notes recorded in the software, and introduced into the consideration of the task delta and likelihood. | 
