Take the 2-minute tour ×
The Workplace Stack Exchange is a question and answer site for members of the workforce navigating the professional setting. It's 100% free, no registration required.

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.

share|improve this question

closed as off topic by ReallyTiredOfThisGame, jcmeloni, Rarity, gnat, bethlakshmi Feb 13 '13 at 22:17

Questions on The Workplace Stack Exchange are expected to relate to the workplace within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here.If this question can be reworded to fit the rules in the help center, please edit the question.

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. –  ReallyTiredOfThisGame Feb 13 '13 at 14:35
1  
By the way I found the solution "Change your job". –  enthusiast Feb 14 '13 at 4:07

5 Answers 5

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

share|improve this answer

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.

share|improve this answer
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!" -- You can't? –  pdr Feb 12 '13 at 22:47
1  
@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 1:32

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.

share|improve this answer

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. After 2 hours, tell him how much is your progress, 20% done, half way done, almost done but you need an extra hour to test it, etc.

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.

share|improve this answer

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.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.