"Proper" way to give clients or managers a reality check on software estimates

Question

Looking back at my past projects I often encounter this one:

A client or a manager presents a task to me and asks for an estimate. I give an estimate say 24 hours. They also ask a business analyst and from what I've heard their experience is mostly non-technical. They give an estimate say 16 hours. In the end, they would consider the value given by the analyst even though aside from providing an estimate on my side, I've explained to them the feasibility of the task on the technical side. They treat the analysts estimate as a "fact of life" even though it is only an estimate and the true value is in the actual task itself. Worse, I see a pattern that they tend to be biased in choosing the lower value (say I presented a lower value estimate than the analyst, they quickly consider it) compared to the feasibility of the task. If you have read Peopleware, they are the types of people who given a set of work hours will do anything and everything in their power to shorten in even though that is not really possible.

Do you have specific negotiation skills and tactics that you used before to avoid this?

Answer 1

If I can help it, I would almost never give a number like "24 hours". Doing so makes several implicit assumptions:

1. The estimate is accurate to within an hour.
2. All of the figures in the number are significant figures.
3. The estimate is not sensitive to conditions that may arise between the time you give the estimate and the time the work is complete.

In most cases these are demonstrably wrong. To avoid falling into the trap posed by (1), quote ranges to reflect how uncertain you are about the accuracy of the estimate: "3 weeks, plus or minus 3 days". This also takes care of (2).

To close the loophole of (3), state your assumptions explicitly: "3 weeks, plus or minutes 3 days, assuming Alice and Bob finish the Frozzbozz component".

IMO, being explicit about your assumptions this way will show a greater depth of thought than the analyst's POV. I'd much rather pay attention to someone who's thought about this more intensely than someone who just pulled a number out of the air, and that will certainly count for plus points on your side of the negotiation.

Answer 2

You can "control" clients a little easier than managers since the only power they really have is to not give the work to you (that solves your incorrect estimates problem pretty quickly).

But you just need to point out that it's not the analyst doing the work, it's you. And nobody is better at judging your times than you are.

It's a fact of life that people paying for the work (including managers) will focus on the lower figure. Many times I've submitted proper estimates with lower (e.g., $10.000) and upper bounds (e.g., $11,000) and had emails back saying that the clients were quite happy that I'd quoted $10,000 for the work.

Then, for some reason, they take umbrage when I bill them $10,500. You have to make it clear up front that estimates are, well, estimates, not guarantees. Otherwise they wouldn't be paying time-and-materials but fixed-price (and the fixed price would be considerably higher to cover the fact that the risk is now yours, not theirs).

In addition, you should include all assumptions and risks in any quotes you give. This will both cover you and demonstrate that your estimate is to be taken more seriously than some back-of-an-envelope calculation.

Answer 3

Do you not have a work breakdown structure that validates your estimate?

If your manager/customer does not trust your estimate, you should be able to easily prove it beyond the ability of an analyst.

Nothing makes your estimate intrinsically better than his beyond the breakdown that shows it to be true. Something like this for example:

Gather Feature Requirements      (2 hours)
Design Feature                   (4 hours)
Build Feature
  1 easy form                    (4 hours)
  1 easy business component      (4 hours)
  1 easy stored procedure        (2 hours)
Test Feature
  3 easy unit tests              (4 hours)
  1 regression test              (4 hours)
Deploy Feature
  1 easy deployment              (4 hours)
                                ==========
                                (28 hours)

Then you say "Okay, I came up with 28 hours, show me where I am wrong. Show me how you can do it in 16."

Answer 4

Do you have specific negotiation skills and tactics that you used before to avoid this?

Don't work for such people.

Seriously.

Changing their behavior is beyond your control.

Answer 5

One thing you can do to try to fix this over time, and improve your estimating skills as well, is to track all of the estimates you make, and match those up with the actual time taken. If you can go back to your boss with a list of the last twenty estimates from both you and the business analyst, and the time each actually took, it will be readily apparent whose estimates you should trust.

Answer 6

Sadly scott adams had a lot to contribute to this debate

Dilbert: "In a perfect world the project would take eight months. But based on past projects in this company, I applied a 1.5 incompetence multiplier. And then I applied an LWF of 6.3." Pointy-Haired Boss: "LWF?" Alice: "Lying Weasel Factor."

Answer 7

Under no circumstances give a single figure, give a best, worst and a most likely. If you respond correctly then the next question should be "How do I get a more accurate number" to which the answer should be more detailed requirements and/or design depending where you are in the lifecycle.

Then you give another more refined range of best .. most ... likely and wost. This continues until you are done.

This is known as the cone of uncertanty I have lost count of the number of times I have drawn it on a whiteboard when talking estimates with clients.