knowledge management project abandonment: an exploratory

Communications of the Association for Information Systems

Volume 16 Article 35

October 2005

Knowledge Management Project Abandonment:An Exploratory Examination of Root CausesWing LamUNiversitas 21 Global, [email protected]

Alton ChuaNanyang University

Follow this and additional works at: https://aisel.aisnet.org/cais

This material is brought to you by the AIS Journals at AIS Electronic Library (AISeL). It has been accepted for inclusion in Communications of theAssociation for Information Systems by an authorized administrator of AIS Electronic Library (AISeL). For more information, please [email protected].

Recommended CitationLam, Wing and Chua, Alton (2005) "Knowledge Management Project Abandonment: An Exploratory Examination of Root Causes,"Communications of the Association for Information Systems: Vol. 16 , Article 35.DOI: 10.17705/1CAIS.01635Available at: https://aisel.aisnet.org/cais/vol16/iss1/35

https://aisel.aisnet.org/cais?utm_source=aisel.aisnet.org%2Fcais%2Fvol16%2Fiss1%2F35&utm_medium=PDF&utm_campaign=PDFCoverPages

https://aisel.aisnet.org/cais/vol16?utm_source=aisel.aisnet.org%2Fcais%2Fvol16%2Fiss1%2F35&utm_medium=PDF&utm_campaign=PDFCoverPages

https://aisel.aisnet.org/cais/vol16/iss1/35?utm_source=aisel.aisnet.org%2Fcais%2Fvol16%2Fiss1%2F35&utm_medium=PDF&utm_campaign=PDFCoverPages

https://aisel.aisnet.org/cais?utm_source=aisel.aisnet.org%2Fcais%2Fvol16%2Fiss1%2F35&utm_medium=PDF&utm_campaign=PDFCoverPages

https://aisel.aisnet.org/cais/vol16/iss1/35?utm_source=aisel.aisnet.org%2Fcais%2Fvol16%2Fiss1%2F35&utm_medium=PDF&utm_campaign=PDFCoverPages

mailto:[email protected]%3E

Communications of the Association for Information Systems (Volume 16, 2005) 723-743 723

Knowledge Management Project Abandonment: An Explanatory Examination of Root Causes by W. Lam and A. Chua

KNOWLEDGE MANAGEMENT PROJECT ABANDONMENT: AN EXPLORATORY

EXAMINATION OF ROOT CAUSES Wing Lam Universitas 21 Global [email protected] Alton Chua Nanyangt Technological University

ABSTRACT

This paper examines the root causes of Knowledge Management (KM) project abandonment. The authors use root cause analysis to identify the causes of KM project abandonment in five well-documented cases of KM drawn from the literature. The findings are synthesized into a Cause-Effect Diagram (CED), culminating in a causal model of KM project abandonment. The model identifies three major categories for causes of KM project abandonment, namely (1) poor project implementation, (2) mismatch between the KM project and the organization’s strategy or existing structure, and (3) content deficiencies related to the creation, capture and access of knowledge content. These three major categories of causes are iteratively refined and eventually root causes emerge. KM project abandonment is compared with IS project failure, and the implications for risk management practices for KM projects are discussed.

Keywords: knowledge management, project abandonment, project failure, critical success factors, risk management

I. INTRODUCTION

Corporate spending on Knowledge Management (KM) increased substantially over the years [Ithia, 2003]. Fuelled by the notion that knowledge is a key resource upon which an organisation’s competitiveness depends [Kogut and Zander, 1992], organisations are implementing various KM initiatives to identify, share, and exploit their knowledge assets. Most KM projects take the form of:

• developing discussion databases

• lessons learned database, • Communities Of Practice (COP),

• technical libraries • starting and transferring best practices.

Highly-publicised KM success stories include Buckman Laboratories’ Knowledge Network [Zack, 1999], Xerox’s Eureka database [Brown and Duguid, 2000], Tech Clubs in DaimlerChrysler, the COPs among quantitative biologists in Eli Lilly [Wenger, et al, 2002], various KM initiatives in BP Amoco [Hansen, 2001] and the Center for Army Lessons Learned [Thomas, et. al 2001].

724 Communications of the Association for Information Systems (Volume 16, 2005) 723-743


It is understandable why organisations are attracted to KM— successful KM

• improves decision-making, • fosters innovation, • accelerates staff development,

• increases productivity, • minimises reinvention and duplication

• lessens the impact of staff attrition

In some cases, the reported benefits from KM are nothing short of spectacular. Xerox, for example, estimates to have saved US$100 million from its Eureka database [Brown and Duguid, 2000]. Indeed, the literature in general appears skewed towards KM success stories and positive accounts of KM.

Despite the KM rhetoric, however, Lucier and Torsiliera, [1997].report that an estimated 84% of KM projects exerted no significant impact on the adopting organisations This finding is contrary to the generally upbeat impression of KM given the literature. Worryingly, the estimate suggests that most KM projects fail to deliver their expected benefits and eventually are abandoned. Organisations would, of course, want to conceal KM project abandoment, at least from public view for fear of negative publicity and possible damage to reputation. Research that attempts to provide insight into the causes of KM project abandonment is therefore especially relevant and timely to the many organisations now seriously considering KM initiatives.

DEFINITION OF SUCCESS

Davenport et al [1998] defines a successful KM project in terms of the following characteristics:

• Growth in the resources attached to the project, including people and budget; • Growth in the volume of knowledge content and usage; • A high likelihood that the project would survive without the support of a particular individual or

two, • Evidence of financial return either for the knowledge management activity itself or for the

larger organization.

GOALS

For the purpose of the research here, we view an organisation as embarking on a KM initiative that may have one or more distinct KM projects each with a specific set of objectives. Typically, these objectives include: • The creation and sharing of reusable knowledge assets, measured for example by the

number of knowledge assets created and the number of times a knowledge asset has been reused in other projects

• The fostering of communities of practice, measured for example by the number of participants and the participation level in terms of the average number of postings per week.

• Improved decision-making, measured for example by the financial savings compared to not having KM within the organisation.

DEFINITION OF ABANDONMENT

No widely-accepted definition exists for an unsuccessful KM project in the literature. An abandoned KM project is one that is prematurely terminated for one reason or another. Thus, even if a KM project meets its original objectives, it may become abandoned because the original objectives are no longer deemed important, or because of changing business priorities and external factors. Furthermore, an organisation that abandons one KM project may not necessarily abandon its KM initiative as a whole.



II. LITERATURE REVIEW: KM SUCCESS FACTORS

Critical Success Factors (CSFs) for KM are widely discussed in the literature. Such CSFs include

• a clear KM vision and strategy [Von Krogh 1998; Maeir and Remus 2003]

• alignment of KM strategy to business goals [Malone 2002]

• a learning culture [Zolingen et al. 2001; Goh 2002; McDermott and O’Dell 2001]

• incentives for knowledge creation and reuse [Lynne 2001],

• a specific community that provides a context for KM to flourish [Dixon, 2000; Wenger et al, 2002]

• continuous top management support [Storey and Barnett, 2000]

• employee empowerment [Liebowitz and Beckman 1999; Stenmark 2003]

• a positive attitude to knowledge sharing [Bock and Kim 2002]

• a flexible organisation structure [Forcadell and Guadamillas 2002]

• usable and up-to-date KM systems [Davenport and Prusak 1999]

• knowledge governance structure for maintaining quality of knowledge content [Dilnutt 2002],

