Whose ROI Is It?

I was trying to address the issue of ROI (Return on Investment) in the project portfolio book. I don’t buy project ROI. First, the idea of a project for software is an artifical construct–our consumers buy running tested features, that we happen to package in a project to release as a product. But the idea of ROI means you know how many consumers are going to buy/use the product, and you know how much you’ll charge for it. That means you need a crystal ball. Mine’s not working.

Instead of Producer-ROI, I’ve started thinking about Consumer-ROI. When someone consumes your product, what can they do with it? What kind of waste can they eliminate? What new abilities will they have?

If you think about one consumer at a time, and think about their capabilities and waste, you get a better idea of what the real ROI is. It’s possible to have examples of how the product would reduce waste or increase capabilities for a given consumer. Then you ask this question: which features help solve a particular problem or reduce waste for a specific kind of consumer?

I still don’t know how to predict Producer ROI (Project-based ROI), with any sort of assurance I’m telling the truth, but when I think about the users or potential users, I feel as if I’m more of the right track.

4 Replies to “Whose ROI Is It?”

  1. Ultimately, I think that producer and consumer ROI yield the same result, with producer ROI being the aggregate of all consumer ROIs. ROI is most useful as a project selection tool. Projects that produce products or services with higher “potential” ROI, often having to exceed a specified internal rate of return, called a hurdle rate, are more attractive to an organization than projects with lower ROI.

    Of course, these are future looking measures, and, as such, require forecasting tools and a fair amount of risk assumption. New products are introduced with the expectation that they will sell at a profit. As we know, this does not always happen.

    ROI may be readily more applicable for projects which yield products for internal use, e.g., a new accounting system that has an expectation of increasing internal efficiency and saving the organization an expected amount per transaction.

    ROI, like Payback Period and NPV, is a financial measure of future revenue and cost streams that are used to evaluate investment alternatives. They may be applied to a given project or to a portfolio of discrete projects. It has been my experience that the project team is only responsible for managing the development cost of this calculation. It is up to the internal customer or the sales and marketing people to achieve the revenue or cost savings part of the equation.

  2. I don’t know if this is also related to Consumer ROI, I’m still learning this things, however last time we were trying to define an MVP for our product we start looking at how much money can our customers make using our product and how can we make him earn more money. This way we were sure we will pick the most valuable features.

    It was a shift in the way we looked at the problem. Usually we were looking at ROI per feature. We decided just as an exercise to start looking at ROI per product for customer.

  3. Sounds close to the concept that I have used measuring earned value. ROI is a financial measure used to PROJECT (guess) whether or not the completed state (as defined in requirements) will deliver the value that caused management to fund the project.

    Earned value is closer to understanding how much of the projected value, has actually been delivered, or is scheduled to be delivered in the current release.

    Glen Alleman (Hearding Cats) has a number of posts about earned value, and is generally right on in comparing agile or iterative strategy for project management to other project management paradigms. check out his recent post

    http://herdingcats.typepad.com/my_weblog/2008/08/a-new-agile-pm.html

Leave a Reply