7

I have a boss with extremely outdated software experience. He says it has been around 20+ years since he last did any development. When I give an estimate that he feels is taking too long, he publicly (during the meeting) says that is too long you need to do it in X time. I come back and I say no, I gave you an estimate based on my experience with this in the past. He will usually say, I used to do that in 5 or 10 minutes (doubtful, but whatever) and you should be able to do it in the same time since this is your degree. Note, he only did scripting languages and I am currently building in WPF :(.

So, how can I (politely) tell the VP of the company that I am right and he is out of date?

Side note, my other estimates have been accurate.

UPDATE This is in response to those that said I did not give enough detail on the estimate. Here is how I create my estimates. Please do not take this as a request on improving my estimates unless you see something absolutely horrible.

I write down what all I know about what needs to go in a project for each sub-task. These sub-tasks are then totaled. The total has an additional 33% for unknowns/testing. That usually gets me within a few hours unless something changes or completely unexpected comes up. The total of the sub-tasks is what is given to the manager.

Tat Angel
  • 361
  • 2
  • 10
  • 7
    Provide detailed estimates not an overall figure. Make sure he understands the exact steps you need to take to do that chunk of the work. – HLGEM Oct 09 '13 at 21:00
  • This happens on multiple estimates. I usually have estimates from 1/2 day to 2 days per item. – Tat Angel Oct 10 '13 at 13:33
  • I estimate items in much smaller increments sometimes even 15 miinutes. My estimates virtually never get changed. – HLGEM Oct 10 '13 at 13:36
  • Subtasks are that small, but the items that are reported to a VM, they only want to hear about the top level summary tasks. Those are usually several subtasks that are somewhere in the range of 1/2 day to 2 days. – Tat Angel Oct 10 '13 at 13:48
  • 2
    Yeah but when they question them, then bring out the detailed estimate. – HLGEM Oct 10 '13 at 14:36
  • So simple you just have to step outside the box to see it. Thanks. – Tat Angel Oct 10 '13 at 17:46
  • 2
    Are you the only one giving estimates that are being questioned? There's some reason that he's questioning your estimates. Have you asked him why? Without knowing why it's impossible for anyone, including you, to know what you should change. – dcaswell Oct 10 '13 at 18:35
  • 1
    Very good question, no I am not the only one. My feelings toward that are I have been consistent in the past so I should be able to be distinguished from the others. I can also see that he may just want to treat everyone the same. I did talk with a different manager about this after asking this question. I found out that others, not just in my line of work, but everywhere in the company have quit in the history of the company. The explanation was he was moved to VM so he interacted with employees less and only other managers. That seems like a whole new issue though, not really in this scope. – Tat Angel Oct 11 '13 at 14:18
  • 1
    see also: Too aggressive project estimation, what are my alternatives? and How can we protest a deadline that is too short? – gnat Dec 20 '14 at 11:50
  • 2
    Im just curious to see how is ur situation after almost three years! – AleX_ Sep 23 '16 at 14:26

4 Answers4

14

It's quite common to underestimate the complexity of a task when you are only aware of the rough details. The more you think about the details of a task, the more small, unobvious problems you discover which will take additional time to solve. This is a fallacy which even the most experienced people in our business can rarely overcome. Here is an interesting article which takes this very website as an example for hidden complexity in software projects.

Time estimates should be based on facts and thus should be treated as facts themself. When you estimate a task will take 10 days, this is not an offer, it's an estimation. It can not be negotiated.

When your manager says "but you need to finish it in 5 days", then all you can respond with is "But it won't be finished in 5 days, unless we [cut requirement x] or [get resource Y]". When your manager then replies "But you MUST complete it in 5 days WITH requirement X and WITHOUT resource Y", all you can reply with is "We can try, but it is highly unlikely that we will be successful. Do you want us to try anyway?". When he says "Yes, do it", you start working, because that's what you are paid to do. When you aren't finished after 5 days, you respond "I told you that we won't be successful, but you decided that we should try anyway".

Philipp
  • 40,012
  • 10
  • 92
  • 143
  • 1
    While I am mostly against a "told you so" attitude, in this case it is one thing you can do that is right. +1. –  Oct 10 '13 at 12:16
  • Philipp, this is the closest to answering my question on how to interact with my boss. I agree with Renan about the "I told you so" attitude, but I think as long as I say before and after the same things without a tone of voice that is just the way it is. I will make sure to keep records of what I told him and what I requested be taken off. – Tat Angel Oct 10 '13 at 13:46
  • 1
    Your answer was great but a lot of managers don't tolerate the I told you attitude. and unfortunately the paranoid ones think that you did it on purpose. – AleX_ Sep 23 '16 at 14:26
  • If "We can try, but it is highly unlikely that we will be successful. Do you want us to try anyway?" and the response "Yes, do it" are taken into paper trails, you wouldn't need to respond with "I told you that we won't be successful, but you decided that we should try anyway".. – Romeo Sierra Mar 26 '20 at 06:52
7

Hmm, I'm going to play Devil's advocate here.

You say he's a manager 20+ years out from being a dev, so is that 20 years of being a manager or 20 years in a Tibetan monastery then back to software? The thing is he may be sensing your estimates are on the high side and he may be trying to get you to justify why they are the way they are ( you say they are accurate, but you could have estimated 6 months for a 3 day task and spent 6 months doing it, which would be accurate, but not very productive).

I'd look at breaking things down to show where the time goes, and seeing if he's quite so skeptical, I'd also avoid confronting the VP as you'll just come out of it badly.

The Wandering Dev Manager
  • 33,609
  • 11
  • 71
  • 119
  • In the most recent case it was for something that I estimated at 1 day. Since this happens most every time I feel that is is an automatic response and not a 'sense' that I am giving too much time in my estimate. I took the time to write down what all I knew about that needed to go in and in line by line detail added these up to 6 hours and added 33% for unknowns/testing. That usually gets me within a few hours unless something changes or completely unexpected comes up. – Tat Angel Oct 10 '13 at 13:37
  • 2
    OK, interesting to look at your accepted answer as it's talking about what would be needed to be cut, then looking at your adding 33% to all estimates for unknowns. The main thing about managing project is showing you're in control. You estimates are adding a fudge factor for things you don't know about, I think he's questioning to see if you do know or are just guessing. I'd suggest you give him a 3 factor estimate (best case/ worst case/ likely) and demonstrate that you understand where/what the pain points are in the work, he'll then have more confidence that your estimate is accurate. – The Wandering Dev Manager Oct 10 '13 at 14:59
  • I can see how the 3 case/multiple case scenario is useful. I had already upvoted or I would upvote again. However the fudge factor as you put it seems like a standard, I have never had a project where something unknown did not come up. And there needs to be a base rule of thumb for testing, I combine the two. I see others around me doing much larger additions and still coming in over. I believe that is because they did not do their due diligence with their initial estimate. – Tat Angel Oct 10 '13 at 17:19
4

Estimates are estimates. The time you take to do something might be completely different. So if you have been in your job for a while, you can compare your estimates with your peers' and manager's, and see who is getting them off more often. Since you are the one doing the actual job, and given your last sentence there, I believe you'll be able to make your point with that.

Also relevant is the amount of detail that comes with an estimate. As Mark and HLGEM have said, add information to an estimate when you give it - how long each subtask is going to take, in the least.

Finally, I'd like to recommend you a book on software development estimation, called The Mythical Man-Month: Essays on Software Engineering. It is a very pleasing read about one of our profession's greatest historical challenges. There is this great quote in the book:

Good cooking takes time. If you are made to wait, it is to serve you better, and to please you.

Just extrapolate that to coding and find a way to make your boss understand that.

  • I agree that adding the subtask times seems to be the only way to go. I was not looking for a way to more accurately give estimates, I feel that my estimates are accurate. My issue is how do I get the VM to back off and agree that I have done my due diligence to give accurate estimates. The last sentence is exactly what I am trying to find. – Tat Angel Oct 10 '13 at 13:41
0

This is an expansion on Renans post.

When creating an estimate you should create the costing document as such.

List each section chronologically. It should detail like the following.

Task: [subject of the task in question]

Dependancies: [what tasks need to be completed before this can progress]

Time for task: [mark in 1-5 days maximum]

Any task taking more then 5 days should be broken down into sub tasks which should not be more then 5 days each. Also do not leave anything out. If you believe for example you need a day for upskilling, put it in.

This way it gives a clear picture of all the work involved. It is then up to the manager to determine what they need to drop to stay within the deadline.

One issue on this! Do not fudge the figures. If you believe it will take 2 days to do X, do not put in 5 days. Having a project come in well ahead of schedule is just as bad as a late project.

I'd also recommend getting project planning software. For example ProjectLibre. Although there are a number of alternatives out there.

Community
  • 1
Simon O'Doherty
  • 6,049
  • 2
  • 24
  • 41
  • 1
    Please stop expanding/giving further details on how to give estimates. I am looking for how to convince that my record of already accurate estimates is sound. – Tat Angel Oct 10 '13 at 13:42
  • You probably need to expand on how you are giving estimates then. At the moment from your description it is looking like you are just giving totals without context. – Simon O'Doherty Oct 10 '13 at 14:07
  • At the time of the question I did not give details of estimates because this was not a single instance. I have had this happen for multiple estimates. Each of those in the past have been accurate. I will add the response that I gave to Mark to give further detail. – Tat Angel Oct 10 '13 at 14:18