The application and development team that I'm going to estimate has the following characteristics:
As you can see from that list, I think all of these variables are important when making an estimate. Project specifications vary from one business analyst to another. No two development teams are the same. Customers that haven't worked on software development projects need to be "trained" (for lack of a better term). New technologies affect productivity.
Size of the project is also very important. Small projects are easy, longer projects much harder, and I don't mean linearly harder. At some point trying to tackle too much all at once makes complexity increase more exponentially than linearly. Think of all the recent delays with Windows Vista, and you'll know what I mean. Even Steve Ballmer said they will never try to change so many things at one time ever again.
Finally, I will also add that if you don't have a formal requirements specification, I don't think you can really estimate a project. How can you estimate what you don't know? At the end of this tutorial I will show you one "back of the envelope" approach I have used when first discussing business application during the conceptual phase, but that's as close as I can imagine to estimating a given project without a proper requirements document.