PROJECT MANAGEMENT FOR ERP IMPLEMENTATIONS A

CASE STUDY OF SUCCESSFUL IMPLEMENTATION

Fergal Carton Business Information Systems, University College Cork, Cork, Ireland,
fcarton@afis.ucc.ie
Frdric ADAM, Business Information Systems, University College Cork, Cork, Ireland,
fadam@afis.ucc.ie

Abstract
The success rate of ERP implementations is not high in view of the sums invested by firms in these
applications. It has often been indicated that a combination of inadequate preparedness and
inappropriate project management have been responsible for the low success rate of ERP
implementations. In this paper, we present our investigation into the project management strategy
adopted in the Pharma Inc. case. We consider this very successful case under the 12 headings of our
revised model for project management and seek to illustrate one vision of what could be termed best
practice in terms of ERP implementations.
Keywords: ERP, Implementation, Project Management.

INTRODUCTION

A considerable volume of research has been carried out on Enterprise Wide Systems and most notably
on Enterprise Re-source Planning systems (or ERP). This research has established that, on the one
hand, significant benefits can accrue to organisations implementing these systems, but on the other
hand many implementations are not conclusively successful. There is evidence that the degree to
which organisations prepare themselves properly for their implementation projects has a bearing on
whether they encounter many problems during implementation and, ultimately, whether they achieve
any of the benefits they sought. It also appears that inadequate project management leads to short term
solutions being found to the problems that occur during the implementation of ERP systems with
substantial side effects when systems go live. Previous research has indicated that ERP specific project
management strategies should be developed to tackle the specific challenges of such projects. In this
paper, we leverage our investigations of a very successful ERP implementation in a multi-national firm
(MNCs) to develop a best practice approach specific to ERP implementation is large MNCs where
there is a need for large scale integration and standardisation of processes.

PROJECT MANAGEMENT FOR ERP AND PROJECT SUCCESS

Project management for ERP projects is little different from Project Management for any IS projects,
and traditional frameworks for project management have been applied to ERP projects. However,
certain areas of traditional project management require a greater emphasis while others can be
discarded. PMBOK (2000) describes project management as the application of knowledge, skills,
tools and techniques to a broad range of activities in order to meet the requirements of a particular
project(Pg.6). Project management is an aid to project managers because it helps them to standardise
routine tasks and reduce the number of tasks that could potentially be forgotten. It also ensures that
available resources are used in the most effective and efficient way. The application of project
management principles allows senior managers to establish and use more appropriate measures of

success, to quantify value commensurate with cost and to optimise the use of organ-isational
resources.
However, Maylor (2001) has warned that project management lacks a strong theoretical base; it is not
based on a series of premises from which consistent theory can be delivered but rather on empirical
evidence, which has built up over time to form a body of knowledge. Thus, project management is
learned through experience and this has earned it the title of the accidental profession.

THE TWELVE AREAS OF PROJECT MANAGEMENT

Project management as a discipline is only a recent concept, yet, over the past fifty years a
considerable body of knowledge has been built up around project management tools, skills and
techniques. The purpose of the PMBOK is to identify and describe best practices that are applicable to
most projects most of the time. PMBOK (2000) identifies nine knowledge areas upon which project
management is based. These nine areas, although presented as distinct features are usually totally
integrated, as are their component processes. Based on initial research on applying the PMBOK
framework to ERP implementations, researchers have identified that 3 additional areas must be added
to the framework in order to suitably cater for the specificities of such projects (reference removed to
avoid identifying the authors of this paper). The 9 areas of the original framework and the 3 ERP
specific areas are listed below (additional areas marked with a *):
1.

Project Integration Management

2.

ERP Project Rationale Management *

3.

Project Scope Management

4.

Global ERP Project Management *

5.

Project Time Management

6.

Project Cost Management

7.

Project Quality Management

8.

Project Human Resource Management

9.

Project Communications Management

10.

Project Risk Management

11.

Project Procurement Management

12.

ERP Project Review Management *

In our previous research, we have identified that these areas are critical to the correct preparation of
firms to ERP acquisitions and implementation. Indeed, most of the salient points, either good or bad
that are reported about ERP projects seem to fall naturally within these categories. However, these
categories are not sufficient to provide a prescriptive method to guide future project managers. In
order to make our framework more directly applicable to project preparation, we carried out a case
study of a roll out of SAP in one large local subsidiary of a MNC in the pharmaceuticals sector (which
is called Pharma Inc. in the paper because we are still negotiating the use of the real name of the firm
at this time) using the frame-work as research model. The dominant characteristic of this case study is
that it was, by any standard, quite a successful project (see section 3) and one from which elements of
best practice could be derived, especially with the added benefit of insight which could be gained by
revisiting the site regularly in the months following the go live of the application (January 4th, 2005).
Additional opinions were collected in this way which enabled us to propose an ideal scenario for this
case study. This is analysed in the next sections.

METHODOLOGY

