MAIN TITLE OF THE PAPER STYLE "MAIN TITLE"

2

Project Management for ERP Implementations A Case Study of Successful ImplementationFergal Carton Business Information Systems, University College Cork, Cork, Ireland, fcarton@afis.ucc.ie Frdric ADAM, Business Information Systems, University College Cork, Cork, Ireland, fadam@afis.ucc.ieAbstract The success rate of ERP implementations is not high in view of the sums invested by firms in these applications. It has often been indicated that a combination of inadequate preparedness and inappropriate project management have been responsible for the low success rate of ERP implementations. In this paper, we present our investigation into the project management strategy adopted in the Pharma Inc. case. We consider this very successful case under the 12 headings of our revised model for project management and seek to illustrate one vision of what could be termed best practice in terms of ERP implementations.Keywords: ERP, Implementation, Project Management.

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

2Project Management for ERP and project success

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

However, Maylor (2001) has warned that project management lacks a strong theoretical base; it is not based on a series of premises from which consistent theory can be delivered but rather on empirical evidence, which has built up over time to form a body of knowledge. Thus, project management is learned through experience and this has earned it the title of the accidental profession.3The Twelve Areas of Project Management

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

1.Project Integration Management

2.ERP Project Rationale Management *

3.Project Scope Management

4.Global ERP Project Management *

5.Project Time Management

6.Project Cost Management

7.Project Quality Management

8.Project Human Resource Management

9.Project Communications Management

10.Project Risk Management

11.Project Procurement Management

12.ERP Project Review Management *

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

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

Type of firmMultinational

IndustryPharmaceutical

Size (emp.)100,000

Turnover$25 billion (2004)

Scope of projectManufacturing, Planning, Procurement, Sales & Distribution, Finance, Engineering, Quality

Type of projectWorldwide roll out in 4 waves

Duration5 years

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

Project managersLocal managers from affected functions seconded to project

Team members availability 100% for 12 months

Project resources70 people locally + 45 in core team*

Table 1 Key characteristics of the case study firm

*the core team is the travelling team which moved from location to location to facilitate the local roll outs during the successive waves of the project.

In Pharma Inc., we carried out over 55 interviews in 4 different sites: our local site, where we exchanged our work as facilitators for the team building and awareness seminar stages against acess to people and documents for the duration of the project, Pharma Inc. Headquarters, where we spoke to the global leaders for the project and two other local sites in a different country (one was a primary site and one was a secondary site) where we met with the local project managers. This gave us a comprehensive, if not complete, vision of this large and long project and allowed us to make definitive judgments on what had gone to plan and what deserved further improvements. Such an extensive amount of data collected allowed to approach Eisenhardts (1989) notion of saturation, where it felt that no more understanding can be gained by pursuing the field work and this gave us confidence that we were able to give an accurate and realistic account of what happened at Pharma Inc. All our write-ups have been reviewed by our informants and they have agreed with their accuracy.5The Pharma Inc. case study

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

Under this heading, we think that the general preparedness of an organisation must be considered. Too many firms embark in ERP projects with a general lack of awareness of what is involved in their ranks. Top managers in particular, may not realise the level of efforts required from staff in areas that are going to be affected by the new systems and sometimes expect these staff members to carry on with their normal duties on top of their role in the ERP project. Setting up a full time team, backfilling the positions left vacant by team members, allocating a discretionary budget to the team, sending some team members on special training workshops so they understand what is expected of them must all be taken into consideration at the outset.

Our experience of ERP projects is that preparedness is crucial and often lacking. In Pharma Inc., the overall level of preparation was quite good in our local site, given that this was the 4th wave of a global project that had already seen 5 manufacturing sites go live with the ERP global template. On the other hand, of an initial core team of 24 business representatives, only 2 team members had direct experience of an ERP system implementation. This meant that much work was done in the project preparation phase from mid 2003 to educate team members on the background to ERP projects, the key challenges they would face as a project management team and the communication channels that would be used to make decisions. It is interesting to note that, at that stage, team members were quite uncertain about the task facing them and that they feared that SAP would jeopardise much of the work accomplished in previous years in streamlining and optimising key processes. They perceived themselves as quite far ahead of other sites in Pharma Inc. and worried that this global roll out would bring them back in line with all other primary sites, their efforts in distinguishing themselves being therefore nullified (Subsidiaries of large pharmaceutical firms see themselves as competing with the other sites in their corporation much more so than again other firms). As we see further in this paper, this impression was slowly reversed over the course of the project.5.2. ERP Project Scope Management

