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 :-)
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.
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.
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
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.
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.
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