Estimating Tips


Table of Contents

Avoid off-the-cuff estimates.

Usually, no matter how many caveats you place on an off the cuff estimate, it some how is always remembered as what you said it would take. If you are cornered, then make it BIG or give several options.

Allow time for the estimate, and plan it.

Rushed estimates are inaccurate estimates. If you’re estimating a large project, treat estimation as a mini-project, and take the time to plan the estimation activity itself so that you can do it well.

Use data from previous projects.

Don’t Guess. Use documented data from similar, past projects (not what you remember happen but what happened from the documents). Studies show that using past projects  is negatively correlated with cost and schedule overruns (ie you get less cost and schedule overruns)..

Use developer-based estimates.

Estimates prepared by people other than the developers who will do the work are less accurate than estimates prepared by the developers who will do the work (Lederer and Prasad 1992). When estimator-developers do the estimate and the work, meeting their own estimates reflects positively on both their estimating and work abilities. Separate estimators are more likely to underestimate than estimator-developers (Lederer and Prasad 1992).

Estimate by walkthrough.

Have each team member estimate pieces of the project individually, then have a walkthrough meeting to compare estimates. Discuss differences in the estimates enough to understand the sources of the differences. Work until you reach consensus on high and low ends of estimation ranges.

Estimate by categories.

Simplify by classifying areas as easy, medium, and hard. Assign a fixed size to each category, and then add up the sizes.

Estimate at a low level of detail.

Base the estimate on a detailed examination of project activities. In general, the more detailed your examination is, the more accurate your estimate will be. The Law of Large Numbers says that the error of sums will be greater than the sum of errors. In other words, a 10-percent error on one big piece is 10 percent high or 10 percent low. The 10-percent errors on 50 small pieces will be both high and low and will tend to cancel each other out. Summing task durations is negatively correlated with cost and schedule overruns (Lederer and Prasad 1992).

Don’t omit common tasks.

Here is a list of commonly omitted tasks: cutover, data conversion, installation, customization, management of the beta-test program, demonstrating the program to customers or users, attendance at change-control meetings, maintenance work on existing systems during the project, tech support of existing systems during the project, defect corrections, administration related to defect tracking, coordination with QA, support for user documentation, review of technical documents, integration, vacations, holidays, sick days, company and department meetings, and training.

Use software estimation tools.

Software estimation tools can produce estimates for a wide variety of project sizes, project types, team sizes, staffing mixes, and other project variables. On large projects software estimation tools give the more accurate scheduling and lower incidence of cost overruns than manual estimation methods (Jones 1994b).

Use several different estimation techniques, and compare the results.

Try several different estimation techniques. Study the different results from the different techniques. The most sophisticated commercial software producers tend to use at least three different estimating tools and to look for convergence or spread among their schedule estimates. Convergence among the estimates tells them they’ve probably got a good estimate. Spread tells them there are probably factors they’ve overlooked and need to understand better.

Change estimation practices as the project progresses.

In the early stages of a project, an algorithmic or table-lookup estimate will be most accurate. During those stages, use estimation software. But about mid-design time, a project estimate you make by estimating each of the tasks individually and then adding them up will become the most accurate estimate available and will remain so for the remainder of the project (Symons 1991).

Plus-or-minus qualifiers.

Use plus-or-minus style estimates to indicate both the amount and the direction of uncertainty in the estimate.

Even when you have been forced into promising the software in an unrealistic time frame, you can let those around you know how risky the schedule is by presenting your estimates in plus-or-minus style. An estimate of 6 months, +1/2 month, -1/2 month says that the estimate is quite precise, and that there’s a good chance of meeting the estimate. An estimate of 6 months, +3 months, -2 months says that the estimate isn’t very precise and that there’s less chance of meeting the estimate. An estimate of 6 months, +6 months, -0 months says that the estimate is quite optimistic—probably unrealistic.


One of the problems with plus-or-minus style estimates is that sometimes only the nominal part of the estimate is disseminated throughout the organization. The plus-or-minus factors are stripped off, which results in a significant loss of information. If that’s the case, one alternative is to use ranges of estimates rather than plus-or-minus style estimates. For example, if your estimate is 6 months +3 months/-1 month, you could present the estimate as being 5 to 9 months instead.

Risk quantification.

An extension of plus-or-minus estimation is to explain what the pluses and minuses represent in the estimate. Rather than simply saying “6 months, +3 months, -2 months,” you can add information by putting the estimate into a table.

Estimate: 6 months, +3 months, -2 months         

+ 1 month for late delivery of graphics-formatting subsystem    

- 1 month for less delay hiring new developers than expected

+ 1 month for new development tools not working as well as planned   

- 1 month from new development tools working better than planned

+ 0.5 months from staff sickness              

+ 0.5 months from overly optimistic size estimation        

When you document the sources of uncertainty in your estimates, you provide your customers with information they can use to reduce the risks to the project, and you lay the groundwork for explaining schedule changes if any of the risks materialize.

When you present estimates in this form, be prepared to answer questions about how you plan to address the risks and how to take advantage of the potential schedule reductions.

Coarse dates and time periods.

If your estimates are rough, use obviously coarse numbers such as 2Q97 or 10 man-years rather than misleadingly precise numbers such as April 19, 1997 or 520 man-weeks. In addition to expressing the message that the dates are approximate, the advantage of coarse numbers is that you don’t risk losing information when they’re simplified. An estimate of “6 months, +3 months, -1 month” can be simplified to “6 months.” An estimate such as “2Q97” is immune to such simplification.

Confidence factors.

One of the questions that people ask about a schedule is, “What chance do we have of making this date?” You can  use the confidence-factor approach.

Delivery date     Probability of delivering on or before the scheduled date

April 1   5%

May 1    50%

June 1   95%

25 January 2009 (4)