Implementing Iterative ROI

Capturing return on investment on new software has never been more important than right now — and never has it been harder to identify.

In the old days you could identify weak spots in your business and purchase software systems designed to eliminate or at least to significantly reduce those liabilities.

Performing an ROI analysis usually consisted of two parts: a before study to determine the business’ steady state; and a post implementation analysis to determine improvement.

Good as that sounds, such studies left out a lot.

For instance, can we be sure that the results from post implementation truly reflect the future steady state? Also, if the new system provides financial gains simply by reducing headcount, can we really say that the system improved business processing?

These are important questions, especially in the front office or in moving operations to the cloud, because the proof of new systems should be in enhanced business processing, better customer relationships, faster deal making and such.

Calculating ROI Nowadays

In the era of Covid we should also add the nebulous but real concern about keeping a suddenly remote workforce on the same page. So increasingly, it looks like the traditional approach to ROI might be failing us big time. But what to do about it?

Moving operations to the cloud no doubt presents its own challenges but it’s also a microcosm. For instance, many, if not most, organizations already have things like ERP, SCM, CRM and HCM, so the traditional ROI on reducing departmental headcount is mostly already taken.

However, moving to the cloud can still provide certain migration efficiencies and the ROI that goes with them — like one monthly subscription fee instead of big investments in hardware, software, energy, and some of the people who run the systems.

Even so, none of this touches on a couple of the greatest ROI concerns of our time, namely: Are my new systems helping me do more and better business; and are they improving my employees’ work experiences, or are my people fighting the system by day and polishing their resumes by night?

You can’t get this kind of ROI from a study of use soon after implementation; in fact, you need to be tracking answers to these questions all the time.

Look, new people come into the organization, need training, make rookie mistakes, and some become super users. But how do you know who’s who, what’s working, and what isn’t?

Iterative Development

I took a briefing recently from Knoa Software, a company that has a great deal of experience in answering these and other questions, primarily on SAP systems but now also for Oracle Cloud.

Knoa hired me to provide an analysis and to advise them; and that work appears elsewhere. I’m writing about them here because I think they’ve developed a concept that they have not presented to me but that I am calling iterative ROI.

We know what iterations are. Early in my career I sold 4GL products that enabled developers to build systems iteratively; meaning they could quickly build a working system and then modify it based on user feedback.

It was a great advance on traditional 3GL programming that could take months or more and produce something totally wrong. They don’t call it iterative development any longer but most software platforms that incorporate code generation are enabling precisely that.

So, Iterative ROI: How Do You Get It?

Very simply, rather than conducting manual surveys of users, Knoa captures metadata from actual use of a product. You can tell a lot about how effective training is for a newbie by how often that person calls the internal support desk. You can also understand who’s having trouble by how many screens they visit or how long it takes to perform a task.

Obviously, other metrics like revenue per interaction can also be useful as can daily output of software developers. All of this user metadata becomes grist for the analytics mill.

Analytics run against all that metadata will give you an accurate understanding of your current position and most importantly, how to do better. For example, who needs training? There’s no need to wonder or to put a whole group into a day-long session if just a few individuals need help.

That’s what Knoa does — and that’s why I am calling it iterative ROI.

Most importantly, you can and should care as much about ROI three years down the road as you do when you turn on a new system. It wasn’t always affordable to do the studies that provide that information, but now such information can be automatic.

As for the transition to the cloud, migration projects are big and expensive and there are loads of opportunities for things to slip through the proverbial cracks. But an iterative ROI approach based on recurring data gathering and analysis will prevent the unpleasant surprise you get when you realize that the new systems work as advertised but your people hate them.

My Two Bits

It’s no surprise that traditional ROI has come under the microscope; it’s only surprising that it has taken this long. Social media has been analyzing user metadata for many years with interesting results.

In the hands of a business with interests limited to what works for the organization, analyzing user metadata can be an important addition to the management arsenal, and managers need all the help they can get because the task is only growing.