However, the presence of success factors alone is no guarantee of KM success. A KM project may exhibit all the success factors, but if risks to the project are not managed along the way, then the likelihood of success is severely diminished. KM success is therefore dependent not only upon the presence of success factors, but also the effective management of risk.

III. RESEARCH METHOD

RESEARCH QUESTION AND DESIGN

The authors decided to explore the causes of KM project abandonment from an inductive research paradigm in which the theory for KM project abandonment is developed on the basis of empirical evidence. Case-study analysis is a well known approach for exploratory, theory-building research that builds on the rich empirical reality of the case data [Eisenhardt, 1989]. Since single case studies are criticised for leading to results that are not generalisable [Pinto and Covin 1989], this paper adopts a multiple case approach which also allows for more diverse results to be cross-analysed [Yin 1994].

CASE SELECTION

Unsurprisingly, the number of published cases of KM project abandonment pale in number compared to published success stories. An initial, prospective set of cases was drawn up by searching the online versions of three popular databases (ProQuest, Ebsco Host and Emerald) using the search terms ‘knowledge management’, ‘failure’ and ‘abandonment’. We later extended the search to include other databases (such as ScienceDirect, SwetsWise and Web Of Science) and KM text books. Search results that were obviously inappropriate were discarded. As the research was relying on secondary data, the cases were filtered according to two important criteria:

• The case was published in a peer-reviewed scholarly publication, ensuring a certain level of case quality in terms of academic rigour, significance, and substance of case data.

• The case provided sufficient contextual details about the KM project from inception to eventual abandonment for the authors to perform a meaningful level of case analysis. When reviewing each case, we sought to identify three main pieces of information; namely,

♦ the objectives of the KM project,



♦ the outcome of the project, and ♦ reasons that led to the outcome.

Cases which did provide these three main pieces of information were rejected.

A total of eight cases were rejected in the filtering process, four of which are summarized in Table 1.

Table 1. Rejected Cases

Source Case Description Reasons for Rejection Malhotra, [2005]

Cisco implemented a KM initiative that involved real-time enterprise technologies. The aim was seamless integration of real time data within and across its supply chain and customer ordering system so that Cisco could improve its forecasting and decision-making abilities.

• Insufficient details about the project’s inception were given.

• Reasons for the project’s abandonment were not discussed

Davenport, and Prusak, [1999]

Javelin Development Corporation implemented an online knowledge warehouse which was intended to make knowledge available across projects. The aim was to reduce construction time and cost by applying existing design solutions to new situations.

• Insufficient details about how the project progressed, leading to its eventual failure.

Schwen and Hara 2003]

Two cases of derailed KM implementation were presented. One was a high-technology Fortune 50 company while the other was a consulting firm. Both cases were drawn from unpublished dissertations whose content were not easily available..

• The reasons of project’s abandonment in the first case were not provided

• No details were given about the project’s inception in the second case.

McDermott [2004]

The problems of sustaining matured communities of practice in six global companies were reported.

• Details are too scanty to make any sense of how the KM efforts developed.

A set of five cases were selected from the filtering process. While this number of cases is relatively small, it was deemed sufficient for the research here which was investigative and exploratory in nature.

CASE REVIEW PROCEDURE

The authors examined the circumstantial elements of KM project abandonment in each case. Specifically, the authors asked a number of preliminary questions when reviewing each case:

• What were the intended objectives of the KM project? • How were the KM projects implemented? • What was the eventual outcome of the KM project?

This step allowed the authors to familiarize themselves with the case before delving deeper into the case details regarding the causes of KM project abandonment. The authors used root cause analysis [Dew 1991], a well-known approach for diagnosing failure, to analyze each case systematically and develop a model of KM project abandonment iteratively.



CASE DESCRIPTIONS

Summaries of the five cases of KM project abandonment are given next. Readers should refer to the full case for further details.

Case 1: A Global Bank

A global bank spanning across 70 countries decided to implement several KM projects after the departure of a major client who felt it could not receive integrated services across divisions and countries from the bank [Newell, 2001; Scarbrough, 2003]. The main objective of the KM project was to develop a global knowledge network so that the services in the bank could be integrated. By fostering organisation-wide knowledge sharing, the bank believed it would be better positioned to build a global service portfolio. Intranet technology was perceived as central to achieving this objective.

Several independent intranet projects proliferated after the pilot. Among them were OfficeWeb, GTSnet and Iweb. OfficeWeb was designed for the domestic division. The intention was to leverage intranet technology to support the shift towards a more decentralised, entrepreneurial, organisational structure in the branches. The project brought together the relevant branch managers to create a community of users where local knowledge could be shared freely. The project was strategically important for the domestic division. However, despite expending considerable efforts, the project was abandoned after test trials showed that the bandwidth of the existing infrastructure could not support the network traffic generated in Officeweb.

GTSnet was designed for the Global Transaction Services division. The aim was to consolidate the disparate sources of information across the bank and allow users to obtain information from an integrated source. In addition, it provided the possibility to create virtual discussion groups. The project was allocated abundant financial resources and was staffed mainly by external IT consultants who did not possess the relevant business knowledge. Furthermore, during the project development stage, the targeted end users were minimally. involved. When GTSnet was launched, it faced the problem of both supply and demand. There was no impetus for individuals to share their knowledge or access the knowledge of others through GTSnet. As a result, the content in GTSnet became obsolete after a while, and its relevance to the bank diminished.

Iweb was designed specifically for the IT function. Besides being intended as a central repository for storing information, Iweb was to be used as a platform for staff to gain and share expertise. The project was well-resourced with technical staff. State-of-the-art servers were also purchased as part of the implementation requirements. Furthermore, a senior IT manager provided official sponsorship . The manager’s involvement enabled standards to be established for putting up and maintaining contents on the intranet. While Iweb infrastructure was fully operational, it was unable to promote any knowledge sharing even within the IT division. It remained a repository of existing information.

Case 2: A Pharmaceutical Company

A US-owned global pharmaceutical company which specialised in high margin “lifestyle” drugs aimed to accelerate its internal drug development processes. The management was convinced that organisational innovation was critical to this goal, and that organisational innovation could be fostered by overt KM initiatives. Hence, the management committed a substantial amount of political and financial resources to implement three KM projects, namely, ‘Lessons Learned’, ‘Warehouse’ and ‘Electronic Café’ [McKinlay, 2002].

‘Lessons’ was a highly structured debriefing exercise conducted by each workgroup at the end of a major drug development process. It was intended as a method to archive corporate lessons and to prevent the loss of operational knowledge in the drug development process. ‘Lessons’ yielded uneven results within three years of its implementation. Some workgroups deployed the ‘Lessons’ process rigorously, but most conducted it perfunctorily. The output was a list of dissatisfaction with how standard operating procedures were applied rather than critical



reflections on the procedures themselves. Thus, instead of fostering organisational innovation, ‘Lessons’ became a ritualised reinforcement of routines. There was no mechanism to sift through the lessons compiled. Neither were there any opportunities to extend the scope of the exercise beyond existing procedures.

‘Warehouse’ was an organisation-wide groupware populated with content based on the ‘Lessons Learned’ debriefings. Its objective was to capture not only problems and solutions but the details of administrative and decision-making processes. It provbided features such as common repositories, discussion forums and communication facilities which supported coordination and collaboration across workgroups. In practice, however, ‘Warehouse’ could not be adapted to the specific context of each workgroup. It was thus deemed to be irrelevant to the day-to-day operational processes. Moreover, contributing to ‘Warehouse’ was perceived as a loss of personal expertise while accessing ‘Warehouse’ was perceived as a sign of inadequacy. Hence, ‘Warehouse’ did not attract spontaneous contribution and access.

