This article addresses the concept of developing a Return on Investment (ROI). It does so by first defining the ROI concept, then by setting out the components that comprise its creation, and finally by identifying several scenarios in which an ROI is created.
ROI is often used as a selling tool. However, to say that we are not all salespersons in one form or another across varying times is not true. Every time you are pitching a project, improvement, or change in strategy/method, you are clearly selling.
Just what is an ROI?
From Wikipedia, a Return on Investment (ROI) is:
“…the benefit to the investor resulting from an investment of some resource. A high ROI means the investment gains compare favorably to investment cost. As a performance measure, ROI is used to evaluate the efficiency of an investment or to compare the efficiency of a number of different investments. In purely economic terms, it is one way of considering profits in relation to capital invested.”
There are alternative names for ROI. One such name is “value proposition.” Again, from Wikipedia, a Value Proposition “is a promise of value to be delivered and acknowledged and a belief from the customer that value will be delivered and experienced. A value proposition can apply to an entire organization, or parts thereof, or customer accounts, or products or services.”
While there are kinds of nuances in various definitions, these will do. From a formulaic point of view, the Wikipedia’s calculation is:
- ROI = (gain from investment – cost of investment) / cost of investment
The ROI we are addressing here, however has to have a different formula:
- ROI = Traditional Approach Resources / (New Approach Resources + Resources to Adopt the New Approach)
So, using a business information system example, if through a traditional approach to business information system development, the cost is $6 million, and through the replaced approach it only costs $1 million having adopted a new approach that has an adoption cost of $500K, the ROI is 4. ($6 million / ($1 million + $500K)).
That would be the ROI on the first cycle of the new approach’s adoption. For the second and on, the ROI would be 6 as the costs of adoption would have already been incurred.
My first encounter with the formal need to develop ROIs came years ago. The gentleman had become CIO of a world-wide and very large financial services firm headquartered in Boston. He had been–over the years–listening to the evolving development of my various products. In the spring of 2013 he said to me:
“I really believe that your products and approaches have value. Honestly. But here’s the thing. Until you can answer these two questions, I just cannot devote corporate resources to investigate what you have:
- If I don’t have enough time to do what I must do now, how do I have extra time for you?
- If I don’t have enough money for what I must do now, how do I have extra money for you?”
He is right, of course. So, during the rest of 2013 into early 2014 I set about developing a number of ROIs. But where to start? First, I thought that I should set about describing all the really “neat” features of my company’s data management approaches, methodologies, and its metadata management system that stores, integrates and interrelates IT work products. But I had already done that without much success. I came to realize that clearly describing solutions without first knowing the issue was a problem. What had not worked in the past was unlikely to work in the future. Therefore, I stopped that approach.
I did research on the subject and one conclusion stood out: If you don’t know the issue, you cannot configure and/or sell a solution. Put another way, from a sales talk I attended recently, “Don’t sell the drill before you know the hole.”
Taking this advice to heart, I went back to the two “If” questions above and tried to figure out just what the issues were that had to be solved so my friend would give me his time. In short, my approach had to enable him to “make room for me” by reducing his expended resources so there were extra resources for me.
My years of experience with a focus on data management and business information systems, and having participated in many long-term projects across a number of IT areas told me that the following “customer” problems are common to almost all enterprises:
- Enterprise-wide Project Management: Knowing what you’re going to do, when, how, how much, and when must it be done.
- Information Systems Planning: Which areas of the business are you going to tackle in what sequence so that you avoid redundancy and conflict.
- Data-Centered Development and Management: Understanding that data models are defined once but are used many times. And, accomplished once, they enable business information systems driven by data models to be profoundly smaller, better engineered, and much easier to be evolved and maintained. Data models become the common center across many business information systems, and become the interrelationship-intersections across virtually all business information systems work products.
- Data Model Manufacturing: Understanding that the various generalization and abstraction layers of data models from business data elements to commonly employed data structures of concepts, to the two database layers, logical and physical, which collectively form the foundation for business information system access through views and technology data exchanges through XML can all be set into an data model manufacturing environment.
- Information System Environments: Understanding and setting into place the overall business information systems architecture, development, and maintenance environments that support maximum common component design and re-use through business information systems code generation rather than custom programming, the ability to incorporate custom business rule specification and coding without every compromising business information system generation.
- Information Systems Manufacturing: Understanding that the creation of “Right the First Time” efficient, effective, interoperable, and non-redundant business information systems can occur after generation and subsequent iterations of business information system operational prototypes based on subsets of enterprise business functions and data models.
- Enterprise Architecture Development: Right-sizing, engineering and architecture across the enterprise in a non-redundant manner of all the key IT work-products that become the basis for data model modeling and manufacturing, business information systems planning and manufacturing, and quick, easy, and effective evolution and maintenance.
These are listed in an order of encounter. I have run this list by several CIOs and they have all indicated that if these issues were addressed, their life would be bearable.
ROI Component Parts
Now that I had an issues list that was verified to be busting budgets, causing lateness, and producing unacceptable results given evolving requirements, the next step was to construct the ROIs for each of these areas.
I had to figure out just what constituted a well-crafted ROI. Clearly this could not be a “Trust me!” proposition. That has been asserted and heard too many times before. In IT, the phrase, “Trust then Verify” needs to be changed to “Verify then Trust.” Besides, this is just not like buying a new computer with more memory and/or faster disks. That’s a product. Rather, this is a change in approach solution for the issue. What resulted after a number of tries was the following outline for each developed ROI:
- Issue: What was the problem that needed to be addressed? What are the common evidences of failures? What are the typical/traditional expended resources (time and money) that occur that produce a failed or sub-optimal result?
- Solution Approach: What are the characteristics and descriptions of solutions to the issue’s component parts?
- Solution Engineering: How the Solution Approach component parts are engineered to arrive at a reliable and repeatable solution to the issue and also a brief solution process that makes sense.
- ROI: Given the Issue, Solution Approach, and Solution Engineering, the computation of the return on investment. It must compare before-adoption costs with adoption-costs and the clear specification of the returns resulting from the changed.
The final format for the ROI presentation on the website had two additional sections that appeared at the top of each ROI:
- ROI Savings Summary
- Support Links to materials the provide additional detail to the ROI
ROI Summary and Way Ahead
It has become apparent to me that the human element that is the problem. We have become artists and craftsman. It was Pope Julius, in the movie, The Agony and the Ecstasy, who kept demanding of Michelangelo, “When will you make an end of it?”
While the Sistine Chapel was certainly not on the critical path of the Church or the Vatican, data models and business information systems clearly are on the critical path of our businesses. In reaction to IT critical path failures, we first saw that the PC was salvation to the problems of the main-frame. Then it was the server. Then it was “packages.” Today it’s “The Cloud.”
The solution, however, is none of these, because the solution-blocking issues are timeliness, quality, efficiency, manufacturing, and the ability to evolve. These issues can only be addressed by having the correct IT environment and effective manufacturing. Everybody doesn’t need a Duesenberg. Model-Ts are more than good enough. Bringing manufacturing to IT is essential for solving the identified IT issues.
Consequently, the ROIs all have to be based on setting out the issue, describing the solution approach, the solution’s engineering, and finally, the calculation of the ROI once adopted. Needless to say, since most CEOs and CIOs are “show me” people, you better be able to immediately demonstrate the actual achievement of the ROIs. Otherwise you will just be another IT solution huckster.
Therefore it becomes your job to take the IT issue ROIs to the enterprise “C-level” officers who are not only charged with addressing theses issues but will be fired if they don’t deliver, and to clearly demonstrate via presentations and that the determined ROIs are achievable. Then and only then will you be given the time to accomplish what we in IT have been selling since the 1950s.
