CHARACTERIZATION OF CONSULTANT ACTIVITIES

IN ERP PROJECTS

A Case Study

Emiliano Lutteri and Barbara Russo

Department of Computer Science, Free University of Bolzano, Piazza Università 1, Bolzano, Italy

Keywords: ERP implementation project, Enterprise resource planning, ERP upgrade project, Consultants activities.

Abstract: Enterprise Resource Planning (ERP) systems are very common worldwide, but their implementation and

upgrade projects are expensive, complex and often unsuccessful. A great role in their implementation is

played by the consultancy firms, which provide manpower and qualified knowledge. Often, IT managers, on

the preparation stage, need to know how the project will be organized, how the resources will be distributed

and which effort will be necessary from the employees to perform a successful project. Through a case

study we aim to define a way to measure the business value of the consultancy and understand if it is

possible to build a model to achieve this result.

1 INTRODUCTION

An Enterprise Resource Planning (ERP) system is an

enterprise wide packaged application software with

full integrated business processes for enterprise

management. Today, ERP systems have become a

basic business need for many organizations.

Unfortunately, many implementations have

terminated before completion and didn’t achieve

their business objectives even a year after the

implementation. One of the reasons of this failures is

the lack of competence on the ERP deployment and

on the maintenance of the company. Typically, these

activities are outsourced to external consultants and

vendors and their contribution is crucial for

implementing an ERP system. External expertise

and internal competence are both critical resources.

IT managers base their decision on existing

benchmarks for the evaluation of proposals of ERP

implementations that often emphasize the consulting

services. Therefore, with this work we aim at

defining a way to measure the business value of the

activities of consultants and also to build a first

model to achieve this result.

In section 2, we briefly review the literature on

ERP implementations. Section 3 describes the

research settings, question and methods, Section 4

introduces the findings. Discussion, limitations and

future works are respectively described in section 5,

6, and 7.

2 LITERATURE REVIEW

ERP systems are very common platforms

characterized by their modular structure; each

module handles a specific set of business processes

of the company (Bingi et al, 1999). The

implementation of an ERP system is an extensive,

lengthy and costly process, specifically in related

services such as consulting, training and system

integration (Parr et al, 2000; Parr and Shanks,

2000,Esteves and Pastor, 2001.)

Implementing ERP Systems is a complex process

in technical and organizational aspects. Firms need

experienced people for their process implementation

(Esteves and Pastor, 2002). Often they didn’t have

enough resources in house, and so they outsource

part of the implementation to external consultants.

(Wang and Chen, 2006; Holland and Lightet al,

1999) Consultants are involved into ERP

implementation projects to provide additional skills,

knowledge, or simply manpower not available at the

customer, (Haines and Goodhue, 2003). In this

respect, Chan (1999) hypothesized that an ERP

implementation should rely on a composite team that

includes vendors, consultants and customers. In

addition ERP maintenance might require a similar

effort due to system complexity, and the large

number of stakeholders involved (Salmeron and

Lopez, 2010).

293

Lutteri E. and Russo B..

CHARACTERIZATION OF CONSULTANT ACTIVITIES IN ERP PROJECTS - A Case Study.

DOI: 10.5220/0003508902930300

In Proceedings of the 13th International Conference on Enterprise Information Systems (ICEIS-2011), pages 293-300

ISBN: 978-989-8425-55-3

 2011 SCITEPRESS (Science and Technology Publications, Lda.)

2.1 Implementation and Maintenance

Projects

The first projects implemented during the life cycle

of an ERP system are Implementation and

Maintenance Projects. The latter includes

Enhancement, Roll-out and Upgrade projects.

In any of the representations of the lifecycle of

an ERP system existing in literature (PuiNg et al,

2002), Implementation and Maintenance are clearly

separate stages. Implementation projects are crucial

for their impact on the company’s organization

because they introduce innovation and change in the

overall asset of the business activities and involve

the majority of the professional roles. Maintenance

projects need significant investments and they must

be carefully designed before being undertaken.

Enhancement projects, present often a lower

complexity, but they improve existing ERP systems.

The roll-out projects are often used to implement

the same functionalities of the whole system, in

further domains of the company. They are used to

expand the company’s business, using the same

organizational model designed and tested for the

implementation projects. The upgrade project

