A CEO demands dramatic change. A CIO responds. An uncomfortable silence descends

An exercise in mutual frustration is being repeated in boardrooms around the world. It plays out as follows: a CEO demands dramatic change. Within two to three years, he argues, the company must cut its time to market, boost efficiency, and offer more customized service. In all of this, of course, new information systems will play a crucial role. But the head of Information Technology—the CIO—responds to these proposals by explaining that the required systems changes cannot be completed in less than five to seven years. When questioned, the CIO also admits that the new systems will not be any easier to change than the existing ones. An uncomfortable silence descends.

It is no wonder that CEOs are frustrated: CIOs seem permanently in study mode. Adrift in the possibilities of their profession, they endlessly draft business process redesigns, "re-invent" the corporation, fly to priority-setting meetings, and benchmark the competition. Somehow—amid all this activity—not a single line of durable code gets written. And not a single concrete deadline gets committed to, let alone met. How can I, each CEO wonders, make these people do some real work?

The CIOs, however, are just as frustrated. Neither business nor marketplace nor organization structure nor strategy stands still. Worse, CEOs seem never to make up their minds. Moreover, they change frequently, as do other members of senior staff. Thus, as soon as a system is finished, some new initiative calls for rebuilding part of it. And as soon as any IS department builds up a programming team capable of handling this kind of workload, budgets get cut back. How can I, each CIO wonders, make these people figure out what they really want?

Bridging the gap

Across this gap of mutual incomprehension, CEOs keep pressuring the CIOs—putting them on the spot in meetings, challenging their budgets, questioning their technology choices—because that is the only way they know how to get results instead of studies. CIOs, in turn, keep launching systems studies and process redesign projects because that is the only way they know how to identify business priorities. Allowed to fester, such incomprehension transforms information technology from a prime agent of corporate renewal into a bottomless pit of frustration.

Paralysis follows. IT might reduce time to market, but only if a company can wait five to seven years. New systems might increase flexibility, but only if someone can figure out in advance what sorts of decisions managers will be making years hence. Caught between immovable demands and irresistible delays, IT-related projects stall. As a result, user groups usually take matters into their own hands. Inevitably, this means that technology proliferates, costs escalate, and the quality of corporate information deteriorates.

Communities of interest

The foundations for a new and far more productive relationship between CEO and CIO already exist—if both come to share a mutual commitment to action

It does not have to be this way. Tapping the promise of information technology need not be one of a CEO’s most frustrating challenges. The average tenure of CIOs need not be only a couple of years. The foundations for a new and far more productive relationship between CEO and CIO already exist. Indeed, as a handful of leading-edge companies have shown, new attitudes toward systems development can repair the broken dialogue between them. But both have to be willing to change.

Both must, for example, come to share a mutual commitment to action. Many CEOs, for example, have learned to acknowledge the necessary speed and unavoidable risk involved in leading their organizations through a process of major change. Few CIOs have done the same. Most still think of themselves as engineers, whose disciplinary training tells them that painstakingly careful study of a problem is almost always rewarded by more effective systems design and construction.

Unfortunately, the painstaking study of IT-related issues is usually punished by irrelevance, not rewarded by effectiveness. At the same time, of course, building systems too quickly, without reasonable design and strong "plumbing," is a waste of time and money. To be sure, building systems quickly is risky, but building them over anything more than three to four years carries the near certainty of failure. The business world—unlike the geology of a dam site—changes so quickly that any project not carried rapidly to completion will be outpaced by changes in the business, in the technology, or both.

In this kind of environment, CIOs must play a pivotal role in helping their companies bridge the gap between fast-changing business needs and technology. CEOs, in turn, must try to bridge from their end by asking the right questions and by making tough decisions. A CEO, for instance, must insist that the CIO deliver both IT plans and concrete action within a business-relevant horizon. But to enable the CIO to meet such time-compressed goals, the CEO must have the courage to join in on critical decisions about technology, to commit to sustained investments in IT, and to work with the CIO to distinguish the durable, long-lasting aspects of the business from those where competitive success requires continuous, rapid change.

The durable versus the perishable

All companies operate in a "physical" world of things and people, and a "logical" world of accounting convention and corporate organization

All companies operate in two different worlds: a "physical" world of things and people, and an abstract or "logical" world of accounting convention and corporate organization. Things in the physical world are durable; they change relatively slowly. A manufacturer’s physical world includes raw materials, machines, trucks, distribution warehouses, and the like. For a railroad, it includes locomotives, cars, track, signals, and crew. For both, it also includes money—payments and receipts.

Since the physical world—the products, plants, customers, suppliers, and distribution channels—of most companies is fairly stable, it is relatively easy to build transaction processing systems to support activities in it. In practice, systems to track and support activities that can be physically observed and simplified—inventory management, say—can be built in a reasonable time, as well as gradually updated and improved. In recent years, these "real activity" systems have provided most of the enhanced operating leverage from improvements in time, cost, and quality.

