UNDERSTANDING THE PROBLEMS OF ENTERPRISE SYSTEM

IMPLEMENTATIONS

Beyond Critical Success Factors

Sue Newell, Gary David, Traci Logan , Linda Edelman and Jay Cooprider

BENTLEY COLLEGE, 175 FOREST STREET, WALTHAM, MA 02452-4705, US.

Keywords: Enterprise System implementation, critical success factor, case study

Abstract: Many companies continue to implement Enterprise Systems (ES) in order to

take advantage of the

integrating potential of having a single common system across the organization that can replace a multitude

of independent legacy systems. While increasingly popular, research continues to show that such systems

are difficult to implement successfully. A number of studies have identified the critical success factors for

such implementations. However, in practice, it is often difficult to ensure that these critical factors are in

place and are maintained in place across the lifespan of the implementation project. In this paper we identify

the socio-political and cultural issues that explain why this is difficult and suggest some meta-level

processes (induction, informality and improvisation) that can help to offset the problems with maintaining

the critical success factors.1

1 INTRODUCTION

Enterprise Systems (ES) are being widely adopted

by organizations in all types of industry and

geographical locations and there is now considerable

research around ES adoption and impact (Holland

and Light, 1999, Robey et al., 2002).

In particular, many multinational enterprises

have

adopted ES with the intention of leveraging

productivity and efficiency gains in order to improve

organizational competitiveness (Davenport, 1998,

Wagle, 1998). The promoted advantage of an ES is

that it can integrate business functions into a single

system with a shared database (Lee and Lee, 2000),

allowing organizations to develop a homogenous

enterprise-wide information systems infrastructure.

At the same time as improving integration, this will

also allow the organization to get rid of legacy

systems, which will have typically been developed

in an ad hoc fashion over a long period. Large

organizations will often have several hundred, often

duplicated legacy systems which are very costly to

maintain. Replacing many of these with a single ES

is therefore seen to be advantageous.

While these potential benefits are very attractive,

expl

aining why so many organizations have opted to

adopt an ES, in reality implementing an ES can be

problematic to the extent that many such projects

involve significant delays and budget over-spends,

as well as sometimes ending in outright failure

(Robey et al., 2002). A great deal of research has

been done to identify the critical success factors for

ES success (Summer, 2000, Holland and Light,

1999, Parr and Shanks, 2000, Markus et al., 2000).

This is very helpful and provides the background for

the results of the research reported in this paper.

More specifically, in this paper we explore why

many of the normative and prescriptive factors that

research has identified as critical to success are

problematic in practice. We argue that prescriptive

accounts can be enhanced with research which

considers why these so-called critical factors are

difficult to establish and maintain in practice

2 ERP CRITICAL SUCCESS

FACTORS

As indicated above, a number of studies have

identified the critical success factors associated with

successful ES implementations. In this paper we

draw upon the list produced by Nah et al., (2003).

This list is based on an extensive literature review of

previous research that had sought to identify the

critical factors for ES implementation success.

238

Newell S., David G., Logan T., Edelman L. and Cooprider J. (2005).

UNDERSTANDING THE PROBLEMS OF ENTERPRISE SYSTEM IMPLEMENTATIONS - Beyond Critical Success Factors.

In Proceedings of the Seventh International Conference on Enterprise Information Systems, pages 238-247

DOI: 10.5220/0002510002380247

 SciTePress

Based on this literature review they identified 11

critical ES implementation success factors that they

suggest become more or less critical at different

times in a project’s life-cycle. In this paper we group

these elements rather differently, since they relate to

different aspects of project management and

structure that we found were associated with the

problems experienced in our case organization.

Specifically, we consider the 11 factors that Nah et

al., (2003) identified under three headings: Staffing

Issues: here we consider three of the critical success

factors - top management support, project champion

and ES teamwork and composition; Formal Project

Management Methodology: here we consider five of

the critical success factors - project management,

business plan and vision, effective communication,

software development, testing and troubleshooting

and monitoring and evaluation of performance; and

finally Organizational Structure and Culture: here

we consider three of the critical success factors -

change management program and culture,

appropriate business and legacy systems and

business process reengineering and minimum

customization.

Given the need for brevity we will not discuss

these factors in any more detail here. Instead, we

next present the case study and then consider the

case findings in the analysis section in terms of these

critical success factors. In doing this we provide a

more detailed discussion of these different critical

factors, in particular identifying why, in practice,

each factor can prove problematic from the

perspective of the implementing company.

3 METHODOLOGY

In this paper we use an exploratory case study of a

large consultancy firm, hereafter called XYZ that

was in the process of implementing a major ES

across its global business. The data collected in the

study is subjected to an interpretive analysis since

we had no predetermined hypotheses or propositions

to test. The strengths of the interpretive

methodology have been reported in a number of

