Avoiding Pain in Software Estimation: Part 3 – The Cone of Uncertainty

Early on in the life of a project, when it’s only an idea in someone’s head, there is very little information from which to base any meaningful estimate. No details regarding the requirements, no details about the technology selected to best meet those requirements, no architecture, no design, not much at all really to use in any kind of reasonable estimate. The project, at this early stage, contains a lot variability or uncertainty which contributes directly to variability in estimates.

Avoiding Pain in Software Estimation: Part 2 – The Devil’s in the Details

Some well intentioned project planners, in an attempt to provide the most accurate estimate possible, will begin by breaking down the project into small tasks no larger than about 3 days, dump all these tasks into a large project plan, assign resources, identify dependencies, resolve conflicts, and boil the entire project down to a specific completion date which is, let’s say, six months from now. This, in actuality, is a very risky approach to software estimation because it completely ignores the concept of visibility.  A project planner really has very little visibility into what the project is going to look like, the issues that are going to be faced, the roadblocks that will be encountered, the compromises that will be made two, four or six months out. The effort that goes into creating a project plan to this level of detail is, just frankly, wasted effort. Some would argue that putting so much detail into planning early on in the project is just a bureaucratic exercise and is worse than not planning at all.

Avoiding Pain in Software Estimation: Part 1 – Targets vs. Estimates

When developers are being asked to estimate a project timeline, they are usually being asked to commit to hitting a target which has already been determined. Sometimes, when presented with this scenario, developers will go through the exercise of figuring out how to meet the target rather than estimating.