‘Café’ was a set of linked websites based on the anecdotes of individuals involved to the drug development programmes. It was intended as a platform for self-reflection and sharing of personal experiences among a small group identified as organisational innovators. Within ‘Café’, unrelenting deadlines and operational constraints were temporarily forgotten. Individuals were liberated to digress from reality and to discuss hypothetical issues or explore radical alternatives. This generative and open-ended nature of ‘Café’ inadvertently made its relevance and practicality questionable. Furthermore, the exclusive access to ‘Café’ limited its potential for expansion. As a result, the existence of ‘Café’ became marginalised.

Case 3: A Manufacturing Company

A European manufacturing company that operated more than 60 production units in 30 countries implemented three distinct KM projects, namely, ‘Production Project’, ‘Supply Chain Project’ and ‘Design Project’ [Kalling, 2003].

The focus of ‘Production’ was on capturing, documenting, and sharing knowledge about production methods such as machine maintenance methods and safety prevention. The main aim was to cut production costs.

‘Supply’ was intended to improve and distribute knowledge about offered products in the downstream supply chain. The aim was to enhance product functionality and better understand the effects of product design on the economics of transport and warehousing.

The objective of ‘Design’ was to improve structural product design so that designers could construct a prototype with minimal raw materials.

Two years after implementation, ‘Production’ was successful in capturing knowledge from the external environment and from different plants within the company, and in transferring the knowledge to the plant that needed it. However, its aim to promote the application of the new knowledge resulted in mixed success. Of 40 plants studied, ten plants did not apply the new knowledge mainly because they did not perceive a production performance gap in their plants. They were unconvinced of the value created by applying the new knowledge. It was later discovered that the rest of the plants which applied the new knowledge actually saw a significant improvement in their production performance.

‘Supply’ involved soliciting the requirements on the company’s products in the downstream supply chain such as the use and transportation of the products, storing conditions, order sizes, and packing features. Knowledge culled from customers, warehouse delivery centres, transporters, and end-consumers was codified into a software system made available in the intranet. However, when the software system was eventually launched, it was under-utilised. Users commented that the software merely provided them with information they already possessed.



Moreover, the software neither resulted in increased sales volume for sales staff nor helped create better products for designers.

‘Design’ focused on helping designers use state-of-the-art methods for structural design and predicting tenacity of products under certain conditions. The domain expertise of two R&D scientists was codified and resulted in a highly sophisticated software system. However, when the system was launched, designers perceived the system to be too cumbersome and difficult to understand. In addition, the system did not reduce the raw material costs or the amounts of prototypes as intended. Nonetheless, given that it was graphically appealing, the system was used for publicity purposes and in new staff orientation. After a while, since the system was largely neglected by designers, it was not updated and became obsolete.

Case 4: A European-Headquartered Company

The management of a European-headquartered company was convinced that a knowledge-based learning organisation was the key for the company to achieve cost-effectiveness, competitiveness, and better management of business risks. For this reason, it commissioned a KM project team which consisted of nine management staff, among whom were several KM enthusiasts [Storey and Barnett, 2000].

The project team agreed that the immediate priority was to create awareness among all staff so that everyone could be kept informed of the events, activities and the internal expertise within the company. To support the awareness campaign, the team drafted plans to implement frequent “town hall meetings” and to create informative web-pages of the management and all business units. In addition, several other plans such as organising staff into COPs, identifying internal knowledge champions and formalising post-project reviews were confirmed and endorsed. The team was also able to secure commitment from the top management to exemplify and to foster a more open culture. Instances of innovation and knowledge sharing would be publicly recognised and celebrated.

The team made a decision not to engage help from external facilitators or consultants. It spent little time deliberating on the potential barriers to the project and did not consider the content of rolling out a pilot even though the scale of the project was significant. However, the team recommended the appointment of a part-time Chief Knowledge Officer and a dedicated IT resource. It turned out that these recommendations did not materialise.

Within two months, a note was sent to all staff introducing the KM project and its objectives. Informal feedback from grassroots indicated a sense of positive anticipation. In the subsequent meetings, the team fine-tuned the plans and distributed the tasks among its members.

As the project progressed, the team realised that the KM project had developed on the assumption that IT systems would be the foundation for all activities and processes. Furthermore, the team found out that the Website and intranet development were divided between the IT and media affairs. These two departments agendas diverged and they held conflicting views as to how the IT systems should be developed. The IT manager did not appear to be genuinely committed to the KM project since no developments were forthcoming from the IT department. Other members in the team suspected that the IT manager’s involvement in the KM project was to gain a dominant position in the company’s strategy, methodology, and budget. As a result, tension started to grow within the project team.

Meanwhile, external market conditions deteriorated. As a result, the company to implement a major organisational restructuring exercise which saw a sweeping outsourcing and staff reduction programme. The KM project faded and became lost in the turbulence.

Case 5: A Global Company

A global company, which was one of the top ten organisations in its industry with sales of some US$10 billion, lost a number of deals because it was unable to offer integrated order handling



solutions [Braganza and Mollenkramer, 2002]. Based on the recommendations of external consultants, the management commissioned an initiative known as Alpha Project. The aim of the project was to create a ‘blueprint for gaining and maintaining global order handling services market leadership’. Underpinning Alpha was a deliberate and comprehensive attempt to manage knowledge across the company.

The number of staff assigned to Alpha grew to some 100 employees. Several functions such as Sales, Product Implementation, Operations, IT and knowledge management were created within Alpha. In addition, three teams, namely, business architecture, IT and knowledge content and design, were formed. The senior management committed a significant amount of funding: US$300 million over five years coupled with the understanding that this initiative would be operated at a loss at the beginning. Eventually, Alpha’s profile was elevated and it became a formal line of business in the organisation.

One of Alpha’s priorities was to develop a dynamic IT infrastructure to support all KM activities. Known as the ‘Knowledge Enabled Worktable’, it was designed to store relevant information automatically, support decision making, and allow users to enter comments and insights easily. The plan was to design a network of function-specific Worktables so that staff could gain customised access to Alpha’s knowledge base.

Due to the teething problem of using new technology and the poor translation of design requirements to systems functionalities, the IT team could not complete the first Worktable for the Sales function on schedule. Meanwhile, the knowledge content and design team developed a large amount of content. Fearing that the delay could dampen interest in KM, the knowledge content and design team sought to publish its content through an intranet system. However, because many offices in other locations could not access the Intranet the system was not widely accepted. Much of the content needed to be transferred back to Lotus Notes currently in use.

While the Worktable application was still under construction, the knowledge content and design team engaged an external consulting firm to develop another intranet system as a quick alternative to making its content available to others. This move was perceived by the IT team as an invasion into its territory. Even though there was an increase in usage and content, the intranet was treated with scepticism by the rest of the functions in Alpha.

By the end of the year, the viability of the Worktable was in doubt. Given the high dependence and unsustainable expenditure on external IT resources, Alpha was perceived to be losing control over its IT-related projects. Thus, the management curtailed the Worktable project and dissolved the IT function in Alpha. Following that decision, the management also lost faith in the value and relevance of the knowledge management function and disbanded it completely.

Case Summaries

A summary of the five cases is given in Table 2.

Table 2. Case Summaries

KM Objectives Nature of KM solution Issues

Case 1: A Global Bank

To integrate the bank services globally

