When asked about a completion date, what is the best way to say "it will be done when it is done"?

Question

When you are asked to estimate due dates, is there a especially polite or clever way of say it is "Done when it is done" ?

Is the only way to say, "I can't say right now, check with me at [given time]" ?

Answer 1

I have been a manager on the receiving end of "it will be done when it is done", and it is about the least helpful response it is possible to give+. Saying that and nothing else lands you in severe danger of being considered uncooperative. You absolutely must give more information.

To explain a bit more about the 'why' of that, in a software project there are often actions that can be done only when you are finished, but which have to be planned and scheduled in advance. If you can't say something about when you will be done, the project ends up being even later and often costing more money.

Having said that, "When will you be done?" doesn't always mean "Hurry up." Often the person asking wants to know so that they can plan. It's best to assume that unless you have a reason to think otherwise.

Here are some possible circumstances you might be in:

1. You have other work to do which has higher priority. Say that. If it's possible, also tell the asker "If I started the work now and had no interruptions, I would be done by...". If you also know what work is on your plate, and that no other work is likely to come in, say "I believe I will be able to start working on your project on [date], in which case it will be finished by [date]". If the situation is complicated, refer the asker to your boss, who presumably sets your schedule. It's up to the asker to negotiate with her as to what the priority of the work they need is.
2. You are dependent on someone else's work, who has not committed to a completion date. Again, say that and who it is. If you know, then you can say "if such-and-such commits to finishing his work by [date], I can be done by [date]." That would be helpful.
3. You don't have enough info about what is required to make estimates of the work. Again, say that. (Are you sensing a pattern?). Make sure you've told the person responsible for getting you the information that you need what you need.
4. You don't really understand the problem well enough to know. If you are already working on the project, then not knowing when you will be complete is a problem, and you should try to make sure it doesn't happen to you again. If you haven't been able to make an estimate because you have other things to do, then see item 1. If estimation of completion dates is important to you organisation (and if you are being asked for one that usually means it is), it is often worth taking time to increase your understanding of the problem so that you can make an accurate estimation, even if that means delaying the actual completion date slightly. A predictable completion date is sometimes better than a short completion date.
5. If none of the first three apply then the best response you can give is "Not earlier than [this date], not later than [that date]." This is helpful information, even if 'that date' is very far in the future. The 'not later than' date should be your best guess in the worst case, plus a big safety factor.

Sometimes of course you suddenly realize during some work that it's going to take much longer than you think. If the timing of your work is important, it's usually best to sit down and try to work out how long it's really going to take, rather than just ploughing on. Sometimes (or actually always, because of Murphy's law) you will get asked for an estimate while you are still working that out. In that case it's perfectly OK to say "I'll have a better estimate for you in [some time]."

By the way, all of the above responses assume you are 'senior level' worker responsible for their own scheduling. If not, or in case of doubt, involve your boss.

+Not technically the least helpful response. An outright lie, or a date you have no intention of keeping would be worse. But "it'll be done when it is done" is only one step up from those.

Answer 2

When you are asked to estimate due dates, is there a especially polite or clever way of say it is "Done when it is done" ?

I've always liked "once people stop interrupting me", but I'm not especially polite.

Is the only way to say, "I can't say right now, check with me at [given time]" ?

Certainly not. There are companies/cultures where "When it's done." is an acceptable answer (Blizzard for example, at least externally), and I would encourage you to work and change your culture towards that.

"I'm not sure, it depends on Alice and Bob and..." is a fairly passive-aggressive answer which can be used in some areas to deflect the person asking the question and if done well can turn that person into an asset who helps you remove roadblocks.

"I'm not sure, when are you going to get me X?" is a more plainly aggressive response where someone is meddling in your business but not taking care of theirs. Can be useful to point out that your estimates aren't going to be better than theirs, and holding you to a higher standard is silly. Not recommended.

"I'm not sure, I need to check with my team." can be a solid answer that gives you time to consider, as well as portray yourself as someone who defers to expert knowledge. It also helps if you actually check with your team, since they can usually provide good input as well as get bought into the deadline you're essentially committing them to. Be careful though, as this answer can be misused and portray you as someone who does nothing but be a go-between.

"That depends, what does it need to do?" Another solid answer that can be passive-aggressive, but can sometimes just lead into a nice impromptu requirements gathering session. It also works to keep business honest. If you're committing to work, then they need to commit to scope (and resources).

"That depends, how well does it need to work?" Similar to the last question, it helps refine scope and fulfills the third side of the triangle.

