Actually its a mixture of the first four: first studying the requirements, getting a gut-feeling based on this, then doubling/scaling that effort and at the end adding a random number so the whole thing looks somehow more realistic. It works quite well, and allows me to finish in time in most cases :-)
Had a PHB who gave the same estimate no matter what the project was. "2 weeks." When ten days later he was asked for an ETA on the same project he'd answer "2 weeks."
I use a variety of answers myself and it is normally based on several factors. I'll ask a client "when do you need this by?" After I finish rolling around on the floor laughing hysterically at their first answer (an entire CRM application in 72 hours? REALLY?) I then negotiate something we both live with.
A trick that I'll employ is to give them a subset of features on a first pass effort and then add features over an extended period of time.
Now if it is a customer I don't like or a project I don't want to work with my estimates get padded to something ridiculous with the hopes they will get sticker shock and run away in terror. If I fail then I ratchet up my hourly rate a bit.
At that point they will either go away or I'll make more money on the project than I normally would and hopefully that will make up for the aggravation involved.
On rare instance I'll tell a client flat out to take their business elsewhere...
Peter L. Berghold -- Unix Professional
Peter -at- Berghold -dot- Net; AOL IM redcowdawg Yahoo IM: blue_cowdawg
Since I never get a spec of any true value, I give two estimates; One based on a fair guess from past experience for a project of it's size, and a SWAG based on the person giving me the spec and how poorly they've spec'd things in the past.
Should take a week, but for you it'll be two months.
For me Perl is a hobby (strictly for my own fun, or for fiddly things I can do "under the radar")
However I'm paid to implement SAP BPC systems and have found that no matter how optimistic or pessimistic I am in my estimate, the #1 rule is that the client will ALWAYS try and "negotiate" for less time. Initially I reacted by becoming more pessimistic and then delivering faster than planned, but found that clients aren't grateful ... they just take it as a sign you were planning to rip them off.
So now I estimate as accurately as I can, and when the client objects, I ask them to pick the functionality that's NOT going to be implemented.
Only one client has ever accepted the challenge ... and they decided they didn't need any project documentation! :-) ... I've since made more than 3 times the "saved" money out of them afterwards, because they had no idea how to support the system and had to keep calling me in.
Long ago, at a company that has since been purchased twice, one of the project engineers was famous for writing up his estimates for the exact amount, with no padding. On more that one occasion, somebody in the finance office would automatically cut 20% off, then someone else would yell at him for going over the budget. His response was usually something to the effect of "I told you how much time and money was needed; this guy changed my estimate. I know what I'm doing, and I don't put in padding just so it can be cut so some bean counter can look like he's doing a real job."
This only worked because the person who did the cutting was not the same person as the one yelling about going over budget ;)
Information about American English usage here and here. Floating point issues? Please read this before posting. — emc
I carefully analyze the requirements which, based on a gut feeling (and personal assessment of the customer) I add to $day_of_week months and $day_of_month days, adding the amount of overtime I need to pay for my next vacation, pulling some numbers out of the air and multiplying them by a fair dice roll. Then I double that and scale up by some random numbers I pull out of thin air.
this thread should never die IMHO.
i like to charge people based on what i think/estimate their work im doing is worth .
I try to consciously cut out R&D cost from the estimation cost, coz thats usually 90% of a web project.
I put in a key figure like X dollars/local currency per day and then figure out how many days of cold hard labour (minus the creativity) it will take to complete the project.
Im yet to get a large enterprise level perl project. relishing the thought of that. :D
In my company we get a project objective & a deadline that we back into almost every time. Therefore with a fixed amount of time, I scale back the functionality to a level that I can actually deliver in the given time. If it successful and popular then we schedule another swipe at it to add more functionality.