In this paper, we present the case study of Pharma Inc., where a successful ERP implementation took
place between the middle of 2003, when staff were given ERP awareness seminars to the end of 2004
when the SAP software went live in the site. We have been involved in this case study over this
complete period, and as a benchmark project it has consider-able value in that it is perceived by all
participants as being a notable success for the implementing subsidiary and for the parent company
alike. Concretely this means that the system went live as expected, on time and within budget, and that
team were able to achieve a rapid ramp-up to full production volumes ahead of time (7 weeks instead
of 9 weeks after go-live). In our opinions, this makes Pharma Inc. an example of an extreme case in
Pattons (1990) classification of purposeful sampling strategies and this justifies our choice of this case
as a basis for determination of best practice in ERP implementations. The case involves a
manufacturing subsidiary of a multi-national pharmaceutical firm implementing a single instance of
SAP across a large number of sites worldwide (see table 1 for key information about the case). This
subsidiary is what is termed a primary site, meaning that it produces batches of active components
to be used in other sites where the tabletting and packaging of the drugs is performed (these sites are
referred to as secondary sites). One feature of his case study is that the difference between the
primary sites and the secondary sites in Pharma Inc. raised additional challenges that were not
anticipated.
Key Features

Case Study

Type of firm

Multinational

Industry

Pharmaceutical

Size (emp.)

100,000

Turnover

$25 billion (2004)

Scope of project

Manufacturing, Planning, Procurement, Sales & Distribution, Finance, Engineering,

Quality

Type of project

Worldwide roll out in 4 waves

Duration

5 years

Project leadership

Local Steering Committee, Local Project Team and Global Core Implementation Team

Project managers

Local managers from affected functions seconded to project

Team members availability

100% for 12 months

Project resources

70 people locally + 45 in core team*

Table 1 Key characteristics of the case study firm

*the core team is the travelling team which moved from location to location to facilitate the local roll
outs during the successive waves of the project.
In Pharma Inc., we carried out over 55 interviews in 4 different sites: our local site, where we
exchanged our work as facilitators for the team building and awareness seminar stages against acess to
people and documents for the duration of the project, Pharma Inc. Headquarters, where we spoke to
the global leaders for the project and two other local sites in a different country (one was a primary
site and one was a secondary site) where we met with the local project managers. This gave us a
comprehensive, if not complete, vision of this large and long project and allowed us to make definitive
judgments on what had gone to plan and what deserved further improvements. Such an extensive
amount of data collected allowed to approach Eisenhardts (1989) notion of saturation, where it felt

that no more understanding can be gained by pursuing the field work and this gave us confidence that
we were able to give an accurate and realistic account of what happened at Pharma Inc. All our writeups have been reviewed by our informants and they have agreed with their accuracy.

THE PHARMA INC. CASE STUDY

In the following sections, the case study of the local roll out of SAP in Pharma Inc. is described in
detail under the 12 headings of our research model.
5.1

ERP Project Integration Management

Under this heading, we think that the general preparedness of an organisation must be considered. Too
many firms embark in ERP projects with a general lack of awareness of what is involved in their
ranks. Top managers in particular, may not realise the level of efforts required from staff in areas that
are going to be affected by the new systems and sometimes expect these staff members to carry on
with their normal duties on top of their role in the ERP project. Setting up a full time team, backfilling
the positions left vacant by team members, allocating a discretionary budget to the team, sending some
team members on special training workshops so they understand what is expected of them must all be
taken into consideration at the outset.
Our experience of ERP projects is that preparedness is crucial and often lacking. In Pharma Inc., the
overall level of preparation was quite good in our local site, given that this was the 4th wave of a
global project that had already seen 5 manufacturing sites go live with the ERP global template. On
the other hand, of an initial core team of 24 business representatives, only 2 team members had direct
experience of an ERP system implementation. This meant that much work was done in the project
preparation phase from mid 2003 to educate team members on the background to ERP projects, the
key challenges they would face as a project management team and the communication channels that
would be used to make decisions. It is interesting to note that, at that stage, team members were quite
uncertain about the task facing them and that they feared that SAP would jeopardise much of the work
accomplished in previous years in streamlining and optimising key processes. They perceived
themselves as quite far ahead of other sites in Pharma Inc. and worried that this global roll out would
bring them back in line with all other primary sites, their efforts in distinguishing themselves being
therefore nullified (Subsidiaries of large pharmaceutical firms see themselves as competing with the
other sites in their corporation much more so than again other firms). As we see further in this paper,
this impression was slowly reversed over the course of the project.
5.2.

ERP Project Scope Management

Again, this aspect of ERP projects pertains to how well companies are prepared when they embark in
their implementations. Wood and Caldas (2000) found that of the 91% of the respondents who said
they would implement again if faced with the situation again, 25% would significantly change the
scope or the implementation methods of the project.
In our case study the scope was very broad (Warehouse, Engineering, Finance, Procurement,
Production Planning, Production Execution, Quality, Sales & Distribution and NPI / R&D). All of
these modules are integrated in the new global process model, so it was not an option to implement a
subset. In the original scope, it was thought that the processes used by the R&D function, though
mimicking the production processes, would not match with the global template. It was then even
considered to create a separate instance of the application just for R&D, a solution which the core
team would have opposed as strongly as they could anyway. Only through the perseverance of the
project team was it decided to bring R&D in under the scope of the project. In hindsight this was a

