The Six Rules of Return on Investment - from a programmer's perspective...
A Developers' Guide to ROI
By June 30, 2002
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?
"How can you as a programmer use ROI in your project?"
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.
"Politics-driven organisations drag projects out for years..."
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.
<< Back to Lifecycle