Software Estimation Games

Once upon a time, I offered cost estimates on a per-feature basis. It didn't take a lot of time for this strategy to bite me. Over the last few years I have established more stable contracts and now I tend to give estimates for larger blocks of work. My estimates per feature are still often wrong, but this risk is mitigated by spreading the estimated effort across a large set of features.

I usually provide an estimate of the time it would take me to come up for an estimate of the whole project.

Pushing for a 2 level estimation is definitely not easy, and if the person on the other side of the negotiation refuses this, then I ask him/her to stop playing the "Price is right" and spit out his time requirement already.

"...It is our belief that over the 30 plus years of commercial computing has developed a series of sophisticated political games that have become a replacement for estimation as a formal process..."

No. You are confusing the natural inclination for people to negotiate with some kind of slippage into "politics" (The word "politics" is most often used to describe "system of people stuff that I do not understand and that does not make sense to me")

For thousands of years, people have had a natural way of dealing with commitments where incomplete information is present. It's called "negotiation", and it's done by various techniques and tactics such that when all is done both sides are happy. We've also had ways of numerically determining tangible things. It's called math or science.

These are completely different things. What I see all the time is scientific, technical people flummoxed at how business-minded people are treating them. And the reverse is equally true. The reason is that both sides are working inside a completely different universe.

I like this article because it shows how multiparty negotiations can lead to disaster, but I do not like it because it confuses the true nature what's going on.

When asked for an estimate, one good prerequisite is: "with what confidence level?"

Assuming estimating 100 tasks, how many can we safely go beyond the estimate? 20%? 1%? 0.001%

Then give the estimate based on some probability curve considering the known unknowns.

I think you're painting it a bit too black. Having both sides agree to the fact that it's an estimate (and not an exact prediction) does help. And if you make the client understand the contingencies and unknown factors, you may get around the expectation to make an accurate prediction — which nobody can give anyway, except when doing the same thing the umpteenth time. Communicating often on progress that you actually do make can still give the client a good sense of confidence and control on what's happening.