Project management: a case studyof a successful ERPimplementation

Fergal Carton, Frederic Adam and David SammonBusiness Information Systems, University College Cork, Cork, Ireland

Abstract

Purpose – The success rate of enterprise resource planning (ERP) implementations is not high inview of the sums invested by organisations in these applications. It has often been indicated that acombination of inadequate preparedness and inappropriate project management have beenresponsible for the low-success rate of ERP implementations. The purpose of this paper is topresent a case study of a successful ERP implementation.

Design/methodology/approach – In this paper, the authors use a case study of a very successfulroll out of an ERP application in the Irish subsidiary of a UK multinational to investigate the validityof one of the most commonly cited project management frameworks, the project management body ofknowledge (PMBOK), to ERP projects. Discussing each category of the framework in turn, the casedata 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 shedlight on most of the key aspects of an ERP project. However, the specificities of this type of projectrequire a different emphasis on some of the factors, as discussed in the authors conclusions. The caseanalysis also raised some interesting insights into how companies evaluate the success of such highlycomplex change management initiatives.

Research limitations/implications – This research work will need to be extended to cover othercase studies of ERP implementation across other industries and organisational contexts; for examplein less tightly regulated industries and smaller organisations.

Practical implications – This discussion will be of great value to ERP project managers who are inthe early stages of a project and need to understand and anticipate the areas which will require specificattention on their part, based on their knowledge of the specific circumstances within theirorganisational context.

Originality/value – This paper presents an investigation into the project management strategyadopted in the Pharma Inc. case and illustrates the mechanics of a successful ERP projectimplementation, categorised using the PMBOK framework.

Keywords Manufacturing resource planning, Project management

Paper type Case study

1. IntroductionA considerable volume of research has been carried out on enterprise wide systems andmost notably on enterprise resource planning (ERP) systems. This research hasestablished that on the one hand, significant benefits can accrue to organisationsimplementing these systems (Shang and Seddon, 2002) but on the other, manyimplementations are not conclusively successful (Holland et al., 1999). There isevidence that the degree to which organisations prepare themselves for theirimplementation projects has a bearing on whether they encounter many problemsduring implementation and ultimately, whether they achieve any of the benefits theysought (Sammon et al., 2004). It also appears that inadequate project management leads

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

www.emeraldinsight.com/1753-8378.htm

IJMPB1,1

106

Received 5 August 2007Accepted 20 October 2007

International Journal of ManagingProjects in BusinessVol. 1 No. 1, 2008pp. 106-124q Emerald Group Publishing Limited1753-8378DOI 10.1108/17538370810846441

to short-term solutions being applied to the problems that occur during theimplementation of ERP systems with substantial side effects when systems go live(Saint-Leger and Savall, 2001). Previous research has indicated that the scope andcomplexity of ERP implementations are different from traditional analysis and designprojects (Davenport, 2000) suggesting specific project management strategies shouldbe developed to tackle the specific challenges of such projects. In particular, it is arguedthat ERP projects are often associated with the widespread “re-engineering” ofbusiness practices, whereas traditional projects have smaller organisational“footprints” and are designed to match current practices. In this paper, we leverageour investigations of a very successful ERP implementation in a multinationalpharmaceutical company (Pharma Inc.) to gain an insight into the project managementstrategy adopted to manage what was a successful ERP implementation. To facilitatethe presentation of our findings from this case investigation we use the nine areas ofthe project management body of knowledge (PMBOK) framework.

The remainder of this paper is organised as follows. The next section presentsthe PMBOK framework, which has been put forward as a best practice vehicle tounderstand project management in information systems (IS) projects (ProjectManagement Institute – PMI, 2000). In the second section, we present the casestudy protocol we followed and the methods we applied to the case study of PharmaInc. In the third section, we review the findings of the case under the nine headings ofthe PMBOK framework and, finally we propose conclusions towards excellent projectmanagement practices for ERP projects.

2. The PMBOK frameworkProject management helps project managers to standardise routine tasks and ensurethat available resources are used both efficiently and effectively. The application of itsprinciples allows senior managers to establish and use appropriate measures ofsuccess, to quantify value commensurate with cost and to optimise the use oforganisational resources. Project management as a discipline is only a recent conceptand yet, over the past 50 years a considerable body of knowledge has been built uparound its tools, skills and techniques. The PMI is acknowledged as the pioneeringgroup worldwide for bringing professionalism to the area of project management. ThePMI boasts a worldwide membership of several hundreds of thousands. The PMIprovides a variety of services for project managers, including: education andcertification, and standards in the form of the PMBOK.

The PMI produced the first version of the PMBOK in 1987 and the PMBOK hasbeen continually enhanced since then, with the third edition produced in 2000. ThePMBOK 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 advanceit (PMI, 2000). The PMBOK is organised into nine knowledge areas that are considereda subset of project management and describes the knowledge and practices in terms ofthe 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 approvedbudget;

Projectmanagement

107

. will make the most effective use of people involved;

