Secret CIO: Technical Feasibility Isn't Business Viability - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Business & Finance
02:27 PM

Secret CIO: Technical Feasibility Isn't Business Viability

Woe to the CIO who thinks a prototype is proof of concept - or vice versa

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.

We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Comment  | 
Print  | 
More Insights
2021 State of ITOps and SecOps Report
2021 State of ITOps and SecOps Report
This new report from InformationWeek explores what we've learned over the past year, critical trends around ITOps and SecOps, and where leaders are focusing their time and efforts to support a growing digital economy. Download it today!
InformationWeek Is Getting an Upgrade!

Find out more about our plans to improve the look, functionality, and performance of the InformationWeek site in the coming months.

Becoming a Self-Taught Cybersecurity Pro
Jessica Davis, Senior Editor, Enterprise Apps,  6/9/2021
Ancestry's DevOps Strategy to Control Its CI/CD Pipeline
Joao-Pierre S. Ruth, Senior Writer,  6/4/2021
IT Leadership: 10 Ways to Unleash Enterprise Innovation
Lisa Morgan, Freelance Writer,  6/8/2021
Register for InformationWeek Newsletters
Current Issue
Planning Your Digital Transformation Roadmap
Download this report to learn about the latest technologies and best practices or ensuring a successful transition from outdated business transformation tactics.
White Papers
Twitter Feed
Sponsored Live Streaming Video
Everything You've Been Told About Mobility Is Wrong
Attend this video symposium with Sean Wisdom, Global Director of Mobility Solutions, and learn about how you can harness powerful new products to mobilize your business potential.
Sponsored Video
Flash Poll