Towards sanity in software project estimation: a chat with Steve McConnell

1 2 3 4 5 Page 3
Page 3 of 5

cio.com: Given the 25% or so of projects that don't complete at all—what percentage do you think would be healthy? That is, I assume it isn't zero.

McConnell: 25% isn't necessarily a bad number. What's bad about it is that the average project is something like 100% late and 100% over budget at the time it's shut down. With better development approaches, a lot of those projects would get shut down when they've used 20% of their budgets rather than 200% of their budgets.

We as an industry need to do a much better job of evaluating projects' viability earlier rather than later. It's staggering when you think that roughly a quarter of the development dollars in the U.S. are wasted on projects that ultimately fail. If an organization could reduce that number to something like 5%, it would free up a tremendous amount of resources that could be refocused on projects that will ultimately succeed.

cio.com: Where do you see the poor viability decisions are made? Or, more to the point, by whom? The users, who say "this is what I want"? The developers who write the code? The managers, at whatever level? What do you see as the most common missing link?

McConnell: The viability decision needs to be a combination of a business case analysis and a technical feasibility analysis. The most common reasons that projects fail are not very technical. It's mostly due to a mismatch between the business case and the project's schedule and budget requirements. I've found that most projects are commissioned with what I think of as "no-brainer business cases."

In other words, "If we could get this amazing amount of functionality for this small price in this short timeframe, we would have a great business case." The technical leadership receives that business case and is usually asked to come up with an estimate for the project. Typically, the initial project estimate is at least a factor of two higher than the business case that was used to justify the project.

That isn't bad information, if it's interpreted correctly. The business could decide at that point (very early in the project) that there isn't a business case for a project that will cost twice as much as originally expected. But what usually happens is that a dialog ensues, there's little or no adjustment made to the business case, and the business pretends that it can do the project for much less than it can.

Related:
1 2 3 4 5 Page 3
Page 3 of 5
Discover what your peers are reading. Sign up for our FREE email newsletters today!