Estimates and Why They Are Not Accepted

I just delivered a training course in Lahore on software effort and size estimations yesterday. Most of the people present were project managers while three were technical head of departments in their organizations. What was surprising was the fact that quite a few people, almost 1/3 of the total participants, had flown in from Karachi to attend. During the course of the event, I heard a lot of the grievances people had from both management and customers when making estimates and why estimation was considered, at large, an exercise in futility. The basic problem, I learned, was that inaccurate estimates, given at the very beginning of projects were accepted, and any educated estimate made later, even after uncovering requirements and details, were rejected.

Why exactly is this happening, I wondered? And put the question forward to the group. Here is what they had to say.

From the PM’s:

• We’re not given enough time to think of the answer, but have to provide it from the top of our heads, usually within a couple of minutes in a meeting or a phone call.
• Our estimates are overruled by the time line the client wants, not by how/when we can deliver it.
• We’re not included in the pre-sales process, our input is not taken on whether we can even do the project. Management selects everything and then tells us what to do.
• Our projects are all different, in new areas, and we have no idea how long they would take to complete.
• Things go wrong all the time, and we don’t know exactly how long it would take to each task, especially if they involve talking to the user. How can we tell this to our management?
• We dont know of any other method than to ‘guesstimate’, and management makes better guesstimates.

From technical heads:

• We already have an estimate in our minds before we ask our PMs. If they match what we think, we go ahead, otherwise we adjust them.
• If we give them shorter, tougher time frames, it will make them work harder! Otherwise, developers just waste time on orkut or facebook!
• PM’s don’t know what they’re talking about, they dont have enough experience.

The disconnect?

Somehow, it seemed a majority of the PMs were giving excuses, not reasons. The only thing is, when you are a developer, all of these seem like valid reasons. I believe that is where the disconnect lies between PMs and their Technical department heads. The fact that each of them thinks both the best and worst of each other, and both at the same time.

Let me clarify this a bit more.

On one side of the equation, you have PMs, who neither asked their management to give them time to think things through, nor educated them about the accuracy of whatever estimate they are giving. When management asks, ‘how long will this software project take to deliver’ and PMs say ‘about 20 days’, they will either think a)”this guy knows what he’s talking about, if he says 20, then it’ll take 20″ or b)”this guy doesn’t even have a clue. 20 days is too much because last project i did [or supervised] took only 10!” and so on. So people whose reputations have been established, get away with it, while everyone else gets to be pressurized into making estimates which sound good.

On the other side of the equation, management will react to an estimate given their own personal orientation. They either lean towards being optimistic or pessimistic. Tell an optimistic manager that you need 20 days and they’ll hear 15 because they’ve got the best team who will not make mistakes and there will be no rework, but if you tell 20 days to a pessimistic manager, they’ll hear 25 because they are sure the team will screw up and they’ll get major defects to work out later. However, a lot of them never consider the ‘accuracy’ of the original estimate in the first place, because well, they got it from someone who knew their job and they can deliver it in that time.

But what is the accuracy of an estimate anyway?

In general, a top of the head estimate given very early on will be anywhere between -25% to 1000% accurate. Which means, that a 1000 hour project might actually take 750 hours or upto 100,000 hours. (Projects have been known to overshoot their original estimates by as much as 3000% as well). The more information you have when building your estimate, the closer you can take your accuracy range. E.g. making an estimate of work after uncovering requirements and developing the design will take your accuracy down to within -5% to 10%, meaning you can complete the same 1000 hour project in anywhere between 950 to 1100 hours.

So what now?

Once this fact was made clear during the course, I got another very interesting question. So what if my estimate is accurate or inaccurate, how will I explain that to my management? The answer? Explain it to them! Tell whoever is asking for an estimate just how accurate it is at that point. Something like, “I think this project can be made in between 20 to 30 days, however since i don’t have much information at this point, this estimate will only be accurate within -25% to 100%. Give me more information, and i can generate a much more accurate estimate.” You’ll be surprised at just how many managers will tell their clients they can do that project in 40 to 45 days or give you more time to come up with a better estimate. No one wants to end up with egg on their face.

I’ll be giving another course on estimation tomorrow, this time in Islamabad. If i get any more interesting reasons on why estimates are not accepted, I’ll add them up here. Till then, happy estimating.