Fog Creek Software
Discussion Board




Return on Investment of Application Development

Hello,

I want to know what methodology your company use for calculating return on investment of application development project, more specifically business application - not shrinkwrap or commercial application.

I'll do research using google, but if you have any good advice or can point me to resource/site to download good ROI calculation tools please inform/e-mail me.

baruno
Friday, August 23, 2002

I'm not particularly a fan of selecting a generic ROI tool for software projects.

Each project I have has cleared established business objectives - normally both quantitative and qualitative. These are different for each project and therefore require different measurment methods accordingly.

The focus is on only having a few key objectives which determine project success or otherwise.

An anal focus on ROI can often be detrimental to IT projects - considering many IT projects deliver a lot of long term benefits which cannot be quantitatively measured.

Ian Renfree
Friday, August 23, 2002


I do a lot of one-off coding to automate data processing.

It usually works like this:

# of hours it would take to process it by hand * $ hourly salary = X

# of hours it takes me to code, test & run * my Salary = Y

If (X > Y) { We have a winner; }
else { We don't }

Of course, even this equation is unrealistic, because I could be off doing something _more_ profitable.  But that's about as far as we take it.  If X > Y, it's worth doing, and we talk about scheduling.

Just my $0.02 ...

Matt H.
Friday, August 23, 2002

I applaud your focus on the analysis phase of a project.  Too many projects overlook crucial analysis deliverables such as ROI and cost/benefit.  In a nutshell, "Why are we doing this?" 

On one project, I was reprimanded by my fast-talking, well-dressed Dilbert manager for taking too much time in examing the guts of the system we were replacing.  (Why it was being replaced is still a mystery to me, as we also skipped that analysis step)  Note:  there was no documentation of the existing system, and there was no formal design on the new version either.  I'm still not sure how looking at screen shots, and printing a few reports was supposed to be enough for us to code by.  IF anything, I felt I should be applauded for bothering to do what no one else wanted to bother with.  But alas, a poor manager can never recognize a good resource.

The group wanted to just "start coding" when it was clear we didn't know what exactly they were to code.  (Details, details, I suppose.)  Needless to say, (for many other reasons as well) the system was late, required many re-releases, and didn't provide as much functionality as the original version.  (An absolute abomination, in my book)

In the end, it did meet the needs of the developers and manager, who wanted to be involved sexy new languages and buzzwords.  As a saving grace, I believe that entire group has been disbanded, and the Dilbert manager is long canned.    Irresponsible binging and spending of money for projects designed to simply amuse the brainy IT staff, and enable managers to get their claws into as many systems as possible (aka: job security) Firms have been taken to the cleaners, and the party is over.  That is just one example of why the IT sector has self-destructed. 

Bella
Friday, August 23, 2002

I can't believe, it by I actually agree with bella 100%

Daniel Shchyokin
Friday, August 23, 2002

I had most help of FranklinCovey's training "Helping Clients Succeed": http://www.franklincovey.com/letsgetreal/

nobody you know
Friday, August 23, 2002

Tell us more about your life, Bella. It's so interesting.

Alberto
Friday, August 23, 2002

>It usually works like this:

># of hours it would take to process it by hand * $ hourly >salary = X

># of hours it takes me to code, test & run * my Salary = Y

>If (X > Y) { We have a winner; }
>else { We don't }"

One BIG thing that is left out of here is cost to maintain Y, i.e. even if it is but into some kind of job queue and sent to operations there is still some cost associated with running, administrating and supporting it.

Also, this assumes documentation is so clear that OPs/Admins have no trouble understanding it, that Y is bug free, and that there are no changes to the process Y automates

Daniel Shchyokin
Saturday, August 24, 2002

Does any one review projects to see what the actual ROI is?

John McQuilling
Sunday, August 25, 2002

baruno,

I don't think that ROI should be the only criteria to greenlight a project.  I'm not against ROI calculations - they're a good objective measure, but sometimes getting the data needed to calculate the ROI can be a large project in of itself.  This labor is pure waste if everyone agrees that the project makes good business sense but is compelled to provide a number.

Look at the business.  What are it's goals?  How would the software help the organization achieve those goals? What the consequences of not developing the software? Write these things down to tell a simple "story". 

If the story makes sense, go forward with it.  Sell the story to the decision makers who would need to sign off on the project.  Do this whether an ROI number is required or not.  If management understands and agrees with the logic of the story, they're much more likely to buy off on the project - even if the ROI figures are based on wild-ass-guesses.

Nick Hebb
Monday, August 26, 2002

*  Recent Topics

*  Fog Creek Home