Archive of ROI Articles

Return on investment calculation is critical to using ROI for prioritizing requirements. We’ve discussed how to forecast return on investment by estimating costs and predicting benefits. Here are five tips to help you when calculating return on investment.

The following ROI calculation tips are detailed in this article:

1. Recognize the Risks
2. Discount Future Cash Flows
3. Separate Sales From Expenses
4. Overcome Ozymandias Syndrome
5. Ignore Infinite Elvises

Read on for the details…

Prioritization with ROI is generally thought of as a quantitative analysis. For hard ROI, that is true. For soft ROI, it is anything but true. You have to make a prediction of the utility of the requirement or feature. That predicted utility is based on our expected utility, which is based on your past experiences. Your past experiences are reflected in remembered utility, which is a function of experienced utility. How can you know with certainty, and use that to prioritize requirements or features?

At a high level, it is easy to describe ROI - the return on the investment. But how do we measure the investment? There’s a problem when we have to go to the next level. Some costs are obviously incurred as part of our actions, and some costs happen even if we don’t take the action. We have to allocate those costs across all our actions or we won’t have an accurate reflection of our investment. Without an accurate model of our investment, we can’t calculate the return on our investment.

Johanna Rothman just wrote an article titled Implicit Requirements are Still Requirements. She points out that her expectations were not met, even though her needs might have been. Johanna also implicitly begs the question - how do we gather implicit requirement?

Finding the right balance when defining requirements can be hard. On one side, we want to avoid an inadequate system - “Don’t prevent my success by excluding features I might want”. On the other side, we want to avoid cost-overruns, delayed schedules, and negative-ROI features. This can be a hard line to walk.

Kathy Sierra writes (another) great article at Creating Passionate Users. This time, she talks about why users don’t upgrade and presents ways to get users to install the latest version. We focus in this article on one way in particular - using goal-driven documentation to encourage upgrading.

… Skyline Unharmed
Short-sighted demands on software teams usually don’t kill people. Software development is often described with a construction analogy. The Big Dig construction project was under exactly that kind of pressure. On July 10th, 12 tons of tunnel ceiling collapsed and killed a motorist. On July 20th, Mitt Romney ordered [...]

The next piece in the puzzle of how and why we apply use cases to product management. Verification of requirement correctness.

Gartner reported that companies spent $3.7 Billion USD on application development tools in 2004, with a 5% annual growth rate. The Standish Group has shown that 40% to 60% of project failures are due to requirements failures. At least 1/3 of the money spent on getting more efficient at coding is being wasted - it should be spent on writing the right software.

One of the ten big rules of writing a good MRD is writing attainable, or realistic requirements. These are requirements that can be practically implemented, by our team, according to our schedule. Practicality is a function of the skills of our team members, the costs that we face to implement a particular requirement, and the circumstances in which we are developing. Agile proponents use the phrases ‘people trump process’ and ‘politics trumps people.’ To write attainable requirements, we have to think about our people and our political situation.