Paul Laudeman

Well, thanks for the mention, Paul!

Like I said - it's nothing we don't all know; it's just what we don't all *do*.

It was originally going to be 'The 100 Pitfalls', but I didn't think anyone would read all that. ;)

I find estimating to be very hard to do -- especially when it's other people who have to do the work.

The hardest part can be balancing what the customer WANTS to hear versus what the REALITY of the situation is. Smart customers will appreciate the latter, but not all customers are "smart."

"The hardest part can be balancing what the customer WANTS to hear versus what the REALITY of the situation is. Smart customers will appreciate the latter, but not all customers are "smart." "

I'm not convinced you should try to "balance" what the customer wants to hear with reality. Isn't that exactly what project managers are doing when they shave a developer's estimate to make it politically palatable? Sure, you avoid "estimate shock", but then you also set up that feature - if not the whole project - for failure.

Companies need to come up with enough institutional courage to stand by their estimates. Period. No balancing.

Either that, or everyone - clients and providers alike - need to admit that they don't care about deadlines.

I'm not holding my breath for that to happen. ;)

Or for either, for that matter!

I think you cut directly to the point when you said that software estimating is truly a political "maneuvering" game where developers say one thing, managers either hear it or something else that they want to hear, and at the end the estimate ends up being exactly what it needs to be to fit nicely into a project plan to make some Gantt chart look pretty.

It is developers, after all, who will always drive the schedule based on their ability to deliver what is asked in the time given, unless their management forces "mandatory" overtime, adds more resources, or (ideally) reduces scope.

Exactly! But as anyone who's worked in the business for a couple of yeas knows, mandatory overtime and additional resources often don't help.

I sometimes thing that the core issue is just that a) Business typically does not trust Development, and b) the Customer typically does not understand the Value of what they are buying.

A few of my own clients give the distinct impression that they only use computer technology "because everyone else does", not because they understand how it impacts the bottom line of their business.

But really, it boils down to institutional courage and a willingness to say "No" when it is appropriate to do so. Saying "no" is sometimes the best thing you can say to your customers, whether they know it or not.