When Too Much IT Knowledge Is a Dangerous Thing

In recent years, large companies have invested a great deal of money — and faith — in IT systems as a means of leading vital organizational or competitive change. More than half of such investment has been in what I call “process-enabling information technology,” or IT that facilitates the execution of entire business processes rather than individual tasks.1 Such technology includes systems devoted to enterprise resource planning (ERP), supply chain management (SCM), customer relationship management (CRM), and e-commerce operations. The coordination, managerial oversight and marshaling of resources needed to implement any of these systems make for a change effort like no other.

All too often, however, hopes are dashed, and the effort is deemed a failure. Various studies have shown that in 30% to 75% of cases, new systems don’t live up to expectations, register a measurable financial impact, improve work processes, or bring about organizational change.2 In some cases, the result is catastrophe. Nike, for example, spent hundreds of millions of dollars on a system that forecasted sales inaccurately; Hershey Foods suffered through a Halloween season in which it failed to keep its candy in stock with major retailers; and FoxMeyer Drug filed for Chapter 11 at least in part because of problems with its ERP implementation.

Technical snafus are not the reason for these and other failures.3 Nor is the problem a scarcity of good advice for managers. Academics, consultants, IT vendors and managers themselves have conducted research that has generated much valid guidance on one aspect or another of implementation. Nor is such guidance being ignored. Most executives I’ve worked with are keenly aware that implementations are big, risky projects, and they have diligently sought state-of-the-art advice by reading, attending conferences and classes, and hiring experts. In my research, I’ve found that the problem — the fundamental issue — is that managers usually follow what amounts to a universal checklist, one that is supposed to be appropriate for all situations, when they implement a new process-enabling technology. The checklist is assembled from the broad spectrum of IT implementation research on such topics as user acceptance, business-process redesign, system configuration and change management. The assumption is that if all the items on the checklist are attended to, success will follow.

The problem is that the checklist assumes all implementations are basically alike. In other words, taken as a whole, the list is merely a collection of undifferentiated findings and conclusions rather than a synthesis that would help with the particular implementation effort at hand. The executive in charge of the effort is left to discern which findings apply, under what circumstances, and why.4 Many items on the typical list have all the value of a bumper sticker: “Secure top management support.” Naturally, but the kind and level of support needed can vary from project to project. Likewise, “get user buy-in.” Hard to argue with that, except that in some cases it really isn’t necessary, while in others the buy-in must be complete if the project is to realize the sought-after benefits.

About the Research »

In my experience, managers don’t need more nuggets of IT implementation guidance; they need to be able to differentiate one course of action from another, as circumstances dictate. Instead of a longer or different list, then, this article will offer a synthesis that highlights how big IT implementations differ from one another and how managers should handle the differences. My research has led me to conclude that every implementation can fall foul of certain specific pitfalls that will derail its effectiveness and drain value from the investment. I’ll indicate the nature of the pitfalls and how they can be diagnosed and then turn to appropriate actions managers can take to realize the full promise of technological change.5

Five Pitfalls of IT Implementation

Pitfalls crop up even when the ground rules of good implementation are followed. (For a discussion of these rules, see “The Brief Universal Checklist.”) I’ve identified five pitfalls that can appear despite management’s best efforts: inertia, resistance, misspecification, misuse and nonuse. Although the pitfalls are considered individually here, they don’t occur that way in the real world, and managers need to be able to take on the mix of problems they will likely face.

The (Brief) Universal Checklist »

The existence of pitfalls does not guarantee that an implementation will fail, but it makes it more likely. At the very least, pitfalls, when ignored, will delay a project or reduce its benefits.

Inertia, for example, is a prime offender. Inertia in this case is the lack of progress over time on implementation milestones and decisions, even after all parties have agreed that the effort is a good idea. It’s easy to recognize, showing up as missed due dates, project schedules that keep getting extended and “go live” dates that recede into the future. Inertia is expensive: Employees and external consultants continue to cost money even while little is happening.