studies, notably Klein and Myers (1999) and

Walsham (1993). The appropriateness of adopting

such a paradigm is reflected in the need for not only

investigating the influence of the technology

implemented, in this case ES, but also the need to

take into account the broader context, including the

organization and its environment. For example, in

the words of Walsham (1993 p. 4-5), interpretive

research methods are ‘aimed at producing an

understanding of the context of the information

system, and the process whereby the information

system influences and is influenced by the context’.

The main method used is the exploratory

interview. We decided to supplement our data on the

specific ES implementation case with data from

consultants in the same organization who had been

involved in many external ES implementations. We

decided to consider this broader experience of

consultants because consultants have wide-ranging

involvement in a variety of companies which are

likely to approach their ES adoptions very

differently. At the same time, this was an

exploratory study so we wanted to gain access to

rich, qualitative data rather than quantitative data

that could have been collected by a survey

instrument. Thus, we collected data from two

distinct groups of consultants: firstly, senior

consultants who have had considerable experience

of implementing ES in a range of different

companies (N=7); secondly, senior consultants

within this firm who are themselves involved in the

implementation of an ES (Siebel) across the global

firm (N-7). In addition to these interviews we also

collected documents related to this consultancy

firm’s implementation methodology generally and

the Siebel project specifically. The purpose of

collecting data from multiple sources was to enrich

the depth of the study, and to triangulate the data to

ensure the validity and reliability of the findings

(Denzin, 1989).

4 CASE DESCRIPTION

Given the focus of this paper we present data

relating to the key problems that emerged in relation

to XYZ’s own ES implementation project. We draw

upon the more general experiences recounted by the

consultants only as they pertain to this specific

experience and to the previously identified critical

success factors. XYZ is a very large global

organization manufacturing and retailing both PC

and high-end computer systems. It also has large

global consultancy businesses that focus on both

general business services and IT-related

implementation and support services

4.1 The Siebel Project

Siebel is an enterprise-wide customer-relationship

management (CRM) system that the company

decided to implement in 1999. XYZ had already

developed its own CRM systems but the CEO

decided they needed to “web-enable” this

application. Since it was determined the in-house

development efforts required to migrate to the web

UNDERSTANDING THE PROBLEMS OF ENTERPRISE SYSTEM IMPLEMENTATIONS: Beyond Critical Success

Factors

239

were too significant, the decision was made to buy

an external package to support the XYZ

organization. The decision was made to go with

Siebel, predominately because of its scalability and

ability to support the breadth of the XYZ

corporation. The project was kicked off in 2000 and

was still ongoing in 2004.

Interviewees admitted that the success of the

project was difficult to judge given that it had

spanned such a long period of time, overlapping

many other projects and organizational change

initiatives. XYZ was described as becoming ‘a very

different and much more nimble organization’ over

this period and Siebel was seen to be at least a factor

in contributing to this change. However, in more

tangible terms, the Siebel project had not been a

complete success. One of the major business

rationales for the project was that by replacing many

customized and independent legacy systems with a

single “vanilla” application, maintenance costs

would be significantly reduced. With this in mind

the project plan had a built-in schedule for

‘sunsetting’ existing applications. Unfortunately,

four years on, only one of the scheduled legacy

systems had actually been phased out and as one of

the project leaders admitted: “We are a little off-

track!” (PM). More generally, there had been

significant delays in implementing the various

modules. For example, the sales module had been

delayed by one year and the marketing module by

two years. Moreover, the human cost of the project

was very high, especially among the core team, who

were described as ‘burnt-out’ by one of the core

team members:

“When we are talking about four years,

it’s an awful long time to put people onto a

project like that. And one of the aspects of

that is that some of the executive team has

been on the project now for four year and

are burned, burned to crisps… In my own

case… I can no longer sustain an 80-hour

work week”.

4.2 Project Methodology

The project has followed a well-established IT

implementation methodology; one that XYZ uses

with its clients when implementing IT systems. The

overall project has a project leader who is a Vice-

President. Under this leader there is a core team of

about 12 individuals, each responsible for a different

aspect of the design and implementation of the

system, including communications, data coding,

operations and deployment. In turn, each of these

core team members is responsible for a number of

project teams that are working on different modules

within the overall CRM system. Each module has

been rolled out in relatively independent phases,

including the call centre module, the services and

support module, the field sales and distribution

module, and the marketing module. For each of the

module implementations, a unique global project

team is brought together which includes content

experts as well as CRM experts. This team is called

the project definition team (PDT). It has a leader and

under the leader there is a project manager, a process

leader, an architecture leader, an education leader,

and a deployment leader. That worldwide PDT team

is responsible for the deployment of the particular

module worldwide. This team is responsible for the

initial gap exercise (see below), understanding the

requirements of the business, feeding the

