Archive of ROI Articles

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.

Tarun Upadhyay wrote a fair criticism of our previous post on why incremental delivery is good on his blog today. It is great that he is extending the conversation, and he makes some valid points. We definitely missed a big benefit of incremental delivery, and will cover it in this post.

Sunk cost is an expression representing the unrecoverable amount of money that has already been placed into an ongoing investment or project. It is one of the simplest, yet most commonly misused financial measurements of a project. We’ll learn how to avoid the most common mistake in project (financial) management, and how to survive when our boss makes the mistake.

We’ve talked previously about using ROI to determine which projects to fund. This isn’t the only way to make those decisions, as Ski points out with the concept of flush. Payback period is the measure of how quickly an investment returns the invested amount, or the break-even point in the investment.

Why won’t my boss approve my project? I’ve done the math - it’s a good investment. Because it isn’t good enough. We learn the math and rationale behind these decisions in this article.

Developing great software requirements demands iteration

In our previous post of an example of the software development process, we showed a linear flow through the process, as depicted in several posts over a couple weeks. What we failed to show was any of the iteration cycles, as Deepak points out by asking a great question in the comments on that post. In this post, we will show a little more about how the process works by showing how iteration fits into the machinery of software development.

A real world example of converting from an MRD to a PRD. This is the process of translating from a market-requirements view of the product to a product-requirements view of the product.

We’ve talked repeatedly about using ROI to drive prioritization of requirements based upon value. ROI can be used as the basis for prioritization for all decision making.

If we fail to take risk into account, our calculations will certainly be wrong, and we may make a poor decision. When we talk about accounting for risk in this context, we mean that we are accounting for the unlikely, undesired, or unintentional outcomes. We use the term expected value to refer to the risk adjusted approximation of the outcome. In financial circles, this is also called discounting.

The most common mistake people make when calculating ROI is failing to take into account the expected value of the return or the expected value of the cost of a project.