Manager questioning my time estimates for a project [duplicate]

Question

I work in a software development company. For a new project, my manager asked me time-estimates. I read the project requirements document and worked out worst-case estimates.

During a meeting, he asked me the estimates and I told those to him. However, he started saying things like 'Would this task really take that long?', 'Coding the xyz component shouldn't take more than abc amount of time!!'.

How do I handle such manager? Am I doing something wrong by giving him the worst-case estimates? Are my estimates really that long? Am I a slow software developer? If I am a slow developer, any tips to survive in the industry?

I have a feeling that if I give him both the worst case and the best case estimates, he would still be dismissive about my estimates.

Answer 1

Take a deep breath, and start over.

Remember: What seems to be very realistic for you, can be seem arbitrary for someone else who does not know the details that you know. Ask yourself: are you providing enough data with your estimates to show / support your estimation?

If yes,

• Are they detailed enough and shows the complexity of the work that needs to be carried out?
• Do they outline any dependency (or blockers) of the chain of assignments?
• Did you consider planning assignments in a way that some part of it can be worked in parallel?
• Did you break down the work to show where you need to get inputs / do R&D (usually more time consuming) and where you can start working right away (immediate output)?

After considering all of these, add some more buffer time for the unforeseen delays that could occur, and present that estimate.

If questioned, you can repeat the details in the estimate already. That is your estimate. Remember, people can ask you to reduce your estimate, but it's you who has to get the work done - so do not let anyone else estimate the work for you. It's your work, your estimate and your responsibility.

Calculate wisely, and stick to that. Do not overcommit (take best case assumption) under any scenario. Usually, until you are mastering the practice of estimation, going ahead with the worst case scenario is the usual way to go.

Remember, it's way better to delay the delivery upfront (or, in other words, set a realistic delivery date) because of capacity adjustment, rather than committing at an earlier date/time and finally end up failing to deliver.

Note: If you're not doing this activity already, it may seem a lot to you, but once you get started and get habituated, it'll be come easier and part of your routine.

Answer 2

Personally, I think you are right on the money giving worst-case estimates.

It is much better to get something done in a shorter amount of time that they're expecting ('underpromise and overdeliver'), than the opposite. Running over time estimates is stressful and no fun for anyone.

My strategy for estimating tasks is basically a function of 'how much work is it' and 'how much uncertainty is there' - the uncertainty factor multiplies the 'how much work' factor.

• The minimum time to do anything code related is one hour. And that's for the most trivial task like changing a string. Should only take 5 minutes to find the string, change it, and commit the change, but the minimum is one hour. The joke I make is 'It takes 15 minutes to turn on my computer' (and grab a cup of tea, chat to a colleague about something, find the ticket on the ticket managing system, open my IDE etc).
• My starting point is 'Realistically, how long do I think this should take me'. Add a decent amount of buffer to that. Double it. That's to deal with interruptions, having lunch, and to just create some buffer.
• Have I done this before? If it's something I've been doing day and day out, then I'm happy to keep my estimate near that starting point.
• If it's something that I haven't exactly done before, but seems simple enough, then perhaps just double the estimate.
• If it's something I have no idea about, it's a technology I haven't used, then the minimum should be a couple of days.

To give you a real example of some estimations.

My day-to-day work is as a JavaScript developer, but a task I have coming up is getting this containerised code I have running on my own machine running in a public environment.

This is work I have done before, but not day in day out, so there's a decent amount of uncertainty.

Now realistically, all this job involves is writing some kind of yaml file, and setting up some resources on a cloud provider. Doing that should only take a couple of hours. But because of the uncertainty, I'm giving an estimate of two days to get this done. (And actually, that estimate was based on 'I just need to learn how to do it', but now that I've started I'm realising that I need to rewrite some code (importing non-version-controlled configuration files at run time), and so that's probably going to use up all my buffer!).

Now, in terms of handling your manager, here's what the points I would make:

• Firstly, point out that you are making worst-case estimates, and that you're not expecting that in every case it would take you this long, but in aggregate, tasks will take that long.

• Explain that you understand that IT estimations are notoriously difficult and are often too optimistic.