Several factors increase the likelihood of inertia slowing down progress. One is the introduction of many new processes all at once, as in the case of comprehensive ERP implementations. Another is the complexity of the processes being automated; data-intensive, mathematically difficult problems (such as the optimization of production or logistics, or the allocation of scarce products among customers) are difficult to embed in software. Finally, inertia will arise when multiple groups are affected by the new processes and fear that the core of their efforts — and thus their mission at the company — could be compromised by the implementation. They will, quite naturally, want to proceed slowly.

In the mid-1990s, Cisco Systems suffered from inertia after it experienced a series of failures in its legacy IT applications, which were not robust or scalable enough to support the needs of the rapidly growing company. Because CIO Pete Solvik did not want IT to dictate business systems at the company, he told Cisco’s senior line managers that he would support whatever application decisions they made. The line managers, who were all affected by the company’s IT woes, agreed that something had to be done —but none of them stepped forward to lead a large project or even suggest one. The volume, complexity and sheer importance of the processes made it difficult for them to pull the trigger. After a year, Solvik and the board were forced to take action when the legacy systems failed catastrophically, shutting down the company for two days. They decided on a single comprehensive system and set an aggressive implementation timetable.6

Inertia, then, is failure to act with necessary dispatch even when there is agreement about the need to act. The second pitfall, resistance, shows up when people are not on the same page about how or whether the implementation should proceed. It arises not when the new, IT-enabled business processes are complex but when they’re novel — far from the current way of doing business. Resistance also becomes more likely when people’s incentives are misaligned. A manufacturing manager whose evaluation depends on meeting production targets may well oppose a large project that has the potential to disrupt output temporarily.7 Like inertia, resistance can manifest itself as a lack of progress over time. It’s easy to spot the difference between the two, however, because resistance is marked by arguments, overt or covert hostility toward the project, extensive political maneuvering and turf battles.

Consider what happened at one company that sells highly customized products through independent sales reps. It decided to encourage smaller customers to order via the Web and began a combined ERP and CRM project that would allow them to do that. Sales reps would no longer receive commissions on those orders. In addition, the reps were going to be responsible for entering large customer orders into the new system themselves, instead of phoning them in. As the reps learned more and more about the implementation, they began to complain, both to the company’s managers and to their customers. Some went as far as warning large customers that fulfillment performance would deteriorate because of the new system, and others began promoting competitors’ products. Performance suffered after the project went live, and many customers and sales reps defected. The situation eventually became so bad that the new systems were ripped out and scrapped. The implementation’s leaders became so enamored of how the company as a whole could perform better that they forgot to consider how the affected groups would feel about the changes. In this case, the sales reps had both the motive and the opportunity to strongly resist.

A very different kind of pitfall is misspecification. When new processes can be embedded in software in a straightforward way — office-supply procurement and general ledger updates are two examples — misspecification is not likely. A high degree of complexity, however, greatly increases the risk of misspecification. When a project is misspecified, the organization ends up with a system that works in a technical sense but does not improve the execution of business processes. Misspecification also can result when a company attempts to modify a business-process template provided by an IT vendor. A customized template can become unstable and can also have an adverse impact on related processes, as Nike learned in its fiasco with a $400 million supply-chain management system.

Nike purchased the system from software vendor i2 Technologies in the late 1990s and put it into operation in 2000. Nike soon discovered that the system’s forecasting accuracy was low, which caused problems both with overproduction and underproduction. In addition, Nike found that some production orders were being placed twice internally, while others fell through the cracks and were never manufactured. In 2001, Nike claimed that problems with the software had reduced one quarter’s sales by as much as $100 million. But i2 charged that Nike had heavily modified the software instead of adopting the business processes built into the application. As a result, i2 maintained, Nike’s software was improperly configured for supply and demand planning.8 The two companies do not agree about what went wrong with the project, but it is clear that the business processes were complex and that software templates were modified to meet what Nike felt were its unique requirements. Those characteristics of the implementation made misspecification a real and likely danger.

Once a system is operational, its potential can fall victim to two common pitfalls: misuse and nonuse. Misuse is likely to be a problem if the users of the new process are unsophisticated about the technology, if the process itself is a new one and if it spans several parts of an organization or more than one organization. When users are unfamiliar with technology or processes, they are prone to incorrect or incomplete data entry. Such errors multiply in importance when they have a spread beyond the borders of one department, function or company.

