The Curse of Success

In the effort to improve corporate performance by sharing key knowledge among employees across an organization—a practice known as knowledge management—glowing reports of success far outnumber tales of disappointment.

But this picture isn't quite as rosy as many people believe.

That's because there are many projects that initially are labeled a success—and it's only later that negative consequences appear. Some companies, for instance, have found their knowledge-management projects result in an overreliance on a database for problem solving. Others have tried, unsuccessfully, to replicate the same knowledge-management system across different departments. Others have discovered that the original team of contributors in a project ends up squeezing out any knowledge from outside the core group.

Such troubles generally don't show up in the usual measurements of these knowledge-management, or KM, projects. But they hold profound ramifications for organizations that are committed to the cause of KM.

This article seeks to cast a spotlight on the curses of successful KM projects. Three case studies are presented in which a KM system attained a high level of success before exhibiting one or more dysfunctional outcomes: a bank that designed a fully integrated database to assist agents at its customer-service call center; a telecommunications company that supplied engineers at its support centers with a "digital repository" of solutions for technical problems; and a college that built an online forum to facilitate broad faculty participation in developing e-learning programs.

The cases presented were drawn from a larger, continuing study of KM implementation dilemmas and from interviews with a wide spectrum of participants in the KM projects, including cmanagement and front-line staff members. Annual reports, Web sites, in-house publications, email and similar archival sources were consulted as well. Each organization requested anonymity as a condition for its cooperation with the research.

What follows is a look at how each initial success was achieved, the trap each project then fell into, and how others can avoid similar problems in the future.

THE BANK

A consumer bank based in Hong Kong launched a pilot KM system at its call center that markedly improved customer service. The only mistake was attempting to replicate that system throughout the bank.

The pilot system for the bank, which has more than 100 domestic outlets and total assets of more than US$7.2 billion, was a Web-based database whose contents were created and maintained by the call center's roughly 800 agents. Contents included such things as additional information about important customers, helpful phone numbers, and advice on bank procedures, such as what to do if a caller reports a stolen credit card.

Because the system was fully integrated with key applications of the bank, if a caller reported a stolen credit card, an agent could use just one computer screen while initiating the card-cancellation and replacement procedures and consulting the KM database. The agent could quickly find, for example, directories of police stations and hospitals in the vicinity of the customer, if necessary.

Six months after its implementation, a survey of call-center agents found that 87% gave the system a "very high" satisfaction rating. Turnaround times per phone call, too, were slashed to 12 minutes from 23.

Based on this success, management decided to replicate the same type of KM system for five other bank departments simultaneously: marketing, business intelligence, human resource, legal and procurements. Officials in charge of the project thought the replications would be very straightforward. The system in use by the call center was a so-called content-management system that starts out as an empty shell. The users supply the contents. Similar shells were envisioned for the other departments in which users would capture, store, index and retrieve a body of domain-specific knowledge within their divisions. No major obstacles were expected.

DOWNFALL: The extension, however, turned out to be a disaster. For starters, integrating the KM databases with the applications of the other departments was monstrously complex. Across all of the departments, there were more than 50 back-end and legacy systems with which the KM systems had to be integrated. Each integration was unique, and demanded huge amount of resources and time, exceeding budgets and schedules.

Another problem: Tools found helpful at the call center were not nearly as useful elsewhere. For example, the KM search engine was intended for full-text and keyword searches—like call-center agents needed. But the marketing and business-intelligence departments, for example, wanted a different tool: concept search, which is the ability to make connections between patterns of words. A search term such as "priority customers" might turn up results like priority services, exclusive privileges and an internal directory of relationship managers.

Adding to the chaos, most of the other departments were never certain what they wanted out of their KM systems. And with a team from the IT department driving the project, there was a lack of individual responsibility for results.

The extended systems did not attract sustained usage in any organized fashion outside the call center. The culture of sharing and exchanging ideas that existed among the call-center agents, and which kept the contents of the database fresh, proved to be more an exception than the norm.

The poorly conceived replication effort not only failed to deliver the purported benefits of KM, it also misdirected resources and damped staff morale. Subsequent bankwide initiatives promoted as bringing about better organizational performance and operational efficiency were perceived with much skepticism.

THE TRAP: Although one senior manager blamed the problems on the IT team assigned to the implementation, extensive research and interviews at the bank produced a more complex picture. The trap here was one experienced by many organizations: a tendency to rely on only one or a few proven approaches to deal with all of the challenges of the future. Flush with initial success, some organizations unconsciously discount new experiences and become incapable of coping with the demands of new environments as they move forward.