Estimates sound like a simple, beautiful, thing no project should ever be without. As always, if something is too good to be true, it is not true. Having a detailed estimate up-front for something highly uncertain is desirable, and impossible.
Estimates are hard to use properly, and very hard to get value from. There are people who understand probabilities, have a good grasp of variability and resulting deviations. These people are able to work with, and to benefit from, early estimates while considering all the uncertainty of the situation. These people also do not exist in IT project-planning roles.
Estimates are hard to use properly, and very hard to get value from. There are people who understand probabilities, have a good grasp of variability and resulting deviations. These people are able to work with, and to benefit from, early estimates while considering all the uncertainty of the situation. These people also do not exist in IT project-planning roles.
Estimates look like a wonderful thing to have, but they are hardly necessary. Not having a good estimate may be less than ideal, but never disastrous. Estimates do not change the flow of work to the better, although they could encourage cutting corners. Many projects have been successfully completed without any estimates, or with bad ones.
Overall, the most desirable estimates are impossible to get right, all estimates are easy to misuse, and even the best estimates provide limited value even if everything goes well. Estimates are normally discussed in terms of a best-case scenario, which is very different from what usually happens.
- Best case scenario
- On-point estimate. All necessary resources available when needed. No changes in requirements.
- On-time and on-budget delivery.
- What usually happens
- Best-case scenario estimate, further shortened because of business need. All necessary resources are not available until much later, except a few, that are not available at all. Massive and conflicting changes in requirements.
- Complete chaos when estimated delivery date arrives.
Estimates are a nice thing to have in a perfect world. Having good estimates allows to predict far ahead of time when and what resources will be needed, when and what milestones should be completed, and when to expect the final delivery. However, in a perfect world, resources are available quickly, milestones are hit reliably, and delivery has perfect timing - whether there were estimates or not.
Real world is far from perfect. In the real world, more often than not, estimates are way off, inputs are late, milestones keep changing, and final delivery turns out to be a first draft. The only piece that remains set in stone is the original estimate, while the rest of the situation changes dramatically. Rough guesses become deadlines, do-or-die commitments, and the cornerstone of blame-passing culture.
For those projects that attempt to succeed in the real, rather than perfect, world, consider doing away with the estimates-come-deadlines.
So looking at that picture of the rock, would you be interested in knowing the probability of reaching the top, doing what you had planned to do, returning to the base in time before the thunderstorms roll in with lightening every afternoon if you left the trailhead at 2:00 PM?
ReplyDeleteEstimates are never simple and estimates in SWDev are not for the developers, they're for those paying your salary to produce the value they paid for. What you describe is actually "bad management practices." If management is manipulating the estimates, they're likely promising other things they can't deliver on as well. As nothing to do with estimates and everything to do with the maturity of the organization and its viability to provide measurable value to its customers
Glen, I agree that estimates could potentially be used properly and be somewhat valuable. But as practice shows, they don't and they aren't. You can call it "bad management practices", but those are the management practices prevalent in the industry.
ReplyDelete