critical decision for the project, as the effort to develop interfaces to R&D and subsequently integrate
at some later date the whole R&D activity would have far outweighed the marginal increase in effort
to include them in the scope of the implementation for production.
Our case study revealed 2 elements of the scope of the project that were not anticipated in advance:
(1) the amount of work that would be required in collecting, cleaning up and converting legacy data
into a format suitable for the new sys-tem, and (2) the changes that would be requires to the physical
organisation of the warehouse function that would be required when the system was used to dispense
material (Primary sites are characterised by non-discrete activities, the core of which is weighting and
dispensing, which is critical for an ERP application).
Data cleansing became a huge issue for the project team, and a dedicated data maintenance team of 17
Full Time Equivalents (FTEs) was recruited to ensure that data going into the new system was clean,
valid and in the right format.
It was found following implementation that the workload involved in dispensing material under the
new processes was significantly more onerous than with the legacy system. This involved the
warehouse function eventually creating a separate dispensary area for dispensing material to
production jobs and requiring hiring more staff, which ran contrary to the general thrust of the ERP
implementation to boost efficiency.
Another un-intended change to the organisation occurred after go-live: rather than have all technicians
spend time updating the system during production runs, it was decided that it would be more efficient
to have specific technicians with responsibility for system integrity. From that point onwards, each
shift included a member of this group of system savvy technicians. This organisational change had
non-trivial impacts in terms of job responsibility, shift pattern planning, and end-user training which
required for instance long hours of negotiations with unions in terms of wages and job titles.
Davenport (1998) states that the single biggest reason that ERP projects fail is because companies are
unable to reconcile the technological necessities of the system with their own business needs. An ERP
system imposes its own logic on a companys strategy, organisation and culture and if a definite scope
statement is not articulated early in the project, the ERP system will drive the company towards full
integration even though a certain degree of business unit segregation may be the optimal solution. A
lack of understanding of the scope of the system may result in a conflict between the logic of the
system and the logic of the business (Davenport 1998).
Bingi et al. (1999) commented that the scope of an ERP project affects not only the number of
modules being implemented but also the number of functional units affected, the number of sites in
which the system is to be implemented, the extent of customisation and the number of interfaces with
legacy applications. Thus, in complex organisations such as multi-nationals, this scope management
stage is crucial and requires a preliminary determination of what configuration will be rolled out in the
different sites. This vision of the software is sometimes referred to as the template.
In our case study, the company was implementing a global template that itself had been designed
around corporate best practice. So the parameters and options that were available to the implementing
site were not simply a question of SAP options, but rather a question of choices available under the
corporate best practice template (called Global Standard Operating Procedures or GSOPs). It became
clear that in order to negotiate changes to this template to accommodate changes that allowed for the
local sites requirements, new types of skill would be required. The discussion became a 3-way
negotiation between the local stream lead or subject matter expert, the core team member who had
an in depth knowledge of the GSOP, and a SAP expert recruited by the local implementation site to
advise on what was and wasnt possible with SAP. It was found on several occasions that the GSOP
was lacking in basic functionality that the site required, and yet the core implementation team was
unable to suggest the solution because their experience was limited to the global best practice
template. An example would be the ability to have SAP deal with tonnes of raw material to a suit-able
degree of precision, when the global template had been designed with tablet manufacture, not bulk

active ingredient. This was the first example of the clash between the two cultures inherent in Pharma
Inc., the primary sites and their non-discrete processes and the secondary or tabletting plants and their
discrete processes.
Thus, the scope of the implementation needed to be re-examined to fit with the operations of the local
plant, and this necessitated the availability of advanced SAP knowledge to be able to suggest workarounds.
5.3.

ERP Project Time Management

Depending on the size of the organisation and the scope of the project, implementing an ERP system
may take years be-cause of the need to be rolled out across multiple sites, lines of business and
countries. McKie (1999) stated, nobody is capable of implementing financial, distribution and
manufacturing software across a range of statutory, operational, lin-guistic and cultural parameters in a
short time frame (Pg. 2).
Minahan (1998) claims that a typical ERP implementation takes between two and three years while
larger ones, especially worldwide roll outs, can stretch to five years.
This is certainly true in the case study, where the 4 waves of the implementation programme ran over a
period of over 5 years. In fact the timescale of the global roll-out was so long that by the time the last
site was up and running, the implementation team had to re-start the whole cycle again in order to
upgrade the version of the system used by the original sites.
Evidently, the length of implementation is greatly affected by the scope of the project i.e. more activity
regarding modules, sites and functions means a longer process. A large proportion of the
implementation time is consumed by customising the package, so the length of time could be
substantially reduced by keeping the system plain vanilla and reducing the number of packages that
require customisation in order to be bolted on to it (Bingi et al. 1999), which has led software vendors
and consultants to recommend a zero modification approach that has nowadays become a de facto
standard.
This aspect of the implementation represented a lose-lose situation for the implementing site in our
case study: on the one hand, to facilitate tight timelines, the number of specific requirements that could
be taken into account was non-existent. On the other hand, the time it would have taken to analyse the
new proposed business process to understand their impact on the local organisation was not sufficient,
so stream leads found themselves in the unenviable position of having to accept process changes
without really having time to validate them properly against local operations. Thus, the focus on
deadlines (that were defined externally to the project team) meant that team leaders had to focus
acutely on being on time at all stages. This resulted, in some cases, in critical tasks being left behind
for the sake of being on time. It seems that a proper balance must be found between being on time for
the sake of it and keeping all areas of the project as tight as possible.
Another interesting aspect of the timing of large multi-site global roll-outs is the learning that can
occur from each site and the core teams ability to take on board this knowledge in a way that would
make it meaningful for subsequent implementations. However, the learning process whereby
manufacturing sites within the same company can improve the template based on their own
implementation experience, such that subsequent sites might benefit is very difficult to put in place
without totally losing control over the overall duration of the project. This leads MNCs to sometimes
sacrifice this aspect in the name of standardisation and expediency (Bingi et al., 1999)
In our case study, the site studied was the first primary manufacturing site to go live, and thus their
experience with the GSOPs and core team was invaluable for subsequent primary sites. However,
there was no onus on the core team to pro-vide the channel for such communications, and they more
or less started each site from scratch. Any communication between sites that did occur took place
because it was initiated by the sites themselves.

