In software development (and in many other types of projects), there is a typical non-agile approach to estimation of project size. This method starts with a high-level understanding of the work to be done, the requirements, and uses that to make an initial estimate of the project size. This estimate is often stated in units such as man-months. There is a very important piece missing here that makes this estimate completely useless… that makes it pure fantasy.
Any estimate made by anyone other than the team doing the work is useless. For any sort of project, software or otherwise, estimates made by a project manager or leader on behalf of an existing, or, even worse, a non-existant team, must be subject to the highest degree of scepticism.
Not only does the team need to make the estimates for its own work, but the team must be mature! If the team is newly-formed, the team members will have no sense of the team’s capacity other than their own individual capacity.
Not only must the team be mature to make reasonable estimates, it must have a recorded history of their own work capacity in order to be able to estimate their capacity to do work in the future. If there is no record of their capacity, then the usual factors of optimism will be unaccounted for, and the team will almost always over-estimate its capacity.
Knowledge of Domain and Tools
Not only must the team use a recorded measure of their capacity, but they also must be experienced with and knowledgeable of both the subject of the work and the tools they will do to perform the work in order to come up with a reasonable estimate of a project’s size. If they need to learn about the project and how to execute it, then again, the team will almost always over-estimate its capacity.
If someone gives you an estimate for project duration, ask them the following questions:
1. Was this estimate made by the team which will actually be doing the work?
2. How long has this team worked together?
3. Has this team measured their own actual capacity and used that measurement for this estimate?
4. How well does the team know the domain and tools to be used?
If the answers to these questions are unsatisfactory, then the estimate is pure fantasy, it is a lie.