. will have timely information provided;

. will avoid unnecessary risks; and

. will have the required external resources available.

The processes within each knowledge area interact with each other and with theprocesses in other knowledge areas. Each process has an input for the process toolsand techniques to carry out the process, and an output from the process. While eachprocess presented within the knowledge areas appear as discrete elements withwell-defined interfaces, some interaction and overlap is expected in practice. The nineareas are illustrated in Table I.

2.1 The application of the PMBOK framework to ERP projectsOne of the recommendations of the PMI is that although the PMBOK is generallyaccepted and there is widespread consensus regarding the value and usefulness of thenine knowledge areas, it does not mean that the knowledge and practices describedshould be applied uniformly on all projects. Ultimately, “the project management teamis 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 PMBOKframework is immediately applicable to ERP projects. It is useful to consider to whatextent ERP implementations are like or unlike other IS projects. Prima facia, most ofthe salient points (either good or bad) that have been reported about ERP projects inthe 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 thereis 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 areproperly coordinated

Project scope management Includes all of the work required, and only the workrequired, to complete the project successfully

Project time management Ensures timely completion of the projectProject cost management Ensures that the project is completed within the

approved budgetProject quality management Ensures that the project will satisfy the needs for

which it was undertakenProject human resource management Makes the most effective use of people involved with

the projectProject communications management Ensures timely and appropriate generation,

collection, dissemination, storage, and ultimatedisposition of project information

Project risk management Is concerned with identifying, analysing, andresponding to project risk

Project procurement management Involves acquiring goods and services from outsidethe performing organisation

Source: PMI (2000)Table I.Nine areas of the PMBOK

IJMPB1,1

108

Nevertheless, reported cases of ERP failure seem to indicate that certain, particularlysensitive areas of traditional project management require greater emphasis thanothers. For example, the specification of requirements for ERP projects is oftennon-existent or applied retrospectively because organisations are hoping to acquireready-made solutions that embody best practice that is directly applicable to them. Inthese cases, the project begins with discussions with consultants already propoundinga particular software solution and technical architecture where other important aspectsare overlooked, for example, how the project should be managed. Based on calls fromprevious researchers to derive better suited project management practices and betterapproaches to ERP in general (Sauer, 2002; Swanson and Ramiller, 2004) and onavailable evidence of the problems that have led to significant failure rates in the pastfor such projects, there is a need to analyse the nine areas of the PMBOK and discusstheir relevance in the context of a successful ERP project implementation process inorder 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 needsand expectations from a project (PMI, 2000). However, there are competing demandsamong scope, time, cost, and quality; differences in stakeholders needs andexpectations; and identified requirements (needs) and unidentified requirements(expectations). As a result, it is critical to the success of a project and the ability toaddress these competing demands that the organisation’s structure and approach tothe management of projects is a match to the objectives of the ERP implementation.While an understanding of “vanilla” project management is beneficial, it is notsufficient, due to the fact that projects and project management operate in anenvironment broader than that of the project itself and the project management teammust understand this broader context. For example, managing the day-to-dayactivities of the project is necessary for success, but not sufficient (PMI, 2000). In thispaper, we examine a case study of an ERP roll out in an American multinationalinvolved in the pharmaceutical sector. We also investigate the perceptions of a projectteam responsible for the implementation of an ERP package as the project progressthrough the stages of the project lifecycle. Using the nine areas of the PMBOK toorganise the case data we present an insight into what happened and into the evolutionof the project team members’ perceptions of the project management challenges.

3. MethodologyIn this paper, we present a case study of Pharma Inc., where a successful ERPimplementation took place over a period of time between early-2003 and end-2004. Wefollowed the case study over this period, and as a benchmark project it hasconsiderable 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 thismeans that the system went live as expected, on time and within budget, and that theproject team were able to achieve a rapid ramp-up to full production volumes ahead oftime (seven weeks instead of the predicted nine weeks after go-live). This makesPharma Inc. an example of an extreme case in Patton’s (1990) classification ofpurposeful sampling strategies and this justifies the choice of this case as a basis fordetermination of best practice in ERP implementations.

Projectmanagement

109

3.1 The case studyThe case involves a manufacturing subsidiary of a multinational pharmaceutical firmimplementing a single instance of specific technical skills (SAP) across a large numberof sites worldwide (refer to Table II for key information about the case). Thissubsidiary is what is termed a “primary site” meaning that it produces batches ofactive ingredients to be used in other “secondary” sites where the tabletting andpackaging of the drugs is performed.

One feature of this case study is that previous waves of the ERP implementationhad only been carried out at secondary sites. The manufacturing subsidiary studiedhere was the first primary site to go live on the new SAP system, and this raisedadditional challenges that were not anticipated. Project members from theimplementation team studied here were solicited by the core team post go-live toassist with the SAP roll-out in further primary sites, based on the skills and know-howgained in adapting the global template to their local (primary site) requirements.