Misuse plagued Rich-Con Steel, the oldest family-owned business in Kansas City, after it installed a basic enterprise system in late 1996. Soon after, managers found that they couldn’t get an accurate picture of inventories, accounts payable and receivable and customer order status. Investigations revealed that many employees, none of whom were experienced with computers, had been using the new system incorrectly. When expediting the backlog of orders that built up during the transition to the new system, for example, some clerks neglected to close out orders that had been shipped. As a result, the system indicated that inventory for those orders was still available, even though the steel had left Rich-Con; in addition, customers could not be billed for orders that had not been closed out, so payments owed the company were delayed.9 Partly as a result of the negative aftereffects of the implementation, Rich-Con’s owners were forced to sell the company to an outside buyer in 1999.

Whereas people’s misuse of a system becomes clear relatively quickly, nonuse is a more subtle pitfall because it comes about when people’s employment of the new technology is discretionary — that is, when failure to use the new technology does not automatically compromise the execution of other tasks or processes. When people have a choice, t hey may well ignore a new technology, especially if it affects a core task or is highly novel. As with misuse, nonuse can result when the new technology must be executed by people who are unsophisticated about technology.

The networking hardware vendor CoSine Communications had trouble with nonuse after it installed a CRM system in 2001. The new technology was meant to help CoSine’s sales force with sales-call planning, forecasting, ordering and customer account management. Originally, sales reps were not obligated to use the new system, and four months after the software went live, only 20% of the sales force was using it. Salespeople did not trust it to give accurate information and felt that it was leading customers to think that the reps didn’t know what they were doing.10 CoSine resolved the problem by tweaking the software and educating its salespeople about ways in which the system could make their jobs easier and more lucrative.

Many deeply troubled implementations suffer from a “death spiral” brought on by interactions between two or more of these pitfalls. For example, it appears that the system at Rich-Con Steel was at least partially misspecified — among other things, it would-n’t allow a partially complete order to ship, even though partial shipments were a common practice in the industry. When employees started using it, they quickly became frustrated and began resorting to manual and system-based workarounds. This misuse made the system’s initial misspecification even more harmful.

Fortunately, the kind of problems experienced at Rich-Con and elsewhere are not insoluble. Companies can use a variety of strategies to avoid getting trapped by the implementation pitfalls.

Beyond the Checklist

Instead of thinking in terms of typical checklist items that don’t differentiate one process-enabling implementation from another, corporate leaders should start by thinking about the specific pitfalls they are likely to face and should then tailor strategies to address them. There are five primary areas in which managers face choices: the level at which the project is led (how high in the organization); the optimal management style (top down or consensus building ); the project’s scope (limited or comprehensive); its timing (in phases or through a “big bang”); and the extent of organizational preparation (basic or extensive).

Level of Project Leadership Process-enabling IT efforts are usually staffed and managed by a dedicated implementation team that reports to a program office led by a project manager. They are also commonly watched over by a steering committee of senior managers and a high-ranking executive sponsor. In order to overcome the pitfalls of inertia or resistance, it’s important that the rank of the project manager and executive sponsor be high. The project must be guided by people who have the authority to make difficult decisions. In the absence of that authority, organizational groups with a vested interest in the project tend to proceed conservatively (inertia) or to dig in their heels (resistance). And the more interested groups there are, the more likely it is that one or both of these pitfalls will damage the implementation.

An effective approach in these circumstances is to think in terms of managing the project “above the interfaces” of the involved groups. In other words, the project’s ultimate decision maker is someone who outranks everyone from the affected groups. That was how Cisco overcame inertia — its ERP project was eventually led by the CIO and the vice president of manufacturing, who reported directly to the board of directors. Managing at that level helped the company get its comprehensive new system in place in less than nine months, a remarkably quick job given the magnitude of the task.

