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

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;







up vote
54
down vote

favorite
10












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]" ?







share|improve this question
















  • 13




    Is there a reason you can't give at least a rough estimate?
    – David K
    Nov 4 '14 at 16:38






  • 52




    @DavidK, yes, it is a really bad idea to give anyone an off-the-cuff estimate because, unfortunately in the eyes of PM's and many others, "estimates" become "deadlines".
    – teego1967
    Nov 4 '14 at 16:54






  • 16




    Whatever you do never give absolute dates - only hours.
    – user1220
    Nov 4 '14 at 18:04






  • 9




    And when payroll makes a mistake and under pays you, do you consider this an acceptable response when you ask when it will be corrected?
    – user8365
    Nov 4 '14 at 19:13






  • 7




    Just reply that it will be done in six to eight weeks. It has worked out fine for stack overflow. Ref: meta.stackexchange.com/a/19514/153954
    – Fredrik
    Nov 5 '14 at 9:28
















up vote
54
down vote

favorite
10












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]" ?







share|improve this question
















  • 13




    Is there a reason you can't give at least a rough estimate?
    – David K
    Nov 4 '14 at 16:38






  • 52




    @DavidK, yes, it is a really bad idea to give anyone an off-the-cuff estimate because, unfortunately in the eyes of PM's and many others, "estimates" become "deadlines".
    – teego1967
    Nov 4 '14 at 16:54






  • 16




    Whatever you do never give absolute dates - only hours.
    – user1220
    Nov 4 '14 at 18:04






  • 9




    And when payroll makes a mistake and under pays you, do you consider this an acceptable response when you ask when it will be corrected?
    – user8365
    Nov 4 '14 at 19:13






  • 7




    Just reply that it will be done in six to eight weeks. It has worked out fine for stack overflow. Ref: meta.stackexchange.com/a/19514/153954
    – Fredrik
    Nov 5 '14 at 9:28












up vote
54
down vote

favorite
10









up vote
54
down vote

favorite
10






10





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]" ?







share|improve this 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]" ?









share|improve this question











share|improve this question




share|improve this question










asked Nov 4 '14 at 16:25









nobrandheroes

427148




427148







  • 13




    Is there a reason you can't give at least a rough estimate?
    – David K
    Nov 4 '14 at 16:38






  • 52




    @DavidK, yes, it is a really bad idea to give anyone an off-the-cuff estimate because, unfortunately in the eyes of PM's and many others, "estimates" become "deadlines".
    – teego1967
    Nov 4 '14 at 16:54






  • 16




    Whatever you do never give absolute dates - only hours.
    – user1220
    Nov 4 '14 at 18:04






  • 9




    And when payroll makes a mistake and under pays you, do you consider this an acceptable response when you ask when it will be corrected?
    – user8365
    Nov 4 '14 at 19:13






  • 7




    Just reply that it will be done in six to eight weeks. It has worked out fine for stack overflow. Ref: meta.stackexchange.com/a/19514/153954
    – Fredrik
    Nov 5 '14 at 9:28












  • 13




    Is there a reason you can't give at least a rough estimate?
    – David K
    Nov 4 '14 at 16:38






  • 52




    @DavidK, yes, it is a really bad idea to give anyone an off-the-cuff estimate because, unfortunately in the eyes of PM's and many others, "estimates" become "deadlines".
    – teego1967
    Nov 4 '14 at 16:54






  • 16




    Whatever you do never give absolute dates - only hours.
    – user1220
    Nov 4 '14 at 18:04






  • 9




    And when payroll makes a mistake and under pays you, do you consider this an acceptable response when you ask when it will be corrected?
    – user8365
    Nov 4 '14 at 19:13






  • 7




    Just reply that it will be done in six to eight weeks. It has worked out fine for stack overflow. Ref: meta.stackexchange.com/a/19514/153954
    – Fredrik
    Nov 5 '14 at 9:28







13




13




Is there a reason you can't give at least a rough estimate?
– David K
Nov 4 '14 at 16:38




Is there a reason you can't give at least a rough estimate?
– David K
Nov 4 '14 at 16:38




52




52




@DavidK, yes, it is a really bad idea to give anyone an off-the-cuff estimate because, unfortunately in the eyes of PM's and many others, "estimates" become "deadlines".
– teego1967
Nov 4 '14 at 16:54




@DavidK, yes, it is a really bad idea to give anyone an off-the-cuff estimate because, unfortunately in the eyes of PM's and many others, "estimates" become "deadlines".
– teego1967
Nov 4 '14 at 16:54




16




16




Whatever you do never give absolute dates - only hours.
– user1220
Nov 4 '14 at 18:04




Whatever you do never give absolute dates - only hours.
– user1220
Nov 4 '14 at 18:04




9




9




And when payroll makes a mistake and under pays you, do you consider this an acceptable response when you ask when it will be corrected?
– user8365
Nov 4 '14 at 19:13




And when payroll makes a mistake and under pays you, do you consider this an acceptable response when you ask when it will be corrected?
– user8365
Nov 4 '14 at 19:13




7




7




Just reply that it will be done in six to eight weeks. It has worked out fine for stack overflow. Ref: meta.stackexchange.com/a/19514/153954
– Fredrik
Nov 5 '14 at 9:28




Just reply that it will be done in six to eight weeks. It has worked out fine for stack overflow. Ref: meta.stackexchange.com/a/19514/153954
– Fredrik
Nov 5 '14 at 9:28










11 Answers
11






active

oldest

votes

















up vote
42
down vote



accepted











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.






share|improve this answer


















  • 7




    The principles behind these responses are good, but the passive-aggressive tone is a problem. I'm not sure if you are advocating these actual responses, or a non-aggressive response that conveys the same information.
    – DJClayworth
    Nov 4 '14 at 18:47






  • 1




    @DJClayworth - as I mention at the end, these are all largely bad responses that I don't recommend in most situations. I don't expect that they could be made non-aggressive.
    – Telastyn
    Nov 4 '14 at 18:48










  • Pointing out context is very good, also +1 for the mention of Blizzard. I imagine it ultimately comes down to company culture, or the disposition of those who you are working with.
    – nobrandheroes
    Nov 4 '14 at 18:52










  • At least the second one can be rephrased to a less agressive form without compromising much on its content: After I get X it should take about T. Of course this assumes that the only problem is that you are waiting for X, and that you can reasonably estimate T.
    – Dennis Jaheruddin
    Nov 5 '14 at 15:19


















up vote
73
down vote













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.






share|improve this answer


















  • 4




    This is probably the best answer so far, but here's my question for you. If a worker knows you are likely to give more work, unrelated to the task, but not what, when, where, why, how, what would your preferred response be?
    – nobrandheroes
    Nov 4 '14 at 18:28






  • 9




    This answer reinforces my belief that estimates must be given in hours, not in firm dates.
    – user1220
    Nov 4 '14 at 18:32






  • 4




    Yes you can. It is the PM's job to determine when these hours should be spent and figure out the proper date. Not the developer's he has no role in determining priorities.
    – user1220
    Nov 4 '14 at 18:36






  • 19




    @nobrandheroes That's probably worth another question. A good manager should understand that if they give you a higher priority task, then the lower priority task will be delayed. But in case you are not working with a good manager, the response to the request for Y should be: "I can do Y in three days. But you realize that X will be delayed by three days if I do it, right?"
    – DJClayworth
    Nov 4 '14 at 18:44






  • 2




    I would counter saying the least helpful response it is possible to give, with being on the receiving end of when will it be done? is about the least helpful question for someone to ask. For much the same reasons you give.
    – nicodemus13
    Nov 5 '14 at 11:04

















