The current issue and full text archive of this journal is available at

www.emeraldinsight.com/1753-8378.htm

IJMPB
1,1

Project management: a case study

of a successful ERP
implementation

106
Received 5 August 2007
Accepted 20 October 2007

Fergal Carton, Frederic Adam and David Sammon

Business Information Systems, University College Cork, Cork, Ireland
Abstract
Purpose The success rate of enterprise resource planning (ERP) implementations is not high in
view of the sums invested by organisations 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. The purpose of this paper is to
present a case study of a successful ERP implementation.
Design/methodology/approach In this paper, the authors use a case study of a very successful
roll out of an ERP application in the Irish subsidiary of a UK multinational to investigate the validity
of one of the most commonly cited project management frameworks, the project management body of
knowledge (PMBOK), to ERP projects. Discussing each category of the framework in turn, the case
data to illustrate where the PMBOK framework is a good fit or needs refining for ERP projects is used.
Findings It is found that, by and large, PMBOK, because it is a very broad framework, can shed
light on most of the key aspects of an ERP project. However, the specificities of this type of project
require a different emphasis on some of the factors, as discussed in the authors conclusions. The case
analysis also raised some interesting insights into how companies evaluate the success of such highly
complex change management initiatives.
Research limitations/implications This research work will need to be extended to cover other
case studies of ERP implementation across other industries and organisational contexts; for example
in less tightly regulated industries and smaller organisations.
Practical implications This discussion will be of great value to ERP project managers who are in
the early stages of a project and need to understand and anticipate the areas which will require specific
attention on their part, based on their knowledge of the specific circumstances within their
organisational context.
Originality/value This paper presents an investigation into the project management strategy
adopted in the Pharma Inc. case and illustrates the mechanics of a successful ERP project
implementation, categorised using the PMBOK framework.
Keywords Manufacturing resource planning, Project management
Paper type Case study

International Journal of Managing

Projects in Business
Vol. 1 No. 1, 2008
pp. 106-124
q Emerald Group Publishing Limited
1753-8378
DOI 10.1108/17538370810846441

1. Introduction
A considerable volume of research has been carried out on enterprise wide systems and
most notably on enterprise resource planning (ERP) systems. This research has
established that on the one hand, significant benefits can accrue to organisations
implementing these systems (Shang and Seddon, 2002) but on the other, many
implementations are not conclusively successful (Holland et al., 1999). There is
evidence that the degree to which organisations prepare themselves 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 (Sammon et al., 2004). It also appears that inadequate project management leads

to short-term solutions being applied to the problems that occur during the
implementation of ERP systems with substantial side effects when systems go live
(Saint-Leger and Savall, 2001). Previous research has indicated that the scope and
complexity of ERP implementations are different from traditional analysis and design
projects (Davenport, 2000) suggesting specific project management strategies should
be developed to tackle the specific challenges of such projects. In particular, it is argued
that ERP projects are often associated with the widespread re-engineering of
business practices, whereas traditional projects have smaller organisational
footprints and are designed to match current practices. In this paper, we leverage
our investigations of a very successful ERP implementation in a multinational
pharmaceutical company (Pharma Inc.) to gain an insight into the project management
strategy adopted to manage what was a successful ERP implementation. To facilitate
the presentation of our findings from this case investigation we use the nine areas of
the project management body of knowledge (PMBOK) framework.
The remainder of this paper is organised as follows. The next section presents
the PMBOK framework, which has been put forward as a best practice vehicle to
understand project management in information systems (IS) projects (Project
Management Institute PMI, 2000). In the second section, we present the case
study protocol we followed and the methods we applied to the case study of Pharma
Inc. In the third section, we review the findings of the case under the nine headings of
the PMBOK framework and, finally we propose conclusions towards excellent project
management practices for ERP projects.
2. The PMBOK framework
Project management helps project managers to standardise routine tasks and ensure
that available resources are used both efficiently and effectively. The application of its
principles allows senior managers to establish and use appropriate measures of
success, to quantify value commensurate with cost and to optimise the use of
organisational resources. Project management as a discipline is only a recent concept
and yet, over the past 50 years a considerable body of knowledge has been built up
around its tools, skills and techniques. The PMI is acknowledged as the pioneering
group worldwide for bringing professionalism to the area of project management. The
PMI boasts a worldwide membership of several hundreds of thousands. The PMI
provides a variety of services for project managers, including: education and
certification, and standards in the form of the PMBOK.
The PMI produced the first version of the PMBOK in 1987 and the PMBOK has
been continually enhanced since then, with the third edition produced in 2000. The
PMBOK is a set of standards (management best practices that are common to projects)
and it describes the sum of knowledge within the profession of project management.
The body of knowledge rests with practitioners and academics that apply and advance
it (PMI, 2000). The PMBOK is organised into nine knowledge areas that are considered
a subset of project management and describes the knowledge and practices in terms of
the component processes required to ensure a project is properly coordinated (PMI,
2000) such that the project:
.
will satisfy the needs for which it was undertaken;
.
will be successfully completed in a timely fashion and within the approved
budget;

