I don't multiply by 6, instead I use various techniques that works quite well: - http://www.mountaingoatsoftware.com/books/1-agile-estimating-and-planning http

I don't multiply by 6, instead I use various techniques that works quite well: - http://www.mountaingoatsoftware.com/books/1-agile-estimating-and-planning http://www.mountaingoatsoftware.com/books/1-agile-estimating... (with free chapters; also read the various presentations on the site) - http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351 http://www.amazon.com/Software-Estimation-Demystifying-Pract... One key point is to really understand what is risky in terms of estimating (either technically or politically or because it's too vague). At some point, you can really become accurate as long as the scope is well understood. In my case, the Fred Brooks technique does not apply: my last customer iteration was 70% infrastructure, 20% code, 10% pm. The one before was 70% code, 10% infrastructure, 10% documentation, 10% pm.