The Magic Bullet Theory in IT-Enabled Transformation

It is widely known that many large-scale change management projects involving new information technology (IT) fail for reasons unrelated to technical feasibility and reliability.1 It is also well known that good technology “implementation” and “change management” techniques can substantially increase the chances of success.2 Why, then, do so many organizations fail at IT-enabled transformation? What can line executives and IT specialists do to increase the odds of success?

In fact, there is a lengthy list of good techniques and methods for successful IT-enabled change projects. While we have nothing new to add to this list, we explain why the techniques and methods are not always used, and we challenge common notions about who should use them. In our experience, both IT specialists and line managers frequently have and hold onto failure-promoting beliefs about their roles in change. Success requires different beliefs and team-work in applying the best practices of change.

We view IT-enabled transformation as a business process that crosses several functional lines. Because there are handoffs in the process, some things get done twice, while others fall through the cracks. Even if each function performs its role exactly as prescribed, the outcome may not meet customer expectations for timeliness or quality. And when the different functions do not even agree about who is supposed to do each task, only luck — or magic — can produce good results.

When we examined what many people think about who should do what in IT-enabled change, we found that they seem to believe in magic. The joint efforts of all parties playing their scripted roles do not add up to successful change. Sometimes these people still get good results — by accident — which means that they’re less likely to change their behavior the next time when things don’t go as planned.

In manufacturing, production experts have learned how to achieve better results and just-in-time flexibility by broadening people’s work roles. One strategy combines separate production tasks into the work of a team. Another involves cross-training workers on upstream and downstream jobs. That way, production workers can correct errors introduced by workers upstream and prevent errors that might affect workers farther down the line.

In IT-enabled change, however, the emphasis seems to be on people staying within prescribed roles. Line executives, IS specialists, and other groups are each assigned a role (e.g., process owner, design team member, transition management team member, coach, or implementation team member) with specific responsibilities.3 Line executives, for instance, are told that they must champion change. And IT specialists are told to seek top management support. What happens when any group fails to perform its role is the subject of many horror stories.4

But, in fact, people do not always perform their assigned roles well. Line managers who initially champion IT-enabled change sometimes get cold feet when their subordinates “explain” why the change won’t work. And IT specialists sometimes steer organizational change projects into expensive proofs-of-concept for leading-edge technologies. We’ve found that when these events occur, strong expectations about people’s proper roles in change management often get in the way. Because “it’s supposed to go that way” or “it’s not my job,” people do not see other ways to accomplish the same goals and do not take proactive, effective measures to keep change on track.

The great irony is that failure to implement change can happen even when all parties feel confident that they’ve done their job. The great tragedy is that preventing failure can be relatively simple when both line managers and IT specialists understand and practice multiple change management roles. In the next section, we’ll describe some common expectations about change roles that we’ve observed in numerous cases where IT-enabled change has failed. In later sections, we describe two alternative ways to be a change agent. These roles have been associated with many successes, but who can or should perform them is controversial. In conclusion, we explain our recommendations for both line managers and IT specialists.

Change Agent? What’s That?

Several years ago, we began asking ourselves why so many IT-enabled change projects failed when so much is known about best practices in change management. We knew that organizational transformation, like personal change, is always difficult, even when known best practices are followed. When they are not followed, success is a matter of luck. So we rephrased our question to ask why effective change management practices are not being followed. Our first approach was to talk to consultants and IT specialists who were actively involved in IT-enabled transformation projects. We suspected that IT specialists were the most likely nonadopters of change management practices because they did not view themselves as agents of change.

We quickly learned that we were wrong — on two counts. IT specialists were by no means the only non-adopters of change management best practices. And many IT specialists and others we spoke with emphatically described themselves as “change agents.” However, while many self-styled change agents actively employed practices detailed in the research and practical writing about technical and organizational change, many others did not.

When we listened closely to what these people told us, we heard expectations about what it means to be a change agent that differed sharply from ours. Even nonadopters of change management best practices believe that they are change agents if they initiate or develop IT, because they think IT itself has the power to create organizational change. These people describe IT as a magic bullet — and believe that they have built the gun.

This view of technology is not new. In fact, under the name of “technological determinism,” it has been the subject of much academic debate. But it took on an entirely new meaning for us when we tried to understand the widespread nonuse of known best practices in change management. We call it the “magic bullet theory” of IT and organizational change (see the sidebar).

