There is a good short article by Virginia Franke Kleist in the September/October 2012 edition of IEE IT Pro magazine called "The Elusive Technology ROI". It covers the ground on traditional approaches to ROI and the pitfalls. As I was reading the article, I started thinking about the additional challenges of building ROI models for Agile projects. In traditional waterfall projects, the basic assumption is that the requirements can be defined up front to a large extent. Included in this assumption is the concept of a business problem or opportunity that the software will more or less wholly address. To build the ROI, we estimate cash flows associated with the business problem or opportunity solution. With Agile, we dispense with the traditional assumption that we can solve the business problem or opportunity wholly by defining requirements up front. Instead, we take a piecemeal approach to tackling the next most important aspects of the business problem or opportunity that we can bite off in realatively small chunks. In doing so, we expect our customers understanding of the problem or opportunity to change and their ideas for the solution to change. We expect to reprioritize our effort. How then can we make reasonable estimates of cash flows for a reasonable ROI calculation up front? If we cant get a reasonable ROI calculation up front, how can we justify starting the project? In thinking about this, I have two observations to get you started:
- On the benefits side of the ROI, the "what" of the size of the business problem or opportunity should not be influenced by the "how" of the methodology used to build the solution other than in that an Agile approach might be expected to produce more unforeseen, "emergent" benefits that traditional waterfall.
- On the costs side of the ROI, the "how" can be very influential and the less predictable (at face value, assuming good requirements for the waterfall) nature of Agile could imply that costs might be more than expected for Agile. However, it shoudld also be true that the risk of building useless "white elephants" in Agile is much smaller because projects that will struggle to solve the business problem or opportunity can be identified and re
Mike Harris DCG President