"I don't know. This sprint is XYZ." A limited answer for people using sprints (often software engineers). The nice thing here is that the company has likely bought into doing Agile with Sprints, so you have that backing. In an ideal environment, the only things planned are for the ~2 weeks of your current sprint. Everything else is purposefully unplanned so that you can be well... agile about what gets priority. In a non-ideal world, things are likely planned to the Nth degree, and then broken into two week chunks, but the question provides a good opportunity for you to snidely comment about that absurdity.

So in short, there are many bad ways to dodge the question. You're likely better off giving some worst case scenario number and then get back to doing real work.

Answer 3

I like "there is no estimate for that yet."

It gives the answer you want, it's fairly factual and neutral in tone, and it suggests that an estimate could be made at some point, but certainly not right now here at the coffee machine without a clear picture of what would it actually mean to do the thing he's asking about.

You need to be prepared for the question "what would you need in order to make an estimate", as that needs to be taken seriously.

Answer 4

When you are asked to estimate due dates, is there a especially polite or clever way of say it is "Done when it is done" ?

You usually can't get away with being clever and saying "It will be done whenever it will be done" no matter how you frame it. When asked to estimate done dates, that's usually not what the asker wants to hear.

Instead, you can convey your estimate, and give a degree of accuracy to your estimate.

Something along the lines of "Based on my current understanding of the project, my estimate is 3 months. But, since the Requirements aren't written yet, I will be able to provide a more precise estimate once I read them." (Off the record, I call these "guesstimates".)

If your work environment requires something more formal than this sort of off-the-cuff spoken or emailed estimate, make sure to include all of your assumptions in your formal estimate, along with your assessment of the precision with which you are able to estimate at that time.

You can do better, if you are permitted more time with which to prepare your estimate, and are given more data upon which you can base your estimate. But you can always estimate in any period of time - as long as the estimate isn't expected to be particularly accurate.

Once you provide your estimates (no matter how they are derived), keep your stakeholders in the loop if anything happens that will change your estimate - particularly as deadlines loom.

Answer 5

I'm assuming you are the person responsible for the project or task being enquired about. In which case, why can't you say?

• Your time is being consumed with other tasks
• You are waiting for blockers to clear before making progress
• There are too many future unknowns or dependencies in the task to sensibly estimate
• The task as given to you is ill-defined

All these are legitimate reasons for not having a good estimate, but they are also problems you need to be proactively raising with your manager (or in the first case, you could get an acknowledgement from them that the task can slip to allow for higher priority stuff). "Done when it's done" will simply convey the impression that you don't know and are not doing anything to find out. As such, this stops your manager from planning out the bigger picture.

Answer 6

From your responses to comments and answers, I suspect your question should really be:

My job consists of many small tasks, which I can receive in any order, and which have varying priorities. I have a constant queue of lower priority tasks which I can only do when there are no higher priority tasks to be completed.

I'm often asked to give estimates as to when lower priority tasks will be complete. My current answer, "It will be done when it's done" isn't being received well.

What should I do?

From this perspective, the answer is obvious - you need to do better task tracking and management. This won't involve a change to your process/queue/prioritization - just a little extra work in time tracking of each task.

1. Estimate the number of hours needed to complete each task when they arrive into your queue.
2. Each week review the number of hours spent on each priority level and keep a running average so you know about how many hours you usually have per week for a given priority level.

Number 1 is probably easy enough for a rough guess. "Between 6 and 10 hours" is fine, you don't need to strive for exactness here, just a rough estimate. Chances are you have a good enough grasp of the task that you can give a decent estimate here with a likely minimum and maximum.

Number 2 is going to require a little more work each week. If you track tasks and time already it shouldn't be hard, but even if you don't just keep a notepad, and every time you finish a task write down the priority level and how many hours you spent on it. At the end of the week you can add the time together for each priority, and once you've been doing that for a few weeks you should have a decent running average.

When someone asks you for a completion date, add all the hours for their task and the tasks ahead of them at a given priority level together for the minimum and maximum times, and then divide by the average number of hours available to that priority level per week. Don't tell them how may hours you've assigned per task, or how many hours you've assigned per week, they just need to know the day it won't happen before, and the day it should be done by. "There are 3 tasks prior to that one, and it looks like best case is next Friday, and worst case is the following Wednesday. Check with me in a few days and I'll have a better estimate."

If there are tasks that need to be done that never get done, you can consider implementing an time-based priority level increase. Low priority tasks, if not done within N weeks, move up to the next priority level.

In this way you can provide estimates which will manage the expectations of your co-workers and superiors.

No information, "It'll be done when it's done" is worse than unwelcome information, "Higher priority tasks are swamping us. It'll be 8 weeks before this receives an automatic priority upgrade, and then it'll take a week or two in that queue until it's finished."

