Padding schedules for risk is not an incredibly new strategy. But to do it properly isn’t as obvious as it might seem. When you’re sitting down staring at a schedule, most people think they’re being pretty clever by tacking on 30% to the end of their schedule and calling it buffer. There are a number of hidden problems with this approach.
Firstly, big bosses are trained at management school to go right to the end of a schedule (or budget) and slash anything that starts with “B” and ends with U-F-F-E-R. That way, they feel like they’re leaning on people to “get the best/most” out of them. (Which is also a rookie management mistake, but that’s another topic altogether.) Want to thwart this bad habit? Rename all buffer items in a schedule with things like: “Recalibrate the discombobulator” – that will throw them off track for a little while. I’m only half joking here.
Second, in pure* software development, any buffer less than 100% probably isn’t enough in many cases. (* I say “pure” meaning higher degrees of complexity and invention versus “content development” which accounts for the bulk of standard commercial web-site development.) You may be better off thinking in terms of multiples. Even if that’s not the case for your particular project, your buffer time (i.e. “oopsies”) isn’t likely to get used all at the END of the project. It’ll more likely happen in little pockets throughout the project. Which brings me to my 3rd point:
The release date isn’t the only date worth protecting. Besides when the quality control phase of your project starts (which is a HUGE milestone), there are likely components, tiers, or other important dates within your schedule that you’re trying to predict the finish date for. Proper padding for risk should be sprinkled throughout the schedule so that when a slip on some small component does occur, there’s enough elasticity after it that it won’t linearly slide the remainder of the items off the chart. This is important because there are likely other dependencies in your schedule where certain activities are being co-ordinated and planned around smaller phases, components or milestones inside your schedule. The more protected they are from individual slips, the easier it is to plan around them on a continual basis.
Of course, it’s EASIER to just tack on 30% to the end of a schedule, but easier isn’t always better. This is where your choice of scheduling tool can have a dramatic impact on making your schedules stronger and your life easier. For example, Devshop automatically squeezes in little bits of risk padding after tasks by using trends it has observed with respect to the things that most often cause schedule slips: inaccurate time estimation, and dealing with distractions. Having these 2 top schedule killers accounted for in little bits and pieces sprinkled throughout your schedule gives you the most resilient schedule, for the least amount of work.
