in reply to The IT Project Estimation Game

I find this problem a really easy one to deal with as soon as you realize that it is an apples and oranges problem. There is no relation between the time and cost the client (or your boss) is willing to spend on the project and the time it will take to implement it. They are two different things*.
As a developer it is your responsibility to make a good faith estimate and stick to it. The only way to marry a gap between the estimate and clients expectations is to either add resources (to a point) or to remove functionality. Don't buckle and agree to a date you cannot meet because your boss is unhappy with your estimate.
Also, any estimate given should be submitted with a list of caveats, bottlenecks and external requirements. CYA for when things go wrong. If you need a database set up, a webserver set up, etc., the estimate should include this, and make clear at what point their absense will affect the deliverable.
That being said, I find that the biggest enemies to accurate estimation are incomplete or changing requirements. One thing I have learned as a developer is to always push back on requirements. Do not estimate against anything that is unclear. Your first response to an estimate request should be a list of questions. Questions that point to the missing and fuzzy requirements. Questions that, until answered, will prevent you from making an estimate. Your estimate should make very clear that if any of the requirements change the date will be affected. Then, as the project continues be diligent and estimate the delta of any proposed requirement change and insist that the date be pushed back if the change is to be made.
Don't waver. They can accept your method and have good estimates and happy clients, or they can fire you. Chances are if they do the latter, you didn't want to work in an environment where you would constantly be overworked, behind schedule and taking the blame for other's bad decisions.
Finally, get everything in writing and signed off on. When the sh*t hits the fan, make sure it is somebody elses sh*t and somebody elses fan.

* This applies to a lot of games that people play. The amount of money you are making at your current position has nothing to do with what the prospective job pays, nor does what you are looking to earn. They know what they are willing to spend, let them tell you.

-pete
"Ted Nugent called. He wants his shirt back."

Replies are listed 'Best First'.
Re: Re: The IT Project Estimation Game
by one4k4 (Hermit) on Jun 05, 2003 at 14:48 UTC
    I'm ++ this and it's thread. It's a good point.

    As a developer it is your responsibility to make a good faith estimate and stick to it.
    At first I read this and though "woah" but your explaination afterwords made it "ok".

    I think, when it comes to developing web-related products, that a sign-off on specs is often quite hard to get. Sure, you can mock up sample report-pages (fyi: I write applications that are based on IE->Apache->mod_perl->Sybase.. so, "web related") and go from there, but that's never quite "enough". This column header needs changing, the math behind calculating that value is "right" but for this specific case, it's wrong..

    I think spec signoff is do-able as long as the business rules in place are static.

    We get a lot of the users with the "the report shows the wrong data, it's a report problem" mentality, when in fact, it's a spec change for a specific "rule" that was forgotten..

    But, you are right. As long as you think CMA then you should have enough information to present to your boss(es) when they ask where/what/how long a project will be before it's done..

    One4k4 - perlmonks@poorheart.com (www.poorheart.com)