Give Me Estimates Now

A management and schedule AntiPattern.

A client (or PointyHairedBoss) demands estimates before you have enough data to deliver it.

You accept the "challenge" and give out of the head estimates (i.e. guesses).

The client/boss then treats the estimate as an iron-clad commitment.

I generally try to give an estimate of how much time and extra info i would need to produce the desired estimate -- SvenDowideit

Tried that - boss doesn't buy it. Lower accuracy is suggested instead. Funny thing is however inaccurate the estimate is said to be, it turns into a deadline. -- JoeOtten

When pressed, and the boss needs a take down, I say something like "probably less than <some-really-big-number> ... I could be wrong though and it could be more." He usually says he wants a more accurate estimate, I say I want more accurate information to base the estimate on. Point made.

I would recommend " probably more than <some-really-big-number>" -- GeraldoXexeo

Boss wants a less accurate estimate? Fine - estimate from longest to longestx2. Less accurate does not mean shorter....

Why do you think it is better to over-estimate rather than under-estimate? My mantra is that my guesses will be wrong approximately 100% of the time, but on average they will be right.

The effects of incorrectly under-estimating are usually disproportionately worse than incorrectly over-estimating (when there may not be any ill effects at all).

Whatever number you give, that is going to become The Number. Managers like hard numbers, and all qualifications ("probably", "more than", "less than", "ball-park", "rough order of magnitude") will be ignored or forgotten. The best strategy is to give a safe estimate based upon whatever information you do have, and absolutely refuse to let anyone talk you down without additional information and time for analysis.

Just say "anywhere from one day to one year" (i.e., ridiculously small and ridiculously large). Don't pronounce anything that can possibly be interpreted as a plausible deadline.

Alternatively, you can try to find out how much time/money the client/manager is willing to spend, make that the number, and then give an estimate of how much of the desired work can be completed within those constraints. Again, be conservative based upon whatever certainty you have, and refuse to promise more than you can deliver.

See also NegotiatingWithManagers.

-- KrisJohnson

My experience agrees very much with your observation. One more thing is that some managers will throw in vague promises as "additional information", usually with phrases like "just a common XXX system", or "nothing fancy", etc. Don't fall into that trap, his idea of what's "common" or "simple" may not coincide with yours. Instead, press them for concrete, precise requirements by citing examples. e.g. if he wants "just a common text editing function for the XXXX", ask if it is functionally similar to MicrosoftWord, or Notepad, then list out the features of it for confirmation, (setting fonts, embedding images, undo buffer, menu bar, load/save, online help, etc), he will likely tell you to email him with the list so he can look at it in detail, because he is not ready to confirm the requirements at that point. If he presses you for an estimate anyway, assume you are going to build a full-blown Notepad. Or you can ask if they can use Notepad instead. -- OliverChung

I am not sure I understand all of this hesitancy to provide a prediction (and prediction is the correct term, not estimate). This type of information is often needed for overall budget, manpower, or availability planning; and these are things that often do have to be planned early and are difficult to change later. Presumably, if you are being asked to provide this type of prediction, you have the experience and knowledge necessary to make it. I have also found that after about the first day, extended analysis time does nothing to improve the accuracy of the prediction. If you are already knowledgeable about the system, you will not find any startling new information over the next several days or weeks.

Estimates are unreliable, particularly in software development. A client that demands estimates obviously believes strongly in estimates. Perhaps it would be best if we saved the client from disappointment when the estimates inevitably do not match reality.

A second point is these requests are for information, not "The Number." Be prepared to negotiate. If the time prediction is too long, what other things can you alter to meet a target date? What if we drop or defer this capability? Can we hire some consultants or borrow Al and Bill from the other project? Can we buy an expensive existing product? Don't just provide a number, help juggle the constraints to find the one that best fits the situation.

Borrowing Al and Bill from other projects has a potential pitfall: they may not do good work, because their bread is buttered on the other project, not yours (which they regard as a distraction/chore). If your good name will be at stake, but not theirs, then resist being pushed into this situation. If you find yourself in this situation, be prepared to check their code quality ruthlessly.

Check out the ScrumBook, which describes just how unrealistic 'estimates' are, and an alternative way to provide about the same level of emotional assurance the customer/manager wants without committing to the unpredictable.

In my opinion, RapidEstimates are a must to keep the ProjectUnderControl. No developer should continue his coding unless he has estimated all his pending tasks. You would find this awful, especially if I forbid any estimate to be longer than 3 days.

Developer: No problem. I will divide the task in several smaller tasks. All the tasks that can't be done by me, will be assigned to other groups, with no estimate from me and not including their tasks in my estimate. I will even divide my tasks so that I can estimate the smaller ones and then assign a big huge estimate to the one that will take the most time.

Manager: Mhhh, everything seems fine, except this big huge task here that takes more than 3 days. In total, if I remove that task, everything is okay, I will then reassign this task to the developer that is the strongest in this area, (probably me), he will divide this task and assign the remainings to this developer who was collapsed by this task.

The same developer as above, eventually receives the same task he overestimated, but now the pieces are smaller. The estimates for most of them will be small and possibly one of those task will again be too much. The manager repeats the process until all tasks individually take less than 3 days or a number of days agreed before the project started.

See TaskDatabase for a proposed solution and SomeNumbersAreLies for a related AntiPattern.

-- GuillermoSchwarz

Give him the best number you can, and let him know when it blows out. If he whinges, just say "Bugger me, I'm sorry, but it's going to take as long as it takes", as nicely as you can. If he is any good, he won't whinge. Part of the job of a manager is to deal with shifting situations like this. To ManageYourManager, give him accurate, timely, honest feedback on project status.