A Failure-Promoting Theory

To illustrate how the magic bullet theory helps promote failure in large-scale IT-enabled change projects, let’s trace the logical implications of the analogy between IT and a bullet that always hits its mark.

• First, since the magic bullet changes the behavior of people who use IT by enabling new work practices and preventing old ones, users are the intended target of change.

• Second, IT specialists — the tool builders — play the role of designing and building guns. Builders of guns that fire magic bullets do not have to worry very much about who is going to aim and fire the gun. After all, magic bullets always hit the right targets. So the gun builders can focus on the performance characteristics and aesthetics of their craft, without worrying about the shooters’ aim or the targets’ ability to dodge.
• Third, if there are gun builders, there must be entrepreneurs — people who contract for guns with the hope of profiting from their sale. In our analogy, senior line managers usually play this role. They fund IT projects and set the objectives for changed user behavior and organizational results. Entrepreneurs often focus more on marketing and profitability than on product characteristics and implementation. If the product doesn’t work as expected, the builders are responsible and will have to take the blame. (But, because entrepreneurs have little control over how their products are used in the marketplace, they also hire lawyers for protection against unexpected product liability suits.)

What’s missing from this picture?

Who’s Firing the Gun?

The magic bullet theory doesn’t tell us who should aim and fire the gun. In other words, it doesn’t say who is going to be the change agent responsible for producing the desired outcome with the magic bullet. Is the change agent the mythical middle manager to whom the users report? If so, does that middle manager truly share the objectives of the entrepreneur? Is the change agent the users themselves? If so, do they really want to fire this powerful weapon at themselves? Is the change agent the senior line managers who funded the project? If so, do they still have the same objectives when the technology is finally built? Is the change agent a staff professional from the organization development (OD) or training group? Or an outside consultant?

In effect, the magic bullet theory of IT assumes that the gun fires itself. Therefore, people who believe in the magic bullet theory do not feel a need to learn and practice change management techniques. IT specialists who subscribe to the theory (viewing themselves as “change agents” by virtue of their technology-building role) do not see themselves as responsible for ensuring that users employ the technology to achieve the desired results. Similarly, senior managers (who see themselves as “change agents” for commissioning large-scale IT projects) may also find comfort in the magic bullet theory. It allows them to turn IT projects over to specialists, whom they can blame if the projects don’t have the desired results.

In other words, both line managers and IT specialists can believe in IT’s magic. It allows them to neglect change management best practices, which, in turn, promotes failure. Furthermore, when line managers believe in magic, they tend to develop negative stereotypes of IT specialists, who also promote IT’s magic power, despite their limited effectiveness as magicians. No wonder CIO turnover is so high! IT specialists, in turn, may blame the senior managers for their poor ideas about technology implementation or for not providing “top management support.” Or they may blame the “damn users” (who know better than to play with loaded guns). Worse yet, once the finger pointing starts, no one ever learns how to make IT succeed. Consequently, future IT-enabled change efforts will be jinxed before they start.

Why the Magic Bullet Theory Fails

In Plato’s The Phaedra, Theuth, the Egyptian god of invention, explains the features of his new technology — the written word:

“This invention, O King,” said Theuth, “will make the Egyptians wiser and will improve their memories; for it is an elixir of wisdom and memory that I have discovered.”

Thamos, the Pharaoh, responds:

“Most ingenious Theuth, one man has the ability to beget arts, but to judge of their usefulness or harmfulness to their users belongs to another; and now you who are the father of letters may have been led by your affection to ascribe to them a power the opposite of that which they really possess. For this invention will produce forgetfulness in the minds of those who learn to use it, because they will not practice their memory.”

As we stated earlier, the magic bullet theory assumes that the gun fires itself. It also assumes that users are targets who invariably succumb to the powerful impact of steel-jacketed projectiles. Unfortunately for believers, users often act more like wily opponents than like sitting ducks.

First, most users know how to dodge bullets. It is incredibly easy to find fault with even the best current IT. Second, users have their own purposes —not necessarily those of executives — to which guns and bullets can be put. They may use the new IT, but management’s intended results may never happen. Instead of cutting costs, they may improve quality and expand service. Third, users can fight back and turn weapons on their makers. Sometimes, what occurs is the exact opposite of what managers originally intended. This, we believe, is one way to read Plato’s The Phaedra: Users can foil the plans of the world’s best change initiators and technologists.

