Learning curves have been studied for decades when evaluating manufacturing systems and proposing cost reductions. The Boston Consulting Group did an oft-cited analysis in the 1960’s that describes how people get faster at tasks through repetition. Peter Abilla looked at the extension of this to writing software. We look at how it applies to using software.
Agile Development and Software Maintenance Costs
Over 90% of the cost of software development is software maintenance (cite). This alarming trend was predicted as early as 1972. McKinsey suggests that CIOs should spend no more than 40-60% on maintenance. Gartner’s IT Spending and Demand Survey (2002) reports that CIOs are spending 80% of their budgets on maintenance (p12 of presentation). Agile development can help reverse this trend.
Product Life Cycle and the ROI of Agile Development
The product life cycle is a description of the presence or behavior of a product in the marketplace over time. The framework for description is a function of the sales volume of the product versus time. Over time, products are created and introduced, and sales grow, peak and decline. The product life cycle uses phases to describe these different periods in the life of a product. Understanding the product life cycle is also key to calculating the ROI of agile development.
5 Return On Investment Calculation Tips
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 and Utility
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?
How To Measure Costs When Calculating ROI
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.
Gathering Implicit Requirements
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?
Don’t Prevent My Success
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.
Goal Driven Upgrades
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.