Are you gambling on a magic bullet?

OCTOBER 20, 1997 - FoxMeyer Drug Co. gambled on information technology - and lost.

When the Carrollton, Texas-based company decided to replace its legacy mainframe systems in a $65 million enterprise resource planning (ERP) project, Chief Information Officer Robert Brown told Computerworld: "We are betting our company on this." [CW, Sept. 5, 1994.] Just a few years later, after the system failed to deliver the expected benefits, the pharmaceuticals company filed for bankruptcy and sold off a major business unit to a key competitor.

The real culprit in the FoxMeyer Drug story is not IT, ERP or client/server technology. It's unrealistic, "magic bullet" thinking about IT and its benefits by information systems managers and line executives.

Magic bullets are technologies and methodologies that people believe can do remarkable things with little or no human intervention. Computerworld readers are more familiar with magic bullets than most people, because the IT industry produces them at a very rapid rate. Examples include client/server architecture, object-oriented programming, Java, outsourcing, re-engineering and enterprise packages. In our research and consulting, we have learned that belief in IT's magical powers is widespread and plays an important role in IT project failures - and even business failures. Are you and your line management colleagues betting your company on IT? And if so, is it a calculated risk or a reckless gamble?

The details of the FoxMeyer Drug story show that only some of the blame can be traced to technical problems. In the middle of the ERP implementation, for example, the company had the bad luck to lose a key customer that accounted for 15% of its sales. But a closer look at the project reveals a series of risky management decisions, which can be traced to the company's "magical thinking" about the power of IT.

Risky business

Among the risky bets FoxMeyer Drug placed were these:

FoxMeyer Drug, a business with very tight margins, embarked on a second high-risk IT project simultaneously with the ERP implementation. It was an $18 million state-of-the art computerized warehouse, which encountered severe technical problems and led to inventory losses of more than $15 million.

In an attempt to regain lost sales, FoxMeyer Drug's managers signed a contract for a new customer on the assumption that a projected $40 million in benefits from the ERP implementation would be realized right away.

To accommodate the new customer, FoxMeyer Drug pushed the deadline for the ERP implementation project forward 90 days. This meant it could not re-engineer business processes and reap the attendant savings. IT specialists responded by cutting short the testing of modules that hadn't been modified.

The results were predictable. FoxMeyer Drug's ERP started up on time and customer orders were filled. But widespread data errors led to inaccurate customer sales histories, thereby limiting the company's ability to benefit from forecasting inventory needs. Ultimately, the firm realized only half the projected savings.

"In hindsight," said the company's new CIO, Douglas Schwinn, "I'd stand up in front of the board of directors and say, 'Don't spend that money.' '' ("A Cautionary Tale: FoxMeyer's High Tech Gamble,'' The Wall Street Journal Interactive Edition, Nov. 18, 1996.) But at the time, both then-CIO Brown and FoxMeyer Drug's line managers gambled on the magical ability of IT to deliver enormous benefits with a minimum of risk and effort.

FoxMeyer Drug's executives were not alone in believing in IT's magical powers. We've found similar patterns of thinking among both IT specialists and line managers in many companies. The tragedy of the "Magic Bullet Theory of IT" is that it lulls executives into a false sense of security in which they don't take adequate steps to prevent failures and ensure success.

Research conclusively shows that good change management skills can substantially increase the odds of IT project success. Yet it is also clear that best practices in change management, although known, are not widely used by IT specialists or their line management clients. IT executives and consultants often do not employ these practices because of magic bullet thinking.

Altogether, there are three different models of what it means to be a successful agent of IT-enabled organizational change. We call these models the Tool-Builder model, the Facilitator model and the Advocate model. All three are appropriate in different circumstances; the odds of success are highest when IT and line executives know and practice all three roles. But in our conversations with IT executives and consultants, we found that the Tool-Builder model was heavily overused in ways that reduced the odds of success.

The tool-builder model: "IT is magical"

Many people who work with IT claim to be "change agents." But what they usually mean is that the IT they implement will create favorable organizational change. They believe that IT changes people and organizations by empowering them to do things they couldn't do before and by preventing them from working in old, unproductive ways. Therefore, the people who initiate, design, build or install this powerful, magical technology are "agents" of organizational change.

"We bring you Lotus Development Corp. Notes, and you will collaborate." "We bring you an enterprise logistics system, and you will save time and money." "We bring you data warehouses, and you will make better decisions."

