How to respond to, "How long will this take?" when in a new job position

Question

I started a new job two weeks ago using technologies that are new to me. I was upfront from the start about what I did and did not know so there's no surprises.

I do a little of everything and so I work with three project managers at one time due to the nature of my role being involved in almost every client project we have. When assigning me a task and allocating an expected time, two of the three project managers are generous with their time estimates and have mentioned that they understand I'm new and learning a lot of unfamiliar technologies while also trying to stay on top of multiple projects (which relate to the things that I'm learning). They give me enough time that I've hit the minimum time expected (or finish in less time).

But the third manager's project(s) are the most out of my field. Despite this, and unlike the other managers who are aware of how new I am, she repeatedly asks me "How long will this take you?" and when I reply, "I honestly couldn't give you an estimate because there is a lot of dependencies to get this task done that I need to learn first", her eyes bug out and I can tell she's trying her best not to lose it. I think the reason being is that the role I filled was backlogged with weeks, if not months, worth of work from the get go and so she's trying to hit deadlines for clients. She'll then assign me an expected time that, at this point, I've gone 10 hours over. I'm salary so it's not like they have to payout overtime and I also spend this extra time finishing up the project at home (going well beyond my 40 hours which is fine).

I don't mind busting my ass; I mind the sense of dread and emergency she approaches every conversation with because she's worried about the project timelines. It stresses me out and makes me feel uncomfortable for not giving her time estimates.

I may normally question my progress or capabilities, but I've had nothing but great feedback from the other managers. The senior project leader told me at the end of this week that she's, "Extremely glad to have [me]". The CTO even went out of my way to give positive comments on my work. So... How should I handle this?

Answer 1

I don't mind busting my ass; I mind the sense of dread and emergency she approaches every conversation with because she's worried about the project timelines. It stresses me out and makes me feel uncomfortable for not giving her time estimates.

So... How should I handle this?

Give your best estimate. Avoiding one isn't helping you, and certainly isn't helping this project manager. Project managers need estimates in order to help track the overall project. And not giving one means they have to take their own (often less informed) guess and use that. Not giving one also makes you look bad.

Many find that breaking down the task into smaller chunks helps in creating an estimate. Often, smaller chunks are easier to visualize and estimate. And usually, you can ask for a little bit of time to do this analysis, rather than providing your estimate immediately.

Make sure you convey that your estimate likely can't be very accurate yet, and explain the reasons why. Then, promise to give a revised estimate once the project tasks become clearer. And give her a time frame for when you will provide your next estimate.

Track your estimates and actuals, so that you will get better over time.

And as your project progresses, re-estimate the remainder even if not required to do so. If you feel that your original estimate isn't likely to hold, then make sure to provide feedback to the project manager as soon as you know. Project managers (all managers) don't like surprises.

Then stop the dread, stress and uncomfortable feelings. These are emotions that you bring on yourself. Knowing that you are doing your best, and that it is being recognized by those about you should free you from these feelings.

Answer 2

Don't give a point estimate, give a range. Point estimates are usually seen as the default, but in most cases, range estimates would do a much better job. Your case is one where the range estimate is the better choice.

For a task you are very comfortable with, you can start giving narrow ranges. "I will finish the monthly report in two hours, plus/minus 15 minutes". When you are faced with a task which you don't know what will entail, the truth may well be "between two hours and two days". Simply stating that will sound insolent, so give it with an explanation. "I saw a monthly report produced in another project. I'll have to look into it. If the numbers are available somewhere, two hours should be sufficient to write up the report. If I have to find a way for calculating them, and chase down sources, it can easily stretch to two days or more".

Now, the manager can let her inner Kirk hang out and scream at you that two days is unacceptable. To which you can answer that 1) it is still possible that it is done in 2 hours, you just can't estimate the probability, 2) you cannot create true numbers out of thin air, 3) after you have gone through the process once, you can prepare better for next time (gathering numbers during the month, reusing an Excel macro to calculate them from raw data) so next month the report will take much shorter, and 4) ask her, if two days are not acceptable, what should you do if it turns out that the numbers will not be available on time? For example, provide only one section of the report (which one), or get permission to pull a second person from his usual tasks to also work on the numbers?

It is especially important to get the fourth one right. You have to display understanding for her concerns and be genuinely open to alternatives, while gently reminding her that "get it done in the time I alot" is not an option. If you come across as sarcastic or condescending, you will hurt your chances for reaching a constructive relationship with your manager.

She still won't be happy, but the best thing to do here is to take her concerns seriously (maybe you are missing an external deadline) and to engage her in your estimation process so she sees for yourself that you are not simply being difficult on purpose, or too dense. She may manage your time, but you have to manage her expectations.

Answer 3

I find the PERT estimation useful for software development tasks. Summarising:

a = time if you fly through it, no delays, no problems

b = time you think it will realistically take given known delays and known problems

c = worst possible scenario, everything gets delayed, your other bosses give you extra work, and you find a flaw in your implementation at 80% through your plan

Estimated time = (a + 4b + c) / 6

Variability = (c - a) / 6

