Making IT Work: If You Can’t Scale a Pilot, Don’t Start

A global financial services firm?you probably have this company’s card in your wallet?has an amazing track record with its technology pilots. They almost never fail.

Great IT management? Hardly. That amazing track record comes with a catch: Only a tiny fraction of those pilots are successfully deployed throughout the enterprise. The company is littered with expensive “mini-me” implementations: software, hardware, networks and apps that work perfectly well in their designated guinea-pig departments but virtually nowhere else.

Most of these pilots?including a not quite expert system for fraud detection and a data mart for CRM?did not live beyond a year or two. And those that did have become subject to perennial budget battles over who should pay to maintain them. Ugly.

This pathology of IT pilots is as global as IT innovation itself. The corporate landscapes of Fortune 1000 firms are cluttered with the digital bones of IT pilots that couldn’t, wouldn’t or shouldn’t scale. Indeed, too many pilots are designed with scaling as the last thing in mind. Companies focus on making their pilots more workable than scalable. In other words, they optimize the pilots’ success at the expense of optimizing the knowledge necessary to cost-effectively scale. The pilots become an end, not a means.

This economic dysfunction exists for completely logical reasons. The most important is that nobody likes failure. When a company spends real dollars and man-hours on a database or CRM pilot, it doesn’t want to declare that investment a waste. So companies try to make sure the pilot “works.” IT and the designated department will do whatever it takes to ensure the benefits of the pilot exceed its cost.

Which naturally leads to the next reason: To guarantee that the pilot succeeds, IT and its designated department conspire to have it solve some unique set of business problems. These problems tend to be so localized and specialized that they require more customization than standardization. Guess what’s more expensive to scale?

At the aforementioned global financial services firm, departments worldwide have superb point solutions to their particular problems. But in reality, the company’s approach has generated diseconomies of scale that wasted hundreds of millions of dollars in less than a decade.

Pilots that run without scalability as a priority aren’t IT projects; they’re research. There’s nothing wrong with doing research on innovative IT offerings. However, let’s make sure the vendors?not the shareholders and employees?are paying their fair share for it.

The most important question confronting CIOs considering innovative technologies is not, How well do they work? but rather, How well do they scale? Instead of asking, How do we make the pilot work better? IT must probe, How might that suggestion to improve the pilot affect how we scale?

In many cases, a technology may scale quite well but the organizational use of it may not. I’m constantly surprised by IT departments that have debugged the technical scalability concerns at the departmental level but utterly fail to appreciate?let alone document?how long it took people in the department to accommodate the technical changes. For example, cryptokey technology may scale well technically, but the effectiveness of the implementations vary widely. Some companies put IT in charge, others HR, and still others hold individual departments accountable. The latter is a sure recipe for failure.

The huge advantage of Net-centric architectures is that they can redefine the economics of IT experimentation. Running a pilot for, say, a sales-force automation package can be expensive and time-consuming. Using the intranet to emulate the key functionality of such a package in a controlled way is not. I would never implement an SFA deployment without testing it on an intranet to see how salespeople actually use it.

The opportunity to rehearse tech rollouts by first putting them on an intranet or extranet should be as appealing as it is cost-effective. It minimizes the chance that either IT or the company will get caught up trying too hard to make an app work at too local a level. And these nets are a cheaper place to make mistakes.

Today’s economics no longer permit the luxury of piloting. The ability for IT to experiment faster, better and cheaper to understand the real costs of implementation represents a strategic choice, not just a tactical opportunity. The organizational message is simple: no scale; no sale. If we can’t cost-effectively scale it, we shouldn’t do it. That’s an implementation philosophy worth implementing.