requirements to the development arm, testing the

applications and the changes as they come through,

developing educational material for users, and

actually deploying the system across the different

geographies and BUs.

The gap exercise is seen to be an extremely

important part of the project. Led by the PDT team,

a representative group of people from across the

world are brought together for a one week intensive

workshop. The people involved will eventually be

users of the system and will be involved in various

project teams during the implementation. By taking

this group through the Siebel process and comparing

this to existing practices, the core team is able to

work-flow how these people do their job. The aim of

the exercise is to see if there are any limitations to

the Siebel software so that customization is needed.

However, the overriding rationale is to get users to

accept the ’vanilla’ system, “out of the box”, since

customization is so expensive.

Any customization and interface

requirements that are identified are then passed over

to the development centre, which is now a separate

profit centre within XYZ, mostly located in India,

which develops the required code, working on a 24

hour a day cycle. There is then extensive testing

done on the system before it is piloted and then

gradually rolled-out across the different geographies

and BUs. In terms of this roll-out, the education of

users is accomplished primarily through the use of

online materials, with in a few cases, additional

classroom sessions to supplement. At the time of the

interviews most of the different modules had been

deployed across Asia, Europe and North America,

with the exception of the marketing module which

was still in progress. The interviews were

undertaken with project members involved in this

marketing module since we wanted to track the

project in real-time. However, we also interviewed

members of the core team who had been involved in

the project for four years. In total, about 50,000

ICEIS 2005 - DATABASES AND INFORMATION SYSTEMS INTEGRATION

240

users were already using the CRM system and this

would rise by about another 10,000 once the

marketing module was in place globally.

5 PROBLEMS ENCOUNTERED IN

THE PROJECT

Interviewees discussed a number of problems that

had been experienced over the four years of the

project. We have categorized the main problems

under five main headings and discuss each in turn

next.

5.1 Sustaining Resources for Social

rather than Technical Work

At the very outset of the project, the change

management and relationship issues were seen to be

central and resources were allocated to ensure that

initiatives were introduced which focused on

extensive user education and general user adoption

issues. Yet in reality, very early on, as soon as the

project hit some technical problems, funds got

diverted from the human to the technical and these

resources were never subsequently restored. As one

core project team member commented:

“I have this chart that we developed in

the first two months of this, which said one

of the biggest issues to deal with is people

change. We have to focus on that… And

then we promptly forgot about it and we

didn’t do nearly as much from the people

change aspects as we originally had

planned to do… The IT side wasn’t bedded

in, so we gave up funding for people

management in the early part, believing that

we could put it in later in the season”.

5.2 Getting Things Done at Critical

Points

While following the formal methodology worked

when everything went to plan, working around the

formal system was described as necessary at

‘crunch’ times, when problems were encountered,

especially when these problems had the potential to

negatively impact the project’s critical path. At these

times, informal networks were used – ‘to get things

done in the end, as opposed to simply transferring

information’. An example of the informal system at

work was described:

“Right now I have an out-plan item,

which is the deployment of marketing in

Asia-Pacific. We have no money to do this.

But we figured out with the AT guys that

we can actually do it as a skunk work if we

can get everybody onboard and just get shit

done. So what I did was I called one of the

guys who used to work for me in my old

job, who is now the relief manager, and I

said I want to hide this. I want this to

happen, but I don’t want it be in front of

everybody’s face until we know more about

it, to know how deep this bread box is we

are looking in.”.

5.3 Leadership and Team

Involvement

Given the extended time-span of the project, there

were numerous changes to both the leadership of the

project, the core team and the middle managers

involved at different points throughout the

implementation. The leadership of the project had

changed three times over the four year period. The

first leader, who had initiated the project, was

described as: “hard driving, pain in the ass, all of

those sorts of things, and not a good people person”.

He understood that people issues were important but

simply did not have good people management skills.

However, he was very good at building senior

management support. The second leader was

described as:

“Very experienced with consulting

background, but not someone who had a lot

of experience with dealing with the politics

of (XYZ); and above everything else, this

was a political project”.

In relation to the core team of about 12, this

group was described as working very closely and

effectively together:

“Most of us have worked together for

four years now. There is a great deal of

trust and liking amongst the executive

team”.

This cohesion was built up through intense

interaction at the start of the project:

“(we were in) each other’s pockets for

about six or eight weeks to begin with, and

we got to know each other extremely well,

which was great because it carried us

through the hiatus when we didn’t get to

see each other very much”.

However, while the core team of 12 remained

more-or-less consistent over the 4 year time period,

there was a great deal of turnover among the more

periphery members of the project. Initially, the

whole team, core and non-core, had got together for

a 2 week meeting where they had discussed the

UNDERSTANDING THE PROBLEMS OF ENTERPRISE SYSTEM IMPLEMENTATIONS: Beyond Critical Success

