Project effort estimation involves both science and art. There are well known approaches and techniques for estimating project sizes and effort, these approaches and techniques however do not work well with all project sizes. For example, small projects (less than 5 team members) are severely impacted by team instability, and models used for large projects (teams larger than 25 people) are not applicable to small projects. The best approach for small projects is a bottom-up estimate using analogous techniques to speed up the estimation exercise.
In estimating a common approach is to count, compute and assess. Counting involves counting the number of elements in the projects, such as features, capabilities, web pages, use cases, stories, reports, requirements or similar components. Computing involves calculating an estimate for a per unit count, counts could come in different T-shirt sizes (small, medium and large). The computation should always take into consideration a range and not a fixed value. For example to compute the average time for developing a use case, we should consider the worse case situation, the best case and the most probable. Using a formula like the PERT formula we can then estimate the duration, cost and effort for the average use case development. The same exercise can be repeated with different stages of the project, for example the use case definition, design, development, testing, documentation and training. Assessments are the art part of the estimation and are based mostly on expert opinions and "gut feeling". There is no hard rule on when to use expert opinions, it depends on the project, the experts weighing in, the complexity and novelty of the problem being addressed by the project. In many cases experts opinions have been found to be very reasonable and a great quick estimate approach, however in many more cases it has failed its originators due to factors not considered or accounted for when the expert judgments were rendered, bottom line, use with caution. Some good resources on estimation are Steve McConnell's book software Estimation: Demystifying the Black Art.
In estimating a common approach is to count, compute and assess. Counting involves counting the number of elements in the projects, such as features, capabilities, web pages, use cases, stories, reports, requirements or similar components. Computing involves calculating an estimate for a per unit count, counts could come in different T-shirt sizes (small, medium and large). The computation should always take into consideration a range and not a fixed value. For example to compute the average time for developing a use case, we should consider the worse case situation, the best case and the most probable. Using a formula like the PERT formula we can then estimate the duration, cost and effort for the average use case development. The same exercise can be repeated with different stages of the project, for example the use case definition, design, development, testing, documentation and training. Assessments are the art part of the estimation and are based mostly on expert opinions and "gut feeling". There is no hard rule on when to use expert opinions, it depends on the project, the experts weighing in, the complexity and novelty of the problem being addressed by the project. In many cases experts opinions have been found to be very reasonable and a great quick estimate approach, however in many more cases it has failed its originators due to factors not considered or accounted for when the expert judgments were rendered, bottom line, use with caution. Some good resources on estimation are Steve McConnell's book software Estimation: Demystifying the Black Art. 
