13

Our IT Managers give me a project and says estimate it, how long will it take to get it done. I say well 2 days or more. He think it can be done in 2 hours. Now the project is basically about adding functionality so that we link new accounts with old one. There are definitely going to a challenges that I don't see now. I see such challenges in every project that I do. The problem is, our IT Manager (and some other people) don't seem to think that way. To them it is just straight forward, write some code and it is done, no planning or whatsoever is required.

Well I am company employee. If it gets done in 4 hours, good enough, I will move on to other things. But I need to give a reasonable estimates so that I don't get myself in hot water. If the project does not get done in 2 hours and possibly 1 day, I will be the one to be blamed. This trend has been going on lately in our department where we are given no 'room' in estimating the project. No cushion at all. Just give us minimalistic time to get it done. In that case I can ask, why don't they estimate it and give it to me. And I will most likely get fired (which is fine with me).

But asking me for estimates and then not agreeing with it, who is wrong? Who should be estimating the project? Is my idea of estimating the project wrong that you have to consider unforeseen circumstances and some cushion? How can I educate them that IT projects are not that straight forward? It needs planning, evaluating, writing code and testing.

gnat
  • 3,068
  • 10
  • 41
  • 77
TheTechGuy
  • 1,669
  • 16
  • 25
  • Wants to add there are many projects that I do in 5min, half an hour, half day and weeks, so I think I have a better idea of how long a project should take. Plus I have outlined all the steps for this project. Part of it is a new logic that will work at its core. – TheTechGuy Feb 12 '13 at 21:26
  • I am the sole developer on this software and know it from inside out. We are talking about specific domain here. – TheTechGuy Feb 12 '13 at 21:41
  • 2
    Is this perhaps a case of incompetent management that thinks that pressuring you into a lower estimate will get it done faster? – Loren Pechtel Feb 13 '13 at 04:00
  • @LorenPechtel I think someone is not good at estimating a project and that can be a huge embarrassment for the employees. I am not sure which path to talk. – TheTechGuy Feb 13 '13 at 12:19
  • 1
    This question and these answers remind me how lucky I am to work in a small organiztion with management that trust my judgement and doesn't push me to do things faster than I am comfortable doing. – maple_shaft Feb 13 '13 at 13:51
  • 1
    The question probably belongs on project management SE rather than the workplace. This question is very specific to developers, because while the problem crosses industries, the application of it in development is completely different from engineering, marketing, etc. For that reason this question is off topic here. – IDrinkandIKnowThings Feb 13 '13 at 14:35
  • 3
    By the way I found the solution "Change your job". – TheTechGuy Feb 14 '13 at 04:07
  • Just to answer it anyway: you should not estimate a task accurately at all. It takes too much time, is wrong anyway and creates all kinds of organizational toxicity. – Alper Jan 20 '17 at 16:23
  • Once, a manager told me and my coworker that the time over our estimated was on our time. When we realized it was serious, we tried to convinced the management about agile, it did not work, we left the company. – Tom Sawyer Aug 29 '17 at 12:37

5 Answers5

10

The answer to this is 'Yes'

Where I work we have an estimating sheet mocked up in Excel, we split the task into subtasks, e.g development, testing, deployment, and then maybe split them into smaller sections. e.g develop webpage, develop app, etc etc.

Then we estimate for each small segment and mark down the time we think each will take individually. Then the excel sheet calculates the overall time in another cell.

Then this is given to the manager who will look over it, discuss it with you, perhaps try to refine it a bit more, then submit it to wherever it needs to go to.

This has many advantages, a few of which i will touch on here.

Number One: This approach forces you to think of each individual task and its difficulty, which means you estimate for each task. This avoids the problem where you prematurely optimize, for example you say 3 days, but to you that sounds too much, so you cut a day off and make it two days. Whereas if you do it bottom up you can say well this will take X days, this will take Y days, and you will see the grand total.

This forces you to think about each task and allows you to provide more accurate estimates for the work load.

Number Two: This approach means that both you AND your manager get a say in the process. You can estimate it for yourself, and discussions with the manager may lead to revelations you were unaware of and the estimate can be refined. This also means you and your manager end up with an estimate you BOTH agree on and there is less hassle over when the deadline is, how long it should take etc as you have already agreed to one.

Number Three: This gives you the best of both worlds in an estimate, your knowledge of your own skills as well as your managers knowledge of the overall project and potential pitfalls.

Number Four: This forces you to think about your estimate. You wont randomly pick a number out, your thought process on each task will lead you to have to think about each task, this makes it much much easier to justify to your boss because you yourself have thought about the potential pitfalls and this is then much easier to explain to them why it is X days rather than Y hours. Which can potentially lead to a better understanding of how things work from your manager, as well as the added bonus of more accurate estimates.

An alternate approach is to document the changes you do (which you shouldbe anyway) and keep a note of how long each one has taken you.

This way when you are given a similar task again you can see how long it took you last time and use that as a basis to work off of. This also gives you the added bonus of being able to say to your boss

I have had to do a similar task before and last time it took X days. This is because of A, B and C and i feel those would also be constraints here too. These added challenges make the project slightly longer than is immediately obvious and i feel this estimate is closer to the actual time it will take to overcome them again