Factors

241

project – its objectives, how it was going to

transform the organization, the problems and

opportunities of the project etc. This had provided a

lot of energy for all team members at the outset.

However, over time, those who had been involved in

this initial meeting left and were replaced with other

people who had not been at this kick-off meeting.

This created problems in terms of both commitment

to and understanding of the project. As one of the

core team members commented:

“If I were to run a project like this, the

lessons I have learned about people on the

project is we need to be re-educating them

on how you want the project to work;

otherwise, they will reinvent it”.

5.4 Divergent ‘Common’ Practices

While the original legacy CRM systems were not

integrated, working off multiple independent

databases, they had been based on a reengineering

analysis that had been undertaken at the time that

XYZ was significantly downsizing during the early

1990s. During this reengineering effort the aim had

been to define common processes and procedures so

that the way of interacting with customers was

common across all geographies and business units of

XYZ. The prior establishment of these common

processes meant that the introduction of Siebel

should have been relatively easy since they

anticipated that only minimal adjustments to reflect

country differences would be necessary. However,

this did not prove to be the case. So, in the initial fit-

gap exercise the PDT team found that:

“There is an interesting difference

between the process documents – how they

say the job is done and the people at the

keyboard actually doing the job – they

don’t match. You get very clever people

who learn their own short-cuts and unless

you are a practitioner you don’t learn these

things”.

In other words, even though at the start they had

believed that the implementation would be easier

because common processes were assumed to have

been universally adopted, they found during this fit-

gap analysis stage that in reality people followed

very different processes in actually carrying out their

everyday practices. People had developed work-

arounds and adaptations to ‘common processes’,

hence the concept of common processes had gone

through a natural erosion over time. This introduced

enormous problems for creating the unitary database

and interfaces for Siebel. For example, to create the

common marketing database they had to clean-up

data from many different legacy systems,

supposedly all based on common processes but in

reality with a lot of diversity:

“So you end up with a huge amount of

different data formats and different legacy

databases… the people are doing the best

they can and also people using the fields for

something in which it was never intended,

either because it was never really closely

defined or because tactically they had to do

something so they did that”.

Each of these legacy systems had grown and

developed overtime so that there were many

examples of the idiosyncratic use of particular fields.

An example was provided of the use of the customer

number:

“A rather amusing example that is

probably (XYZ) specific; but we had

something call the customer number. It’s

supposed to be a unique identifier for a

customer. Which is actually legacy

thinking if you think about it because if

you’ve got a customer database that’s got

separate address lines, customer lines, you

don’t actually use the proxy which is the

customer number”.

This interviewee went on to say that although the

customer number is obsolete in the new system, and

the simple fix would be to delete all the customer

numbers, this had not been done because there was

resistance from users who had always relied on

customer numbers and could not understand how

they would not be needed in the future. So, for the

sake of getting user-acceptance the customer number

(or rather numbers) had been left in. But cleaning up

the data so that the databases could be integrated

into a single database was a major undertaking,

especially because of the frequency of duplication

records:

“If you’ve got a duplication of contact

or duplication of an account with marketing

you can get a

major problem with some of

the work flows that you’ve got”.

The problem was enormous given the numbers

of accounts that needed to be integrated into the

common database. So, in the UK for example, where

they were starting the roll-out, they had to sort

through about three hundred thousand accounts and

over a million contacts; and this was ‘small deal’

compared to some of the other countries. For

example in Germany there were about four million

contacts and in Italy over one million accounts.

5.5 Resistance and Stalemates

In relation to the first call-centre module, mutual

discussion among the participants during the fit-gap

ICEIS 2005 - DATABASES AND INFORMATION SYSTEMS INTEGRATION

242

week lead to the identification of the differences

between the way people wanted to do their job and

how the Siebel tool enabled them to do it. Because

of this, the first group identified over 600

requirements for customization. However, as was

noted, the implementation plan was to keep

customizations to the absolute minimum, and

consequently in the first release of the software only

8 of the suggested customizations had been

developed and put into production. These were

mostly related to nomenclature and terminology so

that the tool mirrored existing XYZ usage. The rest

of the suggested customizations were disregarded as

non-essential:

“The rationale was to keep as close to

out-of-the-box as possible – we were really

striving to minimize the number of

customizations that had to be made to the

application”.

However, while the project team was able to get

users to accept the ‘vanilla’ system in this instance,

they were less successful for the other modules. For

example, users in sales were reluctant to accept

changes to their existing practices, not only holding

out against them, but also imposing additional

modifications to the system:

“The sales team basically stuck their

tongue out and said screw you; we ain’t

going to do this unless you do it our way,

which has led to a number of compromises

in how we actually implemented the

package, some of which are good, some of

which aren’t good”.

This had similarly happened in relation to the