• Explain that you want to do the job properly. You don't want to produce a bunch of copy-paste code that will be more time consuming to maintain in the long run.

• You could always give two estimates - a 'median' estimate of realistically how long it might take, and a 'worst-case' estimate. Of course - they should always expect that even a worst-case estimate can be too optimistic!

• One key point is, that it's not reasonable to expect you to give a full breakdown on what makes a task take a long time either - except to say 'I don't know what I don't know, until I start doing it'.

• It could be that you're just working with an unreasonable manager. If that is the case, then don't let them get you down, you might need to just put on an act, but certainly keep pride in your professionalism as a programmer.

Answer 3

Do not EVER reduce your estimates, unless you have new information pertaining to some specific part. Most developer estimates, especially from those inexperienced at it, are always optimistic - in this respect, providing worst case is probably a good idea, although presenting as a range from worst to most likely (not "best") is better.

However, he started saying things like 'Would this task really take that long?', 'Coding the xyz component shouldn't take more than abc amount of time!!'.

Does he have performance metrics from the last time this or similar work was done? Do you?

If not, take each estimate and break it into subtasks of a couple of hours each. If they're longer than that, repeat. Create worst / best for each, ideally with the help of a colleague, then walk your manager through the subtasks and their estimates and get agreement on them. Add up subtask times to create worst / best totals - that's where you get the big numbers from; the ones which were shot down. You'll probably only have to do this for the largest one or two tasks, before manager gets the point.

If you must still "just shave off a few days/weeks", ask what feature(s) you should cut to achieve this. Descoping should not reduce your estimate either; what it does is change the delivery window because you're delivering less functionality.

Do not EVER reduce your estimates

I started by saying this and that's because even if you reduce your estimates, it won't reduce the time it takes to develop. What it will do is make you "late", because the finish line has moved. Your reputation will take a hit. And then another, as you desperately try to correct, by dropping quality or making another delivery promise that you won't keep.

Finally, do your estimates include time for testing, ideally provided by the person/group doing the testing?

Answer 4

There's a simple fact: If you give a good estimate, then 50% of the time the work will take longer, and 50% of the time the work will take less time. If it's different for you, then you are not giving good estimates.

There's another simple fact, and that is that many managers don't understand this simple fact. You give an estimate, and they take this as a 100% commitment to deliver in that time. You realised that, so you gave worst case estimates to compensate for this.

There's another simple fact that many managers don't understand: And that is the fact that they can make you change (reduce) your estimate if they apply enough pressure, but that reducing the estimate doesn't reduce the amount of work to be done, or the time it takes. So if your good estimate was six weeks, and your worst case estimate was eight weeks, then the job will take probably 5 to 7 weeks, and if the manager makes you change the estimate to 3 weeks, it still takes 5 to 7 weeks (or longer, if you have an employee who can't handle the pressure, or you have an employee who is totally demotivated by being given a timeframe that is unachievable - why would you work hard to meet a target that is unachievable. Since you miss the target anyway, you might as well relax and take your time).

Questioning you is kind of irrational. Either he is better at estimating the times than you, or he isn't. If he isn't, he shouldn't be questioning you. If he is better at estimating, why ask you to estimate in the first place? So what is really happening: He isn't doubting your ability to give estimates. He just wants the work done quicker, and he thinks (bad manager) that will happen if he makes you change your estimates.

To make the work finish earlier, there are several methods: Add manpower. Or reduce the amount of work (remove features). Or reduce quality (by shipping an untested product which gives you more time, or by asking you to rush the work, producing technical debt that needs repaying later). The latter two are only acceptable if it is clear that this is done to meet a deadline, and that more work has to be done and will be done immediately after the deadline.

Answer 5

Giving only worst case estimates is not useful. Over time they will be wrong and your estimates won't have credibility, as possibly evidenced by your manager's questions. Sure, some times things go wrong and it is the worst case. But other times things are fine and even a few times things go great. If your estimates aren't reliable over time, they lose credibility.

One of my former managers showed me what he called the 1-4-1 estimation model. Multiply your best case estimate by 1, your normal estimate by 4 and your worst case estimate by 1. Add them together and divide by 6. This will give you an estimate that provides protection from bad events but also gives fair balance for things going very well. I have found this model to be much more reliable when comparing results vs estimates.

