[tweetmeme source=”aabdulmoniem” only_single=false]
Have you ever thought that an accurate estimate may save your project?! Career? Or even your life?! Yeah, I am just like you, I haven’t thought that it is too important to try to give an accurate estimate! So, if you want to learn what I have learned, go and read this chapter.
What I have learned?
- When to overestimate, and when to underestimate? How you can choose between them? And why?
- Overestimation will let Parkinson’s Law to kick in which is: Parkinson’s Law will kick in—the idea that work will expand to fill available time.
- Underestimation will create numerous problems like:
- Reduced effectiveness of project plans.
- Statistically reduced chance of on-time completion.
- Poor technical foundation leads to worse-than-nominal results.
- Destructive late-project dynamics make the project worse than nominal.
- Don’t intentionally underestimate. The penalty for underestimation is more severe than the penalty for overestimation. Address concerns about overestimation through planning and control, not by biasing your estimates.
- What is the benefits of the accurate estimates? (See the following section).
Hidden Gems
Here I will introduce some excerpts which I rate them as hidden gems inside this chapter.
- Gem 1:
Benefits of Accurate Estimates
Once your estimates become 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. Good estimates thus provide important support for project tracking.
Higher quality Accurate estimates help avoid schedule-stress-related quality problems. About 40% of all software errors have been found to be caused by stress; those errors could have been avoided by scheduling appropriately and by placing 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 extreme pressure (Jones 1994). One reason is that teams implement quick-and-dirty versions of features that absolutely must be completed in time to release the software. Excessive schedule pressure has also been found to be the most significant cause of extremely 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 projections, 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 tighter coordination of the whole project, including both software and nonsoftware activities.
Better budgeting Although it is almost too 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 development 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 target, 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 between project goals and project estimates. Consider what happens when the business sponsor 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 substantial chance that the project will fail to meet its business objective. 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 be 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.”
Tip #9 Recognize a mismatch between a project’s business target and a project’s estimate for what it is: valuable risk information that the project might not be successful. Take corrective action early, when it can do some good.
Finally
Guys, keep reading this book. It is marvelous.
Thans
for the nice post.
Hi, Thank you for the nice post! I am as well interested in software estimating.
There is one thing that came to my mind when I read the last one of your hdden gems.
One of the things I often do to express the risk inherent in an estimate is to add “certainty”. I.e. a probability at which the estimate will happen.
For example: We will be able to complete this project with a 30% probability in 10 000 person hours, with an 80% probability in 30 000 hours and with a 50% probability in 20 000 hours.
This way you will be able to give your sponsors one kind of quantifiable measure of risk, and they will be able to make an informed decision about an investment. “Monte Carlo”-based methods will – for example – provide you with this type of information.
Regards!
Michael