The belief that IT makes benefits happen glosses over the great shifts in users' knowledge, skills and routine workplace behaviors that are needed for improvements in organizational performance. No matter how magical the bullet, someone has to aim the gun and pull the trigger. Tool builders don't do that; they just build the guns and the bullets. But somebody (actually, many people) in the organization has to take responsibility for the training, coaching, redesign of business processes and new managerial behaviors needed to get IT's promised results.

Successful organizational change is a contact sport. Change is not produced by planners planning, designers designing and funders funding. Rather, it is the result of hard, interpersonal work by all the actors in the change drama, where the tactics can range from infinite patience to the use of metaphorical two-by-fours. The magic bullet theory's seductive appeal is that it will do the hard, contact sport work for all of those who prefer disembodied ideas to "in-your-face" contact with the users who are targets of change.

The Tool-Builder model of IT change agentry does not even recognize the need for the contact sport of change. It does not specify who, if anyone, should go out on the playing field. It assumes that the hard work of change can be accomplished without human intervention, as if by magic.

Quite frankly, that's a message many busy executives like to hear (especially if they are still ignorant about, and intimidated by, IT). Not surprisingly, line managers who listen to tool builders can easily feel justified in shifting the burdens of change onto the technology itself. Unfortunately, however, IT really isn't magic. When line managers eventually realize their mistake, it's often too late to prevent an implementation or business failure. Any wonder, then, that many line managers blame IT specialists when things don't go as planned?

Magic bullet thinking in IT implementation is like a Hail Mary pass in football: It's better if you don't have to use it. So, it's useful to know the alternatives to the Tool-Builder model.

The facilitator model:

Organizational development (OD) specialists also frequently refer to themselves as change agents. When you listen to them closely, you find that they mean something very different than "tool builder" by this phrase.

Whether they are consultants or staff members, OD specialists are concerned with improving the effectiveness of human systems at all levels: work groups, organizations, interorganizational alliances. They view themselves as facilitators of others' efforts to create change. The basic belief is that people, not technologies, make change. Even facilitation and other "soft" skills cannot produce change. At best, they help people take responsibility for making change happen and empower them by surfacing information they need to make informed decisions about change. OD facilitators stay out of the content of the decisions they facilitate as a matter of principle: They do this to avoid exerting unfair influence on their clients' choices.

MUCH TO GAIN