Project
management

107

IJMPB
1,1

.
.
.
.

108

will
will
will
will

make the most effective use of people involved;

have timely information provided;
avoid unnecessary risks; and
have the required external resources available.

The processes within each knowledge area interact with each other and with the
processes in other knowledge areas. Each process has an input for the process tools
and techniques to carry out the process, and an output from the process. While each
process presented within the knowledge areas appear as discrete elements with
well-defined interfaces, some interaction and overlap is expected in practice. The nine
areas are illustrated in Table I.
2.1 The application of the PMBOK framework to ERP projects
One of the recommendations of the PMI is that although the PMBOK is generally
accepted and there is widespread consensus regarding the value and usefulness of the
nine knowledge areas, it does not mean that the knowledge and practices described
should be applied uniformly on all projects. Ultimately, the project management team
is always responsible for determining what is appropriate for any given project (PMI,
2000, p. 3). Therefore, one issue of importance in this paper is whether this PMBOK
framework is immediately applicable to ERP projects. It is useful to consider to what
extent ERP implementations are like or unlike other IS projects. Prima facia, most of
the salient points (either good or bad) that have been reported about ERP projects in
the literature, either in terms of case studies or in terms of critical success factor (CSF)
research, seem to fall naturally within these categories. Thus, we can argue that there
is a good fit between the PMBOK traditional framework and ERP projects.

Knowledge area

Description of required processes

Project integration management

Ensures that various elements of the project are

properly coordinated
Includes all of the work required, and only the work
required, to complete the project successfully
Ensures timely completion of the project
Ensures that the project is completed within the
approved budget
Ensures that the project will satisfy the needs for
which it was undertaken
Makes the most effective use of people involved with
the project
Ensures timely and appropriate generation,
collection, dissemination, storage, and ultimate
disposition of project information
Is concerned with identifying, analysing, and
responding to project risk
Involves acquiring goods and services from outside
the performing organisation

Project scope management

Project time management
Project cost management
Project quality management
Project human resource management
Project communications management
Project risk management
Project procurement management
Table I.
Nine areas of the PMBOK

Source: PMI (2000)