IT as a Change Idea

The magic bullet theory hides one of the most important characteristics of information technology. IT is a package of ideas about how people should work differently. The packaging is important too, and we’ll discuss it as well. For now, consider the change ideas in some typical major IT projects:

1. Installation of the financial modules of an integrated enterprisewide software package (such as SAP) in a global corporation. This project is intended to reduce finance personnel costs and the IT personnel costs of maintaining legacy mainframe applications. It will require units in different countries to adopt common terminology and standard operating procedures. It will regionalize or centralize some financial activities and reduce the financial reporting flexibility of local country managers.
2. Development of a worldwide corporate logistics system for a global manufacturer. This project is expected to improve customer service and reduce cycle time while decreasing transportation costs substantially. It changes component supply and product delivery to and from every business unit companywide. It conflicts with established reward systems and the performance standards for promotion.
3. Implementation of an enterprisewide groupware or information-sharing package (like Lotus Notes or a corporate intranet). Such a project is intended to promote teamwork and information sharing across departments and divisions. But it may run afoul of a culture that promotes interpersonal or interunit competition. Users may have difficulty understanding the purpose of this technology relative to existing communication systems and more structured management reporting systems.
4. Consolidation of corporate telecommunications networks and standards. This very expensive undertaking is expected to reduce long-run operating costs companywide, but it requires three large units to make major changes in applications software and operating procedures that they would not otherwise do.

Implicit in major IT-enabled change projects (especially those labeled “IT infrastructure projects”) are expectations that the organization and its people will operate better when the technology is successfully installed and used. Nevertheless, many aspects of these changes are contentious.5 Even otherwise laudable goals such as reducing total corporate costs can create legitimate organizational conflicts by interfering with individuals’ career goals and financial incentives or with organizational culture and managerial autonomy. Conflict is particularly likely in organizations with many professionals or Americans, because these groups tend to place a high value on personal and unit autonomy.

Organizational change theorists continually remind us that organizations behave the way they do because they have found that behavior successful in the past.6 Thus any new IT that contains an idea about organizational change is an implied threat. Less well understood is that IT contains change ideas packaged in vehicles that have only some of the conditions necessary for change.

When used as intended, well-built IT makes it easier for users to perform some improved work practice and makes it harder for users to continue ineffective methods. But IT does not — and cannot —ensure that users will use it as intended. Nor can technologists or entrepreneurs. Ultimately, only users behaving mindfully can achieve appropriate and effective use of IT. Users must understand and accept the idea of and reasons for change. They must also thoroughly understand not only how to use IT but also how to use it to accomplish the desired results. Therefore, in addition to the necessary conditions for change contained in the IT package, there are other conditions that don’t fit in the box. (And this is not likely to change until computers come labeled “Intelligent Users Inside.”) The role of the change agent is to bring together all the necessary conditions for IT-enabled change.

Change as a Contact Sport

The role of bringing together all the necessary conditions for IT-enabled change is not easy because it involves changing people’s minds. As in the hoary expression about leading horses to water, a change agent can’t make people think, but he or she has to try. Whether the change agent’s tactics include infinite patience or a metaphorical two-by-four, ensuring the necessary conditions for IT-enabled change almost always requires considerable interaction between change agents and change targets.

Ideas printed in books are “disembodied” from the people who thought them. A few people can learn new ideas thoroughly and effectively just by reading them in books. Similarly, a few people can easily absorb (even create) new work practices just by using technologies that were designed to facilitate them. But many people learn new ideas best by talking about them with other people who “embody” the new ideas. One consultant told us, “Change flows best across a helping relationship.” We like to say, “Change is a contact sport.”

The magic bullet theory is seductive to many IT specialists and line managers because it allows them to disembody change ideas, package them as technologies, and distance themselves from the hands-on sport of helping people to change. Disembodied ideas appear more objective than personalized pleas for change. The attributes and attractiveness of technology can be separated from the change initiator and his or her goals. Instead of talking about how and why we all need to change, people can rejoice in the power of today’s IT.

Change ideas packaged as new technologies are much easier to deliver to the people likely to challenge them than verbal demands are. So technology provides ready-made opportunities for would-be change agents to avoid speaking about the hard facts of organizational performance and change. By initiating a new technology project (intended to reduce costs), some executives feel relieved of the need to say: “I’m dissatisfied with our costs, and I expect to see the following improvements.”7 And technologists can ignore users’ learning needs by focusing on easy-to-use graphical user interfaces.

