Skip to content

The realities of ‘ROI’ for developers

Once, the CEO told the software team I was in working on in regards to a proposed feature … “Basically the feature’s ROI has to beat the cash rate. If I can get a better return by leaving this million dollars on deposit at the bank then I owe it to my shareholders to do that instead.” … ouch! … The realities of business and ‘Return On Investment’. Just like a managed investment fund has “beat the index” as developers the ROI on our features have to “beat the cash rate”.

On the other hand I have also worked with lower-level product owners who simply could not quantify the ROI for any particular feature. When they asked for (effectively inessential) features which doubled the size of the effort required they would have a meltdown (i.e. emotional pressure to get us to ‘magically’ reduce our estimates) rather than admitting that perhaps we could delivery 95% of the business value and nearly 100% of the projected project revenue  with only 50% of the effort.

We once proposed a software feature that would vastly increase the efficiency of a business’s payment handling, eliminating several costly manual steps. We thought we were doing good. But … Our Bad!!! Our Very Bad. The very inefficiency of the process meant that the business in question could hang onto the revenue – 90% of which was passed from consumer to ultimate supplier – for a much longer period. It added days if not weeks. This is very very good from the CFO’s point of view. Much more money earnt on interest earnings and inflating the cash-at-hand than cost-base savings that could be made making a process “efficient”. Leave it alone and don’t ask about it again was the general message!

In a similar view, many years ago I was a programmer at the technology arm of a futures broker; rather than making most of its money from brokerage or its own trading activities (or software technology), in fact the best and most consistent revenue came from the interest earnt on aggregating the client’s trading accounts (which had a minimum deposit level, and of course, did not pay interest to the client).

Sometimes you work for a business, and their business isn’t really what you think it is.

Share and Enjoy:
  • Digg
  • del.icio.us
  • Facebook
  • DZone
  • StumbleUpon
  • Technorati
  • TwitThis
  • LinkedIn

2 Comments

  1. Robert wrote:

    Scot, it’s very simple: propose the solution for eliminating the costly manual process, and mention how the new system would have the ability to just schedule the payment when desired… the business hangs onto the money as long as they want!

    Saturday, May 2, 2009 at 12:56 | Permalink
  2. Scot Mcphee wrote:

    Well, maybe it’s that simple, and maybe it isn’t. Because it certainly isn’t as simple as “mentioning” the new system’s payment schedule functionality. Also, perhaps the system is relying on ‘costly’ to be reflected not just in in the internal system, but the way this reflects to teh customer’s experience of the system. We’ve all come across things that are trivially easy to sign up to, but nigh near-on impossible to sign out of. Look at SMS texting services, for example. The crushing bureaucracy is a *feature* from the POV of the CFO.

    The point is, you need to be very sure what exactly the “ROI” is in all of these sorts of situations.

    Saturday, May 2, 2009 at 21:41 | Permalink