Nevertheless, reported cases of ERP failure seem to indicate that certain, particularly
sensitive areas of traditional project management require greater emphasis than
others. For example, the specification of requirements for ERP projects is often
non-existent or applied retrospectively because organisations are hoping to acquire
ready-made solutions that embody best practice that is directly applicable to them. In
these cases, the project begins with discussions with consultants already propounding
a particular software solution and technical architecture where other important aspects
are overlooked, for example, how the project should be managed. Based on calls from
previous researchers to derive better suited project management practices and better
approaches to ERP in general (Sauer, 2002; Swanson and Ramiller, 2004) and on
available evidence of the problems that have led to significant failure rates in the past
for such projects, there is a need to analyse the nine areas of the PMBOK and discuss
their relevance in the context of a successful ERP project implementation process in
order to fully understand how to apply the framework in the case of an ERP project.
According to the PMI, project management is the application of knowledge, skills,
tools, and techniques to project activities in order to meet or exceed stakeholder needs
and expectations from a project (PMI, 2000). However, there are competing demands
among scope, time, cost, and quality; differences in stakeholders needs and
expectations; and identified requirements (needs) and unidentified requirements
(expectations). As a result, it is critical to the success of a project and the ability to
address these competing demands that the organisations structure and approach to
the management of projects is a match to the objectives of the ERP implementation.
While an understanding of vanilla project management is beneficial, it is not
sufficient, due to the fact that projects and project management operate in an
environment broader than that of the project itself and the project management team
must understand this broader context. For example, managing the day-to-day
activities of the project is necessary for success, but not sufficient (PMI, 2000). In this
paper, we examine a case study of an ERP roll out in an American multinational
involved in the pharmaceutical sector. We also investigate the perceptions of a project
team responsible for the implementation of an ERP package as the project progress
through the stages of the project lifecycle. Using the nine areas of the PMBOK to
organise the case data we present an insight into what happened and into the evolution
of the project team members perceptions of the project management challenges.
3. Methodology
In this paper, we present a case study of Pharma Inc., where a successful ERP
implementation took place over a period of time between early-2003 and end-2004. We
followed the case study over this period, and as a benchmark project it has
considerable value in that it is perceived by all participants as being a notable success,
both for the implementing subsidiary and for the parent company. Concretely this
means that the system went live as expected, on time and within budget, and that the
project team were able to achieve a rapid ramp-up to full production volumes ahead of
time (seven weeks instead of the predicted nine weeks after go-live). This makes
Pharma Inc. an example of an extreme case in Pattons (1990) classification of
purposeful sampling strategies and this justifies the choice of this case as a basis for
determination of best practice in ERP implementations.

Project
management

109

IJMPB
1,1

110

3.1 The case study

The case involves a manufacturing subsidiary of a multinational pharmaceutical firm
implementing a single instance of specific technical skills (SAP) across a large number
of sites worldwide (refer to Table II for key information about the case). This
subsidiary is what is termed a primary site meaning that it produces batches of
active ingredients to be used in other secondary sites where the tabletting and
packaging of the drugs is performed.
One feature of this case study is that previous waves of the ERP implementation
had only been carried out at secondary sites. The manufacturing subsidiary studied
here was the first primary site to go live on the new SAP system, and this raised
additional challenges that were not anticipated. Project members from the
implementation team studied here were solicited by the core team post go-live to
assist with the SAP roll-out in further primary sites, based on the skills and know-how
gained in adapting the global template to their local (primary site) requirements.
3.2 Data collection and analysis
In Pharma Inc., we carried out 26 interviews and distributed a total of 63
questionnaires over four rounds. The fieldwork was focused on the local
implementation team and the evolution of their perceptions of the project
management challenges as the project progressed from initiation to go-live and
beyond. Table III summarises the data collection carried out.
An original facet of the research method employed was that interviewees
themselves were asked to define the key strengths of the company, and then in
subsequent interviews, as the project progressed through the preparation and
implementation phases, they were asked to comment on how ERP impacted these
strengths. This internal view of key strengths and their subsequent evolution is a
method of self-reporting that removed any notion of putting words into peoples
mouths as the project progressed. Researchers have been trying for some time to

Key features

Pharma Inc. case study

Type of organisation
Industry
Size (emp.)
Turnover
Scope of project

Multi national
Pharmaceutical
100,000
$25 billion (2004)
Manufacturing, planning, procurement, sales and distribution, finance,
engineering, quality for local manufacturing site
Worldwide roll-out of SAP in four waves
Five years for entire roll out, 18 months for local manufacturing site
Local steering committee, local project team and global core
implementation team
Local managers from affected functions seconded to project
100 per cent for 18 months
40-70 people locally 45 in core teama

Type of project
Duration
Project leadership
Project managers
Team members availability
Project resources
Table II.
Key characteristics of the
case study organisation

Note: aThe core team is based at corporate headquarters, is independent of the IT organisation, and
moves from location to location to facilitate the local roll outs during the successive waves of the
project

Number
Interviews by function
Finance
Manufacturing/distribution
Sales
Information systems
Engineering
HR
Total
Questionnaires completed
April 2003
May 2003
December 2003
September 2004
Total

2
14
2
3
2
3
26
22
11
16
14
63

understand the low-success rate of ERP projects by analysing retrospectively the