IS executives and specialists have much to gain by judiciously adopting the change facilitator role in large-scale IT projects. At a minimum, adopting the change facilitator role brings together the factors necessary for IT success: sound ideas for the use of IT to improve performance, well-built and supported technologies, conditions that foster effective IT use and knowledgeable users. Broadly, being a change facilitator helps managers and users test the feasibility of proposals for change before the search for technical solutions begins. (FoxMeyer Drug's new CIO claimed he would tell the board of directors today: "Don't spend that money [on ERP software and state-of-the-art warehouse automation]ý There are cheaper ways to do it. There are better ways to do it that aren't quite as technologically advanced. ")

HELPING CHANGE

Where might change facilitation help in cases of IT-enabled change?

IT projects often run into trouble when internal clients and users interpret IS' technical expertise as self-serving advocacy. A neutral facilitator would not endorse a particular solution, but would instead help clients make informed decisions based on valid information about the alternatives and their pros and cons. (Valid information means that IS clients would know, for example, that a particular technology reduces costs for the IT group but increases costs for users.) We believe if more IS executives and specialists behaved like facilitators in technology choice decisions, then conflict between specialists and clients or users would wane and more projects would be successful.

IT efforts often fail to yield their intended benefits because line executives fail to take full responsibility for ongoing user training and support. In some cases, these tasks do not fall within the IS budget. Nevertheless, success depends on these tasks being performed well. In cases like these, IT specialists can help by educating managers tactfully about implementation requirements and helping managers find the resources to get the job done.

Many newer information technologies such as Lotus Notes and the Internet do not require the same heavy investments in development as traditional transaction-oriented systems. At the same time, users may require much more education and support to employ the new groupware technologies productively than they would for familiar technologies. IT specialists can act as change facilitators by documenting and disseminating information about effective user-developed practices with collaborative technologies throughout the organization.

Despite the potential advantages of the change facilitator role in IT-enabled change, there are some hazards and difficulties.

First, there's the chicken-and-egg problem. IT specialists can actually gain credibility by not pushing their technical expertise, but it requires some credibility for IT specialists to play the role of neutral facilitator. In addition, there are times when clients expect IT specialists to display their expertise - though these times are not as frequent as most specialists think.

The advocate model: "You've got to make them think"

Successful business and technical leaders often refer to themselves as change agents, but they mean something quite different from either the Tool-Builder or the Facilitator model of change agentry.

Change advocates know that facilitated empowerment often results in more of the status quo. A change of mind and heart is required for real change to happen. The role of a change advocate is to envision what is needed to get the organization on track and to get everyone else to see that vision, too. They don't worry about elegant tools or staying on the sidelines while people work things out. They neither flaunt nor conceal their technical expertise; they don't worry about exerting too much influence on how others see the world. Their model of change agentry is best described as "whatever works." Overt persuasion, covert manipulation, symbolic communication and even the naked exercise of formal organizational power (when the advocate has it, which is not always the case) are all acceptable tactics for achieving change. At the same time, successful change advocates understand they work with and through people and often make sure others get all the credit for success.

SHOWING THE WAY

In an IT context, the successful change advocate shows people the kinds of IT they want and need as well as how to use IT to get results. One CIO we know built and demonstrated small prototype systems to his clients to get them thinking about organizational improvement opportunities. Another type of advocate would preach the benefits of IT skills testing and training for users. Practiced astutely, the change advocate role can create consensus among line managers about the need to invest in IT infrastructure today to get business results tomorrow.

As with the facilitator role, change advocacy has pitfalls and inappropriate uses. For example, it may work best in organizations in which IT is viewed as primarily supportive rather than strategic. It probably works better when the role of the IT function is more advisory than control-oriented. And it can be deadly in multidivisional companies with strong general managers and a CEO who wavers on questions of shared IT needs.

By changing hearts and minds, one change advocate added $500 millionto his company's bottom line

When the CEO of a business equipment manufacturer learned that slow inventory turns were hurting profits, he charged a distribution executive with an IS background with reducing inventories by improving the worldwide inventory management process.

The advocate rejected line responsibility and chose to build a team of 30 change agents - experts in IS, distribution and organizational development. The team defined a vision and a clear road map for fulfilling it. Then they created a simple, unified company inventory measure. The advocate subsequently convinced the CEO to give bonuses to his top 20 executives if they drove down this measure.

Once the incentives were in place, the team focused on obvious quick fixes, such as transferring inventory from countries that could not move it to those that needed it. The team's IS experts provided simple inventory summary reporting that facilitated inventory sharing across the company. Meanwhile, the team's senior members kept encouraging and assisting the business unit leaders.

These early successes paved the way for a tougher step: changing the production planning process. For years, inflexible, 26-week production schedules were set by the top manufacturing, marketing and procurement executives. The team could see that empowering middle managers and plant managers to plan production every week would keep inventories in line. The only obstacle was fear: Managers were afraid of making mistakes, executives of losing control.

The team's IT experts developed a simple production decision-support system. To keep executives happy, the system alerted mid-level managers when they had crossed thresholds that required them to seek approval for their decisions. Facilitators supported the managers' weekly meetings by walking through the data and clarifying the decision issues. In time, the managers' confidence grew. Savings came to exceed expectations, and the new approach spread worldwide.

The moral: Change agents are agents of organizational change, not agents of technology.

Conclusions

Despite all that is known about IT success, many projects still fail. Why? IT and line executives often hold magical beliefs about the power of IT, and these beliefs are reflected in what they see as their own and others' roles.

The result may be that no one accepts responsibility for playing the contact sport of change. Then IT fails, nobody learns and more failures are likely in the future.

Effective change management is everyone's job. IT executives may not officially be responsible for educating users or convincing line managers of the need for change. But to remain in the Tool-Builder role while these things do not get done is a recipe for failure. Today's IT projects are so large and complex that they're "bet-the-company" propositions. They cannot succeed if people only do their own jobs well; everyone must make a direct contribution to the desired final result. This means line executives must take more responsibility for IT than they often do today and, at the same time, IT specialists must take more responsibility for making the business a success.

IT leaders cannot just build tools. They must also facilitate people and try to change their minds. But first, they must examine their own beliefs and understand how magical thinking about IT's power can lead to IT failures.

The ideas presented in this article are developed further in "The Magic Bullet Theory in IT-Enabled Transformation," M. L. Markus and R. I. Benjamin, Sloan Management Review, 38, 2 (Winter): 55-68.