Does the Cisco dilemma mean that top-level executives need to be involved in every IT-enabled change effort? Absolutely not. When a project affects only a single group within the company, it can be managed from within the group and doesn’t need the involvement of high-ranking general managers. Automation efforts directed at the sales force are one example. Likewise, when many groups are involved but the project is uncontroversial, high-level managers don’t need to step in. An example is moving office-supply purchasing online.

Some projects and efforts, on the other hand, can’t easily be managed at sufficiently high levels to be successful. That dilemma partly explains the slow adoption rate of B2B technologies and the lack of enthusiasm for electronic marketplaces.11 Since B2B and e-marketplace technologies and processes involve many companies, they cannot be led above the interfaces of the affected groups and thus have no direct counter to inertia and resistance. There are many industry-level standards bodies currently defining e-documents (such as standardized digital purchase orders and inventory status updates) and business processes to make use of them, but these consortia can rarely dictate that member companies follow their proposals.12 As a result, intercompany IT efforts are likely to remain cautious, slow-moving and incremental. They simply can’t be managed forcefully from above for faster, deeper progress.

Management Style Whatever their level, executives in charge of an implementation have a choice about how they go about their work. They can adopt a top-down, heavy-handed approach or lead a bottom-up effort based on participation and inclusion. I call these directive and consensus-building styles, respectively. Most managers rely on a blend of the two, but the distinction is important because each style is appropriate in some circumstances and inappropriate in others.

Of course, every manager would love to have complete consensus and 100% buy-in upfront from the people and groups that will be using the new technology. But consensus is not always essential. When the only pitfalls in the path of a successful implementation are inertia and resistance, it is usually more efficient simply to make decisions, even if they are unpopular ones. Obviously, an above-the-interfaces level of leadership is required in such cases.

A directive style has been used to put in place large-scale enterprise systems at companies like IBM, Tektronix and Harley-Davidson. In all these cases, business processes were not highly complex, users were sophisticated about IT and the systems were mandatory — people did not have discretion about using them. In these circumstances, broad consensus and incrementalism aren’t required.

In at least three circumstances, however, a directive style is a bad idea. First, when the new business processes are complex and misspecification is a likely pitfall, it is a mistake to decide on process configurations too quickly or without seeking enough input. Second, when use of the new technology is not mandatory, a heavy-handed style increases the danger of nonuse. Third, projects involving more than one company don’t lend themselves to a directive style, for the simple reason that most companies aren’t willing to let someone else make important IT and business-process decisions on their behalf.

In those situations, a consensus-building style is necessary. Leaders of the implementation have to bring its intended users along with them by moving more slowly, seeking their input and ratification of choices. This style has worked well for Alibris, the Internet’s leading source for used and hard-to-find books and one of very few successful independent e-marketplaces.13

Alibris was founded in 1994 by a respected book dealer who used his industry knowledge and contacts to persuade an initial group of dealers to sign up. Since then, whenever the company has changed its technology or business processes — for example, when it moved from charging dealers book-listing fees to charging them a percentage of each book sold — it has consulted with its customers, explaining the rationale and the benefits and making changes based on the feedback. Alibris has also been willing to accommodate the wishes of such large customers, on the distribution side, as Amazon. The company has understood from the beginning that it controls only a tiny portion of the resources required for success and has worked to build consensus and participation with all its customers.

Project Scope One of an implementation manager’s most potent tools is also the most straightforward: the decision about the scope of the effort. A project’s boundaries can be divisional (should it include the sales and marketing department?); geographic (should it embrace the Latin American operations?); or technical (should it include a data warehouse?). There are often compelling reasons for a comprehensive scope; big projects get all the organizational upheaval out of the way, and business benefits are often multiplied as more processes are changed.

However, when inertia, resistance and misspecification are likely pitfalls, implementation leaders should consider throttling back on scope. Smaller projects move faster, lead to less infighting, and present fewer opportunities to configure a technology incorrectly. (Note that reducing scope is not the same as preventing an implementation’s natural tendency toward “scope creep.” Reducing scope is a choice; preventing scope creep is a necessity.)