This would suggest that the role of the core team, particularly with respect to their own learning
processes, needs to be evaluated against the necessity to stick rigidly to a timeline.

5.4.

ERP Project Cost Management

The total costs of implementing an ERP system include the cost of licensing, training, implementation,
maintenance, customisation and hardware requirements (MacVittie 2001), but Bingi et al. (1999)
warned that ERP projects are characterised by a lot of hidden costs. Berger (1998) added that for every
pound spent on ERP software licences, companies must spend a further 5 - 7 pounds on related
services, most of which are consultancy costs. Indeed, Scott et al. (2000) stated that the complexity of
ERP projects has generated a lucrative consulting support industry and this has caused considerable
controversy over the risks of escalating implementation costs.
Like most software, ERPs are priced on the functionality of the system and the number of users who
will access it. ERP systems also require companies to invest in migrating data, modifying existing
systems and overhauling hardware and network infrastructure. The costs quickly add up and Chevron
spent nearly $160m implementing their ERP system over a five year period.
With the global roll-out of a corporate template the cost equation is a little more complex, with the
local per user license fee probably being managed through a global contract with the corporation. The
costs of the core team are, in addition, sunk in the corporate project budget. On the other hand, the
local site manager of the project had to fund the local re-source bill for the project: secondment (and
back-filling) of his stream leads for 12 months, the hiring of additional re-sources for data cleansing,
and the hiring of specific technical skills (SAP). In addition the infrastructural costs to set the team up
were considerable (involving the commissioning of one floor of an entire building to the team). This
does not include training, travel and administrative costs.
Stedman (1998) states that 10%-20% of the total project cost is spent on training the end-users, e.g.
Baan charge $5,000 per head to train users. The problem with using external trainers is that they are
perfectly familiar with the ERP system but they are unable to answer questions regarding the business
processes that underpin the system.
In the case study, the project budget was externally decided, which did not prevent some of the local
teams to come in under their allocations. The firm minimised training costs by training super-users,
some of which came from the data maintenance team, who were then used to train the rest of the
workforce in the company.
An extensive training programme was put in place to ensure all staff were provided with training, no
matter what shift pattern they worked. It was perceived as vital for the success of the project that
training was undertaken by internal re-sources. Extra care went into planning for this, with mobile
modular space being rented and set up in a corner of the car park to create a temporary dedicated
training centre.

5.5.

ERP Project Quality Management

An ERP system is not just an office automation software package that can be bought off the shelf and
implemented with the aid of a step-by-step user manual. It is a serious transformation process that
requires fundamental change in the way business processes are designed and conducted. Various
methodologies have been put forward to ensure the package is implemented in a manner, which
ensures the quality of the final system, i.e. that the system is implemented in an efficient way and the
objectives are met. Minahan (1998) points to the need to hire the right people for the job internally and
externally. Stefanou (2000) put for-ward a three-phase model for ERP selection. Crucially, both

authors insist on preparing properly and thoroughly prior to acquiring or implementing any
technologies, which is rarely the case in todays ERP market. Thus, both authors link the quality of the
outcome of ERP projects to elements that must be put in place at the outset. The problem inherent in
such ideas is that this is precisely the stage in a project where managers awareness levels are at their
lowest and when they are least able to make key choices, hence the recourse to external parties which,
unfortunately are rarely independent and un-biased.
Our case study showed a unique willingness to go it alone with respect to integration partners. There
were no consult-ants employed in the local implementation team. Specific technical skills were hired
into the team on contracts to bolster the team without the exorbitant expense of paying consultants day
rates.
This had 2 effects on the running of the project:
1.

Costs were minimised

2.

Control was optimised

Another consequence was that there was no one else to blame in case something went wrong. In the
opinions of the interviewees, this was actually an added benefit that all responsibility for the
implementation of the package was internal, making the site autonomous.
4.6.

ERP Project Human Resource Management

