Clustering ERP Implementation Project Activities: A
Foundation for Project Size Definition
Guy Janssens
, Rob Kusters
1, 2
and Fred Heemstra
1, 3
Open Universiteit Nederland, School of Management, P.O. Box 2960, 6401 DL Heerlen
The Netherlands
Eindhoven University of Technology, Department of Technology management
P.O. Box 513, 5600 MB Eindhoven, The Netherlands
KWD Resultmanagement, P.O.Box 551, 3430 AN Nieuwegein, The Netherlands
Abstract. The size of an ERP project can be a useful measurement for
predicting the effort needed to complete an ERP implementation project.
Because this measurement does not exist, research is needed to find a set of
variables which can define the size of an ERP implementation project. This
paper shows 21 logical clusters of ERP implementation project activities as a
result of a formal group session. The clusters are based on 405 ERP
implementation project activities retrieved from literature. These clusters can be
used in further research to find variables for defining the size of an ERP
implementation project.
1 Introduction
Globalization has put pressure on organizations to perform as efficient and effective
as possible in order to compete in the market. ERP is a key ingredient for gaining
competitive advantage, streamlining operations, and having “lean” manufacturing [1].
ERP projects are large and risky projects which affect large parts of the organization
and lead to changes in the way the organization performs its tasks. The costs for
implementation are usually very high and also very hard to estimate. Even cases exist
where ERP implementation projects led to bankruptcy [2, 3]. Francalanci states that
within the total cost of the implementation project, the software costs represent only a
fraction of the overall cost of ERP projects, less than 10% over a 5-year period [4]. In
addition Willis states that consultants alone can cost as much as or more than five
times the cost of the software [5], this is confirmed by Von Arb who indicates that the
consultancy costs can be 2 to 4 times the software license costs [6]. This indicates that
the effort required for implementation of an ERP system consists mostly of effort
costs. Von Arb also argues that the license and hardware costs are fairly constant and
predictable and that only a focus on a reduction of effort costs is realistic. The
conclusion is legitimate that the total effort is the most important and difficult factor
to estimate in an ERP implementation project. Therefore the main research of the
Janssens G., Kusters R. and Heemstra F. (2007).
Clustering ERP Implementation Project Activities: A Foundation for Project Size Definition.
In Proceedings of the 1st International Joint Workshop on Technologies for Collaborative Business Processes and Management of Enterprise
Information Systems, pages 23-32
DOI: 10.5220/0002413800230032
authors focuses only on the estimation of the total effort needed for implementing an
ERP system.
This paper takes a first step in this research by answering which activities exist in
ERP projects according to literature and how these can be clustered as a basis for
defining the size of an ERP project. It will start with explaining the approach and goal
of the research, followed by a literature review on ERP project activities. After that it
will present the clustering approach and results followed by conclusions and
2 Research Approach
When examining more or less successful methods for predicting software
development effort, it is to be expected that in the area of implementing ERP systems,
measurements can also be found for predicting implementation efforts.
However, Stensrud [7] already indicated that although many effort prediction
systems exist, none unfortunately have been specifically devised for ERP projects.
Heemstra and Kusters [8] collected candidate cost driver variables from literature and
asked experts in two major companies for their opinion about the relevance of these
variables. One of their conclusions was that the size of an ERP implementation is a
major cost driver in ERP implementation projects. In software development the size
of the software can be expressed in a single variable such as number of program lines
or function points [7]. By using this variable in a formula with several parameters,
useful predictions of the development effort can be made. Can similar variables be
found for predicting the implementation effort in an ERP project? According to
Stensrud several variables together should be used to express this size. Francalanci [4]
used three variables for her size definition: organizational size, configuration size and
technical size. Von Arb [6] used two variables for size definition in his dissertation:
number of users and number of ERP (sub)modules. As far as the authors can conclude
from studying available publications on this topic, no further research has been done
in defining the size of an ERP implementation project. All the mentioned researchers
concluded that size cannot be expressed as a single variable as in software
development, but should be expressed as a multidimensional variable. ERP
implementation projects are complex projects where successful organizational,
technical and people strategies are critical factors for success [9]. Because an ERP
implementation project is confronted with many different aspects, the authors
postulate the hypothesis that an ERP implementation project consists of a collection
of clusters of activities with their own focus on implementation costs and project size.
Clusters of activities include: the preparation of the appropriate technical
infrastructure, the business process redesign or the installation of the software. Of
course these clusters of activities will be related to each other, but the authors expect
them to influence the total cost of the implementation project fairly independently. If
size variables can be found for these clusters and these variables could be used as an
estimator for the prediction of the effort needed for these clusters, these variables
could be the dimensions of the multidimensional variable which defines the size of an
ERP implementation project.
In order to define these clusters, the activities in an ERP implementation project
must be known. In methodologies for (regular) information systems development, all
relevant activities are described and defined in terms of goals, results and necessary
resources. During planning, activities relevant in a specific situation will be selected
from this methodology. It goes without saying that not all activities are relevant in
every project. There is no reason to expect that an ERP implementation project will be
different in that matter. Therefore this research is based on the assumption that a
range of activities exists which represents the most relevant activities in an ERP
project. The relevant ERP implementation activities were retrieved from published
research. Although several authors showed the phases in an ERP project and activities
within [10], a complete list of all relevant activities in an ERP implementation project
was not found unfortunately. Therefore papers were collected which listed activities
within an ERP implementation project. By examining papers with different views the
authors of this paper expect to have found the most relevant activities.
This paper tries to lay a foundation for the definition of the size of an ERP project.
Because it is expected that the costs for effort will constitute the greatest part of the
total cost of an ERP implementation project, the first logical step is to define which
activities that require human effort are important in an ERP project. Activities are
always performed for a reason, i.e. to reach a certain goal and can be grouped into
logical clusters which contribute to the same intermediary product or products. For
instance, an intermediary product such as ‘trained users’ can be achieved by a cluster
of activities like: ‘prepare training material’, ‘train the trainers’, ‘set up training
infrastructure’, ‘train users’ etcetera.
3 Objective of this Research
The objective of this research is to define logical clusters of ERP project activities.
This paper will show the method and results in retrieving important ERP activities
and the results of this first formal attempt to cluster these activities into clusters which
contribute to similar intermediate products. This paper aims at answering the next
research questions: Which activities in general exist in ERP projects according to
literature? What is a useful method to cluster these activities? What is the result of a
first clustering of these activities?
4 Literature Review on ERP Project Activities
A literature search was performed aiming at finding papers in which activities within
an ERP implementation project were listed. From these papers a collection of names
and expressions of activities was retrieved.
A paper was selected if it showed at least one list of activities performed in ERP
selection, implementation or maintenance. A total of 23 papers were found with lists
of ERP activities. These papers can be divided into three categories:
1. Papers which relate risk factors and Critical Success Factors (CSF’s) to
activities and/or project phases.
2. Papers about cases which describe the phases and activities of the actual
3. Papers which describe standard project phases and activities from consultancy
firms or ERP software suppliers.
It can be expected that these three types of papers will show the important project
The next section will discuss the retrieved papers grouped by the three categories.
Although the authors aimed at activities that are part of the implementation
project, activities were also recorded in this literature research that belong to the pre-
implementation phase and maintenance phase of an ERP system.
4.1 Papers with Research based Phases and Activities
These research studies relate risk factors, critical success factors or other influencing
factors to activities and/or project phases. These authors based their framework of the
standard activities and project phases on other scientific research and in some cases
performed interviews with experts to enhance their framework.
A first example of this type of research is by Parr and Shanks [11]. The purpose of
their research was to create a project phase model (PPM) of ERP project
implementation. They based their model on other process models of ERP
implementation from other researchers and tried to synthesize these models into one
model which also recognizes the importance of the planning and post-implementation
stages. They used the model in 2 case studies to examine the relationship between the
CSF’s from their earlier research and the phases to the PPM. Rajogopal [12] used a
stage model to analyse six manufacturing firms that had one of the widely used ERP
systems to retrieve factors of influence in the various stages of ERP implementation.
He based his stage model on a six-stage model from Kwon and Xmud and other
authors. Al-Mashari et al. [13] presented a novel taxonomy of the critical success
factors in the ERP implementation process. They based their taxonomy on a
comprehensive analysis of ERP literature combining research studies and
organisational experiences. In their taxonomy they showed three major ERP phases.
In these phases they also described project activities based on an analysis of ERP
Ehie and Madsen [14] studied 38 critical issues in ERP implementation to measure
the critical factors of ERP implementation. They developed a questionnaire based on
five stages of ERP implementation. Stages are based on reviews of literature and
extensive personal interviews with ERP consultants. In their investigation on critical
management issues in ERP implementation Kumar et al. [15] divided the project
activities into 2 phases ‘dollars to assets’ and ‘assets to impacts’. They described the
typical activities within these phases. They based their phase and activities on
innovation process stage models from other authors. They used these activities in
open-ended questions in a questionnaire for ERP project managers of 20 Canadian
organizations. The aim of the questionnaire was to find critical management issues.
Hallikainen et al. [16] developed and tested a model to support the decision which
modules are implemented and in which order. They based their model on the phase
model of Bancroft. In their paper in which they seek to provide a conceptual model
that explains the complexity of an ERP system to project managers in a non-technical
manner, Marnewick and Labuschagne [17] also present an ERP implementation
methodology, which consists of 5 steps. Somers and Nelson [18] examined the ERP
project from different viewpoints: Players, ERP Project Life Cycle Stages and
Activities. Their main purpose was to analyze the importance of key players and
activities across the ERP life cycle by designing a questionnaire which 116 companies
returned. They adopted the six-stage model from Rajagopal [12]. For every phase
they derived the key activities from other research studies. The same six-stage model
was used by Somers and Nelson [19]. They questioned 86 organizations for retrieving
the impact of Critical Success Factors (CSF’s) across the stages of ERP
implementations. The top CSF’s listed for every ERP implementation stage, largely
consist of project activities. Umble et al. [20] identified CSF’s, software selection
steps and implementation procedures critical to a successful implementation. Based
on available resources and own experiences, including a case study they showed the
most important activities for ERP system selection and implementation steps. The
activities for selecting an ERP system were presented by Wei and Wang [21]. They
constructed a comprehensive framework for selecting an ERP system and applied it to
a case in Taiwan. Followed by a research paper in which they presented a
comprehensive framework for selecting a suitable ERP system, based on the analytic
hierarchy process (AHP) method from Saaty [22]. Wagner and Antonucci [23]
studied whether there are different ERP implementation approaches and models for a
large-scale integrated ERP system in the public sector as compared to the private
sector. For their research they used a generalized structured implementation. Markus
and Tanis [24] described various subjects of ERP systems for educational purposes.
They based their phases on other models from other authors. For every phase they
described typical activities, common errors or problems, typical performance metrics
and possible outcomes. Latvanen and Ruusunen [25] used a socio-technical model of
risk management of ERP projects. Mabert et al. [26] compared and evaluated the use
of regression analysis, logistic (logit) models, discriminate analysis and data
envelopment analysis (DEA), for empirical data from ad survey of ERP
implementations in the US manufacturing sector. For this they used key planning,
decision and implementation management variables for the implementation phases.
They did not specify important activities within these phases. Sumner [27] identified
risk factors unique to ERP projects by interviewing ERP project managers in 7
companies. For this research she used five ERP project phases.
4.2 Papers with Case-based Phases and Activities
These research studies present case studies of ERP implementation projects. The
purpose of these studies is to show in detail what happened in an actual case or to use
a case to test a construct.
Berchet and Habchi [28] studied an ERP implementation project at Alcatel. The
project was carried out according to a five-stage model. They also described
important activities for every phase. In describing the ERP implementation at Rolls-
Royce Yusuf et al. [29] carried out an in-depth study of the issues behind the process
of implementation. The implementation plan at Rolls-Royces consisted of 4 main
phases. In their description of these phases the main activities were also described.
Sarker and Lee [30] tested three critical success factors in a case. They concluded that
only the CSF ‘strong and committed leadership’ could be empirically established as a
necessary condition. The case company implemented ERP by three phases.
4.3 Papers with Project Phases from Consultancy Firms and ERP Suppliers
One paper specifically described ERP implementation methodologies used by
consultancy firms or ERP suppliers.
Bruges [31] showed the phases and main activities from three methodologies:
AcceleratedSAP (ASAP), The Total Solution (Ernest & Young) and The Fast Track
Workplan (Deloitte & Touche).
4.4 Retrieved Activities
From these three types of papers the list of activities was retrieved. Because the
intention is to cluster these activities into logical units, no attention was paid to the
phases mentioned in the papers. As shown above there is a variety of the numbers and
names for project phases. Therefore only the activity names were retrieved.
In total 402 activities were recorded. Of course the same activity was mentioned
more than once. Double names, synonyms or homonyms were not filtered out for
reasons as discussed below in the metaplan session. These activities should be
categorized unbiased. A filtering of the activities before the session would result in
activities selected and named by the personal preference of the researchers.
5 Clustering Approach
A grouping technique was needed in order to be able to categorize the retrieved
activities into logical clusters of activities. As mentioned before the selection and
testing of the technique was also a research goal.
Except for its name and in most cases the project phase, no more properties of an
activity were available. Therefore the clustering can only be done by human
judgement. If this is done by one human individual, bias and limited knowledge will
influence the result. However judgement by several individuals and group interaction
will improve the quality of the results. Unfortunately members of freely interactive
groups are often dissatisfied with group interaction [32]. The number of found
activities (402) also implies the need for a formal technique. According to Howard a
Nominal Group Technique (NGT) improves the output and satisfaction of the group
members [32]. For this research a low-cost, fast and easy clustering technique was
needed. Therefore the metaplan technique was chosen, which can be viewed as a
Nominal Group Technique (NGT).
The metaplan technique was developed by Wolfgang and Eberhard Schnelle and
is a simple visual technique which can be used by groups to structure thinking
processes within the context of group work. A moderator leads the group discussion.
Ideas are generated by group members and noted on cards. Finally, these cards are
organized into categories and may show new results of which the single persons were
not aware.
This metaplan session was performed as a first step in categorizing i.e. clustering
ERP activities in clusters which are logical groups of activities in an ERP
implementation project which contribute to the production of the same intermediary
products. Of course the activities found in the papers are not comprehensive.
However, it is reasonable to expect that the activities mentioned in these papers are
important activities in an ERP implementation project and will influence the total
project effort. The goal of this first session was to find out whether activities can
easily be clustered and if a technique like the metaplan technique can be used in
future to improve the clustering by more experts.
The first step in a regular metaplan session is a brainstorming part from which
ideas are generated and noted on cards. In this case there was no brainstorming
session for retrieving possible ERP activities. This was replaced by retrieving
activities from relevant scientific papers in which phases and activities within these
phases were described. The list retrieved from these activities is probably more
complete and relevant than by brainstorming. Of course there are many synonyms and
homonyms, but this also will be the case in an actual brainstorming session. Only the
categorizing part of the metaplan technique was used. The names of the 402 activities
where printed on 402 post-it notes. Of these activities the following data were printed:
name, project phase if present and title of the paper.
The metaplan session was performed by the authors of this paper in a 3-hour
meeting. The session was prepared by the first author. The participants of this session
were instructed to categorize these post-it notes into logical clusters by sticking them
to a wall. The participants should categorize by bearing strongly in mind that clusters
should not relate to project phases, but that activities within a cluster should strongly
contribute to the same intermediate product or products of an ERP implementation.
After assigning all relevant activities to a cluster, the clusters were studied by the
group in detail, which resulted in some rearranging of activities and also in some
subgroups within the main clusters. After this session the clusters and activities within
the subgroups were recorded in a spreadsheet and obvious double activities and
synonyms removed in a two-hour separate session by the first two of the authors. In
this session the cluster names and logical sequence were also enhanced.
6 Results
From the outcomes of the session it can be concluded that the metaplan technique is a
suitable technique for clustering ERP activities.
Preparing the session was a labour-intensive process. The session itself took about
3 hours, mainly caused by the large number of activities (402). The categorizing itself
was not a difficult task. The method could also be useful in following research where
more experts should perform the same exercise. Although for practical reasons it
would be advisable to perform this session by applying a method and software to do
the clustering independent from time and place. If experts could perform the
clustering whenever they want and wherever they want, the willingness to participate
will be higher. As also shown by Howard, support of this process by a Group
Decision Support System (GDSS), which can support clustering in different locations
and/or at different times, leads to the same quality of the results [32].
Table 1 shows the found clusters and subclusters. Table 1 also shows that 208
unique activities were assigned to the clusters and/of subclusters. In the second
session the homonyms and synonyms from the 405 activities were removed, which
led to 208 unique activities. The complete list of activities is available through the
Table. 1. Found clusters and sub clusters.
Clusters Subclusters Number of unique activities
Vendor selection 4
Product selection 16
Project configuration
Project management
Management 4
Communication to organization 4
Organizational and system design
Current state analysis 5
Organizational requirements 7
Requirements ERP system 8
High level Design 6
Configuration and installation
System configuration 17
Data conversion 4
System integration 9
ERP system testing 14
System implementation
Training Implementation Staff 2
Training users 9
Training maintenance staff 2
Set up maintenance
7 Conclusion and Discussion
The results of the research described in this paper are clusters of activities. It forms a
basis for further research on this subject. Because the clustering has been done by a
group of three authors, future research should increase this group and further verify
these activities and clusters. Future research should also check these activities against
activities retrieved from real life projects. There should be a check whether activities
from real-life projects can be categorized according to the found clusters of activities.
It should of course also be checked whether the activities that can be found in real-life
project documentation occur in the list of activities from the literature search.
As described before, the metaplan technique is a suitable technique for clustering
activities. The use of a Group Decision Support System (GDSS) can facilitate the use
of this technique. The same exercise can easily be performed by other researchers.
The results of this paper will also be used to perform a first exploration into the
practical use of the clusters for defining variables which could be used to define the
size of an ERP implementation project. As discussed in the research approach, the
size of an ERP implementation project should be expressed in a multidimensional
variable. At this point in time the authors assume that the clusters can serve as the
dimensions by which an ERP implementation project can be viewed.
The first impression of the authors is that the sub clusters and not the clusters
should be the starting point for the definition of variables, because the level of detail
of the clusters seems to be too low to be able to easily find variables. However, this
has to be verified in further research. For the subclusters the most important objects
(for instance: user, trainer etcetera) should be found, followed by variables by which
these objects can be measured (for instance: number of users).
1. Mabert, V.A., A. Soni, and M.A. Venkataramanan, Enterprise resource planning:
Managing the implementation process. European Journal of Operational Research, 2003.
146(2): p. 302-314.
2. Holland, C.R. and B. Light, A critical success factors model for ERP implementation.
Software, IEEE, 1999. 16(3): p. 30-36.
3. Scott, J.E., The FoxMeyer Drugs' Bankruptcy: Was it a Failure of ERP? Americas
Conference on Information Systems, August 13-15, Milwaukee,, 1999: p. 223-225.
4. Francalanci, C., Predicting the implementation effort of ERP projects: empirical evidence
on SAP/R3. Journal of Information Technology, 2001. Volume 16(1): p. 33 - 48.
5. Willis, T.H., A.H. Willis-Brown, and A. McMillan, Cost containment strategies for ERP
system implementations. Production and Inventory Management Journal, 2001. 42(2): p. 36.
6. Arb, R.v., Vorgehensweisen und Erfahrungen bei der Einführung von Enterprise-
Management-Systemen dargestellt am Beispiel von SAP R/3, in Information Engineering.
1997, Institute für Wirtschaftsinformatik der Universität Bern: p. 426.
7. Stensrud, E., Alternative approaches to effort prediction of ERP projects. Information and
Software Technology, 2001. 43(7): p. 413-423.
8. Heemstra, F.J. and R.J. Kusters, Wat bepaalt de kosten van ERP-implementatie?
Management Accounting, 2005(July/August).
9. Aladwani, A.M., Change management strategies for successful ERP implementation.
Business Process Management Journal, 2001. 7(3): p. 266-275.
10. Robey, D., J.W. Ross, and M.-C. Boudreau, Learning to Implement Enterprise Systems: An
Exploratory Study of the Dialectics of Change. Journal of Management Information
Systems, 2002. 19(1): p. p17, 30p.
11. Parr, A. and G. Shanks, A model of ERP project implementation. Journal of Information
Technology, 2000. 15(4): p. 289-303.
12. Rajagopal, P., An innovation--diffusion view of implementation of enterprise resource
planning (ERP) systems and development of a research model. Information &
Management, 2002. 40(2): p. 87-114.
13. Al-Mashari, M., A. Al-Mudimigh, and M. Zairi, Enterprise resource planning: A taxonomy
of critical factors. European Journal of Operational Research, 2003. 146(2): p. 352-364.
14. Ehie, I.C. and M. Madsen, Identifying critical issues in enterprise resource planning (ERP)
implementation. 2005. 56(6): p. 545-557.
15. Kumar, V., B. Maheshwari, and U. Kumar, An investigation of critical management issues
in ERP implementation: empirical evidence from Canadian organizations. Technovation,
2003. 23(10): p. 793-807.
16. Hallikainen, P., H. Kimpimäki, and H. Kivijärvi, Supporting the Module Sequencing
Decision in the ERP Implementation Process. Proceedings of the 39th Hawaii International
Conference on System Sciences - 2006, 2006: p. 1-10.
17. Marnewick, C. and L. Labuschagne, A conceptual model for enterprise resource planning
(ERP). Information Management & Computer Security, 2005. 13(2): p. 144-155.
18. Somers, T.M. and K.G. Nelson, A taxonomy of players and activities across the ERP
project life cycle. Information & Management, 2004. 41(3): p. 257-278.
19. Somers, T.M. and K.G. Nelson, Proceedings of the Annual Hawaii International
Conference on System Sciences The Impact of Critical Success Factors across the Stages of
Enterprise Resource Planning Implementations. 2001.
20. Umble, E.J., R.R. Haft, and M.M. Umble, Enterprise resource planning: Implementation
procedures and critical success factors. European Journal of Operational Research, 2003.
146(2): p. 241-257.
21. Wei, C.-C. and M.-J.J. Wang, A comprehensive framework for selecting an ERP system.
International Journal of Project Management, 2004. 22(2): p. 161-169.
22. Wei, C.-C., C.-F. Chien, and M.-J.J.M.-J.J. Wang, An AHP-based approach to ERP system
selection. International Journal of Production Economics, 2005. In Press, Corrected Proof.
23. Wagner, W. and Y.L. Antonucci, An analysis of the imagine PA public sector ERP project.
System Sciences, 2004. Proceedings of the 37th Annual Hawaii International Conference
on, 2004: p. 8.
24. Markus, M.L. and C. Tanis, Chapter 10: The Enterprise System Experience—From
Adoption to Success. Framing the Domains of IT Management: Projecting the Future
Through the Past, Pinnaflex Educational Resources, Inc., 2000: p. 173-207.
25. Latvanen, H. and R. Ruusunen, Management of Risks in an ERP Implementation Project,
Turku School of Economics, 2001. p. 20.
26. Mabert, V.A., A. Soni, and M.A. Venkataramanan, Model based interpretation of survey
data: A case study of enterprise resource planning implementations. 2005. In Press,
Corrected Proof.
27. Sumner, M., Risk factors in enterprise-wide/ERP projects. Journal of Information
Technology, 2000. 15(4).
28. Berchet, C. and G. Habchi, The implementation and deployment of an ERP system: An
industrial case study. 2005. 56(6): p. 588-605.
29. Yusuf, Y., A. Gunasekaran, and M.S. Abthorpe, Enterprise information systems project
implementation: A case study of ERP in Rolls-Royce. International Journal of Production
Economics, 2004. 87(3): p. 251-266.
30. Sarker, S. and A.S. Lee, Using a case study to test the role of three key social enablers in
ERP implementation. Information & Management, 2003. 40(8): p. 813-829.
31. Bruges, P., ERP Implementation Methodologies. MSIS, 2002. 488.
32. Howard, M.S., Quality of Group Decision Support Systems: a comparison between GDSS
and traditional group approaches for decision tasks. 1994
, Eindhoven University of
Technology: Eindhoven. p. 219.