Corporate Intranet Bandwidth limitations, lack of incentive to share knowledge, obsolete content

Case 2: A Pharmaceutical Company

To accelerate the internal drug development processes

Lessons learnt database, groupware and informal websites

Tendency to criticize rather than innovate, inability to personalize, sharing seen as a loss of personal knowledge



Case 3: A Manufacturing Company

To improve overall productivity

Documentation tools and corporate intranet

Knowledge not useful, cumbersome tools

Case 4: A European-headquartered Company

To achieve cost-effectiveness, competitiveness and better manage business risks

Websites, COPs, knowledge champions

No pilot project, internal politics

Case 5: A Global Company

To improve its order handling line of business

Worktable, corporate intranet

Delay in technology implementation, unsustainable IT expenditure

IV. CASE DATA ANALYSIS

CASE ANALYSIS PROCEDURE

To analyse the reasons for KM project abandonment systematically in each case, the authors conducted a root cause analysis [Dew 1991]., A root cause is the most basic reason for an undesirable condition or problem Wilson et al. [1993]. If the real causes of a problem are not identified, then the firm is merely addressing the symptoms and the problem will continue to exist. For this reason, identifying the root causes of KM project abandonment was seen as critical to understanding why a project really failed.

The Cause-and-Effect Diagram (CED), a widely used root cause analysis tool, was used to assist the authors in root cause analysis. Ishikawa [1982] advocates the CED as a tool for breaking down potential causes into more detailed categories so they can be organized and related into factors that help identify the root cause. The authors used the following procedure:

• Case 1 (the global bank).was separately analyzed by authors 1 and 2, who each independently created a CED for Case 1

• The authors discussed the CEDs they had each created for Case 1, highlighting similarities and differences between the CEDs and the rationale for their creation. The individual CEDs were merged into a single CED (merged-CED) agreed to by both authors.

• Case 2 (the pharmaceutical company) was analyzed separately by authors 1 and 2. This time, the authors independently refined merged-CED in light of the findings in Case 2.

• The authors discussed the refined merged-CED they each created in the same way as before, and agreed on a new merged-CED.

• The procedure was repeated for the remainder of the cases, until an agreed CED finally emerged from the analysis of all the cases.

An illustration of this process is shown in Appendix I where the Case 1 CEDs separately generated by the two authors were synthesized into a merged CED for Case 1 after further discussion. The use of the procedure also allowed for some triangulation because the cases were separately reviewed by each author.

CAUSAL MODEL OF KM PROJECT ABANDONMENT

The result of our root cause analysis culminated in a causal model of KM project abandonment, the final CED, shown in Figure 1.



Figure 1. Causal Model of KM Project Abandonment

In the CED, the analyst traces backwards so that the causes, and eventually the root causes, which are the leaf nodes in the CED, are revealed. From our analysis, three main categories of causes for KM project abandonment were identified, namely:

• poor project implementation, of the kind that might afflict any non-trivial project,

KM project abandonment

Organizationalmismatch

Weak business case

Lack of KM measurement

Techno-Bias

Lack of clear KM requirements

Lack of user involvement

Imprecise KM problem definition

Stakeholder conflict

Poor project implementation

Underestimated complexity

Excessive technology costs

Project delays

Content deficiencies

Lack of project support

Shortfall in required expertise

Knowledge hoarding

Lack of knowledge distillation mechanism

Poor perceptions of knowledge sharing

Out-of-date knowledge

Poor knowledge access

Poor tool usability or reliability

Lack of technology scalability

Technology mismatch

Knowledge ‘camouflage’

Root Causes



• organizational mismatch, which occurs when the KM project is not grounded in the organisation’s strategy or well-aligned to existing organisational structures and roles, and

• content deficiencies, which refers to issues associated with the creation, capture and access of knowledge content.

The following section examines the root causes in each category in greater detail, using references from the cases to support and illustrate the analysis. While the authors do not claim that the causal model for KM project abandonment is comprehensive, it does address many of the problems that KM projects are likely to face.

V. ROOT CAUSES OF KM PROJECT ABANDONMENT

CATEGORY 1: POOR PROJECT IMPLEMENTATION

A KM project may become abandoned because of issues related to the management and implementation of the project. In the cases analysed, poor project implementation often manifested itself as excessive technology costs and project delays. Excessive technology costs are in turn caused by under-estimation of the complexity of the project, while project delays could be attributed to the shortfall in required expertise and the lack of project support.

Root Cause #1: Under-Estimated Complexity

When a KM solution is dedveloped that is more complex than what was expected, a project team expends more time and effort than originally anticipated, which in turn leads to an escalation in project costs. In Case 3, for example, ‘Design’ was a KM solution that utilised a highly complex software system involving sophisticated front-end user-interface and back-end processing components that were never imagined at the start of the project. In Case 5, the project was abandoned because the IT maintenance costs became unsustainable. With a better understanding of the true complexity of the KM solutions, both projects might have resulted in more positive outcomes.

In addition to excessive technology costs, poor project implementation is often characterised by significant delays to the original project schedule. In the cases examined, poor implementation was caused by either a shortfall in expertise or a lack of project support.

Root Cause #2: Shortfall in Required Expertise

The importance of attracting and maintaining key personnel or ‘gurus’ on IS projects is well recognized [Curtis, Krasner and Iscoe 1988]. In Case 1, GTSnet was staffed by external IT consultants who did not possess the relevant business knowledge, and who were unable to garner support internally when the KM solution was officially launched. In some cases, projects may seek to bring skills externally. However, bringing external consultants onboard the project is not always helpful, such as in Case 5, where the engagement of three external consulting firms caused the KM project to meander and created confusion.

Root Cause #3: Lack of Project Support

Senior management support is not only required at the start of the project, but also throughout the lifecycle of a project. In Case 4, for example, management support was evident at the start of the project. However, when management faced a crisis when the business climate changed, KM was viewed as optional and ‘nice-to-have’ rather than an integral part of the business operation. The partial withdrawal of support was sufficient to put the project into uncertainty, causing the project to drag and slip. Project support at the user level is also important. Users may begin to lose interest or become disenchanted with a project if they feel that a KM solution is not addressing their needs. In Case 3, for example, when ‘Supply’ was launched, it was under-utilised because users found that the software merely provided them with information they already possessed.

CATEGORY 2: ORGANIZATIONAL MISMATCH



Organisational mismatch occurs when the KM project is not grounded in the organisation’s strategy or well-aligned to existing organisational structures and roles. The five causes of organisational mismatch that emerged from our analysis are a bias towards technology, a weak business case for KM, the lack of clear KM requirements, the lack of KM measurement, and technology mismatch.

Root Cause #4: Techno-Bias

Techno-bias occurs when a technology-centric view of KM is taken while cultural, organizational, and other softer aspects are ignored. For a long time, technology was perceived to be the panacea for all knowledge management problems because it represents a highly tangible and visible solution [Silver, 2000]. However, several scholars and practitioners have cautioned against excessive focus on technology [Davenport and Prusak, 2000; Nonaka and Takeuchi, 1995], arguing that technology is merely an enabler that supports knowledge management efforts. In Case 5, for example, there was an over-reliance on IT systems to manage knowledge in Alpha to the extent that tacit knowledge and behavioural issues received scant attention.

Root Cause #5: Weak Business Case

A weak business case can be considered one that yields insignificant tangible or intangible benefits. It is unlikely that a weak business case was well-thought through. In Case 3, when ‘Supply’ was launched, it was under-utilised because users found that the software merely provided them with information they already possessed. Moreover, ‘Supply’ neither resulted in increased sales volume for sales staff nor helped the designers create better products.