An ERP implementation is a major undertaking, which requires management to assemble the best
possible team to plan, execute and control the project. Top management must be visible in their
commitment to the project, clarifying the exact goals of the project. Responsibility for the
implementation should be given to those individuals who have high degree of knowledge of the
business and the way that its component parts interact. This implies re-assigning the few people who
are most likely to be missed from their duties to the ERP project team on a full time basis (Maher
1999).
Ignorance of the project needs and an inability to provide leadership and guidance to the project by the
companys team is a major reason for the failure of ERP projects. It is not rare to find functional areas
reluctant to sacrifice their best re-sources to the project. However, this is a difficulty which must be
overcome (Bingi et al. 1999). The fact that teams must be cross functional is an added difficulty
especially in firms with no culture for working across functional areas and no experience of such large
projects.
In Pharma Inc., the communication between stream leads was very good, but the communication with
the core team was very uneven, seemingly more dependent on individuals willingness to
communicate than on any pre-defined scheme. In fact, there were even some incidents between
members of the local team and members of the core team when local staff were able to demonstrate
that the understanding that core team members had of the local processes was not sufficient.
In any case, the nomination of a well respected and experienced Director to the role of implementation
site leader in the case study site ensured 3 key aspects to the success of the project:

The project team was given recognised status and authority in the eyes of local employees.

A direct line of communication was opened between the project team and the general manager
of the plant

The political strength of the project leadership gave vital support and encouragement to the
project team in its relations with the implementation core team.

At one critical point in the implementation analysis, the site leader threatened to pull out of
discussions entirely unless the core team accorded sufficient respect to his stream leads. The
affirmation of such clout, at a vital early point in the collaboration between stream leads and core

team, laid the cornerstone for what was to become a much better working rela-tionship, as
acknowledged by both sides, and contributed certainly to the success of the project.
Frequently, companies do not fully comprehend the impact of choosing the internal employees with
the correct skill set. The right employees for the team should not only be experts in the companys
processes but also be knowledgeable of the best business practices in the industry.
In the case studied, following the nomination of a high profile site manager, selecting and obtaining
competent stream leads was the next key element of what was to be a winning combination. From the
outset, the scale of the undertaking was appreciated, and the calibre of the team members was
commensurate with the seriousness of the task ahead. All team members were reasonably senior, with
on average 10-15 years experience in the business. All team members were full time on the project
whether for the full duration of the project or for shorter durations in some cases. At key times in the
project, key staff were added to the team for specific tasks, such as data conversion, training or
desktop deployment, such that the team grew to more than 100 at certain times.
Wood and Caldas (2000) state that ERP implementation teams are multidisciplinary, dedicated teams,
comprised normally of information technology specialists, key users and operations personnel, as well
as consultants with process redesign and change management skills (Pg. 4).
In the case studied, although no external consultants were used, an important cross functional
advantage emerged from the mix of people engaged on the team. As the stream leads were old hands
in the business, not only were they acquainted with one another, they also had an intuitive grasp of the
complexities in areas of the business other than their own particular domain. With systems as
integrated as ERP, project team members have to always bear in mind the up-stream and downstream
effects of choices and configuration options they make as the project progresses. It was acknowl-edged
by the team and by neutral observers outside the team, that one of the key success factors of the
project was the teams ability to work together, and to draw on the individual experience and authority
across different functions in making key design decisions. The inclusion of an integration specialists
charged with anticipated the impact in other areas of decisions made in each area was another key
aspect.
Another unique element of the constitution of the local project team was the pre-meditated pairing of,
as one team member out it, experience and energy in each of the process streams. Stream leads were
allocated graduate level resources to work on data cleansing in each functional area, and this
combination obviated the need to hire in expensive consultants, and created a pool of enthusiastic
resources highly suitable to the task of training users when that time came closer to go-live.
Bingi et al. (1999) add a final point, stating that team morale is a vital component for the success of
the project. Team members are required to put in long hours (as much as twenty hours per day) and
this stress coupled with their regular duties could diminish team moral quickly. Thus, support from
upper management and the project leader is key to maintaining a focused team.
It was also no coincidence that the team in our case study functioned in a harmonious manner: the site
manager was at all stages attentive to the spirit of the team, monitoring formally and informally the
morale of the troops, such that, even if the timeline was punishing, team members felt they were
recognised for their efforts and could let off steam whenever the stress became too much. Team
members were accorded duvet days if it was felt that the unforgiving schedule was be-ginning to
impact negatively on performance.
It would be the researchers view that this factor is more in line with a personal style of management
than an ERP success factor. Getting the best out of a team of volunteers is a challenge in many walks
of life, and good leadership will always pay off in the end.

5.7.

ERP Project Communications Management

