I have observed project managers who provide fine-grained, long-term estimates of project effort. For example, the effort estimate may be expressed as “10,432 person-hours.” There are a number of negative consequences to such a fine-grained estimate:

• It may require a complex calculation involving enormous numbers of tasks.
• It implies precision that cannot exist at the beginning of a project.
• The estimate changes with time, either because requirements change or because uncertainty is eliminated as the project proceeds. Every such change, no matter how small, requires the estimate to be recalculated and republished. Otherwise, confidence in the published estimate is diminished. Such frequent changes, at best, are irritating to stakeholders and, at worst, lead them on a roller-coaster ride.

The solution is to provide coarse-grained estimates. I prefer estimates expressed in team-iterations. Such estimates have the following benefits, all of which flow from the policy of “rounding up” the estimate to the next team-iteration:

• They make the calculation of the overall estimates simpler and more manageable.
• They imply only a level of precision that can reasonably exist at the beginning of a project.
• The date of the product release can be determined as easily as with a finer-grained estimate
• Larger changes in requirements or uncertainty are required for the estimate to change.
• They create an automatic risk buffer, meaning the project is more likely to be completed within a reasonable interval around the published date.
• Stability of the estimate, compounded by increased certainty of timely delivery, increase stakeholder confidence.

Project managers sometimes express risk as “percent confidence” in an estimate. However, what does it mean for some one to be 50% confident that a project will take 10,482 hours? (It seems to me that, at the beginning of a project, the confidence in a fine grained estimate should be nearly zero, in which case estimators will be loath to say anything!) Does it mean that the project is equally likely to take more than 10,482 hours as it is to take less? How much more or less? Confidence, in such situations, tends to be very subjective. Such estimates are not useful to stakeholders financing the project.

I prefer estimates to be expressed with three numbers, corresponding to the best-case, expected-case, and worst-case scenarios. Such an estimate can be provided easily and early. Estimators can quickly place some constraints on the project, saying, “the project will take no more than x amount of effort even if everything I can imagine goes wrong; it could also be easy enough to take only y amount of effort, but no less”.

In order to express estimates in this way, you must enumerate and quantify risks. However, once this is done, it becomes rational to expend some effort on mitigating or eliminating the risks with the largest or broadest impact. I have observed a frequent conflict between the developers wanting to expend certain types of effort and investing stakeholders wanting to minimize effort (cost) expended on development. Such conflicts are best resolved by understanding the risks mitigated by those efforts. Developers often have a keen intuition about risk, but find it difficult to explain how certain efforts mitigate risk. Once risks are enumerated and quantified, it becomes obvious to developers that some efforts are not worth expending, and to investors that some are.