“An off-the-wall thought: When I’m able to pull it off I do a project/time estimate as the inverse. I ask the customer how much time I have…then figure out what I can do in that amount of time. In a way a time estimate is a requirement. What good is a product if it can be delivered on time (which may be at arbitrary length) but not at an *applicable* time.”
Richard brings up an interesting point – sometimes you get a project that is only useful to the client if it can be implemented by a certain date. I often had to do the kind of inverse estimating that Richard refers to when I was building variable compensation systems; those Fortune 500 companies do their compensation processing on a certain schedule, and if I couldn’t deliver certain features by certain dates, the value of those features dropped to 0 until the following year! These days, most of my consulting work falls into the category of "things the client wants to do as soon as I can build a tool to do it with", but that is not going to be the case with everyone and it is good to bear in mind that sometimes you have to back in to your estimates.
Now that I’m thinking about it, backing into an estimate is also a great help in managing expectations. Once you present an estimate containing x number of features, if the client later has to change the due date for some reason, they won’t always understand when you come back and tell them that given the new date you can only deliver x – y features. They won’t always understand why you can’t just “work faster” and deliver the original feature set – they’re experts in their own businesses, not in the very unique (and sometimes strange) rules governing software development. Some might even be taken aback and think you are punishing them for giving you less time to do the project. It sounds outrageous, but it does happen.
Better to present an estimate with fewer features that you KNOW you can implement in the time allotted, if date constraints exist prior to your taking on the project.