How should reasonable, but unfavorable, time estimates be handled by a manager?

Question

Presenting time estimates is a negotiation process: worker gives a high estimate, manager pushes to get the work done in a shorter period of time. However, besides this old-fashioned downward pressure, I also feel that in the face of an unfavorable estimate from a worker, it is the manager's job to reach a reasonable compromise, including, but not limited to:

• Reducing the task's scope to keep a deadline
• Changing the project schedule to allow more time
• Delegating work / increasing team size
• Schedule the task for another time
• Have a brainstorming session to find an alternate task that can be done in the allowable time

However, what we are facing is that, instead the above, many estimates are relentlessly argued down until the new estimates fit into the boss' idea of how much time he wants to dedicate to the task, not how much time is actually required. Employees can never win these arguments because the manager's estimates are based on infallible "experience-based" assumptions about how the work should be done.

Ultimately, when an employee gives up arguing, he or she always ends up never being able to meet the new estimates, and if there is a schedule slip, it becomes a failure on his or her part, not on the manager's.

Having a technical conversation to justify the original estimate is rarely productive, and even if productive, is exceedingly tiresome. In many cases, I feel that alternatives such as the ones above would be vastly preferable to setting an unreasonable expectation, but these alternatives are never chosen.

So.. what to do? Either are acceptable answers:

1. Suggestions on how a worker can best present unfavorable time estimates (bearing the bad news)
2. Better ways to handle incoming but unfavorable time estimates from a manager's perspective.

Sample conversation:

Manager: How long will it take to finish Task X?
Worker: Y Weeks.
Manager: Y weeks! That should be easy, it should only take Z days. You just need to foo the bar, piece of cake.
Worker: I could do it in Z days, and I know about fooing the bar, but I'd still have to make sacrifices A, B, and C.
Manager: It could be done in Z days without making those sacrifices. You can do it. Just foo the bar.
Worker: (after several attempts to justify the original estimate) OK, I'm really not sure of that but I'll try.

(Z days later, after working furiously on the task, staying late, working at home, etc.)

Manager: You're not done with task X.
Worker: I tried the best I could but I am having trouble dealing with A, B, and C.
Manager: OK, then keep working on it, we really need this task done.

(Y weeks later)

Worker: I'm all done with task X and it works great.
Manager: Great, but it took too long and we've really fallen behind while you were working on Task X.
Worker: :-(

Answer 1

I like HLGEM's answer from a Cover Your ASSets perspective and for reasonable expectation setting on future projects. Having a personal repository of past estimates (both yours and your manager's) is extremely beneficial - both for future productive work and for an unfortunate case where a person needs to dispute an unfavorable performance review. Also the scope management and expecatation setting guidance will work well in many cases, although I think you need to balance caution in whether or not you work over time... based on some details I've put in below.

What struck me, though, was that original question - what does one do at the start when unfavorable estimates are initiated, to correct the issue? - hadn't actually been answered. So, here's some tips that have worked for me:

1 - Listen and ask for Detail

A classic problem in any negotiation is that both sides think they have communicated effectively - which means both sides believe that they have fully understood what the other party was saying and that the other party understands them. Very often, this perception is false. Particularly in the gap between management and technical worker, jargon and process can cause a severe rift.

In the example raised above, I'd be asking the following questions:

• Does everyone define "foo" and "bar" the same way? Clearly the employee sees "fooing the bar" as something that raises issues A, B, and C. WHY doesn't the manager see "fooing the bar" the same way?

• Do we all agree on the likelihood of issues A, B, and C? Maybe the manager sees them as a 5% chance, while the employee knows there's an 80% chance of these things happening. Why doesn't the manager see them as an issue? Why does the employee? It's not usual that processes or technology have changed since the last time the manager actually did this type of work (if he EVER did this type of work...) and he may rightfully think of these things as minor - based on the information he has available.

• Do issues A, B, and C matter? How much do they matter relative to finishing the work on time. Can we call call it "done" if A, B and C are still open issues? Why? Why not? As both a manager and an employee, some of the hardest debates have been these. As a manager I've gone both ways - I've delayed schedules based on employee explanations of why the issue is catastrophic, and I've told employees to suck it up, and leave the issue open in other cases - this is where I figure I earn my pay as the boss - I know when to fix or not fix something because I understand the business and the tradeoffs involved.

• Why the crunch? Very very few managers I've spoken to who are worth any degree of respect will willingly burn out their people to accomplish a job. In cases where you are at the "just get it done" level of negotiation, you should still ask "why". If the answer boils down to "because we will all be out of a job in the next 6 months if we don't" - then it may be time to consider overtime and dropping everything. Be aware, though, that your boss is only allowed to play the crisis card once a year or so... if you have a make or break emergency every month, then you have to start asking more questions like "why didn't we see this coming?", "do we really understand the business and it's customers?" and "what on earth in going on in the executive board room? Are you all smoking something?"

