How to exempt oneself from giving project completion time estimates?

Question

After all my subtle attempts to evade project completion time estimate requests ("when will this be done?"), I would like to directly communicate to my boss that I cannot and do not want to be estimating my project time completions. I was hoping that she was going to get the hint because all of my estimates have always been extremely inaccurate, either overdelivering or underdelivering but pretty much never on target, it doesn't make sense to ask me that as I cannot estimate my work, which always gets something in the way of completion along the way to make the original estimate meaningless.

Essentially, I am asking if there is a way, in the modern workplace dynamic, to tell my boss that I will be done when I am done and to stop beating a dead horse asking me for estimates that we both should know mean nothing.

I work as a Sr. Software Developer, I get my job done but I never know ahead of time how long it will take me to complete it. Does this make me an incompetent worker? Should I ask for a demotion or change jobs that will accommodate my commitment preference? Is giving time estimates a critical duty in project oriented work?

Answer 1

Does this make me an incompetent worker? Should I ask for a demotion or change jobs that will accommodate my commitment preference? Is giving time estimates a critical duty in project oriented work?

Since most senior developer positions require at least five years experience, one is left wondering how you are a senior developer, but don't understand working by deadlines and progress reports. That's a general given, especially in the role of a junior developer. As you go up, deadlines, resources, and planning become the mainstay. As a senior software developer, estimating completion dates and time project duration's should come natural given your level of experience. If companies just give a blank check for dev time then nothing would get done. Deadlines are a necessary part of life. Even if your projects drastically differ without continuity, you should be able to give accurate estimates for boiler plate portions of the application and reserve conservative estimates for project elements more R&D in nature where the path to the outcome is less certain in nature.

Regardless of whether you work in a company as a developer or for a client, everyone wants certainty for the expected outcome. If working by deadlines is such an issue for you, then maybe you need to consider switching to an occupation which assigns rather menial tasks without much consideration for time lines and measurable progress.

Answer 2

In software development, giving accurate time estimates is incredibly difficult, and good managers should be able to understand that estimates vary from the actual goal.

However, this is also a skill that you need to practice. Track your estimates and find out what made them late. Are you running into more difficulties then expected? Build that time in. Are you getting projects done sooner than expected? Bear that in mind for the future.

This is part of software development, like it or not. Your boss needs to be able to plan around these estimates, and it's important that your "two days" estimate doesn't devolve into "two months".

Answer 3

They're called estimates because they're not exact. There is a disconnect between the level of accuracy expected by your boss and what you think. If your boss wants more accuracy, you would know it. For many people and situations, any estimate is better than nothing. You have to start somewhere.

You also mentioned about unknown things getting in the way. This happens all the time. Tasks get reprioritized because of unexpected events.

Keep better track of your tasks to see how long it takes while you're actually working on it. There's not point in saying something will take two days, but if you're sick for a day, obviously it will now take at least 3 days from the time you estimated. Maybe your boss is not aware of all the distractions that are part of your job: meetings, trouble-shooting, debugging, email, phone calls, etc.

Set goals to get better at estimating without the stress of thinking you'll be perfect. Work with your boss if you think she can help remove some of the other interupters if you're not getting things done fast enough.

It's not going to go away. Wanting to just put an unlimited time-frame on every task is unrealistic, so don't even try. Work on the things you can control.

Answer 4

After all my subtle attempts to evade project completion time estimate requests ("when will this be done?"), I would like to directly communicate to my boss that I cannot and do not want to be estimating my project time completions.

Everyone can give estimates, although many would prefer not to do so.

I suspect you would be better off indicating that you don't feel confident giving estimates, and asking how you might learn to get better at it.

Essentially, I am asking if there is a way, in the modern workplace dynamic, to tell my boss that I will be done when I am done and to stop beating a dead horse asking me for estimates that we both should know mean nothing.

In most shops where I have worked, estimates are an essential portion of the SDLC. If your shop is like that, then there would be no way for you to decline to provide estimates when asked.

I work as a Sr. Software Developer, I get my job done but I never know ahead of time how long it will take me to complete it. Does this make me an incompetent worker?

I wouldn't use the term "incompetent" here. But most Senior Developers I know are willing to provide an estimate when asked. And most folks can come up with some very rough idea of how long a task might take. Never being able to do so does make you seem a bit out of the norm.

Should I ask for a demotion or change jobs that will accommodate my commitment preference?

In many companies, a demotion wouldn't help. Even less-than-Senior Developers are required to provide estimates in many shops.