concerns entire upgrade of the system that is

modified to adapt it to new features implemented in

the new software version, or to adapt them to new

technologies or architectures, in order to improve

business, competitive advantages, and system

integration (SeePui et al., 2002). A key element of

the implementation of these different types of

projects in ERP consists in the activities of the

consultants. Their expertises, their ability to interact

with the project team, and the way they transfer their

knowledge of the application to customers, have

been identified as possible factors of success of the

project.

Conversely, an upgrade project, in which, often,

the software customizations, already developed

during the previous release, have to be rewritten into

the new version, could require a greater effort of

software development activities and a lower

customizing activity (parameter), because in these

projects, usually, the processes are not modified.

2.2 Theoretical Model of ERP Life

Cycle

In our work, we refer to the theoretical model

proposed by Markus and Tanis (2000) organizing

the various events that guide the completion of an

ERP project in four stages (Chartering, Project,

Shakedown and Onward & Upward), the same

phases can be used in implementation projects and

upgrade projects as described by Nah and Delgado

(2006) in their work.

2.3 The Role of Consultants

Researchers have highlighted the prominent role of

external consultants in technology implementation.

(Kraemmergaard and Rose, 2002, Bingi et al., 1999,

Plant and Willcocks, 2007). Resolving conflicts and

smoothing the relationship with consultants is of

foremost importance (Wang & Chen, 2006) as well

as facilitating knowledge transfer from the

consultant to the company (Al-Mashari et al., 2003)

so as to decrease the dependency on the vendor /

consultant. Much of the knowledge owned by the

consultants concerns ERP customization. (Wu and

Wang, 2006). Somers and Nelson (2004) identify

key players and activities across the ERP project life

cycle. External consultants, top management and

end-users are the key people that will significantly

impact the process and outcome of an ERP

implementation (Wang & Chen, 2006, Wang et al,

2007).

Involving these people with both business and

technical knowledge into the project team is

essential to achieve success.(Tsai et al., 2010)

In this work, we differentiate between external

and internal consultant meaning with the latter

internal staff that act as consultant.

2.4 Critical Success Factors

The definition of success in Information System and

specifically for ERP system is multidimensional and

dynamic. It depends on so many factors that cannot

be uniquely defined. Shanks et al., (2000)

differentiate between success in the planning and

implementation phase and success in stabilization

and maintenance phase. In the former case, success

refers to projects on time and on budget and in the

latter to organizational performance.

To predict project success, research in IS has

focused on factors influencing ERP success, called

Critical Success Factors (CSFs) (Nah and Delgado,

2006; Nah et al, 2003, Razmi et al., 2009 Holland et

al., 1999, Salimifard et al. 2010,Wu and Wang,

2007). Critical success factors have been defined as

“those few critical areas where things must go right

for the business to flourish” (Parr et al., 2000).

Nah and Delgado (2006) have identified seven

categories of factors (Table 1).

ICEIS 2011 - 13th International Conference on Enterprise Information Systems

294

Table 1: The Critical Success Factor for implementation

and upgrade projects (Nah and Delgado, 2006).

Critical Success Factor Implementation Upgrade

ERP Team composition, 4.37 4.35

Top Management Support 4.31 4

Communication 4.17 4.12

Change Management 4.13 4

Project Management 4.06 4.04

System Analysis, and

Technical Implementation

3.92 3.75

Business Plan and Vision 3.87 3.63

Each factor has been ranked with a five-likert

scale on the results of a survey to experts (being five

the most critical value). Factors’ influence varies on

the type of project (implementation or upgrade).

3 RESEARCH

3.1 Research Question

The implementation of an ERP system is often very

expensive, and a large part of the cost of

implementing and maintaining an ERP system is due

to the cost of the consultancy. In our research, we

aim at investigating the success of an ERP

implementation with particular focus on the

activities performed by the consultants and their

business value during an implementation or upgrade

of an ERP system. In particular, we focus on the

following research question:

Q1 what activities of consultancy are critical for

the success of an ERP implementation or upgrade

project according to objective measurement

principles?

3.1.1 Success Factors and Measures

In our research, we were able to collect data and

measures, in terms of effort and size, on three CSFs:

“Team composition”, “Project management”, and

“System analysis, selection and technical

implementation”. This three factors are included in

