I've worked for startups and for aerospace and defense contractors. There are of course different ways to approach software project estimation. I've worked on

I've worked for startups and for aerospace and defense contractors. There are of course different ways to approach software project estimation. I've worked on projects where we needed to do details work breakdown structures: http://en.wikipedia.org/wiki/Work_breakdown_structure http://en.wikipedia.org/wiki/Work_breakdown_structure And I've been in environments where I had to wing it with ever changing requirements where everything was all over the map. Somewhere in the middle is the happy ground. For perspective, I recommend reading the following book: Software Estimation: Demystifying the Black Art by Steve McConnel (http://www.stevemcconnell.com/est.htm http://www.stevemcconnell.com/est.htm) [Edit] Estimation is an iterative process both within a project (even if you are stuck in a god-awful waterfall) and with consecutive projects. You self train your estimation skills for doing similar work. Its when you hit something new that you don't have the past performance to draw upon that you really have to rely on your instincts. As a bottom line, I'm much less wrong when I go with my gut instincts than when I analyze and estimate ad nauseum.