Scott et al. (2000) observed that companies find it very difficult to communicate internally, each
department viewing its information as its own and being reluctant to share it. Indeed, implementation
team members discovered that it was easier to learn and share experiences with people from outside
their organisation than within intra-organisational teams. This is where the chief benefit of using
consultants to aid implementation is apparent, they add value to the project by facilitat-ing meetings
as open discussions of requirements, preparing agendas, prioritising issues providing objectivity and
avoiding bias, conflicts of interests and possible confusion (Pg. 112). Thus consultancy agencies are
very important in ERP projects despite the possible lack of technical experience or knowledge (as in
Wood and Caldas 2000 study), be-cause they facilitate open and productive communication.
Palaniswamy et al. (2000) state that the higher the levels of communication and interaction in the
implementation team, the higher the performance of the team. The members of the team must be able
to communicate between themselves, with the clients, the suppliers and all other stakeholders.
A global ERP implementation can also cause communications problems, Stedman (1998) gives an
example of Meritor Heavy Vehicles Systems LLC which had to transfer a team of US employees to
Europe for nine months in order to eliminate communications breakdowns caused by time-zone
difficulties.
In the case studied, an additional team member was hired from a local PR company in order to
concentrate on communication between the project team and the other employees at the plant. As part
of his effort in communicating widely, he set up countless meetings, particularly with representatives
of the unions, where extremely sensitive negotiations with respect to changes to job specifications
were navigated to success with requisite care and attention. He and his team published 4 issues of a
special internal magazine, solely dedicated to communicating project news, progress reports on
achieving tar-gets and on respecting key milestones. At another level, this magazine served as a
channel to get across to employees out-side the project, in an entertaining way, what the purpose of the
project was and why their participation was vital. In addition, it introduced the project team to their
future trainees, such that when time for training came around, individual relationships were brought
into play to encourage full attendance.
On the day the application went live, one staff member ran the first transaction through the system
behind closed doors (to avoid building up too much pressure), but the whole team was brought into
the same office at 11.30 to stage a fake go-live for a historical photograph when it was certain
everything was going as planned.
5.8.

ERP Project Risk Management

There is ample empirical evidence of the risks involved in ERP implementations (Weston, 1998;
Davenport, 1998; Adam, 2000). Wood and Caldas (2000) have stated that ERP implementations
involve broad organisational transformation processes with significant implications on the
organisations management model, organisation structure, management style and culture and
particularly on people (Pg. 6). Thus as MacVittie (2001) puts it, ERPs require a radical change in the
business processes of organisations, radical change means risks and risks mean more time and money.
Sammer (2000) cited the example of Bournes Inc., a manufacturing company in California, which
encountered resistance to their new ERP system. Prior to the implementation, the local managers were
used to tailoring financial information and reporting to meet their needs, but post implementation,
there was consistent reporting across regions thus local managers were deprived of their autonomy and
reacted negatively towards the new system.
ERP systems are complex and they require reliance on many different types of expertise, which may
also need to be sourced outside the organisation. Good, experienced consultants are difficult to find,

thus employing a consultancy firm is no guarantee that the project will be a success. Companies,
which have trained their employees in the art of ERP implementation, stand a great risk of losing their
investment because personnel with such experience are in great demand by consulting agencies.
The company we studied employed a novel approach to keeping resources post-go live. Most of the
more senior resources returned automatically to their functions, whereas some of the data maintenance
and SAP technical resources were given a choice of 3 avenues for continuing with the company. They
could stay with the local company and move into the business stream that had worked on in the
project, they could move to another ERP implementation site which were crying out for the resource,
or they could stay with the project team in an ERP support role. Of 17 data analysts recruited for the
project, 12 were retained by the company in this manner post go-live.
Also, Wood and Caldas (2000) discovered low levels of satisfaction among firms that have
successfully implemented ERP systems, 45% of firms perceived no improvements whatever and 43%
stated that no cycle reduction had been obtained. In brief, the risks associated ERP implementation
projects are very high and the rewards are possibly very low. Yet as Wood and Caldas put it ERP
systems seem to have simply conquered hearts and minds throughout the business realm (Pg.5).
We had an opportunity to observe a similar phenomenon in the case study when all the members of the
ERP team slowly changed their minds during the 10 months of their implementation, evolving from a
position of reluctance to implement to one where they all thought that the loss of flexibility in their
business processes resulting from the ERP was a good thing because it would lead to more rigour in
the business. In this site, it seemed that the realisation that complete disaster had been averted and that
there would life after ERP was enough for everyone. That the headcount had in fact increased, or that
the response time of the application was, at times, several minutes (when their American colleagues
logged into the application) did not seem to matter in the end.

4.9.

ERP Project Procurement Management

Maher (1999) states that the different packages on the market have different strengths in different
areas, it is important for the customer to recognise this and select the package with the strengths that
are appropriate. Only when top management have reached consensus on what the business requires,
should package vetting and selection begin. When selecting the package, it is critical to get vendors to
state to what extent their products will meet each requirement. This is normally done in the Invitation
To Tender (ITT) released by firms buying ERP packages, but may not always be totally independent
and unbiased depending who firms asked to create the ITT for them. Also, vendors often side step key
issues by refusing to adhere to the template provided in the ITT and describing the way their products
operate without reference to the stated needs of their potential client.
Shanks et al. (2000) conducted a comprehensive survey of successful ERP implementations and
observed that ERP product selection is based on the following factors in the order of importance:
1.

Business Fit

2.

Ease of Implementation

3.

Vendor Services and Support

4.

Special Industry or Applications Capabilities

5.

Product Affordability

6.

Compatibility with Existing Systems

Judging these factors at the proper level of granularity requires using cross-functional and crossbusiness unit teams to ensure that the correct package is procured, i.e. a suite, which will support the
long-term goals of the organisation (Mina-han,1998). Beyond these issues remain the many legal