our success model in figure 1.

Team Composition concerns professional roles and

competences of the project team. Project team

should be balanced, cross-functional and

representative of the different areas of interest of the

project (Razmi et al., 2009).

Project Management defines responsibility and

scope of the project. The activities in project

management relate to control and monitor the

implementation of the project and its schedule and

budget.

System Analysis and Selection and Technical

Implementation consist in all those activities

related to integration with existing legacy systems,

to definition of architecture and design of the ERP

system and to the selection of the more suitable

software package.

Then we aim at evaluating the business value of

the consultancy characterizing:

 the Team Composition in terms of size of

professional roles involved and in terms of effort of

their activities in ERP projects;

 the System analysis and technical

implementation in terms of the effort spent in the

ERP projects;

 the project management as percentage of time

spent in this activity as well as the allocated

resources. Many of these CSFs refer to activities

made by external consultants. These measures are

reported as indicator as predictor of success in the

model presented in figure 1.

3.2 Research Methods

This preliminary research work, using a case study,

aim at analyze the various projects, the professional

roles played by the internal and external team, and at

categorize the activities done from each category of

professionals, during the implementation and the

upgrade project performed in Energy.

Referring to Markus and Tanis model, we focus

on the "Project stage". During this stage, we have

also collected the information related to the activities

carried out, through the time sheets daily compiled

by external consultants and by the employees of the

internal IT department.

3.2.1 Case Study: Energy

Using the model in presentation, we intend to

develop our research work analyzing the data

gathered in a real company. This is a local firm, of

medium size, located in Italy, with around 450

employees, which produces, distributes and sells

electricity and gas in one region of Italy. For

convenience, we will call this company Energy.

3.2.2 The SAP Projects in Energy

The business information system of Energy is a SAP

ERP system, deployed in 2002, implementing the

modules of SAP R3. During 2003 was implemented

the project SAP ISU Electricity (Electricity) that has

involved the core business processes related with the

distribution and sales of electricity. During 2005,

CHARACTERIZATION OF CONSULTANT ACTIVITIES IN ERP PROJECTS - A Case Study

295

Energy implemented the project SAP ISU Gas

(Gas), derived from SAP ISU Electricity. Then,

during 2006, Energy has implemented the sales

processes on the deregulated national market,

through the SAP ISU Trading (Trading). In 2010,

Energy decided to upgrade their SAP system

released 4.6C toward the new version of the

software named ECC6.0 (Upgrade).The upgrade

project implied a technical upgrade of the whole

software system, then rewriting of all the most

important customizations made in the old version

and finally a strong testing activity of all programs,

functions and processes.

3.2.3 Projects’ Description

The four SAP projects performed in Energy are

described in Table 2, where we summarized data on

size and complexity. In particular, we have classified

them in Implementation, Rollout and Upgrade.

Table 2: The four project under study by type, number of

modules, number of users, number of change requests,

budget and duration.

Project Type Mod Users CR Budg Durat

Nr. Nr. Nr. K€ Months

Electricity Impl 5 100 117 450 10

Gas Enhan. 5 70 14 330 9

Trading Roll. 4 20 19 90 5

Upgrade Upg. 11 220 730 190 5

Table 2 illustrates, the name , the type of the

project, the number of the ERP modules implement-

ted (complexity of the project), and the number of

the New Change Requests (CR) (business

complexity). In the case of the Upgrade project, the

number of CRs indicates the number of programs

that have been changed during the technical

upgrade. The first project, Electricity, is an

Implementation Project. The business processes

were tailored starting from a pre-customized model

for Utilities companies. Although the original

commitment was to reduce as minimum as possible

the customizations (as suggested by (Wu and Wang,

2006)), the number of the CRs implemented is high

(117). This was the first project implemented at the

company and demonstrates poor project success in

scheduling and budget as reported in Table 3.

The second project, ISU Gas, was implemented

starting from the ISU Electricity, because many

parts of the processes were in common. For this

reason the number of new change requests is much

lower (14). This indicates a strong strategy of reuse

to reduce cost and effort. The project was on time

and on budget and, as such, demonstrated a high

degree of success. The third project implemented is

Energy Trading: this was a rollout project directly

derived from ISU Electricity. In our context, this

project was a replication of the first one and as such

has a good degree of reuse (low CRs) but a smaller

