But it doesn't have to be that way. Generating accurate software estimates is a straightforward exercise, once you understand what goes into creating them, says McConnell, who is lead software engineer at Construx Software Builders Inc., a software development, training and consulting company in Bellevue, Wash. He spoke with Computerworld's Julia King about some common software-estimation mistakes and how to generate estimates based in reality.
In your book you talk about estimates and targets. What's the difference between the two? An estimate is an analytical assessment of how much a project will cost or how long it will take to be delivered. A target is an expression of a desirable outcome: "Ready in time for a trade show or the holiday sales season." A target doesn't have to be grounded in what's possible. It can be wishful thinking.
But a target -- rather than, say, a cost cap -- is often what upper management sets as the project goal. Then, later, there's a lot of grumbling about high costs. How can IT head this off from the outset? The way to find out what management really values is to ask them. Ask them whether they want to take on more risk to meet a target or to reduce risk but possibly not meet a target. When upper management gets asked that kind of question by technical staff, they really eat it up. They're so happy to have the technical side expressing interest in the business as a business. Almost always, management will say they value predictability. If management has to choose between high costs with high predictability and lower costs with higher unpredictability, they want the predictability.
What's the best way to build that predictability into cost estimates? Using organizational data to build estimates can be pretty accurate, because it takes into account factors such as other [workplace] distractions [that reduce the amount of time a developer devotes to the project at hand] and how good the organization is at developing stable project requirements.
But the better way is to use project-specific data that includes data about individuals who worked together on projects before. When you deal with project data, you know the productivity characteristics of the people on a project, so it tends to be more accurate.
You recommend collecting historical data about productivity as a project is under way. Why? And is that realistic, since so many projects are already under very high pressure? The goal of collecting historical data is to build a model that you can use for [future] estimation. How soon you can begin collecting this data is a function of how a project is being managed. If you're using an iterative approach and delivering software in chunks, you can begin to get data as early as 5 percent to 7 percent of the way into a project. If you're taking more of a sequential, waterfall approach to a project, it's more difficult to get to that data early on.
What's the most common mistake you see in estimation? Many organizations shoot themselves in the foot by committing to a project estimate too early -- before enough is known about the work being done to come up with the best estimate. You don't have to wait all that long to come up with an accurate estimate, but you can't get it on Day One either. By the time you're 30 percent of the way into a project, you'll have an accurate estimate. It needs to be recognized that you can't get an accurate estimate on Day One.
Sidebar
10 tips for accurate software estimates
1. Don't intentionally underestimate. The penalty for underestimation is worse than for overestimation.
2. Don't provide "percentage confident" estimates unless you have a quantitatively derived basis for doing so.
3. Don't reduce developer estimates; they're probably too optimistic already.
4. Invest effort in assessing the size of the software (lines of code) that will
be built. Size is the single most significant contributor to project effort and schedule.
5. Don't assume that effort scales up linearly as project size does. Effort scales up exponentially.
6. Use historical data as the basis for your productivity assumptions.
7. Use data from your current project to create highly accurate estimates for the remainder of the project.
8. For task-level estimates, have the people who will do the work create the estimates.
9. Compare actual performance with estimated performance to improve your individual estimates over time.
10. Don't shorten a schedule estimate without increasing the effort estimate.
-- From Software Estimation: Demystifying the Black Art