counterintuitive management of information technology

Counterintuitive Management of Information Technology

Bruce Johnson, Walter W. Woolfolk, and Peter Ligezinski

B ecause information system technology (IT) affects all areas of an enterprise, misconceptions about it can have broad

and unpleasant consequences. John Whitmarsh (1995) and others quote disturbing statistics pro- vided by the Standish Group International. Defin- ing a successful computer application development project as "one that is delivered on time, on budget, and with most of the features as origi- nally specified," and a failed project as one that has been canceled or that is known as a "runaway" (100 percent over budget and with re- duced features), they reported the success rate in Fortune 500 companies at a shocking 9 percent. Among companies with annual revenues exceeding $100 million, a 31 percent cancellation rate and a runaway project rate of 53 percent were reported.

Given reasonably good information, most managers do make good decisions. But when the results have been consistently poor, as in the last three decades of business system atttomation. there is something wrong- -no t with management, but with the underlying assumptions.

When we consider the general state of long- term dissatisfaction with IT, it makes sense to expose major misconceptions, or myth& and to set against them perhaps less appealing but more realistic conceptions of how IT systems should be built and what characteristics they shoukt pos- sess. For in the projects alluded to above, under- taken to implement business changes, the systems themselves underlie the failures by resisting change.

We propose here a new set of assumptions centered around built-in flexibility, on which decisions can be based that will no longer perpetuate IT systems that impede change. Before discussing specific IT management myths, however, three background topics need to be consid- ered together briefly: the real world, artifact world concept, the economic consequences of system

maintenance, and the relationship between change and flexibility.

Real World/Artifact World

A computerized information system can be viewed as a representation of a real world system. It is, relative to the latter, an artifact, or an artifact world system--a

Some IT mistakes have been made so often, and for so long, they've become mythical.

term we will find convenient in this discussion. System development is thus a series of transformations: from the real world system to a model of the real world system (analyze), from the real world model to a model of the artifact world system (design), and from the artifact world model to the artifact world system (build).

Real World ~ Real Workl System Model

A nal.rze Desl}gPl

Artifact World ~ Artifact World Model ~ System

BuiM

These transformations taken together syn- chronize the functionality of tile artifact world system with that of tile real world system. When the real world subsequently undergoes some change in functionality, the artifact world system needs to be resynchronized with it or else fail to continue to be useful, k~k" will say that the real world cha~;ges, while the artifact world is modified. For example, the requirement for a new type of payroll deduction in the real world payroll system means some corresponding modification must be made to the artifact world automated payroll system.

The common IT terms for synchronization anti resynchronization arc .~l'stem clevelopJ~wJH

Counterintuitive Management of Information Tcchn()lt>gy 29

and system maintenance. The latter repeats the t ransformat ion s teps of the former, but it starts with a changed real wor ld system, analyzes the change in the context of the exist ing artifact wor ld system, and des igns and bui lds a modif ica- t ion to the artifact wor ld system.

It is a c o m m o n IT m a n a g e m e n t myth that system d e v e l o p m e n t holds p r imacy in IT success. Over the life of an information system, however ,

Character is t ics o f F lex ib le S y s t e m s

The actual implementation of flexible systems is very much a technical matter, even in principle. The following is a partial list of characteristics of flexible systems, expressed in both technical and nontechnical terms. If your system has most of these, it gets at least a "B+" in flexibility. In evalu- ating an existing system, a manager can direct attention to these characteristics, but it will require technical staff to physically assess some of them.

• Does the system directly access the same sets of physical data files for information on customer, product, personnel, and so on as do other related systems? Do any data need to be entered more than once? In other words, does a person's hire date need to be entered into payroll, into personnel administration, into benefits administration, and so on?

• Can employee, manager, beneficiary, and so on be represented as subtypes of a generic "person" entity such that new subtypes can be de- fined by end users without programming intervention? Can the same be done for other basic business entities--organizational subtypes, accounting subtypes, product subtypes, etc.?