By contrast, things in the logical world include almost everything on an organization chart: the number of divisions a company has, the locus of its decision-making authority, and the way it divides up its markets, management reports, and managers. These things are volatile, continuously changing, and, therefore, perishable. From an IT perspective, they must be dealt with differently.

In general terms, two rules of thumb help to distinguish durable from perishable:

• Durable describes things; perishable describes structures. A customer’s store is durable, a sales region is perishable.
• Durable is transaction-oriented; perishable is analytic. Things happen in the durable world. Trains arrive and depart. Money is paid and received. The point of view taken by executives seeking to understand these events, however, is highly perishable—as are their approaches to managing them.

A two-layered world

Properly constructed, transaction processing systems in the durable world provide managers with up-to-the-minute information on what is happening in their businesses. This is quite valuable. Decisions based on what is are inevitably better than those based on what was (as provided by historical data) or on what might be (as provided by forecasts). These systems also help to control increasingly fast-paced actions—for example, linking customers and suppliers for both automated payment and the automatically-recorded receipt of goods.

What such systems do not do, however, is interpret events and actions. They record the amounts of money going into and out of a company, but they do not calculate such perishable things as profit margins or total sales by product. That is the job of a company’s analytic management systems—its Executive Information Systems, its competitive analyses, its calculations of asset utilization, its standard management reports, and the like.

The information needed by a regional manager is different from that needed by a product manager ...

... the information needed by a product manager will itself vary from year to year and person to person

One obvious reason for separating perishable from durable is to avoid unnecessary work when change in organizational structure or management philosophy occurs. The information needed by a regional manager is different from that needed by a product manager. Equally important, the information needed by a product manager will itself vary from year to year and person to person. Even so, the durable, basic facts from which these perishable sets of information are collected remain relatively constant. Why, then, waste time and money to rebuild, as many companies now seem to do, basic fact-collecting systems with every shift in structure, personnel, or market dynamics?

Managers cannot easily consider any analysis that requires data not captured by their IT systems

A more subtle reason for separating physical from logical has to do with managerial continuity and breadth of vision. Today, many companies’ information systems are built from top to bottom (functionally) to produce a particular set of management reports. As a result, managers cannot easily change their points of view without completely rebuilding all their IT systems. Nor can they easily consider any analysis that requires data not captured by those systems. In effect, these systems put silent constraints on the way managers can run their businesses, virtually guaranteeing that their understanding of things will lag behind the dynamics of the marketplace.

To be managerially useful, therefore, an IT system must be able both to handle material from these two worlds—the physical and the logical—in a manner appropriate to each and to translate between them easily and efficiently. The best way to build such a system that we have found is to maintain the data from the physical world in a flexible storage facility so that they can, at need, be cut and sliced in many different ways.

A "data warehouse" contains pertinent summaries of the data collected by a company’s transaction systems

This kind of storage system—what we call a "data warehouse"—contains pertinent summaries or aggregate measures of the data collected by a company’s ground-level transaction systems. At any given moment, the shape of the warehouse reflects the company’s current organization, as well as the structure of its logical thought processes (for example, "cuts" by channel, geography, competitors, customers, products, and so on). Unexpected questions or changes require, at most, that the data in the warehouse be re-summarized, not that the underlying transaction systems be completely revamped.

Done right, separating the durable from the perishable in this way can create systems that are faster to build, cheaper to change, and cheaper to run than most being developed today. One challenge that complicates this task is accurately defining the durable: making such distinctions requires intuition, experience, and industry understanding. And making these distinctions does matter.

Without clarity, either nothing ever gets built because everything feels like it is constantly changing, or what does get built is far too rigid to promote or enable change. The good news, however, is that the necessary expertise can travel from company to company. So CEOs and CIOs can give themselves a leg up by hiring people who have previously built two-layer systems to perform roughly similar functions.

Taming the technology

Conceptualizing future-proof information systems is one thing; building them another. The technology out of which such systems are made changes just as fast as, if not faster than, the management perspectives they reflect. Taming this technology is the CIO’s job. It is also the test of the CIO’s real commitment to action.

To get systems built quickly, CIOs must deploy technologies that they know will be outdated by the time they are put to work

To get systems built quickly, CIOs must deploy technologies that they know will be outdated by the time they are put to work. They may also have to start work on the foundations of a system long before plans for the final stages have been completed. But only by facing these contradictions squarely and steering a steady course through them can they avoid the certain failure that comes with paralysis.

The following four rules of experience can help keep their efforts on course:

1. Use only the technology that is on the market today, no matter how wonderful forthcoming products may sound. Information technology improves by leaps and bounds. No matter how fast the latest computer on the market, something much faster is always just about to be launched. To build the best possible systems—or, at least, to try to avoid building ones that are outdated—it is always tempting to wait a little bit longer for the technology to improve. It is also fatal.

Promised technology often fails to materialize. Even when it does, the temptation remains to delay still a bit longer for some other wonder to materialize that can be glimpsed on the horizon. The only way to get things done, however, is to accept that the foreseeable future in technology stretches ahead two to three years at the very most. So the only sensible strategy is to pick the best technology on the market today—and start building.

2. Focus on a few technologies in order to minimize exposure. Given the exciting array of technologies now available, it is hard not to shop carefully in order to choose the best bits and pieces for each project. After all, careful shopping can ensure the best possible fit between technology and use, and a diversity of technology can provide a hedge against obsolescence. Scatter Macintoshes, PCs, and UNIX computers across corporate desktops, and not everything is likely to become outdated at once.

The problem, however, is that the benefits of diversity are typically overwhelmed by the costs and complexity of keeping different technologies working in harmony. Although a diversified company may have to change only a tiny bit of its systems at any given time, reworking all the connections to all the other tiny bits often takes as much time—and as much money—as changing large chunks of the technology all at once.

Narrowing a company’s "technology footprint" reduces the costs of diversity, whether measured in dollars, time, or quality

Thus, narrowing a company’s "technology footprint" to focus on selected technologies reduces the costs of diversity, whether measured in dollars, time, or quality. In practice, minimizing exposure to excessive diversity requires strong, centralized control over technology choice. This can be unpopular, particularly when some of the choices made by the CEO and CIO turn out, in hindsight, to have been wrong, as they inevitably will be. Yet only firm control over the technologies used by a company today permits CEO and CIO together to manage its evolution toward the technologies of tomorrow.

Some functions get duplicated, in slightly different ways, in almost every application system. This is extremely wasteful

3. Build a technical platform only once. In technology as in business generally, some things are more durable than others. Those that are tend also to be the most widely used. Almost every system now built has to deal with security (to determine who gets to use what), software distribution (to keep systems up to date), configuration management (to make sure the right versions of programs are being used), data access (to enable the right people to get at the right information), and so on. As a result, some functions get duplicated, albeit in slightly different ways, in more or less every application system. There are, for example, nearly as many ways of ensuring that a program and data files are in synch as there are applications developers.

This is extremely wasteful. Instead of duplicating these functions, it makes much better sense to build them once only—and then make them accessible to each application through simple programming interfaces.

One program might, for example, ask for a piece of information like "sales in a given region." A separate program would actually assemble the information from the underlying data warehouse and hand it back. This separation of basic technical services and the applications that use them has several advantages. It makes the development process more productive because developers can concentrate on business problems, not on reinventing technical infrastructure. And it insulates applications from changes in the underlying technology. As long as the interfaces remain unchanged, the applications can remain oblivious to the technical details.

The most subtle, yet most powerful, advantage lies in how an IS department can be structured. Because only a small number of "services" providers need to be experts in client-server technology, the bulk of the IS department can usually be left free to concentrate on solving business problems. This is the magic that will let existing IS organizations step into the new technologies more easily.

Today, a full technical platform cannot be bought off the shelf. True, big chunks of it can be bought, but then experts within each company must place mortar between these building blocks. Having built the platform—a single, stable set of services—once, they can array a broad collection of applications on top of it. The key, of course, is to build the platform, not just study it.

A narrow technology footprint can reduce the pain of adapting to change, but it cannot stop change from happening

4. Anticipate change. A narrow technology footprint can reduce the pain of adapting to change, but it cannot stop change from happening. Since the foreseeable future in technology is so short, both CEO and CIO must prepare for technologies to evolve. The key task here is creating the interfaces that define communications between the various pieces of hardware and software that make up a company’s systems. If there is to be, for example, a central "security" server, what specific requests can other programs make of it?

The more succinct the interface, the easier it will be to "unplug" any given piece of technology and replace it. But even if only a complex interface will do, both CEO and CIO should constantly be questioning the possible consequences of change in their systems—and preparing for them. Preserving applications code is more important than preserving the hardware it runs on.

A steady hand

When it comes to information systems, most companies are on an investment roller coaster

When it comes to information systems, most companies are on an investment roller coaster. Big investments to build new systems are often followed by equally dramatic declines, as investment capital is shifted to other projects. These huge swings in spending cause a variety of problems and keep managers in the IT function continually off balance. They are either scrambling to get enough staff in up cycles or struggling to find enough work for those whom they would like to keep through the downs.