Root Cause #6: Lack of KM Measurement

The absence of any systematic effort to track and measure the success of the KM project can also be a cause of organisational mismatch, providing little opportunity to correct mistakes and realign KM efforts. Even when some KM measurement took place, opportunities to publicise KM success stories may not be seized. For example, in Case 3, out of 40 plants studied in ‘Production’, ten plants did not apply the new knowledge largely because they did not perceive a production performance gap in their plants. Even in the face of evidence from other plants indicating improvements in production performance, they remain unconvinced of the value created from applying the new knowledge.

Root Cause #7: Technology Mismatch

Technology mismatch occurs when there is no clear vision of how technology can be used to support KM. Consequently, the technical vision can become misaligned to the overall goals of the project. In Case 2, the technical architecture of ‘Café’ was relatively simple, but lacked appropriate collaboration functionality to support a central goal of the project which was the development of communities of practice. In Case 4, the IT vision shifted from being based around Websites to a document management system because Websites were later acknowledged to be inappropriate for supporting the necessary KM processes.

One of the major dimensions of organisational mismatch is a lack of clear KM requirements. This dimension is consistent with the widely-held view in the IS literature that a lack of clear requirements is a major cause for IS project failure [Dvir et al. 2003; Pinto and Mantel 1990]. Requirements engineering in the IS field therefore attracted significant research about process, methods, and best practices [Juristo et al. 2002]. Three root causes for a lack of clear KM requirements emerged from our case analyses,

• an imprecise KM problem definition, • stakeholder conflict, and • a lack of user involvement.



Root Cause #8: Imprecise KM Problem Definition

A KM problem that is ‘fuzzy’ in nature may not easily lend itself to formal and precise definition. Even when actual KM users are accessible, there may still be no clear agreed articulation of the KM problem, so developing a solution becomes fraught with danger. In Case 5 for example, the failure to construct a ‘global’ view of the KM problem from multiple stakeholders led to significant problems in integrating the distributed knowledge of different groups within the organisation.

Root Cause #9: Lack of User Involvement

User involvement is long recognised as a success factor in IS projects [Whittaker 1999]. Similarly in KM, it is important to involve the intended end-users throughout the project to gain ownership and acceptance over the solutions eventually developed. In Case 1, GTSnet did not involve the targeted end users during the implementation stage and the end users predictably ended up with a solution that did not meet their needs. More significantly, the project team failed to convince users of the importance of the project to the success of the Division.

Root Cause #10: Stakeholder Conflict

Conflict is recognized as an inevitable part of most projects involving multiple stakeholders [Kotonya and Sommerville 1996]. KM projects typically involve multiple project stakeholders because KM is an enterprise solution that spans across multiple organisational units. Conflict can arise between stakeholders that, if left unresolved, has a disruptive effect on the progress of the project and morale of the project participants. In Case 4, the KM team failed to manage the political processes between the IT and media affairs departments where issues about ownership and accountability over roles and responsibilities undermined the project from an early stage. Had such politics been successfully managed, the outcome of the project could have been more positive.e.

CATEGORY 3: CONTENT DEFICIENCIES

The core of a KM solution is its knowledge content. In our analysis, we discovered several issues relating to the creation, capture and access of knowledge content. Three causes for content deficiencies are poor knowledge access, knowledge hoarding and out-of-date knowledge. Poor knowledge access, which refers to the difficulty which users encounter while seeking to access knowledge, can be traced to three root causes, namely, lack of technology scalability, poor tool usability or reliability and knowledge camouflage. Knowledge hoarding refers to the strong tendency among employees to keep knowledge to themselves. It is caused by the poor perception of knowledge sharing. Out-of-date knowledge, which refers to the obsolescence of knowledge stored in electronic repository, is caused by the lack of knowledge distillation mechanism.

Root Cause #11: Lack of technology Scalability

A lack of technology scalability occurs when the technical infrastructure is unable to support the required volume of users due to bandwidth and other technical limitations. High loads on the system affect performance and system responsiveness, particularly where the KM solution may be sharing bandwidth with other enterprise applications on the network. Expansion of the knowledge base might also be limited when a knowledge base has been designed to handle only a limited volume of knowledge objects. This is evidenced in the failure of the OfficeWeb project in Case 1, which was attributed to a lack of bandwidth to support increased network traffic. Interestingly, this problem emerged during an early stage of the project rather than at a later stages, indicating a significant lack of foresight.

Root Cause #12: Poor Tool Usability or Reliability



KM tools that suffer from poor usability are likely to discourage and frustrate potential end users. In the case of end-users who are not IT-savvy, poor usability can present an unnecessarily steep learning curve that users may be unwilling or unable to climb. In Case 3, ‘Design’ was perceived to be too cumbersome and difficult to be understood. This impeded its wide-spread adoption among the intended user-base within the organisation. The adoption of a KM tool can also impeded by poor reliability due to software bugs or architectural instability.

Root Cause #13: Knowledge Camouflage

Knowledge can be camouflaged in such a way that it is hidden from the user or presented in a form that is not easily digestible. In Case 5, critical knowledge that straddled across multiple functional groups was neglected and the content was developed in fragments from different groups of KM users. Hence, knowledge had to be pieced together by the user before it was useful. In Case 2, ‘Warehouse’ could not be adapted to the specific context of each workgroup. It was thus deemed to be irrelevant to day-to-day operational processes. Also, the open-ended nature of ‘Café’ made it difficult to locate important knowledge from a sea of discussion. Users needed to spend considerable effort searching for relevant knowledge, calling into question the usefulness of the KM solution.

Root Cause #14: Poor Perceptions of Knowledge Reuse

Knowledge reuse may be frowned upon as a reflection of an individual’s own lack of creativity and innovation. In Case 2, for example, accessing ‘Warehouse’ was perceived as a sign of inadequacy. In addition, individuals may be less trusting of knowledge that came from elsewhere, i.e. the ‘not invented here’ syndrome. In Case 2, knowledge sharing and contributing to ‘Warehouse’ was regarded as detrimental to the individual. A perceived loss in personal expertise raised concerns over job security.

Root Cause #15: Lack of Knowledge Distillation Mechanism

Where there is no effective mechanism to distil new knowledge from debriefings and discussions, knowledge quickly becomes outdated. In ‘Lessons’ [Case 2], no mechanism was available to sift through the lessons compiled. Neither were opportunities provided to extend the distillation exercise beyond the scope of existing procedures. Consequently, the output from ‘Lessons’ was essentially an expression of dissatisfaction with how standard operating procedures were applied rather than critical reflections on the procedures themselves. In Case 3, poor content structuring led designers to neglect ‘design’ due to its ineffectiveness in helping to reduce the raw material costs. As a further consequence, designers made little effort to update its knowledge base and the knowledge based failed to grow.

VI. DISCUSSION

CONTENT DEFICENCIES AS PART OF THE KNOWLEDGE LIFECYCLE

The first two categories of KM project abandonment, poor project implementation and organizational mismatch, are more widely discussed in the literature. than the third category of content deficiencies. The causal model of KM project abandonment identified some of the root causes of content deficiencies, but falls short of providing a coherent model for content management. We observe some resemblance between content deficiencies as a category of KM project abandonment and Birkinshaw and Sheehan’s [2002] notion of the knowledge lifecycle.

