How Vendors Discourage Experimentation

Now ask yourself: What portion of our "application backlogs" are a function not of unwritten code but of unused or undeployed software features and functionality that are simply unknown or untaught to users? My bet? At least half, probably more.

Why do I so confidently assert this? Because I've seen it with my own eyes. Fifteen years ago, everyone in the industry joked about the unfulfilled promises of overhyped "vapourware". Today, there is not a major enterprise software package - or a desktop app (Web-based or not) - that doesn't have far more features and functionality than 75 percent of its users need. Are there vendors who fail to deliver? Of course, and there always will be. But the reality is, for most organizations, a greater variety of "off-the-shelf" choices with more built-in functionality exists than ever before.

Yes, there will always be circumstances that require workarounds and custom-coding and special subroutines and so on. However, too many IT groups (and their internal customers) haven't thought through how they can tap existing software portfolios to better meet business needs.

Now I'm the first to acknowledge that many vendors - you know who they are, they know who they are - have stupid, counterproductive licensing policies that discourage willing customers from getting greater value. Shame on them! But when you look at the rate of open source evolution and how once-simple servers that handle transactions are becoming more multidimensional, savvy CIOs have to ask: How well do we really know what our software and systems are capable of doing if we're really prepared to be clever about them? Are we adequately building on success?

CIOs need to audit the early wins and encourage people to use them as springboards. The implementation challenge shifts when we think less about reaching for something "new" to solve problems than rethinking how we should tap what we possess. Yes, many vendors do a lousy job of documenting or explaining their offerings. And sometimes it's easier to look for another point solution to solve a new problem.

But if we've already learned to run a package that cost-effectively delivers the goods, why not build on it if the price is right? Building on the right experiences is better economics than acquiring novelties that will inevitably pose their own unique challenges anyway.

Sitting in that airless room with a genuinely committed vendor and genuinely committed customers reinforced a simple but hard-won truth: Build on what works, and treat early success as an invitation to innovate - not as a sign that the problem has been solved. Vendors need to push their sales and support people to explain how usage can evolve over time, not just how best to solve the problem du jour. And CIOs need to do a better job of reaching out to their business units and working with them to help identify the features and functionality they need, and then unlock those features from the software they already own or lease.

The true test of our stewardship is not just how well software is used but whether we're getting the full value that we should. That's not just a technology leadership test; it's a business leadership challenge.

Michael Schrage is codirector of the MIT Media Lab's eMarkets Initiative. He can be reached via e-mail at schrage@media.mit.edu