complexity of modules implemented. This is

because this project doesn’t include more complex

processes of electricity distribution. Table 3

illustrates the projects and their success according to

the perception of the IT manager of Energy.

Table 3: Success in the four ERP projects.

Project name On time? On budget? Success

Electricity No No No

GAS Yes Yes Yes

Energy Trading Yes Yes Yes

Upgrade Yes Yes Yes

3.2.4 Professional Roles

Analyzing data, we have identified seven different

professional roles in project teams: the System

Specialist (SS) provides technical knowledge about

the software, competence on hardware

configurations and on systems tuning. The Junior

Developer (PrJR) is a programmer with experience

in development, usually less than three years. Senior

Developer (Pr) is a programmer with extensive

experience in development with the programming

languages of the ERP system being implemented

and his skills cover several functional modules of

the system. Junior Consultant (CJR) has work

experience less than 3 years, superficial knowledge

of a limited number of software modules. Senior

Consultant (C) is a practitioner with several years

(minimum 7) of experience and a strong knowledge

about the specific topics of the customer’s firm;

Moreover, they know very well, how the different

modules of the software are working, and they

develop the functional and technical analysis, set the

configuration’s parameters and address the

customizing activities. The Project Manager (PM)

has, for side of the consulting firm, the control of the

external resources involved and he is responsible,

together with the internal project manager, for the

outcome of the entire project.. User (U) is selected

from various operating departments and must be

familiar with business processes and have domain

knowledge of their areas .They are involved at the

analysis and the testing stages.

Table 4 displays the number of the persons

involved and the effort per project by role. The data

regarding the Upgrade project are split among

internal and external team. The percentage is refer-

red to total amount of effort spent in the project.

ICEIS 2011 - 13th International Conference on Enterprise Information Systems

296

Table 4: Effort by team role.

6 PM C CJR Pr PrJR SS U Total

Electricity

Nr 1 6 4 4 2 1 18

Days 34 476 150 369 28 25 1082

% 3,1% 44,0% 13,9% 34,1% 2,6% 2,3% 100,0%

Gas

Nr 1 6 1 4 12

Days 33 252 39 171 495

% 6,7% 50,9% 7,9% 34,5% 100,0%

Trading

Nr 1 4 2 7

Days 2 116 44 162

% 1,2% 71,6% 27,2% 100,0%

Upgrade external

Team

Nr 1 5 1 2 1 2 12

Days 46 129 84 80 10 50 399

% 8,3% 23,3% 15,2% 14,4% 1,8% 9,0% 72,0%

Upgrade Internal

team

Nr 1 4 1 1 2 7

Days N/A 49 46 47 13 155

% N/A 8,8% 8,3% 8,5% 2,3% 28,0%

Upgrade Sum 8,3% 32,1% 15,2% 14,4% 10,1% 17,5% 2,3% 100,0%

Table 5: Effort (in days) per project by activity.

Project PM Cust Dev Test Train Sys Act Supp post Err Hand Tot

Electricity

36 308 392 149 46 25 88 37 1082

3,3% 28,5% 36,2% 13,8% 4,3% 2,3% 8,2% 3,4% 100,0%

Gas

46 184 153 64 10 5 32 494

9,3% 37,2% 31,0% 13,0% 2,0% 1,0% 6,5% 100,0%

Trading

12 88 37 10 1 3 11 162

7,4% 54,3% 22,8% 6,2% 0,6% 1,9% 6,8% 100,0%

Upgrade

49 0 106 242 1 105 17 32 552

8,9% 0,0% 19,2% 43,8% 0,2% 19,0% 3,1% 5,8% 100,0%

3.2.5 Project Activities

We analysed the four projects by the activities

reported in the time sheets (records), differentiating

between internal and external effort. After a deep

analysis of the records, we came up with the

following categorization of activities:

Project management: activities related to

organization, management and control of the project.

Customization: activities to tailor the system on

the customer requirements. This includes analysis of

requirements, parameter setting and tuning.

Development: activities of software develop-

ment needed to satisfy customer requirements that

cannot be satisfied directly from parametric

customizing. It includes analysis, code writing, and

first testing on the development system.

Test: system testing to verify the functionalities

of each module and integration testing to verify

modules integration.

Training: activities performed by external

