Estimating hours for a job

adavis

I've received two projects recently where I feel that the hours (determined by someone else) are grossly underestimated.

The first one is about 98% complete and allowed 44 hours. It's taken me just over 80 to this point.

The other project is about 60% complete. The bulk of the project allowed 30 hours and I've already spent about 50 on that part of it.

I don't work excessively fast, but I'm not slow either.

I've asked my manager for extensions on both, but he wants justifications as to why I think the hours are so off.

Thanks in advance,
Alisa

NogDog

Software development estimation is potentially a huge subject. There are entire books on the subject, all sorts of tools, training classes, theories and techniques, etc., etc., and so forth; and still most software projects are inaccurately estimated and end up running over schedule and over budget.

When your manager says, "Here's your requirements, I've estimated it will take you X hours to complete," how does he arrive at that number? Is there any sort of work break-down structure, has he done some sort of function point analysis and applied it to historical data from previous projects, or has he just pulled it out of thin air because it "sounds about right" to him?

And conversely, the same question applies to your estimate. If you think his estimate is wrong, then at the very least you should break the task down into some reasonable level of granularity and estimate the time for each task. Without the use of dedicated tools, a simple spreadsheet can be used. Then at least you'll have a set of talking points to discuss with the boss. Maybe your interpretation of what needs to be done is incorrect and one or two of the tasks you've cited can be eliminated or reduced in scope. Or maybe he'll realize that he hadn't considered that some task you cited would even be needed, and agree some time needs to be added, and so forth.

And of course, after you do all of that, sales will say it absolutely, positively has to be delivered by the end of the month or else you'll lose the customer; and you'll end up working 60-hour weeks anyway to get it done. :rolleyes:

rulian

I definately recommend you read a few articles from developer.com on project management, I spoke once to a contributor there by the name of Paul Kimmel. He wrote what I though was a brilliant piece on that exact topic though I couldnt find it specifically only one of his follow ups
http://www.developer.com/mgmt/article.php/3742681

However I remember he did say one thing that I thought was very true.
When estimating web projects especially, you are always kind of in a blind guess because you are always (at least in theory) building something that has not been built before and therefore judging the amount of time it will take you is really more about experience then any sort of calculations.

My advice is always estimate more time then you think you'll need. I'll often double or tripple th amount of time I actually think it will take. And I never think of it like hours but more like days or weeks. Like I'll look at a job and say 4 weeks. Knowing that if I havent done it in 4 weeks something went wrong.

I did do this one job though I estimated 4 weeks, approved a budget for, and wound up doing it like 30 hours. SO when I came in underbudget and early they were really happy, even though I charged them for more hours then I worked I did not charge the entire project since it was a good client of mine.

Hope they dont read this.

nrg_alpha

NogDog;10887553 wrote:
...
And conversely, the same question applies to your estimate. If you think his estimate is wrong, then at the very least you should break the task down into some reasonable level of granularity and estimate the time for each task. Without the use of dedicated tools, a simple spreadsheet can be used. Then at least you'll have a set of talking points to discuss with the boss. Maybe your interpretation of what needs to be done is incorrect and one or two of the tasks you've cited can be eliminated or reduced in scope. Or maybe he'll realize that he hadn't considered that some task you cited would even be needed, and agree some time needs to be added, and so forth.

I once read somewhere that %60 of managers are unqualified and should not be in the position they are in. I remember thinking..'%60!?! Is that all? I was guessing more like %80..as honestly, how many managers are TRULY exceptional and skilled at what they do? Can't be that many!'

In any case, to the OP, does your boss sit down with you to disucss the matter at hand prior to going back to the corner office to hammer out the details?

I come from the video gaming industry. And when ever there was tight deadlines (crunchtime excluded), I would sit down with the manager and he/she would discuss what is needed.. then I would explain what would most likely be needed as for as the tasks would be and the time associated with those tasks..(ok, I need to model this, this and this..(which will take me around 3 days) and if you want me to unwrap and texture all of those meshes, I will need at least this another say, 4 days ontop of that...otherwise, if there is a shader artist available, send this remainder to him/her to free me up for more modeling tasks).

Point being, if the manager and the employer sits down and bounces honest tasks / assessments back and forth, this will give the manager a better gauge to work off of. Now granted, since you and your boss work for clients on a tighter timeline, things are admittedly different. But in any case, I would encourage the boss to have a sit down session with you and have some form of open discussion that could help shed more detailed light on what is 'more reasonable'. As Nogdog mentioned... revealing tasks that the manager never thought of would undoubtedly make things clearer from the getgo.

NogDog;10887553 wrote:
And of course, after you do all of that, sales will say it absolutely, positively has to be delivered by the end of the month or else you'll lose the customer; and you'll end up working 60-hour weeks anyway to get it done. :rolleyes:

I'm not in web development.. and when I read threads like this.. I start to think to myself.. 'Thank god!' lol.

EDIT - @ Rulian... nice link you provided. That article makes a lot of sense.