As a counter argument, I have usually found that predictions that take longer than about 1 work day to produce seldom provide additional accuracy. I am not condoning hall way or in meeting responses, but if one is qualified to provide a value, then the first impulse is going to be as close to correct as any follow on. If one is not qualified, no research short of doing the task will make one qualified.

And yet we usually need to estimate (predict) things that we've never done before, often using systems or new versions that we've never worked with before. Even if no one is qualified by experience, we still have to have that Number. More research may not help, but rather than assume that the first impulse will be correct, the fact that more research is needed should be seen as a sign that it's probably going to be more incorrect than normal.

Terminology Soap Box: What we are discussing is Predictions not Estimates. An estimate is an approximate measure of an existing thing. I can estimate how long a previous task took. A prediction is an opinion of a measure for a future thing. I can predict how long a future task will take. Depending upon the mechanism used, the accuracy of an estimate can be bounded, but not a prediction. Most predictions may fall inside a range, but extreme outliers may still crop up.

-- WayneMack

The main thing is contingency, the EightyTwentyRule: 80% of the functionality takes 20% of the time to develop, the other 20% takes 80% of your time. ALWAYS split into 2 estimates. For the core functionality, give a precise estimate. Then for the acceptance testing, demands that aren't in the specification, tweaking the gui/reports to client's exact preferences, etc, give huge leeway. I once coded all of the functionality, tested, and deployed my app in a month. Then I spent over 5 months moving a field on a report .5 inches to the left, adding a box around text, changing font sizes, etc, endless changes. Base your estimate only on delivering EXACTLY what is on the requirements without any regard to formatting.

How about sketching a graph? Label the x-axis time, label the y-axis P(x), sketch a skewed bell curve with a very rough estimate as the peak, and tell the manager it's an estimate of the probability of finishing within a given time? If they set a deadline too soon, tell them the probability you can meet it (refer them to the graph). When an event only happens once, a probability estimate can never be demonstrated to be wrong.

Timothy

Speaking from the management perspective, I think there is a place for GiveMeEstimatesNow. For example, during the product definition phase it is useful to have a rough idea of how long each feature will take when making tradeoffs. Later, during early development, it is useful to have estimates for how long tasks will take even when some of the estimates are guaranteed to be inaccurate (for example, because the architecture has not solidified).

*Some* information now is often just as important as *better* information later.

The trick is to make sure that the manager and the engineer have the same understanding of the level of certainty and commitment around these estimates. Every manager will do this differently. You could imagine keeping track of the "reliability" of an estimate on a case by case basis, but for simplicity, I like to break estimates down into two categories: time budgets and time estimates.

For me, a budget is a swag without detailed design and understanding behind it.

Engineer: "I would have to do some prototyping and some deep design before I can commit to an estimate, but I think if we put in a budget of two months, that feels about right."

Meanwhile, an estimate is a date that the engineer feels comfortable standing behind. If the estimate is vastly different than the original budget, it may make sense to see if the estimate can be made to fit the budget, but not at the cost of ignoring reality.

Engineer: "I thought about the problem, and the estimate is going to be five months."
Manager: "Wow! What happened?"
Engineer: "Well, I realized that the Frobozz subsystem needs to be rewritten."

At this point, the question is whether the Frobozz subsytem actually needs to be rewritten. If so, as a manager, you should be thankful that you know this up front. If not, you and the engineer can have a conversation about not rewriting the Frobozz subsystem.

-- ShoKuwamoto

The story of business. One must often give a ProfessionalGuesstimate, and this is the only number, win or lose. It becomes necessary to estimate to the best of your ability, including doing your homework first, then double and sometimes even triple that number. ProfessionalGuesstimateing or EducatedGuesstimateing, is an art, and this type of business is not for the faint of heart or those that can't afford to lose sometimes. Often it is associated with luck, but this is untrue if done correctly, as it is not a gamble.

Questions to ask:

Why do they want to port their system X to our system Y?
How do they use their current system?
What will be the effects of this on their business?
What other alternatives have they considered, and why were they rejected?
What are the time, money, quality priorities? If one is extreme, why?

Often in a GiveMeEstimatesNow case, none of these questions have answers. Or they may not be communicated because you're JustaProgrammer and don't need to worry about those things. But not understanding the purpose of the project can result in dramatically incorrect estimates and later even total project failure. Asking business-oriented questions can buy time to develop a more realistic estimate and may also get the managers and/or salesmen thinking whereas asking technical questions would just result in vague ripostes ("they just want a widget like Z, how many hours?").

Policy of a successful Vice President I used to work for at a major well-known international company: My estimate for anything when I have no idea is six man months. That's something that can easily be funded and staffed, and we can always do something interesting in that time frame.

(Personally, I think that six man months may be a bit small: Maybe good for a prototype. I think that with six good people in six to twelve calendar months, we can come up with a darn good solution to just about any business problem. ...with some bells and whistles. Can't replace all the legacy systems in that time frame, but that may be a bad idea anyways. ;-)

I personally stick to a policy that I will never change an estimate until/unless I have more information. It doesn't matter how irrational and uninformed the estimate is, or how much other people don't like it. An estimate is my best guess, given the currently available information. It can't change unless the information changes. More and Better Information = Better Estimate.

The best estimate is available after we finish, when we can tell you how long it took and how much it cost (But only if we kept good records, which is often not the case). ;-)

One of the things that one of my Masters Profs told me when pressed for a prediction was to determine the time you think it will take, double it and add 10%.

Not sure if he said this tongue in cheek or not but it made sense to me.

Just extend your pinkie finger, raise it to the corner of your lips, and say "One million dollars!"

See: GiveMeEstimatesNowStory, GuessTheNumber

CategoryAntiPattern