consultants and addressed to users. They aim at

transferring knowledge about system’s functio-

nalities from external to internal staff.

System Activity: activities needed to install,

prepare, tune and synchronize the different systems

included in the system environment.

Post go live support: activities performed by

internal or external consultants, after the go-live of

the system to stabilize the system in its first

operational phase. The duration of these activities

can give an indication of the success of the project.

Error handling: activities specific for solving

errors detected after the go - live of the project.

Table 6: Electricity: Effort in days by activity and role.

Role PM Cust Dev Test Train

Sys

Act

Supp

post

Err

Hand

Tot

252

48 69 25 44 27 476

CJR

56 11 42 22 10 10 150

4 325 30 10 369

PrJR

5 22 28

Sys

25 25

21 3 8 2 34

Tot 36 308 392 149 46 25 88 37 1082

Table 7: Gas: Effort in days by activity and role.

Role PM Cust Dev Test Train

Sys

Act

Supp

post

Err

Hand

Tot

171

1 30 9 5 24 252

CJR

2 13 15 1 8 39

152 19 171

33 33

Tot 46 184 153 64 10 5 32 495

CHARACTERIZATION OF CONSULTANT ACTIVITIES IN ERP PROJECTS - A Case Study

297

Table 8: Trading: Effort in days by activity and role.

Role PM Cust Dev Test Train

Sys

Act

Supp

post

Err

Hand

Tot

10 1 3 4 116

37 7 44

1 1

Total 12 88 37 10 1 3 11 161

3.3 Model Construction

To build up our success model, we first identified

the success factors to put in input of the model,

among these ranked in the work of Nah and Delgado

(2006) (Table 1): but only the factors we could

measure in the projects analyzed in this work. Then

we identified, for each factor proposed, the measures

that we used to characterize them (Size, Roles;

Effort per Activity). For each project we are able to

identify them in time and budget as indicator of

success, as perceived from IT manager (Table 3).

Speculating on the measure values collected against

the values of the success model,we have determined

which measures actually might predict the success of

the project. Otherwise we have knowledge that other

factor could be indicate success in other context, and

this is a limitation of our model.

Project

type

Succesfull ?

System analysys

Team composition

Project Mgmt

Size, Roles, Effort per activity

Effort per activity

Success factors Measures

Yes

Figure 1: The model of success proposed in the study.

4 FINDINGS

Using the model proposed, we analyze the data

regarding the factors identified as critical for the

success. As first “Team composition”, evaluated

through the following measures:

Size of the team in terms of total number of persons

involved in each project (table 4): we note that,

considering only the external team composition , the

size results high (18) in Electricity, and lower in Gas

(12) and Trading (7) and Upgrade External (12): it

seems that a lower size of the team might be

indicator of success. But we have to be aware of the

business complexity of the projects, it was higher in

Electricity than in the other implementation projects.

Roles: measured in terms of effort spent for each

role in the project. We note that in all projects, the

most part of activities is made by Senior Consultants

(C ). As such, their activity is necessary to achieve

success but, focusing on implementation projects, it

seems that more activities are needed from this role.

Analyzing the role of Junior Consultant, it seems

that this role is not relevant for the success.

Effort per Activity: measured in terms of days

spent per activity done. Analyzing table 5, we see

that the activities are distributed among the different

roles, but the most performed activities are

customizing and development. In the Upgrade

project, no customization has been reported as no

functional upgrade was performed. Electricity

project has the highest effort in development and the

lowest in customization among the projects. We

pose the attention on the activities made by each

role, but in particular by Senior consultants.

Analyzing table 6,7,8 we see that the major activity

done from them (C), excluding Upgrade Project ,is

the customizing (Cust.) activity: 53% of his

activities in Electricity, 67% in Gas and 76% in

Trading. Moreover, in the projects Gas and Trading ,

both successful , Customizing is the most activity

done. Conversely in the project Electricity the most

performed activity results the development, probably

because of the high number of CR. Analyzing this

data, it seems that the customizing activity is critical,

and the major actor is the Senior Consultant, who, to

achieve success, has to do the customizing activity,

in a more focused way, without spending time in

other activities.

Then we analyze the activities related with “Project

management” (PM) that is characterized by the

measure of effort in project management activity:

table 4 shows that the role of project manager is

