Wagnerblog

In my experience project estimates are all over the place and often do not have any relationship to reality. Depending on any number of subjective factors the same amount of work gets turned into very untenable estimates.

Recently I watched a team of developers produce estimates that were fairly reasonable only to be asked to build the project for less money … in other words in the interest of budget constraints the devs were asked to submit an estimate consisting of less hours.

The unsuspecting developers did exactly that. In the interest of customer relationships they lowered the estimated hours of the project, thinking this would work out because the customer would be happy.

Some weeks passed. Nobody remembered why the total hours for the project were set at a specific level…as time passed all anyone cared about was the deadline. Can the team meet the deadline ???? When are they going to be done ??? We have commitments we need to meet. You know the drill.

Finally a point in time came when the team was behind schedule and the customer became very upset. Turns out that the customers project management people had made commitments on the basis of the discounted estimate.

The error here is that everyone worked in terms of hours = $$ . Instead of hours = work effort. The amount of work needing to be done did not change at all. Its not as though the deliverables had been reduced. And just because the dev team gave a discount expressed in hours on an estimate, that did not change the overall effort needed to produce the work.

The big learning lesson for me is to carefully look at the way in which estimates are expressed. A better solution is quoting the total price based on a normal effort and then apply a discount percentage to the bottom line. That approach could have saved these fellow programmers a lot of heartache.

Of course there was also the matter of having dependencies on legacy code that was not documented and nobody understood but that’s a different post for another day.