The disembodiment and reincarnation of change ideas as new IT is especially convenient for change initiators when the idea not only creates contention but also can’t be discussed, such as change ideas that threaten sacred cows.8 And most people are too embarrassed to admit that the organization has given them no incentive to behave in its best interests.9 But the real issues that can’t be discussed center on who has the authority to initiate IT-enabled change ideas. Several CIOs have told us that they were mortified to learn from the newspaper that their CEOs had engaged consulting firms for major reengineering projects in which the in-house IT department would have no part.10 But few, we’ll wager, have dared to tell their CEOs how this made them feel.

The convenience of using packaged ideas to avoid discussion comes at a high price. Real issues are not confronted and are almost never resolved. The current change effort may succeed, but the next one starts with a much bigger handicap. We know several organizations that have attempted the same IT-enabled change repeatedly — and have repeatedly failed. With every failure, the human and financial costs escalate.

Consider the “Stealth Project,” as insiders named it (see the sidebar). In this project, both line managers and IT specialists subscribed to the magic bullet theory (although they disagreed about the caliber of ammo needed to hit the target). Neither could discuss IT’s poor credibility and managers’ naive assumptions about the limited IT skills of the users. Neither party took a change agent role or discussed what would enhance the users’ IT skills and make the project succeed. Instead, IS specialists focused their efforts on building better IT that would have made it unnecessary (had it worked) for either line managers or IT specialists to change users’ behavior. The result was a fiasco of the sort that has earned IT the reputation of being “one of the least admired corporate functions,” according to a leading IT advocate.11

IT as Scapegoat and Excuse

Because users are not sitting ducks, they can use the disembodiment and reincarnation of change ideas as IT to their advantage, just as well as executives and technologists can. When users understand perfectly the change idea embedded in a technology but do not like it, they don’t have to confront the issue directly. Instead of criticizing the change plan (a potentially embarrassing challenge to those who believe in it), they can merely criticize the IT itself. Instead of saying, “Cutting costs will reduce the size and importance of this unit and our career or income prospects,” they blame the technology for their failure to do what they don’t want to do: “We’d use the technology to cuts costs if we could, but this software is a real dog. Why don’t you give us something that works?” Or they might say, “If you really want to cut costs, why are you spending so much money on this worthless IT?”

In the following quote, we can easily hear a line manager’s reasoned response to a proposed new corporate investment in IT infrastructure. Intended to cut costs and improve coordination among autonomous business units, the proposal elicits scorn for its wasteful expense and its restrictions on managers’ rights to choose their own IT:

“Networking is expensive. It complicates the installation of systems and, in some cases, reduces the number of hardware and software options available. Clearly, there must be distinct benefits from these networks in order for them to be defensible. I have yet to see evidence that those benefits exist. . . . How much common data really exist? A recent Wall Street Journal article estimated than ‘on average, 80 percent of corporate information isn’t needed elsewhere in the company.’ This estimate is consistent with my own experience. More important, however, most or all of the remaining 20 percent is not needed online, and therefore, need not be linked. . . . Electronic mail is also cited as an important benefit of networking. . . . If electronic mail is the excuse to maintain centralized control of hardware, then it is of questionable value.”12

Better yet, instead of panning the technology, opposed users can offer constructive, convincing suggestions about how to make it better. This deludes technology initiators and builders into believing that users have overlooked the change agenda or have finally accepted it. Nothing could be farther from the truth.13 We have talked with executives and IT specialists exasperated by people’s failure to use technology that the nonusers themselves had requested. Probing usually reveals that the requests were socially acceptable ways to rationalize or temporize when confronted with demands for change: “We can’t cooperate with the manufacturing department on new product design,” the change targets might say. “Our departments have two different networks and two different software products, and they’re not compatible.” Since there is always some truth in such claims, executives and IT specialists immediately work on “IT projects” that consume time and money but avoid imminent changes in how the organization works.

Because a fair number of large IT projects encounter substantial delays and fail or are canceled for various reasons, delaying tactics have a reasonable chance of paying off. If a workable technology is finally delivered (and if executives are still interested in their old change demand), wily users can always devise new tactics for avoiding unwanted change.

Who Resists IT-Enabled Change Ideas?