matters that are involved in ERP implementations. Drawing up a contract for an ERP application
require specialised legal assistance and often many iterations insofar as the standard contracts proposed by ERP vendors are overly protective of their interest and systematically neglect the rights of
their clients.
In our study, the decision to select SAP was a logical one, borne out of the fact that SAP is a package
certified by the Federal Drugs Authority (FDA) as being compliant. For a pharmaceutical firm, this
limits the risk of being imposed a penalty for infringement to compliance rules (knowing that such
penalties may run in hundreds of millions of dollars). As a result, the perspective of creating
implementation problems at the local level will not weight very heavily on the decision of the board of
Directors. Local managers were never even consulted.
5.10

ERP Project Rationale Management

Wood and Caldas (2000) found some dubious reasons for implementing an ERP system, these
included the need to follow a trend, the need to meet the pressures of the IT function and the
pressures of the head office. They found that 36% of respondents declared, The firm didnt know
exactly what it was buying or what could be expected from the system. They observed a scarcity of
rationality in the decision process, but a high degree of emotion accompanied by a high degree of
euphoria during implementation, which they believed, is consistent with managerial fads and
fashions (Pg. 7).
Davenport (1998) suggested a number of questions that management need to ask themselves, to ensure
that they are engaging in an ERP project for the right reasons and not from some knee-jerk reaction to
their competitors actions or some-thing that they have heard about in the media.
1. How might an ERP system strengthen our competitive advantage?
2. How might it erode our competitive advantage?
3. What will be the systems affect on organisational culture?
4. Do we need to extend the system across all functions?
5. Should we only implement certain modules?
6. Would it be better to roll out the system globally or restrict it to certain regional units?
7. Are there other alternatives for information management that might actually suit better than an ERP
system?
Top management need to answer these questions to ensure that they understand what an ERP system
actually implies. Wood and Caldas (2000) discovered that many organisations failed to implement
their ERP systems because they viewed them as just another IT project or some type of IT-meetsreengineering-project. Once top management have committed themselves to the project it is vital that
they are able to document the reasons for choosing to implement that system and that they publish the
reasons widely across the organisation (Minahan 1998). Clear and unambiguous statements by top
management regarding why the ERP system is being pursued are vital in ensuring the success of the
project.
As pointed out in the previous section, the board of Directors of the firm studied had decided to
implement SAP in a central and unilateral manner and there was no need for any debate as to what
rationale was being followed. However unsatisfactory such decision making process may seem for
local managers who dont ever get to make a real business case for ERP, there is no doubting the
rationality of making such choices in a multinational. However, this is very difficult to get across
properly at the local level.

5.11

ERP Project Review Management

The Deming Cycle (plan do check act) or Simons 1977 Decision Making Model (Intelligence
Decision Implementation Review) as applied to Project Management is disputed by some project
managers because if projects are unique there should be no need for a review since nothing can be
learned from it which can be applied to new projects in the future but this is quite misguided in that it
is still quite useful to establish whether the targets built into the project (which were used to justify the
investment) have been reached. Refusing to investigate whether reductions in inventory have been
achieved amounts to little less than buying ones head in the sand. However, this is an area where little
empirical evidence is available because many firms have been cagey about leaving researchers control
whether benefits had been achieved. Surveys have nevertheless indicated that many firms were aware
that specific improvements they sought never materialised.
In the firm we studied, an Operational Excellence group, which had been founded well in advance of
ERP to examine process improvements and improve performance metrics in general, was responsible
for carrying out an extensive AAR (After Action Review) of the entire project, whish involved
revisiting objectives 12 months after go live to evaluate whether they had been achieved. A media rich
presentation collating the results of the AAR was published internally on CD and on the web.
Indeed, this same group, from whose ranks one of the stream leads came, in its role of ongoing process
improvement mentors, are uniquely placed to advise different parts of the business on how to get the
best from the ERP system. As she put it herself, the head of the Operational Excellence group will go
investigating how to get information from the ERP system, when she is addressing a particular
process inefficiency. It is the researchers conviction that it is this trial and error approach to
exploiting the vast richness of transactional data stored in the ERP system, that will yield benefits in
the years following implementation, rather than bemoaning the lack of vanilla reports from the system
and the construction of parallel data warehouses to address specific functional reporting needs.
4.12

Global ERP Project Management

Production and manufacturing operations have become more complex, automated and geographically
dispersed according to Palaniswamy et al. (2000). ERP systems are designed to cope with the
complexity inherent in geographical dispersion but a global ERP implementation confronts many
issues, which are particular to worldwide implementation projects, e.g. decision making involving
different time horizons, geographical dispersion and concurrently (Palaniswamy et al. 2000).
Davenport (1998) wonders there should be uniformity a multinational does business in different
regions or countries. For most companies, differences in regional markets remain so profound that
strict process uniformity would be counterproductive. Companies must remain flexible and allow
regional units to tailor their operations to local customer requirements and regulatory structures.
Davenport recommends a type of federalist systems where different versions of the same system are
rolled out to each regional unit, e.g. Monsanto, Hewlett-Packard and Nescafe have found this approach
successful. This raises its own problems for the company, i.e. deciding on what aspects of the system
need to uniform and what aspects can be allowed to vary (Horwitt 1998).
In the case studied, it is clear that a good deal more could be done for local sites ability to question
and change a global template, if not the choice of package itself. Multi-national businesses need to
take into account the idiosyncrasies of local operations when imposing a global corporate standards on
critical business processes such as cash collection, procurement, and material planning.
By the time all sites had been implemented, the first sites had been left behind and had to upgrade to
the newer version of the package. Staff seemed resigned to the fact that an ERP implementation is
never truly over and that no one is ever al-lowed to get too comfortable with any business practice.