implementation experience of practitioners in terms of either CSFs or business benefits
accrued (Markus et al., 2000; Parr and Shanks, 2000; Somers and Nelson, 2001; Murphy
and Simon, 2002; Shang and Seddon, 2002; Lam, 2005; Finney and Corbett, 2007).
Therefore, in the case of the novice ERP project team studied in this case, we decided
that letting the interviewees define the criteria to be measured at the outset, based on
their own expectations of the forthcoming organisational change, ensured relevance
and a sense of ownership of the field data.
We began this research as invited facilitators of a team building and ERP
awareness seminar pre-project implementation in April 2003. This allowed us direct
access to the team members at a very early stage in the process, and the feedback from
the first round of interviews and questionnaires demonstrated a certain perception of
the benefits of ERP that radically changed over the remaining months of the project.
Becoming known as the team confessors we had privileged access to the local
implementation team for the duration of the project. Being seen as neutral observers,
we were privy to the personal opinions, doubts and convictions of the team as they
struggled with the concept, timescale and reality of spearheading the organisational
changes that are part of an ERP roll-out. We feel that this insider knowledge allowed
us to make judgments on what elements of the project management had contributed
most to its success, and in so doing, to enrich the PMBOK framework with criteria
specifically aimed at achieving success in large-scale enterprise integration projects.
4. ERP project management at Pharma Inc.
The following sections report on the findings and important observations from the case
study organised using the nine areas of the PMBOK framework.
4.1 Project integration management/project quality management
An ERP system involves 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 that ensures the quality of the final system, i.e. that the system is

Project
management

111

Table III.
Summary of data
collection

IJMPB
1,1

112

implemented in an efficient way and the objectives are met (Minahan, 1998; Stefanou,
2000). Most of these methodologies insist on preparing properly and thoroughly from
the chartering phase itself prior to acquiring or implementing any technologies. 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.
In Pharma Inc., the overall level of preparation was quite good at the local site, given
that this was the fourth wave of a global project that had already seen five
manufacturing sites go-live with the ERP global template. It was understood from the
outset that the number one objective of the project was process compliance, which
would have an immediate impact on the plants ability to withstand an audit from the
industry regulatory body, the Food and Drug Administration. In this context, ERP was
ultimately seen as a necessary cost avoidance investment. This was confirmed in a
survey question aimed at soliciting team members understanding of the expected
benefits to be delivered by the new ERP system. Table IV highlights the results of this
survey question from April 2003.
There was a general acceptance that the benefits to be derived from the ERP roll-out
were for the greater good of the corporation, rather than any particular advantage to
be derived from the local site. The aggregated results of the answers to the question Is
ERP an enabler or a driver of change? in April 2003, when the project team was still
being consolidated, and there may still have been some hope among team members
that some benefits would accrue to the site, despite the acknowledged compliance
agenda show our respondents split 45 per cent (enabler)/55 per cent (driver). By
contrast, in December 2003, just before the project went live, only 9 per cent of
respondents held on to their belief that the ERP had been a enabler of change,
91 per cent judging it to have been a driver of change. This conviction, that ERP was
imposing change, softened somewhat after go-live, with the 91 per cent dropping to
71 per cent six months later, after go-live. It might be argued, that at this point, any
remaining naivety about the rationale behind the ERP implementation had
evaporated, but that team members could sense the potential for engineering
improvements to the newly implemented compliant processes. Key here would be the
confidence of the team as it had gone through a very aggressive project, gone live on
time and come out intact.

Expected benefits

Table IV.
What are the expected
benefits from the ERP
implementation?

Greater compliance/validated system

Integrated well documented ways of working
Standardisation to global processes
Integration of all key sites systems
Better control of tasks
Increased accuracy of inventory
Integration with the global supply network
One set of data
Better planning and scheduling functions
Do not know

Number of respondents
9
7
3
3
2
2
1
1
1
7

