For More Accurate Software Estimates, Avoid Hidden Risk Buffers
A colleague of mine recently sent me a blog post explaining the difference between project contingency and padding. The blogger made the distinction that padding is what often gets added to an individual’s estimate of the effort required to perform a task (in her example, a software development task) to account for project ‘unknowns’. The estimator determines the most likely required effort, then pads it with a little more effort in order to arrive at an estimate to which he or she can commit. Thus, padding represents an undisclosed effort reserve (and implied schedule reserve) to buffer against potential risk. Contingency reserve, she explains, is “an amount of money in the budget or time in the schedule seen and approved by management. It is documented. It is measured and therefore managed.” Ms. Brockmeier is correct in promoting contingency as the better management tool. The challenge is having a method to measure and document this contingency and the known unknowns it is buffering.
Implicit Risk Buffer
Padding is a natural result of bottoms-up, effort-based estimation techniques. Estimating low-level WBS elements creates more opportunity for padding, because the number of unknowns grows with the task list. The estimator is consciously or unconsciously assessing the risk of each task, considering its dependencies and complexities. What is being implied in the effort estimate is: 1] an assessment of product size and complexity, and 2] a productivity valuation.