Not just users but also line executives and IT specialists resist technologies that are clearly aligned with organizational goals and objectives. In these cases, the executives and specialists seem to favor different technologies for achieving the same goals. The competing technologies may serve organizational goals equally well but represent different costs and benefits for the different stakeholders (e.g., users, line executives, or IT specialists). In other cases, what may really be at issue is that executives or IT specialists insist on exclusive rights to decide which technology best meets organizational needs. (See the sidebar for an example in which line executives only grudgingly supported a user-initiated IT-based change that employed a different technology from the one managers wanted.)

IT specialists can get caught in a similar bind. People occasionally blame them for the pace of technical change and for being too fond of the latest IT developments. Yet we learned that many executives and users view IT specialists as extremely resistant to technical change. Specialists often try to limit the rate at which new technologies are made available to users. Some of their caution reflects incentives, embedded in “service level agreements,” to maintain a stable, reliable operating environment. But, in many cases, their caution also reflects their understandable desire to maintain control over their own work. For all their advantages, new technologies pose threats to technologists. IT specialists may not have the expertise to cope with the questions and problems that arise with new technologies, which can lower their self-esteem and satisfaction in their jobs. Even if the problems associated with a new technology are relatively minor, the inevitable shakedown period can mean long hours, many frustrations, and endless complaints for IT specialists.

Alternative Roles for IT-Enabled Change Agents

Belief in the magic bullet theory can lead to situations in which effective change management techniques are not practiced, and the intended organizational transformation never occurs. The problem stems from the roles and behaviors that the theory prescribes for executives, IT specialists, users, and IT itself. Executives are supposed to define the change idea or devise improved “systems.” IT specialists are supposed to select or build technologies that, when used as expected, will produce the desired results. Users are supposed to use technologies as expected (and not to have competing solutions for organizational problems). IT is supposed to work — like magic.

Alternative roles warrant inspection. We reexamined much of the literature on organizational change and technology implementation and found two distinctly different prescriptions for change agents’ roles. The first, from the OD literature, we call the “IT change facilitator” model. Like many IT specialists, OD practitioners consider themselves to be “agents of change” but approach this role very differently from the way magic bullet adherents do. The major objective of OD facilitators is to see that their clients take responsibility for making informed decisions based on valid information. Some of the OD practitioners’ beliefs may not translate easily into the context of IT-enabled organizational transformation, but line managers and IS specialists in major IT-enabled change projects can adapt many of the practices they have developed.

Our second model of the change agent role comes from the literature on the management innovation, IT implementation, reengineering, and organizational transformation. Here, the change agent role differs strikingly from both the facilitator role and the role in the magic bullet theory. These change agents are deliberately political actors who try to change people’s minds by any available means — from persuasion, modeling, and mandate to the manipulation of symbols and rewards. We call this role for change agents “the IT change advocate.” It is often assumed that only line managers can function effectively as change advocates. In practice, however, many executives are reluctant to advocate change in IT situations. Therefore, IT specialists need to learn how to play this role successfully, especially when executive support for an IT project wanes well after it has been started.

The IT Change Facilitator Role

The literature clearly spells out the core beliefs, roles, and responsibilities of OD practitioners.14 They believe that people, not technologies, create change. Even the change technology of OD practitioners (i.e., facilitation skills) enables rather than creates change. Because people have to create change, they must be empowered to do so. IT can deliver only one necessary condition for human empowerment — valid information. But empowerment is not simply a state in which people’s desks are wired with hot-and-cold running MIPS and bits. Empowerment is a state of mind that people must enter on their own. In addition to valid information, empowered people require opportunities to make informed choices and must accept personal responsibility for their behavior and its outcomes.

People are empowered about IT (not by it) when they thoroughly understand and hold themselves accountable for the organizational results of their own decisions about initiating, selecting, building, buying, using, or managing IT. They are not empowered when they blame other people or technology for their own performance. They are not empowered when IT-related decisions are made for them, or when the information they need to make good decisions about IT is biased or withheld.

By these criteria, people in any organizational role — technologists, entrepreneurs, or users — can be empowered or unempowered about IT. And people in any organizational role can be an obstacle to other people’s empowerment. For instance, by making all important technical decisions for users instead of with them, line managers or IT specialists can foster user dependency and ineffective IT use.