Again, this aspect of ERP projects pertains to how well companies are prepared when they embark in their implementations. Wood and Caldas (2000) found that of the 91% of the respondents who said they would implement again if faced with the situation again, 25% would significantly change the scope or the implementation methods of the project.

In our case study the scope was very broad (Warehouse, Engineering, Finance, Procurement, Production Planning, Production Execution, Quality, Sales & Distribution and NPI / R&D). All of these modules are integrated in the new global process model, so it was not an option to implement a subset. In the original scope, it was thought that the processes used by the R&D function, though mimicking the production processes, would not match with the global template. It was then even considered to create a separate instance of the application just for R&D, a solution which the core team would have opposed as strongly as they could anyway. Only through the perseverance of the project team was it decided to bring R&D in under the scope of the project. In hindsight this was a critical decision for the project, as the effort to develop interfaces to R&D and subsequently integrate at some later date the whole R&D activity would have far outweighed the marginal increase in effort to include them in the scope of the implementation for production.

Our case study revealed 2 elements of the scope of the project that were not anticipated in advance: (1) the amount of work that would be required in collecting, cleaning up and converting legacy data into a format suitable for the new sys-tem, and (2) the changes that would be requires to the physical organisation of the warehouse function that would be required when the system was used to dispense material (Primary sites are characterised by non-discrete activities, the core of which is weighting and dispensing, which is critical for an ERP application).

Data cleansing became a huge issue for the project team, and a dedicated data maintenance team of 17 Full Time Equivalents (FTEs) was recruited to ensure that data going into the new system was clean, valid and in the right format.

It was found following implementation that the workload involved in dispensing material under the new processes was significantly more onerous than with the legacy system. This involved the warehouse function eventually creating a separate dispensary area for dispensing material to production jobs and requiring hiring more staff, which ran contrary to the general thrust of the ERP implementation to boost efficiency.

Another un-intended change to the organisation occurred after go-live: rather than have all technicians spend time updating the system during production runs, it was decided that it would be more efficient to have specific technicians with responsibility for system integrity. From that point onwards, each shift included a member of this group of system savvy technicians. This organisational change had non-trivial impacts in terms of job responsibility, shift pattern planning, and end-user training which required for instance long hours of negotiations with unions in terms of wages and job titles.

Davenport (1998) states that the single biggest reason that ERP projects fail is because companies are unable to reconcile the technological necessities of the system with their own business needs. An ERP system imposes its own logic on a companys strategy, organisation and culture and if a definite scope statement is not articulated early in the project, the ERP system will drive the company towards full integration even though a certain degree of business unit segregation may be the optimal solution. A lack of understanding of the scope of the system may result in a conflict between the logic of the system and the logic of the business (Davenport 1998).

Bingi et al. (1999) commented that the scope of an ERP project affects not only the number of modules being implemented but also the number of functional units affected, the number of sites in which the system is to be implemented, the extent of customisation and the number of interfaces with legacy applications. Thus, in complex organisations such as multi-nationals, this scope management stage is crucial and requires a preliminary determination of what configuration will be rolled out in the different sites. This vision of the software is sometimes referred to as the template.

In our case study, the company was implementing a global template that itself had been designed around corporate best practice. So the parameters and options that were available to the implementing site were not simply a question of SAP options, but rather a question of choices available under the corporate best practice template (called Global Standard Operating Procedures or GSOPs). It became clear that in order to negotiate changes to this template to accommodate changes that allowed for the local sites requirements, new types of skill would be required. The discussion became a 3-way negotiation between the local stream lead or subject matter expert, the core team member who had an in depth knowledge of the GSOP, and a SAP expert recruited by the local implementation site to advise on what was and wasnt possible with SAP. It was found on several occasions that the GSOP was lacking in basic functionality that the site required, and yet the core implementation team was unable to suggest the solution because their experience was limited to the global best practice template. An example would be the ability to have SAP deal with tonnes of raw material to a suit-able degree of precision, when the global template had been designed with tablet manufacture, not bulk active ingredient. This was the first example of the clash between the two cultures inherent in Pharma Inc., the primary sites and their non-discrete processes and the secondary or tabletting plants and their discrete processes.