up vote
17
down vote













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.






share|improve this answer



























    up vote
    13
    down vote














    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.






    share|improve this answer






















    • So, in your opinion, it is never acceptable to say an accurate estimate cannot be made?
      – nobrandheroes
      Nov 4 '14 at 17:42










    • by accurate I mean that a stakeholder holds you accountable for. Ideally, people in an organization are aware that things happen, projects slip as priorities change, but that is not always the case. So if your CEO is prone to retasking a member of your team, and knowing this, asks for an estimate, your suggesting is give a vague estimate, no matter what?
      – nobrandheroes
      Nov 4 '14 at 17:59










    • Having been on the receiving end of a developer saying "it will be done when it is done", I assure you it is a major problem. people may be trying to plan things based on when the work will be completed. With no idea at all of when that will be, it makes other work impossible.
      – DJClayworth
      Nov 4 '14 at 18:03






    • 1




      @DJClayworth does it help you in any way if you get told an arbitrary date, you make plans based on that date, and on that date find out the reality of "it will be done when it's done"?
      – Peteris
      Nov 4 '14 at 18:14






    • 6




      A PM will hear this as your answer to when will it be done: "### #### # #### ## 3 months ### #### ## #####"
      – teego1967
      Nov 5 '14 at 14:06

















    up vote
    10
    down vote













    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.






    share|improve this answer




















    • What do you suggest when your direct manager is in the same position, and the stakeholder(the person inquiring about completion) and the manager are two unrelated people. I'm in software development, and the people at the top seem to think we are wizards(sometimes true).
      – nobrandheroes
      Nov 4 '14 at 16:59










    • Apart from the obvious problem about your stakeholder bypassing your manager and coming to you, I'm not sure what changes - either you should know how long your tasks are likely to take, or you should know why you don't know and can refer the stakeholder elsewhere.
      – Julia Hayward
      Nov 4 '14 at 17:05










    • It's not that I wouldn't know how long they would take, its that I wouldn't know how long the task + randomly assigned task would take, but you still have to factor the inestimable variables into your estimates.
      – nobrandheroes
      Nov 4 '14 at 17:32






    • 3




      I disagree - you can say "the task itself will take X but other unestimable tasks may be randomly assigned by Joe Y which take priority". OK, maybe more diplomatically than that. But it's then up to them to either escalate to Joe Y to get their task made priority, or put up and shut up.
      – Julia Hayward
      Nov 5 '14 at 12:45


















    up vote
    8
    down vote













    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."






    share|improve this answer




















    • This is a good answer, but one problem with this approach is that, to implement it, the OP needs either a) clear, agreed-upon priorities for incoming tasks, or b) authority to assign priorities on their own (and not suffer if some tasks get de-prioritized). Unfortunately, if the tasks are coming in from multiple sources, it's all too likely that everyone will want their tasks to have priority. [...]
      – Ilmari Karonen
      Nov 6 '14 at 0:12






    • 1




      ... Passing the buck (i.e. "Take it up with manager X, they decide what gets prioritized.") may help if there's someone to pass it to, but if that's not an option, in the worst case the priority queue may end up degenerating into a last-in-first-out queue (with everyone demanding that each new task pre-empt all earlier ones) where tasks are either completed quickly or not at all. Of course, that's really a sign of an organizational dysfunction and/or insufficient resources, but it's worth keeping in mind that such situations do exist.
      – Ilmari Karonen
      Nov 6 '14 at 0:14


















    up vote
    7
    down vote













    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.






    share|improve this answer


















    • 2




      Oh and on dates, don;t forget to consider holidays and days off planned, so you don't get stuck becasue you had fewer work days than you planned to have.
      – HLGEM
      Nov 4 '14 at 17:25






    • 2




      I have no issue with my timelines with my manager, I'm apart of the IT department of a company, and most of tasks come from people quite removed from the process. Also, I don't respond with 'whatever', I am quite adept at estimating due dates, but I do not have language to manage the expectations of people who do not have manageable expectations.
      – nobrandheroes
      Nov 4 '14 at 17:37

















    up vote
    6
    down vote













    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.






    share|improve this answer



























      up vote
      2
      down vote













      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!"






      share|improve this answer
















      • 2




        How about a kanban board for each employee? Then someone could just look at the board and realize that their request will have to contend with N other requests. Of course, make this a computer application, not a physical board. PMs would be responsible for this.
        – user37746
        Nov 5 '14 at 17:26

















      up vote
      2
      down vote













      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.






      share|improve this answer



























        up vote
        -1
        down vote













        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.






        share|improve this answer
















        • 1




          This does add not anything substantial to the other answers already given
          – Jan Doggen
          Nov 15 '14 at 10:28











        Your Answer







        StackExchange.ready(function()
        var channelOptions =
        tags: "".split(" "),
        id: "423"
        ;
        initTagRenderer("".split(" "), "".split(" "), channelOptions);

        StackExchange.using("externalEditor", function()
        // Have to fire editor after snippets, if snippets enabled
        if (StackExchange.settings.snippets.snippetsEnabled)
        StackExchange.using("snippets", function()
        createEditor();
        );

        else
        createEditor();

        );

        function createEditor()
        StackExchange.prepareEditor(
        heartbeatType: 'answer',
        convertImagesToLinks: false,
        noModals: false,
        showLowRepImageUploadWarning: true,
        reputationToPostImages: null,
        bindNavPrevention: true,
        postfix: "",
        noCode: true, onDemand: false,
        discardSelector: ".discard-answer"
        ,immediatelyShowMarkdownHelp:true
        );



        );








         

        draft saved


        draft discarded


















        StackExchange.ready(
        function ()
        StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f35790%2fwhen-asked-about-a-completion-date-what-is-the-best-way-to-say-it-will-be-done%23new-answer', 'question_page');

        );

        Post as a guest

























        StackExchange.ready(function ()
        $("#show-editor-button input, #show-editor-button button").click(function ()
        var showEditor = function()
        $("#show-editor-button").hide();
        $("#post-form").removeClass("dno");
        StackExchange.editor.finallyInit();
        ;

        var useFancy = $(this).data('confirm-use-fancy');
        if(useFancy == 'True')
        var popupTitle = $(this).data('confirm-fancy-title');
        var popupBody = $(this).data('confirm-fancy-body');
        var popupAccept = $(this).data('confirm-fancy-accept-button');

        $(this).loadPopup(
        url: '/post/self-answer-popup',
        loaded: function(popup)
        var pTitle = $(popup).find('h2');
        var pBody = $(popup).find('.popup-body');
        var pSubmit = $(popup).find('.popup-submit');

        pTitle.text(popupTitle);
        pBody.html(popupBody);
        pSubmit.val(popupAccept).click(showEditor);

        )
        else
        var confirmText = $(this).data('confirm-text');
        if (confirmText ? confirm(confirmText) : true)
        showEditor();


        );
        );






        11 Answers
        11






        active

        oldest

        votes








        11 Answers
        11






        active

        oldest

        votes









        active

        oldest

        votes






        active

        oldest

        votes








        up vote
        42
        down vote



        accepted











        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.






        share|improve this answer


















        • 7




          The principles behind these responses are good, but the passive-aggressive tone is a problem. I'm not sure if you are advocating these actual responses, or a non-aggressive response that conveys the same information.
          – DJClayworth
          Nov 4 '14 at 18:47






        • 1




          @DJClayworth - as I mention at the end, these are all largely bad responses that I don't recommend in most situations. I don't expect that they could be made non-aggressive.
          – Telastyn
          Nov 4 '14 at 18:48










        • Pointing out context is very good, also +1 for the mention of Blizzard. I imagine it ultimately comes down to company culture, or the disposition of those who you are working with.
          – nobrandheroes
          Nov 4 '14 at 18:52










        • At least the second one can be rephrased to a less agressive form without compromising much on its content: After I get X it should take about T. Of course this assumes that the only problem is that you are waiting for X, and that you can reasonably estimate T.
          – Dennis Jaheruddin
          Nov 5 '14 at 15:19















        up vote
        42
        down vote



        accepted











        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.






        share|improve this answer


















        • 7




          The principles behind these responses are good, but the passive-aggressive tone is a problem. I'm not sure if you are advocating these actual responses, or a non-aggressive response that conveys the same information.
          – DJClayworth
          Nov 4 '14 at 18:47






        • 1




          @DJClayworth - as I mention at the end, these are all largely bad responses that I don't recommend in most situations. I don't expect that they could be made non-aggressive.
          – Telastyn
          Nov 4 '14 at 18:48










        • Pointing out context is very good, also +1 for the mention of Blizzard. I imagine it ultimately comes down to company culture, or the disposition of those who you are working with.
          – nobrandheroes
          Nov 4 '14 at 18:52










        • At least the second one can be rephrased to a less agressive form without compromising much on its content: After I get X it should take about T. Of course this assumes that the only problem is that you are waiting for X, and that you can reasonably estimate T.
          – Dennis Jaheruddin
          Nov 5 '14 at 15:19













        up vote
        42
        down vote



        accepted







        up vote
        42
        down vote



        accepted







        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.






        share|improve this answer















        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.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Nov 5 '14 at 14:27

























        answered Nov 4 '14 at 18:40









        Telastyn

        33.9k977120




        33.9k977120







        • 7




          The principles behind these responses are good, but the passive-aggressive tone is a problem. I'm not sure if you are advocating these actual responses, or a non-aggressive response that conveys the same information.
          – DJClayworth
          Nov 4 '14 at 18:47






        • 1




          @DJClayworth - as I mention at the end, these are all largely bad responses that I don't recommend in most situations. I don't expect that they could be made non-aggressive.
          – Telastyn
          Nov 4 '14 at 18:48










        • Pointing out context is very good, also +1 for the mention of Blizzard. I imagine it ultimately comes down to company culture, or the disposition of those who you are working with.
          – nobrandheroes
          Nov 4 '14 at 18:52










        • At least the second one can be rephrased to a less agressive form without compromising much on its content: After I get X it should take about T. Of course this assumes that the only problem is that you are waiting for X, and that you can reasonably estimate T.
          – Dennis Jaheruddin
          Nov 5 '14 at 15:19













        • 7




          The principles behind these responses are good, but the passive-aggressive tone is a problem. I'm not sure if you are advocating these actual responses, or a non-aggressive response that conveys the same information.
          – DJClayworth
          Nov 4 '14 at 18:47






        • 1




          @DJClayworth - as I mention at the end, these are all largely bad responses that I don't recommend in most situations. I don't expect that they could be made non-aggressive.
          – Telastyn
          Nov 4 '14 at 18:48










        • Pointing out context is very good, also +1 for the mention of Blizzard. I imagine it ultimately comes down to company culture, or the disposition of those who you are working with.
          – nobrandheroes
          Nov 4 '14 at 18:52










        • At least the second one can be rephrased to a less agressive form without compromising much on its content: After I get X it should take about T. Of course this assumes that the only problem is that you are waiting for X, and that you can reasonably estimate T.
          – Dennis Jaheruddin
          Nov 5 '14 at 15:19








        7




        7




        The principles behind these responses are good, but the passive-aggressive tone is a problem. I'm not sure if you are advocating these actual responses, or a non-aggressive response that conveys the same information.
        – DJClayworth
        Nov 4 '14 at 18:47




        The principles behind these responses are good, but the passive-aggressive tone is a problem. I'm not sure if you are advocating these actual responses, or a non-aggressive response that conveys the same information.
        – DJClayworth
        Nov 4 '14 at 18:47




        1




        1




        @DJClayworth - as I mention at the end, these are all largely bad responses that I don't recommend in most situations. I don't expect that they could be made non-aggressive.
        – Telastyn
        Nov 4 '14 at 18:48




        @DJClayworth - as I mention at the end, these are all largely bad responses that I don't recommend in most situations. I don't expect that they could be made non-aggressive.
        – Telastyn
        Nov 4 '14 at 18:48












        Pointing out context is very good, also +1 for the mention of Blizzard. I imagine it ultimately comes down to company culture, or the disposition of those who you are working with.
        – nobrandheroes
        Nov 4 '14 at 18:52




        Pointing out context is very good, also +1 for the mention of Blizzard. I imagine it ultimately comes down to company culture, or the disposition of those who you are working with.
        – nobrandheroes
        Nov 4 '14 at 18:52












        At least the second one can be rephrased to a less agressive form without compromising much on its content: After I get X it should take about T. Of course this assumes that the only problem is that you are waiting for X, and that you can reasonably estimate T.
        – Dennis Jaheruddin
        Nov 5 '14 at 15:19





        At least the second one can be rephrased to a less agressive form without compromising much on its content: After I get X it should take about T. Of course this assumes that the only problem is that you are waiting for X, and that you can reasonably estimate T.
        – Dennis Jaheruddin
        Nov 5 '14 at 15:19













        up vote
        73
        down vote













        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.






        share|improve this answer


















        • 4




          This is probably the best answer so far, but here's my question for you. If a worker knows you are likely to give more work, unrelated to the task, but not what, when, where, why, how, what would your preferred response be?
          – nobrandheroes
          Nov 4 '14 at 18:28






        • 9




          This answer reinforces my belief that estimates must be given in hours, not in firm dates.
          – user1220
          Nov 4 '14 at 18:32






        • 4




          Yes you can. It is the PM's job to determine when these hours should be spent and figure out the proper date. Not the developer's he has no role in determining priorities.
          – user1220
          Nov 4 '14 at 18:36






        • 19




          @nobrandheroes That's probably worth another question. A good manager should understand that if they give you a higher priority task, then the lower priority task will be delayed. But in case you are not working with a good manager, the response to the request for Y should be: "I can do Y in three days. But you realize that X will be delayed by three days if I do it, right?"
          – DJClayworth
          Nov 4 '14 at 18:44






        • 2




          I would counter saying the least helpful response it is possible to give, with being on the receiving end of when will it be done? is about the least helpful question for someone to ask. For much the same reasons you give.
          – nicodemus13
          Nov 5 '14 at 11:04














        up vote
        73
        down vote













        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.






        share|improve this answer


















        • 4




          This is probably the best answer so far, but here's my question for you. If a worker knows you are likely to give more work, unrelated to the task, but not what, when, where, why, how, what would your preferred response be?
          – nobrandheroes
          Nov 4 '14 at 18:28






        • 9




          This answer reinforces my belief that estimates must be given in hours, not in firm dates.
          – user1220
          Nov 4 '14 at 18:32






        • 4




          Yes you can. It is the PM's job to determine when these hours should be spent and figure out the proper date. Not the developer's he has no role in determining priorities.
          – user1220
          Nov 4 '14 at 18:36






        • 19




          @nobrandheroes That's probably worth another question. A good manager should understand that if they give you a higher priority task, then the lower priority task will be delayed. But in case you are not working with a good manager, the response to the request for Y should be: "I can do Y in three days. But you realize that X will be delayed by three days if I do it, right?"
          – DJClayworth
          Nov 4 '14 at 18:44






        • 2




          I would counter saying the least helpful response it is possible to give, with being on the receiving end of when will it be done? is about the least helpful question for someone to ask. For much the same reasons you give.
          – nicodemus13
          Nov 5 '14 at 11:04












        up vote
        73
        down vote










        up vote
        73
        down vote









        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.






        share|improve this answer














        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.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Sep 5 '17 at 13:16

























        answered Nov 4 '14 at 18:24









        DJClayworth

        41k887147




        41k887147







        • 4




          This is probably the best answer so far, but here's my question for you. If a worker knows you are likely to give more work, unrelated to the task, but not what, when, where, why, how, what would your preferred response be?
          – nobrandheroes
          Nov 4 '14 at 18:28






        • 9




          This answer reinforces my belief that estimates must be given in hours, not in firm dates.
          – user1220
          Nov 4 '14 at 18:32






        • 4




          Yes you can. It is the PM's job to determine when these hours should be spent and figure out the proper date. Not the developer's he has no role in determining priorities.
          – user1220
          Nov 4 '14 at 18:36






        • 19




          @nobrandheroes That's probably worth another question. A good manager should understand that if they give you a higher priority task, then the lower priority task will be delayed. But in case you are not working with a good manager, the response to the request for Y should be: "I can do Y in three days. But you realize that X will be delayed by three days if I do it, right?"
          – DJClayworth
          Nov 4 '14 at 18:44






        • 2




          I would counter saying the least helpful response it is possible to give, with being on the receiving end of when will it be done? is about the least helpful question for someone to ask. For much the same reasons you give.
          – nicodemus13
          Nov 5 '14 at 11:04












        • 4




          This is probably the best answer so far, but here's my question for you. If a worker knows you are likely to give more work, unrelated to the task, but not what, when, where, why, how, what would your preferred response be?
          – nobrandheroes
          Nov 4 '14 at 18:28






        • 9




          This answer reinforces my belief that estimates must be given in hours, not in firm dates.
          – user1220
          Nov 4 '14 at 18:32






        • 4




          Yes you can. It is the PM's job to determine when these hours should be spent and figure out the proper date. Not the developer's he has no role in determining priorities.
          – user1220
          Nov 4 '14 at 18:36






        • 19




          @nobrandheroes That's probably worth another question. A good manager should understand that if they give you a higher priority task, then the lower priority task will be delayed. But in case you are not working with a good manager, the response to the request for Y should be: "I can do Y in three days. But you realize that X will be delayed by three days if I do it, right?"
          – DJClayworth
          Nov 4 '14 at 18:44






        • 2




          I would counter saying the least helpful response it is possible to give, with being on the receiving end of when will it be done? is about the least helpful question for someone to ask. For much the same reasons you give.
          – nicodemus13
          Nov 5 '14 at 11:04







        4




        4




        This is probably the best answer so far, but here's my question for you. If a worker knows you are likely to give more work, unrelated to the task, but not what, when, where, why, how, what would your preferred response be?
        – nobrandheroes
        Nov 4 '14 at 18:28




        This is probably the best answer so far, but here's my question for you. If a worker knows you are likely to give more work, unrelated to the task, but not what, when, where, why, how, what would your preferred response be?
        – nobrandheroes
        Nov 4 '14 at 18:28




        9




        9




        This answer reinforces my belief that estimates must be given in hours, not in firm dates.
        – user1220
        Nov 4 '14 at 18:32




        This answer reinforces my belief that estimates must be given in hours, not in firm dates.
        – user1220
        Nov 4 '14 at 18:32




        4




        4




        Yes you can. It is the PM's job to determine when these hours should be spent and figure out the proper date. Not the developer's he has no role in determining priorities.
        – user1220
        Nov 4 '14 at 18:36




        Yes you can. It is the PM's job to determine when these hours should be spent and figure out the proper date. Not the developer's he has no role in determining priorities.
        – user1220
        Nov 4 '14 at 18:36




        19




        19




        @nobrandheroes That's probably worth another question. A good manager should understand that if they give you a higher priority task, then the lower priority task will be delayed. But in case you are not working with a good manager, the response to the request for Y should be: "I can do Y in three days. But you realize that X will be delayed by three days if I do it, right?"
        – DJClayworth
        Nov 4 '14 at 18:44




        @nobrandheroes That's probably worth another question. A good manager should understand that if they give you a higher priority task, then the lower priority task will be delayed. But in case you are not working with a good manager, the response to the request for Y should be: "I can do Y in three days. But you realize that X will be delayed by three days if I do it, right?"
        – DJClayworth
        Nov 4 '14 at 18:44




        2




        2




        I would counter saying the least helpful response it is possible to give, with being on the receiving end of when will it be done? is about the least helpful question for someone to ask. For much the same reasons you give.
        – nicodemus13
        Nov 5 '14 at 11:04




        I would counter saying the least helpful response it is possible to give, with being on the receiving end of when will it be done? is about the least helpful question for someone to ask. For much the same reasons you give.
        – nicodemus13
        Nov 5 '14 at 11:04










        up vote
        17
        down vote













        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.






        share|improve this answer
























          up vote
          17
          down vote













          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.






          share|improve this answer






















            up vote
            17
            down vote










            up vote
            17
            down vote









            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.






            share|improve this answer












            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.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Nov 4 '14 at 21:42









            RemcoGerlich

            3,4521018




            3,4521018




















                up vote
                13
                down vote














                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.






                share|improve this answer






















                • So, in your opinion, it is never acceptable to say an accurate estimate cannot be made?
                  – nobrandheroes
                  Nov 4 '14 at 17:42










                • by accurate I mean that a stakeholder holds you accountable for. Ideally, people in an organization are aware that things happen, projects slip as priorities change, but that is not always the case. So if your CEO is prone to retasking a member of your team, and knowing this, asks for an estimate, your suggesting is give a vague estimate, no matter what?
                  – nobrandheroes
                  Nov 4 '14 at 17:59










                • Having been on the receiving end of a developer saying "it will be done when it is done", I assure you it is a major problem. people may be trying to plan things based on when the work will be completed. With no idea at all of when that will be, it makes other work impossible.
                  – DJClayworth
                  Nov 4 '14 at 18:03






                • 1




                  @DJClayworth does it help you in any way if you get told an arbitrary date, you make plans based on that date, and on that date find out the reality of "it will be done when it's done"?
                  – Peteris
                  Nov 4 '14 at 18:14






                • 6




                  A PM will hear this as your answer to when will it be done: "### #### # #### ## 3 months ### #### ## #####"
                  – teego1967
                  Nov 5 '14 at 14:06














                up vote
                13
                down vote














                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.






                share|improve this answer






















                • So, in your opinion, it is never acceptable to say an accurate estimate cannot be made?
                  – nobrandheroes
                  Nov 4 '14 at 17:42










                • by accurate I mean that a stakeholder holds you accountable for. Ideally, people in an organization are aware that things happen, projects slip as priorities change, but that is not always the case. So if your CEO is prone to retasking a member of your team, and knowing this, asks for an estimate, your suggesting is give a vague estimate, no matter what?
                  – nobrandheroes
                  Nov 4 '14 at 17:59










                • Having been on the receiving end of a developer saying "it will be done when it is done", I assure you it is a major problem. people may be trying to plan things based on when the work will be completed. With no idea at all of when that will be, it makes other work impossible.
                  – DJClayworth
                  Nov 4 '14 at 18:03






                • 1




                  @DJClayworth does it help you in any way if you get told an arbitrary date, you make plans based on that date, and on that date find out the reality of "it will be done when it's done"?
                  – Peteris
                  Nov 4 '14 at 18:14






                • 6




                  A PM will hear this as your answer to when will it be done: "### #### # #### ## 3 months ### #### ## #####"
                  – teego1967
                  Nov 5 '14 at 14:06












                up vote
                13
                down vote










                up vote
                13
                down vote










                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.






                share|improve this answer















                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.







                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited Feb 20 '15 at 20:13

























                answered Nov 4 '14 at 17:35









                Joe Strazzere

                223k106657924




                223k106657924











                • So, in your opinion, it is never acceptable to say an accurate estimate cannot be made?
                  – nobrandheroes
                  Nov 4 '14 at 17:42










                • by accurate I mean that a stakeholder holds you accountable for. Ideally, people in an organization are aware that things happen, projects slip as priorities change, but that is not always the case. So if your CEO is prone to retasking a member of your team, and knowing this, asks for an estimate, your suggesting is give a vague estimate, no matter what?
                  – nobrandheroes
                  Nov 4 '14 at 17:59










                • Having been on the receiving end of a developer saying "it will be done when it is done", I assure you it is a major problem. people may be trying to plan things based on when the work will be completed. With no idea at all of when that will be, it makes other work impossible.
                  – DJClayworth
                  Nov 4 '14 at 18:03






                • 1




                  @DJClayworth does it help you in any way if you get told an arbitrary date, you make plans based on that date, and on that date find out the reality of "it will be done when it's done"?
                  – Peteris
                  Nov 4 '14 at 18:14






                • 6




                  A PM will hear this as your answer to when will it be done: "### #### # #### ## 3 months ### #### ## #####"
                  – teego1967
                  Nov 5 '14 at 14:06
















                • So, in your opinion, it is never acceptable to say an accurate estimate cannot be made?
                  – nobrandheroes
                  Nov 4 '14 at 17:42










                • by accurate I mean that a stakeholder holds you accountable for. Ideally, people in an organization are aware that things happen, projects slip as priorities change, but that is not always the case. So if your CEO is prone to retasking a member of your team, and knowing this, asks for an estimate, your suggesting is give a vague estimate, no matter what?
                  – nobrandheroes
                  Nov 4 '14 at 17:59










                • Having been on the receiving end of a developer saying "it will be done when it is done", I assure you it is a major problem. people may be trying to plan things based on when the work will be completed. With no idea at all of when that will be, it makes other work impossible.
                  – DJClayworth
                  Nov 4 '14 at 18:03






                • 1




                  @DJClayworth does it help you in any way if you get told an arbitrary date, you make plans based on that date, and on that date find out the reality of "it will be done when it's done"?
                  – Peteris
                  Nov 4 '14 at 18:14






                • 6




                  A PM will hear this as your answer to when will it be done: "### #### # #### ## 3 months ### #### ## #####"
                  – teego1967
                  Nov 5 '14 at 14:06















                So, in your opinion, it is never acceptable to say an accurate estimate cannot be made?
                – nobrandheroes
                Nov 4 '14 at 17:42




                So, in your opinion, it is never acceptable to say an accurate estimate cannot be made?
                – nobrandheroes
                Nov 4 '14 at 17:42












                by accurate I mean that a stakeholder holds you accountable for. Ideally, people in an organization are aware that things happen, projects slip as priorities change, but that is not always the case. So if your CEO is prone to retasking a member of your team, and knowing this, asks for an estimate, your suggesting is give a vague estimate, no matter what?
                – nobrandheroes
                Nov 4 '14 at 17:59




                by accurate I mean that a stakeholder holds you accountable for. Ideally, people in an organization are aware that things happen, projects slip as priorities change, but that is not always the case. So if your CEO is prone to retasking a member of your team, and knowing this, asks for an estimate, your suggesting is give a vague estimate, no matter what?
                – nobrandheroes
                Nov 4 '14 at 17:59












                Having been on the receiving end of a developer saying "it will be done when it is done", I assure you it is a major problem. people may be trying to plan things based on when the work will be completed. With no idea at all of when that will be, it makes other work impossible.
                – DJClayworth
                Nov 4 '14 at 18:03




                Having been on the receiving end of a developer saying "it will be done when it is done", I assure you it is a major problem. people may be trying to plan things based on when the work will be completed. With no idea at all of when that will be, it makes other work impossible.
                – DJClayworth
                Nov 4 '14 at 18:03




                1




                1




                @DJClayworth does it help you in any way if you get told an arbitrary date, you make plans based on that date, and on that date find out the reality of "it will be done when it's done"?
                – Peteris
                Nov 4 '14 at 18:14




                @DJClayworth does it help you in any way if you get told an arbitrary date, you make plans based on that date, and on that date find out the reality of "it will be done when it's done"?
                – Peteris
                Nov 4 '14 at 18:14




                6




                6




                A PM will hear this as your answer to when will it be done: "### #### # #### ## 3 months ### #### ## #####"
                – teego1967
                Nov 5 '14 at 14:06




                A PM will hear this as your answer to when will it be done: "### #### # #### ## 3 months ### #### ## #####"
                – teego1967
                Nov 5 '14 at 14:06










                up vote
                10
                down vote













                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.






                share|improve this answer




















                • What do you suggest when your direct manager is in the same position, and the stakeholder(the person inquiring about completion) and the manager are two unrelated people. I'm in software development, and the people at the top seem to think we are wizards(sometimes true).
                  – nobrandheroes
                  Nov 4 '14 at 16:59










                • Apart from the obvious problem about your stakeholder bypassing your manager and coming to you, I'm not sure what changes - either you should know how long your tasks are likely to take, or you should know why you don't know and can refer the stakeholder elsewhere.
                  – Julia Hayward
                  Nov 4 '14 at 17:05










                • It's not that I wouldn't know how long they would take, its that I wouldn't know how long the task + randomly assigned task would take, but you still have to factor the inestimable variables into your estimates.
                  – nobrandheroes
                  Nov 4 '14 at 17:32






                • 3




                  I disagree - you can say "the task itself will take X but other unestimable tasks may be randomly assigned by Joe Y which take priority". OK, maybe more diplomatically than that. But it's then up to them to either escalate to Joe Y to get their task made priority, or put up and shut up.
                  – Julia Hayward
                  Nov 5 '14 at 12:45















                up vote
                10
                down vote













                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.






                share|improve this answer




















                • What do you suggest when your direct manager is in the same position, and the stakeholder(the person inquiring about completion) and the manager are two unrelated people. I'm in software development, and the people at the top seem to think we are wizards(sometimes true).
                  – nobrandheroes
                  Nov 4 '14 at 16:59










                • Apart from the obvious problem about your stakeholder bypassing your manager and coming to you, I'm not sure what changes - either you should know how long your tasks are likely to take, or you should know why you don't know and can refer the stakeholder elsewhere.
                  – Julia Hayward
                  Nov 4 '14 at 17:05










                • It's not that I wouldn't know how long they would take, its that I wouldn't know how long the task + randomly assigned task would take, but you still have to factor the inestimable variables into your estimates.
                  – nobrandheroes
                  Nov 4 '14 at 17:32






                • 3




                  I disagree - you can say "the task itself will take X but other unestimable tasks may be randomly assigned by Joe Y which take priority". OK, maybe more diplomatically than that. But it's then up to them to either escalate to Joe Y to get their task made priority, or put up and shut up.
                  – Julia Hayward
                  Nov 5 '14 at 12:45













                up vote
                10
                down vote










                up vote
                10
                down vote









                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.






                share|improve this answer












                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.







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Nov 4 '14 at 16:54









                Julia Hayward

                12k53438




                12k53438











                • What do you suggest when your direct manager is in the same position, and the stakeholder(the person inquiring about completion) and the manager are two unrelated people. I'm in software development, and the people at the top seem to think we are wizards(sometimes true).
                  – nobrandheroes
                  Nov 4 '14 at 16:59










                • Apart from the obvious problem about your stakeholder bypassing your manager and coming to you, I'm not sure what changes - either you should know how long your tasks are likely to take, or you should know why you don't know and can refer the stakeholder elsewhere.
                  – Julia Hayward
                  Nov 4 '14 at 17:05










                • It's not that I wouldn't know how long they would take, its that I wouldn't know how long the task + randomly assigned task would take, but you still have to factor the inestimable variables into your estimates.
                  – nobrandheroes
                  Nov 4 '14 at 17:32






                • 3




                  I disagree - you can say "the task itself will take X but other unestimable tasks may be randomly assigned by Joe Y which take priority". OK, maybe more diplomatically than that. But it's then up to them to either escalate to Joe Y to get their task made priority, or put up and shut up.
                  – Julia Hayward
                  Nov 5 '14 at 12:45

















                • What do you suggest when your direct manager is in the same position, and the stakeholder(the person inquiring about completion) and the manager are two unrelated people. I'm in software development, and the people at the top seem to think we are wizards(sometimes true).
                  – nobrandheroes
                  Nov 4 '14 at 16:59










                • Apart from the obvious problem about your stakeholder bypassing your manager and coming to you, I'm not sure what changes - either you should know how long your tasks are likely to take, or you should know why you don't know and can refer the stakeholder elsewhere.
                  – Julia Hayward
                  Nov 4 '14 at 17:05










                • It's not that I wouldn't know how long they would take, its that I wouldn't know how long the task + randomly assigned task would take, but you still have to factor the inestimable variables into your estimates.
                  – nobrandheroes
                  Nov 4 '14 at 17:32






                • 3




                  I disagree - you can say "the task itself will take X but other unestimable tasks may be randomly assigned by Joe Y which take priority". OK, maybe more diplomatically than that. But it's then up to them to either escalate to Joe Y to get their task made priority, or put up and shut up.
                  – Julia Hayward
                  Nov 5 '14 at 12:45
















                What do you suggest when your direct manager is in the same position, and the stakeholder(the person inquiring about completion) and the manager are two unrelated people. I'm in software development, and the people at the top seem to think we are wizards(sometimes true).
                – nobrandheroes
                Nov 4 '14 at 16:59




                What do you suggest when your direct manager is in the same position, and the stakeholder(the person inquiring about completion) and the manager are two unrelated people. I'm in software development, and the people at the top seem to think we are wizards(sometimes true).
                – nobrandheroes
                Nov 4 '14 at 16:59












                Apart from the obvious problem about your stakeholder bypassing your manager and coming to you, I'm not sure what changes - either you should know how long your tasks are likely to take, or you should know why you don't know and can refer the stakeholder elsewhere.
                – Julia Hayward
                Nov 4 '14 at 17:05




                Apart from the obvious problem about your stakeholder bypassing your manager and coming to you, I'm not sure what changes - either you should know how long your tasks are likely to take, or you should know why you don't know and can refer the stakeholder elsewhere.
                – Julia Hayward
                Nov 4 '14 at 17:05












                It's not that I wouldn't know how long they would take, its that I wouldn't know how long the task + randomly assigned task would take, but you still have to factor the inestimable variables into your estimates.
                – nobrandheroes
                Nov 4 '14 at 17:32




                It's not that I wouldn't know how long they would take, its that I wouldn't know how long the task + randomly assigned task would take, but you still have to factor the inestimable variables into your estimates.
                – nobrandheroes
                Nov 4 '14 at 17:32




                3




                3




                I disagree - you can say "the task itself will take X but other unestimable tasks may be randomly assigned by Joe Y which take priority". OK, maybe more diplomatically than that. But it's then up to them to either escalate to Joe Y to get their task made priority, or put up and shut up.
                – Julia Hayward
                Nov 5 '14 at 12:45





                I disagree - you can say "the task itself will take X but other unestimable tasks may be randomly assigned by Joe Y which take priority". OK, maybe more diplomatically than that. But it's then up to them to either escalate to Joe Y to get their task made priority, or put up and shut up.
                – Julia Hayward
                Nov 5 '14 at 12:45











                up vote
                8
                down vote













                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."






                share|improve this answer




















                • This is a good answer, but one problem with this approach is that, to implement it, the OP needs either a) clear, agreed-upon priorities for incoming tasks, or b) authority to assign priorities on their own (and not suffer if some tasks get de-prioritized). Unfortunately, if the tasks are coming in from multiple sources, it's all too likely that everyone will want their tasks to have priority. [...]
                  – Ilmari Karonen
                  Nov 6 '14 at 0:12






                • 1




                  ... Passing the buck (i.e. "Take it up with manager X, they decide what gets prioritized.") may help if there's someone to pass it to, but if that's not an option, in the worst case the priority queue may end up degenerating into a last-in-first-out queue (with everyone demanding that each new task pre-empt all earlier ones) where tasks are either completed quickly or not at all. Of course, that's really a sign of an organizational dysfunction and/or insufficient resources, but it's worth keeping in mind that such situations do exist.
                  – Ilmari Karonen
                  Nov 6 '14 at 0:14















                up vote
                8
                down vote













                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."






                share|improve this answer




















                • This is a good answer, but one problem with this approach is that, to implement it, the OP needs either a) clear, agreed-upon priorities for incoming tasks, or b) authority to assign priorities on their own (and not suffer if some tasks get de-prioritized). Unfortunately, if the tasks are coming in from multiple sources, it's all too likely that everyone will want their tasks to have priority. [...]
                  – Ilmari Karonen
                  Nov 6 '14 at 0:12






                • 1




                  ... Passing the buck (i.e. "Take it up with manager X, they decide what gets prioritized.") may help if there's someone to pass it to, but if that's not an option, in the worst case the priority queue may end up degenerating into a last-in-first-out queue (with everyone demanding that each new task pre-empt all earlier ones) where tasks are either completed quickly or not at all. Of course, that's really a sign of an organizational dysfunction and/or insufficient resources, but it's worth keeping in mind that such situations do exist.
                  – Ilmari Karonen
                  Nov 6 '14 at 0:14













                up vote
                8
                down vote










                up vote
                8
                down vote









                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."






                share|improve this answer












                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."







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Nov 5 '14 at 13:05









                Adam Davis

                7,73111534




                7,73111534











                • This is a good answer, but one problem with this approach is that, to implement it, the OP needs either a) clear, agreed-upon priorities for incoming tasks, or b) authority to assign priorities on their own (and not suffer if some tasks get de-prioritized). Unfortunately, if the tasks are coming in from multiple sources, it's all too likely that everyone will want their tasks to have priority. [...]
                  – Ilmari Karonen
                  Nov 6 '14 at 0:12






                • 1




                  ... Passing the buck (i.e. "Take it up with manager X, they decide what gets prioritized.") may help if there's someone to pass it to, but if that's not an option, in the worst case the priority queue may end up degenerating into a last-in-first-out queue (with everyone demanding that each new task pre-empt all earlier ones) where tasks are either completed quickly or not at all. Of course, that's really a sign of an organizational dysfunction and/or insufficient resources, but it's worth keeping in mind that such situations do exist.
                  – Ilmari Karonen
                  Nov 6 '14 at 0:14

















                • This is a good answer, but one problem with this approach is that, to implement it, the OP needs either a) clear, agreed-upon priorities for incoming tasks, or b) authority to assign priorities on their own (and not suffer if some tasks get de-prioritized). Unfortunately, if the tasks are coming in from multiple sources, it's all too likely that everyone will want their tasks to have priority. [...]
                  – Ilmari Karonen
                  Nov 6 '14 at 0:12






                • 1




                  ... Passing the buck (i.e. "Take it up with manager X, they decide what gets prioritized.") may help if there's someone to pass it to, but if that's not an option, in the worst case the priority queue may end up degenerating into a last-in-first-out queue (with everyone demanding that each new task pre-empt all earlier ones) where tasks are either completed quickly or not at all. Of course, that's really a sign of an organizational dysfunction and/or insufficient resources, but it's worth keeping in mind that such situations do exist.
                  – Ilmari Karonen
                  Nov 6 '14 at 0:14
















                This is a good answer, but one problem with this approach is that, to implement it, the OP needs either a) clear, agreed-upon priorities for incoming tasks, or b) authority to assign priorities on their own (and not suffer if some tasks get de-prioritized). Unfortunately, if the tasks are coming in from multiple sources, it's all too likely that everyone will want their tasks to have priority. [...]
                – Ilmari Karonen
                Nov 6 '14 at 0:12




                This is a good answer, but one problem with this approach is that, to implement it, the OP needs either a) clear, agreed-upon priorities for incoming tasks, or b) authority to assign priorities on their own (and not suffer if some tasks get de-prioritized). Unfortunately, if the tasks are coming in from multiple sources, it's all too likely that everyone will want their tasks to have priority. [...]
                – Ilmari Karonen
                Nov 6 '14 at 0:12




                1




                1




                ... Passing the buck (i.e. "Take it up with manager X, they decide what gets prioritized.") may help if there's someone to pass it to, but if that's not an option, in the worst case the priority queue may end up degenerating into a last-in-first-out queue (with everyone demanding that each new task pre-empt all earlier ones) where tasks are either completed quickly or not at all. Of course, that's really a sign of an organizational dysfunction and/or insufficient resources, but it's worth keeping in mind that such situations do exist.
                – Ilmari Karonen
                Nov 6 '14 at 0:14





                ... Passing the buck (i.e. "Take it up with manager X, they decide what gets prioritized.") may help if there's someone to pass it to, but if that's not an option, in the worst case the priority queue may end up degenerating into a last-in-first-out queue (with everyone demanding that each new task pre-empt all earlier ones) where tasks are either completed quickly or not at all. Of course, that's really a sign of an organizational dysfunction and/or insufficient resources, but it's worth keeping in mind that such situations do exist.
                – Ilmari Karonen
                Nov 6 '14 at 0:14











                up vote
                7
                down vote













                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.






                share|improve this answer


















                • 2




                  Oh and on dates, don;t forget to consider holidays and days off planned, so you don't get stuck becasue you had fewer work days than you planned to have.
                  – HLGEM
                  Nov 4 '14 at 17:25






                • 2




                  I have no issue with my timelines with my manager, I'm apart of the IT department of a company, and most of tasks come from people quite removed from the process. Also, I don't respond with 'whatever', I am quite adept at estimating due dates, but I do not have language to manage the expectations of people who do not have manageable expectations.
                  – nobrandheroes
                  Nov 4 '14 at 17:37














                up vote
                7
                down vote













                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.






                share|improve this answer


















                • 2




                  Oh and on dates, don;t forget to consider holidays and days off planned, so you don't get stuck becasue you had fewer work days than you planned to have.
                  – HLGEM
                  Nov 4 '14 at 17:25






                • 2




                  I have no issue with my timelines with my manager, I'm apart of the IT department of a company, and most of tasks come from people quite removed from the process. Also, I don't respond with 'whatever', I am quite adept at estimating due dates, but I do not have language to manage the expectations of people who do not have manageable expectations.
                  – nobrandheroes
                  Nov 4 '14 at 17:37












                up vote
                7
                down vote










                up vote
                7
                down vote









                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.






                share|improve this answer














                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.







                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited Feb 20 '15 at 16:31

























                answered Nov 4 '14 at 17:24









                HLGEM

                133k25226489




                133k25226489







                • 2




                  Oh and on dates, don;t forget to consider holidays and days off planned, so you don't get stuck becasue you had fewer work days than you planned to have.
                  – HLGEM
                  Nov 4 '14 at 17:25






                • 2




                  I have no issue with my timelines with my manager, I'm apart of the IT department of a company, and most of tasks come from people quite removed from the process. Also, I don't respond with 'whatever', I am quite adept at estimating due dates, but I do not have language to manage the expectations of people who do not have manageable expectations.
                  – nobrandheroes
                  Nov 4 '14 at 17:37












                • 2




                  Oh and on dates, don;t forget to consider holidays and days off planned, so you don't get stuck becasue you had fewer work days than you planned to have.
                  – HLGEM
                  Nov 4 '14 at 17:25






                • 2




                  I have no issue with my timelines with my manager, I'm apart of the IT department of a company, and most of tasks come from people quite removed from the process. Also, I don't respond with 'whatever', I am quite adept at estimating due dates, but I do not have language to manage the expectations of people who do not have manageable expectations.
                  – nobrandheroes
                  Nov 4 '14 at 17:37







                2




                2




                Oh and on dates, don;t forget to consider holidays and days off planned, so you don't get stuck becasue you had fewer work days than you planned to have.
                – HLGEM
                Nov 4 '14 at 17:25




                Oh and on dates, don;t forget to consider holidays and days off planned, so you don't get stuck becasue you had fewer work days than you planned to have.
                – HLGEM
                Nov 4 '14 at 17:25




                2




                2




                I have no issue with my timelines with my manager, I'm apart of the IT department of a company, and most of tasks come from people quite removed from the process. Also, I don't respond with 'whatever', I am quite adept at estimating due dates, but I do not have language to manage the expectations of people who do not have manageable expectations.
                – nobrandheroes
                Nov 4 '14 at 17:37




                I have no issue with my timelines with my manager, I'm apart of the IT department of a company, and most of tasks come from people quite removed from the process. Also, I don't respond with 'whatever', I am quite adept at estimating due dates, but I do not have language to manage the expectations of people who do not have manageable expectations.
                – nobrandheroes
                Nov 4 '14 at 17:37










                up vote
                6
                down vote













                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.






                share|improve this answer
























                  up vote
                  6
                  down vote













                  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.






                  share|improve this answer






















                    up vote
                    6
                    down vote










                    up vote
                    6
                    down vote









                    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.






                    share|improve this answer












                    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.







                    share|improve this answer












                    share|improve this answer



                    share|improve this answer










                    answered Nov 4 '14 at 22:13









                    John Connell

                    772




                    772




















                        up vote
                        2
                        down vote













                        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!"






                        share|improve this answer
















                        • 2




                          How about a kanban board for each employee? Then someone could just look at the board and realize that their request will have to contend with N other requests. Of course, make this a computer application, not a physical board. PMs would be responsible for this.
                          – user37746
                          Nov 5 '14 at 17:26














                        up vote
                        2
                        down vote













                        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!"






                        share|improve this answer
















                        • 2




                          How about a kanban board for each employee? Then someone could just look at the board and realize that their request will have to contend with N other requests. Of course, make this a computer application, not a physical board. PMs would be responsible for this.
                          – user37746
                          Nov 5 '14 at 17:26












                        up vote
                        2
                        down vote










                        up vote
                        2
                        down vote









                        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!"






                        share|improve this answer












                        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!"







                        share|improve this answer












                        share|improve this answer



                        share|improve this answer










                        answered Nov 5 '14 at 17:14







                        user37746














                        • 2




                          How about a kanban board for each employee? Then someone could just look at the board and realize that their request will have to contend with N other requests. Of course, make this a computer application, not a physical board. PMs would be responsible for this.
                          – user37746
                          Nov 5 '14 at 17:26












                        • 2




                          How about a kanban board for each employee? Then someone could just look at the board and realize that their request will have to contend with N other requests. Of course, make this a computer application, not a physical board. PMs would be responsible for this.
                          – user37746
                          Nov 5 '14 at 17:26







                        2




                        2




                        How about a kanban board for each employee? Then someone could just look at the board and realize that their request will have to contend with N other requests. Of course, make this a computer application, not a physical board. PMs would be responsible for this.
                        – user37746
                        Nov 5 '14 at 17:26




                        How about a kanban board for each employee? Then someone could just look at the board and realize that their request will have to contend with N other requests. Of course, make this a computer application, not a physical board. PMs would be responsible for this.
                        – user37746
                        Nov 5 '14 at 17:26










                        up vote
                        2
                        down vote













                        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.






                        share|improve this answer
























                          up vote
                          2
                          down vote













                          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.






                          share|improve this answer






















                            up vote
                            2
                            down vote










                            up vote
                            2
                            down vote









                            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.






                            share|improve this answer












                            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.







                            share|improve this answer












                            share|improve this answer



                            share|improve this answer










                            answered Nov 5 '14 at 18:05







                            user8365



























                                up vote
                                -1
                                down vote













                                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.






                                share|improve this answer
















                                • 1




                                  This does add not anything substantial to the other answers already given
                                  – Jan Doggen
                                  Nov 15 '14 at 10:28















                                up vote
                                -1
                                down vote













                                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.






                                share|improve this answer
















                                • 1




                                  This does add not anything substantial to the other answers already given
                                  – Jan Doggen
                                  Nov 15 '14 at 10:28













                                up vote
                                -1
                                down vote










                                up vote
                                -1
                                down vote









                                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.






                                share|improve this answer












                                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.







                                share|improve this answer












                                share|improve this answer



                                share|improve this answer










                                answered Nov 14 '14 at 22:43









                                FreakyDan

                                9




                                9







                                • 1




                                  This does add not anything substantial to the other answers already given
                                  – Jan Doggen
                                  Nov 15 '14 at 10:28













                                • 1




                                  This does add not anything substantial to the other answers already given
                                  – Jan Doggen
                                  Nov 15 '14 at 10:28








                                1




                                1




                                This does add not anything substantial to the other answers already given
                                – Jan Doggen
                                Nov 15 '14 at 10:28





                                This does add not anything substantial to the other answers already given
                                – Jan Doggen
                                Nov 15 '14 at 10:28













                                 

                                draft saved


                                draft discarded


























                                 


                                draft saved


                                draft discarded














                                StackExchange.ready(
                                function ()
                                StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f35790%2fwhen-asked-about-a-completion-date-what-is-the-best-way-to-say-it-will-be-done%23new-answer', 'question_page');

                                );

                                Post as a guest

















































































                                Comments

                                Popular posts from this blog

                                What does second last employer means? [closed]

                                Installing NextGIS Connect into QGIS 3?

                                One-line joke