It is interesting to note that, at the early 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 being far ahead of other sites in Pharma Inc.,
particularly with respect to customer satisfaction, a key performance indicator
measuring the per cent shipments made to customers within the commit date. Local
management were worried that this global roll-out would impact their customer
satisfaction rating, their efforts in distinguishing themselves being therefore nullified.
However, this impression was slowly reversed over the course of the project. When
initially asked in April 2003 to list the core competences or areas of excellence that
made them stand out from other subsidiaries, respondents identified the following
strengths: customer responsiveness, innovation, new product introduction (NPI), CAN
DO attitude, R&D (research and development), implementation of new
processes/technologies, manufacturing knowledge and ability, project delivery track
record/proven performance, and highly efficient and flexible operation/quality.
Approximately nine months later, just prior to go-live, they were asked to rate the
impact of the new ERP systems on these core competences. The results of this question
are displayed in Table V.
This picture changed dramatically in the months following go-live, with a
polarisation of opinion around key strengths such as customer responsiveness and
CAN DO attitude. Table VI shows the post go-live situation in September 2004 for
the same question. The relevance these findings have for our study is that the rationale
for ERP project implementations is not a static business case, showing a monetary ROI
after x number of years. It is much more closely linked to companys values, and the
perception of impact on those values, among core team members (who are arguably
best placed to judge the impact), evolves in a negative sense over the lifetime of the
project.
As already argued by Davenport (1998), top management need to answer some
serious questions at the outset to ensure that they understand what an ERP system
actually implies. Wood and Caldas (2001) discovered that many organisations failed to
implement their ERP systems because they viewed them as just another IT project or
some type of IT-meets-reengineering-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.
At Pharma Inc., it is clear that a good deal more could have been done for local sites
ability to question and change a global template, if not the choice of package itself.
multinational corporations (MNCs) need to take into account the idiosyncrasies of local
operations when imposing a global corporate standard 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 one cannot get too comfortable with any business practice. In
the case of Pharma Inc., an operational excellence group, which had been founded well
in advance of ERP to examine process improvements and improve performance

Project
management

113

Customer responsiveness
Innovation, NPI
CAN DO attitude
R&D
Implementation of new processes/technologies
Manufacturing knowledge and ability
Project delivery track record/proven performance
Highly efficient and flexible operation/quality
1

4
3
1
2
4
4
4
5
2
2

3
2
1
1
1
3
3
4
2
4
3
1

Low

3
2
2
3
1
2
2

N
Medium to high positive/medium negative
Medium to low positive/low negative
Low positive/high to low negative
Low to medium positive/low negative
Medium positive/low negative
Low to medium positive
Medium to low positive
Medium positive/medium to low negative

Notes: The level of impact is categorised as positive (P ) or negative (N ) across high/medium/low. The numbers in the cells relates to the total number
of respondents selecting that level of impact for a specific core competency/area of excellence. For example, three respondents perceived the ERP system
to have a high positive impact on customer responsiveness while four respondents suggested a medium positive impact on customer responsiveness

2
1

2
1

Level of impact
Medium
P
N

114

1
1

Table V.
Level of impact of ERP
on core competences
(December 2003)

Core competency/area of excellence

High

IJMPB
1,1

2
3
1
2
3
3
3

Customer responsiveness
Innovation, NPI
CAN DO attitude
R&D
Implementation of new processes/technologies
Manufacturing knowledge and ability
Project delivery track record/proven performance
Highly efficient and flexible operation
Quality
Inspection readiness
2
1

1
1
1
1
1

N
5
1
5
2
3
7
5
3
3
3
2
6

3
2
3

Level of impact
Medium
P
N
1
2
1
6
3
1

Low
1
4
1
1
3
1
3
1

N
Medium positive/medium negative
Low to medium negative
Medium positive/medium negative
Low to medium positive
Low negative/high to low positive
Medium positive
High to medium positive/low negative
Medium negative/medium positive
High positive
High positive

Notes: The level of impact is categorised as positive (P) or negative (N) across high/medium/low. The numbers in the cells relates to the total number of
respondents selecting that level of impact for a specific core competency/area of excellence. For example, two respondents perceived the ERP system to
have a high positive impact on customer responsiveness while five respondents suggested a medium positive impact on customer responsiveness

10
10

Core competency/area of excellence

High

Project
management

115

Table VI.
Level of impact of ERP
on core competences
(September 2004)

IJMPB
1,1

116