“new knowledge is born as something fairly nebulous and that it takes shape as it is tested, matures through application in a few settings, is diffused to a growing audience and eventually becomes widely understood and recognized as common practice”. Birkinshaw and Sheehan [2002]



Knowledge thus progresses through four stages of a lifecycle: (1) creation, (2) mobilization, (3) diffusion and (4) commodization. Furthermore, we can

Birkinshaw and Sheehan’s knowledge lifecycle is a framework within which we offer a proposed set of content properties, that are described in Table 3.

Table 3 Knowledge Lifecycle and Content Properties

Description of Stage Content Property Consequence of Content Deficiency

creation Content starts out as an idea which may be quite abstract and fuzzy

• content is testable The content is discarded or lost because it can not be articulated or tried out.

mobilisation Content becomes concrete and its value established through testing and validation

• content is well-formed

• Content is validated

Content can not be properly understood and applied because it is not well-formed. Content is not viewed as reliable because it is not validated.

diffusion Content gets diffused into the marketplace, and is available to anyone

• Content is accessible

Content does not reach those who most need it.

commodization Content is widely accepted as common practice

• Content is trusted

• Content is up-to-date

Content is discredited or viewed with suspicion because it is not trusted or because it is out-of-date.

Table 3 explains how content deficiencies, characterized in terms of the absence of certain content properties, can affect KM success and failure.

• In the creation stage, content must be testable so that it can be scrutinized or at least discussed.

• In the mobilization stage, content must be well-formed to be understood, applied, and validated so that its reliability can be established.

• In the diffusion stage, content must be accessible, i.e. knowledge content reaches the intended users. Reasons why content may not be accessible include limitations in technology, knowledge camouflage and knowledge hoarding, as identified in our causal model of KM abandonment.

• In the commoditization stage, content must be trusted by the user community at large and kept-up-to-date.

One of the root causes identified in our causal model of KM project abandonment, #13: knowledge camouflage, reflects the need for knowledge to be presented in a form that is digestible to the user. Hansen et al. [1999], for example, discusses the importance of communicating knowledge to a particular set of users as key to a personalization strategy in KM.



Chua [2004] considers personalization as a central component of any KM system architecture. Majchrzak et al. [2004] also mention the importance of adaptability, and whether an idea can be modified to fit a new problem. The concepts of personalization and adaptability, although different concepts, appear to go hand-in-hand. Hence, a further content property in addition to that proposed in the Birkinshaw and Sheehan framework is that content should be adaptable or personalizable.

COMPARISON WITH IS PROJECT ABANDONMENT

KM projects often involve the delivery of information systems (IS), such as an Intranet, database, and electronic discussion forms. Therefore, it is meaningful to draw comparisons between KM project abandonment and IS project abandonment, a subject which is widely studied by researchers [Boehm 1989, Whittaker 1999]. Many of the root causes associated with poor project implementation (Category 1) in the causal model of KM project abandonment, such as underestimating complexity and shortfall in required expertise, are also common to IS project abandonment. Similarly, under organisational mismatch (Category 2), issues related to a weak business case and lack of clear requirements are also problematic for IS projects. Given the established and well-documented best practices for project management in the form of the Project Management Institute’s [PMI 2004] project management body of knowledge (PMBOK), it seems appropriate that these ideas should used in managing KM projects. Even so, some researchers do not see KM initiatives as a deterministic, milestone-driven venture in the way that IS projects are typically viewed (.e.g., Wenger, et al, [2002]). Unlike an IS project which ends when a software solution is delivered to the client, a KM project includes institutionalisation of the KM solution. KM projects therefore tend to be ongoing and include broader organisational and cultural considerations.

RISKS UNIQUE TO KM PROJECTS

The root causes under content deficiencies (Category 3) are unique to KM projects where, unlike typical IS projects, KM projects strongly emphasize knowledge content. Arguably, content is the heart of a KM solution. Therefore, content issues cannot be ignored. Root causes were examined individually in Section V. However, they cut across technology (e.g. knowledge camouflage), process (e.g. lack of knowledge distillation mechanism) and cultural concerns (e.g. poor perceptions of knowledge sharing).

An important characteristic of knowledge is its relevance to problem-solving. As new problems emerge, knowledge must be updated so that it is relevant to the problem-solving situation. In certain industries, such as biosciences and pharmaceuticals, the shelf-life of knowledge can be very short, so there is great significance attached to establishing processes within the organisation that addresses out-of-date knowledge content and the continual introduction of new content.

PRACTICAL IMPLICATIONS

The overall implication from our research is that KM projects, like all projects, are subject to risk. KM practitioners need to be aware of such risks and manage them accordingly to ensure continued project survival. Many specific implications for KM risk management practice emerged from our research, some of which confirm what is already known. Less well-known, however, are the implications for KM risk management practice related to content deficiencies, which are:

• A KM requirements document should be written that describes, amongst other things, the KM problem being addressed and the nature of the KM content needed to solve the problem. The KM requirements document should be a key deliverable in the KM project plan and should be signed-off by the user representative before the project is allowed to move to the implementation stage.

• Prototyping should be encouraged to validate with users that content is properly structured and relevant to problem-solving. Walking through various KM-solving scenarios during the



early design of a KM solution would generate useful feedback from users and other project stakeholders.

• Operational prototypes should also be used to test knowledge access, technology scalability, usability and reliability.

• Organisational processes should be defined to address how knowledge within the organisation is to be acquired, captured, and maintained. For implementation, a resource plan should be drawn up that describes how resources will be allocated to support such processes.

• To address knowledge hoarding and poor perceptions of knowledge reuse, management should institutionalize KM as a formal activity, and where appropriate, include it in individual work plans and performance objectives. In some cases, management may wish to consider financial or other rewards for contribution to KM activities. The human resources department should be involved in integrating KM into the personal development of employees.

VII. SUMMARY AND LIMITATIONS

This paper analyses the root causes of KM project abandonment and addresses the question of why organisations fail to achieve widespread adoption of KM. Five cases of KM project abandonment from the literature were examined and root cause analysis was used to develop and propose a causal model of KM project abandonment, the main contribution of the paper. The findings of the research revealed three main categories of causes of KM project abandonment, namely poor project implementation, organisational mismatch and content deficiencies. The causes of abandonment relating to poor project implementation and organisational mismatch can be closely compared to project risk on any IS project. However, the causes of abandonment relating to content deficiencies, such as out-of-date knowledge, knowledge hoarding, and poor knowledge access, are more specific to KM projects. In terms of practical application, the causal model for KM project abandonment can be used by itself as a risk management tool to facilitate KM project planning or as a framework for reviewing and steering ongoing projects.

The multi-case analysis approach used here suits the formative, exploratory research related to the research objectives described in this paper. However, several limitations are worth mentioning. The use of only five cases, albeit rigorous and richly-documented ones, naturally introduces a certain element of bias. The reliance on secondary data is also not ideal. To address both these limitations, an area of future work is to validate the causal model of KM project abandonment on further cases where researchers are able to access primary data. Performing similar analysis across more cases is likely to produce more generalised results and lead to developing a more complete causal model for KM project abandonment. In addition, improvements in research procedure and triangulation, such as the use of multiple researchers to analyse cases independently, will go some way towards increasing the reliability of the research findings.

This article was received on November 29, 2004. It was with the authors for 4 months for 2 revisions. It was published on October 25, 2005