Answer 7

That is something that you should never say. All that will do is irritate your manager and make you look incompetent.

Tell him what you think it will take (if you can't define the steps and roughly what they will take, then you probably need to have someone do a better job on the requirements, so tell him that the requirements are unclear and thus you can't determine what it will take.), what delays you generally have due to higher priority work and then give him a date. Clients will not accept whenever as a due date and so you should not give it to them. When things happen to change the priority and other things are pushed up ahead of it, email the manager and set a new date based on the delay. Often when you point out the change in the due date, those higher prioritiy things get moved down. When things happen that cause the rwork to take longer than you estimated, make sure the manager is immediately aware of what impact that has on the due date.

Any dev should be able to provide time estimates. It part of what you are being paid for, so stop copping out with "whenever." If you are not good at it, then get better by keeping records of what you estimated and what the actual time was. Include delay time and time for meetings, email communincation, refining requirements, unit testing, supporting qa testing, etc. in your estimate to get a better number. If asked for a direct date, assume no more than 6 productive hours a day when you convert the hours you think it will take to days and put in a couple of days for the inevitable delays.

Based on comments on other answers, it appears that your problem is not time estimating but communicating delays based on changing priorities. What you need is to be more, not less communicative when this happens. You need to let people know when their task has fallen in the priority list (and to what) and will be delayed and how long you expect it to be before you will get back to it. Let them go fight out the priorities with the managers. Tell them that they can talk to the manager if they disagree with the current priorities.

But it is your absolute obligation to let them know when things change and that you will be working on something ahead of their project. This should not wait until they have to ask you why it isn't done yet. In any event, "whenever' is not an acceptable answer. Pretending you are too busy to answer is not acceptable either.

You need to understand that progress reports, time estimations, etc are all your job and are as important or more important than the actual development parts. This is not an unnecessary interruption, this is part of your job. These people are paying your salary with their projects. Start treating them with respect and respecting their needs. Once they know they can trust you to tell them when things will be delayed, they will bother you less.

Answer 8

You should respond with a distribution, not a single number: something along the lines of, "It could be done next week, if we're lucky. If we're unlucky, six weeks from now. Best guess is about two weeks." That response often will get a bad reaction. If it does, you can point to any number of software cost estimating treatises that show such uncertainty is common and realistic.

Answer 9

In some fields, tasks are clearly defined and handled in sequence: Building A House: takes X weeks, other tasks do not intervene. If you have 6 projects lined up already, you simply refuse more.

Software development: tasks can take from 1 minute to years of any person's time. Tasks are added to and (sometimes) removed from queue constantly. Priorities changed at random. Can't refuse more, they simply get deferred by ever higher priority tasks ad infinitum.

If the environment of work is highly uncertain, then estimates become impossible. Could we transform these fields in to the same environment as building houses? Not likely.

I think the people managing the work have to add NO to the vocabulary. Or perhaps: No, unless this other task can be discarded (permanently). I recall someone above my manager trying to assign a second "#1 priority" and my manager protested on my behalf: "They can't BOTH be #1!" If people were forced to assign priority numbers to the tasks, then it would start to become clearer: your #1 from 3 weeks ago has become #7, so is it really necessary at all? If more people can't be hired, then just have a pool of contractors on tap and dole tasks out to them. "Our non-employees are our greatest asset!"

Answer 10

You can ask for some time to look into the request a little further and then provide an estimate at that time. It could take a few hours, days, weeks. Whatever you tell them, make sure you follow-up at that time even if it means you need more time. Otherwise, they'll just think you've dropped the ball. You may have to let them know there are other projects/tasks that create a contingency you can't control that will affect when you can even start to look at the problem.

I've had car mechanics, plumbers, home builders, etc. let me know that they need to assess the situation and come up with a solution. Once you have a solution, estimating is easier.

It's important to remember what an estimate is- a guess in many cases. Too often, people feel pressured and make the mistake of over-promising. Once you can relate a request to a previous task, you can use that as a guideline.

Answer 11

I have worked on a project similar to this. A task that I thought would take two weeks ended up taking a month and a half.

Thankfully I knew I didn't have a proper grasp on the time requirement going in. So when my boss would ask in the standup (we work with Agile development) I would give him my best estimate and explain why I thought that. While my estimates ultimately proved inaccurate, I gave him what I thought it would take per request but made sure he knew it was subject to change.

In general, honesty is best, be upfront about it, and keep him in the loop. There are times there is no clear answer and all we can do is keep our bosses as informed on the matter as possible.