ROI of Application Development

Just read an interesting piece from Sunjay Pandey arguing that ROI measurement for application development is too soft.

This is of interest to me on two counts.  As the head of a software vendor, I have to argue for and demonstrate ROI to my customers.  Conversely, as the head of a software vendor, my technical team needs to demonstrate ROI to me for any new developments in our product.

In both scenarios I have been guilty of not paying sufficient attention to the importance of ROI.  Whilst I don’t claim I have learnt every lesson, I would like to propose one addition to the list of 5 ingredients suggested by Sunjay for successfully evaluating and subsequently delivering the best ROI.

6.  Break the project down into bite sized chunks and avoid big bang implementations at all cost.

By doing so, the business and IT can evaluate the ROI for each component/feature of the project and each one should stand up to its own business case or not get done!

To many, this may sound so blindingly obvious as to not be worth stating.  However, I challenge you to consider the projects you have been involved with over your career and ask yourself this:

Did a project I worked on ever deliver something that was not essential to the overall business case?

I’ve just challenged myself to answer this question and I can’t think of a single project where some “nice to have” was not included, that had no business case of its own.

It is too easy to look at the overall business case, evaluate this as massive, then start include people’s pet features because the business case has “room”.

This weakens the ROI of the overall project, and results in the delivery of features that are not needed.  Furthermore, it can cause a costly diversion, not only in the execution of the project itself, but also in the business processes that result.

4 Responses to “ROI of Application Development”

  1. Sunjay Says:

    Excellent 6th ingredient! That’s something we’ve learned the hard way so many times that we forget to mention it, but it definitely bares repeating and focus.

  2. Ciaran Says:

    Just a thought – do nice-to-haves give an overall feel of quality or professionalism to an application or solution that can’t be so easily quantified?

  3. Alastair Bathgate Says:

    It’s a fair point.
    My view is that a professionally designed and coded application is not a “nice to have” it is an essential. Within any application there needs to be some bells and whistles to give a good user experience. Major chunks of functionality, however, should be checked against ROI measured in financial terms (increased income, improved margin, reduced cost etc).
    What represents a major chunk? That’s probably a grey area that could command a post in its own right.

  4. Ed French Says:


    Great points.
    I’ve sometimes thought that the ROI should be risk-adjusted. Big risky projects should have to meet a different ROI barrier to small and low-risk projects. Some of those extra “nice to have” features can have an impact on the risk that the project doesn’t provide the planned benefits.


Leave a Reply