I used to work for a software company that did projects for clients and charged by the hour (a consultancy) and we frequently had to estimate projects with inco

I used to work for a software company that did projects for clients and charged by the hour (a consultancy) and we frequently had to estimate projects with incomplete information in order to event get the contract in the first place, so they often turned into the actual final budget. Since I was the head of engineering I ended up doing a lot of sales and estimation for new projects. Besides just doing it a lot and gaining experience from many projects, there were a few other things that really helped me: 1) Software Estimation: Demystifying the Black Art by Steve McConnell (already mentioned by others). 2) His short video on "Targets vs. Estimates" was super helpful - we watched it with engineering, sales, and project management all together and had a good discussion afterwards. https://www.youtube.com/watch?v=FY9X21HA02w https://www.youtube.com/watch?v=FY9X21HA02w 3) Keeping a running list of "Things to Remember". Every time a project went astray or we encountered something during a project that I had failed to estimate (but potentially could have) it went on the list. That was useful to share with other too, when they did estimates. I really like the discussion of standing up to those who ask for estimates. A clear understanding of what an estimate is and what it's for is important, as is a strong sense of professionalism. I would recommend "The Clean Coder" by Robert Martin for this. It's more about professional behavior than software practices. Especially his chapters on "Saying No" and "Saying Yes". I read it and discussed it with my team often. It helped us realize when we had to refuse to give an estimate because we lacked the necessary information to do so, rather than just guess or make something up.