Once your estimate becomes accurate enough that you get past worrying about large estimation errors on either the high or low side, truly accurate estimates produce additional benefits, Improved status visibility – One of the best ways to track progress is to compare planned progress with actual progress. If the planned progress is realistic (that is, based on accurate estimates) , it’s possible to track progress according to plan. If the planned progress is fantasy, a project typically begins to run without paying much attention to its plan and it soon becomes meaningless to compare actual progress with planned progress. Godd estimates thus provide important support for project tracking,Higher Quality – Accurate estimates help avoid schedule stress related qualiry problems. Almost 40% of all software errors have been avoided by scheduling appropriatly and by less stress on the developers (Glass 1994), When schedule pressure is extreme, about four times as many defects are reported in the released software as are reported for software developed under less exteme pressure (Jones 1994). One reason is that teams implement quick and dirty versions of features that absolutly must be completed in time to release the software. Excessive schedule pressure has also been found to be the most significant cause of extrenely costly error-prone modules (Jones 1997).Projects that aim from the beginning to have the lowest number of defects usually also have the shortest schedules (Jones 2000). Projects that apply pressure to create unrealistic estimates and subsequently shortchange quality are rudely awakened when they discover that they have also shortchanged cost and schedule.Better coordination with nonsoftware functions – Software projects usually need to coordinate with other business functions, including testing, document writing, marketing campaigns, sales staff training, financial planning, software support training, and so on. If the software schedule is not reliable, that can cause related functions to slip, which can cause the entire project schedule to slip. Better software estimates allow for tigher coordination of the whole project, including both software and nonsoftware activities. Better budgeting – Although it is almost to obvious to state, accurate estimates support accurate budgets, An organization that doesn’t support accurate estimates undermines its ability to forecast the costs of its projects. Increased credibility for the devolopment team – One of the great ironies in software development is that after a project team creates an estimate, managers, marketers, and sales staff take the estimate and turn it into an optimistic business target – over the objections of the project team, The developers then overrun the optimistic business, at which point , managers, marketers, and sales staff blame the developers for being poor estimators! A project team that holds its ground and insists on an accurate estimate will improve its credibility within its organization. Early risk information – One of the most common wasted opportunities in software development is the failure to correctly interpret the meaning of an initial mismatch project goals and project estimates. Consider what happens when the business sponser says, "This project needs to be done in 4 months because we have a major trade show coming up.." and the project team says, "Our best estimate is that this project will take 6 months." The most typical interaction is for the business sponsor and the project leadership to negotiate the estimate, and for the project team eventually to be pressured into committing to try to achieve the 4-month schedule.Bzzzzzt! Wrong answer! The detection of a mismatch between the project goal and the project estimate should be interpreted as incredibly useful, incredibly rare, early-in-the-project risk information. The mismatch indicates a sudstantial that the project will fail to meet its business odjective. Detected early, numerous corrective actions are available, and many of them are high leverage. You might redefine the scope of the project, you might increase staff, you might transfer your best staff onto the project, or you might stagger the delivery of different functionality. You might even decide the project is not worth doing after all.But if this mismatch is allowed to persist, the options that will ba available for corrective action will be far fewer and will be much lower leverage. The options will generally consist of "overrun the schedule and budget" or "cut painful amounts of functionality."