[thinkstoomuch]

I wholly agree with this, and feel that all project plans should be constructed to mitigate the very high risk of initial estimates.

Too many project processes treat estimates as commitments with no backup plan when they (inevitably) go awry. I think a better approach would be to design your system around the idea that all estimates are suspect until proven otherwise, which of course leads to iterative approaches etc.

However, you can't run a business without any idea when anything will ship. Estimation is still, in my view, a very necessary step, so long as there is significant incentive to get it right rather than get it fast, AND the business is receptive to a little ambiguity through the project life cycle. This is a very difficult balance to strike.

In my experience you can have certainty in project scope or time, but not both.

[wpietri]

Your point about estimate risk is excellent.

I agree you can't run a business without any idea when anything will ship. But to get a good idea when things will ship, you don't need estimates.

For example, in the Lean world there's something I've heard called "Disneyland scheduling". You break the project down into lumps. You maintain a queue of the lumps. You measure the average time from position X in the queue to being released.

Now you have a reasonable early warning system for when things will ship. Which is generally much better than what people have with most projects, which is a fantasy date.