Part of a series on Making better estimates.
Estimates require making assumptions. Assumptions violated are like risks realized. Both can be accounted for with some estimate buffering.
Estimates by necessity are based on assumptions the team makes. Keeping track of these assumptions formally allows for the team to review them and do a simple sensitivity analysis of the estimate with respect to the assumptions. At the very least the assumptions should be documented as part of the estimate.
Like assumptions, it can be very valuable to identify and document project risks while estimating. Tim Lister, author with Tom DeMarco of “Waltzing with Bears: Managing Risk on Software Projects” describes a simple technique for responsibly accounting for these risks in a project schedule.
For each identified risk, record the probability of the risk event coming true and the impact to the estimate if the risk event comes true. Now calculate a contribution from each risk to an overall risk buffer by multiplying the probability by the impact. For example:
| Risk | Description | Probability | Impact | Contribution |
|---|---|---|---|---|
| QuickBooks integration | The QuickBooks expert isn’t available | 30% | 2 weeks | 0.6 weeks |
| Deployment | Client must host on Windows | 10% | 1 week | 0.1 week |
| Detailed requirements | Customer not readily available | 50% | 4 weeks | 2 weeks |
Project risk buffer = 0.6 + 0.1 + 2 = 2.7 weeks
We don’t usually take this approach in our projects. We tend to turn risks into assumptions and document them along with the project estimate, helping the customer to understand them and making it clear that the schedule may be impacted if assumptions are violated.
If you use a project risk buffer be sure you’re not double counting for risks in the breadth of estimates on some task. Using risks for aspects of the team or project or business environment, versus the natural variation of tasks, achieves this.
Previous post: Date vs Duration