Secret CIO: Technical Feasibility Isn't Business Viability

Sometimes I think that CIOs survive not so much by making the right moves as by avoiding the wrong ones. It goes back to my theory that people in an election vote against candidates, not for them. Goof up a few times and you're the former CIO. Muddle along without sticking your foot in foul-smelling stuff and you get to cross the finish line. Not a particularly pleasant observation, but that's life. Even though I don't like the idea--it breeds too many executives unwilling to take a risk--it seems to pan out in reality.

There are lots of ways to fail as a CIO: Overpromise and underdeliver, ignore unhappy users, pay more attention to technology trends than business needs, or just be in the wrong spot at the wrong time. One of the biggest dangers is talking about the importance of technical feasibility and business viability but not managing projects in a way to make sure that both exist.

While people easily agree with the concept of the importance of having the right idea and then executing it well, they often ignore or misuse the tools to make it happen in practice. Specifically, they confuse a proof-of-concept model with a prototype system--and vice versa. Maybe the difficulty is caused by a lack of clear definition of the two processes. They are most decidedly different.

Many of us have built prototypes. A prototype is a barebones system that has some or most of the functionality we expect in the production implementation. Prototypes let us know whether our architectural plan is sound. A prototype also has the virtue of letting users kick the tires for a while and tell us about problems before we commit a lot of resources.

After all, how many of us have faced the sickening realization midway through an expensive development effort that the latest new functionality demanded by a user means we have to scrap the design? Or maybe we find that it's impossible to scale the database-access method we love so much. A successful prototype spares everyone a lot of pain in actually building and implementing the system.

A proof-of-concept model is an animal of a very different breed. It's the system that you put together on a desktop that looks nice but is actually a kind of Potemkin village. It has an attractive facade but not much behind it. The purpose of the proof of concept is to do just what its name implies: Determine whether the idea driving the proposed system makes any sense. So, if you want to Web-enable your sales-reporting system, you build some pretty screens that show what a user can do and what responses he sees. The objective is to make the idea real to people, and if you can get some oohs and ahs along the way, so much the better.

Significant initiatives (those that take a lot of resources or mean a great deal to the company) need to go through both the proof-of-concept and the prototype stages. After all, it's hard enough to get money for good ideas without taking the chance that you'll lower the likelihood of success by messing up along the way.

A friend of mine learned that lesson the hard way. He was a divisional CIO for a fairly large company. Its customers are other businesses, and it has a good reputation for quality products and services. He was given the task of putting together an order-tracking system that customers could use directly.

It was a great idea, and Ray knew that it would have to work perfectly. He built a prototype that did all the right things. It validated the integration of the architecture with the corporate systems, tested the scalability of the data-access methods, and provided information as to exactly what hardware changes had to be made as customer acceptance increased the volume of concurrent users. What he didn't do was provide a little sandbox for the businesspeople and customer-focus groups to see if they liked the concept in the first place. The result was that the poor guy was busy tweaking his prototype with dozens of changes as each person finally gave his or her input on a live demonstration.

Naturally, since he was working with a prototype instead of a proof-of-concept model, he had to rework a whole bunch of integration points on the fly. Had he first built a desktop dummy (my less-than-official name for a proof-of-concept model), he could have made changes overnight until the users were satisfied. Then, when he finally built the prototype, he could have concentrated on technical excellence.

Good ideas don't translate intuitively into valuable and reliable operational systems. Seriously consider building both a proof-of-concept model and a prototype. You just might wind up being one of those people who actually makes a difference in your company.

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

To discuss this column with other readers, please visit Herbert Lovelace's forum on the Listening Post.

To find out more about Herbert Lovelace, please visit his page on the Listening Post.