Empowering people about IT is difficult. Many factors stand in the way. The sheer complexity of information technology makes it hard even for experts to keep up to date and to sort out difficult technical issues. Another factor is the incomprehensible technical jargon and self-serving arguments in vendors’ sales pitches. A third is the press of business as usual and the need to respond quickly to changing opportunities and threats. Many people fear new technology and worry about their own ability to master it. And, of course, many new technologies threaten people’s bases of organizational power and feelings of control.

Because of these obstacles, change agents who model their role on that of OD practitioners can make important contributions in large-scale IT-enabled change projects. Minimally, these “IT facilitators” focus their efforts on bringing together all the conditions for successful IT-enabled organizational change: sound change ideas and rationales, well-built IT, organizational conditions that support both change and effective IT use, and mindful IT users. More broadly, they see their role as expanding the opportunities for thoroughly testing the organizational feasibility of IT-based change proposals before the search for technical solutions begins. They seek to expand users’ opportunities to learn about IT and provide informed input to critical IT decisions (see the sidebar).

· Potential Advantages of This Role.

There is a need for “neutral” facilitators in large-scale IT projects — people who do not advocate a particular position or solution but who mediate among those who do. In fact, a number of OD-based methodologies have been designed for reengineering and system development projects.15

We believe that there are enormous potential advantages in having organizational members who can play this change agent role. First (assuming constant quality of the change idea and the IT that enables it), better implementation (e.g., better training and support of users) improves the chances of IT success. We challenge any organization to boost its payoff from existing IT by at least 15 percent with minimal investment, by (1) looking at how much users know about their current IT tools; (2) identifying user-developed best practices with IT and disseminating them to other users in focused retraining or support efforts; and (3) making simple, low-cost changes (like relocating printers) that remove obstacles to more effective outcomes.

Second, the facilitator role can introduce listening and mutual respect in situations often characterized by assertion and self-interested advocacy. IT specialists often assign great value to their technical expertise, and executives often prize their authority and status. But both these valuable resources can produce unintended negative results in IT-enabled change. Either one can create distrust, dependency, or resentment in others; these emotions can easily destroy working relationships and the personal and professional credibility needed to get things done. The atmosphere of sincere inquiry fostered by effective IT facilitation can promote better IT decision making and better organizational results.

· Who Can or Should Perform This Role?

Despite these potential advantages, there is considerable uncertainty about who can or should perform the IT facilitator role. OD practitioners firmly believe that only neutral “third parties” — nonmembers of the groups they facilitate and nonexperts in the issue —can formally perform the facilitator role. They admit that managers and ordinary group members (e.g., IT specialists) can successfully practice many facilitation techniques. But they insist that leadership, membership, and expertise in “content” (i.e., business or technical issues) disqualify people as facilitators. The IT-related techniques and methods they have devised recommend third parties (e.g., OD practitioners) for the facilitator role.

We fully understand how the status and world-view of unbiased “outsiders” can promote success in organizational change processes. That’s why, for instance, external consultants who are not merely hired guns can be so helpful in many cases. But we also think that executives and IT specialists can wield great, if nonobvious, power by carefully practicing the IT facilitator role.16 Preventing IT specialists and executives from learning and practicing this role can hinder users from empowering themselves.

The major obstacle to effective performance as an IT facilitator is the will to see it through. Encouraging responsible participation can be as frustrating in the beginning as it can be rewarding when it’s more mature. Sometimes people will want the facilitator to do it for them, and he or she may be only too happy to oblige. But the payoff from diligent practice now is an easier time later when the next major IT-enabled change comes along. At current rates of IT development, the next major change won’t be long in coming.17

The IT Change Advocate Role

In the writings of innovation theorists, line managers, consultants, and some academics who study organizational change, we found yet another model for the change agent role.18 Unlike OD facilitators who try to unleash their clients’ ideas and energies for change, change advocates have their own visions and attempt to direct people toward them. Change advocates focus less on empowerment and more on inspiring people to adopt and tackle a specific new organizational challenge or undertake a specific change in work methods.

To realize their visions, change advocates follow the strategy of “whatever works.” They do not limit themselves to OD facilitators’ precise ethical guidelines. They don’t worry about revealing their content expertise or about biasing people to their vision. Overt persuasion, covert manipulation, symbolic communication, and even the occasional exercise of formal power (when the advocate has it to use) are all acceptable tactics in the advocate’s rulebook.19 A favorite tactic is to shock people into seeing things differently by deliberately behaving outrageously, like refusing to make all the decisions even when people ask you to.20 Others prefer to model the behavior they want others to adopt, such as senior executives who communicate via e-mail and do their own hands-on searches of organizational information. Still others rely on the “water torture method” of constant but varied repetition:

