I have the luxury of working in an office that does not do cost recovery. We do, however, still have to give our clients time estimates from time to time. It helps us plan out our release cycles and give our customers some expectations. More often than not though, our “estimations” come from clients who say they need a project done by x/x/xx because of factors a, b, and c.
I have seen a lot of talk within the AgileBCS group about project estimation, and usually it ends with “yea…it’s a tough problem.” Indeed, it is, and usually every project seems to be unique in some way or another with regards to estimation.
Anyway, I ran across a reposted TechRepublic article today titled Estimate a project’s bottom line using top-down techniques. The interesting thing about this article is that it was originally posted in June of 2001. A lot of the techniques are still in use and come with different names now, usually correlated to a specific methodology it promotes.
An interesting read and an interesting discovery that in business terms, tech projects really have not gone a really long way to becoming more accurate.