Say you think a task would take a day in ideal conditions, and normally you'd get there in the next 2 days because of meetings, but there are a few stages that could cause problems and then it would be 9 days. Then your estimate is (1 + 4x2 + 9) / 6 = 3 days, variability is 1.3 days, so you would say "I expect to get it done in 3 days, but it could easily take 4.5 days."

This way, they have an idea of when to expect it (for delivery to customers, you want to estimate the time to delivery in calendar days, including the effects of meetings, holidays and so on), and an idea of what a conservative estimate might look like. If there is a big variable, like 'it might break component X, so then I'd have to modify and rebuild that component, which would be an extra week', then flag that up in the response - 'I expect it to be done in 3 days, but it tests the limits of component X, so there could be an additional week there'.

This is one of the hardest bits of working in small businesses with multiple competing demands on your time. So grasp it with both hands and don't shy away from giving estimates. The sooner you get a handle on it, the better things will be. If quizzed in person, don't be afraid to say "I can't give you an estimate that would be any use off-hand, let me send you something by the end of the day".

Good luck.

Answer 4

Estimating timeframes is an important skill, work on it. Factor in everything you know, give yourself a healthy and generous margin and give the estimate. As you progress this gets easier and easier. If there's multiple variables, factor them all in, each with a margin.

Otherwise you get stuck with what you got stuck with, a wildly inappropriate timeframe you're struggling to meet.

Answer 5

You say: "She'll then assign me an expected time". This is probably the most important thing to address. She's asked you for an estimate. You have been unable to give her one, so she has gone ahead and made a plan anyway.

The point is that as the technical specialist, your estimate is probably the best one available. Has she just made up a number, or has she got a basis for the number she's chosen? It's probably reasonable for you to ask how she's arrived at it. You may need to use all the professional tact at your disposal, but running away from this won't help either.

The distinction between an estimate and a plan is crucial. In refusing to give her an estimate, perhaps you have given away your opportunity to influence the plan. It might be possible to say: "I really don't know, but I understand we need to plan something." At least then you can discuss the plan. As it will be based on inadequate information, you'll want to plan to replan it. Often it can be really helpful if you can say when you think you'll know more. For example, "At the moment I don't have enough information. It's impossible to estimate it right now. In order to make progress, I'd suggest we start by planning 4 weeks for it, but I'll know much more by the end of the first week, so let's meet then to see whether that's anywhere near the mark. Is that going to work for you? Are there any other constraints I need to know about?"

Answer 6

Does she ask "how long will this take" and expect an answer right now? That would be utterly ridiculous and incompetent. I'll assume that she is not incompetent but wants a proper estimate.

There is a commonly used strategy for getting good estimates which is used by agile development / scrum. For a proper estimate, you need a precise statement what work needs to be done, and what the acceptance criteria is. Then you split the work into components that take at most two days each. Then you estimate how long each component takes. I mean you estimate. Your manager can't estimate. Your manager can state their wishes, which you should completely ignore, because wishing doesn't get the job done. And you don't make any estimates for anything taking more than two weeks, because that is just about impossible to get right.

Making these estimates will take you considerable time. Probably a day or so. It's not lost time, because doing the estimates, you find out what all the components are that need doing. So you are prepared when you actually start the work. It may be that you also need to write down the specifications what needs to be doing. Which also takes time, which is also not lost because without some decent specification what you want you might as well not start.

And when you make that estimate, you take everything into account. Mostly you take into account that you are not working 40 hours a week without interruption. And then you take into account the minor detail that you are working for three people, so instead of 30 hours a week she will get about 10 hours a week of your work.

One answer showed something like "customer sign up functionality". That's much too little for a proper estimate. There's so much you will be missing. Something like this, you need to write down all the components, ever item that needs doing. Overwise you will not estimating, you will be guessing.

And finally, stop doing 50 hours a week right now. As a salaried employee, maybe you need to work overtime if it is needed due to business reasons. A huge backlog that was there before you even started isn't a business reason. That problem isn't solved with overtime, and not with unpaid overtime, but by hiring another employee. And a manager who is incompetent at making estimates is also not a business reason.

Answer 7

Split the task you have been asked to do in subtasks. Estimate how long each task should take. If any task is either hard to evaluate or longer than, say 2 days, split it again.

Once you have a list of small tasks, re-evaluate to make it consistent. Add whatever margin needed to make you feel confident (e.g. x2 every estimate)

Group you subtasks in deliverable features of possible, then give a schedule to the PM.

This planning work is usually done in collaboration with the team, the team lead and with input from the PM, though (to split in features, and give priority to these).

Answer 8

If I know what I'm doing with every piece of technology involved and know the infrastructure, and a project manager asks me how long a given task will take, I sketch out a flow diagram, break that down into components, estimate each component, add it all together. That's my hours estimate. Then I take that number and multiply it by 2.5x. This allows for unexpected problems.

If there's any part of it that's unfamiliar... add 5x for unfamiliar infrastructure, 10x for unfamiliar programming language, 10x for unfamiliar RDBMS product. I usually nail it within 10% of this adjusted estimate.

Answer 9

