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
Copyright
c
 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