Software Estimates

“How long would it take you to walk the marathon?” If some one asked me this question, am I able to answer it? I never walked 42 kilometers, but I think so. I once did half a marathon, so I have some indication (believe me, this was years ago). I would just multiply that time by two and add a little thing. So, although I didn’t do the job previously, I can give a reasonable estimation on the duration.
“How long would it take to make your own dress?” If some one asked me this question, I am in trouble. First, I would be worried by the question itself, and second, even if I tried, I would be unable to give you a proper estimate. I would know how to make a small web site. I would know how to make a excellent spaghetti. My best guess would be something in between the site and the pasta.
Yep, we are now talking all about estimating. So, pick up the dice, and start rolling them…
Getting an estimate
You created already a nice WBS and put some millstones (just kidding, milestones) in them. That’s just fine. It is a nice structure, but it tells you nothing about the most important part of a schedule; time. Some one has to yell some dates, how long will it take, when can you start?
The best people to provide you with an estimate, are the people who will have to perform the task. First of all, they probably know what they are talking about. But most of all, it will be their estimation. Otherwise, if you have to work with the people later on in the project, and you provided the estimate, they normally will not agree and will not feel committed to do the work in your estimated time. Getting a good estimate from e.g. a programmer is not just a task for the programmer himself. The project manager plays a critical role in getting quality numbers. He has to talk with the guy (or gal), to see why he thinks it will take 7 days… Because he already walked half a marathon, or because he thinks a dress and spaghetti are the same to create. I know, I repeat myself. I already stated this before. But, just do it, for … sake.
So, the project manager is a kind of shrink for the programmers. That’s right. They just have to kick back and tell what comes to their minds, and that’s it. Yeah, right, duh! The programmer, in this case, should take steps to ensure that his estimates are getting more and more accurate. He can do this by keeping statistics on how much time he spend on what. How accurate were his previous estimates, etc.
I dug this quote up on an internet newsgroup:
“My experience is that people work to deadlines. If an engineer estimates a task will take 4 weeks, they do *not* mean 4×40=160 Hrs. They mean its feasible that it will be done 4 weeks after the start, and the Engineer will put in as many or few hours as necessary to get it done. On one hand, the Engineer will be factoring in such things as other workload going on, planned days off, etc. On the other, most people will underestimate the time it actually takes, and the experienced manager will know how to “pad” (or in some cases shrink) the estimate based on the track record of the individual.”