A couple of weeks ago, I was showing a new module to a client that had purchased their software from another company. Several months earlier, we had done an upgrade. We offered the client support and training, but they declined.
Throughout the discussion, they insisted that the reporting was terrible in the current product. I ignored the comments for a while. Finally, I asked, “Can you give me an example?”
The Purchasing Manager said, “I wanted a list of vendors in Excel. The best technical support could come up with was a label report. We had to key them manually.”
“Hmmm,” I answered, “Let me show you something and see if this is what you wanted.” I clicked File –> Export, selected a few options, typed a file name, and hit Ok. Then I opened Excel and the file I had just created.
“Was that what you wanted?” I asked.
The Purchasing Manager answered, “That’s more information than I wanted.” (She was serious, and sounded angry.)
I turned to the controller, and asked, “Was there a reason you didn’t give us a ring about this?”
“You would have charged us,” she answered.
The Purchasing Manager hit the nail on the head. “Let’s see,” she said, “a couple of hundred dollars (at most) vs. two weeks of my time…”
Penny wise and pound foolish…

There was a Gartner Group report some months back that contained a statement that (roughly) said, “It’s easier to train a business person in IT than to train an IT person in business.”
In many ways, I agree. The thinking processes are different. The objectives are different. True IT people are analytical and technical. Many business people are intuitive and relationship oriented. Not that each couldn’t learn from the other.
However, the more I work with IT professionals, the more I see that there is a central problem that I’m beginning to call the IT Effectiveness CHASM. It’s produced by a simple fact: IT objectives are often different from business objectives. In many cases, they aren’t even on the same page, and they can’t be easily translated to one another.
I’m working on ways that will work for both the IT side and the business side to bridge the gap.

I’m sure you know already–so excuse me if I’m repeating–that ROI is intended as a tool to compare different investments. The way ROI is often used in the IT industry is a bit different. Here’s an example.
Suppose that we’re looking at a new order entry system with warehouse management capability. The system costs (say $100,000). Now we analyze our ROI:
We have 4 warehouse employees, based on history, we believe that we can eliminate 1 of the 4. Salary plus benefits are $25,000.
We are also being charged by large customers when we do partial shipments or make errors in orders. Based on history, we think that warehouse management can save us 75% of these charges, or another $25,000.
Next, we’ve observed that salespeople often wander the warehouse to check stock levels. This is necessary because inventory quantities in the current system are not accurate. Salespeople estimate that they spend about 2 hours per day or 25% of their time doing this. We will eliminiate all of this for 10 salespeople, and estimate that with only a 10% increase in their daily number of orders, we will increase sales by $250,000 per year.
We could go on and list several other items. Some of them like “One-time inventory reduction,” we could actually assign a dollar value to. Others, like “Increase customer satisfaction,” will be hard or impossible to assign dollars to. All of these should be listed.
As you can see from above, we expect $300,000 return from a $100,000 investment. Most people would say this is a good project from a monetary standpoint. This is as far as most ROI analysis goes.
The system is implemented. Some of the ROI is realized (hopefully). Much of it is forgotten.
Bluntly, we’re using ROI wrong. It’s fine to do this analysis–in fact, I recommend it. The important thing here is not the amount of the return (as most people think). This might be a good project if we could only identify $90,000 in ROI, or even $50,000.
In reality, most of the benefit from a new system may be hard to quantify. Intangible benefits like customer service increase, sales management effectiveness increase, better inventory investment, increased correct order fills, reduced stockouts, etc. are difficult to assign hard numbers to (although some try).
The important things about this analysis are (a) there is ROI (tangible and intangible), (b) it provides a focus for implementation of the system, and (c) it gives a basis for measuring the effectiveness of the project.
For more on implementation with ROI, see Rule # 3.

Last week, I taught a class titled, “How to Cut Your IT Cost and Increase Effectiveness.”
At the beginning of the class, I thought it would be interesting to learn what the attendees thought “Effectiveness” was. I didn’t realize that I had both IT professionals and non-IT business professionals in the class, but I did.
The fascinating thing was that the IT professionals thougth that effectiveness equalled uptime, bandwidth, reliability, and other system performance metrics. The business people thought that effectiveness meant profit, productivity, and efficiency.
Their couldn’t have been a wider gap between the opinions. It made me realize that this is not just a gap, it’s a chasm. The cultures of business and the culture of IT are completely different. The values and objectives are different. Moreover, they are potentially in conflict.
How?
Suppose that you could trade 1 random hour per day of system down time for $1 million more profit on the bottom line. Would you?
That’s a bit extreme. Suppose you could trade a new copy of the latest version of Office for a half-day of training on how to use your order entry system better? Would you?
Focusing on the IT objectives the attendees in my class gave certainly isn’t bad. Neither is a new copy of Office. But they are not directly related to the most important goal of the business, either: to make a profit.
That’s the chasm: IT effectiveness is not defined in terms of business effectiveness.