As a general guideline, the total project schedule reserve should be five to ten percent of the sum of the estimated duration of all project activities (Wysocki and McGary 2003). Note that this is not five to ten percent of the overall project schedule; that’s not enough slack. The higher number is appropriate for especially complex projects or those that involve unusual risks, uncertain or churning requirements, or bleeding-edge technologies.

To estimate an appropriate contingency buffer for your project, first identify areas of uncertainty that could lead to poor estimates. These might be the most technically challenging or innovative parts of the project, tasks that use unfamiliar techniques or technologies, or poorly defined requirements. Once you’ve identified the major sources of uncertainty, set an appropriate safety margin, perhaps 25 percent, for the duration you allocate to the corresponding tasks.

Next, examine your past projects for recurring patterns that led to delays, such as chronic requirements growth, overlooked tasks, or consistently overoptimistic estimates. One company came to me for help because they were routinely overrunning their schedules by at least 25 percent. When we investigated, we saw that their projects experienced an average scope increase of about 25 percent. It didn’t take a rocket scientist to figure out that they should include a 25 percent contingency buffer in their future project schedules to accommodate an expected level of requirements growth. Managers reject such thoughtfully derived buffers at their peril.

Finally, use risk analysis to estimate the possible schedule impact if any of the serious risks—known factors that pose a potential threat—materialize or if external dependencies are not satisfied. See Chapter 6, for more about risk management. Multiplying the estimated probability that the risk could become an actual problem by the potential schedule impact if it does become a problem yields a risk exposure in units of time. Factor the schedule risk exposures from your top 10 or so risks into your contingency buffers.

For example, suppose you plan to subcontract a critical component of your next project to a specific vendor. The last four times you used this vendor, they delivered on schedule twice and they were four weeks late twice. Therefore, your best estimate of the vendor’s future performance (assuming that the vendor is doing similar work for each project) is that they have a 50 percent probability of being four weeks late, for a risk exposure of two weeks from that one risk factor.

When you reach the end of a project phase or achieve a major milestone, reassess any contingency buffers for the remaining duration of the project. Suppose you based your contingency in part on a possible late delivery for the component that vendor supplies. Once you receive the component, perhaps you can shrink the contingency buffer for a future phase because that risk can no longer delay the project. Alternatively, you might want to increase an upcoming buffer if you identify new risks, if the potential exposure from a specific risk factor increases, if a dependency fails, or if earlier buffers turned out to be too small.

Your risk analysis will also help you sell managers and customers on the need for contingency buffers. I know of a telecommunications company that successfully incorporates a risk analysis into its standard estimation process for that very reason.