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 Deﬁnition.

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

 SciTePress

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

discussion.

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

projects.

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

activities.

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

literature.

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

authors.

Table. 1. Found clusters and sub clusters.

Clusters Subclusters Number of unique activities

Selection

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

Customizing

Infrastructure

Reorganization

System implementation

Training

Training Implementation Staff 2

Training users 9

Training maintenance staff 2

Set up maintenance

TOTAL

208

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).

References

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.