« Why You Pay Too Much | Main | Just the Facts, Ma'am »

February 14, 2006

The Sources of Software ROI

Be careful what you ask for: you might get it!

That's what everyone needs to know about ROI.

ROI is a term that everyone intuitively understands but -- as often as not -- can misinterpret. The generic interpretation of ROI is nothing more nor less than a formula that describes how we expect value to come from spending. But that means being careful about what it is that we consider to be "value" as well as "expense".

One interesting task that carefulness suggests is to catalog how different kinds of expense match up to different kinds of value. This will show a set of many-to-many relationships. Consequently, what comes to the surface is that there are lots of different stories to tell about whether people are getting their money's worth or not.

In telling those stories, one factor to discuss up front is the difference between "cost and "expense". Expense is a budget issue that relies on approvals. Cost is a financing issue that relies on strategy. We don't want expenses to undermine the financing strategy, but too often an expense is the beginning of something that winds up costing a lot more than expected.

Meanwhile, what about "value"? We know from experience that what is valuable for one party may not be seen as such by another. This occurs because the nature of value lies in the importance that is attached to some distinction that has been made. Many parties can agree on what distinction was made, or in other words, what change took place; but unless those parties all have the same needs and circumstances, the importance of the change is likely to differ, in level and/or implications, from one party to the next.

So when it comes to ROI, what we really look at is how certain reasons for expenses would be associated with certain kinds of expectations about impacts.

For example, wIth software, the typical association is between the purchase justification of ownership and the predicted risk/benefit of its usage. That's a one-to-one relationship, but different parties experience different benefits. So it's as if the software is associated with any number of expectations, some more clearly or strongly than others. Likewise, an impact may have multiple sources.

In effect, there can be many different combinations of such reasons and expectations -- some apparently more preferable, logical or validated than others. Indeed, those are three attitudes that can help explain differing parties' often different perception of importance and therefore of value.

Normally, no one pursues combinations that don't have some positive attribute.

However, in cataloging already accepted reasons, expectations, and combinations that the organization either proves to have or claims to have:

- Sometimes the matchups are ones that just don't fit the policies of the organization. When it comes to the purchase and subsequent use of software, these stories tend to include issues with missing or disorganized support, and with potential theft.

- Some matchups don't seem likely to occur even if they are desired, due to organizational structure or processes that crowd them out. These stories point at issues like legacy implementations -- and legacy decisions, too -- that compete with change. And on the flip side, issues here include unproven new software, prematurely deployed.

- Some matchups are more under the control of users than providers, or vice versa, and there may be a question as to whose administration is better and/or whether the real control is actually the way it is generally believed to be. Here, key software issues involved include a lack of standards -- or disagreements -- in accountability for the condition or configuration of things.

Companies try to protect ROI with their policies, processes, and administration -- but it is not unusual that pressures from competition (that is, needs) or from business performance evaluations (results) can provoke isolated decisions that create misalignment between them.

So, one problem we find amongst these stories is ROI "erosion". Between the reason for software being bought, the habits for using it, and the ways it actually affects the organization, the value proposition gets worn down.

Software Management has an important objective of protecting the software value proposition against erosion, so that the software's potential ROI can be realized.

To offer this protection, management must be able to confirm that any practiced combinations of purchase reasons and demonstrated impacts are:
- documented, trackable, and reasonable; plus,
- prioritized, supportable, and improvable.

In the first set of confirmations, evidence is king. In the second, agreed requirements are the key.

Often the second set is practically impossible (or pointless) without success in the first set. This puts the emphasis on having, through the first set, a reliable reference record that accurately communicates not just what is available but why it is.

The software inventory is at least a concept that satisfies the role of being the reference record or database.

Many known complications with software inventory are due to the fact that records are created and maintained by many different parties for different reasons, which might later resist being well consolidated. Records maintenance also may vary in its diligence, completeness, or other quality levels -- according to who is doing it and why. Often this is tolerated because the standards for accounting are not demanding anything more. So one of the first things that must happen to drive a change in records maintenance is an explicit company need for standardization.

Standardization really means that everyone understands how their piece of record-keeping fits with pieces that must be maintained by others. Like with a protocol for a network, each part understands what the other part means. As a result, the parts do not all have to be in the same place, but they all have to speak the same language or use the same grammar. With software reference records, the grammar is a data model that all record-keepers share.

Going along with that is a move beyond accounting to analysis. By itself, accounting does not express the importance of the many-to-many relationships between what software is present and what it is actually doing. So, accounting does not talk about ROI. Not understanding ROI means not having one of the most essential ways of evaluating whether current software is helping or hurting -- and whether change should or should not occur. So what we look for is a chance to do analysis by being able to correlate impact data with reliable accounting data. This highlights the significance of getting control over the inventory -- which becomes a driver for a standardized data model.

Posted by Malcolm Ryder at February 14, 2006 2:38 PM

Trackback Pings

TrackBack URL for this entry:
http://www.malcolmryder.com/cgi-bin/mt-tb.cgi/213

Comments

Post a comment