“I had to convince my coworkers of the need to change. . . . Since talking directly to upper management had failed in my previous situation, I decided I would try a longer-term, grassroots strategy. I gave myself a four- to five-year window. . . . The nom de guerre for my change process was ‘the water torture method.’ . . . Focus on one or two related topics. Casually work the topic into as many conversations as possible. Carefully repeat the principle in as many different ways as possible. Create opportunities for conversation. Avoid sounding like a repetitious tape-loop. Over time, I heard my ideas in developers’ conversations in other parts of the company. I found it most exciting when they considered these ideas their own. It’s important to give everyone an opportunity to stand in the spotlight. Give credit at every opportunity.”21

IT change advocates have clear views of what their organizations need to do to use IT effectively. Sometimes these visions encompass specific types of IT (e.g., knowledge sharing software or enterprise packages) or internal IT governance strategies. At other times, their visions describe major changes in business processes that would be impossible without IT. But they always focus clearly on meeting organizational objectives and upgrading users’ IT skills (see the sidebar).

· Potential Advantages of This Role.

The successful IT advocate shows people what kinds of IT they want and need. For example, a CIO of a large, diversified electronics company with twenty years tenure told us that his most successful change strategy was to build small demonstration systems (e.g., client/server prototypes) as vehicles for discussing organizational improvement opportunities with his internal clients. Practiced astutely, the change advocate role is its own reward. The advocate discards tactics that don’t work, so he or she succeeds and builds credibility for future initiatives. The organization also wins through better performance.

In addition, the IT change advocate may be better able to guide organizations through difficult IT infrastructure decisions than can advocates of the magic bullet theory or IT change facilitators. The major challenge of many in-house IS specialists is to ensure threshold levels of commonality and interoperability to support internal and external communication and future flexibility. In economists’ terms, this is a public-goods problem: because everyone benefits from IT infrastructure, no one wants to pay for it.22 Therefore, neither rational persuasion based on technical expertise nor a participatory, consensus decision-making approach will result in the optimal organizational decisions about IT infrastructure. Most organizations need deft assistance to negotiate the dangerous political shoals of IT infrastructure decision making.23 The IT change advocate can provide it.

· Who Can or Should Perform This Role?

Academics of the change school frequently write as if change advocacy is the exclusive domain of line executives with the formal authority to command. Yet consultants and innovation theorists know that effective change advocates can be found in every organizational role and even in the ranks of technical staff specialists. Change leaders are not necessarily people who would be tapped for top management positions; they include “the funny little fat guys with thick glasses who always get the job done.”24 Thus both mid-level line managers and IT specialists can play the IT change advocate role (see the sidebar for one senior IT manager’s role).

The most serious obstacle to playing this role effectively is delegated control authority. It is very hard for IT specialists whose job is, for example, approving or disapproving other departments’ IT purchase requests or ensuring they adhere to corporate standards to act effectively in the change agent role. The execution of delegated control authority introduces tensions into the relationship between staff specialists and their “clients” that turn change advocacy attempts (and facilitation attempts) into exercises in frustration.25 Nevertheless, when it is possible to segregate control-related activities from client service activities (e.g., into different jobs or work units), the IT specialists who don’t have control responsibilities can be effective IT change advocates.

Conclusion

Many IT-enabled change projects fail, despite how much is known about ensuring success. In this article, we have argued that failure to employ best practices in IT-enabled change stems from mistaken beliefs about the causes of change — belief in IT as a magic bullet. Deeply held beliefs that IT can cause change lead both line managers and IT specialists to restrict their own efforts as change agents. With everyone assuming that change management is the job of someone — or something — else, there is often no one left to perform change management tasks. Change then fails, and lack of learning about the root causes of failure promotes future failures.

We wish we had a magic bullet solution to this too-common problem. We do not. But we have a few suggestions for breaking the vicious cycle. First, success in IT-enabled transformation is more likely (yet still difficult) when everyone involved in initiating, designing, or building technology-enabled change accepts that IT is not a magic bullet. Good ideas and good designs together are not enough to ensure success. Change in human behavior cannot take place at a distance but requires direct personal contact between change agents and targets. Not just any contact will do. It is not sufficient to tell change targets how and why they have to change. Nor does it work only to explain a technology’s features and how to operate it. Change management involves listening, understanding, giving people a chance to learn, designing learning experiments, and visualizing and dramatizing ideas. This change management activity must be done as an integral part of initiating, designing, and building technology-enabled change. It cannot safely be ignored, delegated to someone else, or deferred.

