Chapter 10. Saving for a Rainy Day[11]
Note
An article in a home remodeling magazine noted that "the prudent homeowner sets aside 20 percent of his budget for cost overruns and unexpected expenses." This sounds like good advice, doesn’t it? Most remodeling projects include surprises, like the time the carpenter who built my deck spent an unplanned and exhausting half-day augering through a tangle of twisted tree roots to dig holes for the deck supports. My deck wasn’t completed as quickly as the carpenter had promised and he didn’t get paid extra for the additional time he spent working on it.
Most software projects experience cost overruns and unexpected expenses. They begin with uncertain estimates and encounter schedule setbacks. They experience requirements growth and technology shifts. They encounter essential tasks that weren’t planned. They are thwarted by slips in other projects that tie up people or resources they expected to be available on a specific date. Risks materialize into schedule-destroying problems. Life is just full of surprises.
But few software projects create a schedule or budget reserve to help them deal with such eventualities. To respond effectively to your project’s changing realities, it’s wise to save a little time and money for a rainy day.
This chapter makes the case for incorporating a contingency buffer (also known as management reserve or safety time) into your project plans to accommodate the unforeseen and the unknown. I’ll discuss ways to determine the size of contingency buffers and how to include them in your negotiations with managers and customers. I’ll also look at critical chain analysis as a technique for deriving cumulative contingency buffers to account for estimation inaccuracies. During project initiation you should determine how you will estimate and manage your contingency buffers. Also, this is the time to establish an understanding with your senior management and other key stakeholders about the importance of contingency buffers and why they can expect to see them in your project schedules.
Before we dive into the mechanics, let’s explore how to convince managers and customers that contingency buffers will increase our chances of success. Honest estimation and project planning sometimes leads to schedules that senior managers regard as unacceptable. When managers spot a task labeled "contingency" in the plan, they sometimes think of it as unnecessary padding that can be removed to shorten the schedule. They may not recognize that thoughtfully derived contingency buffers are a practical acknowledgement of reality, not a crutch for weak-kneed estimators who are afraid to make aggressive commitments.
If you’re a project manager, discuss with your managers early on the value of including some safety time and money, instead of surprising them with a project plan they might perceive as padded. Then, use these two strategies to produce convincing numbers:
Analyze historical records. This can be your most effective weapon in battling unreasonable imposed schedules. Compare previous schedule and budget estimates with actual results, identify factors that contributed to any differences, and use this information in your buffer calculations.
Use a proven method for calculating buffers. You can make your case more effectively if you can describe how you came up with your contingency buffer durations. We’ll examine a couple of options in the next section.
Once your plan is in place, resist the pressure to remove your buffers and make impossible promises, no matter what your managers, customers, or other stakeholders want to hear. If your manager or customer claims that some other provider promises a shorter schedule without that pesky contingency buffer, ask how likely the other provider is to achieve that target. Does that provider have better people and processes, or are they just more optimistic (or less honest)? Also ask about the other provider’s track record of actual performance compared to estimates and promises—and be prepared to show your own.
In addition, you can point out that building in slack will increase the chances of delivering on schedule and avoiding litigation that might arise from an unsatisfied contract (DeMarco 2001). I once consulted on a lawsuit involving a vendor that began missing deadlines partly because unplanned communication cycles were required to pin down the client’s requirements. As the vendor’s project schedule included no contingency buffers, it was impossible for them to absorb any of these slips without directly affecting the delivery date.
[11] This article was originally published in The Rational Edge, April 2002. It is reprinted here, with modifications, with permission from IBM.