Network Computingwww.networkcomputing.com

Chances are good you're dealing with hostility and confusion from senior management. Promises and predictions haven't come true. Who's to blame?

There are budget and staff cuts, the first place to go when stanching red ink. And cost justification is suddenly a stiff requirement -- not just for future purchases, but often for past expenditures audit-style.

You're probably also dealing with a communications breakdown with senior management. Business strategy has turned from proactive product development to survivalist tactics, which cuts IT and IS executives out of the loop. To top it all off, you have to accept that much of your company is convinced that the New Economy was nothing but a myth to begin with.

For those CIOs who are still employed, all of the above are tacked on top of extreme pressure to finish or fix the existing product or service, add new value to it to compete and do both in record time. The goal is to capture market share and keep the venture capitalists from giving up. An e-business's lifeblood is its technology, and most of us are shocked at how few technology managers have realized this.

But once you have figured this out, it's time for more than an attitude change; it's time to re-evaluate your approach to the job.

First things first: The New Economy is a myth -- at least as it's been described until now. There is value on the Web, but the same rules of return apply as in brick-and-mortar businesses, chief of which is that you don't build success overnight. Amazon.com, Yahoo, Pets.com and the rest invariably followed the clear historic gold-rush pattern: a boom that is followed closely by a crash. Yeah, there are a couple of overnight winners, but more than a couple of people have won the lottery in New York this past year, too; that doesn't make Lotto tickets a viable retirement plan. IT executives need to face the fact that building value on the Web is just as time-consuming and difficult as it is in the land of brick and mortar. Then they need to educate their bosses to this fact as well.

Does that mean that e-commerce has no idiosyncrasies when compared with analog commerce? Heck no, that's what makes the thing so difficult. E-commerce is definitely its own animal, and IT executives will need to learn to ride that animal if they want to survive. This discipline has been termed BTM (business technology management) ^*, also called BITM (business information technology management).

Business Technology Management 101

The most noticeable BTM evolution needs to occur at the CIO and IT VP level. Until now, navigating the requirements of this job has been more art than science, and let's face it: There are damn few talented artists out there. BTM seeks to address this problem by outlining core management issues that need to be tackled at a senior level to ensure the success of an e-business venture.

What makes an e-commerce technology executive pop so much Advil is that e-business has three unique difficulties: First, it's fast -- not necessarily in returns, but in market conditions, competitive advancements and a never-ending stream of new technology platforms that may or may not put your application in front of the pack. Second, e-commerce is expensive to build, which is far harder to justify today than it was just 12 months ago.

Third, and critically important, e-commerce is usually segregated from the rest of the enterprise, and that can prove fatal. Technology in many businesses is still viewed solely as a resource, a necessary cost center. Technology management executives in these companies are cut off from frontline business strategy and relegated to a passive, reactive role.

Unfortunately, because many IT executives come from old-fashioned brick-and-mortar businesses, where technology segregation has always been the rule, they simply accept the practice without question. They even go so far as to dismiss alternative, forward-thinking management practices as pipe dreams or unrealistic academics. If you take nothing else from this article, take this: Finding ways to incorporate the right technology in an e-business is absolutely mandatory to its success.

Standard Product-Development Process Click here to enlarge

Senior IT managers who are waiting for their business-side counterparts to solve this problem are waiting in vain. Implementing technology matches to business requirements is IT's responsibility, but finding those matches is your job as well.

Ignoring this disconnect hurt IT even before the New Economy did a face plant. In ERP (enterprise resource planning), for example, millions of dollars were spent on a technical vision that embodied platform unity above everything else. Only after development and during deployment did traditional ERP customers realize that marrying their specific businesses to these high-priced wonder tools was incredibly difficult.

Enter BTM. The name says it all, business and technology under a single management umbrella. The goal is to employ technology and communication strategies to:

>>  Enable IT and business strategy executives to speak a common language, share common goals. One e-business, not two halves held together by quarterly meetings.

>>  Make sensible spending decisions based on tangible business needs rather than fuzzy IT interpretations. Buy stuff you really need, not stuff you only think you might need.

>>  Use technology and technology processes to reduce delivery and cycle times, manage costs, increase product quality and, most of all, find and exploit innovations to add competitive value. Use technology to make your job easier, build the best widget you can build and build it better than the other guy.

The mechanics of BTM boil down to communication, business understanding and team building.

The communication lapse between business and technology is a chronic problem. Processes were invented in brick-and-mortar businesses to deal with this. If you were developing a new software application five or more years ago, for example, you'd have most probably followed a development cycle as shown in "Standard Product-Development Process," above. Most of us are familiar with this chart and know that it's really about groups of product managers and developers throwing huge documents at each other until someone finally says, "Stop" and coding begins.

This isn't a bad process, but it is time-consuming and isolates technologists -- especially network technicians and programmers -- from the rest of the business. They live by these documents and nothing more.

This has been tried in e-business.

Take the fictional example of D-Trust National Bank, which is building a Web front end for consumer bill payment. The bank is building this application because both its competitors and new e-business upstarts, like PayMyBills.com, are using this technology to eat its lunch. The bank needs its own offering in this space now.

Product managers sit down and conduct workshop meetings and research plans to develop business cases, business requirements and functional specifications. This can take from one month to six months. Developers are somewhat involved during the functional specification stage but don't really get involved until the technical specification stage. The critical part here is when the technical specification is built, and product management needs to reconcile this with its functional specification. Screw up this part of the process and your developers will build a perfectly functional application that doesn't meet your needs -- and it won't even be their fault.

Now imagine there is a screwup: Your bill-payment application can't handle credit-card payments while all your competitors can, simply because the functional specification failed to mention it. These product managers typically will wait until after the first release of the faulty product and then follow this up with a 1.5 release that can handle credit cards. Meanwhile, the business has suffered because what was already a slow process was made even slower through bad communication. The product that management thought it could sell in six months now takes a year.

While D-Trust may be larger and better funded than PayMyBills, its size is actually a disadvantage in the e-business arena -- lots of employees coupled with existing processes and a resistance to change. BTM in this case needs to start at the senior management level, where executives must realize that this application is entrepreneurial in nature, not merely another service offering.