Remember the goal of providing an estimate is not to give a time window you can guarantee you can meet, but to give a fair evaluation of how long it should take. In the end you will miss more than you hit, but for estimates to be valuable, you should miss long just as often as you miss short.

Answer 6

I'm surprised no one referenced this great talk from Uncle Bob: https://www.youtube.com/watch?v=eisuQefYw_o

The issue of estimate and missing the mark regularly in my team was raised last year and one of our agile coach referenced the talk.

The TLDW: estimate are not a single hard number and most have three quality: accuracy, precision and honesty. "I'll get this project done between right now and the heat death of the Universe." is accurate (you are in the right ballpark). But it is hadrly precise and mostly useless for a manager. "I'll get this project done the Xth of the Yth month in the year ABCD at 13:24 and 13 seconds". Very precise, not accurate at all unless you have the project already done and you just wait out to deliver it.

What Uncle Bob suggest is to use time interval as an estimate and give a worse case scenario, a likely scenario and a best case scenario and make your manager understand that the project will likely be delivered around the likely scenario but he can not go around and promise it will be absolutely be delivered at the likely scenario. This is especially true if your manager must coordinate with other department and those will depend on your project to deliver on time too. Use a normal distribution and try to get a good estimate of what your standard deviation is.

Your manager will push back and that is it's job. He want an honest answer and want to make sure your understood the requirements. He does not want a project with bell and whistle and if those are included in your estimate he will quickly try to remove them. If he had previous experience in software development he might try to guess some of those task and argue with your estimate. Kindly remember your manager that we are bad at estimating, our estimate are often best case scenario even when asked to estimate for worse case scenario (I remember reading sociological study about the phenomenon on student and essay time completion estimate). We forget contingencies, we forget auxiliary task and we forget that developer, architect, SQA and such are human and have bad and good days in their personal life and this can impact their productivity. We also assume the information we have are accurate, they often are not or will change or will be incomplete.

So you can sum up to your manager that the time interval estimate encompass 95% of those scenario instead of doing exhaustive task and subtasks analysis and contingency planning. I'm not saying you should not do such things, but the 20-80 rule apply strongly here. If you can get away with less of those costly analysis and still get a fairly decent picture that really all you need often (YMMV, adapt for your team, manager and industry need).

Bottom line your estimate must be honest and being honest is also being transparent. Your manager might feel the need to get involve because of the lack of information or not understanding your reasoning.

If you ask, my team abandoned estimation and we now use project time shirt-size. Our shirt size are 40h (very small feature, quick fix), 80h, 200h, 500h (major project, multi squad or overhaul of the architecture). Anything less that 40h does not exist, anything above 500h is not manageable in our roadmap and not be plan honestly and adequately and need refinement or to be split. I recently work on two simultaneous 500h projects were the hope was we could reuse the work of the first project to quickly complete the second. It did work, but our team had it's backup because the second project could had been more complicated that what we though originally.

TLDR: estimate is not a single hard number, it is not a commitment, it is a likely time interval. Be honest about how you got that time interval what a worse case scenario looks like, what a best case scenario looks like and how much you expect to be around your likely scenario.

Answer 7

A good rule of thumb (for any task, not just software development) is to estimate how long it will take / how much it will cost and then double it.

If you think something will take 2 days then quote 4 days as your estimate. Customers (in this case your manager) are always happy when something is achieved earlier / cheaper than quoted and never (or rarely) when it takes longer / costs more. And why should they be? The quote sets expectations.

When faced with questions like:

'Would this task really take that long?', 'Coding the xyz component shouldn't take more than abc amount of time!!'

it sounds very much like your manager thinks you write some code and then it's finished. It doesn't include testing, debugging, more testing. Writing the initial code is the easy part. So you could say something like:

Sure, maybe the first draft of the code could be done in that amount of time, but we need to make sure that it works properly with the other components.

And use we when you talk about it. It will get your manager thinking (even if only at a subconscious level) that he is part of the process so if (when) there is a good result he gets credit, and the converse if there's a problem.

It's not worst case, it's contingency planning.

Answer 8