marketing module, resulting in a two year delay to

the implementation. Eventually a new manager was

brought in to try and resolve this setback. His view

was that if you lead the implementation from a

purely organizational perspective, it would be too

expensive and too time-consuming. Instead he

advocated getting the system up and running,

believing that users would be able to adapt their

practices to the system:

“The piloting and working forward I

think are the absolute key ingredients

because otherwise you can get a committee

working and discussing it for

years and

they’ll come up with something they think

is absolutely perfect and it will fall apart

within two weeks of going live because

there’s so much stuff they didn’t know…”.

6 ANALYSIS AND DISCUSSION

In this section we will consider the data from the

case in relation to the critical success factors

identified by Nah et al., (2003), grouping them into

three areas – staffing issues, project management

methodology issues, and organizational structure

and culture issues. Our analysis identifies how the

socio-political and cultural realities of an

organization make it very difficult to sustain the so-

called critical success factors.

6.1 Staffing Issues – Leadership and

Team Composition

First, in terms of leadership issues, it is clear that top

management support in general (Summer, 2000,

Bingi et al., 1999) and a project champion in specific

(Summer, 2000, Rosario, 2000) are critical to the

success of any large organizational project, such as

the implementation of an ES. The general interviews

with the XYZ consultants confirmed this:

“The key thing (for ES project success)

is higher executive championship.

Somebody from the top who has bought in,

who is really doing that, having the key

mentality of having everybody bought in.”.

Moreover, the project itself should include

people who have been selected based on their skills

and expertise, so that there is an appropriate mix of

team members, each of whom will presumably add

value to the implementation. Again, the general

consultant interviews emphasized this factor in

discussing what made a successful ES

implementation. These interviewees stressed the

importance of building a strong internal project team

because of the impact this could have on knowledge

sharing and creativity, both seen as essential for a

successful ES project:

“Where the team comes together and

starts to appreciate each others personalities

and each others values, then you start to

build the relationships that will see you

through… there’s just a natural outpouring

if you put a bunch of smart people in a

room with a problem. They’re going to

come up with some alternatives that any

one person wouldn’t have seen before”.

However, in reality the Siebel project

demonstrates how difficult it is to achieve sustained

project team commitment, and consistent on-going

project leadership in the context of complex ES

projects spanning multiple years like the one

described here. Four years is a long time, during

which any organization is likely to see numerous

UNDERSTANDING THE PROBLEMS OF ENTERPRISE SYSTEM IMPLEMENTATIONS: Beyond Critical Success

Factors

243

personnel changes at all levels, including senior

management. This was the case with XYZ who, over

the four year span, experienced three different

project leaders and multiple changes to the project

teams assigned to the various CRM modules. In

terms of the different leaders, each had a different

style and was more or less able to play the necessary

internal and external leadership roles. In relation to

the team participants, for those who joined the

project later, and so had not been involved in the

initial 2 week induction meeting, there was less

understanding of the project benefits and less

commitment to the goals of the project, especially to

the goal of minimizing customization.

In other words, what happened in this case was

that the initial induction was successful in providing

the relevant stakeholders (leaders, project members

and users) with a good understanding of the project

and its importance, thus they were very much behind

it. However, over time, as the mix of personnel

changed, most of whom did not receive any formal

induction, project commitment could not be

sustained. What seems therefore to be important is a

continuous and unified induction of all new

stakeholders, including project leaders, project team

members, and end users, the aim of which is to

ensure project understanding, commitment and

prioritization over time. Research does demonstrate

the importance of prioritizing projects (Case and

Shane, 1998), but this emphasis is typically

communicated at the outset of a project. However,

for projects like Siebel, which are of significant

duration, this priority needs to be continuously

reemphasized in order that all key stakeholders

continue to buy-in to the project (Huang, 2000).

Maintaining the priority of a project over a four year

duration would be difficult in any situation, and

certainly these inevitable personnel changes serve to

exacerbate this problem. Bringing people

periodically together for workshops may be a good

way of encouraging this continuous induction, since

it will also encourage the development of informal

networks which were also identified as crucial (see

below).

6.2 Formal Project Management

Methodology

Structured IS project management methods offer a

set of techniques and tools to carry out systems

development work within a defined framework.

Formalized project management methodologies are

seen to be a key to successful ES projects (Holland

and Light, 1999, Summer, 2000). The formal project

management structure should be based on a clear

business plan (Wee, 2000), which is effectively