metrics in general, was responsible for carrying out an extensive after action review
(AAR) of the entire project, which 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 plays a role of ongoing process improvement and its 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 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, so prevalent among
other less successful implementations. Indeed, this approach is evidence of the survival
of the CAN DO attitude, despite the perceived constraints of ERP!
4.2 Project communications management
It has been observed that organisations find it very difficult to communicate internally,
each department viewing its information as its own and being reluctant to share it
(Scott and Kaindl, 2000). 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 primary benefit of using
consultants to aid implementation is apparent as they add value to the project by
facilitating meetings and the open discussions of requirements, prioritising issues and
avoiding conflicts. Thus, consultancy agencies are important in ERP projects despite
the possible lack of technical experience or knowledge (as in Wood and Caldas, 2001)
because they facilitate open and productive communication.
At Pharma Inc., of an initial core team of 24 business representatives only two 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. Following this rapid learning curve, with just nine months on the
project and with go-live imminent, team members were extremely aware of the extent
of the changes that were about to take place and for which they would have to take
responsibility. Table VII illustrates their response to the question What level of
change do you expect across the main business processes impacted by ERP?
It was recognised at Pharma Inc. that dealing with change of the scale implied by a
new ERP system would require particular attention and careful monitoring. 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 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. Furthermore, the project PR consultant and his team published four issues of a
special internal magazine, solely dedicated to communicating project news, progress
reports on achieving targets and on respecting key milestones. This served as a channel

High
Warehouse/material movements
Production planning and production execution
Plant maintenance
Quality control
Engineering
NPI/R&D
Procurement
Customer service/supply
Financial management
Sales and distribution

6
6
6
6
3
1
1

Process level of change

Medium

Low

Project
management

3
3

117
1
1
1
1
1

Notes: The process level of change is categorised as high/medium/low. The numbers in the cells
relates to the total number of respondents selecting the process level of change for a specific business
area. For example, six respondents perceived the ERP system to have a high process level of change
in warehouse/material movements while three respondents suggested a medium process level of
change

to get across to employees outside 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.
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 logistics director to the role of
implementation site leader ensured that the project team was given recognised status
and authority in the eyes of local employees, and a direct line of communication was
opened between the project team and the general manager of the plant. Crucially, 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 a critical point in
the implementation analysis phase, the site leader threatened to pull his entire team out
of the project 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 relationship, as acknowledged by both sides, and contributed certainly to the
success of the project.
4.3 Project scope management
Again, this aspect of ERP projects pertains to how well organisations are prepared
when they embark on their implementations. 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. A lack of
understanding of the scope of the system may result in a conflict between the logic of

Table VII.
What level of change do
you expect in your
business area?

IJMPB
1,1

118

the system and the logic of the business. In complex organisations such as MNCs, this
requires a preliminary determination of what configuration will be rolled out in the
different sites the template. At Pharma Inc. the global template had been designed
around corporate best practice. So the parameters and options that were available to
the implementing site were not a question of SAP options, but rather a question of
choices available under the corporate best practice template the global standard
operating procedures or GSOPs. It became clear that in order to negotiate changes to
this template, with a view to accommodating local requirements, new types of skills
would be required. The discussion became a three-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 was not, possible with SAP. On several occasions, 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. For example, core team members were
unable to understand the limitations of a bulk chemical dispensing parameter that did
not have the required number of decimal places to record the actual readings from the
scales in use in the plant (the template having been designed for tablets, not bulk
chemical). The response of the core team, unacceptable to the local implementation
team, was to use the parameter as it was defined and lose the data granularity! 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, was the source of such problems. 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.
In this case study the scope was very broad (warehouse, engineering, finance,
procurement, production planning, production execution, quality, sales and
distribution and NPI/R&D). All of these modules were integrated in the new global
process model, so it was not an option to implement a subset. During the project, two
elements of the scope of the project emerged 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 system; and
(2) the changes that would be required to the physical organisation of the
warehouse function 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 ensured that data going into the new
system was clean, valid and in the right format.
4.4 Project time management/project cost management
Depending on the size of the organisation and the scope of the project, implementing an
ERP system may take years because of the need to be rolled out across multiple sites,
lines of business and countries. In the case of global roll-outs at MNCs, project
time management is critical during the chartering, project and shakedown phases.