Thus, the scope of the implementation needed to be re-examined to fit with the operations of the local plant, and this necessitated the availability of advanced SAP knowledge to be able to suggest work-arounds.

5.3. ERP Project Time Management

Depending on the size of the organisation and the scope of the project, implementing an ERP system may take years be-cause of the need to be rolled out across multiple sites, lines of business and countries. McKie (1999) stated, nobody is capable of implementing financial, distribution and manufacturing software across a range of statutory, operational, lin-guistic and cultural parameters in a short time frame (Pg. 2).

Minahan (1998) claims that a typical ERP implementation takes between two and three years while larger ones, especially worldwide roll outs, can stretch to five years.

This is certainly true in the case study, where the 4 waves of the implementation programme ran over a period of over 5 years. In fact the timescale of the global roll-out was so long that by the time the last site was up and running, the implementation team had to re-start the whole cycle again in order to upgrade the version of the system used by the original sites.

Evidently, the length of implementation is greatly affected by the scope of the project i.e. more activity regarding modules, sites and functions means a longer process. A large proportion of the implementation time is consumed by customising the package, so the length of time could be substantially reduced by keeping the system plain vanilla and reducing the number of packages that require customisation in order to be bolted on to it (Bingi et al. 1999), which has led software vendors and consultants to recommend a zero modification approach that has nowadays become a de facto standard.

This aspect of the implementation represented a lose-lose situation for the implementing site in our case study: on the one hand, to facilitate tight timelines, the number of specific requirements that could be taken into account was non-existent. On the other hand, the time it would have taken to analyse the new proposed business process to understand their impact on the local organisation was not sufficient, so stream leads found themselves in the unenviable position of having to accept process changes without really having time to validate them properly against local operations. Thus, the focus on deadlines (that were defined externally to the project team) meant that team leaders had to focus acutely on being on time at all stages. This resulted, in some cases, in critical tasks being left behind for the sake of being on time. It seems that a proper balance must be found between being on time for the sake of it and keeping all areas of the project as tight as possible.

Another interesting aspect of the timing of large multi-site global roll-outs is the learning that can occur from each site and the core teams ability to take on board this knowledge in a way that would make it meaningful for subsequent implementations. However, the learning process whereby manufacturing sites within the same company can improve the template based on their own implementation experience, such that subsequent sites might benefit is very difficult to put in place without totally losing control over the overall duration of the project. This leads MNCs to sometimes sacrifice this aspect in the name of standardisation and expediency (Bingi et al., 1999)

In our case study, the site studied was the first primary manufacturing site to go live, and thus their experience with the GSOPs and core team was invaluable for subsequent primary sites. However, there was no onus on the core team to pro-vide the channel for such communications, and they more or less started each site from scratch. Any communication between sites that did occur took place because it was initiated by the sites themselves.

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

5.4. ERP Project Cost Management

The total costs of implementing an ERP system include the cost of licensing, training, implementation, maintenance, customisation and hardware requirements (MacVittie 2001), but Bingi et al. (1999) warned that ERP projects are characterised by a lot of hidden costs. Berger (1998) added that for every pound spent on ERP software licences, companies must spend a further 5 - 7 pounds on related services, most of which are consultancy costs. Indeed, Scott et al. (2000) stated that the complexity of ERP projects has generated a lucrative consulting support industry and this has caused considerable controversy over the risks of escalating implementation costs.

Like most software, ERPs are priced on the functionality of the system and the number of users who will access it. ERP systems also require companies to invest in migrating data, modifying existing systems and overhauling hardware and network infrastructure. The costs quickly add up and Chevron spent nearly $160m implementing their ERP system over a five year period.

With the global roll-out of a corporate template the cost equation is a little more complex, with the local per user license fee probably being managed through a global contract with the corporation. The costs of the core team are, in addition, sunk in the corporate project budget. On the other hand, the local site manager of the project had to fund the local re-source bill for the project: secondment (and back-filling) of his stream leads for 12 months, the hiring of additional re-sources for data cleansing, and the hiring of specific technical skills (SAP). In addition the infrastructural costs to set the team up were considerable (involving the commissioning of one floor of an entire building to the team). This does not include training, travel and administrative costs.

