How good are your estimates?
Well, it depends. If the project is slow-moving, the team is stable and has been at it for awhile, the platform is well-known and doesn't change much, and requirements are more along the lines of “get me some more of this”, rather than asking for something completely new and unknown – maybe the estimates are right on the money. For the rest of us, working in the real world and on real projects, with real people involved, estimates are mostly guesses, often – very bad guesses.
Yet there is all that great pressure to get the estimates right early on. The business side needs to know how much will be done when. The clients have to understand when the product will be available for use. Marketing is in dire need to make an announcement. It has to go into the contract. Salesperson already swore to it on building manager’s dog’s grave.
The estimate, which is often pure guesswork, rules the fate of the project, the development team, the customer’s hopes and the business success. Never mind that the guess has been made at the worst possible time, when hardly anything is known about the project and no patterns have yet been established. Rather than iterating on estimates, deadlines, project scopes, the tendency is to push for more overtime, less testing, more risk-taking – and more blame going around.
If the estimate is wrong, there is very little the project team can do to overcome an overly aggressive or too-far-out estimate. Adding or removing people, and making the team work more hours has been shown to waste resources and reduce quality, rather than increase the speed of development. Piling pressure to work “better and faster” helps even less.
The only reasonable solution is to iterate on the estimate, refining and re-setting expectations as the project goes forward and new information becomes available.