Periodic requests for massive budgets put IT spending at the center of corporate politics, making it harder to evaluate decisions purely on their business merits. Business users, in turn, often get technology in indigestibly large chunks, which, because investment is not sustained, start to become outdated almost as soon as they are finally understood by those who work with them. Moreover, huge, periodic systems investments can make a hefty dent in corporate earnings. Smaller, more regular ones can be taken in stride.

Technology, like most things, is better managed at a steady pace. To eliminate the boom/bust swings in technology spending, CEO and CIO need to begin with a shared, high-level understanding of the company’s information requirements—even if it is based only on back-of-the-envelope calculations. That is the figure that the senior management group should then count on investing. Once the infrastructure is built, only moderate investments of capital will be needed to continually renew those assets going off depreciation. This is a very calculable investment stream. It can be predicted, and it can be known. And it should be.

A performance culture

The right 10 people are worth more than 100 others when it comes to issues of quality or performance

Systems talent varies widely. Just as there are poor teachers and extraordinary teachers, most companies will have a pretty full range of systems leadership and technical skills. Knowing that you have a hundred IT professionals or a budget that is 2 percent of sales is useless information because the right 10 people are worth more than 100 others when it comes to issues of quality or performance.

There is no shortage of systems people. There is, however, a real shortage of extraordinary systems talent with a proven track record and top-level technical skills, business acumen, and leadership ability. Still, in most companies, you do not need that many of them to build a great systems organization. Being able to recruit, retain, and develop the few who are essential must be a priority area of focus for CEO and CIO. This, more than anything else, is the lever that makes the difference between results and write-offs.

Repairing the dialogue

It is possible to make the dialogue between CEO and CIO productive, rather than an exercise in endless frustration. Here is how it can work:

A CEO contemplating major change asks the CIO to deliver an information technology plan within three months. The plan is not—and is not expected to be—a complete "corporate architecture" for every system needed by the company. Though some CIOs will argue that it is irresponsible not to have a top-to-bottom plan before starting work, CEOs will remind them that creating such an architecture can often take longer than building the systems it comprises. Particularly in the fast-changing, perishable realms of a business, valid criteria for choosing priorities include not just "What is important?" but also "What do we know enough about to start work on now?"

The plan will, however, demonstrate why and how the proposed slate of applications supports the company’s business objectives. It will describe the technical platform needed to deliver those applications. It will analyze how the durable aspects of the business can be separated from the perishable. And it will state what resources and financing the CIO needs to deliver everything promised on the plan within three years. Most important, it will provide a schedule for the delivery of each part of the finished system—and a definition of which benefits each will provide, by when.

The CEO needs to make sure that line managers understand—and agree with—the priorities embedded in the plan, and that the CIO has thought about—and is ready to cope with—future changes in the technologies to be used. Further, the CEO has to establish centralized control over technology to make sure that the CIO’s choices can be implemented in a disciplined way throughout the corporation.

In examining the CIO’s plan, the CEO will also want to ensure that the investments proposed are sustainable. Should the plan require a rapid surge in expenditure, which will inevitably be followed by an equally rapid fall, the CEO should ensure that the budget gets recast in a form that provides more stable investments. But if the needed level of investment drops, the CEO should review with the CIO opportunities that initially may have been neglected.

Any plan that calls for a single "big bang" at the end is unworkable; the company will never be able to absorb so much technology at once

In addition, CEOs should expect their IT functions to work on multiple time scales. The general rule is that benefits should be delivered as quickly and as frequently as possible. Any plan that calls for a single "big bang" at the end is unworkable and wrong—if only because the company will never be able to absorb so much technology at once.

That said, however, some of the systems needed to capture the durable aspects of a business may take as much as 19 to 24 months to begin to deliver value. Building the networks, interface standards, and databases to deal with them is hard and time-consuming work. To ease the waiting, the CIO can begin to deliver many of the benefits of data warehouses long ahead of their actual construction simply by taking information from existing applications and making it more available via information-sharing tools. Although such tools will have neither the capabilities nor the resilience of the new transaction systems, they can provide value quickly.

Should the CIO threaten to slip back into the never-never land of study mode, it is up to the CEO to shock him or her back to the real world

CEOs should keep the pressure on. A key question that needs to be asked frequently is, "What’s the progress versus the plan?" Another is, "How many people come to work each day to write code?" In many companies, particularly those with fast-growing IT departments, far too many people are communicating, coordinating, facilitating, and integrating, and too few are doing the work that all the fuss is ultimately about. Should the CIO threaten to slip back into the never-never land of study mode, it is up to the CEO to shock him or her back to the real world. If the expected benefits of the new systems do not appear on time, the CEO will have to find out why.

Ultimately, building information systems that are able to change as fast and as vigorously as the businesses they serve is largely a matter of commitment. Parkinson’s Law states the fundamental relationship between work and time: "Work expands so as to fill the time available for its completion." But it does not say whether that time is long or short. That is for managers to decide for themselves.