• a related but different question is "what will happen if I blow this schedule?" Estimates are done for all kinds of reasons... in one case, knowingly blowing a schedule can lead to inefficiency, because a different approach may have been taken if the real schedule was known. In others, it's merely a measurement and management mechanism - a way to set goals and expecations. This factors into project management stuff - like the "critical path", but if your manager is worth anything, he should be able to explain the critical path in terms that go beyond Microfot Project 101 and speak to the actual business drivers for your company.

2 - Speak to the Audience

One of the riskiest thing about a formerly technical manager who thinks he knows how to do your job is that he probably knows more than enough to be dangerous. The terms of technology tend to sound similar from decade to decade, while the actual activity can change remarkably.

This is a touchy area, since you don't want to ask the boss if he actually knows what all the words in your sentence really mean. Instead, you have to look for cues that the words he's throwing around show a marked disconnection from reality as you know it. Then you need to backup and redefine them with him. Often this can be done gently with connection phrases like "here's how I define what you just said..." or "let me take this a deeper level of detail so I can be sure we really understand each other..." Things like this let you do a little management-education along the way.

3 - In general

I find that technical commmunication about uncertainty is always tricky - its case where everyone has to assume more than their fair share of communicating.

Another trick is enter a "can we fix this?" conversation that isn't loaded with the need to communicate about an actual task and estimate. Finding a low-stress time between tasks and booking in some time with your manager will let you say "hey, we seeem to have this bad cycle where I give you an estimate, you don't believe me, I can't change your mind, and I can't meet the deadline, so we are all screwed... how do we fix this?". Stepping up and engaing will show the boss that you really do care, you're not just blowing him off for fun... and it gives you both some space to think about the horrible pattern without the looming issue of the next task.

Also - I'm blithely assuming that everyone in your office has the same problem, or that there is no peer of yours who has a similar set of circumstances. The answers above are general guidelines for trying to figure out other people... mileage on any particular trick varies markedly on a manager by manager basis. People have all different sorts of styles and barriers to communication and sometimes the order of operations in a communication or other less-sensible sounding factors will come into play in terms of being effective. If you have a coworker who has similar needs to negotiate tasks with the boss, and he has better luck, ask for help. He likely has a few tricks to how to manage this... and if you're really stuck, ask him to help mediate - maybe he can be a translator between you and the boss and offer more tips at how to get through this...

Answer 2

You are making a fundamental mistake, and by doing so are doing both you and your company a disservice -- estimates are not negotiable. Time estimates represent your best GUESS as to how long something will take, based on your experience.

You can break it down, but it's impossible to justify -- it's your opinion and experience.

Working overtime doesn't make the project shorter, at best it means that fewer calendar days are used, but the number of hours (which is the unit you should be giving your estimates in), will remain the same and may actually increase.

Your sample conversation should go like this:

Manager: How long will it take to finish Task X?
Worker: YY hours.
Manager: Thats N weeks! That should be easy, it should only take Z days. You just need to foo the bar, piece of cake.
Worker: IMO it will take me YY hours.

Only change your estimate in response to a change in scope or an actually change in your estimate (either up or down). Negotiating your opinion is just a fancy phrase for lying...

Please note that this does not mean the manager is wrong about how long it will take, or that he shouldn't budget it as he feels best -- that's an entirely different matter. But the worker asked to provide an estimate should provide an estimate, not parrot back whatever the manager says.

Edit in response to comment: it's been suggested that the employee should be keeping track of his estimate, the managers estimate, and the actual time. And the fact of the matter is that he should be doing so, and so should the manager. They should be doing so, so that they can both do a better job of estimating the time for the next project, with more confidence and experience.

Answer 3

Document it all. Keep a spreadsheet of your intial estimate, the lowered estimate and what it actually took. That should improve the devs estimation ability as well as show the manager what simliar tasks took in the past. If the manager is reasonable, just being able to show past history may help him. It also gives you something to show to senior management when the line manager tries to throw you under the bus for failing to meet the deadline you told him was unreasonable. And always object to the unreasonable deadline in writing, stating why it is unreasonable and what you may have to cut to meet the deadline. And make sure that all the interested parties in your company are copied on that email.

In doing estimates, do them in detail. Don't forget to include time for meetings and email communications, time to write/run unit tests, debugging time (you can incude that in development time if you prefer, just make sure you incude the time). Include time to support QA and UAT testing (answer questions, fix issues found etc.) and time to do required documentation. We have a template we use that includes all of this, so we never forget it in estimating. The more detail you have, the harder it is to dismiss your estimate as inaccurate. And the easier it is to prove later that you were correct and the manager was wrong.

