Reader QuestionBy Regina Kwon | Posted 2002-03-01 Email Print
WEBINAR: On-demand webcast
Next-Generation Applications Require the Power and Performance of Next-Generation Workstations REGISTER >
Cost overruns. Delays. Infighting. Most problems in the development lifecycle can be traced back to scope creepincluding project failure.From the April 24, 2003, Baseline Tools newsletter:
James Schiel, the manager of Siemens Medical Solutions' Integration Engineering R&D department, wrote in after browsing our scope-creep article: "Your article demonstrates the not-so-obvious costs of adding features to a development project. I'm uneasy about combining the cost of 'risk' with the cost of developing a feature.
"You've defined 'feature risk' in this instance as the increased risk of project cancellation and have added that additional risk to the cost of the feature. Granted, this is a small matter (and your article said that too), but isn't the cost of doing something and the risk of not doing it mutually exclusive? While I could easily understand the increased cost of risk mitigation that results from the new feature being added to the project, I'm finding myself unable to argue for attributing an incremental cancellation risk to the feature."
We turned to Doug Hubbard of Hubbard Decision Research (www.hubbardresearch.com), who helped us write the original article. Mr. Hubbard invented AIE, a method of calculating I.T. costs and benefits using economic and actuarial principles.
"Yes, the costs of doing something and the risk of not doing it are, by definition, mutually exclusive. But we are not really asking the question about the "risk of not doing it"--which is, by definition, a benefit of doing it. What we are computing is the total cost of doing it, which includes several categories of costs. One of those costs is the slightly increased risk of project cancellation. This is already a very small risk, and the risk of canceling the feature itself (which, since cancellation is partly a function of size and duration, is much smaller than the risk of cancellation of the entire project) is even smaller than that.
What we are really saying is that the total benefit of adding a new feature (which includes, among many other things, the risk of not doing it) should be compared with a more complete accounting of costs, not just near-term development costs, as is usually the case.
And the fact is, historical data clearly shows that there IS an incremental increase in the risk of cancellation when new features increase the size and duration of a project. Take an analogy: I suppose it's hard to argue that a given straw actually broke the camel's back all by itself. Well, of course it really didn't. Instead, each straw added an (admittedly very small) increase to the chance that the camel's back would break.
But that's why our additional risk of cancellation is a small number, too. The part here that confuses people is that they see this breaking point as a single threshold that is either exceeded or not. That is partly true. But we also have to remember that we have uncertainty about how many straws will be added in the future, so each straw added now increases the odds that the threshold will be exceeded at some point in the future. And in the case of software development, we also have uncertainty about the threshold itself.
However, since the risk of cancellation cost is pretty small, you could even leave it out and still see that including only near-term development costs of a new feature is a gross underestimate. And that's the point of the article: The increased chance of cancellation is nothing more than the smallest factor that still shows up after rounding to the nearest percentage point. There are many other factors smaller than that.
Thanks for your interest in the article."