• Is the underlying physical associa- [:::::::::x:x:~ f g - - ~ tion that has been set up in the database between any two or more business entities many-to-many? Can a person who has one job in the company today have two or more simultaneously tomorrow without reprogramming?

• Are the identifiers used in the database for recording associations among business entities (product ID, person ID, and so on) automatically assigned by the system? Are they completely without any embedded information? Are they assigned so that a person ID value cannot be the same as a product ID value, a customer ID value, and so on?

• The bill-of-material structure is traditionally used to describe product structures. Is the same bill-of-material approach available to end users to describe the organizational structure, the chart of accounts structure, and so on? Can these structures be interrelated and used by the system in inventory. and financial reporting, so that a change in organization, for example, is automatically reflected in inventory, cost, and revenue for each relevant organization component?

• In general, can anything that has changed in the past about how the company does business be changed now in the system without reprogramming? That is, can such changes by made by end users manipulating data, rather than by programmers and database administrators manipulating programs and file definitions? Has the product line changed? Has the back- order policy changed? Have payroll deduction types changed? Has the chart of accounts changed? Have the tax regulations changed? Has the organizational structure changed?

• Can the basic association rules of the business be changed by end users? If the system enforces the rule of one person/one position today, can it be changed to multiple positions (multiple salaries, multiple supervisors, etc.) per person or to multiple persons per position (job sharing) tomorrow without reprogramming?

main tenance , not deve lopment , is the main work. And within main tenance , resynchronizat ion, not error correct ion ("debugging") , is the dominan t activity.

D e v e l o p m e n t Dr ives t h e Budget , But t h e M o n e y Is Spent o n M a i n t e n a n c e

Resynchroniz ing a system is even more difficult than bui ld ing it in the first place, po r t end ing a resynchroniza t ion success rate of even less than the 9 pe rcen t r epor t ed by the Standish Group. Moreover, p rog ram code modif icat ions tend to in t roduce errors, and adding error correct ion to resynchroniza t ion s imply c o m p o u n d s the diffi- culty and the costs.

For each dol lar spent on deve lopmen t , 20 cents typical ly goes to opera t iona l costs and 40 cents to nondiscre t ionary main tenance annual ly for the life of the system. This reduces the resources avai lable for n e w deve lopment . Peter Keen (1991) demons t ra tes the effect of this ero- s ion of d e v e l o p m e n t resources in four f ive-year scenarios:

1. Given a constant IT budget , d e v e l o p m e n t will be cut by 93 percent .

2. Given a level d e v e l o p m e n t budget , devel - o p m e n t will d rop from 25 to 18 percen t of the IT budget , which will g row 15 percent .

3. Given a d e v e l o p m e n t budge t increased by 10 percent annually, d e v e l o p m e n t will d rop from 25 to 20 percen t of budge t whi le y ie ld ing 18 percen t IT budge t growth.

4. Given a d e v e l o p m e n t budge t increased by 20 percent annually, d e v e l o p m e n t will stay at 25 percent of budge t while the IT budge t goes up 108 percent .

C h a n g e o r Die vs. Modi fy a n d Die

Real wor ld systems must change or they will die. However , most artifact wor ld systems are so brittle that, when modif ied, they die anyway, unless costly l i fe-support measures are taken. Tht' artifact workt system ideally must be as flexible as the real wor ld system it represents in o rder to live into tomorrow. In 1990, Inves tment Trust Bank AG in Vienna incorpora ted approx ima te ly 30 work processes into an au tomated system. Since then, more than 170 processes have been inc luded in the system, requir ing more than 2,70(I modificat ions. The modif icat ions are made not b'~ IT profess ionals modifying p rogram code, but by special ly t rained and des igna ted system end user : who maintain the control data that def ine the work processes . The bank ' s original requirement, , were not detai led; instead, the system deve lop - ment effort concen t ra ted on achieving flexibility. Dynamic p rograms were des igned to process e lementary act ions that cou ld be a d d e d or modi-

30 Business Horizons/March-April 199

fled independently of existing code by manipulating the control data. Due in large part to this adaptability, the bank has enjoyed an enviable record of rapid response to challenges, market opportunities, and changing regulatory demands.

These 2,700 modifications required 24 worker-months of effort over three years. Based on the original development effort of 140 worker- months, traditional resynchronization using Keen's figures would have taken approximately 168 worker-months--more than the cost of the original development. The bank's experience illustrates that artifact world systems can be designed to facilitate their resynchronization with unanticipated changes in the real world systems they represent, thereby enabling the enterprise to break out of the fatal economic embrace that erodes development resources, pushes IT bud- gets ever higher, and inhibits change in the enterprise itself.

MYTHS AND REALrrIEs

L et us nov," consider some of the more pervasive and persistent misconceptions about IT that have led to such problems

as failed and runaway projects and the severe maintenance burdens presented above. We shall contrast them with their ultimately more manage- able realities.

Most o f the S y s t e m ' s Life Is in T o m o r r o w

It is more costly to modify a computer system at the back end of the system development process than at the front end. It takes more effort to modify computer programs and file structures than to modify design specifications, and more effort to modify design specifications than a requirement model. From this fact. a fundamental misconception has arisen that high system maintenance costs are largely due t() imprecise requirement determination {analysis) at the front end of the process:

"We're spending a lot of money changing this system because we didnt get all the requirements right at the beginning. ~Z ~ need more exact requirement analysis in our ,;ystem development method"

This is the myth ofpe~.'fect knrm'led, e.e at work: • Myth: With enough effort, we can attain

essentially perfect knowledge of a system's rc- quirenaents.

• Reality: The real world changes, so knowledge of a system's requirements is necessarily imperfect because significant parts of the requirements lie in the future and are not available at the time the automated system is developed.

This myth has led to the industry-wide focus on improving requirement determination methods and the corollary myth of methodology..

• Myth: Good methods will produce good systems.

• Reality: Good methods can and do produce bad systems, when the system perfectly fitted to current requirements cannot be efficiently adapted to unanticipated future requirements.

Given these myths, as future requirements arrive they are viewed as "missed requirements" whose incorporation into existing software is disruptive. This means we must rely on techniques other than improved requirement determination. As Fred Brooks (1987) states in his fa- mous "No Silver Bullet: Essence and Accidents of Software Engineering," it is basically a wrong assumption that a satisfactory software system can be specified in advance. The fact of imperfect knowledge of requirements should alter the development objective fundamentally, from achieving functional accuracy in representing current requirements, to providing adaptability to functional change--flexibility.

Reliance on ever more refined system development methods has increased in order to improve the precision of requirement elicitation. There has also been a corresponding emphasis on method automation, referred to as computer- assisted system engineering (CASE), to improve the speed with which requirements are recorded and transformed into computerized systems. The reality, however, is that methods produce what they produce, and good methods simply do so more efficiently or reliably. Systems developed with such great precision and efficiency can still be ruinously expensive to maintain. The focus on accuracy today has virtually no affect on synchronization with change tomorrow. The problem is not precision: the problem is change.

Managers must insist on their staff making and keeping this distinction clear--first, what are the system's characteristics to be achieved, and only then, secondarily and derivatively, bou' are those characteristics to be achieved.

All Things Fast and Faster

As tile pace of change in the real world speeds up. the reaction has been to speed up the pace of computer system development. The belief that it is better to go faster is the myth of rapid application development (RAD).

• Myth: The race against change is won by going faster.

• Reality: It's not a race: it's a dance. This myth results in applying method-oriented

solutions to an outcome-based problem. The result of rapid, streamlined development of new

Counterintuitive Management of Information Technology 31

systems (or more often, replacements for old systems) is simply inflexible systems developed faster. The erosion of development capacity by maintenance is accelerated as development is accelerated. Everywhere the backlog of maintenance is increasing, often reported as requiring 80 percent of IT resources. In fact, if unexpressed demand is taken into account, we would find in many installations a maintenance need exceeding 100 percent, wherein all resources could be de- voted to maintenance and the backlog would still be increasing. Rapid application development worsens the problem because the point of de- creasing return on IT resource investment arrives much sooner, and attention is diverted from solv- ing the real problem--the maintenance burden created by inflexible systems. Nor are rapid development techniques transferable to the maintenance work itself. An existing inflexible artifact world system is not a green field amenable to fast footwork. It is more like a minefield requiring extreme care in moving about. Rapid application development, assuming it truly speeds up development and/or reduces its cost, can only be applied to the 40 percent (or less) of IT that is development. It cannot be applied to the 60 to 100 percent that is maintenance--where the real leverage is.

Managers must stop paying homage to rapid application development. RAD is flashy, but it's not where the real payoff is in terms of the development/maintenance cost ratio.

Integrate vs. Interface

Fixing managers' attention on rapid development has also fostered the myth of the isolated sl.,stem.

• Myth: We'll develop the new project control system initially for the engineering depart- ment. Then, as we get the requirements from

Civil Software Engineering

At one time, Civil Engineers specified exactly how contractors were to build a highway. The contractor was told what method to use: the type of machinery, how many passes to make with the roller, how many layers of fill, and so on. Eventually, contractors and engineers agreed that this approach was not achieving the desired results and was stifling innovation and creativity at considerable cost to the industry. For a time, debate raged between proponents of the "new way'' and those of the "old way," but the debate is long since over. Civil Engineers now specify the characteristics of a good highway, and contractors determine the best ways to produce the desired outcome. Continuous improvements are now made independently in both construction methods and design. By contrast, the software world is still in the pre-debate stage over method versus outcome.

other departments, we'll evolve the system and roll it out across the company. This evolutionary approach will be cost-effective and will not commit us to too big a development piece at any one time. We can develop systems one at a time and fit them together into an integrated whole as we go along.

• Reality: We can build an organization's systems one at a time, but the underlying information structure for all the systems must be ana- lyzed and designed first if integrated systems are to result.

This myth sounds sensible, and information processing can be evolved in this way. But the underlying information structure cannot. If a system is to really serve multiple concurrent requirements from different departments, or to integrate with other systems, the information structure must be worked out in advance and held constant. Thus we have a seemingly contra- dictory principle: A flexible system requires a stable structure.

When real world systems work together suc- cessfully, they necessarily share a common set of factors. The products Sales sells are the same products Manufacturing makes, and for which Accounting accounts. This applies to all the real components of a business. The artifact world systems of an organization work together best when they share a common information structure. This means the information about any real world component of a business has the same meaning and is found in the same logical place and identified in the same way by all the artifact world systems concerned with that information.

Such system ensembles are integrated systems: they share a common semantic framework. This is in contrast to systems that use separate information structures and can be made to work together only via interfaces--specialized sub- systems that extract and convert data from one semantic framework to another. Many collections of aut(mlated applications are billed as integrated but are actually interfaced. Even when the application systems in a packaged set all come from the same vendor, they are not necessarily (and not usually) integrated. It is misleading and ironic that software companies specializing in providing interfaces for un-integrated systems are referred to as "system integrators."

Tile information structure is the foundation for the infornmtion system's processing, and cannot be modified to any significant degree without grossly disrupting that processing. It is in the nature of artifact workl systems that a small and apparently local modification to the information structure can result in a global disruption of the processing that relies on that structure. Modifying the structure is equivalent to changing the foundation of a building after it has been built.

32 Business Horizons / March-April 199'

It is vital to note here that the kinds of struc- tural modifications that can devastate a conven- tionally developed system are equally disruptive to an object-oriented system. Neither stable reus- able elements nor design for flexibility is an auto- matic result of the object-oriented approach.

Managers must stop considering systems in isolation from each other. Instead, they should focus on establishing a single coherent information structure for all the essential business functions, then fitting systems onto that stable foundation.

Use It or Lose It

Change tends to upset both people and information systems. Thus, managers are often uncom- fortable with change. This yields the myth of the successful system.

• Myth: Successful computer systems generate few, if any, modification requests.

• Reality= Successful computer systems usually generate continuous demands for modification.

Often the unsuccessful system is mistaken for a successful one and vice versa. The system that produces unused results does not engender requests for it to do more. On the other hand, the system that is really being used effectively has end users (customers) who continually say, "If you can produce my design report, why can't you also calculate shop times?" And once that has been done, "Why can't you make material order lists by supplier?" Because such systems are "never finished," they are often looked upon as failures. It is a counterintuitive managerial truth that being bugged for money and resources for modifications is really a sign of a successful, rather than a failed, system. (Being behind in providing such requested modifications is a sign of an inflexible "successful system.")

Managers need to establish a system's "success metric" that includes the level of usage and modification requests by system customers.

What D o They Know?

System customers generally perceive that the level of effort needed to make system modifications is out of proportion to the change requested.

"All I wanted was for the system to re- flect that now one person often holds two jobs. What's the big deal? How can it take six people six months? What do you mean you have to modify the information structure? And what's to test? You keep talking about all the testing that will be needed-- i t ' s just a simple request!"

This is a frequent scene in the experience of IT managers, from which has come the myth of the naive customer.

• Myth, Customer perceptions of what it should take to implement system modifications are grossly unrealistic; they do not appreciate how complex automated systems are. So IT managers need to educate customers in this matter.

• Reality: Customer perceptions of what ought to be the case are realistic. What they do not perceive correctly is the inflexibility and fra- gility of current systems. IT must learn how to develop flexible and stable systems.

In one sense, the customer's feeling for the size of a modification is not realistic. IT customers generally do not appreciate the internal com- plexity of their computer applications. And when a large estimate is made for what seems to the customer to be a small modification, the estimate more or less accurately reflects the size of the work, not the size of the request. But despite efforts to educate customers about system com- plexity, the discrepancy between the customer's intuition and the current reality persists. After all, the customer deals with the real world system and is an integral part of it, while the computer application is only a representation of (part of) the real world system. Consequently, there is an almost inescapable apprehension on the customer's part that the effort required to modify the computer system should be approximately the same size, if not smaller, than the effort ex- pended on the real world system to implement the same change. In this sense, the customer's intuition should be right, particularly when the modification seems unrelated to the size of the system. This is much like adding toll booths to a br idge-- the cost of the toll booths should be independent of the length of the bridge.

Managers must stop trying to educate customers and focus instead on building systems consistent with the customers' accurate sense that modifying the automated system should be no harder than changing the real world system.

Accidents o f History

Consider the case in which an existing artifact world system is, for whatever reason, to be re- placed with a new one. Management's desire to completely understand the existing system leads to the myth of retroactive documentation.

• Myth: The most important step in developing a replacement system is to "document the existing automated system."

• Reality: The existing real world system is usually distorted by the presence of its entrenched automated component.

When an artifact world system has been in place for some time, it usually represents past


versions of the real world system--i t is literally an accident of history. More important, as it has fallen farther out of synchronization over time, it

"The problem~solution perspective plays the vendor's game. It fosters viewing the customer/ vendor relationship as patient~doctor rather than as buyer~seller, "

has increasingly over- constrained the current real world system, which must be bent in various ways to circumvent the limitations of the automated system. When coupled with frequent breakdowns of the automated system during modifications, the resulting unpredict- ability leads to fear of the system a n d an un- derstandable reaction to

counter this by completely understanding the old system before attempting to replace it.

Managers must realize, however, that documenting the existing system will perpetuate the distortions into the next generation. Instead, they should insist on documenting answers to the questions: What are the requirements, given today's technology and our proprietary knowledge? How should this business function be done now and in the foreseeable future?

Doctors and Patients

A current perspective, popular with those who must sell software, promotes the myth of the solution.

• Myth: Information systems are solutions to business problems.

• Reality: Information systems simply offer fast, cheap, and accurate automated assistance with business functions.

This misconception leads to a variety of ills, such as building systems for processes that don't exist and misleading people about the disposition of their real business problems.

To what problems do vendors of IT systems have the solutions? There is a widespread prac- tice of using "problem" to refer to any real world process that is a candidate for automation assistance, and of using "solution" to mean any artifact world system. Tile initial usage began in packaged system sales and advertising as a ploy for reaching businesses that described their need for better information processing as a "problem": "The problem is to get receivables in the bank sooner." "The problem is the expense of keeping the catalog current for 9,000 products." "The problem is errors in recording service calls."

What's wrong with this perspective? 1. When there is actually a problem other

than speed and accuracy--when the business system is doing the wrong thing-- the problem/

solution view promotes the automated system as the solution when the business system itself really needs attention. Automating a dysfunctional process will not fix it.

2. When there is no problem other than speed and accuracy--when the business system is doing the right thing-- then the problem/solution view promotes inappropriate automation directions in which the automated system is used to leverage "improvements" that are not part of the business system.

3. The problem/solution perspective plays the vendor 's game. It fosters viewing the customer/vendor relationship as patient/doctor rather than as buyer/seller.

Most business systems can be improved func- tionally, but it is important to first understand and commit to the change in the system, then implement or modify the automation accordingly. Ear- lier we contended that when processes are accidents of history we don't need to know how they are done - -bu t we do need to know how they shouldbe done to meet today's requirements and exploit today's technology and expertise. Busi- ness process reengineering considers automation an essential enabler without which new process designs are often impractical.

A better approach is to think of the problem as an opportuni ty--which of course it is. Remem- ber, the Japanese say, "A defect is a treasure." Such a perspective has many advantages, including helping people see new ways to run the business based on "automation opportunities." For example, there is a great difference in end results between (1) developing an automated order ful- fillment system and reorganizing the customer service, credit management, and other departments around it, and (2) developing a redesigned business process for order handling in conjunc- tion with new or modified automation assistance to enable its success. In the first case, the focus is on the automation; in the second case, it is on the business process.

Managers need to mentally substitute the concept "'automated assistance" every time they hear or read a reference to a system as a "solution" when considering system investments.

Apples and Apples

The off-the-shelf purchased package almost al- ways fails to integrate with other systems, even in the case of a set of related systems from a single vendor. If, despite this, a packaged system is to be purchased, then take care not to fall prey to the myth of comparative evaluation.

• Myth: The best product is chosen by comparing candidate products to each other

• Reality: The best product is chosen by comparing candidate products to requirements.

34 Business Horizons / March-April 199'

Yes, this is obvious, but the myth persists, so it's worth a reminder. Don't compare apples to apples; compare them to a description of the apple you need. Also, having the requirement specification first---one that includes flexibility-- is a strong aid to keeping the buyer/seller relationship clear. The following highlight adapted from our case study of Hipublishing Company demonstrates the apples-to-apples folly:

When a new IT manager was hired, his first priority was to tackle the monthly business disruption caused by Hipublish- ing's outdated and quirky accounting system. He attempted to form a team to determine the capabilities required for an up-to-date system for the company. Un- fortunately, the accounting personnel were unavailable for this because, when they were not absorbed by the month- end panic, they were traveling around the country attending demonstrations of packaged accounting systems. Over the manager 's objections, a feature-rich "best of breed" accounting package was purchased and installed. Once in operation, it was apparent that certain functions vital to the company were missing or deficient, and several other functions were superfluous to the business but required considerable resources to maintain.

At last count, the description of the apple that was required had not been prod0ced and the accounting staff had even less time to work on it.

Managers must actively prohibit "system shopping" without a shopping list.

Who's Minding the Store? Abdicate vs. Manage

There is a strong belief that by washing our hands of IT issues and turning them over to outside experts, effective IT systems will painlessly appear. This is the myth qyoutsourcing.

• Myth: We can hire :m outside firm with the appropriate expertise that will man:tge our information technology cheaper and better. Then we w o n t have the management headaches.

• Reality: It's your business, you nlust inan- age it--including the IT component.

The transformation processes leading to successful IT systems require diligent effort, proper proiect management, and just plain hard work by management, system customers, and IT profes- sionals alike. This fact of IT lid cannot be stressed enough-- there is no way around it. Often, one or more of these groups try' to circumvent the effort by outsourcing the project. At the very least.

project management responsibility must be re- tained internally. This is true even if the bulk of the development work is done by people outside the firm and regardless of whether custom or off- the-shelf IT systems are used.

Managers must not abdicate to marry Mrs. Simpson.

We T h i n k Alike

In the workaday pressure to get things done we often fall victim to the myth ofparallelpercep- tions.

• Myth: Managers, customers, and IT profes- sionals have shared perceptions of the business, the technology, and their interface.

• Reality= Managers, customers, and IT pro- fessionals speak widely different languages and have different views of both real world and artifact world systems.

This myth is different from the others we have examined, because it is what can be called an "enacted myth." We talk as if we understand that there are serious communication problems among managers, customers, and IT profession- als. But we do not walk the talk during the chaos of daily business.

In designing a system to assist with elec- trical construction, an analyst encoun- tered the following situation. "We need long descriptive wire names," one of the engineers said. "How long-- twenty or thirty, characters?" asked the analyst. "How would I know? They need to be long and descriptive," replied the engineer. This dialogue (two monologues?) went on without resolution for some time. Finally the analyst produced some sample reports with wire names. When they got to the wire name "CONNECTOR BETWEEN AIR CONDITIONER AND EXHAUST FAN IN THE WOMEN'S WASH ROOM ON THE SECOND FLOOR NORTH WEST CORNER." the engineer said. "That's too long!"

The real world and business world models are models of perceptions. Moreover, they are someones perception of what is necessary and important to transform business requirements into the computer 's terms. Compounding this situation, the implementation is based on the inlplementer's perception of the designer's perception of the customer's perception. This is where the methodological approaches do make a valuable contribution.

Managers must consider adopting the Zach- man (1987) framework, which helps ensure that the fidelity of the requirement model is sustained


as it passes from one conceptual realm to another in the system development or acquisition process.

A s business moves onward, requirements change. But managers' reactions to change when it comes to IT have some-

thing of the nature of bipolar manic-depression. On one side we are panicked into ever more de- tailed requirement analysis and ever more rapid system development faster, faster! On the other, we are lethargic and dopey about building flexibility into the systems themselves--but, but! The ironic result is the rapid creation of artifact world systems that become impediments to change. The severe financial strain of the growing maintenance burden will continue until general, line, and technical managers "get real": in other words, adopt the counterintuitive realities that dispel the my- thology.

Our purpose here has been to raise management consciousness, not to provide a technical tutorial on flexible system design. Some excellent techniques for increasing system flexibility have been developed, such as those employed at the Investment Trust Bank. Their application to systems today and the development of more in the future are a matter of intention--the intention on the part of IT and general management to demand that flexibility be realized.

References

F. Brooks, "No Silver Bullet: Essence and Accidents in Software Engineering," Computer, April 1987, pp. 10-19.

P.G.W. Keen, Shaping the Future: Business Design Through Information Technology (Cambridge: Harvard Business School Press, 1991).

J. Whitmarsh, "Letter from the Editor," Cbieflnforma- tion Officer, November 1995, p. 10.

W.W. Woolfolk, P. Ligezinski, and B. Johnson, "The Problem of the Dynamic Organization and the Static System: Principles and Techniques for Achieving Flex- ibility," Proceedings of the 29tb Annual Hawaii Inter- national Conference on System Sciences (HICSS-29), 3 (1996): 482-491.

J.A. Zachman, "A Framework for Information Systems Architecture," IBM Systems Journal, 26, 3 (1987): 276- 292.

Bruce Johnson is a consultant and a retired associate professor of information and decision sciences from Xavier Uni- versity in Cincinnati, Ohio. Walter W. Woolfolk is MIS Director for the Taylor Distributing Company, also in Cincinnati. Major Peter Llgezinskl is the director of information technology systems for In- vestment Trust Bank AG, Vienna, Austria.

36 Business Horizons / March-April 1999

counterintuitive management of information technology

Documents