Next step. Do not work nights and weekends to meet a bad deadline. This just encourages them to set poor deadlines becasue you will meet them even if you go over the hours allotted, even if it kills you. But it makes it harder to ask for what you need each time after that. Well you got XYZ done in a week and this is easier. Yes but I don't want to work 120 hours every week.

Finally, do not accept any changes to the requirement without a corresponding change to the hours and deadline. This is especially true if the problem is coming from the client or the internal stakeholders not your immediate manager. We get a change to the requirement, we tell them how much more time it will take and how much that will move the deadline out. Amazing how many of those immoveable deadlines become moveable. And amazing how much absolutley needed functionality becomes not needed until the next version when you do this.

Answer 4

Let's clear two things upfront: - what are the things which might prevent a person from doing things on time; - what innovation (no matter tiny one or great one) could help a person finish a task sooner than expected.

If I were either the employee or employer I would start with those two points.

Let's take a closer look at them:

---

• things which might prevent a person from doing things on time

technicalities: - lack of proper equipment, inconvenient workplace, a lot of time wasted in commuting, distractions, etc

communication: - probably the biggest time waster. Whereas estimates are more or less guess work, bringing them down to specific components decreases the overall level of uncertainty. Almost any task, in any field, consists of work on the task itself, communication, distractions, rest, revisions, final check. Communication tends to take the most time and surprisingly, to employers, more often than not they are the ones causing extraordinary amounts of time to be consumed in this. My advice is to set an initial time limit (quota) on communication.

human resources: - not having someone on hand to guide you/ help you when you get stuck/ do a quick proof check/ etc can be a serious drawback in some cases. You don't know if and when you might possibly need external help but when you do and it is not immediately available, sinful amounts of time get wasted for nothing.

motivation: - if we could this right we could get everything right... A vast topic, yet worth thinking about it or reading something about it, on every single task we assign or get assigned. A provocative question here: could just the thought of an existing deadline demotivate one from doing things on time? Even when deadlines work as motivators aren't they just too stressful? Isn't there a better way?

---

• what innovation (no matter tiny one or great one) could help a person finish a task sooner than expected

Instead of fretting over estimates couldn't we just try to improve the task wokrflows with every new task? This is what Kaizen/ continuous improvement preaches. Let's optimize the structure of the workflow and make it as independent from the paricular human involved as possible. Then the issue of arguing over estimations would not exist.

---

Answer 5

what the manager really wants is a nice progress bar on how the piece of work is going. In my book anything estimated at longer than a week is something that needs a proper functional breakdown and spec. So I would start be producing the shopping list of tasks that need to be done till they are in the 1-2 day bracket - you should be able to produce at least 5 of these probably more. The shopping list will be like "define api" "refactor package" this kind of thing. Then when manager wants update you just show what is ticked off shopping list. They will be happier as they will feel more connected to the work and you will be happier because there will be less ambiguity. If manager is not interested in shopping list then their aggressive timeline is simply mad men style bravado.

Answer 6

This problem was solved years ago, it's called story point estimation.

You can read about it online, but basically:

You avoid management trying to manipulate developers into unrealistic time estimates by having no time estimates at all.

Instead, each piece of work is split into small tasks, and each dev (not manager) estimates the task size/complexity as a point value (1, 2, 3, 5, 8, 13... fibonacci numbers work best). Majority/average point score becomes the "estimate" for the task.

After a few weeks, the team gets consistent with what they consider a 1-pointer, what's a 3-pointer, etc (it's different for every team).

They also get into a rhythm of how many points worth of tasks are completed per week.

The manager never gets a say in how many points a job is, of course. And now it's their own fault if they expect the team to do 100 points of work in a week when they always do around 50.

Many tasks can't be estimated with any accuracy, that's just a fact of very complex work (like software development). But if tasks are small enough, and the dev team is in charge of estimation, and it's based on complexity instead of time, a manager can plan releases and manage customer expectations.

Answer 7

My experience with this was the following: I was asked to create a Microsoft Project timeline for a software migration involving a green screen to GUI in the mid 1990s. I estimated two and a half years. The person asking me to schedule the project said 'make it fit in one year'. I wasn't going to be the developer, but I knew the one year estimate was hopeless, and I made that clear to the person asking me to do it.

Basically I jiggled everything to fit in the one year timeframe. The employer committed, I moved on, and as I followed up with the people that did the work, it turned out it took about three years. This was a military project migration and there was no doubt the new system was necessary, so not doing it wasn't really an option. The contractor told the military buyer whatever they wanted to hear, billed time and materials, and got it done. If the schedule is driven by political concerns in the first place, the estimator should simply tell people whatever they want to hear, warn them that the estimate is optimistic, and leave it up to the second guessers to live with the results.