The IFM model tags financial benefits/returns to each major feature proposed for the software. At a fundamental level, it looks at software development as a value creation process which is how entrepreneurs tend to think about businesses at a macro level. An MMF, or minimal marketable feature, is the fundamental measure of software value employed by IFM.

MMFs are discrete units of value creation mapped to specific software features. They are the basic elements of an IFM development sequence. Net Present Value (NPV) is used as the measure as opposed to the usual suspect i.e. ROI. This model is not meant to be a substitute to established models such as Agile or iterative. In fact, the authors intended to strengthen such methodologies by introducing the financial aspect.

A quick description of NPV below (to jog your memory, just in case):

NPV: This is the net result of a multiyear investment expressed in today’s dollars. It recognizes that you would prefer to have $1.00 today to having $1.00 a year from now. If you earn 10% interest on your money, $1.00 today will be worth $1.10 a year from now. Or, the NPV of $1.10 one year hence is $1.00.

By considering the time value of money, it allows consideration of such things as cost of capital, interest rates and investment opportunity costs. It’s especially appropriate for long-term projects. But NPV doesn’t compare absolute levels of investment. It looks at cash flows, not at P&L – the way accounting systems do. Computing NPV requires use of a discount rate equal to some minimum desired rate of return. Determining that percentage may be the tricky part. In general, many IT projects use NPV only for large investments (eg:>$500k) as the process is complex and cumbersome.

ROI: Expected income divided by the amount originally invested

IFM is not new – it’s been around for about 4 years now. While IFM seems rational on paper, I wonder if it is feasible to do something like this in reality. There are several intangibles involved in an IT investment and those cannot be easily accounted for in such calculations. Long-term discipline in planning and execution is required for such initiatives. But at the very least, such calculations will trigger discussions within the product team and lead to evaluation and brainstorming of multiple ideas and options (apart from the heated arguments, fights etc).

At sunset (as against ‘at the end of the day’:) ), every decision-maker knows that data and numbers are attempts at rationalization of man’s intuitions and gut-feel decisions. That may be the single biggest reason why this model will never gain large scale adoption. What do you think?