• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Devaka Cooray
  • Liutauras Vilda
  • Jeanne Boyarsky
Sheriffs:
  • Knute Snortum
  • Junilu Lacar
  • paul wheaton
Saloon Keepers:
  • Ganesh Patekar
  • Frits Walraven
  • Tim Moores
  • Ron McLeod
  • Carey Brown
Bartenders:
  • Stephan van Hulst
  • salvin francis
  • Tim Holloway

What is the proper way to answer when asked for estimation of a task?  RSS feed

 
Ranch Hand
Posts: 251
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It is common to be asked to give estimation of a task. What is the proper way to answer when asked for estimation of a task ? Also should I only answer as number of days or a breakup of expected time for sub tasks adding for total time estimate.  What if it takes more time on being stuck with some issues?

Thank You.
 
Marshal
Posts: 61777
193
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Start by making sure you have definite specifications for the task; when they ask for changes, you can legitimately say, “That will be another £22,000.”
 
Rancher
Posts: 506
15
Java Notepad
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Satyaprakash Joshii wrote:It is common to be asked to give estimation of a task. What is the proper way to answer...



When initial estimations are being asked for a task and made, often one may not have all the information or requirments to arrive at a correct figure. Based on what information is available at that time one has to use it. I think its alright to say that - I have made this estimation based on the info available, or, the info available at this point is inadequate to make an estimation at all (and can request more info).

One can also ask for some time to arrive at the estimates, in case a task is complex or takes a while.

Breaking up the estimates in detail is also fine - if one can or if needed. It clarifies the task ahead. But, if things keep changing as the work progresses one has to update and communicate these with the people involved. These communications and clarifications make life easier for all involved.

Finally, you can also add a small buffer (and can mention so) to your estimations. And, almost always you will get a question back when you present the estimate - how did you arrive at this figure or number, etc.

There are procedures and processes and techniques for estimating large and complex projects.  What I have mentioned here is for simpler tasks and is subjective.
 
Campbell Ritchie
Marshal
Posts: 61777
193
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Prasad Saya wrote:. . . one may not have all the information or requirments to arrive at a correct figure. Based on what information is available at that time one has to use it. . . .

That is risky; that[edit]they[/edit] will think they may request additional features for a very small additional payment. Or the costs will overrun and you to end up losing money.
 
Prasad Saya
Rancher
Posts: 506
15
Java Notepad
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well little risk is alright, I think. Well, I ran into this saying over the last weekend:
Take risks in life.
If you win, you will lead.
If you loose, you will guide.
 
Campbell Ritchie
Marshal
Posts: 61777
193
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Agree that you are taking a risk with every job you undertake. You might end up with lots of money like that. You need to avoid running out of money altogether, though.
The more information you have, the better. If they ask for a cloud database, you can simply say it wasn't in the original contract and you can consider charging extra. You don't have to charge extra. Maybe it is worth getting the goodwill from making a small enhancement for a zero surcharge.
 
Satyaprakash Joshii
Ranch Hand
Posts: 251
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks All. If my manager asks me that how much time would I take for a task than that task may actually have time spent on activities other than coding too. E.g some installation, configuration, resolving installation issue (if it arises), coding, resolving issue if stuck with some issue.  However the manager may have impression that task should take this much time for coding whereas there were other things too.  In that case should I tell him the breakup saying for these small small tasks I estimate to take these many hours each and thus total is this. Also should after completion of task I should tell the total activities on which my time was spent?
 
author & internet detective
Posts: 38921
686
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A lot of the above posts assumed you were self employed. When you work for a company, estimates are more for planning. They aren't contracts.

I imagine your manager doesn't want a large amount of detail. That said, do know the bigger components in case questioned.
 
Satyaprakash Joshii
Ranch Hand
Posts: 251
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thanks.
If my manager asks that how much time would I take for this task, he may be thinking mostly about time for coding but in actual the task may take time for coding and in addition time for  some installation, configuration, resolving installation issue (if it arises), resolving issue if stuck with some issue while coding.   So should I tell him my estimate is so and so hours and below that in the email I should write breakup of time estimate (number of hours for etc).   Also while giving the status for the task should I tell the current status of the task and also let manager know that some of my time was spent in  so that he is does not think that I took all this much time for coding.?
 