normally played by only one external employee.

Table 5 shows the effort per project by activity: the

PM activity has a similar value among the four

projects, but we note that the minor value (3,3,%)

regards the project Electricity. this is a not

successful project, That’s why to achieve success we

need an higher effort in this activity.

Finally we evaluate the activities related with

“System analysis, selection and technical implemen-

tation" that in our case is characterized by the

measure of the effort spent in "System's activity",

performed by System specialists (SS) or by

Consultants (C). Analyzing the implementation or

rollout projects the values of the system's activity

appear quite similar. This means that this activity is

not relevant to achieve success. The effort spent in

system activity for Upgrade project, conversely, is

very high, and this measure, together with the test

activity, characterizes very well this kind of projects.

ICEIS 2011 - 13th International Conference on Enterprise Information Systems

298

5 CONCLUSIONS

This preliminary work aim at characterizing the

business value of the professional roles, measuring

the activities performed in implementation and

upgrade of ERP projects to understand which roles

are critical for the project to succeed. We propose a

simple model drafted from these initial observations,

based on the success factors of Nah and Delgado,

(2006) and a set of measures that, evaluated on these

factors characterizes the factors in terms of the

overall project success. By analyzing the distribution

of effort over the activities performed in four

different SAP projects, we found that in our context

the key factors of success are Team composition,

Project management and System analysis and

technical implementation. Using our model we

found that to achieve success, the project team

should not be too large, and we have identified as

critical for the implementation projects the role of

Senior Consultant, that is mainly involved in several

activities. Moreover, we observed that his activities

are critical, that’s why his effort should be well

enough provided and focused on the customization

activity. By upgrade projects, where there is no

customizing activity, the critical activities are

Testing, performed by internal and external

Consultants, and System's activity, performed

mainly by system's specialists.

The success has been also determined by the

increasing knowledge reuse and retain acquired by

the internal staff with the implementation of the

projects. This knowledge allowed the manager to

reduce the cost for external staff and establish an

internal Help Desk that automatically manages the

change requests.

6 LIMITATIONS

The findings of this study are specific to one single

ERP System, the SAP System, and one company.

The size of the company, medium for Europe, the

number of the users involved, the characterization of

the specific business (energy) could limit the

generalization of the findings. Moreover, not all the

professional roles considered - as Junior developer

or junior Consultant – can be found in literature. In

addition, the classification of the activities is made

interpreting the activity's description written from

team members on time sheets. As such, data are

subjective and subject to bias. For the Upgrade

project, an automated system for Help Desk has

been implemented and more objective analysis on

the activities and the requests of change can be

derived. This will be matter of future work. In our

projects, we were able to collect data for three CSFs:

Project Management, Technical Activities and ERP

and Team composition. Other factors were not

considered relevant at time of data collection. For

this reason, the model and the related discussion is

limited.

7 FUTURE WORKS

The success defined in this work concerns the

contractual commitment of the suppliers. The project

has been successful if it has been on time and on

budget at go live. According to Markus and Tanis

(2000), the activities performed after go live are

critical and key indicators of long-term success. As

such, Energy has established a Help Desk service

that automatically collects bug reports and new CRs

and provides solutions.. With this data we can trace

the flow of request and the time of occurrences and

fixing of issues Future work will mine this wealth of

information to get a more objective characterization

of the projects during maintenance.

REFERENCES

AlMashari, M., AlMudimigh, A. and Zairi, M. 2003.

Enterprise resource planning: A taxonomy of critical

factors. European Journal of Operational Research,

Vol.146, Issue 2, pp.352364.

Bingi, P., Sharma, M., Godla, J. 1999. Critical Issues

Affecting an ERP Implementation. Information

Systems Management, Vol. 16 issue 3, summer 1999,

pp.7-8.

Chan R. 1999 Knowledge management for implementing

ERP in SMES, Sapphire 99, 3rd Annual SAP Asia

Pacific, 1999.

Esteves, J., Pastor, J. 2001. Enterprise Resource Planning

Systems Research: An Annotated Bibliography.

Communications of AIS, Volume 7 Number 8.

Esteves, J., Pastor, J. 2002. A framework to analyse most

critical work packages in ERP implementation.

International Conference on Enterprise Information

Systems (ICEIS), 2002, Spain.