3.2 Data collection and analysisIn Pharma Inc., we carried out 26 interviews and distributed a total of 63questionnaires over four rounds. The fieldwork was focused on the localimplementation team and the evolution of their perceptions of the projectmanagement challenges as the project progressed from initiation to go-live andbeyond. Table III summarises the data collection carried out.

An original facet of the research method employed was that intervieweesthemselves were asked to define the key strengths of the company, and then insubsequent interviews, as the project progressed through the preparation andimplementation phases, they were asked to comment on how ERP impacted thesestrengths. This internal view of key strengths and their subsequent evolution is amethod of self-reporting that removed any notion of “putting words into people’smouths” as the project progressed. Researchers have been trying for some time to

Key features Pharma Inc. case study

Type of organisation Multi nationalIndustry PharmaceuticalSize (emp.) 100,000Turnover $25 billion (2004)Scope of project Manufacturing, planning, procurement, sales and distribution, finance,

engineering, quality for local manufacturing siteType of project Worldwide roll-out of SAP in four wavesDuration Five years for entire roll out, 18 months for local manufacturing siteProject leadership Local steering committee, local project team and global core

implementation teamProject managers Local managers from affected functions seconded to projectTeam members availability 100 per cent for 18 monthsProject resources 40-70 people locally þ 45 in core teama

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

Table II.Key characteristics of thecase study organisation

IJMPB1,1

110

