For More Accurate Software Estimates, Avoid Hidden Risk Buffers

<< Webinar Replay Now Available:... | Main | Demand the (Right) Right Data with... >>

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.

Explicit Risk Buffer

QSM’s SLIM-Estimate tool provides an alternative approach that eliminates padding by taking a top-down view of the project.  At the project level, as opposed to the task level, the vast majority of unknowns are attributed to just two factors:  the product size, and team productivity.  Using project productivity values measured from past projects, plus an estimate of the entire product size, SLIM calculates the total effort and duration needed to complete the project.  Risk is explicitly calculated using expected values for size and productivity (along with uncertainty ranges for each input) to produce a probability distribution of effort and duration outcomes.

Read more about how to explicitly set and manage contingency.

Related Posts

Back to Main Blog

Comments

Padding

Padding by the estimator is a bad practice, onl y the PM should pad to account for many factors.
Reply | Add Comment

Thank you for taking the time

Thank you for taking the time to comment.  I appreciate your additional reasons for avoiding hidden buffers.

It is true that SLIM-Estimate's PI's value encapsulates unknowns about the project environment which may be the cause of specific risks.  Because it is a calculated value, capturing lessons learned at project closeout enables you to compare estimate assumptions to project outcomes and identify areas for improvement.  As questions such as:

• Was the contingency amount enough to cover identified risks?  If it was burned too quickly, how was it spend?
• Was the delivered product size much different from the estimate?  Was it within the specified uncertainty range?  Was the variance due to insuffient data to support the estimate, or was their requirements churn?
• How did the actual PI compare to the predicted value?  If the variance was significant, what was the cause (Tools and Methods, Personnel, Technical Difficulties, etc.)?

Good software project management is supported by closing the loop, from estimation to tracking and closeout, with measurement and analysis.

Padding is a bad practice

Padding is not only an undisclosed effort / schedule reserve, but it is a mitigation for an undisclosed risk that is left for a single individual to manage! If the risk itself is not discussed on the team, then others who have the same risk, but do not recognize it, will fail to mitigate it. Also, the PM may have already put aside a reserve for the same risk leading to duplication in the estimates. Being explicit about what mitigations you've put in place, whether at the team member or PM level, is required behaviour.

As a reminder, Parametric estimates can also include padding, typically hidden within the effort / productivity value being used in the calculations. Use of historical data to determine the productivity value and the range for that size of project helps to eliminate the padding and expose the amount of contingency reserve required. Comparing multiple estimates derived from multiple techniques helps to identify padded estimates so long as you investigate why the estimates differ significantly.