Secret CIO: Early Adopters Must Balance Pros And Cons

I enjoy reading articles about early technology adopters. It's impressive to see the smiling faces of my visionary colleagues who have installed the latest whiz-bang gadget or beta version of cutting-edge software. They bask in the admiration and awe of vendors and CIOs alike for their courage and organizational leadership. Without their work, the stuff we buy for our companies would be even more error-prone and flawed than it is.

On the other hand, I've never quite figured out what exactly the return is on all the time and energy spent debugging someone else's product. It might be fun to be the first person in your corporate neighborhood to play around with Windows Vista, but does it really warrant the resource investment? I'm not saying it doesn't, just that the value isn't readily apparent to me. Sort of like how I've never been able to accept on faith that pointy high heels are glamorous rather than making a woman's foot look like the tip of an anvil.

Over the years, I've been involved with testing a few beta products. One was a learning station that I used successfully to train people at various locations on a new system. The vendor needed a solid reference account, while I wanted a system that would prevent us from having to send badly overworked people out to small sites. We discussed our mutual priorities and reached an agreement. The company got its reference account, and I got a significant discount on a system that was modified to meet my special requirements. It was a satisfactory relationship that ended happily for both of us.

Evaluation Criteria
At other times, when some big software industry players approached us, we've politely demurred from being involved with early-adopter agreements. Unless there was a clearly measurable benefit for us, avoiding the offers seemed best. What were the criteria we used for measurable benefit?

Does the early-adopter test solve a problem that can't wait? Much software contains new features that would be useful but aren't valuable enough to risk fooling with before they come out in a production version. Even then, it frequently makes sense to avoid being the first to install. Let someone else spend the time finding all of the inevitable bugs the testers missed.

Is there financial incentive to commit the resources required to be a beta site? People cost money, and unless a shop is very unusual, beta testers could be working on important business issues. Sometimes a vendor will provide significant monetary motivation to a company to participate in an early-adopter program. There has to be a sound business rationale for the investment of your organization's time. And, sorry, the prestige to your staff of working on the latest and greatest and the opportunity for you to get your picture in a trade magazine won't offset a user project that doesn't get done because of the beta commitment.

Is there a benefit to a long-term relationship with the vendor? Even if you intend to use its product for a long time, what can you expect from the vendor over time if you participate? If you think that your maintenance support will be better down the road because of your involvement, the beta program might be a good idea. If all it gets you is some amorphous promise of input on the next version's features, get a life. Any vendor is going to do exactly what benefits itself. If you're a big enough customer, you'll have input whether you're a beta user or not.

The Hippocratic oath for physicians is often summarized as, "First, do no harm." If there were a CIO oath for joining early-adopter programs, it would go something like, "First, make sure you're doing your company some good."

Herbert W. Lovelace shares his experiences as CIO of a multibillion-dollar international company (changing most names, including his own, to protect the guilty). Send him E-mail at [email protected].