REFERENCES Editor’s Note: The following reference list contains hyperlinks to World Wide Web pages. Readers who have the ability to access the Web directly from their word processor or are reading the paper on the Web, can gain direct access to these linked references. Readers are warned, however, that 1. these links existed as of the date of publication but are not guaranteed to be working thereafter. 2. the contents of Web pages may change over time. Where version information is provided in the References, different versions may not contain the information or the conclusions referenced. 3. the author[s] of the Web pages, not AIS, is [are] responsible for the accuracy of their content.



4. the authors of this article, not AIS, are responsible for the accuracy of the URL and version information.

Birkinshaw, J. and Sheehan, T. [2002], Managing the Knowledge Life Cycle, Sloan Management Review, 44(1), pp.75-83.

Boehm, B. [1989], Software Threat Management, Los Alamitos, CA: IEEE-CS Press, 1989. Bock , G.W. and Kim, Y. [2002], Breaking the Myths of rewards: An Exploratory Study of Attitudes

About Knowledge Sharing, Information Resources Management Journal, 15[2], pp.14-21, April-Jun 2002.

Braganza, A., and Mollenkramer, G.J., [2002], Anatomy of a Failed Knowledge Management Initiative: Lessons from PharmaCorp’s Experiences, Knowledge and Process Management, (9)1, pp 23-33

Brown, J.S., and Duguid, P., [2000], Balancing Act: How To Capture Knowledge Without Killing It, Harvard Business Review, , (78)3, May/Jun pp 73 – 80

Chua, A. [2004], Knowledge Management System Architecture: A Bridge Between KM Consultants and Technologists, International Journal of Information Management, (24)1, pp 87 – 98.

Davenport, T.H., De Long, D.W., and Beers, M.C., [1998], Successful Knowledge Management Projects, Sloan Management Review, (77)2 Winter, pp 43 – 57

Davenport, T.H. and Prusak, L., [1999] Working Knowledge, Boston: Harvard Business School Press,

Dew, J. R. [1991]. In Search of the Root Cause. Quality Progress, 24[3]: 97-107 Dilnutt, R. [2002], Knowledge Management in Practice, Three Contemporary Case Studies,

International Journal of Accounting Information Systems, (3)2, pp.75-81, 2002. Divr, D., Raz, T. and Shenhar, J. [2003], An Empirical Analysis of the Relationship Between

Project Planning and Project Success, International Journal of Project Management, 2(21), pp.89-95.

Eisenhardt, K.M. [1989], Building Theories form Case Study Research, Academy of Management Review, 14(4), pp.532-550.

Firestone, J.M., [2000], Knowledge Management: A Framework for Analysis And Measurement, White Paper 17, Wilmington, DE: Executive Information Systems Inc. http://www.dkms.com/papers/kmfamrev1.pdf, accessed 10 August 2004

Forcadell, F.J. and Guadamillas, F. [2002], A Case Study on the Implementation of a Knowledge Management Strategy Oriented to Innovation, Knowledge and Process Management, 9(3), pp.162-171, 2003.

Goh, S.C. [2002], Managing Effective Knowledge Transfer: An Integrative Framework and Some Practice Implications, Journal of Knowledge Management, 6[1], pp.23-30, 2002.

Hansen, M.T., Nohria, N. and Tierney, T. [1999], What’s Your Strategy for Managing Knowledge?, Harvard Business Review, (78)2, March-April, pp.106-116

Hansen, M. T., [2001], Introducing T-Shaped Managers, Harvard Business Review, , ( 79), 3, March, pp106- 116

Ishikawa, K. [1982]. Guide to Quality Control [2nd ed.]. Tokyo: Asian Productivity Organization. Ithia, A., [2003], UK Lawyers Spend More on KM, KM Review; (5)6 Jan/Feb, p11 Juristo, N., Moreno, A.M. and Silva, A. [2002], Is the European Industry Moving Toward Solving

Requirements Engineering Problems?, IEEE Software, 19(6), November/December, pp.70-77.

Kalling, T, [2003], Knowledge Management and the Occasional Links with Performance, Journal of Knowledge Management, (7)3 pp. 67-81

Kogut, B., and Zander, U., [1992], Knowledge of the Firm, Combative Capability and the Replication of Technology, Organization Science 3(3), pp.383–397.

Kotonya, G. and Sommerville, I. [1996], Requirements Engineering with Viewpoints, Software Engineering, 1[11].

Liebowitz, J. and Beckman, T. [1998], Knowledge Organizations: What Every Manager Should Know, Boca Raton, FL: CRC Press

Lincoln, Y.S., and Guba, E.G., [1985] Naturalistic Inquiry, Beverly Hills, CA: Sage



Lucier, C., Torsiliera, J., [1997], Why Knowledge Programs Fail, Strategy and Business, 4th quarter, 14-28. http://www.strategy-business.com/ press/article/13007?pg=0 accessed 21 Oct 2005.

Lynne, M. [2001], Toward a Theory of Knowledge Reuse: Types of Knowledge Reuse Situations and Factors in Reuse Success, Journal of Management Information Systems, 18[1], pp.57-93.

Maier, R. and Remus, U. [2003], Implementing Process-Oriented Knowledge Management Strategies, Journal of Knowledge Management, 7[4], pp.62-74.

Malhotra, Y., (2005) Integrating Knowledge Management Technologies in Organizational Business Processes: Getting Real Time Enterprises to Deliver Real Business Performance, Journal of Knowledge Management, (9)1, pp 7 – 27.

Malone, D. [2002], Knowledge Management A Model for Organizational Learning, International Journal of Accounting Information Systems, 3(2), pp.111-123, 2002.

Majchrzak, A., Cooper, L.P. and Neece, O.E. [2004], Knowledge Reuse for Innovation, Management Science, (50)2, pp.174-188.

McDermott, R., (2004) How to Avoid a Mid-Life Crisis in your CoPs, KM Review, (7)2, pp 10 – 13 McDermott, R. and O’Dell, C. [2001], Overcoming Cultural Barriers to sharing Knowledge, Journal

of Knowledge Management, 5[1], pp.76-85. McKinlay, A. [2002], The Limits of Knowledge Management, New Technology, Work and

Employment (17)2 pp76 – 88 Newell, S., [2001], From Global Knowledge Management to Internal Electronic Fences:

Contradictory Outcomes of Intranet Development, British Journal of Management, (12)2, pp92 -106

Nonaka, I., & Takeuchi, H. [1995]. The Knowledge Creating Company. New York: Oxford University Press.

O’Dell, C [2000], Knowledge Management: A Game of Skill, Not of Chance, Las Vegas, NV: APQC Conference Proceedings, Dec 7-8,

Pinto, J.K. and Covin, J.G. [1989], Critical Factors in Project implementation: A Comparison of Construction and R&D Projects, Technovation, 9(1), pp.49-62.

Pinto, J.K and Mantel, S.J. [1990], The Causes of Project Failure, IEEE Transactions on Engineering Management, 37(4).

PMI [2004], Project Management Body of Knowledge, available http://www.pmi.org Schwen, T.M., and Hara, N., [2003] Community of Practice: A Metaphor for Online Design?, The

Information Society, (19)3., pp 257-270 Silver, C.A., [2000], Where Technology and Knowledge Meet, The Journal of Business Strategy,

(21)6 pp 28 – 33. Stenmark, D. [2003], Knowledge Creation and the Web: Factors Indicating Why Some Intranets

Succeed where Others Fail, Knowledge and Process Management, 10[3], pp.207-216. Storey, J. and Barnett, E., [2000], Knowledge management Initiatives: Learning from Failure,