Stedman (1998) states that 10%-20% of the total project cost is spent on training the end-users, e.g. Baan charge $5,000 per head to train users. The problem with using external trainers is that they are perfectly familiar with the ERP system but they are unable to answer questions regarding the business processes that underpin the system.

In the case study, the project budget was externally decided, which did not prevent some of the local teams to come in under their allocations. The firm minimised training costs by training super-users, some of which came from the data maintenance team, who were then used to train the rest of the workforce in the company.

An extensive training programme was put in place to ensure all staff were provided with training, no matter what shift pattern they worked. It was perceived as vital for the success of the project that training was undertaken by internal re-sources. Extra care went into planning for this, with mobile modular space being rented and set up in a corner of the car park to create a temporary dedicated training centre.

5.5. ERP Project Quality Management

An ERP system is not just an office automation software package that can be bought off the shelf and implemented with the aid of a step-by-step user manual. It is a serious transformation process that requires fundamental change in the way business processes are designed and conducted. Various methodologies have been put forward to ensure the package is implemented in a manner, which ensures the quality of the final system, i.e. that the system is implemented in an efficient way and the objectives are met. Minahan (1998) points to the need to hire the right people for the job internally and externally. Stefanou (2000) put for-ward a three-phase model for ERP selection. Crucially, both authors insist on preparing properly and thoroughly prior to acquiring or implementing any technologies, which is rarely the case in todays ERP market. Thus, both authors link the quality of the outcome of ERP projects to elements that must be put in place at the outset. The problem inherent in such ideas is that this is precisely the stage in a project where managers awareness levels are at their lowest and when they are least able to make key choices, hence the recourse to external parties which, unfortunately are rarely independent and un-biased.

Our case study showed a unique willingness to go it alone with respect to integration partners. There were no consult-ants employed in the local implementation team. Specific technical skills were hired into the team on contracts to bolster the team without the exorbitant expense of paying consultants day rates.

This had 2 effects on the running of the project:

1.Costs were minimised

2.Control was optimised

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

4.6. ERP Project Human Resource Management

An ERP implementation is a major undertaking, which requires management to assemble the best possible team to plan, execute and control the project. Top management must be visible in their commitment to the project, clarifying the exact goals of the project. Responsibility for the implementation should be given to those individuals who have high degree of knowledge of the business and the way that its component parts interact. This implies re-assigning the few people who are most likely to be missed from their duties to the ERP project team on a full time basis (Maher 1999).

Ignorance of the project needs and an inability to provide leadership and guidance to the project by the companys team is a major reason for the failure of ERP projects. It is not rare to find functional areas reluctant to sacrifice their best re-sources to the project. However, this is a difficulty which must be overcome (Bingi et al. 1999). The fact that teams must be cross functional is an added difficulty especially in firms with no culture for working across functional areas and no experience of such large projects.

In Pharma Inc., the communication between stream leads was very good, but the communication with the core team was very uneven, seemingly more dependent on individuals willingness to communicate than on any pre-defined scheme. In fact, there were even some incidents between members of the local team and members of the core team when local staff were able to demonstrate that the understanding that core team members had of the local processes was not sufficient.

In any case, the nomination of a well respected and experienced Director to the role of implementation site leader in the case study site ensured 3 key aspects to the success of the project:

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

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

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

At one critical point in the implementation analysis, the site leader threatened to pull out of discussions entirely unless the core team accorded sufficient respect to his stream leads. The affirmation of such clout, at a vital early point in the collaboration between stream leads and core team, laid the cornerstone for what was to become a much better working rela-tionship, as acknowledged by both sides, and contributed certainly to the success of the project.

Frequently, companies do not fully comprehend the impact of choosing the internal employees with the correct skill set. The right employees for the team should not only be experts in the companys processes but also be knowledgeable of the best business practices in the industry.

In the case studied, following the nomination of a high profile site manager, selecting and obtaining competent stream leads was the next key element of what was to be a winning combination. From the outset, the scale of the undertaking was appreciated, and the calibre of the team members was commensurate with the seriousness of the task ahead. All team members were reasonably senior, with on average 10-15 years experience in the business. All team members were full time on the project whether for the full duration of the project or for shorter durations in some cases. At key times in the project, key staff were added to the team for specific tasks, such as data conversion, training or desktop deployment, such that the team grew to more than 100 at certain times.

