Is There Return on Investment of Information Assets

From MIKE2.0 Methodology

There is return on investment (ROI) of information assets if there is return on investment. Data projects should ultimately improve the bottom line condition of the company. This means one of two things – increased profitable revenue or decreased expenses. While most projects target both of these objectives, one is usually dominant. For example, an enterprise MDM project that is unifying many enterprise-wide half-hearted master data approaches is saving the company money because it is centralizing the unavoidable work of master data management in support of numerous company projects. It is centralizing the work as well as the systems. Though tougher to prove, done well, it should be enabling the systems it supports to achieve greater results. At some point, the systems provide profitable revenue to the company. If not, the company is unwell.

Recently, there has been a resurgence of the ROI need for information projects. Many information management professionals are put in the unenviable position of justifying their projects this way, something that many find discomforting. Many would rather get justification under the banners of architecture, data quality, data democratization and so forth, but as this is not in the cards, let this guidance, along with the wiki here [[1]] empower you to speak the language. We need to translate the project into cash flow – cash in and cash out.

The expenses of the projects should be calculable much more easily than the returns. Justifications of one way to do something (usually a more architected, enterprise way) over an independent, unarchitected way may be simply a matter of showing a smaller expense stream over a period of time. This approach is called the total cost of ownership (TCO) approach.

Complicating matters in many organizations is that the information (data warehouse, master data management, business intelligence, etc.) team provides the “I” (investment) while the business teams provide the “R” (returns). To do ROI, both sides need to work together. If you are simply (relative term) providing THE way to do what will be done inefficiently otherwise (TCO), you often just need to show the lower cost of YOUR way.

Whether doing ROI or TCO or both, the time periods are getting shorter for proving a project’s worth as business becomes more competitive and is demanding shorter payback periods, on the order of six months. This highlights the need for an agile approach and a tight return on investment approach. This does not mean that benefits can fall off a cliff at that point. Indeed, the benefits from these projects, done well, tend to get larger over time. However, the point is that you do not have a long time to deliver benefits and those short-term ROI estimates are often very key to project approval.

To get to the returns, one must trace the project delivery through the complex chain to sales or to the expense reduction. Though many benefits accrue, all of which could be traced through to sales and expenses, only the core benefits are worth measuring. If 1-2 benefits do not turn ROI in the expected period, you may need to refactor the project. You may need to give up the idea of measuring the project after the sourcing all of SAP into the data warehouse. You may need to give up the idea of not delivering reports and metrics out of your data warehouse until you have all the data from SAP. You may need to carve up the project into chunks that may be uncomfortable if unfamiliar with agile approaches. These information projects are not fundamentally different from other projects in this respect.

While the Information Assets article [[2]] refers to net present value, there are actually a few ways you may find the Finance arm of the organization interested in forming calculations. All are based on cash flow and all easily flow from that cash flow. So, you would show cash flow first (by breaking it into months or quarters) including the expected returns.

Net Present Value is taking the expected cash flow stream (utilizing cost of money) and showing that that stream has positive value now. In other words, based on projections out 6 months, the project looks like $250,000 today. Not only must the stream show positive, but many times it must show larger than potential competing projects for the limited company budget available.

Break Even Analysis looks for that point in the future when the cash flow goes positive – and stays that way. In this method, the project is competing against other projects to show the quickest break even point.

And then there’s return on investment analysis, which takes the cash flow stream (utilizing cost of money) to show a percentage return. This is similar to what the bank offers as its interest rate. Again, shorter periods and higher ROI are best.

Internal Rate of Return is a final common approach. It “backs into” the cost of money by analyzing the cash flow stream. It is the interest rate corresponding to zero net present value.

So when asked to justify the information management project, regardless of whether it’s a data warehouse, MDM, BigData, data mart, customer relationship management, analytics or business intelligence project, you need to understand:

1. Do you need to show the best WAY to do something (TCO) or that the entire something delivers to the business (ROI)? 2. If ROI, which form of ROI – net present value, break even analysis, return on investment or internal rate of return? 3. How long can you calculate the ROI for (the longer, the better it will look)? 4. How much will the project cost – broken up into even time periods (months or quarters)? 5. If ROI, how are you going to get the estimated returns?

Then, go deliver those returns and make the sponsor look “like a boss.”