I don't think providing only worst-case estimates is a good idea. Like the name suggests, they are not realistic. After all business can't be run in catastrophe mode all the time.

However, you could provide a range of estimates. From realistic to worst-case. And explain the risks/uncertainties there is and how they affect the estimates.

This would give both you and your manager better ground to work on. You would have a reasonable estimates and stated that work might take longer. And manager will have initial risk analysis, reasonable estimates and something to plan resources on.

Management has most likely discussed about some kind of overall estimate already (x hours) and now if developer says it's going to take 3x (worst-case), this might not be received well.

Also it's not practical the plan resourcing based on worst-case scenario. Let's say you need to work with new framework and therefore say 2x hours (actual work 1x, learning curve 1x). Manager needs it to happen in x, and without knowing the reason for high estimate he appoints 2 developers for the task. Things will still fail as you have learning curve 1x and can't complete the task even with 2 developers.

Answer 9

I can't believe none of the existing answers mention Planning Fallacy.

Anyway, I'd suggest doing some googling/research/etc on Planning Fallacy - a mental bias that causes people to systematically underestimate how much time things will take. It'll not only help you figure out the way to interact with your manager, but help you understand why you need to do so.

Some examples:

"Coding the XYZ component should only take ABC amount of time!"

"The happy path would probably only take that amount of time. But there are a lot of complications and edge cases we'd have to work out if we don't want a lot of bugs on delivery."

or

"Coding the XYZ component should only take ABC amount of time!"

"There's a lot of uncertainties with some of the modules in XYZ - we're not sure how they interact with the other systems. We're almost certainly going to run into some unforseen problems that we don't know about yet, so we had to bake that into the time estimate."

... etc.

Answer 10

If your manager is being rude or confrontational, that’s one thing. And I won’t address that.

Otherwise, discussions over variances in estimates is common in many methodologies, especially agile. In fact, in order to account for how different estimates can be from different parties. Almost all agile “estimation” schemes involve providing an estimation without knowledge of other parties estimates, to ensure that their wildly different estimates don’t cause you to change yours before providing it. Poker planning, fist of five, etc.

But first and foremost, remember, we’re trying to get the estimates right. And not really for the short term tasks. It’s mote about, over the long haul, being able to accurately predict the amount of stuff our group can do in a given time frame.

Estimation variances are also a part of the common reasons that modern estimates come in t-shirt sizes or non-time-unit units. Because an engineer that works 20 hours a day. Or who specializes in the task being estimated, or who already did phase 1 of the task, is going to obviously complete that task in a different amount of time.

So it’s extremely common, if not required, to discuss varying estimates. “John you estimated that as being a large task, and Jane estimated that as a small task. Let’s discuss” to make sure we understand the task.

John speaks about problems he’s had in the past with getting a piece of the puzzle working. Jane says she’s had that problem, but the new environment means there’s a template, etc etc.

And then one engineer says “that makes sense, I’m fine with it being a small/large whatever”.

This way, even if you have one superstar engineer capable of finishing tasks in half the time, we still come over time to more accurate velocities for the team. Since the superstar engineer cannot complete all tasks themselves.

Now, if your not following that type of methodology, then you’ll likely have the pitfalls its trying to avoid.

So if your manager is always doing “follow up” estimates, ask them to provide estimates at the same time as you, not after. And then discuss the variances.

But the best chance is to have multiple engineers all providing blind estimates and then discussing.

Answer 11

Remind your manager that your estimates are worst case, and worst case estimates are supposed to be on the high side. I would also provide an "average case" estimate, something like, "In the worst case, if everything explodes, this might take 2 weeks. But more realistically if everything goes normally it will take 3 days. I will promise you 2 weeks, but I will say that it will more likely be between 3 days and 2 weeks, which is sooner than 2 weeks".

The thing to be careful of is that you want to undercommit and overdeliver, not the opposite. Commit to more time than you need, and then deliver in less time. If you say to your boss "If everything explodes and nothing works properly then it will take 2 weeks", and you take 2 weeks, and you don't show your boss that everything exploded, then you'll be in trouble.

Answer 12

There are several parts to the answer.

