Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

Being Business Focused: ROI

‘Being Business Focused’ is going to explore various business concepts and how we can use them to explain the bottom line impact of our decisions.

At work I am usually challenged to show the business value of the various things that I want to do. Improve a system, use some new technology, etc. Though its frustrating (because of course my idea is a good idea 😉 ), it has made me think through what the actual return on the investment would be.

The first thing I had to do though was learn how do we calculate the return on my work? For that I had to crack open my dusty undergrad college textbooks (and wikipedia). The rate of return, or return on investment (ROI) can be calculated simply with the following equation. Rate of Return equals the Future Value of an Investment minus the Initial Value of an Investment divided by the Initial Value of the Investment or:

roi = (future_value-initial_value)/intial_value

So some obvious things are now apparent. If we can lower initial value (aka cost) or increase final value (aka benefit) we can increase roi. (The trick is to actually show the numbers). Armed with this knowledge you can start to look at your input to the software development process a bit differently. We can start to ask ourselves questions about where we are contributing our efforts and that is really the key thing that my business is asking me. Of course they would love me to be able to quantify, but at this point I am just happy to say “I think I am lowering initial cost and here’s why”.

So what would an example be of us choosing to impact ROI?

This example is extremely simple and merely serves as an example it purposefully excludes many other important factors to overall roi

As the developer you could use a for-fee tool, like MSSQL, and raise the initial value of the equation (less roi) or use a free database,like PostgreSQL, and lower the initial value (increased roi). Conversely, you could choose to implement high value features and raise the final value (increased roi) or implement low value features and lower final value (less roi).

So there we have the basic calculation of ROI and some ways we as software developers can choose to effect it. So the next time you have a decision to make you can take a step back and think about its impact on the ROI of your product. Is it going to improve the future value? or lower the initial cost?

Next up, how our ability to lower risk increase ROI even though it can usually mean an increase in initial value.

-d

About Dru Sellers

Sr. Software Engineer at Dovetail Software.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • wic

    Interesting. but how do you handle things like bug fixing and maintenance? Ie, stuff that only costs but does not increase future value.

  • Collin

    In thinking about ROI from a purely numerical standpoint–a prudent but somewhat unrelated question is: what ROI calculation has the best chance for success–initial value as a denominator has profound influence on the outcome. This may make the case for a persistently low upfront cost. This statement is simplistic, but it does have its applications.

  • http://relentlessdevelopment.wordpress.com Grant C

    Yeah, and to add to what Rhys said, don’t forget to include the cost of developer time when working out the initial value. If the free database in the example given took longer to develop against, the costs could well be higher and the ROI less with that solution.

    Of course, you’ve also got to avoid making you simple examples too complex! 😉

  • RhysC

    ROI on is software is always a tricky one (for many reasons). One that i feel seems to trip people up is the total cost of ownership. A company I worked with many year ago chose .Net over Java because the total cost of ownership was deemed to be less. The lack of reliable “help” (amoung other things) with java was deemed too expensive. Now i am not getting in to the arguement of whether it was the right descision or not, but it was nice to know that they took more the the price tag as the investment: developers time cost money too.
    Now proving the reurn is also an interesting one.. :)