Estimates or Code?
If there was ever a no-brainer for improvement, you might think it would be "Gather estimates before you code." After all, business people count on return on investment (ROI), and to do that you need to know how expensive the project will be!
The problem here is that nothing is free. Meaningful estimates take considerable time to produce; you have to have relatively solid requirements and almost have a complete design. If the organization has 20 projects for which it wants to calculate ROI, the development staff could find that it’s spending as much as 50% of its time just estimating. Last time I checked, companies expect developers to actually create software, not just quote it.
Estimates are a good thing. But time spent on estimates is typically time not spent on project progress. My questions are along the lines of "How do we balance between quality of estimates and the time spent to make them?"
The Agile movement gets away from this problem by just listing work in orders of magnitude, creating a simple working system, comparing estimates to actuals to create a ratio, and then predicting delivery. Notice that to get to that point, they trade away predictability, which may be fine for this project—but when should we plan on the next project starting?