This is published under the terms of the licence summarized in the footnote.

All free-to-read materials on the Avancier web site are paid for out of income from Avancier’s training courses and methods licences.

If you find them helpful, please spread the word and link to the site in whichever social media you use.


Poor estimating can lead to serious pains.

Business managers should value improved accuracy in estimating.

Estimates can benefit from applying analogy and/or group-think techniques.


Three kinds of estimating technique. 1

Commentary. 2


Three kinds of estimating technique

“An estimate is a calculation of the quantities of various items of work, and the expenses likely to be incurred there on.

The total of these probable expenses to be incurred on the work is known as estimated cost of the work.”


See guidance at for guidance on estimating techniques.

It is common to advise using two or three different techniques, and three are outlined below.


Bottom-up estimates

Managers commonly approach the estimation of a large project by using a “bottom up” approach that involves detailed analysis and synthesis processes.


First, there is a process of analysis, decomposition or work breakdown.

The manager divides the work into tasks, then finds an expert in each task and asks them to estimate it.

The expert divides their task into subtasks, then finds an expert in each task and asks them to estimate it, and so on.


Second, there is a process of synthesis or composition in which the bottom level estimates are added up, and some contingency is added,

Then the second bottom level estimates are added up, and some contingency is added, and so on.


This estimating process can take a lot of people a long time.

The initial estimates are made at the bottom level by inexperienced people with little or no idea of the big picture.

Then way too much contingency is added during the process of synthesis.


Bottom up estimating is hard work, and less reliable than you might think.

You can do well to consider applying one or both of the two big picture techniques below.


Analogy-based estimates

Estimate based on how much it cost you to do a project like this before.

Don’t question how the costs add up, just make sure the project was similar.


Group think estimates: as in the Delphi method.

A facilitator asks a panel of experts to come up (anonymously) with a single estimate for the whole project.

The highest and lowest estimates are discarded.

The facilitator then guides the panel through a process that gradually narrows range of their individual answers until they converge towards the optimal answer.

Many such consensus forecasts have proven to be more accurate than forecasts made by individuals.

You can find the Delphi method in Wikipedia.



Beware that people (encouraged by quality standards like ISO 9000 and CMMI) can hide behind a cloak of procedures and methodology.

Getting a quality system auditor to approve what you are doing doesn't mean you know what you are doing.

Following an estimating method doesn’t mean you are doing estimating well.


There are very strong social pressures to produce an “acceptable” estimate

You might find subcontractor show you public estimates, and maintain private estimates for themselves.


Beware the risky shift phenomenon

“When people are in groups, they make decision about risk differently from when they are alone.”

The Delphi technique is based on the idea that collective decision making is a way to reduce, or at least control, risky decisions.

You might think that is obvious, But psychology research suggests the reverse.

An individual is likely to make riskier decisions in a group, since the shared risk makes the individual risk less.


Greater risks are chosen due to a diffusion of responsibility, where emotional bonds decrease anxieties and risk is perceived as shared.

High risk-takers are more confident and hence may persuade others to take greater risks.

Social status in groups is often associated with risk-taking, leading people to avoid a low risk position.

As people pay attention to a possible action, they become more familiar and comfortable with it and hence perceive less risk.

Ref. “The Risky Shift Phenomenon”


So, if you want support for a thinly-researched estimate, then present it for approval to a board full of Feelers.

In the group, accountability is reduced and each Feeler is reassured by the support of other Feelers.


Q) Can we make estimating more scientific?

Applying an estimating procedure is one thing; getting it right is another.


How to be sure you have well enough understood the scope of what needs to be done, recognised all the items?

Don’t rely on a requirements catalogue alone.

There is a lot of advice on scoping techniques in Avancier Methods.

Use as many of these scoping techniques as you can.


Accurately quantified the size of each item in scope and the time needed for it?

Experience suggests estimation of IS projects is usually more art than science.

Successful estimating depends on the knowledge, experience and skills of the estimators.

So, you could hire some specialist estimators.


And you should collect metrics.

If you don’t test estimates (which are hypotheses) against evidence, then you aren't trying to be scientific.

Across your range of project types and sizes, you ought to:

1.      Catalogue and classify time and cost estimates for each item and item class.

2.      Catalogue and classify actual times and costs for each item and item class

3.      Compare actuals against estimates

4.      Revise your approach to estimating accordingly

5.      Look for fewer discrepancies between 1 and 2.


Without cross-project metrics, there is no science behind estimating
But collecting metrics and interpreting them is very difficult.

So, you should collect anecdotal evidence of where, when and why estimates are accurate or inaccurate.


Q) Have you done any research into estimates?

Yes. I found projects took around one man year for between 10 to 20 requirements in a requirements catalogue.

But don’t rely on that!




The papers on the “Enterprise Architecture” page at contain much advice relating to EA.


Footnote: Creative Commons Attribution-No Derivative Works Licence 2.0     04/02/2015 16:52

Attribution: You may copy, distribute and display this copyrighted work only if you clearly credit “Avancier Limited:” before the start and include this footnote at the end.


No Derivative Works: You may copy, distribute, display only complete and verbatim copies of this work, not derivative works based upon it.

For more information about the licence, see