Wood and Caldas (2000) state that ERP implementation teams are multidisciplinary, dedicated teams, comprised normally of information technology specialists, key users and operations personnel, as well as consultants with process redesign and change management skills (Pg. 4).

In the case studied, although no external consultants were used, an important cross functional advantage emerged from the mix of people engaged on the team. As the stream leads were old hands in the business, not only were they acquainted with one another, they also had an intuitive grasp of the complexities in areas of the business other than their own particular domain. With systems as integrated as ERP, project team members have to always bear in mind the up-stream and downstream effects of choices and configuration options they make as the project progresses. It was acknowl-edged by the team and by neutral observers outside the team, that one of the key success factors of the project was the teams ability to work together, and to draw on the individual experience and authority across different functions in making key design decisions. The inclusion of an integration specialists charged with anticipated the impact in other areas of decisions made in each area was another key aspect.

Another unique element of the constitution of the local project team was the pre-meditated pairing of, as one team member out it, experience and energy in each of the process streams. Stream leads were allocated graduate level resources to work on data cleansing in each functional area, and this combination obviated the need to hire in expensive consultants, and created a pool of enthusiastic resources highly suitable to the task of training users when that time came closer to go-live.

Bingi et al. (1999) add a final point, stating that team morale is a vital component for the success of the project. Team members are required to put in long hours (as much as twenty hours per day) and this stress coupled with their regular duties could diminish team moral quickly. Thus, support from upper management and the project leader is key to maintaining a focused team.

It was also no coincidence that the team in our case study functioned in a harmonious manner: the site manager was at all stages attentive to the spirit of the team, monitoring formally and informally the morale of the troops, such that, even if the timeline was punishing, team members felt they were recognised for their efforts and could let off steam whenever the stress became too much. Team members were accorded duvet days if it was felt that the unforgiving schedule was be-ginning to impact negatively on performance.

It would be the researchers view that this factor is more in line with a personal style of management than an ERP success factor. Getting the best out of a team of volunteers is a challenge in many walks of life, and good leadership will always pay off in the end.

5.7. ERP Project Communications Management

Scott et al. (2000) observed that companies find it very difficult to communicate internally, each department viewing its information as its own and being reluctant to share it. Indeed, implementation team members discovered that it was easier to learn and share experiences with people from outside their organisation than within intra-organisational teams. This is where the chief benefit of using consultants to aid implementation is apparent, they add value to the project by facilitat-ing meetings as open discussions of requirements, preparing agendas, prioritising issues providing objectivity and avoiding bias, conflicts of interests and possible confusion (Pg. 112). Thus consultancy agencies are very important in ERP projects despite the possible lack of technical experience or knowledge (as in Wood and Caldas 2000 study), be-cause they facilitate open and productive communication.

Palaniswamy et al. (2000) state that the higher the levels of communication and interaction in the implementation team, the higher the performance of the team. The members of the team must be able to communicate between themselves, with the clients, the suppliers and all other stakeholders.

A global ERP implementation can also cause communications problems, Stedman (1998) gives an example of Meritor Heavy Vehicles Systems LLC which had to transfer a team of US employees to Europe for nine months in order to eliminate communications breakdowns caused by time-zone difficulties.

In the case studied, an additional team member was hired from a local PR company in order to concentrate on communication between the project team and the other employees at the plant. As part of his effort in communicating widely, he set up countless meetings, particularly with representatives of the unions, where extremely sensitive negotiations with respect to changes to job specifications were navigated to success with requisite care and attention. He and his team published 4 issues of a special internal magazine, solely dedicated to communicating project news, progress reports on achieving tar-gets and on respecting key milestones. At another level, this magazine served as a channel to get across to employees out-side the project, in an entertaining way, what the purpose of the project was and why their participation was vital. In addition, it introduced the project team to their future trainees, such that when time for training came around, individual relationships were brought into play to encourage full attendance.

On the day the application went live, one staff member ran the first transaction through the system behind closed doors (to avoid building up too much pressure), but the whole team was brought into the same office at 11.30 to stage a fake go-live for a historical photograph when it was certain everything was going as planned.

5.8. ERP Project Risk Management

