Software product success.
Seth Godin has a post titled The Reason. In each of his examples, Seth asks and answers the reason why we do things that don’t have an obvious rationale.
Requirements elicitation is about asking why. When we ask why correctly, we get great insight, which enables great requirements, which can yield great software. When we ask why incorrectly, we can get a great big mess.
Prioritizing software requirements
Jason at 37 signals recently posted about essential vs non-essential requirements – the software equivalent of Am I hot or not? He talks about the prioritization decisions their team went through as part of bringing Campfire to it’s launch. Campfire is an online collaboration application that just launched today. We will talk about how their prioritization
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.
Understanding the expected value of a possible future event allows us to make mathematically sound decisions. We can decide if we want to make an investment. We can assign a reasonable price for our services. We can prioritize requirements. Expected value is a calculation that should be used when calculating ROI.