5.

CONCLUSIONS

The success rate of ERP implementations is not high in view of the sums invested by firms in these
applications. It has often been indicated that a combination of inadequate preparedness and
inappropriate project management have been responsible for the low success rate of ERP
implementations. Our investigation into the project management strategy adopted in the Pharma Inc.
case under the 12 headings of our revised model illustrates one vision of what could be termed best
practice in terms of ERP implementation. In particular, it shows the importance of project governance
and the need for a multi-level structure spanning both the corporate and local levels. It also shows the
crucial importance of the proper selection of team members and the need for a high profile team leader
even at the local level. On a more technical basis, it suggests that a dual cycle of exploration /
negotiation leading to a stable corporate template on the one hand and execution / roll out on the other
hand could greatly boost the success rate of ERP projects. Project managers need to be persuaded that
any unclear area not resolved in the exploration cycle will need to be tackled in the implementation or
else there is a risk that it might get left behind and only re-emerge after go live with disastrous
consequences. In relation to the creation of such a template, it is certain that differences in expertise
and cultures within MNCs (eg: primary versus secondary sites in our case study) cause many
additional problems which require substantial re-works and workarounds.
However, even in this very positive case, some aspects remain open to criticism. In particular, the need
for balance between attention to local specificities and the need to standardise business processes and
stay on schedule seems to be very difficult to find. In a MNC, the corporate level is strong enough to
impose its rules, but the cost at local level in terms of motivation lost and inefficiencies must be
understood. Also, the need to preserve learning in each roll out so it can benefit to all sites is critical
and was neglected in Pharma Inc. The core team members need to understand that it is part of their
role to support the communication between the sites that have done it and those that have not.
This research brings us closer to an ERP specific methodology to systems implementation in large
firms. However, more case studies will be required to assemble a complete set of best practice
recommendations for future ERP project managers.

References
Adam, F (2000) Rflexions sur le mouvement ERP Risques et Opportunits, Congrs de la NetEconomie, Mach 2000, Paris, France.
Berger, P. (1998) PGI: les services valent cher, Le Monde Informatique, 25th September 1998, #779.
Bingi, P., Sharma, M. and Godla, J. (1999) Critical Issues Affecting an ERP Implementation,
Information Systems Management, Summer 1999, 7-14.
Davenport, T. (1998) Putting the Enterprise into the Enterprise System, Havard Business Review, JulyAugust, 131-131.
Eisenhardt, K. M. (1989). Building theories from case study research. Academy of Management
Review, 14, 532-550
Horwitt, E (1998) Enduring a global rollout - and living to tell about it, Computerworld, March 1998.
McKie, S. (1999) The great leap forward, Business and Finance, January 1999.
McVittie, L (2001) Buckle up: Implementing ERP takes time and Patience, March 2001; URL:
www.networkcomputing.com/.
Maher, J (1999) ERP in industry: Automate and integrate, The Engineers Journal, November, 1999.
Maylor, H (2001) Beyond the Gantt chart: Project management moving on, European Management
Journal, 19(1).
Minahan, T (1998) Enterprise Resource Planning, Purchasing, July 16 1998.
Palaniswamy, R and Frank, T (2000), Enhancing Manufacturing Performance with ERP Systems,
Information Sys-tems Management, Vol. 17, No. 3, pp. 43-55.
Patton, M. (1990) Qualitative evaluation and research methods, Sage Publications, Newbury Park, CA.

PMBOK (2000) Project Management Institute Body of Knowledge. URL: www.pmi.org.

Sammer, J (2000) The ERP continuum, Business and Finance, Issue 343, December.
Scott, J and Kaindl. L (2000) Enhancing functionality in an enterprise software package, Information
and Manage-ment, 37.
Shanks, G., Parr, A., Hu, B., Corbitt, B., Thanasankit, T., Seddon, P., 2000, Differences in Critical
Success Factors in ERP Systems Implementation in Australia and China: A Cultural Analysis,
Proceedings of the 8th European Con-ference on Information Systems, July 3-5 2000, Vienna
Austria, 537-544.
Simon H., 1977, The New Science of Management Decisions, Prentice Hall, Englewood Cliff, New
Jersey.
Stedman, C Global ERP rollouts present cross-border problems, Computerworld, November 1998.
Weston, R (1998) ERP users find competitive advantages, Computerworld,, January 19, 1998
Wood, T. and Caldas, M. (2000) Stripping the big brother: unveiling the backstage of the ERP fad,
http://www.gv.br/prof_alunos/thomaz/ingles/paper5.htm.