If possible, it’s best to reduce a project’s scope before it gets under way, but scaling back can still be effective midstream. The medical device manufacturer Becton, Dickinson found its enterprise implementation bogged down in 2000, plagued by a lot of inertia and a bit of resistance. The company’s leaders examined the entire effort and decided to exclude some sites, functions and modules. Afterward, the implementation team was better able to focus on what remained and found the project easier to sell within the company. After scope was reduced, the project tracked well against its milestones.

Project Timing Within certain constraints, managers have a great deal of freedom to expand or compress timelines, move activities forward or backward, and carve up a large implementation into several smaller phases. Few large-scale implementations are currently done in a big-bang fashion, in which all of the new technologies and business processes are introduced at once.

Most implementations proceed through a series of phases, each defined by a combination of functionality, divisions or geographies (or some combination of the three). Phasing can build positive momentum for an effort (thus overcoming nonuse), but its most important advantage is its ability to combat misspecification. Going live in a series of incremental phases provides the opportunity to learn over time what works and what doesn’t, and to recover from earlier mistakes by revisiting IT and business-process decisions. Nike apparently tried to go live with too much, too quickly in the case of the SCM system it purchased from i2.

The main alternative to phasing is a big-bang approach in which the entire new technology is put into use all at once. That approach can be effective when misspecification, misuse and nonuse are not serious threats. In 1996, for example, the disk-drive manufacturer Quantum put its new ERP software into operation all at once throughout the $4.4 billion company.14

Timing decisions are not usually a stark choice between big-bang and incremental approaches. Managers have discretion over how large each step toward full deployment will be and can elect to proceed via a series of small, incremental projects or fewer and larger ones. In general, big steps work to overcome inertia (and to some extent resistance), while smaller ones combat misspecification, misuse and nonuse. Since ERP implementations are more susceptible to the first two pitfalls, they often work better with fewer, larger steps. SCM implementations, on the other hand, are more often derailed by the latter three and so optimally go live in a number of small releases.15

Organizational Preparation Of course, some level of preparation is always necessary; people need to know that a new system is coming and how to use it. Beyond that minimum, however, there is a great deal of variation in the amount of preparation required. For example, on the low end are systems that simply move routine, peripheral processes (such as procuring office supplies or filling out travel and expense forms) online, as well as those that are aimed at sophisticated IT users. Misuse is not likely in these cases, and nonuse can be combated by making the systems mandatory so that they don’t have to be heavily sold to the organization.

Clearly, the main pitfalls requiring extensive preparation are nonuse and misuse. In such cases, the preparation should include communications before and during the implementation about why it is necessary, user training on the new technologies after they are up and running, and help desks and other support during the post-cutover period.

When Hewlett-Packard replaced the fragmented information systems at its California server-manufacturing facility with a comprehensive enterprise system, tasks changed dramatically and jobs became much more interdependent. Even though the company was full of computer-literate users, the implementation’s leaders realized that misuse was a real possibility and so invested heavily in preparation. Significantly, they extended implementation support well past the new software’s go-live date, with specialists from the implementation team remaining on-site to answer questions and help people navigate through the new environment. Within months, the facility was consistently hitting performance levels it had been unable to reach with the old systems.

Again, some level of training is always necessary, but it takes thoughtfulness on the part of an implementation’s leaders to know when to open the spigot of resources and when it’s best to conserve them for other purposes.

The Craft of Leadership

Although many companies have already experienced frustration over an internal enterprise system or a B2B failure, technology-enabled business-process change is far from over. Businesses will continue to replace and integrate their systems and to automate, streamline and otherwise improve their processes with new IT systems. In particular, the emerging technologies of “Web services” hold much promise for linking previously fragmented systems, groups and companies.16

But unless implementation leaders throw away all but the most basic checklist of ground rules and consider each project as a unique effort — one that will have its own quirks and company-specific requirements — the work of IT-enabled business transformation will continue to be plagued by catastrophes and high rates of failure and disappointment. And no technological breakthrough will change that, because technology can never trump organizational, process or human considerations. The successful leadership of an IT implementation will continue to be a subtle craft.

The analysis of potential pitfalls and consideration of appropriate actions to counter them are important elements of that craft. They are certainly not the only ones required to lead a successful process-enabling implementation, but experience has shown that they are necessary ones.