First, if you are not using a formal estimating methodology, that produces artifacts that can be sanity-checked and an estimate that is solely based on the data in the artifacts and on coefficients that are calibrated based on actuals from previous projects, you are h0zed from the beginning.

Books to read: "Software Engineering Economics", by Barry Boehm, "Software Cost Estimation With COCOMO II", same author, and "Controlling Software Projects", by Tom Demarco. These are the classics of software cost and schedule estimation.

If your estimating methodology is not based on actuals that can be measured DIRECTLY from previous projects, you are almost as badly h0zed. Yes, this is a hard slap in the face at "function points": I have been looking for years, and I have NEVER found either an explanation of what a function point is or how to measure it from deliverables. This is also a statement in favor of SLOC (source lines of code) as the basis of the estimation: for small modules, pretty much everyone will agree on 10 SLOC vs. 50 SLOC vs. 500 SLOC, and it is EASY to measure. (Yes, SLOC can be gamed, but, seriously, how long will someone be allowed to game his SLOC by doing interesting source editing before the Coding Standards Police escort him away in handcuffs? This is a cute way of saying that SLOC gaming doesn't happen in the real world.)

What this gives you is the data for a PowerPoint pitch (the only communications medium that managers these days understand) that says: These are the components, these are the estimated sizes of each component, these are the complexities, here are the equations, here are the individual results, and here is the grand total. Your manager then has to argue with the set of components, or the INDIVIDUAL estimated component sizes, or the effort adjustment coefficients, or your adding machine tape.

That's a hard, uphill argument to make, even for a typical modern software manager.

Second, your emphasis in worst-case estimates is well-founded. The problem is that an estimate is not a point in time. It is a probability: you are saying that there is "X" percent probability that we will be finished by "Y" date, where "X" depends on your manager's perception. The corollary is immediately obvious: there is (100 - "X" percent) probability that you will overrun the estimate. A worst-case estimate is aiming for 100% probability. The typical software manager wants a 1% estimate: there's about 1% chance you'll actually make it, and 99% chance you'll blow the schedule, but the small estimate makes him look good and lets him blame you for the blown estimate when reality comes crashing in.

Here I insert a data point, from Boehm's "Software Engineering Economics": Detailed COCOMO, which relied on estimating each component down to the most detailed part, then adding up the estimates, went on the map, big time, when Boehm showed that it hit within 30% of actuals, something over 60% of the time. That was far better than any other estimating methodology available at the time could do.

The key takeaway here is that no estimate will ever be perfect. They all have an inescapable margin of error, and there is always the possibility of a major overrun or underrun. You state this, you say that the estimating methodology is known to give this range of results, and you move on.

Third: If your estimate is to more than two to three significant digits, you are fooling yourself. If your estimate says 455 man-hours, you are saying it isn't 454 and it isn't 456. You can't predict bathroom congestion with that much precision, never mind flu outbreaks.

What this means is you add it all up, you get, say, 3579 man-hours, and then you round it to 3600. You keep the original numbers, so that you can tell your manager how you rounded, and that you rounded BECAUSE you can't predict bathroom breaks or bachelor party hangovers.

Answer 13

So the question and a bunch of the answers really miss some key things:

1. What is the 'estimate' for? Pricing, Internal costing/ budget, Schedule?
2. Is the estimate for the developer themselves or for others?
3. Does the team or individual have any track record of projects?
4. Are there milestone deliverables that can help track how accurate the estimates are?
5. Sounds very waterfall anyway - why?
6. If this is not a very short project (and the implication it is not), then why is it a single developer project?
7. The above point is critically relevant is there is any suspicion that the developer is not top quartile perform. Software engineering is a team sport and putting two people on a project with the right processes gives a high return.
8. Does the 'manager' have real development experience in order to assess effort?
9. Can you just ask - "Okay , I hear that. Let's talk through what each of us see as involved
10. It is pretty common for estimates to be a group effort nowadays - has your organisation tried that?
11. Suggest an Agile approach with a detailed task breakdown. That gives the management a degree of control as well as visibility on progress.
12. With Agile, a key concept is that Scope is variable. Can that work with this project?
13. Do you know the context the manager is coming from? Deadline? Cost limits?