Is giving time estimates a critical duty in project oriented work?

I've worked in many companies where it was indeed a critical part of the job for the software folks to provide estimates on a regular basis.

I've worked at a few that didn't typically require much estimation, but they seem to be rare, and with Agile methodologies seem to be disappearing.

Under the theory of "You never know until you ask" you could just directly ask your boss "Are estimates required here? Can I do my work without providing estimates?" and see what kind of reaction you get. (I don't suggest using phrases like "I will be done when I am done" or "stop beating a dead horse" though, Those wouldn't be received well by the managers I know).

My suggestion is to learn how to estimate better, so that your attempts won't be so inaccurate, or feel so meaningless. One place to start is to keep close track of your actual hours, to provide a historical basis on which you can draw your future estimates. That's how I learned. You should also ask if there is company-provided training that would help with this and other parts of your company's SDLC.

You might find that you are unnecessarily worried about accuracy. Or you might find that better requirements might make you feel more confident in your estimates.

Answer 5

I think it is very unlikely that any boss will let you get away with "I can't do estimates, I don't want to do estimates". On the other hand, estimates are difficult, and some bosses take estimates as promised deadlines, which causes more problems.

So first you must be able to estimate how long a job takes (we come to that later). You then need to decide what number you tell your boss. If you estimate that a job takes four weeks, and you know yourself that you are notoriously bad at estimating and therefore the job is expected to take 8 weeks, or one or two weeks more or less, and your boss takes estimates as a deadline that you promised him, then the answer is 11 weeks. If your boss takes estimates as a best estimate and expects it to be longer or shorter, you say 8 weeks.

There is a simple technique to improve your estimates, which has worked perfectly for me. Get yourself a spreadsheet program. In that spreadsheet, you enter all the things you need to do to perform the task, and assign days to each item. Go over it several times to make sure you haven't left out anything. At the end, you add up the days and get an estimate. Put in holidays and bank holidays.

As you progress through the job, and finish tasks, write down for every task how long it actually took, compared to your estimate. And here comes the use of the spreadsheet: Calculate how much the estimates add up to for all completed tasks, and what the actual times add up to for each completed task, and with that you calculate how long the other tasks should take, assuming they are all delayed or speeded up by the same factor, and now you have an improved estimate how long it takes.

Now you can do two things: First, you can go to your boss and tell him what you are doing. You tell him "I made this estimate and it says four weeks, but you know how bad I am with estimates, so don't believe this number. I use this new method and in a week I'll tell you an estimate that should be a lot better". That demonstrates that you are willing and on your way to improve your estimates; obviously it takes a while, but within a week you should deliver much more accurate numbers.

And you can collect the data, and on your next job you collect your old, bad numbers, and the spreadsheet automatically takes into account how bad you are with estimates and corrects it. So the next time, you go to your boss with a much better estimate.

Answer 6

Honestly, I agree with you - best and most efficient companies I've worked for don't use estimates. Estimates are a terrible micro-managing tool and people need to move on from that crap.

However, giving them is extremely easy, you just need to think about it in terms of days and give it a day or two buffer if you are not confident in your estimate. The fact is if your estimate is poor they will ask how far off you are to completing it and you should be able to give some response, say you've found the issue and just need to implement some system to fix it and should be able to give a pretty solid estimate from that point - any Sr. level developer will be able to do that.

EDIT: I realized I wasn't very helpful with my last comment so I edited it.

If you're stuck on 'getting out of estimates' just appease them, come to common ground - say things like "No I was to busy to give the estimate but I did complete this task and it took me X hours/days". They may just need 'something' from you so find a way (in your way, that your comfortable and willing to do) to give that to them. One company wanted me to log the hours I worked on a dev task in JIRA and since I would complete like 10-12 a day just closing them like crazy I stopped logging the hours after day 1 - they never cared because of how effective I was at improving the software, and they were pertinent on day 1 that I logged my hours but they never mentioned it after I stopped, not even once - and were very happy with the way I did things. That's why I find it hard to believe if you are doing the job well that they are pin-point concerned you're not giving them estimates, I wonder, do you just say 'No' to them? Do you also get frustrated when they ask you? Cause if so those could be the main problem, sometimes they just need you to communicate to them better - they may get pushy but they may also just not truly understand. I would calmly and professionally talk to them about it, explain that you get all this stuff done and your really efficient in 'the way you work', see if they will make a compromise with you (such as keeping track of the time you do work on things after they are completed, or giving them a 'current amount worked on' type deal, or etc...).