In short, our first recommendation is that line managers and IT specialists who wish to achieve success with IT-enabled transformation must change their own minds so that they can then alter their change management behavior. This is a tall order, especially since giving up the magic bullet theory can leave a real void. In place of the failure-promoting magic bullet theory, we offer the more realistic metaphor of the Trojan horse.

Greek warriors faced powerful resistance at the walls of Troy when they attempted to recapture their queen. They respected their enemy’s fighting skills, valor, weaponry, and defenses. They knew that they would have to fight hard, even if they succeeded in breaching the walls. They needed an edge, not a magic weapon. They improvised a clever idea grounded in sound human psychology. They built supporting technologies — a great hollow wooden horse and a wheeled carriage to get it to the walls. Then they executed their plan flawlessly. Brave trained warriors hid inside the horse, while others pulled the horse to the gates at night. In the morning, the curious Trojans brought the horse inside their walls. The warriors inside the horse remained quiet and ready until night fell again, and the Trojans went to sleep. Then the warriors climbed out of the horse, slew the guards at the walls, and opened the gates of the city to the rest of the invading force, who were standing by, ready to finish the job.

There was no magic bullet here. The Trojan horse was a highly coordinated effort in which warriors, temporarily playing different roles (creative initiators, skilled builders, highly trained fighters, and a strong support staff) all worked together to achieve a difficult task. They did not have narrowly defined roles: “Trojan horse idea generators,” “Trojan horse construction workers,” “Horse pullers” “Horse-borne sword carriers.” They were all just warriors. All had to remain alert to new opportunities and challenges that would necessitate changing their plans. In short, the Trojan horse metaphor is more likely to promote successful action than the magic bullet theory, because it reminds us that: (1) while good design is important, successful change requires implementation planning, execution, and improvisation to deal with resistance and unforeseen events, and (2) assigning the responsibility for a complex change to a single group (or thing) is a recipe for failure.

This last point leads to our second recommendation, regarding who should perform the change management role. We believe that it is folly to approach such a complex, dynamic, and chaotic process as IT-enabled organizational transformation as a linear sequence of tasks with defined roles and handoffs (especially when no one is lined up to play certain key roles). What happens if something changes? What happens if someone for any reason cannot or will not perform his or her scripted role? We can’t stand around hoping for better — that’s a losing game. Everyone needs to be ready to do whatever it takes. Change is everyone’s job. Our conclusion here is similar to a basic principle of total quality. As in service provision or order fulfillment, quality is everyone’s “job one”; in IT-enabled transformation, change is everyone’s first priority.

To implement this recommendation, we suggest that line managers, IT specialists, and other organizational members who get involved in IT-enabled transformation learn about and practice all the different roles that change agents can play — the traditional roles of IT client and expert and the alternative roles of IT facilitator and IT change advocate. Each of these roles has strengths and weaknesses, and not all people in all formal organizational positions will play them the same way. Nevertheless, we believe that all individuals will be more effective contributors to change processes if they learn to shift tactics when conditions change and familiar practices don’t work.

Behavioral flexibility is, we believe, a critical success factor in chaotic change processes. Sometimes the most effective tactic involves shocking people with evidence of the need for change, sometimes providing them with an attractive vision of how life could be better with change, and sometimes rewarding people for their efforts at change. Sometimes it will be giving people the opportunity, information, and resources to create their own change. Effective change management is whatever it takes.

Our vision of change as everyone’s job will be a stretch goal for many organizations. It may be advisable to approach this goal in stages. Some companies that have made good progress have started by creating formal change management positions and designating particular members of IT-enabled change project teams to fill these roles. In our view, at least two team members should be designated as “change agents” —one IT specialist and one nonspecialist. Further, the assignment should rotate periodically, so that all team members can think through and practice change management skills. Then, once a shared change culture has begun to form, we recommend that the organization formalize the role as part of everyone’s job. Effective change management performance criteria should be included in the job descriptions and weighed seriously in the performance assessments of both IT specialists and business people.

Successful change takes good ideas, skill, and plain hard work — but it does not need magic.