Skip navigation
2010

Jacob Varghese has more to say about how and why ROI (return on  investment) might not be a good way to make determinations regarding IT  investments. In doing so, he references work by Ross and Beath:

 

"In 'New Approaches to IT Investment,'  Jeanne W. Ross and Cynthia M. Beath break all IT investments along two  dimensions: (1) strategic objectives (short-term profitability vs.  long-term growth) and (2) technological scope (shared infrastructure vs.  business solutions)…. Based on those two dimensions, all IT investments  can be broken into one of the following four categories:

 

"Transformational: IT investments  that aim to remove the infrastructural barriers to long-term growth  across the organization (for example, integrated CRM, enterprise  information portals, or end-to-end processing). Given the  organization-wide impact and the imperative that such investments must  be in line with organizational strategy, the CEO must own these  investment decisions. The success of these projects should be his  responsibility.

 

"Renewal:  The aim of renewal IT investments (such as legacy modernization and  platform conversion) is to improve the service levels of the existing  shared infrastructure or reduce the cost of support and maintenance. The  ownership of such projects should lie with the CIO, since the  boundaries of these projects are well defined and benefits accrued can  be quantified up front. Moreover, it is the CIO's responsibility to  ensure the service levels from the shared IT infrastructure are  constantly improved.

 

"Process  Improvements: The end objective of IT investments that focus on  short-term profitability or incremental process improvements might be to  speed time to market, lower the cost of operations, or to differentiate  services/product offerings. The ownership of such investments should  lie with the business unit head, functional head, or the process owner,  depending on how the organization is structured.

 

"Experiments: New technological  trends that present significant opportunities for long-term growth  should be the focus of IT experiments that use pilot programs to  validate the technology's promise and impact. There is no fixed home for  these projects. In one the industry, they might reside within the  R&D organizations, in another, the enterprise architecture teams  of MIS departments might take responsibility." (Varghese 2003)

 

There  is, of course, legitimacy surrounding each of these classifications,  but I want to take a closer look at each since it is my firm belief that  business organizations really should be seeking ongoing  improvement and, for for-profit organizations, real improvement should  lead to making more money.

 

Transformational IT  projects

Ross and Beath describe transformational IT projects as being  "IT investments that aim to remove the infrastructural barriers to  long-term growth across the organization (for example, integrated CRM,  enterprise information portals, or end-to-end processing)." Now, in  for-profit organizations, my guess is that the real measure of "growth"  is in two realms: revenues and profits. I doubt that there is a desire  to grow the balance sheet just to call it "growth."

 

Another  word for "barriers to long-term growth" would be a "constraint." So,  "transformational" IT investments should be aimed at exploiting,  elevating or breaking a constraint to long-term growth. And, while we  are talking about it, let us set forth this axiom: It is not possible to  exploit, elevate or break a constraint to long-term growth  without the action also opening the door for short-term growth.  So whatever investment your executive team makes in so-called  "transformational" IT should still be able to be measured in the  essential terms we used in earlier portions of this series: namely, increasing Throughput, reducing Inventories or demands for new Investment,  and cutting or holding the line on Operating Expenses while  supporting significant growth.

 

Let us look at each of  these more closely in the context of "transformational" IT:

 

Increasing  Throughput: Some business executives look at IT investments in,  say, a new ERP system as though ROI for such investments were a given.  There justification for yanking their present systems out and going  through 18 months or more of upheaval in a traditional ERP –  Everything Replacement Project is frequently little more than some  general sense that "If we do it, things will get better." They hear that  other companies have replaced or upgraded their ERP systems and report  making more money, and they don't want to be left behind. But these same  executives forget that other companies have also gone into Everything  Replacement Projects only to be tapped for hundreds of thousands or  even millions of dollars and not improved at all. In fact, some  companies never recover from traditional ERP implementations and end up on the junk-heap of business history.

 

In  the absence of the willingness or tools to create a valid estimate for  their firm's "transformational" IT projects, some executives and IT  managers seem to buy into the software vendors' and resellers' theory  that somehow "new" or "improved" ERP systems are like oil to an engine –  just pour it in and everything will run smoother, faster and with less  friction.

 