Ranch Hand
Posts: 42
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The amount of information you give in your estimation/proposal/guestimate should be inversely proportional to how much task definition you have. If the boss says" how much time do you need to write a cash register program, say "30 hours assuming target is standard Windows environment with standard Java libraries""

If the question is" how many hours to write a cash register program, beta test to a team of 15 target operators, 3 cycles, deploy to the customer's site containing 150 machines, and provide phone support for 6 months 8 hours per day" the answer would be "2,500 hours".

The first question is most likely a " do we want to pursue this project, whereas the second is likely a "We're working on a proposal"
 
Jeanne Boyarsky
author & internet detective
Posts: 38921
686
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Satyaprakash Joshii wrote:thanks.
If my manager asks that how much time would I take for this task, he may be thinking mostly about time for coding but in actual the task may take time for coding and in addition time for  some installation, configuration, resolving installation issue (if it arises), resolving issue if stuck with some issue while coding.   So should I tell him my estimate is so and so hours and below that in the email I should write breakup of time estimate (number of hours for etc).   Also while giving the status for the task should I tell the current status of the task and also let manager know that some of my time was spent in  so that he is does not think that I took all this much time for coding.?


I think you should ask your manager. Do it once like you described and then say "do you want a less detailed breakdown next time".

It may be that your manager just wants a number and doesn't want you writing up a whole story about it.
 
Bartender
Posts: 19993
95
Android Eclipse IDE Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I once worked on a project where we were constantly required to estimate tasks and where we recorded what it took to do to accomplish them.

The overall pattern was that we were actually pretty accurate as far as how long it would take to implement "X" amount of code, but we were also horrible at estimating how much code would be required - generally it was about twice as much as we thought it would.

Any time you give an estimate that you think is realistic, expect a push-back. "That long? NO! It's EASY. All You Have To Do Is..." Neither management nor end users have any realistic idea of how much work software development is. All they know is that their Little Johnny managed to write a program that moved a turtle around on a screen in under 15 minutes, so surely it shouldn't take more than 3 weeks to create another Amazon.com.

And so they will push back, and if you're not fortunate, you'll end up amending your estimate and it will be Your Fault when you cannot do it in time.

And the perniciousness doesn't stop there. There's also the "All I Have To Do Is..." side. It isn't just users and managers who underestimate the work involved. Developers do, too. Remember what I said about us having to write twice as much code?

The problem is, we all forget just how stupid computers are. You cannot give generalized directions and expect them to figure out the rest. Like a contract with the Devil, everything needs to be done in meticulous detail or at best you'll end up spending as much time and money fighting issues with that 3-week Amazon clone as you ever did designing it. And likely much more.

So I like to estimate how much time I think it will take and triple it. It's often fairly close.

One other observation. When estimating time, one generally looks at the more complex and technically challenging parts as where the bulk of the time and effort will fall. In reality, I've blown through all sorts of complexities in far less time than expected, only to lose those gains tracking down a mis-placed comma or falsely capitalized word. Those things can eat up days, and the only real ways I now to speed that up are to walk away from the project until you stop seeing what you "know" is there (and get slapped for being "un-productive") or to find someone else to look at the offending code. Even a junior programmer can often see what the best of us cannot when we've been looking at it for too long.
 
Satyaprakash Joshii
Ranch Hand
Posts: 251
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

So I like to estimate how much time I think it will take and triple it. It's often fairly close.



But if I think it will take me 5 days and I say 15 days , would my manager not say "15 days ? We do not have that much time"  OR "15 days for this task? why so much time? ".

 
Tim Holloway
Bartender
Posts: 19993
95
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Satyaprakash Joshii wrote:

So I like to estimate how much time I think it will take and triple it. It's often fairly close.



But if I think it will take me 5 days and I say 15 days , would my manager not say "15 days ? We do not have that much time"  OR "15 days for this task? why so much time? ".



It doesn't matter how long you think it will take. First, because you probably thought wrong (remember what I said earlier about the differences between what my team thought and what we measured). Secondly, of course your manager is going to say that, whether you say 5 days or 15. He's probably been pressured to deliver in no more than 3 days from his manager and/or the users. And after all, why so long when All You Have To Do Is...  
 
Satyaprakash Joshii
Ranch Hand
Posts: 251
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So considering everything, what is the best strategy?
 
Don't get me started about those stupid light bulbs.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!