There is ample empirical evidence of the risks involved in ERP implementations (Weston, 1998; Davenport, 1998; Adam, 2000). Wood and Caldas (2000) have stated that ERP implementations involve broad organisational transformation processes with significant implications on the organisations management model, organisation structure, management style and culture and particularly on people (Pg. 6). Thus as MacVittie (2001) puts it, ERPs require a radical change in the business processes of organisations, radical change means risks and risks mean more time and money.

Sammer (2000) cited the example of Bournes Inc., a manufacturing company in California, which encountered resistance to their new ERP system. Prior to the implementation, the local managers were used to tailoring financial information and reporting to meet their needs, but post implementation, there was consistent reporting across regions thus local managers were deprived of their autonomy and reacted negatively towards the new system.

ERP systems are complex and they require reliance on many different types of expertise, which may also need to be sourced outside the organisation. Good, experienced consultants are difficult to find, thus employing a consultancy firm is no guarantee that the project will be a success. Companies, which have trained their employees in the art of ERP implementation, stand a great risk of losing their investment because personnel with such experience are in great demand by consulting agencies.

The company we studied employed a novel approach to keeping resources post-go live. Most of the more senior resources returned automatically to their functions, whereas some of the data maintenance and SAP technical resources were given a choice of 3 avenues for continuing with the company. They could stay with the local company and move into the business stream that had worked on in the project, they could move to another ERP implementation site which were crying out for the resource, or they could stay with the project team in an ERP support role. Of 17 data analysts recruited for the project, 12 were retained by the company in this manner post go-live.

Also, Wood and Caldas (2000) discovered low levels of satisfaction among firms that have successfully implemented ERP systems, 45% of firms perceived no improvements whatever and 43% stated that no cycle reduction had been obtained. In brief, the risks associated ERP implementation projects are very high and the rewards are possibly very low. Yet as Wood and Caldas put it ERP systems seem to have simply conquered hearts and minds throughout the business realm (Pg.5).

We had an opportunity to observe a similar phenomenon in the case study when all the members of the ERP team slowly changed their minds during the 10 months of their implementation, evolving from a position of reluctance to implement to one where they all thought that the loss of flexibility in their business processes resulting from the ERP was a good thing because it would lead to more rigour in the business. In this site, it seemed that the realisation that complete disaster had been averted and that there would life after ERP was enough for everyone. That the headcount had in fact increased, or that the response time of the application was, at times, several minutes (when their American colleagues logged into the application) did not seem to matter in the end.

4.9. ERP Project Procurement Management

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

Shanks et al. (2000) conducted a comprehensive survey of successful ERP implementations and observed that ERP product selection is based on the following factors in the order of importance:

1.Business Fit

2.Ease of Implementation

3.Vendor Services and Support

4.Special Industry or Applications Capabilities

5.Product Affordability

6.Compatibility with Existing Systems

Judging these factors at the proper level of granularity requires using cross-functional and cross-business unit teams to ensure that the correct package is procured, i.e. a suite, which will support the long-term goals of the organisation (Mina-han,1998). Beyond these issues remain the many legal matters that are involved in ERP implementations. Drawing up a contract for an ERP application require specialised legal assistance and often many iterations insofar as the standard contracts pro-posed by ERP vendors are overly protective of their interest and systematically neglect the rights of their clients.

In our study, the decision to select SAP was a logical one, borne out of the fact that SAP is a package certified by the Federal Drugs Authority (FDA) as being compliant. For a pharmaceutical firm, this limits the risk of being imposed a penalty for infringement to compliance rules (knowing that such penalties may run in hundreds of millions of dollars). As a result, the perspective of creating implementation problems at the local level will not weight very heavily on the decision of the board of Directors. Local managers were never even consulted.

5.10 ERP Project Rationale Management

Wood and Caldas (2000) found some dubious reasons for implementing an ERP system, these included the need to follow a trend, the need to meet the pressures of the IT function and the pressures of the head office. They found that 36% of respondents declared, The firm didnt know exactly what it was buying or what could be expected from the system. They observed a scarcity of rationality in the decision process, but a high degree of emotion accompanied by a high degree of euphoria during implementation, which they believed, is consistent with managerial fads and fashions (Pg. 7).

