The Six Rules of Return on Investment - from a programmer's perspective...

A Developers' Guide to ROI

By Robin Sharp
June 30, 2002

Introduction

ROI, or Return on Investment is a buzzword that litters vendors' websites like confetti. And yet like many concepts, ROI is little understood by your sales persons or managers, who probably wouldn't have a clue how to calculate it.

As developers we are told little about such things, which is paradoxical because it really requires developers to understand ROI to make it work. But what does ROI mean to you and me as developers, and how can we use it to empower our developments?

One of the (few) refreshing things to come out of eXtreme Programming is a return to the acceptance that the software development process is fundamentally one of development, and not management. By that I mean it is fundamentally a process of creativity and construction rather than a process of control and arrangement.

The movement by the methodologists to diminish the power of the hero programmer in favour of top-heavy management power structures has been proven to be flawed. Such structures are essentially geared towards monolithic organisations driven by politics and machinations, resulting in heavyweight software lifecycles that can drag relatively simple projects out over a number of years. Recently however, the dot-com revolution brought with it the introduction of Internet timescales. "Internet time" has shown that applications can be built rapidly and deployed globally in a matter of months.

Internet time is more about accounting than management. There has been a slide toward the idea that projects should be managed by strong technical and business management.

The upsurge of the developers' power brings with it a heavy responsibility to understand the business content and the business model behind any development. Developers should help to support management accountants by better understanding the business model behind their development efforts. This article addresses this issue by explaining key points that any developer should understand about the impact of ROI analysis.

Every company, small or large has a management accountant (even if they are the CEO). The success of your project can be measured by the willingness of the management accountant to increase your budget, because this means that you must be returning a better ROI.

The whole point is that we as developers can write truckloads of programs, yet only very few of them will be profitable. Just because they work it doesn't mean they are successful.

Understanding ROI will help you to develop programs that are financially more successful.

What is ROI?

ROI (Return on Investment) is defined as:

"A general concept referring to Earnings from the Investment of Capital, where the earnings are expressed as a proportion of the outlay."
Source: The Dictionary of Modern Economics, 4th Edition, The MIT Press, David W. Pearce

ROI = ( PROFITS / INVESTED CAPITAL ) * 100

The ROI for each project is compared with the invested capital on a yearly basis. ROI analysis means that where expected benefits and costs are realized within the same year of implementation of the project, the project is more likely to proceed.

Those projects having an ROI less than 100 % may not be undertaken.

A 300% ROI over five years indicates a return of 3 times the original investment over a five-year period. Break-even analysis is used to indicate how many months after investment that the investment is recouped (100%).

To understand the concept of ROI from a developer's perspective, it's best to look at the concepts of PROFITS and INVESTED CAPITAL and the YEAR over which they are invested.

The Six Rules of ROI

So how can you, as a senior software developer or team leader, use ROI to good effect in your project? To answer that, we've put together six handy rules:

RULE 1: Have a clear business model.

RULE 2: Prioritise functionality against ROI, not perceived priority by users.

RULE 3: Deliver the biggest revenue creating items within a 3 month period.

RULE 4: Design your software so that development is quick and scalable.

RULE 5: Build business softwalls that are architecture neutral.

RULE 6: Employ a mix of permanent and contract staff on a project.

>> RULE 1: Have a clear business model.

Talkback:

Post a new message

good points
Keith Ray keithray at mac dot com

Post a new message

<< Back to Lifecycle