Haines, M., Goodhue, D., 2003. Implementation Partners

Involvement and Knowledge Transfer in the Context

of ERP implementation. International Journal of

human computer interaction Vol16,No.1,pp.23-28.

Holland, C., Light, B., Gibson, N., 1999. A Critical

Success Factors Model for Enterprise Resource

Planning Implementation. 7th European Conference

on Information Systems ECIS, Copenhagen, Denmark.

CHARACTERIZATION OF CONSULTANT ACTIVITIES IN ERP PROJECTS - A Case Study

299

Kræmmergaard, P., Rose, J. 2002. Managerial Compe-

tences for ERP Journeys Information Systems

Frontiers 4:2, 199–211, 2002.

Markus, M. L., Tanis, C., 2000. The enterprise systems

experience from adoption to success, in: R.W. Zmud,

M.F. Price (Eds.),(2000), Framing the Domains of IT

Management: Projecting the Future Through the Past.

Pinnaflex Educational Resources Inc., pp. 173–209

(Chapter 10).

Nah, F., Delgado,S., 2006. Critical success Factors for

enterprise resource planning implementation and

upgrade. Journal of Computer Information Systems.

Nah, Zuckweiler, Lau, (2003). "ERP Implementation:

Chief Information Officers Perceptions of Critical

Success Factors". International Journal of Human -

Computer interaction, Vol.16(1), pp.5–22.

Parr, A., Shanks, G., 2000. A Taxonomy of ERP

Implementation Approaches. 33rd Hawaii

International Conference on Science Systems HICSS,

Maui, Hawaii.

Parr, A., Shanks, G. 2000. A Model of ERP Project

Implementation. Journal of Information Technology,

vol. 15, n. 4, December (2000), pp.289-304.

Plant, R., Willcocks, L., 2007. Critical success factors in

international ERP implementations: a case research

approach. Journal of Computer information Systems.

Pui Ng, C., Gable, C. and Chan, T., 2002. An ERP-client

benefit-oriented maintenance taxonomy. The Journal

of Systems and Software, Vol. 64.

Razmi, J., Sadegh Sangari, M., Ghodsi, R., 2009.

Developing a practical framework for ERP readiness

assessment using fuzzy analytic network process.

Advances in Engineering Software 40 (2009) 1168–

1178.

Salmeron J., Lopez, C., 2010. Forecasting Risk Impact on

ERP Maintenance with Augmented Fuzzy Cognitive

Maps. Transactions on Software Engineering, 2010.

Salimifard, Ebrahimi and Abbaszadeh, 2010. Investigating

Critical Success Factor in ERP Implementation

Projects. IEEE 2010 2 ,pp. 82–86.

Shanks, G., Parr, A., Hu, B., Corbitt, B., Thanasankit, T.,

Seddon, P., 2000. Differences in Critical Sucess

Factors in ERP Systems Implementation in Australia

and China: A Cultural Analysis. 8th European

Conference on Information Systems ECIS, Vienna,

Austria, (2000).

Somers, T. M., Nelson, K., 2004. A taxonomy of players

and activities across the ERP project life cycle;

Information and Management, Vol 41, No 3,pp. 257-

278.

Tsai, Schaw, Fan, Liu, Lee and Chen, 2010. An empirical

investigation of the impact of internal/external

facilitators on the project success o ERP: a structural

equation model. Decision Support Systems 50 (2011),

pp. 480 – 490.

Wang, E., Chen, J, 2006. Effects of internal support and

consultants quality on the consulting process and ERP

system Quality. Decision support Systems, Vol 42,

pp.1029-1041.

Wang, Chia-Lin, Jiang, Klein. 2007. Improving enterprise

resource planning (ERP) fit to organizational process

through knowledge transfer. International journal of

Information management .Vol 27, pp 200-212.

Wu, J., Wang, Y., 2007. Measuring ERP success: The

key-users_viewpoint of the ERP to produce a viable IS

in the organization. Computers in Human Behavior

Vol 23 (2007),pp. 1582–1596.

Wu, J., Wang, Y. 2006. Measuring ERP success: The

ultimate user view. International Journal of

Operations &Production Management Vol. 26 No. 8,

2006 pp. 882-903.

ICEIS 2011 - 13th International Conference on Enterprise Information Systems

300