One common activity in enterprises that are trying to implement a new software application internally or upgrade an existing one is to try and do some kind of ROI analysis to validate the effort. (Here, I am primarily talking about products required for the company to conduct their business). The argument typically goes like this: The application will make us faster, cheaper, allow us to produce better quality widgets etc.
However, most often, the data and analysis behind this assertion varies from a very high level guesstimate, to pure opinion. In order to do this ROI analysis well, in my opinion, you have to start with a very simple question, yet one which could be fraught with political disasters.
What is it exactly that will make the company faster, better etc? In other words, what has changed to make the enterprise more efficient?
In most cases, one would hope that the efficiencies come from changes to the underlying business processes. However, the challenge lies in capturing the business processes and efficiencies at that level across the company, and determining the ROI. For e.g. If a sales manager is spending 5 hours entering data into a home grown CRM system, and if upgrading this system or replacing it will allow her to reduce this time to 3 hours, there is a efficiency gain of 2 hours. So what? Can we take these 2 hours and translate it to revenue gains? Can the sales manager sell more with the 2 hours she has gained? If not, what do we do with those 2 hours? Cost savings? How much and where are these savings?
Which brings me to the next issue. How do we communicate the expected changes to the affected stakeholders? Many projects fail because employees fail to adopt the new application - and a big reason for this is, they don't buy into th expected benefits. A process level analysis, showing the activities and time spent pre-implementation and post-implementation will go a long way in eliminating these issues.
Unfortunately, there are few projects that actually spend time doing this kind of analysis. The benefits are outsized in relation to the effort needed.
Which brings me to the next issue. How do we communicate the expected changes to the affected stakeholders? Many projects fail because employees fail to adopt the new application - and a big reason for this is, they don't buy into th expected benefits. A process level analysis, showing the activities and time spent pre-implementation and post-implementation will go a long way in eliminating these issues.
Unfortunately, there are few projects that actually spend time doing this kind of analysis. The benefits are outsized in relation to the effort needed.
What about the next best alternative and how the benefits relate to that? When you say benefits, are you talking about the differences?
ReplyDeleteWhen someone is looking at a product there is always a comparison going on... with the next best alternative. If the new solution address a pain point int he NBA, you got a winning solution. Just a different way of saying what you are saying.
Thanks SM. Thinking about the next best solution is always the right thing to do - the Net present value (NPV) of the proposed is essentially the typical output of the ROI analysis - which you calculate by looking at efficiency gains at the process level, and it should be greater than the NPV from the next best solution. The efficiency gains at the process level are really gains in spent on various activities - you become faster or slower etc. from before the solution was implemented..and to get to the NPV, you would make assumptions to allocate these time savings to revenue increasing activities and hence sell more, or to decreases in costs, all leading to one number at the end of it..
ReplyDelete