Some good things others have covered: take some time to break down the task into smaller chunks that you're more familiar with; give the best estimate you can; update as soon as you know more. I'll add something I haven't seen yet: give a confidence interval.

Think of it from the other end. As a PM, I have to ask people for estimates all the time. My org is growing and we're not collectively used to formal project management - so people often refuse, which drives me nuts, because I have nothing to work with and no idea when something will be done, so I can't make status reports or tell if we're on schedule or need to reprioritize, etc. So, it's understandable that your third PM's eyes are bugging out when you don't answer, even if they're not handling it that well by making up numbers and putting more pressure on you instead of helping you through the process.

And I get it, you won't really know until it's done. But if you think about it, you probably know at least a little bit more than the PM - five minutes, five days, five months? Here's what I do when I'm the technician and I have to give an estimate: give two instead.

"There's probably a 50-50 chance that it's easy and things will go smoothly, in which case it'll only take about 5 hours, which with my current workload means I should have it for you in a week. Even if it goes wrong in a few ways I can think of, I'm 90% sure it should take less than four weeks."

Do check in again once you know which of those is more likely, especially if something unforeseen has blown up and you think it might be longer than the second estimate.

Also, if the estimates the other two PMs have been giving you (presumably based on past experience with others in your role) have been reasonable, consider asking those other project managers for help with the third. They may have some insight to offer - either on the general skill of estimation, or on the specifics of what sorts of tasks your new role is typically responsible for and how long those usually take.

Answer 10

Being "NEW" is not the problem here.

Providing estimates, as a new or old employee, is a pain until you master the magic words to ease every PM's firing thoughts...

We recently started following scrum and obviously estimating our tasks. It's difficult to estimate tasks, especially when working on new technologies.

Enough talking, give me the solution now?

Here is a fantastic article which I believe fixes issues with estimates and will makes you less stressful, as it did for me.

Simply add risk to your estimates:

Section	Line Item	Estimate	Risk
customer sign up functionality	design html & css	12	MEDIUM
	create new asp.net page	4	SMALL
	add javascript validation	6	SMALL
	post sign up details to 3rd party API	16	LARGE
Total		38	MEDIUM (76.25%)
Best		29
Worst		50
Avg		40

_{(example table taken from the above linked article)}

Based on my experience

You can't ask a PM to slow down, but what you can do instead is give your best estimates with risk factor. This risk could be anything e.g. New technology, third party software, disorganized code of ex employee etc..

Not sure how desperate you are for this job, but don't spend a second working overtime for free. Ask yourself, would you pay you extra for no reason?

Answer 11

I haven't seen this answer...
Talk to your immediate manager/boss and ask them what the priorities are - how many hours per week should you spend on each of these items as well as other items (research, education, team meetings, etc.) A few years ago I became overcommitted, and worked with my boss on how many hours per week to spend on each type of item. That worked great. If a task type was allocated 10 hours, and I knew something would take 40, then it would be about 4-5 weeks. I would also caveat any deliverable date with any prerequisites such as needing information from other people.

As an aside: Consider taking one short class (credit or no-credit, an EDx class maybe) in project management to be able to manage your projects and to "manage up" to the project manager. A little bit of research and understanding will give you many of the tools mentioned by the other answers.

Answer 12

One more point that wasn't mentioned yet: Talk to coworkers who have done similar tasks (if they exist) and get a feel for what timing is usually necessary.

I was in this same boat when I started my job. I had to report to 3-6 project managers (depending on what projects I was working on) and they ALL wanted to know how long things would take.

I did my best to estimate, and yes - my estimates were quite off at first. Usually on the low end. (To the point where one of my project managers always multiplied my estimates out by X percentage before telling it to the client!) Eventually I started adding a generous buffer to every estimate that I said (even when the buffer seemed unneeded!) and my estimates slowly started getting better.

The biggest help, though, was talking with coworkers. If a project manager asked me how long something would take, and I really had no idea whatsoever, I'd ask for a drop of time to get back to him/her, and then I'd catch a coworker for a few minutes to get his/her sense of what's involved with task.

In cases where I couldn't do that, I would give my best estimate - and then later go talk to a coworker & get an idea of what his estimate would have been. Although it doesn't help in the moment, the goal is here to improve over time, not to get it right the first time.

Estimating is hard. Don't beat yourself up about it; just focus on trying not to repeat the same estimation mistakes twice.

Answer 13

In a negotiation, the person who names a number first, loses.

Your answer should be "That depends, what expectations have been set? what are the hard deadlines? What other tasks are dependent on this and what are their deadlines?"

Note, don't ask them what the urgency level is, because then they get to tell you it is critical for the survival of the human race.

Also, don't ask them when they WANT it done. That will give them an opportunity to say 'yesterday'.

Then, depending on their answer, you can follow up with anywhere between:

Sure, I'll get it to you by then (whilst secretly knowing that's twice the time you need).

Through to "That won't be feasible with my current workload, if it needs to be done then, you'll have to speak to one of the other managers and rearrange some other work." (Note, make sure THEY speak to your manager, not you).

Or even the extreme of "That isn't feasible even if I have no other work to do, which may require either more people to work on the project, or resetting customer expectations."