Well, oil does that for an engine and we can  accurately predict the effects of the lubrication on the engine because  we have laws of physics and mechanics to guide us in calculating the  predicted effect. Unfortunately, most business executives and IT  managers today do not even have an accurate theoretical framework about  what the constraint is – or constraints are – to their businesses'  making more money tomorrow than they are making today. Instead, they  accept the "mystical mojo" theory that "new" or "improved" technology  will somehow make their enterprise also run smoother, faster and with  less friction.

 

Would it not be more business-like for your executive management team to actually figure out how just how any investment in IT that is designed to "remove infrastructural  barriers to long-term growth" will actually remove barriers to  long-term growth? Would it not be more practical for the team to  make some rational estimates of the measure of improvement that  will result from the removal of these "barriers to long-term growth"?  Does it not stand to reason that, if managers believe that implementing  new technologies will, in fact, "remove… barriers to… growth" that they  be asked also to define just how the technologies will elevate or  break existing constraints to business growth?

 

That is  what figuring out how much new technologies will contribute to increasing Throughput is all about. The executive management team should be able  to say something along these lines before making a decision regarding  any given IT project: We believe that investments in technology X  will lead to increasing Throughput (for definitions see related posts)  by Y dollars within N months. We base our estimates on the new  technology's providing us with the ability to expand our reach into  markets A, B and C accompanied by commitments from Sales and Marketing  that targeted offers in Product Lines P, Q, R and T.

 

To  do less than this is for your executive management team and IT staff to  make a resolution to spend, perhaps, hundreds of thousands of dollars  on new technologies based only on "hope" and we all know that "hope" is  not a strategy, at all.

 

Reducing Inventories or  other demands for new Investment: Much of what I just said about  your executive team setting forth specifics in estimating changes in  Throughput applies equally well in calculations regarding potential  changes in Inventories or other Investment. If your IT staff or software  vendor is encouraging you and your team to consider an investment of  potentially hundreds of thousands of dollars, it seems that you would  owe it to yourself and to your stakeholders to grapple with just how  this investment may help the company with regard to liberating cash or  reducing demands for new investments in other areas of the enterprise.

 

If  investing in new supply chain technologies will help slash your $10  million average inventory by an estimated 22%, then that is $220,000 in  cash that will be liberated in your operating cash flow. But your  management team should figure out, in advance, just how the  application of the technologies in your specific environment will lead  to this 22% reduction in inventories. The 22% figure should not be  grabbed out of the air; nor should it be taken for granted that because  the technology vendor has reports from other clients that this number  has been achieved that your organization can do the same.

 

However,  on the positive side, if your proposed technology investment can cut  your inventories by 22% while simultaneously support significant  increases in Throughput, then you and your team are probably also  looking at an apparent reduction in demand for new investment, as  well. It means that your enterprise may be able to double or triple its  Throughput without having to build a new warehouse or invest in the  expansion of the existing one. This is all good news and should be  calculated in the firm's ROI for the proposed investment in  "transformational" IT.

 

Cutting or holding-the-line  on Operating Expenses while supporting significant growth: Again,  much of what I have said above regarding your executive team's  willingness to "dig out the numbers" and figure out the "how" an  investment in "transformational" IT will "remove barriers to… growth"  applies to calculating changes in Operating Expenses (OE). Do not rely  on rules-of-thumb and reports from technology vendors and resellers  regarding the benefits other companies have achieved. If these are going  to be real for your enterprise, then the how-to and resulting  benefits should not be too difficult for your team to put down on paper.

 

Actually,  in the example given above, we could already calculate at least one  portion of the change in OE: If we know the firm's carrying costs  for inventory, then the change in Operating Expenses from the reduction  in inventory would simply be $220,000 times C%, where 'C' is carrying  costs as a percent of inventory. If it costs your business 20.8% to  carry inventory, then the change in Operating Expenses would be a decrease  of $220,000 times 20.8% or $45,760 per annum.

 

The  bottom line