3

Unfortunately, you can't just say "Well, if you think it can be done in 2 hours, I'd love to see you try!"

The truth is that in order to get projects approved, one often needs to underestimate the project. Once approved, the developers want a cushion. This expands the estimate. The conflict between these two imperatives is inextricably part of the estimate negotiation between you and your manager.

One of the most successful tactics I've found is to expand the Work Breakdown Structure (WBS). In project management, this is a list of the tasks that must be performed, presented in an outline form. When initially recievieng the estimate, you probably have 3 levels of WBS. PMP Methodology says you can have up to 6.

By enumerating all of the tasks, you can build in a better margin, spread out over more tasks. Not only is it easier to estimate a smaller unit of work, but by defining more of what must occur, you can justify it more easily too. Within each of these tasks, however, its also easier to "hide the camel." Is it really going to take you 1 hour to update DNS for these new websites? No. It'll probably take about 5 minutes. The rest of the hour is all research.

The downside, of course, is that it is very hard to say agile when expanding the tree. As such, just putting it all out there, even if informally, is your best defense.

Affable Geek
  • 2,416
  • 1
  • 20
  • 28
  • I created this document already that outlines all the steps that will be done. Thanks for the answer though. – TheTechGuy Feb 12 '13 at 21:15
  • 4
    Unfortunately, you can't just say "Well, if you think it can be done in 2 hours, I'd love to see you try!" -- You can't? – pdr Feb 12 '13 at 22:47
  • 2
    @RhysW: I've said exactly that, in more than one company, and never lost my job. I've also stipulated that if they're going to take me on, it has to be roughly as bug-free, or it's not a fair challenge. Sometimes it's the only way to stop a manager who thinks they know how to estimate your work better than you do. – pdr Feb 13 '13 at 01:32
  • @RhysW: Absolutely true. And, in an ideal world, I'm only ever talking in story points and we don't have to have this conversation. But, when I think that a manager is setting me up for a fall, I will call their bluff, see how confident they are. – pdr Feb 13 '13 at 11:54
  • @pdr "Everything is easy to the person who doesn't need to do it". Of course your manager can do it in two hours - until he actually had to do it. Good managers realise that. – gnasher729 Aug 29 '17 at 06:23
3

Do not make any promise you cannot fulfill.

When your manager gives you a task and tells you to finish it in 2 hours, you tell him you will do your best to get it done. Ask him what's the priority of this new task. If it has the highest priority, start it right away. As soon as you have made some progress, tell him how much you have done and how much longer you expect to take. Say, 20% done, or half way done, or almost done but you need an extra hour to test it, etc. As soon as the deadline starts slipping, tell your boss so he can manage expectations with the customer or other project teams waiting on this dependency.

If he says the new task is not the highest priority. Tell him that it will be in your queue. You will finish the highest priority one first before you start the new task.

Once you start the new task, keep him posted. If you encounter obstacles, tell him this unforeseeable problem. Tell him how much more time you'll need when it pasts his 2 hours estimate.

Always remember, you work for him. If you make late delivery, not only your reputation is damaged, but also he will be blamed for his inaccurate estimate by his manager (he's got a manager, too). After several times of inaccurate estimate, he'll know what to do. It's not your problem anymore because you have done your best already.

Edit Note that the answer above only applies to small tasks as described by OP in this question. I am a retiree from a huge company. A project to me is something that could cost hundreds(or even thousands) of staff months. If something that takes 2 hours to finish can only be called tasks. If you're dealing with real projects, then you need to have project planning. The project planning itself could take tens of staff-months to complete.

Nobody
  • 7,502
  • 10
  • 39
  • 53
1

This is a difficult one, when I scope something I try to see if we have done any similar projects before and then see how much time we spent on there. If you think it's 2 days and your manager thinks it's 2 hours, there is a high chance you are both wrong. You should both be scoping the project.

What you need to do is make a list of all functionalities that need to be altered/added and tested. Estimate the time it will take to write them and a separate timing to properly test them. Go with this plan to your manager and explain him why you think this will take so long, if you can refer to previous projects all the better.

Lucas Kauffman
  • 1,400
  • 16
  • 20
  • Well it is complete redesigning of the "renew" functionality. We need to establish logic first, add new fields to the page, implement the logic, send automated emails from this new code and then test the whole thing. – TheTechGuy Feb 12 '13 at 21:00
0

Create a costing document.

It should detail exactly what is required in order to complete the task in chunks of days no longer then 5. If a particular task takes more then 5 days, you break it up again. (although you have 2 days it seems).

It should detail everything, including training/research/testing. If there risks involved in skipping a step it should be detailed as well.

You then give that to your manager and have him review it. This gives you three advantages.

  1. It is clear picture to your manager who thinks the job can be done in two hours what is actually involved.

  2. You have a clear picture of your action plan to take.

  3. The manager can also do a "risk assessment" and drop sections if they need it faster.

AVOID THE FOLLOWING If you think "I can do it in 2 days, I will cost around that", don't do this. Likewise if the manager says "I need this in two hours write the costing document to that", do not change the times involved, only drop features and detail the risks in doing this.

Simon O'Doherty
  • 6,049
  • 2
  • 24
  • 41