At Pharma Inc., the four waves of the implementation programme ran over a period of
over five 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 sometimes
resulted 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 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 sites within the same organisation can improve the template
based on their own implementation experience, such that subsequent sites might
benefit, is very difficult to put in place without 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). This might explain why the local
implementation team did not regard project management as important initially. At the
beginning, the team perceived the required skills for the project to be knowledge of SAP
(38 per cent), process knowledge (27 per cent), existing systems knowledge (23 per cent)
and project management (14 per cent). This perception developed over time however,
and the importance of project management skills began to grow as the project
approached go-live. It needs to be remembered that none of the team members were
project managers per se, and that there was no systems integrator on board to carry
the can for meeting deadlines. Figure 1 shows how the perception of skills changed
over time (in December 2003 and nine months after go-live in September 2004).
The increased importance of Project Management SAP Knowledge and the
continued importance of the Process Knowledge skill sets is evident. On the other
hand, Existing Systems Knowledge and Data Knowledge is perceived to be less
important.
Like most software, ERPs are priced on the functionality of the system and the
number of users who will access it. Organisations are also required to invest in

Project
management

119

IJMPB
1,1

December 2003
6% 0%
Process Knowledge

120

17%

32%

Existing Systems
Knowledge
Data Knowledge
28%

17%

Knowledge of SAP
September 2004

Project Management

11%

0%

Other

Figure 1.
What skills are most
important in this ERP
project? (December 2003
vs September 2004)

32%
24%

19%

14%

migrating data, modifying existing systems and overhauling hardware and network
infrastructure. 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 resource bill for the project:
secondment (and back-filling) of his stream leads for 12 months, the hiring of
additional resources for data cleansing and the hiring of SAP. In addition, the
infrastructural costs to set the team up were considerable. This does not include
training, travel and administrative costs.
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 organisation 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 local site workforce. An
extensive training programme was put in place to ensure that 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 resources. 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.
4.5 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. This implies
reassigning 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). It is not rare to find functional
areas reluctant to sacrifice their best resources 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 organisations with no culture of
working across functional areas and no experience of such large projects.
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. At Pharma Inc., 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
entire duration of the project or for shorter periods. At key times in the project, staff were
added to the team for specialised tasks such as data conversion, training or desktop
deployment, such that the team grew to more than 100 at certain times.
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, but
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 upstream and downstream effects of choices
and configuration options they make as the project progresses. 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 specialist 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. It was 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
beginning 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.
4.6 Project risk management/project procurement management
Implementing an ERP system requires a radical change in the business processes of
organisations, radical change means risks and risks mean more time and money.

Project
management

121

IJMPB
1,1

