Negotiate Estimates

An AntiPattern.

Sometimes managers think that they can negotiate time estimates for a project. That is, if the engineers say the project will take twelve weeks to do, managers will "negotiate" by giving the engineers eight.

The negotiations sometimes work like this: "Work overtime and on weekends and sacrifice your soul to the company or you're fired!" [A good response is to quit.]

This is not a good idea. It has often been shown that engineers are very good at estimating how long a task will take.

It has? Where? Not in my experience. (This was in companies where very little feedback was given on how well estimates were met). I'll buy "developers can come to be good as estimating" (and even if they aren't, I'm not arguing that managers will do any better) -- PaulHudson

Therefore...

Estimates are not negotiable. Requirements are.

---

If managers feel tempted to NegotiateEstimates, what I usually do is to put the task and the estimated time in a TaskDatabase. Then the manager doesn't feel confident enough to change the estimate himself, he rather goes to talk to you and asks you to change the estimate. Look at him, ask him why and listen carefully. Then tell him you can reduce the scope, otherwise you won't change the estimate.

Really smart managers usually can code and they can come up with good estimates themselves. If the estimates you are proposing are too expensive, managers can always take the task from you and assign it to someone else. It is harmful if managers do the task themselves, because managers are there to manage, not to concentrate on only one task. An engineering mistake usually costs between $1,000 and $10,000, while a manager mistake usually costs $10,000 to $100,000 if not more. That's why managers usually have better wages than programmers, because their mistakes are more expensive.

Really good managers take the estimates that are not acceptable and do not NegotiateEstimates, but divide the tasks in several smaller tasks (usually 3). Then each subtask is reassigned according to expertise area and availability, for developers to estimate themselves. See EstimatesLongerThanThreeDaysConsideredHarmful. -- GuillermoSchwarz

---

It's kind of amazing that managers do this for software. Can you imagine the manager of a civil engineering project saying "I know you said that beam needs to be that size, but I've put it in the plan at 50% of that"? -- PaulHudson

---

I'd say that programmer's inability to estimate accurately is in itself a good reason why estimates are not negotiable: No one at the table has any rational basis on which to negotiate.

"My numbers may be arbitrary and fictitious, but your numbers are biased and politically motivated. I won't budge unless someone can give me a logically sound rational reason to do so." (And threats do not count! ;-)

---

In the book DeathMarch, this is described as a game called GuessTheNumber.

---

I came across these comments recently. They are one of the biggest dangers of trying to NegotiateEstimates.

"I have experienced that when I give my estimate, the managers says it's too long. So what if I shorten it, and miss it? Won't I, in my managers eyes, just be missing it to prove him wrong? What if I stick to it, and finish early? The manager might think I tried to gain free time."

"However, if I don't shorten it, then my manager will know I'm just avoiding the aforementioned dilemma. Therefore, the solution is clear. Never go up against a Sicilian when death is on the line."

"What do you mean, shorten it? Your estimate is what you believe, period. If you say a number smaller than what you believe, you're no longer talking about an estimate. So stop calling it an estimate." -- DaleEmery

---

Maybe this game is a primitive, knuckle-dragging form of the PlanningGame. Let's listen to manager "Og" and programmer "Ook":

• Og: Ook, when can you have that wheel reinvented?
  • (Ook thinks about the hundreds of nifty features involved and presumes they must all be delivered)
  • Ook: About a month.
• (Og subconsciously thinks, "Surely something has been miscommunicated, the product I'm envisioning is simple.")
• Og: That's too long!
  • (Ook reels at the thought of producing so much in so little time, violently negotiates the estimate for a while, ultimately realizing the only way he can hit that deadline is to give them a simple solution.)
  • Ook: I guess I have no other choice.

The conversation ends, with both sides making implicit tradeoffs, and both end up feeling like the other is an idiot.

I find that it is very rare for a manager or customer to expect something simpler than what the developer is envisioning. Managers almost always expect the outcome to be "complete", meaning that it perfectly fulfills all imagined (and unstated) requirements and will require no further work as development on the rest of the system proceeds. And managers are always disappointed with the "incompleteness" of any solution, whether or not it fulfills the immediate real needs. I'd love to have a manager like Og, but I guess they all died out in prehistory. The right thing to do in this case is for Ook to explain how he arrived at his estimate, and for Og to pay attention and to correct any mistaken assumptions Ook has made. If Ook's assumptions are correct, then Og should accept the estimate. Both Ook and Og are idiots if they don't discuss the disparity in expectations and estimates. --KrisJohnson

---

And there are a few ways the scenario may end in.

Scenario 1

Ook completed the simple wheel in a month, both Ook and Og is happy.

Scenario 2

2 weeks later, Og come and "take a look" at how Ook is progressing.

• Og: Umm... Wheels ought to have shock absorbers, and it got to have anti-lock braking otherwise we can't sell it. Put those in, and finish it by the end of the month.
  • Ook: ....

Ook learns that the word "simple" means very different things to different people.

---

My experiences are it is a political reality that even a most meticulously done technical estimate has to be prepared to be drastically slashed by management. That does not mean people in charge does not value your efforts and input, they have to work within their environments too. --dl

Btw, last change to this page was in the preceeding section, in mid2002 by KrisJohnson.

---

Developers are generally poor with estimates. So poor in fact that the only people worse are managers. --210.54.73.23

Developers are not always poor with estimates. However they often do so with hands tied and eyes blindfolded. Managers, on the other hand, make poor estimates with ulterior motive, there is a discussion area in ProjectCostEstimates if you would like to expand on your views.

---

See also NegotiatingWithManagers

---

I have never heard of a manager saying "I don't care if it you think it takes X. I think that the task should only take X/2, and that's what I expect! I don't care if you have to work evenings and weekends. Get it done, or there will be hell to pay."

I, however, have encountered plenty of managers using a more subtle tactic: "We need to have the project done by X, otherwise we miss the MarketingWindow and will have to cancel it." Where the justification for the MarketingWindow is somewhat dubious.

This tactic can work when a design team invests themselves too much (emotionally) in a project or product--and wants to see it completed, come hell or high water. BeenThereDoneThat, won't do it again.

In some cases, the MarketingWindow is legitimate (a customer-imposed deadline, the need to be on the shelves by Christmas, etc.) in which case the FlexibilityMatrix? (and accordingly, the project's scope and resources) should reflect this deadline. In other cases, though, the "deadline" may be a negotiating ploy, to increase the productivity of the design team. (Whether it actually does so is highly debatable).

When given such a challenge, the correct things to do are:

• Ask for justification of the deadline. Justification along the lines of "the marketing department says so", or "we need revenue in this fiscal year" are generally suspect.
• Request more resources, or a smaller scope. Emphasize that your estimate assumes that you work at the maximum sustainable rate.
• If all else fails, and this is the hard one for many--agree with management that maybe the project should be cancelled. In other words, call the bluff. If they aren't bluffing, and the project is cancelled as a result--this is probably a good thing--embarking on a DeathMarch with little risk of success is good for neither the organization as a whole, your boss, or you. If they are bluffing; they often will become more flexible in the schedule.

---

CategoryAntiPattern CategoryScheduling