Davenport (1998) suggested a number of questions that management need to ask themselves, to ensure that they are engaging in an ERP project for the right reasons and not from some knee-jerk reaction to their competitors actions or some-thing that they have heard about in the media.

1. How might an ERP system strengthen our competitive advantage?

2. How might it erode our competitive advantage?

3. What will be the systems affect on organisational culture?

4. Do we need to extend the system across all functions?

5. Should we only implement certain modules?

6. Would it be better to roll out the system globally or restrict it to certain regional units?

7. Are there other alternatives for information management that might actually suit better than an ERP system?

Top management need to answer these questions to ensure that they understand what an ERP system actually implies. Wood and Caldas (2000) discovered that many organisations failed to implement their ERP systems because they viewed them as just another IT project or some type of IT-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.

As pointed out in the previous section, the board of Directors of the firm studied had decided to implement SAP in a central and unilateral manner and there was no need for any debate as to what rationale was being followed. However unsatisfactory such decision making process may seem for local managers who dont ever get to make a real business case for ERP, there is no doubting the rationality of making such choices in a multinational. However, this is very difficult to get across properly at the local level.

5.11 ERP Project Review Management

The Deming Cycle (plan do check act) or Simons 1977 Decision Making Model (Intelligence Decision Implementation Review) as applied to Project Management is disputed by some project managers because if projects are unique there should be no need for a review since nothing can be learned from it which can be applied to new projects in the future but this is quite misguided in that it is still quite useful to establish whether the targets built into the project (which were used to justify the investment) have been reached. Refusing to investigate whether reductions in inventory have been achieved amounts to little less than buying ones head in the sand. However, this is an area where little empirical evidence is available because many firms have been cagey about leaving researchers control whether benefits had been achieved. Surveys have nevertheless indicated that many firms were aware that specific improvements they sought never materialised.

In the firm we studied, an Operational Excellence group, which had been founded well in advance of ERP to examine process improvements and improve performance metrics in general, was responsible for carrying out an extensive AAR (After Action Review) of the entire project, whish involved revisiting objectives 12 months after go live to evaluate whether they had been achieved. A media rich presentation collating the results of the AAR was published internally on CD and on the web.

Indeed, this same group, from whose ranks one of the stream leads came, in its role of ongoing process improvement mentors, are uniquely placed to advise different parts of the business on how to get the best from the ERP system. As she put it herself, the head of the Operational Excellence group will go investigating how to get information from the ERP system, when she is addressing a particular process inefficiency. It is the researchers conviction that it is this trial and error approach to exploiting the vast richness of transactional data stored in the ERP system, that will yield benefits in the years following implementation, rather than bemoaning the lack of vanilla reports from the system and the construction of parallel data warehouses to address specific functional reporting needs.

4.12 Global ERP Project Management

Production and manufacturing operations have become more complex, automated and geographically dispersed according to Palaniswamy et al. (2000). ERP systems are designed to cope with the complexity inherent in geographical dispersion but a global ERP implementation confronts many issues, which are particular to worldwide implementation projects, e.g. decision making involving different time horizons, geographical dispersion and concurrently (Palaniswamy et al. 2000).

Davenport (1998) wonders there should be uniformity a multinational does business in different regions or countries. For most companies, differences in regional markets remain so profound that strict process uniformity would be counterproductive. Companies must remain flexible and allow regional units to tailor their operations to local customer requirements and regulatory structures. Davenport recommends a type of federalist systems where different versions of the same system are rolled out to each regional unit, e.g. Monsanto, Hewlett-Packard and Nescafe have found this approach successful. This raises its own problems for the company, i.e. deciding on what aspects of the system need to uniform and what aspects can be allowed to vary (Horwitt 1998).

In the case studied, it is clear that a good deal more could be done for local sites ability to question and change a global template, if not the choice of package itself. Multi-national businesses need to take into account the idiosyncrasies of local operations when imposing a global corporate standards on critical business processes such as cash collection, procurement, and material planning.

By the time all sites had been implemented, the first sites had been left behind and had to upgrade to the newer version of the package. Staff seemed resigned to the fact that an ERP implementation is never truly over and that no one is ever al-lowed to get too comfortable with any business practice.

5. Conclusions

