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."
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."
