software project business case

Good ROI doesn’t mean project success

I work near some really switched on project finance team members who know their stuff.  In the last couple of days we’ve been having a great on-going discussion about ROI (Return On Investment). Of course it has gone hand in hand with discussions around benefits realisation, but that content is for another blog post. What we’ve decided is that good ROI doesn’t mean project success.

We were discussing how we have all commonly seen business cases where it has been pretty obvious that the financials have been ‘fudged’ to say the least.  You know, fictitious figures put in so that the business case stacks up.  Things that when you look at them, and think about them don’t really seem feasible.  Like those savings from licence fees for a redundant application that you’re closing down, without the full costs of the new software licences being taken into account.

This of course led to the discussion on why having a good ROI didn’t mean that your project was going to be successful.  So here are my thoughts.


Not managing your project

Your ROI is an on paper figure and what needs to happen in order to deliver your project in order for the benefits and savings to start happening is YOU need to manage your project.  If that isn’t happening in order to deliver what you said you were going to deliver in your business case, within the agreed budget that was set, then there is no way that your project is going to be considered successful.

In other words you’ve gone outside the scope that was or should have been clearly defined in your business case.

You don’t have the team necessary to perform the work or the team you have aren’t performing, they are doing other things.


Wrong Assumptions

If as part of calculating that ROI you have made assumptions that either weren’t called out or written down so that they could be validated or were clearly wrong, then again this is going to impact on your ability to deliver the project successfully.  You might have assumed that something could be completed within a certain number of days, and it isn’t.  Or, you might have calculated a saving only to find that it is not possible for what you assumed to occur, which means that saving is no longer valid at all, and what might actually occur is more expense, which would completely change your ROI calculation.


Missing pieces

You didn’t develop business requirements as part of your work in developing your business case, and there are now more items that need to be considered or factored into your delivery.  Back to my scope item noted earlier.  This of course leads to all sorts of impacts on resourcing, delivery against timeline which ultimately all has a financial impact and a strong impact on your ability to deliver.


Be careful then in calculating your ROI.  Make sure that it is real.  By that I mean that you have documented your assumptions in making your financial calculations and had them validated.  You have ensured that you have a clearly defined scope and that it is locked down, and this includes fully understanding the business requirements in a way as to understand what it is that you are expected to deliver.  Make the savings that you include realistic.  Don’t put high figures in, in order to make your project stack up for approval.  It is not worth it in the long run.



Written by Karen Munro

*Photo courtesy of dream designs at