Journal of Knowledge Management, (4)2 pp. 145-156. Szulanski, G., [2003], Sticky Knowledge, London: Sage Publications. Thomas, J.B., Sussman, S.W., and Henderson, J.C., [2001], “Understanding “strategic Learning”:

Linking Organisational Learning, Knowledge Management and Sensemaking, Organizational Science, (12)3 May-Jun, pp 331 – 345

Von Krogh, G. [1998], Care in Knowledge Creation, California Management Review, 40[3], pp.133-153, 1998.

Wenger, E. C., McDermott, R., and Snyder, W. M., [2002], Cultivating Communities of Practice, Boston, MA: Harvard Business School Press.

Whittaker, B. [1999], “What Went Wrong? Unsuccessful Information Technology Projects,” Information Management & Computer Security, 7[1], 1999.

Wilson, P. F., Dell, L. D., & Anderson, G. F. [1993]. Root Cause Analysis: A Tool for Total Quality Management. Milwaukee, WI: ASQC Quality Press

Yin, R.K. [1994], Case Study Research: Design and Methods, Thousand Oaks, CA: Sage Publications

Zack, M. H., [1999], Managing Codified Knowledge, Sloan Management Review, (40)4, Summer, pp. 45-58



Zolingen, S.J. Van, Streumer, J.N. and Stooker, M. [2001], Problems in Knowledge Management: A Case-Study of a Knowledge-Intensive Company, International Journal of Training and Development, 5[3], pp.168-184, 2001.

APPENDIX I. CASE 1 ANALYSIS

Table A1. Case 1 CED by Researcher 1

ID Cause-effect flow A1 Bandwidth problems -> Excessive network traffic -> Poor system usability and

response times A2 IT consultants lacks business knowledge -> Technical solution developed rather

than a business solution A3 End users not involved -> system that does not meet user requirements or address

KM needs A4 Lack of motivation to share knowledge -> knowledge content is weak -> knowledge

content eventually gets out of date and is obsolete -> system usage gets lower A5 Emphasis on technical superiority rather than business value -> system fails to

address true KM requirements

Table A2. Case 1 CED by Researcher 2

ID Case-effect flow B1 Network scalability of OfficeWeb unable to support the required volume of traffic to

properly run the KM solution -> End users not able to access knowledge content in a timely manner -> End users not able to utilize KM solution to fullest benefit and become frustrated

B2 Technology people are in charge of the GTSnet project rather than business people -> business need for KM is not properly identified or established -> KM solution created but there is a gap between business need and what is delivered -> end users and project stakeholders become frustrated

B3 Experts within the organisation have poor incentive to share knowledge, with possible implications for the security of their own position -> no new knowledge content is added to the knowledge base -> knowledge base simply becomes a repository which over time is not refreshed and so has diminishing value

B4 Organisational culture within the bank does not seem to generally encourage a high degree of knowledge sharing -> resistance to change, or even resistance to contribute to make things better -> experts are not fully engaged and committed to GTSnet.

B5 Management support strong but apparent lack of direction on the Iweb project -> no real strategy for knowledge sharing -> rash implementation leads to a KM solution -> the KM is technically sound, but usage and actual business value is low

B6 Lack of strategy for obtaining new knowledge -> knowledge repository of Iweb contains only existing knowledge -> KM solution becomes a static repository -> users use the system for reference rather than new insights or for learning

Table A3. Case 1 Merged CED

ID Case-effect flow A1+B1 Lack of network and technology scalability -> Poor access to knowledge -> End-

user frustration A2+B2+A5 Technical bias -> Mismatch between organisational need and technical solution ->

End-user frustration A3+B2 Lack of user involvement -> KM requirements not properly established -> solution m

ismatch



A4+B3+B6+B5

Poor perceptions of knowledge sharing -> knowledge is not shared -> knowledge content neither increases or is not updated

ABOUT THE AUTHORS

Alton Chua is Assistant Professor at Nanyang Technological University. He has published more than 20 journal articles, book chapters and conference proceedings in knowledge management.

Wing Lam is Associate Professor of IS at Universitas 21 Global, and Program Director for IS. He is the author of over 70 journal and conference articles. His work focuses on enterprise integration and knowledge management.

Copyright © 2005 by the Association for Information Systems. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and full citation on the first page. Copyright for components of this work owned by others than the Association for Information Systems must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, or to redistribute to lists requires prior specific permission and/or fee. Request permission to publish from: AIS Administrative Office, P.O. Box 2712 Atlanta, GA, 30301-2712 Attn: Reprints or via e-mail from [email protected].

ISSN: 1529-3181 EDITOR-IN-CHIEF

Paul Gray Claremont Graduate University

AIS SENIOR EDITORIAL BOARD Jane Webster Vice President Publications Queen’s University

Paul Gray Editor, CAIS Claremont Graduate University

Kalle Lyytinen Editor, JAIS Case Western Reserve University

Edward A. Stohr Editor-at-Large Stevens Inst. of Technology

Blake Ives Editor, Electronic Publications University of Houston

Reagan Ramsower Editor, ISWorld Net Baylor University

CAIS ADVISORY BOARD Gordon Davis University of Minnesota

Ken Kraemer Univ. of Calif. at Irvine

M.Lynne Markus Bentley College

Richard Mason Southern Methodist Univ.

Jay Nunamaker University of Arizona

Henk Sol Delft University

Ralph Sprague University of Hawaii

Hugh J. Watson University of Georgia

CAIS SENIOR EDITORS Steve Alter U. of San Francisco

Chris Holland Manchester Bus. School

Jaak Jurison Fordham University

Jerry Luftman Stevens Inst.of Technology

CAIS EDITORIAL BOARD Tung Bui University of Hawaii

Fred Davis U.ofArkansas, Fayetteville

Candace Deans University of Richmond

Donna Dufner U.of Nebraska -Omaha

Omar El Sawy Univ. of Southern Calif.

Ali Farhoomand University of Hong Kong

Jane Fedorowicz Bentley College

Brent Gallupe Queens University

Robert L. Glass Computing Trends

Sy Goodman Ga. Inst. of Technology

Joze Gricar University of Maribor

Ake Gronlund University of Umea,

Ruth Guthrie California State Univ.

Alan Hevner Univ. of South Florida

Juhani Iivari Univ. of Oulu

Claudia Loebbecke University of Cologne

Michel Kalika U. of Paris Dauphine

Munir Mandviwalla Temple University

Sal March Vanderbilt University

Don McCubbrey University of Denver

Michael Myers University of Auckland

Seev Neumann Tel Aviv University

Dan Power University of No. Iowa

Ram Ramesh SUNY-Buffalo

Kelley Rainer Auburn University

Paul Tallon Boston College

Thompson Teo Natl. U. of Singapore

Doug Vogel City Univ. of Hong Kong

Rolf Wigand U. of Arkansas,LittleRock

Upkar Varshney Georgia State Univ.

Vance Wilson U.of Wisconsin,Milwaukee

Peter Wolcott U. of Nebraska-Omaha

Ping Zhang Syracuse University

DEPARTMENTS Global Diffusion of the Internet. Editors: Peter Wolcott and Sy Goodman

Information Technology and Systems. Editors: Alan Hevner and Sal March

Papers in French Editor: Michel Kalika

Information Systems and Healthcare Editor: Vance Wilson

ADMINISTRATIVE PERSONNEL Eph McLean AIS, Executive Director Georgia State University

Reagan Ramsower Publisher, CAIS Baylor University

knowledge management project abandonment: an exploratory

Documents