Project managers typically use one of the following approaches to calculate contingency buffers:
Option 1: Add a "safety increment" to every task.
Option 2: Place a buffer at the end of a set of project activities (such as a major milestone, a development phase, or an interim release) and/or as a separate task at the very end of the project schedule.
I do not recommend Option 1, simply padding the estimate for each task. It increases the planned duration and cost of the entire project by the expansion factor without differentiating among tasks. Protecting the tasks on the project’s critical path (the longest sequential path of essential activities that runs from initiation to delivery) against overruns must receive top priority. Tasks that do not lie on the critical path already have some slack time following them. They can tolerate some slippage without affecting the overall project schedule, so they shouldn’t need additional safety margins. Of course, if a noncritical path task slips by too much, it might move onto the critical path. In addition, if your estimated duration for a specific task is far too low, it might look as though that task is not on the critical path, even though it really is. Even when using contingency buffers, you need to generate the most accurate estimates you can for each task.
Note
Multiplying each task estimate by an arbitrary constant, such as 50%, to compensate for perceived estimating inaccuracies.
Expanding each task estimate also increases the risk of succumbing to Parkinson’s Law: "Work expands to fill the time allocated to it" (Parkinson 1979). That is, if you include a safety day in a task that you estimate will require four days of effort, you’re likely to spend all five days completing the task. It’s an easy trap to fall into, although some studies have suggested that software people are not as prone to Parkinson’s Law as you might expect (Jeffery and Lawrence 1985). The fear managers have that Parkinson’s Law will prevail, however, leads them to cut estimates and compress schedules to keep the pressure on. This is usually counterproductive. As consultant Tim Lister points out, "People under time pressure don’t think faster" and software development involves a lot of thinking (DeMarco 2001).
Option 2 offers a better approach: Incorporate contingency buffers at the end of major development phases, at the end of the entire project, or both. In this scheme you estimate how much additional money and time (as will be discussed) you need to yield a high probability of completing on schedule and within budget. You assign these safety margins to discrete tasks placed at the end of your project schedule and/or after major milestones. Don’t assign staff resources to these tasks, as they simply represent extra quantities of time or money that the people already assigned to the work tasks might need to complete them. If your project is following an iterative or incremental development life cycle, include a buffer at the end of each planned iteration.
As your project progresses, some tasks will take longer than estimated. Some of those tasks may be on the critical path. As these slippages occur, reduce the remaining contingency buffer time by one day for every day of overrun you experience on critical-path tasks. Without a contingency buffer, if a task on the critical path slips, the project as a whole will slip by the same amount. Keep an eye on the balance remaining in your contingency buffer as part of project tracking. If you’re depleting your buffer more rapidly than your team is completing the planned work, the project schedule is in jeopardy.
Note
Tapping the contingency buffer to accommodate scope changes that occur. It’s better to set aside a separate buffer to anticipate the likelihood of requirements growth and reserve the standard contingency buffer to handle estimate overruns and unanticipated risks that materialize.
Your team members should aim to meet the schedule targets they originally estimated for individual tasks without the contingency buffers, which are intended as a safety margin for overly optimistic estimates. As a project manager, however, base your commitments to external stakeholders on the estimated schedule for all project tasks plus the contingency buffers, as shown in Figure 10-1. That is, work internally to the nominal estimates, which lead to your planned delivery date. But include the buffers in your committed delivery date. And if you don’t consume the entire buffer, you’ll finish early from the perspective of the external stakeholders.
Some contracts base a reward structure on the portion of the buffer that remains unused when the project is completed. When the Rochester, New York, airport repaved its main runway some years ago, the contractors received a bonus for every day they came in ahead of the committed schedule. They finished early, they got their bonus, and those of us who lived under the flight path for the secondary runway were delighted. Of course, it’s possible that a bonus incentive could lead a vendor to pad a bid with an excessive contingency buffer, which is why clients should prepare their own estimates as a reality check.