Professional Documents
Culture Documents
1.1 DEFINITION
1.2 Purpose
The success rate of enterprise resource planning (ERP) implementations is not high in
view of the sums invested by organizations in these applications. It has often been
indicated that a combination of inadequate preparedness and inappropriate project
management have been responsible for the low-success rate of ERP implementations.
The purpose of this paper is to present a case study of a successful ERP
implementation.
1.3 Design/Methodology/Approach
In this paper, the authors use a case study of a very successful roll out of an ERP
application in the Irish subsidiary of a UK multinational to investigate the validity of
one of the most commonly cited project management frameworks, the project
management body of knowledge (PMBOK), to ERP projects. Discussing each
category of the framework in turn, the case data to illustrate where the PMBOK
framework is a good fit or needs refining for ERP projects is used.
1.4 Findings
It is found that, by and large, PMBOK, because it is a very broad framework, can
shed light on most of the key aspects of an ERP project. However, the specificities of
this type of project require a different emphasis on some of the factors, as discussed
in the authors’ conclusions. The case analysis also raised some interesting insights
into how companies evaluate the success of such highly complex change management
initiatives.
1.5 Research Limitations/Implications
This research work will need to be extended to cover other case studies of ERP
implementation across other industries and organizational contexts; for example in
less tightly regulated industries and smaller organizations.
This discussion will be of great value to ERP project managers who are in the early
stages of a project and need to understand and anticipate the areas which will require
specific attention on their part, based on their knowledge of the specific
circumstances within their organizational context.
1.7 Originality/Value
This paper presents an investigation into the project management strategy adopted in
the Pharma Inc. case and illustrates the mechanics of a successful ERP project
implementation, categorized using the PMBOK framework.
2.0 INTRODUCTION
A considerable volume of research has been carried out on enterprise wide systems and most
notably on enterprise resource planning (ERP) systems. This research has established that on
the one hand, significant benefits can accrue to organizations implementing these systems
(Shang and Seddon, 2002) but on the other, many implementations are not conclusively
successful (Holland et al., 1999). There is evidence that the degree to which organizations
prepare themselves for their implementation projects has a bearing on whether they
encounter many problems during implementation and ultimately, whether they achieve any
of the benefits they sought (Sammon et al., 2004). It also appears that inadequate project
management leads to short-term solutions being applied to the problems that occur during the
implementation of ERP systems with substantial side effects when systems go live (Saint-
Leger and Savall, 2001).
Previous research has indicated that the scope and complexity of ERP implementations are
different from traditional analysis and design projects (Davenport, 2000) suggesting specific
project management strategies should be developed to tackle the specific challenges of such
projects. In particular, it is argued that ERP projects are often associated with the widespread
“re-engineering” of business practices, whereas traditional projects have smaller
organizational “footprints” and are designed to match current practices. In this paper, we
leverage our investigations of a very successful ERP implementation in a multinational
pharmaceutical company (Pharma Inc.) to gain an insight into the project management
strategy adopted to manage what was a successful ERP implementation. To facilitate the
presentation of our findings from this case investigation we use the nine areas of the project
management body of knowledge (PMBOK) framework.
The remainder of this paper is organized as follows. The next section presents the PMBOK
framework, which has been put forward as a best practice vehicle to understand project
management in information systems (IS) projects (Project Management Institute – PMI,
2000). In the second section, we present the case study protocol we followed and the methods
we applied to the case study of Pharma Inc. In the third section, we review the findings of the
case under the nine headings of the PMBOK framework and, finally we propose conclusions
towards excellent project management practices for ERP projects.
Project management helps project managers to standardize routine tasks and ensure that
available resources are used both efficiently and effectively. The application of its principles
allows senior managers to establish and use appropriate measures of success, to quantify
value commensurate with cost and to optimize the use of organizational resources. Project
management as a discipline is only a recent concept and yet, over the past 50 years a
considerable body of knowledge has been built up around its tools, skills and techniques. The
PMI is acknowledged as the pioneering group worldwide for bringing professionalism to the
area of project management. The PMI boasts a worldwide membership of several hundreds
of thousands. The PMI provides a variety of services for project managers, including:
education and certification, and standards in the form of the PMBOK.
The PMI produced the first version of the PMBOK in 1987 and the PMBOK has been
continually enhanced since then, with the third edition produced in 2000. The PMBOK is a
set of standards (management best practices that are common to projects) and it describes the
sum of knowledge within the profession of project management. The body of knowledge
rests with practitioners and academics that apply and advance it (PMI, 2000). The PMBOK is
organized into nine knowledge areas that are considered a subset of project management and
describes the knowledge and practices in terms of the component processes required to
ensure a project is properly coordinated (PMI, 2000) such that the project:
The processes within each knowledge area interact with each other and with the processes in
other knowledge areas. Each process has an input for the process tools and techniques to
carry out the process, and an output from the process. While each process presented within
the knowledge areas appear as discrete elements with well-defined interfaces, some
interaction and overlap is expected in practice. The nine areas are illustrated in Table I.
One of the recommendations of the PMI is that although the PMBOK is generally
accepted and there is widespread consensus regarding the value and usefulness of the
nine knowledge areas, it does not mean that the knowledge and practices described
should be applied uniformly on all projects. Ultimately, “the project management
team is always responsible for determining what is appropriate for any given project”
(PMI, 2000, p. 3). Therefore, one issue of importance in this paper is whether this
PMBOK framework is immediately applicable to ERP projects. It is useful to
consider to what extent ERP implementations are like or unlike other IS projects.
Prima facies, most of
the salient points (either good or bad) that have been reported about ERP projects in
the literature, either in terms of case studies or in terms of critical success factor
(CSF) research, seem to fall naturally within these categories. Thus, we can argue that
there is a good fit between the PMBOK “traditional” framework and ERP projects.
Nevertheless, reported cases of ERP failure seem to indicate that certain, particularly
sensitive areas of traditional project management require greater emphasis than
others. For example, the specification of requirements for ERP projects is often non-
existent or applied retrospectively because organizations are hoping to acquire ready-
made solutions that embody best practice that is directly applicable to them. In these
cases, the project begins with discussions with consultants already propounding a
particular software solution and technical architecture where other important aspects
are overlooked, for example, how the project should be managed. Based on calls from
previous researchers to derive better suited project management practices and better
approaches to ERP in general (Sauer, 2002; Swanson and Ramiller, 2004) and on
available evidence of the problems that have led to significant failure rates in the past
for such projects, there is a need to analyses the nine areas of the PMBOK and discuss
their relevance in the context of a successful ERP project implementation process in
order to fully understand how to apply the framework in the case of an ERP project.
4.1 METHODOLOGY
In this paper, we present a case study of Pharma Inc., where a successful ERP
implementation took place over a period of time between early-2003 and end-2004. We
followed the case study over this period, and as a benchmark project it has considerable value
in that it is perceived by all participants as being a notable success, both for the implementing
subsidiary and for the parent company. Concretely this means that the system went live as
expected, on time and within budget, and that the project team were able to achieve a rapid
ramp-up to full production volumes ahead of time (seven weeks instead of the predicted
nine weeks after go-live). This
makes Pharma Inc. an example of an extreme case in Patton’s (1990) classification of
purposeful sampling strategies and this justifies the choice of this case as a basis for
determination of best practice in ERP implementations.
One feature of this case study is that previous waves of the ERP implementation had
only been carried out at secondary sites. The manufacturing subsidiary studied here
was the first primary site to go live on the new SAP system, and this raised additional
challenges that were not anticipated. Project members from the implementation team
studied here were solicited by the core team post go-live to assist with the SAP roll-
out in further primary sites, based on the skills and know-how gained in adapting the
global template to their local (primary site) requirements.
TABLE II: Key characteristics of the case study organization
We began this research as invited facilitators of a team building and ERP awareness
seminar pre-project implementation in April 2003. This allowed us direct access to
the team members at a very early stage in the process, and the feedback from the first
round of interviews and questionnaires demonstrated a certain perception of the
benefits of ERP that radically changed over the remaining months of the project.
Becoming known as the team “confessors” we had privileged access to the local
implementation team for the duration of the project. Being seen as neutral observers,
we were privy to the personal opinions, doubts and convictions of the team as they
struggled with the concept, timescale and reality of spearheading the organizational
changes that are part of an ERP roll-out. We feel that this “insider knowledge”
allowed us to make judgments on what elements of the project management had
contributed most to its success, and in so doing, to enrich the PMBOK framework
with criteria specifically aimed at achieving success in large-scale enterprise
integration projects.
5.1 ERP PROJECT MANAGEMENT AT PHARMA INC.
The following sections report on the findings and important observations from the case study
organized using the nine areas of the PMBOK framework.
In Pharma Inc., the overall level of preparation was quite good at the local site, given
that this was the fourth wave of a global project that had already seen five
manufacturing sites go-live with the ERP global template. It was understood from the
outset that the number one objective of the project was process compliance, which
would have an immediate impact on the plant’s ability to withstand an audit from the
industry regulatory body, the Food and Drug Administration. In this context, ERP
was ultimately seen as a necessary cost avoidance investment. This was confirmed in
a survey question aimed at soliciting team members’ understanding of the expected
benefits to be delivered by the new ERP system. Table IV highlights the results of
this survey question from April 2003.
There was a general acceptance that the benefits to be derived from the ERP roll-out
were for the “greater good” of the corporation, rather than any particular advantage to
be derived from the local site. The aggregated results of the answers to the question
“Is ERP an enabler or a driver of change?” in April 2003, when the project team was
still
being consolidated, and there may still have been some hope among team members
that some benefits would accrue to the site, despite the acknowledged compliance
agenda show our respondents split 45 per cent (enabler)/55 per cent (driver). By
contrast, in December 2003, just before the project went live, only 9 per cent of
respondents held on to their belief that the ERP had been an enabler of change, 91 per
cent judging it to have been a driver of change. This conviction, that ERP was
imposing change, softened somewhat after go-live, with the 91 per cent dropping to
71 per cent six months later, after go-live. It might be argued, that at this point, any
remaining “naivety” about the rationale behind the ERP implementation had
evaporated, but that team members could sense the potential for engineering
“improvements” to the newly implemented compliant processes. Key here would be
the confidence of the team as it had gone through a very aggressive project, gone live
on time and come out intact.
TABLE IV: What are the expected benefits from the ERP implementation?
It is interesting to note that, at the early stage, team members were quite uncertain
about the task facing them and that they feared that SAP would jeopardize much of
the work accomplished in previous years in streamlining and optimizing key
processes. They perceived themselves as being far ahead of other sites in Pharma Inc.,
particularly with respect to customer satisfaction, a key performance indicator
measuring the per cent shipments made to customers within the commit date. Local
management were worried that this global roll-out would impact their customer
satisfaction rating, their efforts in distinguishing themselves being therefore nullified.
However, this impression was
slowly reversed over the course of the project. When initially asked in April 2003 to
list the core competences or areas of excellence that made them stand out from other
subsidiaries, respondents identified the following strengths: customer responsiveness,
innovation, new product introduction (NPI), “CAN DO” attitude, R&D (research and
development), implementation of new processes/technologies, manufacturing
knowledge and ability, project delivery track record/proven performance, and highly
efficient and flexible operation/quality. Approximately nine months later, just prior to
go-live, they were asked to rate the impact of the new ERP systems on these core
competences. The results of this question are displayed in Table V.
At Pharma Inc., it is clear that a good deal more could have been done for local sites’
ability to question and change a global template, if not the choice of package itself.
Multinational corporations (MNCs) need to take into account the idiosyncrasies of
local operations when imposing a global corporate standard on critical business
processes such as cash collection, procurement, and material planning. By the time all
sites had been implemented, the first sites had been left behind and had to upgrade to
the newer version of the package. Staff seemed resigned to the fact that an ERP
implementation is never truly over and that one cannot get too comfortable with any
business practice. In the case of Pharma Inc., an operational excellence group, which
had been founded well in advance of ERP to examine process improvements and
improve performance metrics in general, was responsible for carrying out an
extensive after action review (AAR) of the entire project, which involved revisiting
objectives 12 months after go live to evaluate whether they had been achieved. A
media rich presentation collating the results of the AAR was published internally on
CD and on the web. Indeed, this same group plays a role of ongoing process
improvement and its “mentors” are uniquely placed to advise different parts of the
business on how to get the best from the ERP system. As she put it herself, the head
of the operational excellence group will go “investigating” how to get information
from the ERP system, when addressing a particular process inefficiency. It is the
researchers’ conviction that it is this “trial and error” approach to exploiting the vast
richness of transactional data stored in the ERP system, that will yield benefits in the
years following implementation, rather than bemoaning the lack of vanilla reports
from the system and the construction of parallel data warehouses to address specific
functional reporting needs, so prevalent among other less successful implementations.
Indeed, this approach is evidence of the survival of the “CAN DO” attitude, despite
the perceived constraints of ERP!
TABLE V: Level of impact of ERP on core competences (December 2003)
TABLE VI: Level of impact of ERP on core competences (September 2004)
At Pharma Inc., of an initial core team of 24 business representatives only two team
members had direct experience of an ERP system implementation. This meant that
much work was done in the project preparation phase from mid-2003 to educate team
members on the background to ERP projects, the key challenges they would face as a
project management team and the communication channels that would be used to
make decisions. Following this rapid learning curve, with just nine months on the
project and with go-live imminent, team members were extremely aware of the extent
of the changes that were about to take place and for which they would have to take
responsibility. Table VII illustrates their response to the question “What level of
change do you expect across the main business processes impacted by ERP?”
It was recognized at Pharma Inc. that dealing with change of the scale implied by a
new ERP system would require particular attention and careful monitoring. In the
case studied, an additional team member was hired from a local PR company in order
to concentrate on communication between the project team and the other employees
at the plant. As part of his effort he set up countless meetings, particularly with
representatives of the unions, where extremely sensitive negotiations with respect to
changes to job specifications were navigated to success with requisite care and
attention. Furthermore, the project PR consultant and his team published four issues
of a special internal magazine, solely dedicated to communicating project news,
progress reports on achieving targets and on respecting key milestones. This served as
a channel to get across to employees outside the project, in an entertaining way, what
the purpose of the project was and why their participation was vital. In addition, it
introduced the project team to their future trainees, such that when time for training
came around, individual relationships were brought into play to encourage full
attendance.
In Pharma Inc., the communication between stream leads was very good, but the
communication with the core team was very uneven, seemingly more dependent on
individuals’ willingness to communicate than on any pre-defined scheme. In fact,
there were even some “incidents” between members of the local team and members
of the core team when local staff were able to demonstrate that the understanding that
core team members had of the local processes was not sufficient. In any case, the
nomination of a well-respected and experienced logistics director to the role of
implementation site leader ensured that the project team was given recognized status
and authority in the eyes of local employees, and a direct line of communication was
opened between the project team and the general manager of the plant. Crucially, the
political strength of the project leadership gave vital support and encouragement to
the project team in its relations with the implementation core team. At a critical point
in the implementation analysis phase, the site leader threatened to pull his entire team
out of the project unless the core team accorded sufficient respect to his stream leads.
The affirmation of such
“clout” at a vital early point in the collaboration between stream leads and core team,
laid the cornerstone for what was to become a much better working relationship, as
acknowledged by both sides, and contributed certainly to the success of the project.
TABLE VII: What level of change do you expect in your business area?
Again, this aspect of ERP projects pertains to how well organizations are prepared
when they embark on their implementations. Davenport (1998) states that the single
biggest reason that ERP projects fail is because companies are unable to reconcile the
technological necessities of the system with their own business needs. A lack of
understanding of the scope of the system may result in a conflict between the logic of
the system and the logic of the business. In complex organizations such as MNCs, this
requires a preliminary determination of what configuration will be rolled out in the
different sites – the template. At Pharma Inc. the global template had been designed
around corporate best practice. So the parameters and options that were available to
the implementing site were not a question of SAP options, but rather a question of
choices available under the corporate best practice template – the global standard
operating
procedures or GSOP’s. It became clear that in order to negotiate changes to this
template, with a view to accommodating local requirements, new types of skills
would be required. The discussion became a three-way negotiation between the local
“stream lead” or subject matter expert, the core team member who had an in depth
knowledge of the GSOP, and a SAP expert recruited by the local implementation site
to advise on what was, and was not, possible with SAP. On several occasions, the
GSOP was lacking in basic functionality that the site required, and yet the core
implementation team was unable to suggest the solution because their experience was
limited to the global best practice template. For example, core team members were
unable to understand the limitations of a bulk chemical dispensing parameter that did
not have the required number of decimal places to record the actual readings from the
scales in use in the plant (the template having been designed for tablets, not bulk
chemical). The response of the core team, unacceptable to the local implementation
team, was to use the parameter as it was defined and lose the data granularity! The
clash between the two cultures inherent in Pharma Inc., the primary sites and their
non-discrete processes and the secondary or tableting plants and their discrete
processes, was the source of such problems. Thus, the scope of the implementation
needed to be re-examined to fit with the operations of the local plant, and this
necessitated the availability of advanced SAP knowledge to be able to suggest
workarounds.
In this case study the scope was very broad (warehouse, engineering, finance,
procurement, production planning, production execution, quality, sales and
distribution and NPI/R&D). All of these modules were integrated in the new global
process model, so it was not an option to implement a subset. During the project, two
elements of the scope of the project emerged that were not anticipated in advance:
(1) the amount of work that would be required in collecting, cleaning up and
converting legacy data into a format suitable for the new system; and
(2) the changes that would be required to the physical organization of the
warehouse function when the system was used to dispense material (primary
sites are characterized 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 equivalent’s ensured that data going into the new
system was clean, valid and in the right format.
Depending on the size of the organization and the scope of the project, implementing
an ERP system may take years because of the need to be rolled out across multiple
sites, lines of business and countries. In the case of global roll-outs at MNCs, project
time management is critical during the chartering, project and shakedown phases.
At Pharma Inc., the four waves of the implementation programmed ran over a period
of over five years. In fact the timescale of the global roll-out was so long that by the
time the last site was up and running, the implementation team had to re-start the
whole cycle again in order to upgrade the version of the system used by the original
sites. Evidently, the length of implementation is greatly affected by the scope of the
project,
i.e. more activity regarding modules, sites and functions means a longer process. A
large proportion of the implementation time is consumed by customizing 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 customization 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.
Another aspect of the timing of large multi-site global roll-outs is the learning that
can occur from each site and the core team’s ability to take on board this knowledge
in a way that would make it meaningful for subsequent implementations. However,
the learning process whereby sites within the same organization can improve the
template based on their own implementation experience, such that subsequent sites
might benefit, is very difficult to put in place without losing control over the overall
duration of the project. This leads MNCs to sometimes sacrifice this aspect in the
name of standardization and expediency (Bingi et al., 1999). This might explain why
the local implementation team did not regard project management as important
initially. At the beginning, the team perceived the required skills for the project to be
knowledge of SAP (38 per cent), process knowledge (27 per cent), existing systems
knowledge (23 per cent) and project management (14 per cent). This perception
developed over time however, and the importance of project management skills began
to grow as the project approached go-live. It needs to be remembered that none of the
team members were “project managers” per se, and that there was no systems
integrator on board to carry the can for meeting deadlines. Figure 1 shows how the
perception of skills changed over time (in December 2003 and nine months after go-
live in September 2004). The increased importance of “Project Management” “SAP
Knowledge” and the continued importance of the “Process Knowledge” skill sets is
evident. On the other hand, “Existing Systems Knowledge” and “Data Knowledge” is
perceived to be less important.
Like most software, ERPs are priced on the functionality of the system and the
number of users who will access it. Organizations are also required to invest in
migrating data, modifying existing systems and overhauling hardware and network
infrastructure. With the global roll-out of a corporate template the cost equation is a
little more complex with the local per user license fee probably being managed
through a global contract
with the corporation. The costs of the core team are, in addition sunk in the corporate
project budget. On the other hand, the local site manager of the project had to fund the
local resource bill for the project: secondment (and back-filling) of his stream leads
for 12 months, the hiring of additional resources for data cleansing and the hiring of
SAP. In addition, the infrastructural costs to set the team up were considerable. This
does not include training, travel and administrative costs.
In the case study, the project budget was externally decided, which did not prevent
some of the local teams to come in under their allocations. The organization
minimized training costs by training “super-users” some of which came from the data
maintenance team, who were then used to train the rest of the local site workforce. An
extensive training programmed was put in place to ensure that all staff were provided
with training, no matter what shift pattern they worked. It was perceived as vital for
the success of the project that training was undertaken by internal resources. Extra
care went into planning for this, with mobile modular space being rented and set up in
a corner of the car park to create a temporary dedicated “training center”.
FIGURE I: What skills are most important in this ERP project? (December 2003 vs
September 2004)
5.6 Project human resource management
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 company’s processes but also be knowledgeable of the best business
practices in the industry. At Pharma Inc., following the nomination of a high profile
site manager, selecting and obtaining competent stream leads was the next key
element of what was to be a winning combination. From the outset, the scale of the
undertaking was appreciated and the caliber 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 experiences in the business. All team members were full time
on the project whether for the entire duration of the project or for shorter periods. At
key times in the project, staff were added to the team for specialized tasks such as
data conversion, training or desktop deployment, such that the team grew to more
than 100 at certain times.
Bingi et al. (1999) add a final point, stating that team morale is a vital component for
the success of the project. It was no coincidence that the team in our case study
functioned in a harmonious manner: the site manager was at all stages attentive to the
“spirit” of the team, monitoring formally and informally the morale of the troops,
such that, even if the timeline was punishing, team members felt they were
recognized for their efforts and could let off steam whenever the stress became too
much. Team members were accorded “duvet days” if it was felt that the unforgiving
schedule was beginning to impact negatively on performance. It would be the
researchers’ view that this factor is more in line with a personal style of management
than an ERP success factor. Getting the best out of a team of volunteers is a challenge
in many walks of life, and good leadership will always pay off in the end.
6.0 CONCLUSION
Our investigation into the project management strategy adopted in the Pharma Inc. case under the
nine headings of the PMBOK framework illustrates one vision of what could be termed “best
practice” in terms of ERP implementation. In particular, it shows the importance of project
governance and the need for a multi-level structure spanning both the corporate and local levels.
Indeed, these governance structures ensured that the ERP project maintained focus in terms of
direction, reduced the possibility of delays and rework due to the fact that timely problem
resolution could be carried out. Overall, these structures supported timely decision making in an
effort to minimize the impact, or avoid the possibility, of risks on the project. It also shows the
crucial importance of the proper selection of team members and the need for a high profile team
leader even at the local level. Being able to call on specific local skills at different points in the
project, whether they were application focused or business focused, was a strong factor in the
success of the implementation. On a more technical basis, it suggests that a dual cycle of
exploration/negotiation leading to a stable corporate template on the one hand and execution/roll-
out on the other hand could greatly boost the success rate of ERP projects. In relating the areas of
ERP project management to specific stages of the ERP development lifecycle, attention is drawn
to specific areas that need to be emphasized at different times. Project managers need to be
persuaded that any unclear area not resolved in the exploration cycle will need to be tackled in
the implementation stage or else there is a risk that it might get left behind and only re-emerge
post go-live with disastrous consequences. In relation to the creation of the template of the
ERP, it is
certain that differences in expertise and cultures within MNCs (e.g. primary vs secondary sites in
our case study) cause many additional problems which require substantial re-works and
workarounds.
However, even in this very positive case, some aspects remain open to criticism. In particular,
the need for balance between attention to local specificities and the need to standardize business
processes and stay on schedule seems to be very difficult to find. In a MNC, the corporate level
is strong enough to impose its rules but the cost at local level in terms of motivation lost and
inefficiencies must be understood. Also, the need to preserve learning in each roll-out so it can
benefit to all sites, but also in the following phases of the roll out is critical and was neglected in
Pharma Inc.
This research brings us closer to an ERP-specific project management for large organizations. It
also suggests a novel approach to using the perceived strengths of the organization as a
barometer for the impact of such transformational systems, such as ERP. Further, case studies are
planned to assemble a complete set of best practice recommendations for future ERP project
managers. However, a potential weakness in the current methodology is that the pharmaceutical
sector is highly regulated; therefore business functions are very familiar with the bureaucratic
constraints imposed by external bodies in terms of quality, safety, traceability and transactional
integrity. “90 per cent of the errors in batch manufacturing are around documentation” is how it
was described by one corporate manager. This puts the organization at an advantage when
implementing a highly integrated suite of applications where new control processes will perhaps
find acceptance more quickly than in a less regulated manufacturing environment. In fact,
looking at a sample of such implementations in a less regulated organizational environment,
through the lens of the PMBOK framework, would constitute a further step in validating the
findings of this study.
7.0 REFERENCES
Bingi, P., Sharma, M. and Godla, J. (1999), “Critical issues affecting an ERP implementation”,
Information Systems Management, Summer, pp. 7-14.
Davenport, T.H. (1998), “Putting the enterprise into the enterprise system”, Havard Business
Review, July/August, pp. 121-31.
Davenport, T.H. (2000), Mission Critical – Realizing the Promise of Enterprise Systems,
Harvard Business School Press, Boston, MA.
Finney, S. and Corbett, M. (2007), “ERP implementation: a compilation and analysis of critical
success factors”, Business Process Management Journal, Vol. 13 No. 3, pp. 329-47.
Holland, C.P., Light, B. and Gibson, N. (1999), “A critical success factors model for enterprise
resource planning implementation”, Proceedings of the 7th European Conference on Information
Systems, Copenhagen Business School, Copenhagen, pp. 273-87.
Lam, W. (2005), “Investigating success factors in enterprise application integration: a case-drive
analysis”, European Journal of Information Systems, Vol. 14 No. 2, pp. 175-87.
Maher, J. (1999), “ERP in industry: automate and integrate”, The Engineers’ Journal, November.
Markus, M.L., Axline, S., Petrie, D. and Tanis, C. (2000), “Learning from adopters’ experiences
with ERP: problems encountered and success achieved”, Journal of Information Technology,
Vol. 15 No. 4, pp. 245-65.
Minahan, T. (1998), “Enterprise resource planning”, Purchasing, 16 July.
Murphy, K.E. and Simon, S.J. (2002), “Intangible benefits valuation in ERP projects”,
Information Systems Journal, Vol. 12 No. 4, pp. 301-20.
Parr, A. and Shanks, G. (2000), “A model of ERP project implementation”, Journal of
Information Technology, Vol. 15 No. 4, pp. 289-303.
Patton, M. (1990), Qualitative Evaluation and Research Methods, Sage, Newbury Park, CA.
PMI (2000), A Guide to the Project Management Body of Knowledge, PMI Publishing Division,
The Project Management Institute, Sylva, NC.
Saint-Leger, G. and Savall, H. (2001), “L’apres project ERP: Retour d’experience sur un
changement qui n’a pas eu lieu” (“Post-ERP phase: feedback from experience regarding a
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-implementation
discourse”, Proceedings of the 6th International Conference on Enterprise Information Systems,
April, Porto, Portugal.
Sauer, C. (2002), “ERP project implementation pitfalls”, available at: www.snrgy.com/next/
article3.htm (accessed 3 October 2002).
Scott, J. and Kaindl, L. (2000), “Enhancing functionality in an enterprise software package”,
Information & Management, Vol. 37 No. 3, pp. 111-22.
Shang, S. and Seddon, P.B. (2002), “Assessing and managing the benefits of enterprise systems”,
Information Systems Journal, Vol. 12 No. 4, pp. 271-99.
Somers, T.M. and Nelson, K. (2001), “The impact of critical success factors across the stages of
enterprise resource planning implementations”, Proceedings of the 34th Hawaii International
Conference on Systems Sciences, Honolulu, HI, USA, pp. 1-10.
Stefanou, C. (2000), “The selection process of enterprise resource planning (ERP) systems”,
Proceedings of the 6th Americas Conference on Information Systems (AMCIS), 10-13 August,
Long Beach, CA, pp. 988-91.
Swanson, E.B. and Ramiller, N.C. (2004), “Innovating mindfully with information technology”,
MIS Quarterly, Vol. 28 No. 4, pp. 553-83.
Wood, T. and Caldas, M. (2001), “Reductionism and complex thinking during ERP
implementations”, Business Process Management Journal, Vol. 7 No. 5, pp. 387-93.