How Development Time Impacts ROI

“The expected ROI is 60% higher if we defer the most risky features until the core features are done.”

Is this the kind of confident and informed statement you would like to be able to make when asked about the feature development strategy for your software project?

Unfortunately, a more typical statement is something like, “The risky features might take longer than we think; but we're not really sure what impact this might have for the business – that is your area.”

Step back and consider the power of the first statement, and compare it with the extremely weak and almost useless content of the second statement. If you were a business decision maker, would you want to waste your time with people who “inform” you with statements similar to the second one? You might as well outsource the project and at least bind someone contractually.

If you like to be able to make statements like the former, and have them be credible and tangible enough to discuss and critique, you need to develop an analytical model of the sources of value, cost, and risk pertaining to your project.

Mitigating Risk In the Design

Most software developers endeavor to mitigate risk by incorporating design features that decouple risky features from critical elements. That way, the risky features can be developed somewhat independently. This is not always possible, however, especially if the risky features represent an aspect of behavior that permeates all levels of a system. For example, security strategies often have this quality. Thus, if one chooses to “add security later” one might have to rewrite large portions of a system, introducing substantial technical risk. Even so, deferring such features might be wise if the overall probability of success of the project is enhanced because the software development risks are postponed until after the core features have stabilized and customers have had a chance to use and learn to like the product.

Emphasize “might”: one answer does not work for all situations. That is why it is necessary to have an understanding of how the various sources of value, risk, and cost all interplay. An analytical model is a powerful tool for this purpose.

Modeling Risky Features

Decision makers need to know what the tradeoffs are: Is it better to tackle hard problems up front, or to postpone them? The answer is different in different situations: it depends on the relative size of the tradeoffs. Thus, it is necessary to identify what the tradeoffs are and estimate their relative magnitudes.

Simple estimates might even not be enough. In many cases, there are complex scenarios involving unknowns, such that if certain outcomes occur the tradeoffs change. For example, if a major security incident occurs while a customer is using the software then the customer's interest in the security features might grow rapidly. Simply saying that this could happen is not sufficient because it might be extremely unlikely: one must estimate the chances of this occurrence in order to evaluate the importance of addressing security now, given that time to market risks are reduced by postponing it.

Most developers use gut feeling to make these recommendations, but that leads to statements such as the one above that goes “...and we're not really sure....” It is much more persuasive to have thoughtful analysis behind a recommendation.

This whitepaper provides an example of how to develop such a model. The example focuses on how to model the tradeoffs pertaining to the postponement of high-risk features.

Slashdot It! Digg It!