122

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. Organisations, which have trained their
employees in the art of ERP implementation, stand a great risk of loosing their
investment because personnel with such experience are in great demand by consulting
agencies. Our case study showed a unique willingness to go it alone with respect to
integration partners. There were no consultants employed in the local implementation
team. SAP were hired into the team on contracts to bolster the team without the
exorbitant expense of paying consultants day rates. The net effect was that costs were
minimised and 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 and better able to validate the
quality of what would ultimately be delivered.
5. Conclusion
Our investigation into the project management strategy adopted in the Pharma Inc.
case under the nine headings of the PMBOK framework 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. Indeed, these governance structures ensured that
the ERP project maintained focus in terms of direction, reduced the possibility of
delays and rework due to the fact that timely problem resolution could be carried out.
Overall, these structures supported timely decision making in an effort to minimise the
impact, or avoid the possibility, of risks on the project. 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. Being able to call on specific local skills at different
points in the project, whether they were application focused or business focused, was a
strong factor in the success of the implementation. 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. In relating the areas of ERP project management to
specific stages of the ERP development lifecycle, attention is drawn to specific areas
that need to be emphasised at different times. Project managers need to be persuaded
that any unclear area not resolved in the exploration cycle will need to be tackled in the
implementation stage or else there is a risk that it might get left behind and only
re-emerge post go-live with disastrous consequences. In relation to the creation of the
template of the ERP, it is certain that differences in expertise and cultures within MNCs
(e.g. primary vs 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, but also in the
following phases of the roll out is critical and was neglected in Pharma Inc.
This research brings us closer to an ERP-specific project management for large
organisations. It also suggests a novel approach to using the perceived strengths of the
organisation as a barometer for the impact of such transformational systems, such as
ERP. Further, case studies are planned to assemble a complete set of best practice
recommendations for future ERP project managers. However, a potential weakness in
the current methodology is that the pharmaceutical sector is highly regulated; therefore
business functions are very familiar with the bureaucratic constraints imposed by
external bodies in terms of quality, safety, traceability and transactional integrity.
90 per cent of the errors in batch manufacturing are around documentation is how it
was described by one corporate manager. This puts the organisation at an advantage
when implementing a highly integrated suite of applications where new control
processes will perhaps find acceptance more quickly than in a less regulated
manufacturing environment. In fact, looking at a sample of such implementations in a
less regulated organisational environment, through the lens of the PMBOK framework,
would constitute a further step in validating the findings of this study.
References
Bingi, P., Sharma, M. and Godla, J. (1999), Critical issues affecting an ERP implementation,
Information Systems Management, Summer, pp. 7-14.
Davenport, T.H. (1998), Putting the enterprise into the enterprise system, Havard Business
Review, July/August, pp. 121-31.
Davenport, T.H. (2000), Mission Critical Realizing the Promise of Enterprise Systems, Harvard
Business School Press, Boston, MA.
Finney, S. and Corbett, M. (2007), ERP implementation: a compilation and analysis of critical
success factors, Business Process Management Journal, Vol. 13 No. 3, pp. 329-47.
Holland, C.P., Light, B. and Gibson, N. (1999), A critical success factors model for enterprise
resource planning implementation, Proceedings of the 7th European Conference on
Information Systems, Copenhagen Business School, Copenhagen, pp. 273-87.
Lam, W. (2005), Investigating success factors in enterprise application integration: a case-drive
analysis, European Journal of Information Systems, Vol. 14 No. 2, pp. 175-87.
Maher, J. (1999), ERP in industry: automate and integrate, The Engineers Journal, November.
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, Vol. 15 No. 4, pp. 245-65.
Minahan, T. (1998), Enterprise resource planning, Purchasing, 16 July.
Murphy, K.E. and Simon, S.J. (2002), Intangible benefits valuation in ERP projects, Information
Systems Journal, Vol. 12 No. 4, pp. 301-20.
Parr, A. and Shanks, G. (2000), A model of ERP project implementation, Journal of Information
Technology, Vol. 15 No. 4, pp. 289-303.
Patton, M. (1990), Qualitative Evaluation and Research Methods, Sage, Newbury Park, CA.
PMI (2000), A Guide to the Project Management Body of Knowledge, PMI Publishing Division,
The Project Management Institute, Sylva, NC.
Saint-Leger, G. and Savall, H. (2001), Lapres project ERP: Retour dexperience sur un
changement qui na pas eu lieu (Post-ERP phase: feedback from experience regarding a

Project
management

123

IJMPB
1,1

124

change which did not occur), Conference de lAssociation Information et Management,

Nantes.
Sammon, D., Adam, F. and Carton, F. (2004), Understanding the ERP post-implementation
discourse, Proceedings of the 6th International Conference on Enterprise Information
Systems, April, Porto, Portugal.
Sauer, C. (2002), ERP project implementation pitfalls, available at: www.snrgy.com/next/
article3.htm (accessed 3 October 2002).
Scott, J. and Kaindl, L. (2000), Enhancing functionality in an enterprise software package,
Information & Management, Vol. 37 No. 3, pp. 111-22.
Shang, S. and Seddon, P.B. (2002), Assessing and managing the benefits of enterprise systems,
Information Systems Journal, Vol. 12 No. 4, pp. 271-99.
Somers, T.M. and Nelson, K. (2001), The impact of critical success factors across the stages of
enterprise resource planning implementations, Proceedings of the 34th Hawaii
International Conference on Systems Sciences, Honolulu, HI, USA, pp. 1-10.
Stefanou, C. (2000), The selection process of enterprise resource planning (ERP) systems,
Proceedings of the 6th Americas Conference on Information Systems (AMCIS),
10-13 August, Long Beach, CA, pp. 988-91.
Swanson, E.B. and Ramiller, N.C. (2004), Innovating mindfully with information technology,
MIS Quarterly, Vol. 28 No. 4, pp. 553-83.
Wood, T. and Caldas, M. (2001), Reductionism and complex thinking during ERP
implementations, Business Process Management Journal, Vol. 7 No. 5, pp. 387-93.
Corresponding author
David Sammon can be contacted at: dsammon@afis.ucc.ie

To purchase reprints of this article please e-mail: reprints@emeraldinsight.com

Or visit our web site for further details: www.emeraldinsight.com/reprints