The bottom line is "the bottom-line." Do not succumb to  accepting ROI calculations from your technology vendor or base them on rules  of thumb that may or may not be accurate for your enterprise.  Besides, it is up to your management team to work out – in advance –  precisely how they intend to leverage the proposed new  technologies to achieve the ends of increasing Throughput, reducing Inventories or demands for new Investment, and cutting or holding  the line on Operating Expenses when "transformational" IT projects  claim to be "removing barriers to… growth."

 

We will  continue with the other kinds of IT investment from Ross and Beath in  future posts.

 

[To be continued]

 

©2010 Richard D. Cushing

Works Cited

Varghese, Jacob.  "ROI Is Not a Formula, It is a Responsibility." Journal of Business  Strategy, May/June 2003: 21-23.

As I said in Part 1 of this series, I  have, of late, been challenged in my thinking from two quarters: first,  in a LinkedIn discussion I had an entrepreneur tell me that entrepreneurs had to be  too much "right-brained" and could not be cornered into decisions based  on such things as calculated ROI (return on investment).

 

And  next by this excerpt from a May/June 2003 article by Jacob Varghese:

"Basing IT priorities on ROI rankings is a fool's game, a game in  which the biggest liar wins. By relying solely on ROI figures to approve  a project or decide between projects, managers are shirking their  responsibility for understanding how technology will affect their  businesses. ROI numbers do not ensure that technology initiatives will  be in line with business strategy. The success of any technology  initiative depends on whether the person responsible for implementation  has the required incentives, authority, and credibility across the span  of the organization that would be affected by that initiative. ROI  figures should merely be used as a means to ensure that the planning is  as comprehensive as possible and the totality of impact has been  considered. And managers should avoid approving the entire funding up  front. Rather, funding should be an ongoing contingent upon the project  team meeting key milestones and realization of planned benefits."  (Varghese 2003)

 

"ROI numbers do not ensure that technology  initiatives will be in line with business strategy."

Of course, Mr. Varghese is absolutely correct in this. It  is quite possible to calculate an ROI for a project that has nothing to  do with your business strategy. In fact, this is eminently possible if  you use formulas provided by software vendors and resellers. All you  need for some of those formulas are numbers like:

  • Number of  employees
  • Number of salespeople
  • Current Revenues
  • Number of orders per month
  • Number of SKUs and so on, ad nauseum.

 

Unfortunately, one of the things that you will note about these  numbers supplied to standard ROI formulas used by salespeople is that everyone

has employees, everyone (or almost everyone) has salespeople, everyone has revenues, and so forth. None of these figures say  anything about your business strategy or what will actually make  your business better.

 

If you use these kinds of generic  formulas to calculate the ROI of your IT initiatives, then there is no  assurance whatsoever that the there will any alignment between IT  efforts and your business strategy. So the answer is, do not use  such ROI calculations. Go back to Part 1 in this series and see how you and your management team should calculate ROI in order to compare  business opportunities that may be supported by IT investments.

 

"The success of any technology initiative depends on whether  the person responsible for implementation has the required incentives,  authority, and credibility across the span of the organization that  would be affected by that initiative."

 

Now here is where I'd have to ask Mr. Varghese for the  definition of "success." If you ask the typical software vendor or VAR  (or, unfortunately, maybe even your own IT manager) the definition of  the "success of [a] technology initiative," you are likely to get an  answer along these lines: "If the project is completed on-time, within  the budget, and delivers the quality anticipated to the end-users, then  the project is a 'success.'"

 

What is missing in this  all too typical definition of IT project success is anything having  to do with delivery of business value. If that is true – if your IT  manager does not relate every effort to delivering business value that is a failure of executive management. Either they hired the wrong  kind of person for the job, or they have not taken time to convey across  the whole organization – IT staff included – that every expenditure  of time, energy or money should be focused on delivering business  value.

 

If, on the other hand, your executive  management team is "responsible for implementation" of each IT  initiative and if they have prepared their ROI calculations for the  project as I have described in Part 1 of this series, then they will  have and know everything they need to help guide the project to full  business value-delivering success.

 

"ROI figures  should merely be used as a means to ensure that the planning is as  comprehensive as possible and the totality of impact has been  considered."

 

