Even though programming is all logic and a lot of numbers, the ROI metrics aren’t readily available. I’ve asked past clients for data, and its a pain for them to find numbers.they usually give me vague information.
So, not saying you’re wrong, I just have never seen this kind of specificity in development.
Good point, Roger! It really depends on the application. In no particular order, here are some ideas for addressing the difficulty you mentioned:
- Anchor ROI to FTE equivalent cost: Did a piece of software allow a client to reassign 2 full time employees (FTEs) to other work (hopefully more valuable work) or avoid having to hire 2 positions? Try to find out the fully loaded cost of those FTEs to the company and use that number to calculate the ROI.
- Baseline things before you begin: Perhaps there’s a way for your pre-project discovery process to obtain some baseline numbers that you revisit 6 months or more after the project has shipped to see what the delta is. In other words, you do the work of obtaining the data necessary to make a highly specific claim about ROI or some other benefit of your work.
- Anchor ROI to the cost of failure: Somewhere around 50 to 70% of IT projects fail. So in a very real sense, simply not failing to ship is a success and money well spent. Since you’ll have a pretty good sense of the amount of money your client is spending on you, that amount can form the basis for a claim of ROI, though the true cost of the project is actually higher.
- Anchor ROI to the cost of downtime: Like #3 above, but using the cost of downtime rather than complete failure. This is particularly useful for projects where you’re replacing a legacy app or system that your client knows will fail, but they don’t know when. You may not be able to do a fully accurate cost of downtime, but in many cases you can get a client to share yearly revenue or profit numbers, divide those by 365 or 260 (the number of weekdays in a year) and get a number that can form a rough yet specific number for a “lost day of productivity” or some other result of system downtime.
- Calculate ROI based on known quantities and sane estimates: What is a new customer worth to your client? What’s the range of improvement your software might deliver in terms of that new customer value? Those two numbers can give you at least a range of specific numbers to use in a ROI calculation.
I realize that there are some situations where these ideas won’t help. But hopefully they help you think of creative ways to get metrics that you can use in your marketing.
I’m not surprised to hear you telling me that clients have difficulty finding numbers. That strikes me as an opportunity for you to demonstrate your expertise and differentiate yourself. Sure, you can provide a good software solution, but if you can also help your client demonstrate the ROI of that solution to stakeholders and upper management, that’s even better. So it might be worth looking at your client engagement process to see if you could broaden things enough to do the kind of baselining I mention in #2 above.
Finally, I know that the advice to be specific about numbers also implies that those numbers should be demonstrably accurate. That’s probably also part of the problem here. It feels strange to cite a highly specific number of dubious accuracy. So let your own conscious be your guide here, or frame those specific numbers in a context in which complete accuracy is not implied.
If you’d like to deliver better ROI to your clients, you should develop specialized expertise. This book will help: http://thepositioningmanual.com
Thanks for the question, Roger!