*This post is part of my series on Software Project Estimation:*

*Part 1: Introduction**Part 2: The Process of Software Development**Part 3: The Cone of Uncertainty**Part 4: Expert Judgement**Part 5: Count*

Expert Judgement is the first estimation technique I’m going to explore. Normally when a team is trying to come up with an estimate for a project, they do something very similar. Someone will sit down with a list of features and guess how long it will take for the team to do the development. Most of the time these estimates vary widely from actuality. But, there are things that can be done to make them more accurate.

The first step is to be carefull when picking your expert to do the estimate. The export should satisfy the following qualifications:

- They must be an expert in the problem domain. That is, they should understand the business and technical side of the problem.
- They must be an expert in the technical domain. They should have a deep understand of the systems that this project will integrate with. They should have been invovled with several projects in the past in this domain.
- They must be an expert in the tools and technologies being used in the construction of the project.

The next step is to not just take a single estimate from the expert for each feature. The export should give the following estimates:

- Best Case: If everything goes just right, how quickly could the feature be built.
- Worst Case: Assuming everything goes wrong and road blocks are encountered at every turn, how long with the feature take.
- Most Likely Case: Based on the previous two estimates and his past experience, how long does the expert really think the feature will take.

Based on these three numbers, an industry-standard “Program Evaluation Review Technique” (PERT) can be used to calculate the Expected Case. PERT does this by putting a different weight on each of the three numbers with the following formula:

- Expected Case = (Best Case + (3 x Most Likely Case) + (2 x Worst Case)) / 6

By adding up the Expected Case for each feature, the total amount of time for coding and unit testing can be determined. The percentages assigned to each phase of the project can then be used to determine how long the entire project will take.

Using this technique, you are still dependent on one person’s opinion. Often times you can’t find a single person that meets all of the qualifications of the expert that you need to do the estimate. This technique can be improved by having several experts independently use the above technique to come up with their own estimates. Then, have all of the experts come together an discuss each of their estimates. By talking about the reasons for the differences, the experts should work together to come up with a consensus estimate. The numbers from this consensus are then applied to the above formulas to determine an estimate for the project.

Expert and Group Expert Judgement are great methodologies to use early on in the project when the required features are known, but little about exactly how the solution will be constructed.

In the next post, I’ll investigate another estimation technique that works early on but does not require experts in the domain to do the estimate.