I confess that Mr. Varghese has me confused at this  juncture. If "planning is as comprehensive as possible and the totality  of impact has been considered," then what is wrong with using the ROI  figures altogether? I think most readers will concur with me that the  ROI in the example presented in Part 1 of this series is "comprehensive"  and considers "the totality of impact." So, if such numbers exist, why  not use them in a comprehensive way to set IT priorities?

 

"And  managers should avoid approving the entire funding up front. Rather,  funding should be an ongoing contingent upon the project team meeting  key milestones and realization of planned benefits."

 

I certainly concur with the general notion that, if proof  of concept can be achieved without expenditure of the full  budgetary allowance for any given IT initiative then, by all means, get  to the proof of concept and make a go/no-go decision at that  point. This is common sense.

 

However, planning, that  goes well beyond the IT department, should be responsible for all of the  other things that must occur in order to "realize planned benefits."  Technologies are tools and only tools. They represent  costs, expenses and investment and do not, in themselves, ever represent revenues, Throughput or profit to the organization. It is up  the business organization itself to leverage the tools in order to  achieve more of the firm's goal – to make more money today and in the  future. Executives and managers must have laid the functional groundwork  during the planning that was used to calculate the ROI (see Part 1).  They must already know what must happen to reach the estimated increase  in Throughput, for example. That factor is not in the purview of  the IT department.

 

[To be continued.]

©2010 Richard D. Cushing

Works Cited

Varghese, Jacob. "ROI Is Not a Formula, It is a Responsibility."  Journal of Business Strategy, May/June 2003: 21-23.

