Estimates are not deadlines

This is another one of those cautionary tales of what not to do.

A number of years ago I worked for a digital agency. For most of my time there I worked on systems in a specific market sector and I got to know it quite well. Then a brief came in from a new client in that sector who wanted a new website. It seemed natural that I was asked to work on that project.

It was also natural that we should work out if the brief was doable within the budget that the client had, so we got to work analysing the requirements and estimating how long it would take. This was then translated into billable hours and compared against the client’s budget.

The estimate showed that the work could not be completed within the client’s budget.

At some point shortly after that word from on high was that we needed to make it work within budget, and the development manager then asked us where we could make savings. He went through with us all the estimates attempting to find out if we’d padded them out.

Although we managed to cut the estimates down a little they were still too high. We needed more cuts. We needed to cut 22.8% from the estimates.

At the time, we were using the project to trial a new project management tool called VersionOne so all the tasks and estimates were in that system. Some things were estimated at an hour, some two hours, some four hours, some a day. All rounded numbers. All based on a gut feel in the very early stages of a project when we still didn’t know half the information we really needed, which is to say these estimated weren’t even educated guesses, some numbers were picked from the air, some were based on experience in other projects which were similar but not the same.

The estimate we came up with for the project was our best guess with the information we had.

Then a day or two after the exercise to pare back the initial estimates I came in to discover that all the estimates, every single last one of them, had been revised downwards. I may not have immediately noticed if it wasn’t for the fact that they no longer had nice rounded numbers.

For example, all the tasks that was estimated originally for 2 hours were now estimated as 1 hour, 37 minutes, and 42 seconds. Gosh! That’s an awfully precise estimate. I can hardly call it an accurate estimate.

The Development Manager, in order to meet the board’s approval, had cut precisely the amount needed to meet the budget on every single task. The project now came in almost exactly on budget.

When the work actually started it was clear that the estimates were wildly out in some cases. Not just the overly precise revised estimated, but the original estimates too.

The company culture being what it was, stress was applied to ensure that work was proceeding on scheudle. Developers were held to the estimates, even although they weren’t the original estimates, and estimates are just guesses based on the information available at the time.

There are a number of solutions to this, however, the company was not receptive to those ideas. Their model was the client says jump, they respond how high. Then they whip their staff until the desired height is reached.