Johanna Rothman recently published a series of articles on dzone.com on Software Project Estimation that I thought was quite good.  I would encourage anybody to read it:  http://agile.dzone.com/articles/estimating-unknown-dates-or

I think she has really distilled down the most essential aspects of software estimation.  The most difficult thing about estimating for software projects is that they are almost always new territory.  How can one reliably make an estimate on something one has never done before?

This is much different than estimation for a traditional project, say constructing a building.  In this case, probably 90% or more of the project is identical to many past projects.  So, right off the bat one can expect a variance of less than 10% in the estimation accuracy w/o any effort at all.  This is even easier if the project is similar to past projects (e.g. all commercial office buildings) and one is using largely the same workforce (all the same subcontractors) or skilled tradesmen (i.e. steelworkers) who are largely interchangeable.

Since most software projects are plowing new territory for the first time, one has no past projects on which to base predictions of the future.  In this case, iteration (i.e. successive refinement of an estimate) is the only way to improve on the SWAG that is the first "estimate". I think Kent Beck's book "Extreme Programming" was the first place I read the comparison of hitting a target with either a rifle & bullet vs. a cruise missile.  In the first case, one carefully aims the rifle, calculating the distance to target, wind drift, elevation difference, and many other variables.  This method only works if one has extensive history with this particular rifle, scope, cartridge, and other details.  In the other case, a cruise missile is launched in the general direction of the target and makes continuous course corrections during every of second flight. The cruise missile is able to compensate for headwinds, bad weather, changes in fuel load, and works for targets at any range or elevation within its capability.

I love her suggestion of giving confidence ranges along with estimates.  That really helps to wake up managers (& the whole team) that these estimates have an inherent uncertainty to them (i.e. a probability distribution). It also helps to make clear up front what the unknowns are in the project, in order to help focus people on answering some of those unknowns. This has the beneficial effect that, when an unknown is resolved, one gets a reward in the form of tighter confidence intervals.

Keep up the great work, Johanna!

Alan Thompson