The success rate of ERP implementations is not high in view of the sums invested by firms in these applications. It has often been indicated that a combination of inadequate preparedness and inappropriate project management have been responsible for the low success rate of ERP implementations. Our investigation into the project management strategy adopted in the Pharma Inc. case under the 12 headings of our revised model illustrates one vision of what could be termed best practice in terms of ERP implementation. In particular, it shows the importance of project governance and the need for a multi-level structure spanning both the corporate and local levels. It also shows the crucial importance of the proper selection of team members and the need for a high profile team leader even at the local level. On a more technical basis, it suggests that a dual cycle of exploration / negotiation leading to a stable corporate template on the one hand and execution / roll out on the other hand could greatly boost the success rate of ERP projects. Project managers need to be persuaded that any unclear area not resolved in the exploration cycle will need to be tackled in the implementation or else there is a risk that it might get left behind and only re-emerge after go live with disastrous consequences. In relation to the creation of such a template, it is certain that differences in expertise and cultures within MNCs (eg: primary versus secondary sites in our case study) cause many additional problems which require substantial re-works and workarounds.

However, even in this very positive case, some aspects remain open to criticism. In particular, the need for balance between attention to local specificities and the need to standardise business processes and stay on schedule seems to be very difficult to find. In a MNC, the corporate level is strong enough to impose its rules, but the cost at local level in terms of motivation lost and inefficiencies must be understood. Also, the need to preserve learning in each roll out so it can benefit to all sites is critical and was neglected in Pharma Inc. The core team members need to understand that it is part of their role to support the communication between the sites that have done it and those that have not.

This research brings us closer to an ERP specific methodology to systems implementation in large firms. However, more case studies will be required to assemble a complete set of best practice recommendations for future ERP project managers.

References Adam, F (2000) Rflexions sur le mouvement ERP Risques et Opportunits, Congrs de la Net-Economie, Mach 2000, Paris, France.

Berger, P. (1998) PGI: les services valent cher, Le Monde Informatique, 25th September 1998, #779.

Bingi, P., Sharma, M. and Godla, J. (1999) Critical Issues Affecting an ERP Implementation, Information Systems Management, Summer 1999, 7-14.

Davenport, T. (1998) Putting the Enterprise into the Enterprise System, Havard Business Review, July-August, 131-131.

Eisenhardt, K. M. (1989). Building theories from case study research. Academy of Management Review, 14, 532-550

Horwitt, E (1998) Enduring a global rollout - and living to tell about it, Computerworld, March 1998.

McKie, S. (1999) The great leap forward, Business and Finance, January 1999.

McVittie, L (2001) Buckle up: Implementing ERP takes time and Patience, March 2001; URL: www.networkcomputing.com/.

Maher, J (1999) ERP in industry: Automate and integrate, The Engineers Journal, November, 1999.

Maylor, H (2001) Beyond the Gantt chart: Project management moving on, European Management Journal, 19(1).

Minahan, T (1998) Enterprise Resource Planning, Purchasing, July 16 1998.

Palaniswamy, R and Frank, T (2000), Enhancing Manufacturing Performance with ERP Systems, Information Sys-tems Management, Vol. 17, No. 3, pp. 43-55.

Patton, M. (1990) Qualitative evaluation and research methods, Sage Publications, Newbury Park, CA.PMBOK (2000) Project Management Institute Body of Knowledge. URL: www.pmi.org.

Sammer, J (2000) The ERP continuum, Business and Finance, Issue 343, December.

Scott, J and Kaindl. L (2000) Enhancing functionality in an enterprise software package, Information and Manage-ment, 37.

Shanks, G., Parr, A., Hu, B., Corbitt, B., Thanasankit, T., Seddon, P., 2000, Differences in Critical Success Factors in ERP Systems Implementation in Australia and China: A Cultural Analysis, Proceedings of the 8th European Con-ference on Information Systems, July 3-5 2000, Vienna Austria, 537-544.

Simon H., 1977, The New Science of Management Decisions, Prentice Hall, Englewood Cliff, New Jersey.

Stedman, C Global ERP rollouts present cross-border problems, Computerworld, November 1998.

Weston, R (1998) ERP users find competitive advantages, Computerworld,, January 19, 1998

Wood, T. and Caldas, M. (2000) Stripping the big brother: unveiling the backstage of the ERP fad, http://www.gv.br/prof_alunos/thomaz/ingles/paper5.htm.