Demystifying software estimation

22.05.2006
"Go with your gut, then multiply by three." So goes the conventional wisdom about estimating the cost of software development, a critical business task that very few companies do well, according to Steve McConnell, author of Software Estimation: Demystifying the Black Art (Microsoft Press, 2006).

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.