All Posts in Industry Commentary

|In: Industry Commentary|Last Updated:

According to published reports, Internet Explorer 5.0 will occupy about 50 megabytes of your hard drive.

Now I’m a broad-minded soul, and a firm believer in letting every single adult American make his or her own trip to perdition in his or her own fashion. If Microsoft wants to ship a 50 megabyte browser, bless its heart. If you want to invest a dollar’s worth of hard drive to install it, bless your heart.

And if Microsoft wants to keep on calling a product it packages and ships as a discrete entity for several OS platforms an integral part of the operation system … well, that’s what we have the Department of Justice for, I guess.

Calling it an integral part of the operating system is an interesting enough claim. I enjoy the folks who call it a “thin client” even more, since it isn’t thin and isn’t really a client, either, merely a platform on which the client software can execute.

Blessed with complete ignorance of all facts, I’m confident Microsoft could have provided identical functionality in 25 megabytes had it established compactness and performance as design goals. The code is almost certainly bloated.

But, as Arlo Guthrie once said in a different context, that isn’t what I’m here to talk to you about today.

I’m here to talk about the consumers who will complain about the bloated feature set of the product, proclaiming with great pride that they only use 10% of the features anyway. The inference they’ll want the rest of us to draw is that Microsoft should remove the other 90% of the product.

Bragging that you fail to take advantage of 90% of what a product has to offer ranks right up there with bragging about not knowing how to balance your checkbook — it’s one of the reasons I’ve suggested organizing National Boycott Stupidity Day in previous columns.

So here’s a simple suggestion to all of you who are happy in your 10% mastery of the basic tools with which you perform much of your daily work: LEARN MORE FEATURES!!!

General office software contains lots of features that can make all of us more effective at what we do. When you’re using the computer, any time you find yourself doing the identical thing more than once or getting things out of whack when you make a revision, you’re probably ignoring a useful feature that would do it for you. You may manually number a list, manually retype the name of a section heading when you refer to it elsewhere in the text, manually format bulleted lists, use the space bar to line up right-aligned columns of numbers … do you see a trend emerging?

Extend this insight to the training programs you offer. We go about end-user training all wrong. Most IS trainers teach features. To drive the cliché off a cliff, we give our end-users fish instead of a rod, reel, and bait. Think about it. How much time do your trainers spend on exercises designed to make end-users self-sufficient, able to find solutions for themselves? Probably very little — that’s usually an afterthought at the end of the two-day Basics class. Teach them to poke around in the menus and help system, though, and they’ll learn how to do all sorts of great stuff on their own, including how to not call the Help Desk.

Now here’s where it’s going to hurt. The hardest part of learning these great new techniques is knowing they exist, right? Wouldn’t it be great if the computer watched what you do and, recognizing when you could benefit from one of its features, automatically suggested it to you?

I’ve spent more than a year wanting to punch Mr. Paperclip in the kisser. I still think he’s an obnoxious little cuss. Looking at it objectively, though, (ouch!) I’m forced to conclude (groan!) that he and his compatriots are a valuable addition (eeeeyooow!) to Microsoft’s office suite.

So if you only use 10% of a product’s features, don’t brag about it. Ignorance may be bliss, but it isn’t a virtue.

Comments

|In: Industry Commentary|Last Updated:

One of the most enjoyable experiences of my career was an upgrade.

It wasn’t the upgrade itself that was so much fun. It was the financial justification. Usually, getting capital approved for IS projects is about as much fun as being one of Sigfried and Roy’s cats – you get to jump through a bunch of flaming hoops while someone you’d enjoy clawing to death cracks a whip in your general direction.

This time, since we needed to upgrade our interactive voice response (IVR) system, we calculated the impact of unplugging the existing one. Since it was a 24-line system that was saturated during peak hours, this was simple: We just toted up the cost of adding another twenty-four customer service representatives to the call center and compared it to our original sub-$100,000 investment. Upgrade approved.

Occasionally, it’s possible to calculate the return on information technology through a clear and unambiguous calculation like this one. Usually, as pointed out in the last two columns, the value we provide is harder to quantify. Except for the rare process we can fully automate (an IVR is an example), the value we deliver comes in the form of capabilities used by the rest of the organization … capabilities that let the company achieve its strategic goals or that enable more effective marketing efforts, core processes, internal and external communications, and individual employees.

Capabilities are enablers: Each is necessary; none by itself is sufficient. How do you measure the value of a capability? How much does the fuel pump contribute to winning the Indianapolis 500?

To begin, you need to understand the value of achieving the business goal itself. Take a core business process. Process redesigns reduce unit costs and cycle times while improving the quality of whatever product the process creates.

To implement the new process a company probably needs new technology, new skills, a shift in culture, and perhaps a reorganization (even if it doesn’t, it will probably reorganize anyway because that’s what you do when you’re a big company undergoing change). What contribution does IT make to the tangible and intangible benefits?

The new process is completely different from the old one, so you can’t simply measure how much technology lowered costs, sped things up and improved quality. The best you can do is to determine the optimal process design possible without any technology changes … a good idea when redesigning a process in any event … and compare it to the one you plan to implement. You can plausibly define the difference as the value created by IT. (Caveat: This method isn’t mathematically rigorous; skeptics can challenge it on several grounds. Since nothing better is available, though, call it an approximation and be happy.)

While in principle, you can use this technique to measure the value of your legacy systems, too – by determining how the business would run if you unplugged them – in practice there’s little point. They deliver value – they’re in use, after all – so just measure unit costs and overhead, driving them as low as you can.

Another pothole in the road to IT measurement: Not every business goal is defined quantitatively. When a company redefines its strategy, for example, the usual reason is that the old one has run out of steam. The value of change is survival, not a numeric target. If the company needs new information technology to achieve its strategic goals, what value does it contribute? There’s no answer. Your contribution, while important, can’t be quantified. Don’t try.

And then there’s the hardest job of all: Measuring the value of a capability you deliver that’s unused or under-used. Lots of companies have thrown out gigabytes of customer information over the past decade, for example, because they didn’t have an immediate use for it. It had no value then. Now, with new strategies based on having extensive knowledge of customers, it would be a gold mine … but it’s gone, because the future value of the capability wasn’t understood at the time.

That’s just one reason measurement has its limits, but the ability to envision the future does not.

Comments