What is the least offensive way to confront a programmer about an estimate they've provided?
Even considering that some programmers consistently under or over estimate, sometimes an estimate is far off from what you would ever imagine it to be (one of those... you're kidding me moments). How do you confront them without putting them on the defense?
Ask them to provide a further breakdown of the estimate. 1-2 day estimation levels work well, where each 8 - 16 hours of the estimate must be specified with a specific task. Generally, that's enough granularity to satisfy management, and it's enough specificity yet general enough to be clearly defined by the engineer(s) involved.
I would confront them from the stand point of trying to figure out what they envision the problem that you want them to solve. Usually when I deal with client's and we're not seeing eye to eye on a project budget wise, it's because the client is thinking about the system one way, and I'm thinking about the system a totally different way.
A good example would be say my client told me to build a CMS system to handle their business processes. I look at their requirements and deduce from them that I need to home grow an entire system for them. However, the client is really trying to tell me, deploy a CMS system that is already built by a third party, and fill in the other details as you can.
The two different scenarios have completely different budgets
"How did you arrive at your estimate? Can you break it down for me?"
Ask them to break it down. Estimates should usually be a sum of estimates of smaller tasks. Then if tasks are missing or there are tasks that don't need to be done, you can sort it out.
Walk through with him/her over how the estimate came to be. You might be suprised to find out the amount of creep that might have built up, or if under estimate I don't think you'd be complaining.
Ask them to explain for you the reasoning upon which the estimate is based. You can word this so it appears like it's just to help you understand the situation, even if you're internally really questioning his estimate.
Actually ask that what type of knowledge/skills are needed to finish this faster. It is often the know-how of the programmer that matters. Also have some sort of project management discussion with programmer. You will really earn good result and respect.
I would ask the programmer to give you a break-down of each task involved in the work, along with a detailed estimate for each task. I think that that's a perfectly reasonable thing to ask for when given an estimate, and should clarify where the estimate has gone wrong.
I would just say, "This seems a bit higher than I would have guessed. Can you break it down to smaller chunks of a few hours at a time for me, so I can understand everything that's involved?"
Essentially, don't be accusatory, and make the programmer feel like he/she is helping you understand something.
You can't really just say, "you're wrong".
If the estimate they are giving seems way off, they might just have trouble doing proper estimates. They can learn to adjust if you'll ask them every time for every project.
It's never a perfect science though..
remember the level of precision of the estimate he/she had originally provided and dont hold them responsible for errors that are within reasonable bounds of that level of precision. if you are unclear about what that level of precision was, inquire about it and maybe you can at least start out on neutral ground
Get him Software Estimation: Demystifying the Black Art (Paperback) by Steve McConnell for his birthday, fathers day, Fourth of July, etc.
I would make the assumption he is correct (assuming he has some knowledge/exp) and tell him you were think around X for an estimate, then ask if there is some detail or problem I am missing to explain the extra effort. I would also do it alone and not put him on the spot.
There are multiple things you need to consider before you consider asking him for more explanation:
Finally, the only way is to ask him/convince him to revisit the estimates because the budget would not allow so many hours and ask him to revisit his estimates.
Initially when i asked someone to give the estimates of a task they used to give a ballpark figure. Sometimes it used to be fine and many time it used to be like "what....!". The general tendency for any one is to add buffer and give the estimates. But the question is how much buffer did the programmer add ? It is always the question of how well each member planned his/her work.
I later resorted to the short checklist when i ask for the estimates. This helps everyone to understand the task better and there is no embarrassing confrontation with team-members.Following is what i ask for along with the estimates...
Once i have the above details, it is easy for everyone to talk about the estimates. In this case the only bottleneck is to communicate to the team that they need to give the Work Break Down tasks, Technical and Process dependencies.
When I can't get something in on time it's usually because of an encounter with an unknown. So it should not be offending to the developer to be asked about any unknowns found. There are two types of unknowns that I can list now: (i) the developer has found new area that requires research into theory; (ii) the developer has found an implied requirement or a missing piece that should have been in the specification.
The least "offensive" query is about (ii) because the developer is not at fault here and should be more than willing to talk about this.
When you mess about with (i) you can get into ego hell. Most commercial IT shops have absolutely no mercy with problem (i) because many of these "wise" business leaders assume that the developer is stealing paid hours, learning at the expense of the company. So the questioner is right to talk about "confronting"---because this (i) encounter is tantamount to accusing someone of being a thief.
You just need to ask them and not really "confront" them. Ask them how they arrived at their estimate or a breakdown of their estimate. Also, tell them your concerns, if you have any, and give a valid reason. A valid reason is "I need this live by this and this date because it is business-critical" and not "I want this live by this and this date because it's what I promised my boss".
If the developer seems to be amiable you can try and negotiate with their estimate when they've provided a breakdown for you. Do not push them too hard, though. After all, you are getting someone else to do it for you. If you think it can be done so easily so fast then maybe you should be doing it yourself.