communicated to all stakeholders ((Falkowski et al.,

1998), and constantly evaluated and monitored

(Holland and Light, 1999). The project plan should

also crucially ensure that there is adequate testing

and troubleshooting of the software (Wee, 2000). All

of these were identified as critical success factors by

Nah et al., (2003). The general interviews with XYZ

consultants confirmed the importance of these

project management factors and the Siebel project

was very firmly based on a formal methodology.

However, both the general consultant interviewees

and the Siebel interviewees stressed that the formal

methodology alone is insufficient. For example, one

general interviewee commented:

“The actual relationship building is

probably more important than any of the

other formal methods. The formal methods

will get information through, but they don’t

build the empathy and understanding that

will encourage people to work till 10:00 at

night together because they don’t want to

let the team down or they don’t want to let

each other down”.

Thus, the qualitative interview data demonstrated

that although formal project management

methodologies provide a necessary framework for

directing each implementation phase, they fail to

adequately address the inherent “work arounds”

introduced by participants in an effort to keep a

project moving. Such a view is supported by

Crabtree (2003, p. 36), who observes, “rules and

other formal procedures do not determine the

performance of work activities and do not, therefore,

determine how coordination gets done on each

occasion of work”. This is especially true when

critical project assumptions prove to be inaccurate.

Suchman (1987), in comparing plans (or formal

processes and methodological conceptualizations of

work) to situated actions (or how work actually gets

done as an everyday practical achievement),

describes how incongruencies between the two can

result in significant design flaws in technological

systems that actually impede productivity rather than

enhance it. This indicates that there needs to be more

attention given to understanding how work is

accomplished; rather than depending upon

formalized institutional accounts of work processes

in the building of systems.

In working around the formal process, informal

networks were stressed as being important both for

moving the project along, especially when

difficulties were faced, and also for developing the

internal project team cohesiveness. This is because

in a large project like Siebel, many different players

need to be involved, each approaching the project

from different cultural backgrounds and

understandings. Consequently, the existence of

ICEIS 2005 - DATABASES AND INFORMATION SYSTEMS INTEGRATION

244

personal relationships, those that are collaborative

and mutually supportive, become essential to

ensuring support and common understanding of the

project.

The concept of social capital is helpful here since

social capital relates to using personal networks to

get things done. For example, Nahapiet and Ghoshal

(1998, p.243) define social capital as ‘the sum of

actual and potential resources within, available

through, and derived from the network of

relationships possessed by an individual or social

unit. Social capital thus comprises both the network

and the assets that may be mobilized through the

network’. Adler and Kwon (2002) distinguish

between the bridging and bonding aspects of social

capital; that is the external networks between a given

social unit and the broader community of which it is

a part and the internal networks developed within a

social unit. Likewise, Brown and Duguid (2002)

note the importance of seeing information as a social

rather than technologically driven resource. In this

way, the social relationships around and the social

use of the information (and technology) are the

driver for organizational change. Similarly, Heath

and Luff (2000) stress the importance of the social

uses of information and technology, and highlight

the growing body of research that investigates this

theme.

The interviews with the Siebel participants

stressed the importance of these social relationships,

both internally within the project teams and

externally between the project team and the wider

stakeholder communities. So, networks across XYZ

were used to mobilize support, get favours done, and

identify solutions to problems that were outside the

scope of the formal project procedure. Moreover, the

internal networks within the project teams were

developed and cohesiveness strengthened by the

informal activities outside the project itself, as

individuals socialized at lunchtimes and in the

evenings. It is this informal networking, in

combination with formal project management

methodologies that keeps projects moving forward.

6.3 Organizational Structure and

Culture

Finally, projects exist within particular

organizational contexts and Nah et al., (2003)

identified features of this context that influence

project success. Again, while the results from our

case do not refute any of these as critical factors,

they do suggest that in practice these factors are not

straight-forward because of the socio-political

realities of organizational existence. The first

identified critical success factor in this group

suggests that it is important to manage the change

process, including the people, organizational and

cultural elements (Rosario, 2000). In the case

presented here, the importance of managing the

change process was clearly recognized. However,

sustaining resources for this aspect of the project

proved to be impossible in the face of more

immediate and urgent technical problems.

The second critical success factor here is that an

ES is more likely to be successful if it is being

implemented in a context which is stable and

successful. This suggests a context where

reengineering has already taken place. In the case

reported here this reengineering had, as prescribed,

been previously undertaken. However, between the

reengineering project and the ES project, there had

been considerable divergence from the agreed

processes, as individuals developed these into

practices that suited their own unique situation.

Harold Garfinkel (1967) described such “ad hocing”

behaviours as the essential elements to

understanding everyday social activity.

Considerable evidence now exists that demonstrates

how employees use ad hoc practices and decision-

making, rather than formalized rules and processes,

in the course of getting work done [see Crabtree,

2003, Garfinkel, 1967, Luff and Heath, 2000). As

these ad hoc behaviours form the basis of

communities of practice (Lave and Wenger, 1993),

separate workplace cultures (based on shared

practices) emerge. Formalized systems based upon

an assumed shared methodology and process can,

and often does, clash with the localized “informal”

actions.

Finally, there is the recommendation that the

organization should change to suit the software

rather than visa versa (Holland and Light, 1999) so

that customization is minimized. This was indeed

the stated objective in the project reported here.

However, while this proved possible in most

instances, in other instances user resistance to the

vanilla application was simply too powerful to

ignore, as was the case with sales and marketing.

This isn’t surprising, given the strong link between

these two departments, the strategic mission of the

organization and their external focus on the

customer. The general consultant interviewees

identified problems related to changing the

organization and minimizing customization:

“I mentioned earlier a lot of time re-

engineering and best practices are not

always the focal point. They really are not.

As much as we would like them to be and

we try to drive that, a lot of the time they’re

not. So they’ll look at what standard [name

of ES software] provides. They’ll look at

what they have today. And try to go

UNDERSTANDING THE PROBLEMS OF ENTERPRISE SYSTEM IMPLEMENTATIONS: Beyond Critical Success

Factors

245

through as least change as possible and

that’s the way I can describe it”.

In relation to all these factors connected to the

organizational change process, our case data

suggests that what is most important is to recognize

the flexibility and the improvisational skills of the

users (Orlikowski, 2000). Indeed, the fact that the

agreed common processes had already begun to

diverge after only a short time period in the Siebel

case attests to these improvisational abilities. The

key seems to be to provide users with the

functionality that they use in their day-to-day

practice, albeit in a slightly different format with the

new ES. Then allow users to ‘play’ with the system.

The outcome is very likely to be that they will soon

begin to exploit the added functionality of the ES, as

long as this will indeed make their jobs more

efficient and effective. From this perspective, the

concern about providing resources for a major

organizational change effort will be less important

since the emphasis will evolve to providing a system

that users can learn to exploit through their day-to-

day improvisational practices. Given the difficulties

of sustaining resources for the organizational change

effort when faced with unplanned technical road

blocks, this is also likely to be the most realistic way

to exploit the system.

7 CONCLUSION

A list of critical success factors for successful ES

implementation is helpful (Nah et al., 2003) and our

intent is not to refute these critical success factors.

However, our qualitative case research has provided

sufficient evidence to suggest that in practice, most

organizations encounter difficulty in sustaining these

factors, especially in projects spanning multiple

years. Our analysis demonstrates that even if a

critical factor is in place at one point in time, the

socio-political and cultural realities of organizations,

together with unplanned technical challenges and

project team turn-over make it nearly impossible to

sustain the critical factor over time. This has led us

to stress some meta-level processes that might help

organizations in the face of these difficulties related

to sustaining the critical factors. To make these

meta-level processes more memorable we have

termed them the three Is – induction, informality and

improvisation. Emphasis placed on these three

processes is likely to help keep the project on-track,

even in situations where the critical success factors

have been neglected or have deteriorated.

Induction – we have identified the need for

induction not only at project kick-off, but

continuously throughout the project as the portfolio

of key stakeholders (leaders, team members and

users) changes. This helps to ensure a culture of

engagement by participants while reinforcing

priorities and project benefits across the

organization. Periodic workshops involving key

stakeholders can be a useful way to achieve this,

helping to develop informal networks as well as

bolstering commitment to the project (Huang, 2000).

Such induction sessions will help to ensure sustained

buy-in, both intellectual and emotional, to the goals

and priorities of the project.

Informality – we have identified the need to

recognize that the formal methodology is only likely

to be successful to the extent that informal networks

and influence structures are used to supplement the

formal methodology. Using social capital (Adler and

Kwon, 2002) to ‘get things done’ and to build the

internal team cohesiveness is as important as

following the formal methodology.

Improvisation – we have identified how the

difficulties of managing organizational change may

be offset as long as stakeholders, especially end

users, are encouraged to improvise with the

technology that they are provided with (Orlikowski,

2000). While adoption of technologies like ES is

often driven by defined business goals and ROIs, its

true business value will typically emerge as the

technology is exploited by the end user, rather than

in response to the benefits hyped by the vendor. In

this sense, while an emphasis on change

management is important, it may be helpful to

intentionally rely upon and build into the project

plan an opportunity for improvisation by employees.

Given the natural tendency to shift resources away

from organizational development to resolve

unexpected technical issues as the ES project

progresses, this reduces the burden on active

management of the change process, which will often

be neglected in any case. In this way, improvisation

becomes documented and where appropriate,

communicated across the organization. This in turn

aids in reducing the likelihood of making incorrect

assumptions about practice in future upgrades and

system replacement projects.

Putting in place the so-called critical success

factors (Nah et al., 2003) for an ERP implementation

may indeed be more likely to lead to project success

than ignoring these factors. However, we argue that

realistically these factors are difficult to maintain in

practice, especially in a project of long duration.

Attention to the three identified meta-processes may

not guarantee project success, but they can help to

overcome the inevitable socio-political realities that

any large-scale IT project is likely to face. Thus, we

argue that these socio-political realities need to be

taken into consideration through the continuous

induction of all key stakeholders, the proactive use

ICEIS 2005 - DATABASES AND INFORMATION SYSTEMS INTEGRATION

246

of informal networks to garner support and get

things done, and the active utilization of the

improvisational abilities of end-users.

REFERENCES

Adler, P. and Kwon, S-W. (2002) Social capital: Prospects

for a new concept. Academy of Management Review,

27, 1, 17-40.

Bingi, P., Sharma, M. and Godla, J. (1999) Critical issues

affecting an ERP implementation. Information

Systems Management, 16, 3, 7-15.

Brown, J.S. and Duguid, P. (2002) The Social Life of

Information. Cambridge, MA: Harvard Business

School Press.

Case, R. and Shane, S. (1998) Fostering risk taking in

research and development: The importance of a

project’s terminal value. Decision Sciences, 29, 4,

765-84.

Crabtree, A. (2003) Designing Collaborative Systems: A

Practical Guide to Ethnography. London, UK:

Springer.

Davenport, T. (1998). Putting the Enterprise into the

Enterprise System, Harvard Business Review, 76, 4,

121-133.

Denzin, N. (1989) The Research Act. Prentice Hall, New

Jersey.

Falkowski, G., Pedigo, P., Smith, B. and Swanson, D.

(1998) A recipe for ERP success. Beyond Computing,

44-5.

Garfinkel, H. (1967) Studies in Ethnomethodology.

Englewood Cliffs, NJ: Prentice-Hall.

Heath, C. and Luff, P. (2000) Technology and Social

Action. Cambridge, UK: Cambridge University Press.

Holland, C. and Light, B. (1999) A Critical Success

Factors Model for ERP Implementation. IEEE

Software, 16, 3, 30-36.

Huang, J. (2000) Knowledge Integration processes and

dynamics: An empirical study of two cross-functional

teams. PhD, Warwick University, UK.

Klein, H. and Myers, M. (1999) A set of principles for

conducting and evaluating interpretive field studies in

information systems. MIS Quarterly, 23(1), 67-94.

Lave, J. and E. Wenger (1993) Situated Learning:

Legitimate Peripheral Participation. Cambridge

University Press, Cambridge.

Lee, Z. and Lee, J. (2000) An ERP Implementation Case

Study from a Knowledge Transfer Perspective”,

Journal of Information Technology (12: 2), pp. 281-

288.

Luff, P. and Heath, C. (2000) Technology and Social

Action. Cambridge, UK: Cambridge University Press.

Nah, F., Zuckweller, K. and Lau, J. (2003) ES

implementation: Chief information officers’

perceptions of critical success factors. International

Journal of Human-Computer Interactions, 16, 1, 5-22.

Markus, M.L., Axline, S., Petrie, D. and Tanis, C. (2000)

Learning From Adopters’ Experiences with ERP:

Problems Encountered and Success Achieved. Journal

of Information Technology, 15, 245-265.

Nahapiet, J. and Ghoshal, S. (1998) Social capital,

intellectual capital, and the organizational advantage.

Academy of Management Review, 23, 242-266.

Orlikowski, W. (2000) Using technology and constituting

structures: A practice lens for studying technology in

organizations. Organization Science, 11, 4, 404-428.

Parr, A. and Shanks, G. (2000) A model of ES project

implementation. Journal of Information Technology,

15, 289-303.

Robey, D., Ross, J. and Boudreau, M-C. (2002) Learning

to implement enterprise systems: An exploratory study

of the dialectics of change. Journal of Management

Information Systems, 19, 1, 17-46.

Rosario, J. (2000) On the leading edge: Critical success

factors in ERP implementation projects. Business

World, Philippines.

Suchman, L. (1987) Plans and Situated Actions: The

Problem of Human/Machine Communication.

Cambridge, UK: Cambridge University Press.

Sumner, M. (2000) Risk Factors in Enterprise-wide/ERP

Projects. Journal of Information Technology, 15, 317-

327.

Wagle, D. (1998) The Case for ERP systems. The

McKinsey Quarterly 9, 130-138

Walsham, G. (1993) Interpreting Information Systems in

Organization. Wiley, Chichester.

Wee, S. (2000) Juggling toward ERP success: Keep key

success factors high. ERP News, February, available:

http://www.erpnews.com/erpnews/erp904/02get.html

Yin, R.K. (1989) Case study research: Design and

methods, Newbury Park, CA: Sage Publications

UNDERSTANDING THE PROBLEMS OF ENTERPRISE SYSTEM IMPLEMENTATIONS: Beyond Critical Success

Factors

247