understand the low-success rate of ERP projects by analysing retrospectively theimplementation experience of practitioners in terms of either CSF’s or business benefitsaccrued (Markus et al., 2000; Parr and Shanks, 2000; Somers and Nelson, 2001; Murphyand 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 decidedthat letting the interviewees define the criteria to be measured at the outset, based ontheir own expectations of the forthcoming organisational change, ensured relevanceand a sense of ownership of the field data.

We began this research as invited facilitators of a team building and ERPawareness seminar pre-project implementation in April 2003. This allowed us directaccess to the team members at a very early stage in the process, and the feedback fromthe first round of interviews and questionnaires demonstrated a certain perception ofthe 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 localimplementation 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 theystruggled with the concept, timescale and reality of spearheading the organisationalchanges that are part of an ERP roll-out. We feel that this “insider knowledge” allowedus to make judgments on what elements of the project management had contributedmost to its success, and in so doing, to enrich the PMBOK framework with criteriaspecifically 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 casestudy organised using the nine areas of the PMBOK framework.

4.1 Project integration management/project quality managementAn ERP system involves a serious transformation process that requiresfundamental change in the way business processes are designed and conducted.Various methodologies have been put forward to ensure the package is implemented ina manner that ensures the quality of the final system, i.e. that the system is

Number

Interviews by functionFinance 2Manufacturing/distribution 14Sales 2Information systems 3Engineering 2HR 3Total 26Questionnaires completedApril 2003 22May 2003 11December 2003 16September 2004 14Total 63

Table III.Summary of data

collection

Projectmanagement

111

implemented in an efficient way and the objectives are met (Minahan, 1998; Stefanou,2000). Most of these methodologies insist on preparing properly and thoroughly fromthe chartering phase itself prior to acquiring or implementing any technologies. Theproblem inherent in such ideas is that this is precisely the stage in a project wheremanagers’ awareness levels are at their lowest and when they are least able to makekey choices, hence the recourse to external parties which, unfortunately are rarelyindependent and un-biased.

In Pharma Inc., the overall level of preparation was quite good at the local site, giventhat this was the fourth wave of a global project that had already seen fivemanufacturing sites go-live with the ERP global template. It was understood from theoutset that the number one objective of the project was process compliance, whichwould have an immediate impact on the plant’s ability to withstand an audit from theindustry regulatory body, the Food and Drug Administration. In this context, ERP wasultimately seen as a necessary cost avoidance investment. This was confirmed in asurvey question aimed at soliciting team members’ understanding of the expectedbenefits to be delivered by the new ERP system. Table IV highlights the results of thissurvey question from April 2003.

There was a general acceptance that the benefits to be derived from the ERP roll-outwere for the “greater good” of the corporation, rather than any particular advantage tobe derived from the local site. The aggregated results of the answers to the question “IsERP an enabler or a driver of change?” in April 2003, when the project team was stillbeing consolidated, and there may still have been some hope among team membersthat some benefits would accrue to the site, despite the acknowledged complianceagenda show our respondents split 45 per cent (enabler)/55 per cent (driver). Bycontrast, in December 2003, just before the project went live, only 9 per cent ofrespondents 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 wasimposing change, softened somewhat after go-live, with the 91 per cent dropping to71 per cent six months later, after go-live. It might be argued, that at this point, anyremaining “naivety” about the rationale behind the ERP implementation hadevaporated, but that team members could sense the potential for engineering“improvements” to the newly implemented compliant processes. Key here would be theconfidence of the team as it had gone through a very aggressive project, gone live ontime and come out intact.

Expected benefits Number of respondents

Greater compliance/validated system 9Integrated well documented ways of working 7Standardisation to global processes 3Integration of all key sites’ systems 3Better control of tasks 2Increased accuracy of inventory 2Integration with the global supply network 1One set of data 1Better planning and scheduling functions 1Do not know 7

Table IV.What are the expectedbenefits from the ERPimplementation?

IJMPB1,1

112

It is interesting to note that, at the early stage, team members were quite uncertainabout the task facing them and that they feared that SAP would jeopardise much of thework 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 indicatormeasuring the per cent shipments made to customers within the commit date. Localmanagement were worried that this global roll-out would impact their customersatisfaction rating, their efforts in distinguishing themselves being therefore nullified.However, this impression was slowly reversed over the course of the project. Wheninitially asked in April 2003 to list the core competences or areas of excellence thatmade them stand out from other subsidiaries, respondents identified the followingstrengths: customer responsiveness, innovation, new product introduction (NPI), “CANDO” attitude, R&D (research and development), implementation of newprocesses/technologies, manufacturing knowledge and ability, project delivery trackrecord/proven performance, and highly efficient and flexible operation/quality.Approximately nine months later, just prior to go-live, they were asked to rate theimpact of the new ERP systems on these core competences. The results of this questionare displayed in Table V.

This picture changed dramatically in the months following go-live, with apolarisation of opinion around key strengths such as customer responsiveness and“CAN DO” attitude. Table VI shows the post go-live situation in September 2004 forthe same question. The relevance these findings have for our study is that the rationalefor ERP project implementations is not a static business case, showing a monetary ROIafter x number of years. It is much more closely linked to company’s values, and theperception of impact on those values, among core team members (who are arguablybest placed to judge the impact), evolves in a negative sense over the lifetime of theproject.

As already argued by Davenport (1998), top management need to answer someserious questions at the outset to ensure that they understand what an ERP systemactually implies. Wood and Caldas (2001) discovered that many organisations failed toimplement their ERP systems because they viewed them as just another IT project orsome type of IT-meets-reengineering-project. Once top management have committedthemselves to the project it is vital that they are able to document the reasons forchoosing to implement that system and that they publish the reasons widely across theorganisation (Minahan, 1998). Clear and unambiguous statements by top managementregarding why the ERP system is being pursued are vital in ensuring the success of theproject.

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 localoperations when imposing a global corporate standard on critical business processessuch as cash collection, procurement, and material planning. By the time all sites hadbeen implemented, the first sites had been left behind and had to upgrade to the newerversion of the package. Staff seemed resigned to the fact that an ERP implementation isnever truly over and that one cannot get too comfortable with any business practice. Inthe case of Pharma Inc., an operational excellence group, which had been founded wellin advance of ERP to examine process improvements and improve performance

Projectmanagement

113

Lev

elof

imp

act

Hig

hM

ediu

mL

owC

ore

com

pet

ency

/are

aof

exce

llen

ceP

NP

NP

N

Cu

stom

erre

spon

siv

enes

s3

43

Med

ium

toh

igh

pos

itiv

e/m

ediu

mn

egat

ive

Inn

ovat

ion

,N

PI

32

33

Med

ium

tolo

wp

osit

ive/

low

neg

ativ

e“C

AN

DO

”at

titu

de

12

11

32

Low

pos

itiv

e/h

igh

tolo

wn

egat

ive

R&

D1

12

14

2L

owto

med

ium

pos

itiv

e/lo

wn

egat

ive

Imp

lem

enta

tion

ofn

ewp

roce

sses

/tec

hn

olog

ies

41

23

Med

ium

pos

itiv

e/lo

wn

egat

ive

Man

ufa

ctu

rin

gk

now

led

ge

and

abil

ity

24

41

Low

tom

ediu

mp

osit

ive

Pro

ject

del

iver

ytr

ack

reco

rd/p

rov

enp

erfo

rman

ce1

42

32

Med

ium

tolo

wp

osit

ive

Hig

hly

effi

cien

tan

dfl

exib

leop

erat

ion

/qu

alit

y1

52

12

Med

ium

pos

itiv

e/m

ediu

mto

low

neg

ativ

e

Notes:

Th

e“l

evel

ofim

pac

t”is

cate

gor

ised

asp

osit

ive

(P)

orn

egat

ive

(N)

acro

ssh

igh

/med

ium

/low

.Th

en

um

ber

sin

the

cell

sre

late

sto

the

tota

ln

um

ber

ofre

spon

den

tsse

lect

ing

that

lev

elof

imp

act

for

asp

ecifi

c“c

ore

com

pet

ency

/are

aof

exce

llen

ce”.

For

exam

ple

,th

ree

resp

ond

ents

per

ceiv

edth

eE

RP

syst

emto

hav

ea

hig

hp

osit

ive

imp

act

oncu

stom

erre

spon

siv

enes

sw

hil

efo

ur

resp

ond

ents

sug

ges

ted

am

ediu

mp

osit

ive

imp

act

oncu

stom

erre

spon

siv

enes

s

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

IJMPB1,1

114

Lev

elof

imp

act

Hig

hM

ediu

mL

owC

ore

com

pet

ency

/are

aof

exce

llen

ceP

NP

NP

N

Cu

stom

erre

spon

siv

enes

s2

15

31

1M

ediu

mp

osit

ive/

med

ium

neg

ativ

eIn

nov

atio

n,

NP

I3

11

22

4L

owto

med

ium

neg

ativ

e“C

AN

DO

”at

titu

de

11

53

11

Med

ium

pos

itiv

e/m

ediu

mn

egat

ive

R&

D2

12

61

Low

tom

ediu

mp

osit

ive

Imp

lem

enta

tion

ofn

ewp

roce

sses

/tec

hn

olog

ies

31

33

3L

own

egat

ive/

hig

hto

low

pos

itiv

eM

anu

fact

uri

ng

kn

owle

dg

ean

dab

ilit

y3

71

1M

ediu

mp

osit

ive

Pro

ject

del

iver

ytr

ack

reco

rd/p

rov

enp

erfo

rman

ce3

52

3H

igh

tom

ediu

mp

osit

ive/

low

neg

ativ

eH

igh

lyef

fici

ent

and

flex

ible

oper

atio

n2

36

1M

ediu

mn

egat

ive/

med

ium

pos

itiv

eQ

ual

ity

10

13

Hig

hp

osit

ive

Insp

ecti

onre

adin

ess

10

3H

igh

pos

itiv

e

Notes:

Th

e“l

evel

ofim

pac

t”is

cate

gor

ised

asp

osit

ive

(P)o

rn

egat

ive

(N)a

cros

sh

igh

/med

ium

/low

.Th

en

um

ber

sin

the

cell

sre

late

sto

the

tota

lnu

mb

erof

resp

ond

ents

sele

ctin

gth

atle

vel

ofim

pac

tfo

ra

spec

ific

“cor

eco

mp

eten

cy/a

rea

ofex

cell

ence

”.F

orex

amp

le,t

wo

resp

ond

ents

per

ceiv

edth

eE

RP

syst

emto

hav

ea

hig

hp

osit

ive

imp

act

oncu

stom

erre

spon

siv

enes

sw

hil

efi

ve

resp

ond

ents

sug

ges

ted

am

ediu

mp

osit

ive

imp

act

oncu

stom

erre

spon

siv

enes

s

Table VI.Level of impact of ERP

on core competences(September 2004)

Projectmanagement

115

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 golive to evaluate whether they had been achieved. A media rich presentation collatingthe results of the AAR was published internally on CD and on the web. Indeed, thissame group plays a role of ongoing process improvement and its “mentors” areuniquely placed to advise different parts of the business on how to get the best from theERP 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 aparticular process inefficiency. It is the researchers’ conviction that it is this “trial anderror” approach to exploiting the vast richness of transactional data stored in the ERPsystem, that will yield benefits in the years following implementation, rather thanbemoaning the lack of vanilla reports from the system and the construction of paralleldata warehouses to address specific functional reporting needs, so prevalent amongother less successful implementations. Indeed, this approach is evidence of the survivalof the “CAN DO” attitude, despite the perceived constraints of ERP!

4.2 Project communications managementIt 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 waseasier to learn and share experiences with people from outside their organisation thanwithin intra-organisational teams. This is where the primary benefit of usingconsultants to aid implementation is apparent as they add value to the project byfacilitating meetings and the open discussions of requirements, prioritising issues andavoiding conflicts. Thus, consultancy agencies are important in ERP projects despitethe 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 teammembers had direct experience of an ERP system implementation. This meant thatmuch work was done in the project preparation phase from mid-2003 to educate teammembers on the background to ERP projects, the key challenges they would face as aproject management team and the communication channels that would be used tomake decisions. Following this rapid learning curve, with just nine months on theproject and with go-live imminent, team members were extremely aware of the extentof the changes that were about to take place and for which they would have to takeresponsibility. Table VII illustrates their response to the question “What level ofchange 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 anew ERP system would require particular attention and careful monitoring. In the casestudied, an additional team member was hired from a local PR company in order toconcentrate on communication between the project team and the other employees at theplant. As part of his effort he set up countless meetings, particularly withrepresentatives of the unions, where extremely sensitive negotiations with respect tochanges to job specifications were navigated to success with requisite care andattention. Furthermore, the project PR consultant and his team published four issues of aspecial internal magazine, solely dedicated to communicating project news, progressreports on achieving targets and on respecting key milestones. This served as a channel

IJMPB1,1

116

to get across to employees outside the project, in an entertaining way, what the purposeof the project was and why their participation was vital. In addition, it introduced theproject 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 thecommunication with the core team was very uneven, seemingly more dependent onindividuals’ willingness to communicate than on any pre-defined scheme. In fact, therewere even some “incidents” between members of the local team and members ofthe core team when local staff were able to demonstrate that the understanding thatcore team members had of the local processes was not sufficient. In any case, thenomination of a well respected and experienced logistics director to the role ofimplementation site leader ensured that the project team was given recognised statusand authority in the eyes of local employees, and a direct line of communication wasopened between the project team and the general manager of the plant. Crucially, thepolitical strength of the project leadership gave vital support and encouragement tothe project team in its relations with the implementation core team. At a critical point inthe implementation analysis phase, the site leader threatened to pull his entire team outof the project unless the core team accorded sufficient respect to his stream leads. Theaffirmation of such “clout” at a vital early point in the collaboration between streamleads and core team, laid the cornerstone for what was to become a much betterworking relationship, as acknowledged by both sides, and contributed certainly to thesuccess of the project.

4.3 Project scope managementAgain, this aspect of ERP projects pertains to how well organisations are preparedwhen they embark on their implementations. Davenport (1998) states that the singlebiggest reason that ERP projects fail is because companies are unable to reconcile thetechnological necessities of the system with their own business needs. A lack ofunderstanding of the scope of the system may result in a conflict between the logic of

Process level of changeHigh Medium Low

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

Notes: The “process level of change” is categorised as high/medium/low. The numbers in the cellsrelates to the total number of respondents selecting the “process level of change” for a specific businessarea. 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 ofchange”

Table VII.What level of change do

you expect in yourbusiness area?

Projectmanagement

117

the system and the logic of the business. In complex organisations such as MNCs, thisrequires a preliminary determination of what configuration will be rolled out in thedifferent sites – the template. At Pharma Inc. the global template had been designedaround corporate best practice. So the parameters and options that were available tothe implementing site were not a question of SAP options, but rather a question ofchoices available under the corporate best practice template – the global standardoperating procedures or GSOP’s. It became clear that in order to negotiate changes tothis template, with a view to accommodating local requirements, new types of skillswould 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 depthknowledge of the GSOP, and a SAP expert recruited by the local implementationsite to advise on what was, and was not, possible with SAP. On several occasions, theGSOP was lacking in basic functionality that the site required, and yet the coreimplementation team was unable to suggest the solution because their experience waslimited to the global best practice template. For example, core team members wereunable to understand the limitations of a bulk chemical dispensing parameter that didnot have the required number of decimal places to record the actual readings from thescales in use in the plant (the template having been designed for tablets, not bulkchemical). The response of the core team, unacceptable to the local implementationteam, was to use the parameter as it was defined and lose the data granularity! Theclash between the two cultures inherent in Pharma Inc., the primary sites and theirnon-discrete processes and the secondary or tabletting plants and their discreteprocesses, was the source of such problems. Thus, the scope of the implementationneeded to be re-examined to fit with the operations of the local plant, and thisnecessitated the availability of advanced SAP knowledge to be able to suggestworkarounds.

In this case study the scope was very broad (warehouse, engineering, finance,procurement, production planning, production execution, quality, sales anddistribution and NPI/R&D). All of these modules were integrated in the new globalprocess model, so it was not an option to implement a subset. During the project, twoelements 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 andconverting legacy data into a format suitable for the new system; and

(2) the changes that would be required to the physical organisation of thewarehouse function when the system was used to dispense material (primarysites are characterised by non-discrete activities, the core of which is “weightingand dispensing” which is critical for an ERP application).

Data cleansing became a huge issue for the project team, and a dedicated datamaintenance team of 17 full time equivalent’s ensured that data going into the newsystem was clean, valid and in the right format.

4.4 Project time management/project cost managementDepending on the size of the organisation and the scope of the project, implementing anERP 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, projecttime management is critical during the chartering, project and shakedown phases.

IJMPB1,1

118

At Pharma Inc., the four waves of the implementation programme ran over a period ofover five years. In fact the timescale of the global roll-out was so long that by the timethe last site was up and running, the implementation team had to re-start the wholecycle 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 thepackage, so the length of time could be substantially reduced by keeping the system“plain vanilla” and reducing the number of packages that require customisation inorder to be bolted on to it (Bingi et al., 1999), which has led software vendors andconsultants to recommend a zero modification approach that has nowadays become ade facto standard.

This aspect of the implementation represented a “lose-lose” situation for theimplementing site in our case study: on the one hand, to facilitate tight timelines, thenumber of specific requirements that could be taken into account was non-existent. Onthe other hand, the time it would have taken to analyse the new proposed businessprocess to understand their impact on the local organisation was not sufficient, sostream leads found themselves in the unenviable position of having to accept processchanges without really having time to validate them properly against local operations.Thus, the focus on deadlines (that were defined externally to the project team) meantthat team leaders had to focus acutely on being on time at all stages. This sometimesresulted in critical tasks being left behind for the sake of being on time. It seems that aproper balance must be found between being on time for the sake of it and keeping allareas of the project as tight as possible.

Another aspect of the timing of large multi-site global roll-outs is the learning thatcan occur from each site and the core team’s ability to take on board this knowledge ina way that would make it meaningful for subsequent implementations. However, thelearning process whereby sites within the same organisation can improve the templatebased on their own implementation experience, such that subsequent sites mightbenefit, is very difficult to put in place without losing control over the overall durationof the project. This leads MNCs to sometimes sacrifice this aspect in the name ofstandardisation and expediency (Bingi et al., 1999). This might explain why the localimplementation team did not regard project management as important initially. At thebeginning, 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 projectapproached 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 carrythe can for meeting deadlines. Figure 1 shows how the perception of skills changedover time (in December 2003 and nine months after go-live in September 2004).The increased importance of “Project Management” “SAP Knowledge” and thecontinued importance of the “Process Knowledge” skill sets is evident. On the otherhand, “Existing Systems Knowledge” and “Data Knowledge” is perceived to be lessimportant.

Like most software, ERPs are priced on the functionality of the system and thenumber of users who will access it. Organisations are also required to invest in

Projectmanagement

119

migrating data, modifying existing systems and overhauling hardware and networkinfrastructure. With the global roll-out of a corporate template the cost equation is alittle more complex with the local per user license fee probably being managedthrough a global contract with the corporation. The costs of the core team are, inaddition sunk in the corporate project budget. On the other hand, the local sitemanager 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 ofadditional resources for data cleansing and the hiring of SAP. In addition, theinfrastructural costs to set the team up were considerable. This does not includetraining, travel and administrative costs.

In the case study, the project budget was externally decided, which did not preventsome of the local teams to come in under their allocations. The organisation minimisedtraining costs by training “super-users” some of which came from the datamaintenance team, who were then used to train the rest of the local site workforce. Anextensive training programme was put in place to ensure that all staff were providedwith training, no matter what shift pattern they worked. It was perceived as vital forthe success of the project that training was undertaken by internal resources. Extracare went into planning for this, with mobile modular space being rented and set up ina corner of the car park to create a temporary dedicated “training centre”.

4.5 Project human resource managementAn ERP implementation is a major undertaking, which requires management toassemble the best possible team to plan, execute and control the project. This impliesreassigning the few people who are most likely to be missed from their duties to theERP project team on a full time basis (Maher, 1999). It is not rare to find functionalareas reluctant to sacrifice their best resources to the project. However, this is a

Figure 1.What skills are mostimportant in this ERPproject? (December 2003vs September 2004)

September 2004

December 2003

17%6% 0%

32%

32%

17%

14%19%

24%

28%

Process Knowledge

Existing SystemsKnowledge

Data Knowledge

Knowledge of SAP

Project Management

Other11% 0%

IJMPB1,1

120

difficulty which must be overcome (Bingi et al., 1999). The fact that teams must becross-functional is an added difficulty especially in organisations with no culture ofworking across functional areas and no experience of such large projects.

Frequently, companies do not fully comprehend the impact of choosing the internalemployees with the correct skill set. The right employees for the team should not only beexperts in the company’s processes but also be knowledgeable of the best businesspractices in the industry. At Pharma Inc., following the nomination of a high profile sitemanager, selecting and obtaining competent stream leads was the next key element ofwhat was to be a winning combination. From the outset, the scale of the undertaking wasappreciated and the calibre of the team members was commensurate with the seriousnessof the task ahead. All team members were reasonably senior with on average 10-15 yearsexperience in the business. All team members were full time on the project whether for theentire duration of the project or for shorter periods. At key times in the project, staff wereadded to the team for specialised tasks such as data conversion, training or desktopdeployment, 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 leadswere “old hands” in the business, not only were they acquainted with one another, butthey also had an intuitive grasp of the complexities in areas of the business other thantheir own particular domain. With systems as integrated as ERP, project teammembers have to always bear in mind the upstream and downstream effects of choicesand configuration options they make as the project progresses. One of the key successfactors of the project was the team’s ability to work together, and to draw on theindividual experience and authority across different functions in making key designdecisions. The inclusion of an “integration specialist” charged with anticipated theimpact in other areas of decisions made in each area was another key aspect. Anotherunique element of the constitution of the local project team was the pre-meditatedpairing of, as one team member out it, “experience and energy” in each of the processstreams. Stream leads were allocated graduate level resources to work on datacleansing in each functional area, and this combination obviated the need to hire inexpensive consultants, and created a pool of enthusiastic resources highly suitable tothe 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 forthe success of the project. It was no coincidence that the team in our case studyfunctioned 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, suchthat, even if the timeline was punishing, team members felt they were recognised fortheir efforts and could let off steam whenever the stress became too much. Teammembers were accorded “duvet days” if it was felt that the unforgiving schedule wasbeginning to impact negatively on performance. It would be the researchers’ view thatthis factor is more in line with a personal style of management than an ERP successfactor. 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 managementImplementing an ERP system requires a radical change in the business processes oforganisations, radical change means risks and risks mean more time and money.

Projectmanagement

121

ERP systems are complex and they require reliance on many different types ofexpertise, which may also need to be sourced outside the organisation. Good,experienced consultants are difficult to find, thus employing a consultancy firm is noguarantee that the project will be a success. Organisations, which have trained theiremployees in the art of ERP implementation, stand a great risk of loosing theirinvestment because personnel with such experience are in great demand by consultingagencies. Our case study showed a unique willingness to “go it alone” with respect tointegration partners. There were no consultants employed in the local implementationteam. SAP were hired into the team on contracts to bolster the team without theexorbitant expense of paying consultants day rates. The net effect was that costs wereminimised and control was optimised. Another consequence was that there was no oneelse to blame in case something went wrong. In the opinions of the interviewees, thiswas actually an added benefit that all responsibility for the implementation of thepackage was internal, making the site autonomous and better able to validate thequality of what would ultimately be delivered.

5. ConclusionOur investigation into the project management strategy adopted in the Pharma Inc.case under the nine headings of the PMBOK framework illustrates one vision of whatcould be termed “best practice” in terms of ERP implementation. In particular, it showsthe importance of project governance and the need for a multi-level structure spanningboth the corporate and local levels. Indeed, these governance structures ensured thatthe ERP project maintained focus in terms of direction, reduced the possibility ofdelays 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 theimpact, or avoid the possibility, of risks on the project. It also shows the crucialimportance of the proper selection of team members and the need for a high profileteam leader even at the local level. Being able to call on specific local skills at differentpoints in the project, whether they were application focused or business focused, was astrong factor in the success of the implementation. On a more technical basis, itsuggests that a dual cycle of exploration/negotiation leading to a stable corporatetemplate on the one hand and execution/roll-out on the other hand could greatly boostthe success rate of ERP projects. In relating the areas of ERP project management tospecific stages of the ERP development lifecycle, attention is drawn to specific areasthat need to be emphasised at different times. Project managers need to be persuadedthat any unclear area not resolved in the exploration cycle will need to be tackled in theimplementation stage or else there is a risk that it might get left behind and onlyre-emerge post go-live with disastrous consequences. In relation to the creation of thetemplate 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 problemswhich 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 needto standardise business processes and stay on schedule seems to be very difficult tofind. In a MNC, the corporate level is strong enough to impose its rules but the cost atlocal level in terms of motivation lost and inefficiencies must be understood. Also, the

IJMPB1,1

122

need to preserve learning in each roll-out so it can benefit to all sites, but also in thefollowing 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 largeorganisations. It also suggests a novel approach to using the perceived strengths of theorganisation as a barometer for the impact of such transformational systems, such asERP. Further, case studies are planned to assemble a complete set of best practicerecommendations for future ERP project managers. However, a potential weakness inthe current methodology is that the pharmaceutical sector is highly regulated; thereforebusiness functions are very familiar with the bureaucratic constraints imposed byexternal bodies in terms of quality, safety, traceability and transactional integrity.“90 per cent of the errors in batch manufacturing are around documentation” is how itwas described by one corporate manager. This puts the organisation at an advantagewhen implementing a highly integrated suite of applications where new controlprocesses will perhaps find acceptance more quickly than in a less regulatedmanufacturing environment. In fact, looking at a sample of such implementations in aless 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 BusinessReview, July/August, pp. 121-31.

Davenport, T.H. (2000), Mission Critical – Realizing the Promise of Enterprise Systems, HarvardBusiness School Press, Boston, MA.

Finney, S. and Corbett, M. (2007), “ERP implementation: a compilation and analysis of criticalsuccess 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 enterpriseresource planning implementation”, Proceedings of the 7th European Conference onInformation Systems, Copenhagen Business School, Copenhagen, pp. 273-87.

Lam, W. (2005), “Investigating success factors in enterprise application integration: a case-driveanalysis”, 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’ experienceswith ERP: problems encountered and success achieved”, Journal of InformationTechnology, 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”, InformationSystems Journal, Vol. 12 No. 4, pp. 301-20.

Parr, A. and Shanks, G. (2000), “A model of ERP project implementation”, Journal of InformationTechnology, 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), “L’apres project ERP: Retour d’experience sur unchangement qui n’a pas eu lieu” (“Post-ERP phase: feedback from experience regarding a

Projectmanagement

123

change which did not occur”), Conference de l’Association Information et Management,Nantes.

Sammon, D., Adam, F. and Carton, F. (2004), “Understanding the ERP post-implementationdiscourse”, Proceedings of the 6th International Conference on Enterprise InformationSystems, 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 ofenterprise resource planning implementations”, Proceedings of the 34th HawaiiInternational 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 ERPimplementations”, Business Process Management Journal, Vol. 7 No. 5, pp. 387-93.

Corresponding authorDavid Sammon can be contacted at: dsammon@afis.ucc.ie

To purchase reprints of this article please e-mail: reprints@emeraldinsight.comOr visit our web site for further details: www.emeraldinsight.com/reprints

IJMPB1,1

124