I have, of late, been challenged in my thinking from two quarters:  first, in a LinkedIn discussion I had an entrepreneur tell me that entrepreneurs had to be  too much "right-brained" and could not be cornered into decisions based  on such things as calculated ROI (return on investment). (It's true: he  said "right-brained," but I think he meant "left-brained" with reference  to the creative side.)

 

Next, I was going back through  some old articles I had collected and discovered this excerpt from an  May/June 2003 article by Jacob Varghese:

"Basing IT priorities on ROI  rankings is a fool's game, a game in which the biggest liar wins. By  relying solely on ROI figures to approve a project or decide between  projects, managers are shirking their responsibility for understanding  how technology will affect their businesses. ROI numbers do not ensure  that technology initiatives will be in line with business strategy. The  success of any technology initiative depends on whether the person  responsible for implementation has the required incentives, authority,  and credibility across the span of the organization that would be  affected by that initiative. ROI figures should merely be used as a  means to ensure that the planning is as comprehensive as possible and  the totality of impact has been considered. And managers should avoid  approving the entire funding up front. Rather, funding should be an  ongoing contingent upon the project team meeting key milestones and  realization of planned benefits." (Varghese 2003)

 

Now,  I remain at two-minds regarding the Varghese article. On the one hand, I  might agree with him on some matters, but I cannot be quite sure  because there are other statements that run so outrageously against my  inner sense that I cannot be certain of his meaning in the other  statements. So, let me break this down sentence by sentence:

 

"Basing  IT priorities on ROI rankings is a fool's game, a game in which the  biggest liar wins."

 

Who is the "liar" here?

 

I suppose if the  ROI figures are coming from a salesperson working for a software vendor  or VAR (value-added reseller), then Varghese might have a point.  However, it is the firm's executive team that is the "fool" in that  case, for believing the ROI numbers provided by the very persons who  stand to gain the most – and lose the least – by selling new technology  to the firm.

 

However, if the executives and managers  are doing their job properly and they have the right tool set,  they should be the inventors of their own ROI figures. Furthermore,  those figures should not be predicated on industry averages or  "round-numbers" or rules-of-thumb. The executive team should  figure out – for each proposed investment in IT – the following three  factors (at a minimum):

 

Factor

Description

Example

1

Change in  Throughput or delta-T

How much will  Throughput increase, where Throughput is defined as incremental revenues  less truly variable costs (only those costs that will vary  directly with the change in incremental revenue change)

Investing $85,000  in technology X should increase our sales of Product Lines A, B and C  in the Y market segment by 15% over the next 12 months. We estimate that  this will result in $215,000 per annum in additional Throughput when  fully up-to-speed. We believe that minimal change in Operating  Expenses will be necessary to support this increase it Throughput.

2

Change in Investment or delta-I

How much will total assets change

Of the $85,000 investment in technology X, we  expect that $50,000 will be capitalized. We also expect that about  $22,000 in additional inventory will be required to support the $215,000  per annum in additional Throughput. Therefore, total change in  Investment (first year) is estimated to be $72,000 ($50,000 + $22,000).

3

Change in Operating Expenses or delta-OE

How much will day-to-day expenses increase or decrease

As previously stated, our estimates indicate that we will be able  to support the $215,000 in additional Throughput with no additional  staffing. However, the carrying costs for the additional $22,000 in  inventory are estimated at 23.2% or $5,104 per annum. We also know that  software maintenance costs will 18% of $20,000 or $3,600. Total  estimated change in Operating Expenses are, therefore, $8,704 per annum.

In the first year, we must  add the non-capitalized part of the $85,000 IT project, or $35,000.  First year delta-OE is, therefore, $8,704 + $35,000 = $43,704.

 

 

How, then, do we  calculate the ROI for this "technology X" project? Quite simply using  the following formula:

 

ROI  = (delta-T – delta-OE) / delta-I

 

Or

 

First-year ROI = ($215,000 - $43,704) /  $72,000 = $171,296 / $72,000 = 238%

 

 

 

Now, perhaps  Mr. Varghese can explain to us all why comparing various IT projects on  this basis is "a fool's game."

 

"By relying solely  on ROI figures to approve a project or decide between projects,  managers are shirking their responsibility for understanding how  technology will affect their businesses."

 

Here, again, I guess we need to ask the question: Whose ROI figures? If the figures upon which the executive team is relying  come from the vendor or the VAR or are otherwise based on non-specifics,  then I would concur with Varghese.

 

However, if the ROI  figures are coming from sound analyses as I just set forth in the  examples above, then I would say that it would be managers who do not "rely solely on ROI figures to approve" IT projects, or to "decide  between projects" that are "shirking their responsibility for  understanding how technology will affect their businesses." In fact, by not preparing an ROI analysis with the kind of stringency suggested by my  example above, then managers and executives are simply throwing in the  towel and confessing outright that "We do not know how technology  will affect our business. Instead, we just have hope that if we  spend money on technology, that somehow our company will magically improve."

 

That, folks, is not a strategy.

 

[To  be continued.]

©2010 Richard D. Cushing

Works Cited

Varghese, Jacob. "ROI Is Not a Formula, It is a Responsibility."  Journal of Business Strategy, May/June 2003: 21-23.

Writing for CIO UK, David Henderson suggests several reasons “Why IT vendors must raise their game”. The second major point he mentions is that “IT vendors tend to be driven by their portfolios rather than business outcomes” for their customers. Henderson points out that IT vendors “continue to make significant investments in their portfolios but aren’t prepared to make the same investment in understanding how these apply to their customers’ businesses,” which can “lead to huge inefficiencies” once implemented at the customers’ sites.

 

As a result, Henderson continues, “vendors… tend to give poorly defined generic presentations that bear only passing relevance” to the challenges faced by the customer or prospect at hand. Henderson goes on to berate the ERP vendors for “me, too” solutions and their inability to “connect the dots” between their product offering real value for the firm that buys the technology.

I agree that IT vendors need to change. The economic picture is vastly different in 2010 than it was even three years ago.

 

Where I disagree with Henderson’s writing, however, is who should know what.

Starting off on the wrong foot

Computer-based technologies really were not available to any significant number of SMBs (small-to-mid-sized businesses) until after the introduction of the personal computer (PC) in 1981. Prior to that, computing power available from mainframe and mini-computers was available only to larger firms with significant capital for investment in such technologies.

 

So, in the early days of the computerization of the SMB market, almost every new prospect was anticipating moving off a system dominated entirely by paper and the necessary manpower to keep the paper flowing. As the price of PC-based technologies fell, more and more companies made the switch. This movement dramatically increased productivity and return on investment (ROI) for such a move was almost a certainty. As a result, many ERP salespeople came in the door talking about increasing productivity and providing rapid ROI for almost every SMB they approached. And, almost without exception, the implementation of that first round of technologies provided consistently rapid payback for the firms.

 

Unfortunately, as the market changed (i.e., SMBs’ next round of technology purchases were not taking them off paper-based systems but, more frequently, moving them into a comprehensive suite of application modules or moving some SMBs off the high cost of maintenance associated with mainframe and mini-computer systems), the sales approach of most technology vendors did not change. The technology vendors’ salespeople continued to make the same claims about productivity improvements associated with the first round of ERP implementations and the executives and managers at the customers’ sites continued to drink up the claims like Kool-Aid. In many cases, the SMB management was spurred on by the impending arrival of the year 2000 and the Y2K epidemic of fear. Many executives felt they needed to spend the money to upgrade their systems and took little thought as to the ROI of such an expenditure.

Nobody grew up and nothing changed

By the early 2000’s the ERP market had changed yet again. By 2005 or so, almost every CEO or CFO of every SMB had been through at least one – and usually two or three – implementations of new software (or other technologies) in their business environment. Add to that experience the fact that they now had easy access to the Internet by which to explore and make inquiry regarding almost any ERP software on the market, and the ERP-buyer had changed dramatically over a bit more than two decades.

 

When ERP was starting to be sold (20-plus years earlier), when the technology salesperson first met a prospect, the prospect was hungry for information about products and capabilities. Furthermore, these green-horn technology buyers were more than willing to make the salespeople their de facto “instructors” in the purchase and application of new technologies in their businesses.

 

In addition, as previously stated, ROI was pretty easy to achieve. Almost any SMB moving off labor-intensive paper-based processes or coming from costly mainframe or mini-computer technologies was bound to reap savings in operating expenses, and was almost equally likely to achieve increases in Throughput. However, by the middle of the first decade of the 21st century, all the easy ROI from traditional ERP – Everything Replacement Projects – was gone and not likely to return. Sadly, much of the technology salespersons’ product positioning remained unchanged and the sales rhetoric and promises from a good many ERP vendors still harkened back to days gone by – without, of course, actually mentioning that fact.

 

This unwillingness to face the change in the marketplace was not entirely one-sided. As the traditional ERP sales hype continued to make sweeping “rule-of-thumb” claims about delivering ROI for the ERP-buying executives and managers, these executives and managers proved themselves equally willing to accept the claims without taking the time and effort to discover for themselves what they really needed to know about their particular organization and its potential for reaping ROI from any particular foray into new or upgraded technologies.

What every executive and manager needs to know

As Eliyahu Goldratt has put it so well, there are three – and only three – things that every executive and manager needs to know to make effective decisions in every situation. These are they:

  1. What needs to change
  2. What the change should look like
  3. How to effect the change

If, before making the leap to buy technologies based on “rules of thumb” and sales-speak, executives would just take the time to figure out the answers to these three questions, there would be far fewer stories about traditional ERP implementations failing to deliver expected business results.

 

IT vendors are not necessarily driven by business results for every client. And, as executives and managers, you should be aware that rules-of-thumb may not apply to you and your enterprise – and the ERP vendor or VAR is not responsible for your business’s not fitting the rule-of-thumb by which other enterprises may have achieved return on investment.

 

As executives and managers in your organization with your particular circumstances and requirements, you – not the technology vendor or reseller – need to know what needs to change in order for your firm to start making more money tomorrow than you are making today. You – not your vendor or reseller – need to know what the change should look like in your particular organization. (The vendor or VAR may help you understand how new technologies may be part of what that change should look like, but you need to understand the precise need in order to effect your desired ROI. (Read more in many articles found right here at GeeWhiz To R.O.I.)

 

And lastly, as executives and managers it is your responsibility to understand how to effect the change within your enterprise. (Here again, the technology vendor or reseller may help you understand the technology-related components of the change, but yo and your team need to take full responsibility for creating a roadmap for change.)

 

©2010 Richard D. Cushing